Skip to content

Commit e9c245c

Browse files
committed
Draft for reworking Sentinel workspaces
1 parent 84a67a0 commit e9c245c

12 files changed

+91
-471
lines changed

articles/azure-monitor/logs/workspace-design.md

Lines changed: 9 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
title: Design a Log Analytics workspace architecture
33
description: The article describes the considerations and recommendations for customers preparing to deploy a workspace in Azure Monitor.
44
ms.topic: conceptual
5-
ms.date: 05/30/2024
5+
ms.date: 08/15/2024
66
---
77

88
# Design a Log Analytics workspace architecture
@@ -67,6 +67,7 @@ Each Log Analytics workspace resides in a [particular Azure region](https://azur
6767

6868
- **If you have requirements for keeping data in a particular geography:** Create a separate workspace for each region with such requirements.
6969
- **If you don't have requirements for keeping data in a particular geography:** Use a single workspace for all regions.
70+
- **If you are sending data to a geography or region that outside of your workspace's region, whether or not the sending resource resides in Azure**: Consider using a workspace in the same geography or region as your data.
7071

7172
Also consider potential [bandwidth charges](https://azure.microsoft.com/pricing/details/bandwidth/) that might apply when you're sending data to a workspace from a resource in another region. These charges are usually minor relative to data ingestion costs for most customers. These charges typically result from sending data to the workspace from a virtual machine. Monitoring data from other Azure resources by using [diagnostic settings](../essentials/diagnostic-settings.md) doesn't [incur egress charges](../cost-usage.md#data-transfer-charges).
7273

@@ -123,18 +124,24 @@ For example, you might grant access to only specific tables collected by Microso
123124
- **If you don't require granular access control by table:** Grant the operations and security team access to their resources and allow resource owners to use resource-context RBAC for their resources.
124125
- **If you require granular access control by table:** Grant or deny access to specific tables by using table-level RBAC.
125126

127+
For more information, see [Manage access to Microsoft Sentinel data by resource](../../sentinel/resource-context-rbac.md).
128+
126129
### Resilience
127130

128131
To ensure that critical data in your workspace is available in the event of a region failure, you can ingest some or all of your data into multiple workspaces in different regions.
129132

130133
This option requires managing integration with other services and products separately for each workspace. Even though the data will be available in the alternate workspace in case of failure, resources that rely on the data, such as alerts and workbooks, won't know to switch over to the alternate workspace. Consider storing ARM templates for critical resources with configuration for the alternate workspace in Azure DevOps, or as disabled policies that can quickly be enabled in a failover scenario.
131134

132135
## Work with multiple workspaces
133-
Many designs include multiple workspaces, so Azure Monitor and Microsoft Sentinel include features to assist you in analyzing this data across workspaces. For more information, see:
136+
Many designs include multiple workspaces. For example, a central security operations team might use its own Microsoft Sentinel workspaces to manage centralized artifacts like analytics rules or workbooks.
137+
138+
Both Azure Monitor and Microsoft Sentinel include features to assist you in analyzing this data across workspaces. For more information, see:
134139

135140
- [Create a log query across multiple workspaces and apps in Azure Monitor](cross-workspace-query.md)
136141
- [Extend Microsoft Sentinel across workspaces and tenants](../../sentinel/extend-sentinel-across-workspaces-tenants.md)
137142

143+
When naming each workspace, we recommend including a meaningful indicator in the name so that you can easily identity the purpose of each workspace.
144+
138145
## Multiple tenant strategies
139146
Environments with multiple Azure tenants, including Microsoft service providers (MSPs), independent software vendors (ISVs), and large enterprises, often require a strategy where a central administration team has access to administer workspaces located in other tenants. Each of the tenants might represent separate customers or different business units.
140147

articles/sentinel/TOC.yml

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -19,10 +19,8 @@
1919
href: prerequisites.md
2020
- name: Workspace architecture
2121
items:
22-
- name: Review best practices
23-
href: best-practices-workspace-architecture.md
2422
- name: Design workspace architecture
25-
href: design-your-workspace-architecture.md
23+
href: /azure/azure-monitor/logs/workspace-design?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json
2624
- name: Review sample workspace designs
2725
href: sample-workspace-designs.md
2826
- name: Prepare for multiple workspaces

articles/sentinel/best-practices-workspace-architecture.md

Lines changed: 0 additions & 161 deletions
This file was deleted.

0 commit comments

Comments
 (0)