一つのSOC、多くのテナント:Azure LighthouseによるMicrosoft Sentinelの集中管理
組織は、買収やコンプライアンスなどのさまざまな要因により、複数の Microsoft Entra ID テナントを管理することがよくあります。このスプロールは、すべてのテナントログを一元化せずに統合されたセキュリティオペレーションセンター(SOC)を求めるセキュリティオペレーションチームにとって課題となります。Azure Lighthouse は、中央ハブテナントからスポークテナントへの委任されたリソース管理を可能にすることでソリューションを提供します。Microsoft Sentinel と組み合わせると、このセットアップにより、ログを元のスポークワークスペース内に保持しながら、テナント間の可視性が可能になります。このアーキテクチャは最小権限を優先し、ハブでの単一の Sentinel デプロイメントと、スポーク Log Analytics ワークスペースへの読み取り専用アクセスを利用します。前提条件には、テナントとワークスペースの識別子の収集、およびハブテナントでの特定のセキュリティグループの作成が含まれます。最小 RBAC には、スポークスコープで SOC-Readers グループに Log Analytics Reader を割り当てることが含まれます。Microsoft.ManagedServices などのリソースプロバイダーは、委任が機能するためにスポークサブスクリプションに登録する必要があります。ハブテナントには、Microsoft.SecurityInsights と Microsoft.OperationalInsights も登録する必要があります。このハブアンドスポークモデルは、データの居住性、テナントの分離を保証し、機密性の高いソースログの一元化を回避します。このセットアップは、単一の Sentinel インスタンスからスポークテナントへの管理されたアクセスを備えた中央 CSOC に焦点を当てています。委任されたアクセスは、RBAC の割り当てと Privileged Identity Management(PIM)を通じて制御され、時間制限のあるロールと多要素認証を強制します。スポークテナントのオンボーディングと検証クエリの反復可能な手順は、成功のために不可欠です。一般的な問題のトラブルシューティングには、委任の可視性、テナント間のクエリアクセス、およびハブ Sentinel でのインシデント生成の確認が含まれます。最終的に、このアプローチは、データの主権を損なうことなく、マルチテナント環境全体で統合された SOC 体験を可能にします。