Microsoft Sentinel で複数のワークスペースとテナントを準備する
デプロイの準備を行うには、複数のワークスペース アーキテクチャがご自分の環境に関連しているかどうかを判断する必要があります。 この記事では、Microsoft Sentinel を複数のワークスペースとテナントに拡張する方法について説明します。これにより、この機能が組織のニーズに合っているかどうかを判断できるようになります。 この記事は、「Microsoft Sentinel のデプロイ ガイド」の一部になります。
ワークスペースをまたいで拡張するように環境を設定する場合は、「ワークスペースおよびテナント全体での Microsoft Sentinel の拡張」と、Microsoft Sentinel で有効化された複数の Log Analytics ワークスペースをワークスペース マネージャーで一元管理する方法についての記事を参照してください。 組織が Microsoft Defender ポータルにオンボードすることを計画している場合は、Microsoft Defender でのマルチテナント管理を参照してください。
複数のワークスペースを使用する必要性
Microsoft Sentinel をオンボードするときは、最初に Log Analytics ワークスペースを選択します。 1 つのワークスペースを使用しても Microsoft Sentinel エクスペリエンスの利点を最大限に活用できますが、場合によっては、ワークスペースを拡張して、複数のワークスペースとテナントでデータのクエリと分析を行いたい場合があります。
次の表では、これらのシナリオの一部を示し、可能であれば、シナリオで 1 つのワークスペースを使用する方法を示します。
| 要件 | 説明 | ワークスペースの数を減らす方法 |
|---|---|---|
| 主権と規制のコンプライアンス | ワークスペースは、特定のリージョンに結び付けられます。 規制要件を満たすためにさまざまな Azure 地域 でデータを保持するには、データを別々のワークスペースに分割します。 Microsoft Sentinel では、データは主に同じ地域またはリージョンに格納されて処理されますが、Microsoft の機械学習を利用する検出ルールを使用する場合など、一部の例外があります。 このような場合、データが処理のため、地理的にワークスペースの外部にコピーされることがあります。 |
|
| データ所有権 | データ所有権の境界 (たとえば、子会社や関連会社など) は、個別のワークスペースを使用するとより適切に線引きできます。 | |
| 複数の Azure テナント | Microsoft Sentinel では、それ自体の Microsoft Entra テナントの境界内にある Microsoft と Azure の SaaS リソースからのデータ収集だけがサポートされています。 そのため、各 Microsoft Entra テナントには個別のワークスペースが必要です。 | |
| 詳細なデータ アクセスの制御 | 組織によっては、組織の内部または外部の異なるグループに、Microsoft Sentinel によって収集されたデータの一部へのアクセスを許可することが必要になる場合があります。 次に例を示します。
|
リソース Azure RBAC またはテーブル レベル Azure RBAC を使用します |
| 詳細な保有期間の設定 | 従来、複数のワークスペースは、異なるデータの種類に対して異なる保有期間を設定するための唯一の方法でした。 テーブル レベルの保有期間の設定の導入により、多くの場合、これは不要になりました。 | テーブル レベルの保有期間の設定を使用するか、またはデータの削除を自動化します |
| 課金を分割する | 個別のサブスクリプションにワークスペースを配置することにより、異なるパーティに課金できます。 | 使用状況レポートとクロス請求 |
| レガシ アーキテクチャ | 複数のワークスペースの使用は、現在ではもう有効ではない制限やベスト プラクティスを考慮した以前の設計から生じている可能性があります。 また、設計に関する恣意的な選択であり、変更することで Microsoft Sentinel にいっそう適切に対応できる可能性もあります。 たとえば、次のようになります。
|
ワークスペースを再設計します |
使用するテナントとワークスペースの数を決定する際は、ほとんどの Microsoft Sentinel 機能が単一のワークスペースまたは Microsoft Sentinel インスタンスを使用して動作し、Microsoft Sentinel によってワークスペース内に保存されているすべてのログが取り込まれることを考慮してください。
マネージド セキュリティ サービス プロバイダー (MSSP)
MSSP の場合、上記の要件のすべてではなくても多くが当てはまり、複数のワークスペースとテナントを使用することがベスト プラクティスになります。 具体的には、Microsoft Entra テナントごとに少なくとも 1 つのワークスペースを作成して、それ自体の Microsoft Entra テナント内でのみ動作する組み込みのサービス間データ コネクタをサポートすることをお勧めします。
診断設定に基づくコネクタは、リソースが存在するのと同じテナントに配置されていないワークスペースには接続できません。 これは、Azure Firewall、Azure Storage、Azure アクティビティ、Microsoft Entra ID などのコネクタに当てはまります。
パートナー データ コネクタは、多くの場合、API またはエージェント コレクションに基づいているため、特定の Microsoft Entra テナントにはアタッチされません。
Azure Lighthouse を使用すると、別々のテナント内の複数の Microsoft Sentinel インスタンスを管理するのに役立ちます。
Microsoft Sentinel の複数ワークスペース アーキテクチャ
上の要件で示されているように、1 つの SOC で複数の (場合によっては複数の Microsoft Entra テナントにまたがる) Microsoft Sentinel が有効になっている Log Analytics ワークスペースを一元的に監視および管理することが必要になる場合があります。
- MSSP Microsoft Sentinel サービス。
- それぞれに独自のローカル SOC がある複数の子会社に対応するグローバル SOC。
- 組織内の複数の Microsoft Entra テナントを監視する SOC。
これらの要件に対応するため、Microsoft Sentinel はSOC がカバーするすべてのものに対して単一のペインを提供することで、一元的な監視、構成、管理を可能にする複数ワークスペース機能を実現します。 この図は、このようなユース ケースのアーキテクチャの例を示しています。
このモデルでは、すべてのデータが 1 つのワークスペースにコピーされる完全な集中型モデルよりも大きなメリットが提供されます。
- グローバル SOC とローカル SOC、または顧客の MSSP に対する柔軟なロールの割り当て。
- データ所有権、データ プライバシー、法令遵守に関する課題の減少。
- 最小限のネットワーク待機時間と料金。
- 新しい子会社または顧客の簡単なオンボードとオフボード。
次のステップ
この記事では、Microsoft Sentinel を複数のワークスペースとテナントに拡張する方法について説明しました。