LogicMonitorセキュリティのベストプラクティス
最終更新日: 23 年 2024 月 XNUMX 日概要
LogicMonitor 実装のセキュリティは、LogicMonitor とお客様の組織が共同で責任を負うものです。LogicMonitor ポータルには、お客様が LM Envision アプリケーションのセキュリティを管理できるさまざまな機能が用意されています。お客様は、以下の推奨事項を考慮しながら、組織のセキュリティ要件に合わせてこれらのコントロールを運用する必要があります。セキュリティとアーキテクチャに対する当社の全体的なアプローチに関する追加情報は、以下で確認できます。 (茶事の話はこちらをチェック).
同様に、LogicMonitor Collector のセキュリティを最大限に高めるには、それらが導入されている顧客ネットワークの強力なセキュリティが必要であり、当社はこれらのシステムで十分なセキュリティを維持することを顧客に頼っています。当社は、顧客にこれらのセキュリティのベスト プラクティスを確認して適用することを強くお勧めします。
ポータルセキュリティ
LogicMonitor プラットフォームには、データを自動的に保護する多くの機能が含まれています。パブリック インターネット経由で送信されるすべての情報は、TLS バージョン 1.2 以降の暗号化を使用して、転送中に自動的に暗号化されます。オペレーティング システムのバージョン、SNMP コミュニティ文字列、API 認証情報、デバイス構成ファイル、NetFlow データなどの機密顧客データは、保存前に自動的に暗号化されます。
当社のソフトウェアは、設計、開発、テスト、リリースの各段階でセキュリティを考慮した安全な開発ライフサイクルを使用して開発されています。当社は定期的にプロの侵入テスト会社と契約してプラットフォームのセキュリティを検証し、プロのハッカーによって発見された欠陥を時間どおりに解決しています。
当社の運用システムはセキュリティ強化されたLinuxをベースとしており、脆弱性を継続的にスキャンし、定期的にパッチを適用してセキュリティリスクを軽減しています。当社のプラットフォーム運用の全体的なセキュリティは、ISO 27000標準認証とAICPA SOC2タイプ2コンプライアンスの両方を維持することで検証されています。詳細については、当社の トラストセンター (英語のみ) ポータル。
役割の割り当てと管理
最小特権の原則は、情報セキュリティの基本的な構成要素のXNUMXつであり、LogicMonitorは、そのアプリケーションを可能にするために、きめ細かいロールベースのアクセス制御(RBAC)システムを提供します。
ロールを作成し、デプロイメント構造と要件に最適なアクセス レベルに基づいて最小権限の原則を適用することをお勧めします。全体的な方針として、LogicModules と Collector への「管理」権限は非常に慎重に適用することをお勧めします。これにより、ユーザーは Collector デバッグ機能を使用するか、LogicModules を作成/編集することで、Collector 上で任意のスクリプトを実行できるようになります。
事前設定されたロールを使用する場合は、デフォルトの「管理者」ロールの割り当てをできるだけ少数のユーザーに限定する必要があります。ほとんどのユーザーについては、個人の日常的なアクセスに「読み取り専用」または「確認のみ」ロールを使用することをお勧めします。これら 2 つのロールの主な違いは、「読み取り専用」ではポータル内のデータのみを表示でき、「確認のみ」ではアラートを確認し、SDT を構成できることです。
取るべき行動:
- すべての役割に最小権限の原則を適用する
- ロジックモジュールとコレクターへの「管理」権限は慎重に使用してください
- デフォルトの「管理者」の役割をできるだけ少数の人に制限する
- LogicMonitor がトラブルシューティングの目的で顧客ポータルへのリモート サポート アクセスに使用する「lmsupport」ユーザー アカウントに、最小権限の原則を適用します。
ロールの作成と割り当ての詳細については、を参照してください。 役割.
APIトークン
LogicMonitor は、プラットフォームへの認証に LMv1 や OAuth 2.0 ベアラー トークンなどの API トークンを作成する機能をサポートしています。これを行う際は、API トークンを作成して「API のみ」のユーザーに割り当てることを強くお勧めします。このユーザー タイプにはパスワードやその他のユーザー インターフェイス固有のフィールドがないため、より安全なオプションになります。また、API トークンが割り当てられたユーザーには、使用する API エンドポイントに必要な権限に限定された権限を持つロールを割り当てる必要があります。
クライアント側のアプリケーション コードで API トークンを使用するときに実行する必要があるアクション:
- トークンを秘密に保つ: API トークンはパスワードのようなもので、リソースへのアクセスを許可します。トークンは秘密にしておき、アプリケーションのクライアント側コードや公開アクセス可能なリポジトリにハードコーディングしないようにしてください。
- 安全なストレージ: トークンをクライアント側で安全に保存します。プレーンテキストで保存したり、ローカル ストレージや Cookie などの安全でないストレージ メカニズムを使用したりしないでください。サーバー側アプリケーションにトークンを展開する場合は、環境変数または安全なシークレット管理システム (推奨) を使用してトークンを保存およびアクセスします。
- 監査ログ: トークンの使用状況の監査ログを保持して、疑わしいアクティビティや不正アクセスの試みを監視します。プラットフォーム監査ログはポータル内で検索可能で、API を介して既存の顧客 SIEM またはログ管理システムと統合できます。
- 単一目的: クライアントまたはアプリケーションごとに一意のトークンを生成します。 1 つのトークンは、1 つのソースの場所から 1 つの目的でのみ使用する必要があります。
- ユーザーを教育する: API トークンのセキュリティの重要性と、それらを処理するためのベスト プラクティスについて、開発者とユーザーに教育します。
- API トークンに管理者権限を割り当てないでください。これは API 機能には必要ありません。
- 「lmsupport」というリモート アクセス サポート ユーザーに API トークンを割り当てないでください。
LogicMonitorのREST APIの詳細については、以下を参照してください。 LogicMonitorのRESTAPIを使用する.
lmsupportユーザーの詳細については、 ユーザー.
エンドユーザー認証
LogicMonitor は、エンドユーザー認証の 2 つの方法をサポートしています。
a. 当社の「標準」ユーザーID/パスワードシステム(または)
b. SAML v2 準拠の ID プロバイダー (IdP) との統合による SSO。お客様はどちらのオプションも使用できますが、IdP で SSO を使用することをお勧めします。
弊社の標準認証を使用する場合は、すべてのアカウントに 2 要素認証を適用することを強くお勧めします。前述のように、LogicModules および Collectors に対する「管理」権限を含むロールはセキュリティ上重要なため、適切に保護する必要があります。
SAML 2.0 IdP との SSO 統合を使用する場合は、LogicMonitor ポータルにアクセスできるすべてのエンドユーザーに対して XNUMX 要素認証を要求するように IdP を構成することを強くお勧めします。弊社の認証方法が IdP に置き換えられているため、SAML 統合を使用する場合、弊社の製品内 XNUMX 要素認証は利用できません。
ご注意: 31 年 2024 月 XNUMX 日までに、ポータル内でローカルにプロビジョニングされた (つまり、SAML 経由ではない) すべての顧客アカウントで XNUMX 要素認証を利用することが義務付けられます。
取るべき行動:
- 可能な限り、SAMLとIdP経由でSSOを使用する
- すべてのアカウントで常に2要素認証を使用する
ネットワークアクセス許可リスト
ポータルにはブルートフォース認証攻撃に対する保護機能が組み込まれていますが、より完全な防御ラインを提供するために、承認されたIPアドレス範囲の許可リストを定義することをお勧めします。IPの許可リストの定義の詳細については、以下を参照してください。 ポータル設定の構成.
モバイル アプリケーション経由でポータルにアクセスするには、ネットワーク許可リストの構成が条件となることに注意してください。一般的な構成では、モバイル デバイスはポータルにアクセスする前に、まず企業ネットワークに接続する必要があります (VPN などを使用)。
取るべき行動:
- ポータルアクセスの許可されたIPアドレスのリストを定義および構成する
監査ログの統合
LogicMonitorは、ポータル内の認証アクション、構成変更、およびその他の注目すべきイベントを記録する製品内監査ログ機能を維持します。 SIEMまたはその他のログ集約/分析サービスを維持している場合は、RESTAPIを使用して監査ログをそのプラットフォームにエクスポートすることを検討してください。 中央のログ管理システムに入ると、通常、特定の種類の情報の通知を構成し、既存のデータ保持ポリシーに従ってデータを保持できます。
取るべき行動:
- REST APIを活用して監査ログをSIEMにエクスポートします
LogicMonitorの監査ログまたはRESTAPIを介した監査ログのエクスポートの詳細については、を参照してください。 監査ログについて と ロジックモニター REST API それぞれドキュメント化されています。
ログイン試行回数
LogicMonitor はブルート フォース攻撃に対するセキュリティを提供します。ログイン試行が 5 回失敗すると CAPTCHA が開始され、20 回失敗するとアカウントがロックされます。
コレクターのセキュリティ
LogicMonitor Collector は、高いセキュリティを念頭に置いて慎重に設計および開発されています。コレクターと LogicMonitor プラットフォーム間の通信では、パブリック署名された証明書を使用した HTTPS/TLS が使用され、コレクターと LogicMonitor プラットフォーム間の中間者攻撃を防止します。各コレクターは、定期的にローテーションされる強力な認証情報を介して、LogicMonitor プラットフォームに暗号化キーで接続されます。コレクターによって処理されるすべての機密の監視対象デバイス データはメモリに保存され、ディスクに書き込まれることはありません。さらに、お客様は、デバイス認証情報の保存に業界で認められた認証情報保管ソリューションを利用することもできます。
最小限の権限でコレクターを実行する
LogicMonitor のベスト プラクティスでは、コレクターを顧客の環境内で可能な限り最小限の権限でインストールし、ルート、ローカル管理者、またはドメイン管理者アカウントとして実行しないようにすることが推奨されています。
さらに、コレクターには、特定のデバイスの計測情報を収集するための最小限の権限を付与する必要があります。通常は、読み取り専用権限で十分です。各デバイスのアクセス構成は、LogicMonitor の顧客が完全に管理しており、サポート ドキュメントには、必要な最小限の権限を構成する方法の詳細が記載されています。
あなたが取るべき行動
- 以下の参照に従って、常に最小限の権限でコレクターをインストールして実行してください。
最小権限でコレクターをインストールする方法については、以下を参照してください。
- Linux の非ルートへのサービス ユーザーの移行
- Windows のサービス ユーザーを非管理者に移行する
- WinRM を使用して Windows の非管理者ユーザーへの移行を照会する
- WMI を使用して Windows の非管理者ユーザーへの移行を照会する
オペレーティングシステムの強化
コレクターはセキュリティを最優先に設計されていますが、アプリケーションのセキュリティは基礎となるインフラストラクチャのセキュリティと同程度にしか確保できません。そのため、コレクターがインストールされているシステムでは、業界のベスト プラクティスに沿ってセキュリティを強化することをお勧めします。
最も包括的なアプローチとしては、CIS ベンチマークで指定されている強化ガイドラインを「レベル 1 - サーバー」構成プロファイルに適用することをお勧めします。
完全なCISベンチマークの適用が不可能な場合は、ベースラインセキュリティコントロールの最小限のセットとして以下を検討する必要があります。
- 管理者アカウントに強力なパスワードを設定する
- 必要に応じて他のデフォルトのパスワードを変更します
- ゲストアカウントと不要なネットワークサービスを無効にする
- ホストベースまたはネットワークベースのファイアウォールを使用して、パブリックインターネットからシステムを保護します
- ベンダー提供のセキュリティパッチを最新の状態に保つ
マルウェア対策の免除
コレクターはリリース前に厳格なセキュリティ テストを受けていますが、そのトラフィック パターンは、ヒューリスティック ウイルス対策やインテリジェント エンドポイント検出および応答サービスなどのマルウェア対策ツールにとって疑わしいものになる可能性があります。LogicMonitor コレクター バイナリは広く信頼されているルート CA によって署名されていますが、コレクター システムでこのようなソフトウェアを実行する場合は、コレクターの動作に干渉する可能性があり、免除が必要になることに注意してください。
マルウェア対策の干渉の症状には、コレクター サービスの頻繁な再起動やプロセスのクラッシュなどがあります。推奨はされませんが、LogicMonitor コレクター アプリケーション ディレクトリの再帰的な除外を構成することができます。再帰的な除外を必要とするデフォルトのディレクトリは次のとおりです。
Windows: C:\Program Files\LogicMonitor\
Linux: /usr/local/ロジックモニター/
一般的なマルウェア対策パッケージで除外を設定する方法の詳細については、次のリソースを参照してください。
- Symantec Endpoint Protection: スキャンからファイルまたはフォルダを除外する
- ESET: ESET Windows ホーム製品でファイルまたはフォルダーをスキャンから除外する
- Sophos: グローバル除外
- FortiClient: ウイルス対策除外リストの管理
脆弱性スキャンとコレクター
CollectorはJavaアプリケーションであり、Collectorインストーラーに含まれている(Javaランタイム環境)JREで実行されます。 歴史的に、これらはOracle JREに基づいていましたが、最近のバージョンにはOpenJDK標準に基づくJREが含まれています。
セキュリティ研究者は、JRE リリースのすべてに欠陥や脆弱性を発見することになります。LogicMonitor Collector は、JRE で発見される種類のセキュリティ問題によって基本的に影響を受けることはありませんが、Early Access Collector の各リリースに最新の安定した JRE バージョンを含めることで、これらの問題に積極的に対処しています。
脆弱性スキャン システムによって JRE の潜在的なセキュリティ問題が特定された場合、これらの問題は無視しても問題ありません。コレクターの操作によって悪用される可能性のあるセキュリティ脆弱性は、リリース前に受け入れテスト プロセスの一環として対処されます。通知を無視したくない場合は、通常、コレクターを最新バージョンに更新することで、JRE で報告された脆弱性に対処できます。
さらに、コレクターを含む LogicMonitor アプリケーションは、ソフトウェア レベルの脆弱性がないか毎日スキャンされます。コレクター パッケージをファイル システムにインストールすると、ディレクトリ パスでソフトウェア構成分析 (SCA) の脆弱性が検出されることがあります。コレクターの最新バージョンをすでにインストールしている場合は、常に最新のセキュリティ修正プログラムが適用されているので安心です。セキュリティ修正プログラムには、将来のリリースで対処される新しい脆弱性が含まれる可能性があります。脆弱性情報自体は継続的に変化しており、LogicMonitor はこれを常に分析して対処しているため、これは継続的なサイクルです。
Collectorのリリースバージョンの詳細については、以下を参照してください。 コレクターバージョン.
コレクターのアップデート
LogicMonitor は通常、コレクター ソフトウェアを 3 ~ 4 週間ごとに更新します。最新の機能、セキュリティの改善、バグ修正をすべて適用するには、インストールされているコレクターを最新リリースに更新することをお勧めします。 リリースノート 最新バージョンを確認し、更新を購読してください。
また、年に一度、MGD (必須アップデート) がリリースされます。今後は、MGD が最低限必要なバージョンになります。お客様が都合に合わせてコレクターをアップグレードできるように、自動アップグレード予定日の少なくとも 30 日前に通知を送信します。自動アップグレード日には、MGD バージョンより低いコレクターのみをアップグレードします。
取るべき行動:
- コレクターソフトウェアの最新バージョンを実行していることを確認してください
コレクターバージョンの詳細については、 コレクターVバージョン.
追加の推奨ポータルセキュリティ設定
設定場所 | 属性 | おすすめ 設定 | ノート |
ポータル設定 | IP 許可リスト | 使用可能 | IPアドレス、IP範囲、IPマスク、またはホスト名に基づいてアクセスを制限します |
シングルサインオン | シングルサインオンを許可する | 使用可能 | 顧客がLogicMonitorポータルにアクセスしてユーザーIDを管理できるようにします。 |
シングルサインオン | シングルサインオンを制限する | 有効(「すべての役割とユーザーに2要素認証を要求する」が無効になっている場合) | 2FAが強制されていない場合、顧客はSSO EnforcedRecommendを有効にしない理由があるかもしれません。 |
ポータル設定 | すべての役割とユーザーにXNUMX要素認証を要求する | 有効(「シングルサインオンの制限」が無効の場合) | これは、「シングルサインオンの制限」が強制されていない場合にのみ利用可能です。 |
ポータル設定 | リモートセッションに2要素認証を要求する | 有効(「リモート セッションを有効にする」が有効かつ「すべてのロールとユーザーに 2 要素認証を要求する」が無効の場合) | これは、「リモートセッションを有効にする」が有効になっている場合にのみ適用されます。 |
ポータル設定 | ユーザーセッションタイムアウト | <= 8 時間 | 値を低くすると、ユーザーアカウントの不正使用の可能性を最小限に抑えることができます。 |
ポータル設定 | N 日間非アクティブになったユーザーを停止する | >0、<=90日 | 値が低いほど、未使用のアカウントが侵害される可能性が最小限に抑えられます。 |
ポータル設定 | N 日間使用しないと API トークンが無効になります | >0、<=365日 | 値を低くすると、古いAPIアカウントが侵害される可能性が最小限に抑えられます。 |
ポータル設定 | メールドメイン許可リスト | 使用可能 | 顧客が承認したドメインのみにメールの送信先を強制する |
ポータル設定 | テストスクリプトを有効にする | 身体障がい者 | この機能が必要な場合は、必要なときにのみ有効にし、その後無効にする必要があります。 |
ポータル設定 | リモートセッション | 身体障がい者 | この機能が必要な場合は、最小権限の原則に従って使用する必要があります。 リモート セッション機能は、アカウント全体のレベル、コレクター レベル、およびユーザー レベルで制御できることに注意してください。 詳細については、を参照してください。 リモートセッション. |
ポータル設定 | ダッシュボードのテキストウィジェットでスクリプトを許可する | 身体障がい者 | スクリプトは強力な機能なので、必要な場合にのみ有効にしてください。 |
ポータル設定 | 共有レポートを許可 | 身体障がい者 | レポートへのアクセスをログインしたユーザーのみに制限します |
ポータル設定 | コレクターデバッグを有効にする | 身体障がい者 | コレクターデバッグは強力な機能であり、必要な場合にのみ有効にする必要があります。 |
ポータル設定 | サインインしたままにするを有効にする | 身体障がい者 | 特定の時点でアクティブなログインセッションを最小限に抑えます |
ポータル設定 | サインイン状態を維持する日数の制限 | >0、<= 30日 | 「サインインしたままにする」が有効になっている場合にのみ適用されます |