Multi-Workspace Sentinel Architecture

Microsoft Sentinel is a cloud-native SIEM that typically runs on a single Log Analytics workspace. However, many organizations need multiple workspaces due to: - Data residency requirements: Certain countries require data to stay within their borders (e.g., EU, UK, Australia). - Regulatory compliance: Industries like finance or healthcare may require strict separation of data. - Organizational boundaries: Different business units or subsidiaries with independent security teams. - Cost management: Splitting data to control ingestion costs per workspace. - Operational autonomy: Local SOC teams managing their own incidents.

Multi-workspace Sentinel allows you to connect multiple workspaces under a single pane of glass using cross-workspace queries, analytics rules, and workbooks.

Each Sentinel workspace is independent with its own data, analytics rules, and incidents. The key enabling technologies are:

1. Cross-workspace queries via KQL union operator: You can write a query that spans multiple workspaces by specifying their identifiers. For example:

union workspace("workspace1").SecurityEvent, workspace("workspace2").SecurityEvent
   | where TimeGenerated > ago(1d)
   | summarize count() by Account

This allows a single query to pull data from up to 10 workspaces in a single query (default limit). The query is executed across all workspaces simultaneously, and results are merged.

To set up cross-workspace queries, you need the workspace IDs. You can find them in the Azure portal under each Log Analytics workspace > Properties. Alternatively, use Azure CLI:

az monitor log-analytics workspace list --query "[].{name:name, id:customerId, resourceId:id}"

To verify cross-workspace query permissions, run a test query in the central workspace:

union workspace("workspace1").Usage, workspace("workspace2").Usage
| take 10

If you get results, permissions are correct.

The SC-200 exam expects you to:

A multinational bank has offices in the US, EU, and Asia. Regulatory requirements mandate that all security data generated in the EU must remain within EU borders. The bank deploys Sentinel workspaces in West Europe (for EU data), East US (for US data), and Southeast Asia (for APAC data). Each local SOC team manages its own workspace for day-to-day operations. However, the global SOC needs to detect cross-region attacks, such as a user logging in from the US and then accessing a sensitive system in the EU minutes later. To achieve this, the central SOC workspace (East US) contains analytics rules that query the EU and APAC workspaces using cross-workspace queries. The central workspace also has a workbook that shows global threat trends. The bank uses Azure Policy to enforce that all workspaces have the same data connectors and retention settings. One challenge is data egress costs: querying the EU workspace from the US incurs egress charges. The bank mitigates this by scheduling queries during off-peak hours and limiting the frequency of cross-region queries. Another issue is latency: cross-region queries take longer, so the bank sets analytics rules to run every 10 minutes instead of 5 to avoid overlapping queries.

A managed security service provider (MSSP) monitors security for 50 customers. Each customer has its own Sentinel workspace in the customer's own Azure tenant. The MSSP uses Azure Lighthouse to manage all customer workspaces from a single portal. The MSSP deploys a central workspace in its own tenant that contains analytics rules for cross-customer correlation, such as detecting a known malicious IP that appears across multiple customers. However, the MSSP cannot query customer workspaces from its central workspace due to tenant boundaries unless Azure Lighthouse is configured. With Azure Lighthouse, the MSSP's users have Reader access to each customer workspace. The MSSP also creates cross-workspace workbooks that show all customers' alert trends. One common pitfall is that analytics rules in the central workspace cannot create incidents in customer workspaces; incidents are created in the MSSP's workspace. To address this, the MSSP uses automation rules to send alerts to each customer's workspace via webhook or Logic App.

A conglomerate has multiple independent subsidiaries (e.g., automotive, healthcare, finance). Each subsidiary has its own security team and wants to manage its own Sentinel workspace. However, the parent company wants a global view of threats. They deploy a central workspace for the parent company. Each subsidiary's workspace sends selected high-fidelity alerts to the central workspace using continuous export or automation rules. The central workspace does not query the subsidiary workspaces directly due to cost and complexity; instead, it relies on forwarded alerts. This architecture reduces cross-workspace query costs and respects subsidiary autonomy. The parent company uses a workbook that aggregates alerts from all subsidiaries. One challenge is that the central workspace cannot perform deep investigations on subsidiary data without querying the subsidiary workspace. The parent company addresses this by granting its SOC analysts Reader access to subsidiary workspaces for on-demand queries.