Azure security baseline for Azure Monitor

This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Azure Monitor. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to Azure Monitor.

You can monitor this security baseline and its recommendations using Microsoft Defender for Cloud. Azure Policy definitions will be listed in the Regulatory Compliance section of the Microsoft Defender for Cloud dashboard.

When a section has relevant Azure Policy Definitions, they are listed in this baseline to help you measure compliance to the Azure Security Benchmark controls and recommendations. Some recommendations may require a paid Microsoft Defender plan to enable certain security scenarios.

Note

Controls not applicable to Azure Monitor, and those for which the global guidance is recommended verbatim, have been excluded. To see how Azure Monitor completely maps to the Azure Security Benchmark, see the full Azure Monitor security baseline mapping file.

Network Security

For more information, see the Azure Security Benchmark: Network Security.

NS-1: Implement security for internal traffic

Guidance: When you deploy Microsoft Azure Monitor resources, create or use an existing virtual network. Make sure all Azure virtual networks follow an enterprise segmentation principle that aligns with the business risks. Do you have any system that might incur higher risk for the organization? Then isolate that system within its own virtual network, and secure it sufficiently with a network security group (NSG) or Azure Firewall.

Using Microsoft Defender for Cloud adaptive network hardening, recommend NSG configurations that limit ports and source IPs. Base the configurations on the external network traffic rules.

Configure Monitor to use Transport Layer Security (TLS) 1.2. You can set up this configuration on Monitor's resource deployments through Azure Resource Manager templates (ARM templates). Enforce the configuration through Azure Policy. But if you disable legacy protocols, it may affect the backward compatibility of your service or application.

To communicate with your Log Analytics workspaces and Application Insights components, outgoing traffic from your network requires access to a list of endpoints. Typically, the communication goes over port 443 or port 80. Some Application Insights features, such as availability tests, require inbound traffic into your network.

Responsibility: Customer

NS-2: Connect private networks together

Guidance: Using Azure ExpressRoute or Azure virtual private network (VPN), create private connections between Azure datacenters and on-premises infrastructure in a colocation environment. ExpressRoute connections don't go over the public internet. Compared with typical internet connections, ExpressRoute connections offer:

  • More reliability
  • Faster speeds
  • Lower latencies

For point-to-site VPN and site-to-site VPN, you can connect on-premises devices or networks to a virtual network. Use any combination of these VPN options and ExpressRoute.

To connect two or more virtual networks in Azure together, use virtual network peering. Network traffic that occurs between peered virtual networks is private. This traffic is kept on the Azure backbone network.

Once you have your networks peered, we recommend you use a Private Link to communicate with your Monitor resources privately. See "Design your Private Link setup" to plan how it applied to your network topology.

Responsibility: Customer

NS-3: Establish private network access to Azure services

Guidance: Enable Private Link to allow access to Azure software as a service (SaaS) services (such as Monitor) and Azure-hosted customer/partner services over a private endpoint in your virtual network. Traffic between your virtual network and the service traverses over the Microsoft backbone network, which eliminates exposure from the public internet.

Here are some tips for managing access:

  • To allow traffic to reach Monitor, use the "AzureMonitor" service tags to allow inbound and outbound traffic through NSGs.
  • To allow test traffic from availability monitoring to reach Monitor, use the "ApplicationInsightsAvailability" service tag to all inbound traffic through NSGs.
  • To allow alert notifications to reach customer endpoints, use the "ActionGroup" service tag to allow inbound traffic through NSGs.

Using virtual network rules, you can set up Monitor to receive communications only from selected subnets inside a virtual network.

Do you have computers that can't connect directly to the internet? Then use Log Analytics gateway, which can send data to a Log Analytics workspace in Monitor. This practice means you don't need to connect those computers to the internet.

Responsibility: Customer

NS-6: Simplify network security rules

Guidance: Monitor can monitor resources deployed to your network. So your network must allow outgoing traffic to Monitor endpoints (such as log ingestion). We recommend using a Private Link between your network and your Monitor resources. If you don't want to use a Private Link, you can still limit your network's outgoing traffic to Monitor endpoints. Just use Azure virtual network service tags on NSGs or Azure Firewall.

When you create security rules, use service tags in place of specific IP addresses. By specifying the service tag name in the appropriate rule's source or destination field, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes that the service tag encompasses. It automatically updates the service tag as addresses change.

Responsibility: Customer

NS-7: Secure Domain Name Service (DNS)

Guidance: Follow the best practices for Domain Name System (DNS) security to mitigate against common attacks, such as:

  • Dangling DNS
  • DNS amplifications attacks
  • DNS poisoning and spoofing

Monitor typically doesn't require you to configure your DNS or manage it in a specific way. But if you use Monitor Private Links, you must update your DNS. Then DNS zones map the Monitor endpoints to your private IP addresses.

When Azure DNS is used as your authoritative DNS service, protect DNS zones and records from accidental or malicious modification. Use Azure role-based access control (Azure RBAC) and resource locks to apply the protection.

Responsibility: Customer

Identity Management

For more information, see the Azure Security Benchmark: Identity Management.

IM-1: Standardize Azure Active Directory as the central identity and authentication system

Guidance: Monitor uses Azure Active Directory (Azure AD) as the default identity and access management service. Standardize Azure AD to govern your organization’s identity and access management in:

  • Microsoft Cloud resources, such as:
    • Azure portal
    • Azure Storage
    • Azure Virtual Machine (Linux and Windows)
    • Azure Key Vault
    • Platform as a service (PaaS)
    • Software as a service (SaaS) applications
  • Your organization's resources, such as applications on Azure or your corporate network resources.

Make securing Azure AD a high priority in your organization’s cloud security practice. Azure AD provides an identity secure score. This score helps you assess your identity security posture against Microsoft’s best practice recommendations. Using this score, gauge how closely your configuration matches best practice recommendations. Then make improvements in your security posture.

Note: Azure AD supports external identity. Users without a Microsoft account can sign in to their applications and resources with their external identity.

Responsibility: Customer

IM-2: Manage application identities securely and automatically

Guidance: Monitor supports managed identities for its Azure resources. Instead of creating service principals to access other resources, use managed identities with Monitor. Monitor can natively authenticate to the Azure services and resources that support Azure AD authentication. The authentication occurs through a predefined access grant rule. It doesn't use credentials that are hardcoded in source code or configuration files.

Responsibility: Customer

IM-3: Use Azure AD single sign-on (SSO) for application access

Guidance: Monitor uses Azure AD to provide identity and access management to:

  • Azure resources
  • Cloud applications
  • On-premises applications

Identity and access management includes enterprise identities, such as employees. It also includes external identities, such as:

  • Partners
  • Vendors
  • Suppliers

This arrangement lets single sign-on (SSO) manage and secure access to your organization’s data and resources. SSO works on-premises and in the cloud. For seamless, secure access, plus greater visibility and control, connect to Azure AD all your:

  • Users
  • Applications
  • Devices

For more information, read the following article:

Responsibility: Customer

IM-7: Eliminate unintended credential exposure

Guidance: Deploy Monitor with ARM templates that may have secrets that are defined in code. To identify credentials within your Monitor infrastructure as code templates, implement Credential Scanner. Credential Scanner also encourages moving discovered credentials to more secure locations, such as Key Vault.

For GitHub, you can use the native secret scanning feature. This feature identifies credentials or other forms of secrets within the code.

Responsibility: Customer

Privileged Access

For more information, see the Azure Security Benchmark: Privileged Access.

PA-1: Protect and limit highly privileged users

Guidance: The most critical built-in roles for Azure AD are the Global Administrator and the Privileged Role Administrator. Users who are assigned to these two roles can delegate administrator roles:

  • Global Administrator or Company Administrator. Users with this role have access to all administrative features in Azure AD, and services that use Azure AD identities.

  • Privileged Role Administrator. Users with this role can manage role assignments in Azure AD, and within Azure AD Privileged Identity Management (PIM). This role also allows management of all aspects of PIM and administrative units.

Note: You might have other critical roles that need to be governed if you use custom roles with certain privileged permissions assigned. You might also want to apply similar controls to the administrator account of critical business assets.

Limit the number of highly privileged accounts or roles. Protect these accounts at an elevated level. Users who have this privilege can directly or indirectly read and modify every resource in your Azure environment.

Enable just-in-time (JIT) privileged access to Azure resources and Azure AD using Azure AD PIM. JIT grants temporary permissions to do privileged tasks only when users need it. PIM can also generate security alerts when there's suspicious or unsafe activity in your Azure AD organization.

Responsibility: Customer

PA-3: Review and reconcile user access regularly

Guidance: To ensure the user accounts and their access are valid, Monitor regularly uses Azure AD accounts to:

  • Manage its resources.
  • Review user accounts.
  • Access assignments.

Use Azure AD access reviews to review:

  • Group memberships
  • Access to enterprise applications
  • Role assignments

Azure AD reporting can provide logs to help discover stale accounts. To assist the review process, also use Azure AD PIM to create access review report workflow.

You can also configure Azure PIM to alert when an excessive number of administrator accounts are created. Or configure to identify administrator accounts that are stale or improperly configured.

Note: Some Azure services support local users and roles that aren't managed through Azure AD. Manage these users separately.

Responsibility: Customer

PA-6: Use privileged access workstations

Guidance: Secured, isolated workstations are critically important for the security of sensitive roles, such as:

  • Administrators
  • Developers
  • Critical service operators

Use highly secured user workstations or Azure Bastion for administrative tasks. To deploy a secure and managed user workstation, use one or more of:

  • Azure AD
  • Microsoft Defender Advanced Threat Protection (ATP)
  • Microsoft Intune

You can manage the secured workstations centrally to enforce secured configuration, including:

  • Strong authentication
  • Software and hardware baselines
  • Restricted logical and network access

For more information, read the following articles:

Responsibility: Customer

Data Protection

For more information, see the Azure Security Benchmark: Data Protection.

DP-2: Protect sensitive data

Guidance: Protect sensitive data by restricting access, using:

  • Azure RBAC
  • Network-based access controls
  • Azure Monitor table-based RBAC controls.

To ensure consistent access control, align all types of access control to your enterprise segmentation strategy. Also inform the enterprise segmentation strategy with the location of sensitive or business-critical data and systems.

For the underlying Microsoft-managed platform, Microsoft treats all customer content as sensitive. It guards against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft implements some default data protection controls and capabilities.

Responsibility: Customer

DP-3: Monitor for unauthorized transfer of sensitive data

Guidance: Not applicable; for the underlying Microsoft-managed platform, Microsoft treats all customer content as sensitive. It goes to great lengths to guard against customer data loss and exposure. To make sure customer data within Azure remains secure, Microsoft implements and maintains a suite of robust data protection controls and capabilities.

Responsibility: Shared

DP-4: Encrypt sensitive information in transit

Guidance: To complement access controls, protect data in transit against "out of band" attacks (such as traffic capture) using encryption. Then attackers can't easily read or modify the data.

Monitor supports data encryption in transit with TLS v1.2 or greater. By default, Azure provides encryption for data in transit between Azure data centers.

While this feature is optional for traffic on private networks, it's critical for traffic on external and public networks. For HTTP traffic, make sure clients that connect to your Azure resources can negotiate TLS v1.2 or greater. For remote management, instead of an unencrypted protocol, use one of:

  • Secure Shell (SSH) for Linux
  • Remote Desktop Protocol (RDP) and TLS for Windows

Disable weak ciphers, plus obsolete versions and protocols of:

  • Secure Sockets Layer (SSL)

  • TLS

  • SSH

For more information, read the following articles:

Responsibility: Customer

DP-5: Encrypt sensitive data at rest

Guidance: To complement access controls, Monitor encrypts data at rest. This behavior protects against "out of band" attacks (such as accessing underlying storage) using encryption. It helps make sure attackers can't easily read or modify the data.

Azure provides encryption for data at rest by default. For highly sensitive data, you may implement more encryption at rest on all Azure resources where available. Azure manages your encryption keys by default. It also provides options to manage your own keys (customer-managed keys) for certain Azure services.

Responsibility: Customer

Asset Management

For more information, see the Azure Security Benchmark: Asset Management.

AM-1: Ensure security team has visibility into risks for assets

Guidance: Grant security teams Security Reader permissions in your Azure tenant and subscriptions. Then the teams can monitor for security risks using Microsoft Defender for Cloud.

Depending on how you structure the security team responsibilities, a central security team or a local team could be responsible to monitoring for security risks. But always aggregate security insights and risks centrally within an organization.

Apply the Security Reader permissions broadly to an entire tenant (root management group). Or scope the permissions to management groups or specific subscriptions.

Note: Extra permissions might be necessary to get visibility into workloads and services.

Responsibility: Customer

AM-2: Ensure security team has access to asset inventory and metadata

Guidance: Grant your security teams access to a continuously updated inventory of assets on Azure, such as Monitor. Security teams often need this inventory to evaluate their organization's potential exposure to emerging risks. The inventory is also an input to continuous security improvements. Create an Azure AD group to contain your organization's authorized security team. Then assign read access to the group for all Monitor resources. To simplify this process, you can use a single high-level role assignment within your subscription.

To logically organize into a taxonomy, apply tags to your Azure:

  • Resources
  • Resource groups
  • Subscriptions

Each tag consists of a name and a value pair. For example, you can apply the name "Environment" and the value "Production" to all the resources in production.

Monitor doesn't let you run an application or install software on its resources.

Responsibility: Customer

AM-3: Use only approved Azure services

Guidance: Using Azure Policy, audit and restrict which services users can provision in your environment. Use Resource Graph to query for and discover resources within their subscriptions. Also use Monitor to create rules that trigger alerts when an unapproved service is detected.

Responsibility: Customer

Logging and Threat Detection

For more information, see the Azure Security Benchmark: Logging and Threat Detection.

LT-1: Enable threat detection for Azure resources

Guidance: Monitor doesn't provide native capabilities to monitor security threats that are related to its resources.

Forward any logs from Monitor to your SIEM, which you can use to set up custom threat detections. Make sure you monitor different types of Azure assets for potential threats and anomalies. Focus on getting high-quality alerts to reduce false positives for analysts to sort through. You can source alerts from:

  • Log data
  • Agents
  • Other data

Alerts against these logs would trigger a query of sensitive logs, log purge, or deletion.

Responsibility: Customer

LT-2: Enable threat detection for Azure identity and access management

Guidance: Azure Active Directory (Azure AD) provides the following user logs:

  • Sign-ins. The sign-ins report provides information about the usage of managed applications and user sign-in activities.

  • Audit logs. An audit log provides traceability for all changes that various features make within Azure AD. Examples include changes that are made to any resources within Azure AD, such as adding or removing:

    • Users
    • Apps
    • Groups
    • Roles
    • Policies
  • Risky sign-ins. A risky sign-in indicates a sign-in attempt that might have been made by someone who isn't the user account's legitimate owner.

  • Users flagged for risk. A risky user indicates a user account that might have been compromised.

You can view these logs in Azure AD reporting. For more sophisticated monitoring and analytics use cases, you can integrate the logs with:

  • Monitor
  • Microsoft Sentinel
  • Other SIEM/monitoring tools

Microsoft Defender for Cloud can also trigger alerts on certain suspicious activities. These activities include an excessive number of failed authentication attempts or deprecated accounts in the subscription. Besides the basic security hygiene monitoring, Microsoft Defender for Cloud's Threat Protection module can also collect more in-depth security alerts from:

  • Individual Azure compute resources (virtual machines, containers, and app service).
  • Data resources (SQL DB and storage).
  • Azure service layers.

This capability lets you see account anomalies inside individual resources.

Responsibility: Customer

LT-3: Enable logging for Azure network activities

Guidance: For security analysis, enable and collect:

  • NSG resource logs
  • NSG flow logs
  • Azure Firewall logs
  • Web Application Firewall (WAF) logs

Apply the security analysis to support:

  • Incident investigations
  • Threat hunting
  • Security alert generation

You can send the flow logs to an Azure Monitor Log Analytics workspace. Then use Traffic Analytics to provide insights.

Monitor doesn't produce or process DNS query logs that need to be enabled.

Responsibility: Customer

LT-4: Enable logging for Azure resources

Guidance: Activity logs contain all write operations (PUT, POST, and DELETE) for your Monitor resources. These logs are automatically available, but they don't contain read operations (GET). Use activity logs to find an error when troubleshooting. Or use the logs to monitor how a user in your organization modified a resource.

Monitor action groups currently don't produce Azure resource logs.

Responsibility: Customer

Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require an Microsoft Defender plan for the related services.

Azure Policy built-in definitions - microsoft.insights:

Name
(Azure portal)
Description Effect(s) Version
(GitHub)
Resource logs in Azure Data Lake Store should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0
Resource logs in Azure Stream Analytics should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0
Resource logs in Batch accounts should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0
Resource logs in Data Lake Analytics should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0
Resource logs in Event Hub should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0
Resource logs in IoT Hub should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 3.0.1
Resource logs in Key Vault should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0
Resource logs in Logic Apps should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0
Resource logs in Search services should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0
Resource logs in Service Bus should be enabled Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised AuditIfNotExists, Disabled 5.0.0

LT-5: Centralize security log management and analysis

Guidance: Centralize logging storage and analysis to enable correlation. For each log source, assign:

  • Data owner
  • Access guidance
  • Storage location
  • What tools are used to process and access the data
  • Data retention requirements

Integrate Azure activity logs into your central logging. Ingest logs through Monitor to aggregate security data that's generated by:

  • Endpoint devices
  • Network resources
  • Other security systems

In Monitor, use Log Analytics workspaces to query and do analytics. Use storage accounts for long-term and archival storage.

Also enable and onboard data to Microsoft Sentinel or a third-party SIEM.

Many organizations choose to use Microsoft Sentinel for “hot” data that's used frequently. Those organizations then pick Storage for “cold” data that's used less frequently.

For applications that may run on Monitor, forward all security-related logs to your SIEM for centralized management.

Responsibility: Customer

LT-6: Configure log storage retention

Guidance: Do you have any storage accounts or Log Analytics workspaces that are used for storing Monitor logs? Then set the log retention period to your organization's compliance regulations.

In Monitor, you can set your Log Analytics workspace retention period to your organization's compliance regulations. For long-term and archival storage, use one of these components:

  • Azure storage account
  • Azure Data Lake Storage account
  • Log Analytics workspace

For more information, read the following articles:

Responsibility: Customer

LT-7: Use approved time synchronization sources

Guidance: Monitor doesn't support configuring your own time synchronization sources. The Monitor services rely on Microsoft time synchronization sources, which aren't exposed to customers for configuration.

Responsibility: Microsoft

Posture and Vulnerability Management

For more information, see the Azure Security Benchmark: Posture and Vulnerability Management.

PV-1: Establish secure configurations for Azure services

Guidance: Do you need to audit and enforce configurations of your Azure resources? Monitor supports the following service-specific policies that are available in Microsoft Defender for Cloud. You can configure these policies in Microsoft Defender for Cloud or Azure Policy initiatives.

  • A Log Analytics agent should be installed on your Azure Cloud Services (extended support) role instances. Auto provisioning of the Log Analytics agent should be enabled on your subscription.
  • Microsoft Defender for Clouds auto provisioning of the Log Analytics agent on your subscriptions should be enabled with the default workspace.
  • Microsoft Defender for Cloud's auto provisioning of the Log Analytics agent on your subscriptions should be enabled with a custom workspace.
  • Log Analytics agent should be installed on your virtual machine scale sets for Microsoft Defender for Cloud monitoring.
  • Log Analytics agent should be installed on your virtual machine for Microsoft Defender for Cloud monitoring.
  • Log Analytics agent health issues should be resolved on your machines.
  • Export to a Log Analytics workspace should be deployed for Microsoft Defender for Cloud data.

Monitor provides more policies for secure data through ingestion and storage:

  • Application Insights components with Private Link enabled should use Bring Your Own Storage (BYOS) accounts for the profiler and the debugger.
  • Workbooks should be saved to storage accounts that you control.
  • Saved queries in Monitor should be saved in a customer storage account for log encryption.
  • The storage account that holds the container with activity logs must be encrypted with bring your own key (BYOK) protection.
  • Azure Monitor Logs clusters should be encrypted with a customer-managed key.
  • Azure Monitor Logs clusters should be created with infrastructure encryption enabled (double encryption).

Use Azure Blueprints to automate the deployment and configuration of services and application environments in a single blueprint definition. These services and environments include:

  • ARM templates
  • Azure RBAC controls
  • Policies

For more information, read the following articles:

Responsibility: Customer

PV-2: Sustain secure configurations for Azure services

Guidance: Use Microsoft Defender for Cloud to monitor your configuration baseline. Use the Deny and DeployIfNotExists policy definitions in Azure Policy to enforce secure configuration across Azure compute resources, including:

  • Virtual machines
  • Containers
  • Others

For more information, read the following articles:

Responsibility: Customer

PV-4: Sustain secure configurations for compute resources

Guidance: Not applicable; this guideline is intended for compute resources.

Responsibility: Customer

PV-6: Make software vulnerability assessments

Guidance: Microsoft does vulnerability management on the underlying systems that support Monitor.

Responsibility: Microsoft

PV-7: Rapidly and automatically remediate software vulnerabilities

Guidance: Customers may enable Azure Monitor in Azure and non-Azure virtual machines by installing an agent. To remediate any possible vulnerabilities in the agent that runs in your operating system, upgrade your agent regularly.

Microsoft recommends you always select auto update in your extension deployments. Hotfix updates that carry security or key bug fixes can't be opted out.

Configure the Log Analytics agent for Windows and Linux in Azure virtual machines to upgrade by default. Then any updates that include security or key bug fixes are rapidly deployed.

Responsibility: Customer

PV-8: Conduct regular attack simulation

Guidance: As necessary, conduct penetration testing or red team activities on your Azure resources. Ensure the remediation of all critical security findings. To ensure your penetration tests don't violate Microsoft policies, follow the Microsoft Cloud Penetration Testing Rules of Engagement. Use Microsoft's strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed:

  • Cloud infrastructure
  • Services
  • Applications

For more information, read the following articles:

Responsibility: Customer

Backup and Recovery

For more information, see the Azure Security Benchmark: Backup and Recovery.

BR-1: Ensure regular automated backups

Guidance: Use Azure Resource Manager to export Monitor and related resources in a JavaScript Object Notation (JSON) template. You can use this ARM template to back up Monitor and related configurations. Use Azure Automation to run the backup scripts automatically.

Monitor has internal backups for all customer data. No action is necessary for customers, except for log data that's stored in the Log Analytics workspaces. You may use the export feature to back up this data, which includes Application Insights content that stores data in a Log Analytics workspace.

Responsibility: Customer

BR-3: Validate all backups including customer-managed keys

Guidance: Make sure you can periodically restore Azure Resource Manager-backed template files. Test the restoration of backed-up customer-managed keys.

Responsibility: Customer

BR-4: Mitigate risk of lost keys

Guidance: Have measures in place to prevent and recover from the loss of keys. To protect keys against accidental or malicious deletion, enable soft delete and purge protection in Key Vault.

Responsibility: Customer

Next steps