Skip to content

Commit e7683ca

Browse files
committed
sentinel bcdr
1 parent bf606f0 commit e7683ca

File tree

3 files changed

+136
-0
lines changed

3 files changed

+136
-0
lines changed

articles/sentinel/Sentinel BCDR.md

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
# BCDR in Azure Sentinel
2+
3+
# **Introduction**
4+
5+
This article describes reliability support in Microsoft Sentinel and covers both regional resiliency with availability zones and cross-region resiliency with disaster recovery. For a more detailed overview of reliability in Azure, see [Azure reliability](https://learn.microsoft.com/en-us/azure/well-architected/resiliency/).
6+
7+
## **Availability zone support**
8+
9+
Availability zones are physically separate groups of datacenters within each region. When one zone fails, services can fail over to one of the remaining zones.
10+
11+
For more information on availability zones in Azure, see [What are availability zones?](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview)
12+
13+
Microsoft Sentinel uses [availability zones](https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview#zonal-and-zone-redundant-services) in regions where they're available to provide high-availability protection for your applications and data from data center failures.
14+
15+
## **Cross-region disaster recovery and business continuity**
16+
17+
Disaster recovery (DR) is about recovering from high-impact events, such as natural disasters or failed deployments that result in downtime and data loss. Regardless of the cause, the best remedy for a disaster is a well-defined and tested DR plan and an application design that actively supports DR. Before you begin to think about creating your disaster recovery plan, see [Recommendations for designing a disaster recovery strategy](https://learn.microsoft.com/en-us/azure/well-architected/reliability/disaster-recovery).
18+
19+
When it comes to DR, Microsoft uses the [shared responsibility model](https://learn.microsoft.com/en-us/azure/reliability/concept-shared-responsibility). In a shared responsibility model, Microsoft ensures that the baseline infrastructure and platform services are available. At the same time, many Azure services don't automatically replicate data or fall back from a failed region to cross-replicate to another enabled region. For those services, you're responsible for setting up a disaster recovery plan that works for your workload. Most services that run on Azure platform as a service (PaaS) offerings provide features and guidance to support DR and you can use [service-specific features to support fast recovery](https://learn.microsoft.com/en-us/azure/reliability/reliability-guidance-overview) to help develop your DR plan.
20+
21+
In the unlikely event of a full region outage, you have the option of using one of two strategies:
22+
23+
> **Manual recovery**: Manually deploy to a new region, or wait for the region to recover, and then manually redeploy all environments and apps.
24+
>
25+
> **Resilient recovery**: First, deploy your container apps in advance to multiple regions. Next, use Azure Front Door or Azure Traffic Manager to handle incoming requests, pointing traffic to your primary region. Then, should an outage occur, you can redirect traffic away from the affected region. For more information, see [Cross-region replication in Azure](https://learn.microsoft.com/en-us/azure/reliability/cross-region-replication-azure).
26+
27+
**BCDR for** **Microsoft Sentinel**
28+
29+
Sentinel is leveraging Microsoft best practices for resiliency, Safe Deployment, and Business Continuity and Disaster Recovery (BCDR) with Azure Availability Zones (AZs).
30+
31+
To support BCDR in case of a regional outage, Sentinel employs a customer-enabled Business Continuity and Disaster Recovery (BCDR) approach, meaning customers are responsible for setting up disaster recovery. To ensure continuous business operations, customers should configure their Sentinel environment in an active-active or mirrored fashion across the two paired regions relevant to them, depending on the cloud environment.
32+
33+
This involves not only creating the workspaces in these regions but also ensuring that the same data sources, analytic rules, and all other settings and configurations are mirrored between the regions and maintained consistently throughout the continuous operations of these workspaces. This needs to be done manually by the customer and does not happen automatically.
34+
35+
This setup ensures that if an Azure regional outage occurs in one of these regions, the other paired region, which is geographically and physically separate from the impacted region, will remain unaffected. As a result, continuous business operations can proceed without any downtime or data loss.
36+
37+
**How to configure Azure Sentinel for BCDR**
38+
39+
To configure the Sentinel environment as active-active, customers need to create two identical Log Analytics and Sentinel workspaces in the appropriate regions. See here for more information: [Quickstart: Onboard to Microsoft Sentinel \| Microsoft Learn](https://learn.microsoft.com/en-us/azure/sentinel/quickstart-onboard)
40+
41+
For the public cloud, if the customer is outside of Europe, they should create one workspace in their local region and another in any of the supported regions in Europe. See here for more information about supported regions: [Geographical availability and data residency in Microsoft Sentinel \| Microsoft Learn](https://review.learn.microsoft.com/en-us/azure/sentinel/geographical-availability-data-residency?branch=main&branchFallbackFrom=pr-en-us-289729)
42+
43+
**Gov regions:**
44+
45+
For the government cloud (FFX), customers should create one workspace in Arizona and another in Virginia.
46+
47+
For the air gapped cloud (AGC), customers should create one workspace in USSEC East and one workspace in USSEC West (same thing for USNAT East and West).
48+
49+
**Unsupported geos:**
50+
\*Due to EUDB compliance limitations this capability is currently not supported for EU customers but will be available in the future.
51+
52+
\*Israel region and Mooncake cloud currently do not support that capability as well but will also be available in the future.

articles/sentinel/TOC.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -43,6 +43,8 @@
4343
href: feature-availability.md
4444
- name: Regional availability
4545
href: https://azure.microsoft.com/global-infrastructure/services/?products=azure-sentinel
46+
- name: Business continuity and disaster recovery
47+
href: business-continuity-disaster-recovery.md
4648
- name: Security baseline
4749
href: /security/benchmark/azure/baselines/sentinel-security-baseline?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json
4850
- name: Deploy
Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
---
2+
title: BCDR recommendations for working with Microsoft Sentinel
3+
description: Learn about Business Continuity and Disaster Recovery (BCDR) in Microsoft Sentinel, including availability zones and cross-region disaster recovery strategies.
4+
author: batamig
5+
ms.author: bagol
6+
ms.topic: concept-article
7+
ms.date: 02/04/2025
8+
appliesto:
9+
- Microsoft Sentinel in the Azure portal
10+
- Microsoft Sentinel in the Microsoft Defender portal
11+
ms.collection: usx-security
12+
13+
#customerIntent: As a security administrator, I want to understand and implement Business Continuity and Disaster Recovery (BCDR) strategies in Microsoft Sentinel in order to ensure high availability and resilience of my security operations.
14+
15+
---
16+
17+
# Business continuity and disaster recovery for Microsoft Sentinel
18+
19+
This article describes reliability support in Microsoft Sentinel and covers both regional resiliency with availability zones and cross-region resiliency with business continuity and disaster recovery (BCDR). While this article is mainly directed at Microsoft Sentinel customers working in the Azure portal, this guidance also covers data currently covered by Azure services after having onboarded to the [Microsoft Defender portal](/unified-secops-platform/overview-unified-security). <!--last sentence i added-->
20+
21+
For more information, see [Azure reliability](/azure/well-architected/resiliency/).
22+
23+
## Availability zone support
24+
25+
Availability zones are physically separate groups of data centers within each region. When one zone fails, services can fail over to one of the remaining zones.
26+
27+
Microsoft Sentinel uses availability zones in regions where they're available to provide high-availability protection for your applications and data from data center failures.
28+
29+
For more information, see [What are availability zones?](/azure/reliability/availability-zones-overview).
30+
31+
## Cross-region disaster recovery
32+
33+
Disaster recovery (DR) is about recovering from high-impact events, such as natural disasters or failed deployments that result in downtime and data loss. Regardless of the cause, the best remedy for a disaster is a well-defined and tested DR plan and an application design that actively supports DR. Before you begin to think about creating your disaster recovery plan, see [Recommendations for designing a disaster recovery strategy](/azure/well-architected/reliability/disaster-recovery).
34+
35+
When it comes to DR, Microsoft uses the [shared responsibility model](/azure/reliability/concept-shared-responsibility). In a shared responsibility model, Microsoft ensures that the baseline infrastructure and platform services are available. At the same time, many Azure services don't automatically replicate data or fall back from a failed region to cross-replicate to another enabled region. For those services, customers are responsible for setting up a disaster recovery plan that works for their environment. <!--changed from workload-->Most services that run on Azure platform as a service (PaaS) offerings provide features and guidance to support DR and you can [use service-specific features](/azure/reliability/reliability-guidance-overview) to support fast recovery to help develop your DR plan.
36+
37+
In the unlikely event of a full region outage, customers have the option of using one of two strategies:
38+
39+
- **Manual recovery:** Manually deploy to a new region, or wait for the region to recover, and then manually redeploy all environments and apps.
40+
- **Resilient recovery:** First, deploy your container apps in advance to multiple regions. Next, use Azure Front Door or Azure Traffic Manager to handle incoming requests, pointing traffic to your primary region. Then, should an outage occur, customers can redirect traffic away from the affected region. For more information, see [Cross-region replication in Azure](/azure/reliability/cross-region-replication-azure).
41+
42+
<!--removed business continuity from title - here we only talk about dr-->
43+
44+
## BCDR implementation for Microsoft Sentinel
45+
46+
Microsoft Sentinel uses Microsoft best practices for resiliency, safe deployment, and BCDR with Azure Availability Zones (AZs).
47+
48+
To support BCDR in case of a regional outage, Microsoft Sentinel employs a customer-enabled BCDR approach, which means that customers are responsible for setting up disaster recovery. To ensure continuous business operations, customers must configure their Microsoft Sentinel environment in an active-active or mirrored fashion across the two paired regions relevant to them, depending on the cloud environment.
49+
50+
Customer-enabled BCDR involves:
51+
52+
- Creating two identical Log Analytics workspaces enabled for Microsoft Sentinel in the appropriate regions. For more information, see [Quickstart: Onboard Microsoft Sentinel](quickstart-onboard.md).
53+
- Ensuring that the same data sources, analytic rules, and all other settings and configurations are mirrored between the regions, and maintained consistently throughout the continuous operations of these workspaces.
54+
55+
These activities must be done manually by the customer and do not happen automatically.
56+
57+
A customer-enabled BCDR setup ensures that if an Azure regional outage occurs in one of the customer's regions, the other paired region, which is geographically and physically separate from the impacted region, will remain unaffected. As a result, continuous business operations can proceed without any downtime or data loss.
58+
59+
## Regional and cloud support
60+
61+
The following table describes the recommended actions for setting up BCDR in different regions and cloud environments:
62+
63+
|Cloud type |Guidance |
64+
|---------|---------|
65+
|Public | We recommend that customers outside of Europe create one workspace in their local region and another in any of the supported European regions. |
66+
|Azure Government | We recommend that customers in US government clouds create one workspace in Arizona and another in Virginia. |
67+
|Air-gapped clouds | We recommend that customers in air-gapped US government clouds create one workspace in USSEC East and another workspace in USSEC West, or in USNAT East and USNAT West. |
68+
69+
For more information, see [Geographical availability and data residency in Microsoft Sentinel](geographical-availability-data-residency.md).
70+
71+
The following geographical regions are not currently supported for the customer-enabled BCDR approach described in this artice:
72+
73+
- EU customers, due to EUDB compliance limitations
74+
- Israel
75+
- Azure China 21Vianet
76+
77+
## Related content
78+
79+
For more information, see:
80+
81+
- [Geographical availability and data residency in Microsoft Sentinel](geographical-availability-data-residency.md)
82+
- [Microsoft Sentinel feature support for Azure commercial/other clouds](feature-availability.md)

0 commit comments

Comments
 (0)