Microsoft Sentinel ワークスペース アーキテクチャのベスト プラクティス
Microsoft Sentinel ワークスペース デプロイを計画する際、Log Analytics ワークスペースのアーキテクチャも設計する必要があります。 ワークスペースのアーキテクチャに関する決定は、通常、ビジネスと技術面の要件により主導されます。 この記事では、組織にとって適切なワークスペースのアーキテクチャを決定するのに役立つ、以下を含む主な決定要因について説明します。
- シングル テナントと複数のテナントのどちらを使用するか
- データの収集と保存に関するコンプライアンス要件
- Microsoft Sentinel データへのアクセスを制御する方法
- さまざまなシナリオのコストへの影響
詳細については、一般的なシナリオについては「Microsoft Sentinel ワークスペース アーキテクチャを設計する」と「サンプル ワークスペースの設計」、また「Microsoft Sentinel のデプロイ前のアクティビティとデプロイの前提条件」を参照してください。
動画をご覧ください: 成功するための SecOps の設計: Microsoft Sentinel のデプロイに関するベスト プラクティス。
この記事は、「Microsoft Sentinel のデプロイ ガイド」の一部になります。
テナントに関する考慮事項
ワークスペースが少ないほど管理は簡単ですが、複数のテナントとワークスペースに対する固有のニーズがある場合があります。 たとえば、多くの組織のクラウド環境には、合併や買収の結果として、または ID 分離の要件のために、複数の Microsoft Entra テナントが含まれます。
使用するテナントとワークスペースの数を決定する際は、ほとんどの Microsoft Sentinel 機能が単一のワークスペースまたは Microsoft Sentinel インスタンスを使用して動作し、Microsoft Sentinel によってワークスペース内に保存されているすべてのログが取り込まれることを考慮してください。
コストは、Microsoft Sentinel アーキテクチャを決定する際の主な考慮事項の 1 つです。 詳細については、Microsoft Sentinel のコストと課金に関する記事をご覧ください。
複数のテナントの利用
マネージド セキュリティ サービス プロバイダー (MSSP) のように、複数のテナントがある場合は、Microsoft Entra テナントごとに少なくとも 1 つのワークスペースを作成して、それ自体の Microsoft Entra テナント内でのみ動作する組み込みのサービス間データ コネクタをサポートすることをお勧めします。
診断設定に基づくすべてのコネクタは、リソースが存在するのと同じテナントに配置されていないワークスペースには接続できません。 これは、Azure Firewall、Azure Storage、Azure アクティビティ、Microsoft Entra ID などのコネクタに当てはまります。
Azure Lighthouse を使用すると、別々のテナント内の複数の Microsoft Sentinel インスタンスを管理するのに役立ちます。
コンプライアンスの考慮事項
データを収集、格納、および処理した後は、コンプライアンスが重要な設計要件になり、Microsoft Sentinel のアーキテクチャに大きな影響を与える可能性があります。 多くの国や地域では、あらゆる状況下で、だれがどのデータにアクセスできるかを検証および証明できる能力を持つことが重要なデータ主権要件であり、多くのお客様にとって、Microsoft Sentinel のワークフローでリスクを評価し、分析情報を得ることが優先事項です。
Microsoft Sentinel では、データは主に同じ地域またはリージョンに格納されて処理されますが、Microsoft の機械学習を利用する検出ルールを使用する場合など、一部の例外があります。 このような場合、データが処理のため、地理的にワークスペースの外部にコピーされることがあります。
詳細については、以下を参照してください:
コンプライアンスの検証を開始するには、データ ソースと、データを送信する方法と場所を評価します。
Note
Log Analytics エージェントは FIPS 140 標準とともに、エージェントと Log Analytics サービスの間で転送中のデータ セキュリティを保証する TLS 1.2 をサポートします。
Microsoft Sentinel ワークスペースとは異なる地域またはリージョンにデータを送信する場合は、送信リソースが Azure に存在するかどうかに関係なく、同じ地域またはリージョンのワークスペースを使用することを検討してください。
リージョンに関する考慮事項
リージョンごとに別個の Microsoft Sentinel インスタンスを使用します。 Microsoft Sentinel は複数のリージョンで使用できますが、チーム、リージョン、またはサイトごとにデータを分ける要件がある場合や、規制や制御のために複数リージョン モデルが不可能または必要以上に複雑になる場合があります。 リージョンごとに個別のインスタンスとワークスペースを使用すると、リージョン間でデータを移動するための帯域幅およびエグレスのコストを回避するのに役立ちます。
複数のリージョンを使用する場合は、次のことを考慮してください。
エグレス コストは通常、仮想マシン上などでログを収集するために Log Analytics または Azure Monitor エージェントが必要な場合に適用されます。
インターネット エグレスも課金されますが、Log Analytics ワークスペースの外部にデータをエクスポートしない限り、影響を受けない可能性があります。 たとえば、Log Analytics データをオンプレミス サーバーにエクスポートすると、インターネット エグレス料金が発生する可能性があります。
帯域幅コストは、ソースと宛先のリージョンおよび収集方法によって異なります。 詳細については、次を参照してください。
分析ルール、カスタム クエリ、ブック、その他のリソースにテンプレートを使用して、デプロイをより効率的にします。 各リージョンに各リソースを手動でデプロイするのではなく、テンプレートをデプロイします。
診断設定に基づくコネクタでは、帯域幅内のコストは発生しません。 詳細については、Log Analytics を使用したデータ転送料金に関するページを参照してください。
たとえば、米国東部の Virtual Machines からログを収集して米国西部の Microsoft Sentinel ワークスペースに送信することにした場合、データ転送のイングレス コストが課金されます。 Log Analytics エージェントによって転送中のデータが圧縮されるため、帯域幅に対して課金されるサイズが、Microsoft Sentinel のログのサイズよりも小さくなる可能性があります。
世界中の複数のソースから Syslog と CEF のログを収集する場合、コンプライアンスが問題にならない限り、帯域幅のコストが発生しないよう、Microsoft Sentinel ワークスペースと同じリージョンに Syslog コレクターを設定することをお勧めします。
帯域幅のコストが Microsoft Sentinel ワークスペースを分離することの正当な理由になるかどうかは、リージョン間の転送が必要なデータの量によって決まります。 コストの見積もりには、Azure 料金計算ツールをご利用ください。
詳細については、「Azure でのデータ所在地」を参照してください。
アクセスに関する考慮事項
異なるチームが同じデータにアクセスする必要がある状況が計画されている場合があります。 たとえば、SOC チームはすべての Microsoft Sentinel データにアクセスできる必要がある一方、運用チームとアプリケーション チームは特定の部分にのみアクセスする必要があります。 また、独立したセキュリティ チームも、Microsoft Sentinel の機能に、ただし異なるデータのセットで、アクセスする必要があるかもしれません。
リソース コンテキスト RBAC およびテーブル レベルの RBAC を組み合わせて、ほとんどのユース ケースをサポートする広範囲のアクセス オプションをチームに提供します。
詳細については、「Microsoft Sentinel のアクセス許可」を参照してください。
リソース コンテキスト RBAC
次の図は、セキュリティ チームと運用チームがさまざまなデータ セットにアクセスする必要があるワークスペース アーキテクチャの簡略化されたバージョンを示しており、必要なアクセス許可を提供するためにリソース コンテキスト RBAC が使用されています。
この図では、アクセス許可の分離性を高めるために、Microsoft Sentinel ワークスペースが別のサブスクリプションに配置されています。
Note
もう 1 つのオプションは、Microsoft Sentinel をセキュリティ専用の別の管理グループの下に配置する方法です。これにより、最小限のアクセス許可の割り当てだけが確実に継承されます。 セキュリティ チーム内では、それぞれの機能に従って複数のグループにアクセス許可が割り当てられます。 これらのチームはワークスペース全体にアクセスできるので、完全な Microsoft Sentinel エクスペリエンスにアクセスでき、割り当てられている Microsoft Sentinel ロールによってのみ制限されます。 詳細については、「Microsoft Sentinel のアクセス許可」を参照してください。
セキュリティ サブスクリプションに加えて、アプリケーション チームがワークロードをホストするために別のサブスクリプションが使用されます。 アプリケーション チームには、それぞれのリソース グループへのアクセス権が付与され、そこでリソースを管理できます。 この個別のサブスクリプションとリソース コンテキスト RBAC を使用すると、これらのチームは、直接アクセス "できない" ワークスペースにログが格納されている場合でも、アクセスできるすべてのリソースによって生成されたログを表示できます。 アプリケーション チームは、Azure portal の [ログ] 領域を使用して特定のリソースのログを表示したり、Azure Monitor を介してアクセスできるすべてのログを同時に表示したりして、ログにアクセスできます。
Azure リソースには、リソース コンテキスト RBAC のための組み込みサポートがありますが、Azure 以外のリソースを操作する場合は追加の微調整が必要な場合があります。 詳細については、「リソースコンテキスト RBAC を明示的に構成する」を参照してください。
テーブルレベルの RBAC
テーブル レベルの RBAC を使用すると、特定のデータ型 (テーブル) を定義して、指定したユーザーのセットにのみアクセス可能にすることができます。
たとえば、上の図で説明されているアーキテクチャを持つ組織が、内部監査チームに Office 365 ログへのアクセス権を付与する必要がある場合を考えてみます。 この場合、テーブル レベルの RBAC を使用して、他のテーブルへのアクセス許可を付与せずに、OfficeActivity テーブル全体へのアクセス権を監査チームに付与することができます。
複数のワークスペースでのアクセスに関する考慮事項
組織内に異なるエンティティ、子会社、または地域があって、それぞれに Microsoft Sentinel へのアクセスを必要とする独自のセキュリティ チームが存在する場合は、エンティティまたは子会社ごとに個別のワークスペースを使用します。 1 つの Microsoft Entra テナント内に、または Azure Lighthouse を使って複数のテナントにまたがって、個別のワークスペースを実装します。
また、中央の SOC チームが、オプションの Microsoft Sentinel ワークスペースを追加して、分析ルールやブックなどの一元化された成果物を管理することもあります。
詳細については、「複数のワークスペースの操作を簡略化する」を参照してください。
ワークスペースを作成するための技術的なベスト プラクティス
Microsoft Sentinel に使用する Log Analytics ワークスペースを作成するときに、次のベスト プラクティス ガイダンスを使用します。
ワークスペースの名前を指定するとき、Microsoft Sentinel またはその他のインジケーターを名前に含め、他のワークスペース間で簡単に識別できるようにします。
Microsoft Sentinel と Microsoft Defender for Cloud の両方に同じワークスペースを使用し、Microsoft Defender for Cloud で収集されるログもすべて Microsoft Sentinel に取り込み、使用できるようにします。 Microsoft Defender for Cloud によって作成された既定のワークスペースは、Microsoft Sentinel の利用可能なワークスペースとして表示されません。
予想されるデータ インジェストが 1 日あたり約 1 TB またはそれを超える場合、専用のワークスペース クラスターを使用します。 専用クラスターを使用すると、Microsoft Sentinel データのリソースをセキュリティ保護でき、大規模なデータ セットのクエリ パフォーマンスを向上させることができます。 また、専用クラスターには、組織のキーの暗号化と制御を強化するオプションも用意されています。
Microsoft Sentinel に使用する Log Analytics ワークスペースにリソース ロックを適用しないでください。 ワークスペースに対するリソース ロックにより、多くの Microsoft Sentinel 操作が失敗する恐れがあります。
複数のワークスペースの操作を簡略化する
複数のワークスペースを操作する必要がある場合は、Microsoft Sentinel の各インスタンスのすべてのインシデントを 1 つの場所にまとめて一覧化して、インシデントの管理と調査を簡略化します。
クロスワークスペース ブックなど、Microsoft Sentinel の他のワークスペースに保持されているデータを参照するには、クロスワークスペース クエリを使用します。
クロスワークスペース クエリを使用する最適な状況は、貴重な情報が別のワークスペース、サブスクリプション、またはテナントに格納されていて、現在のアクションに価値を提供できる場合です。 たとえば、次のコードはクロスワークスペース クエリのサンプルを示しています。
union Update, workspace("contosoretail-it").Update, workspace("WORKSPACE ID").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification
詳細については、「ワークスペースおよびテナント全体での Microsoft Sentinel の拡張」を参照してください。
次のステップ
この記事では、組織にとって適切なワークスペース アーキテクチャを決定するのに役立つ主な決定要因について学習しました。