One SOC, Many Tenants: Central... Note

One SOC, Many Tenants: Centralizing Microsoft Sentinel with Azure Lighthouse

Organizations often manage multiple Microsoft Entra ID tenants due to various factors like acquisitions and compliance. This sprawl presents a challenge for security operations teams seeking a unified Security Operations Center (SOC) without centralizing all tenant logs. Azure Lighthouse offers a solution by enabling delegated resource management from a central hub tenant to spoke tenants. When combined with Microsoft Sentinel, this setup allows for cross-tenant visibility while keeping logs within their original spoke workspaces. The architecture prioritizes least privilege, utilizing a single Sentinel deployment in the hub and read-only access to spoke Log Analytics workspaces. Prerequisites include gathering tenant and workspace identifiers and creating specific security groups in the hub tenant. Minimum RBAC involves assigning Log Analytics Reader to the SOC-Readers group at the spoke scope. Resource providers like Microsoft.ManagedServices must be registered in spoke subscriptions for delegation to function. The hub tenant also needs Microsoft.SecurityInsights and Microsoft.OperationalInsights registered. This hub-and-spoke model ensures data residency, tenant isolation, and avoids centralizing sensitive source logs. The setup focuses on a centralized CSOC with governed access to spoke tenants from a single Sentinel instance. Delegated access is controlled through RBAC assignments and Privileged Identity Management (PIM), enforcing time-bound roles and multi-factor authentication. Repeatable procedures for spoke tenant onboarding and validation queries are crucial for success. Troubleshooting common issues involves checking delegation visibility, cross-tenant query access, and incident generation in hub Sentinel. Ultimately, this approach enables a cohesive SOC experience across a multi-tenant environment without compromising data sovereignty.