Povratne informacije

Azure security baseline for Azure Storage

  • Članak
  • 32 min. za čitanje

This security baseline applies guidance from the Azure Security Benchmark version 1.0 to Azure Storage. 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 Storage.

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 Storage, or for which the responsibility is Microsoft's, have been excluded. To see how Azure Storage completely maps to the Azure Security Benchmark, see the full Azure Storage security baseline mapping file.

Network Security

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

1.1: Protect Azure resources within virtual networks

Guidance: Configure your storage account's firewall by restricting access to clients from specific public IP address ranges, select virtual networks, or specific Azure resources. You can also configure Private Endpoints so traffic to the storage service from your enterprise travels exclusively over private networks.

Note: Classic storage accounts do not support firewalls and virtual networks.

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 a Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.Storage:

Name
(Azure portal)		 Description Effect(s) Version
(GitHub)
Storage accounts should restrict network access Network access to storage accounts should be restricted. Configure network rules so only applications from allowed networks can access the storage account. To allow connections from specific internet or on-premises clients, access can be granted to traffic from specific Azure virtual networks or to public internet IP address ranges Audit, Deny, Disabled 1.1.1
Storage Accounts should use a virtual network service endpoint This policy audits any Storage Account not configured to use a virtual network service endpoint. Audit, Disabled 1.0.0

1.2: Monitor and log the configuration and traffic of virtual networks, subnets, and network interfaces

Guidance: Azure Storage provides a layered security model. You can limit access to your storage account to requests originating from specified IP addresses, IP ranges or from a list of subnets in an Azure Virtual Network. You can use Microsoft Defender for Cloud and follow network protection recommendations to help secure your network resources in Azure. Also, enable network security group flow logs for virtual networks or subnet configured for the Storage accounts via Storage account firewall and send logs into a Storage Account for traffic audit.

Note that if you have Private Endpoints attached to your storage account, you cannot configure network security group rules for subnets.

Responsibility: Customer

1.3: Protect critical web applications

Guidance: Not applicable; recommendation is intended for web applications running on Azure App Service or compute resources.

Responsibility: Customer

1.4: Deny communications with known-malicious IP addresses

Guidance: Enable Microsoft Defender for Storage for your Azure Storage account. Microsoft Defender for Storage provides an additional layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit storage accounts. Microsoft Defender for Cloud integrated alerts are based on activities for which network communication was associated with an IP address that was successfully resolved, whether or not the IP address is a known risky IP address (for example, a known cryptominer) or an IP address that is not recognized previously as risky. Security alerts are triggered when anomalies in activity occur.

Responsibility: Customer

1.5: Record network packets

Guidance: Network Watcher packet capture allows you to create capture sessions to track traffic between Storage account and a virtual machine. Filters are provided for the capture session to ensure you capture only the traffic you want. Packet capture helps to diagnose network anomalies, both reactively, and proactively. Other uses include gathering network statistics, gaining information on network intrusions, to debug client-server communication, and much more. Being able to remotely trigger packet captures, eases the burden of running a packet capture manually on a desired virtual machine, which saves valuable time.

Responsibility: Customer

1.6: Deploy network-based intrusion detection/intrusion prevention systems (IDS/IPS)

Guidance: Microsoft Defender for Storage provides an additional layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit storage accounts. Security alerts are triggered when anomalies in activity occur. These security alerts are integrated with Microsoft Defender for Cloud, and are also sent via email to subscription administrators, with details of suspicious activity and recommendations on how to investigate and remediate threats.

Responsibility: Customer

1.7: Manage traffic to web applications

Guidance: Not applicable; recommendation is intended for web applications running on Azure App Service or compute resources.

Responsibility: Customer

1.8: Minimize complexity and administrative overhead of network security rules

Guidance: For resource in Virtual Networks that need access to your Storage account, use Virtual Network Service tags for the configured Virtual Network to define network access controls on network security groups or Azure Firewall. You can use service tags in place of specific IP addresses when creating security rules. By specifying the service tag name (such as Storage) in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change.

When network access needs to be scoped to specific Storage Accounts, use Virtual Network service endpoint policies.

Responsibility: Customer

1.9: Maintain standard security configurations for network devices

Guidance: Define and implement standard security configurations for network resources associated with your Azure Storage Account with Azure Policy. Use Azure Policy aliases in the "Microsoft.Storage" and "Microsoft.Network" namespaces to create custom policies to audit or enforce the network configuration of your Storage account resources.

You may also make use of built-in policy definitions related to Storage account, such as: Storage Accounts should use a virtual network service endpoint

Responsibility: Customer

1.10: Document traffic configuration rules

Guidance: Use tags for network security groups and other resources related to network security and traffic flow. Tagging lets you associate built-in and custom name-value pairs with a given network resource, helping you to organize network resources and to relate Azure resources back to your network design.

Use any of the built-in Azure Policy definitions related to tagging, such as "Require tag and its value" to ensure that all resources are created with tags and to notify you of existing untagged resources.

Network security groups support tags, but individual security rules do not. Security rules do have a Description field that you can use to store some of the information you would normally put in a tag.

Responsibility: Customer

1.11: Use automated tools to monitor network resource configurations and detect changes

Guidance: Use Azure Policy to log configuration changes for network resources. Create alerts within Azure Monitor that will trigger when changes to critical network resources take place.

Responsibility: Customer

Logging and Monitoring

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

2.2: Configure central security log management

Guidance: Ingest logs via Azure Monitor to aggregate security data generated by endpoints devices, network resources, and other security systems. Within Azure Monitor, use Log Analytics Workspace(s) to query and perform analytics, and use Azure Storage Accounts for long-term/archival storage, optionally with security features such as immutable storage and enforced retention holds.

Responsibility: Customer

2.3: Enable audit logging for Azure resources

Guidance: Azure Storage Analytics provides logs for blobs, queues, and tables. You can use the Azure portal to configure which logs are recorded for your account.

Responsibility: Customer

2.5: Configure security log storage retention

Guidance: When storing Security event logs in the Azure Storage account or Log Analytics workspace, you may set the retention policy according to your organization's requirements.

Responsibility: Customer

2.6: Monitor and review logs

Guidance: To review the Azure Storage logs, there are the usual options such as queries through the Log Analytics offering as well as a unique option of viewing the log files directly. In Azure Storage, the logs are stored in blobs that must be accessed directly at http://accountname.blob.core.windows.net/$logs (The logging folder is hidden by default, so you will need to navigate directly. It will not display in List commands)

Also, Enable Microsoft Defender for Storage for your storage account. Microsoft Defender for Storage provides an additional layer of security intelligence that detects unusual and potentially harmful attempts to access or exploit storage accounts. Security alerts are triggered when anomalies in activity occur. These security alerts are integrated with Microsoft Defender for Cloud, and are also sent via email to subscription administrators, with details of suspicious activity and recommendations on how to investigate and remediate threats.

Responsibility: Customer

2.7: Enable alerts for anomalous activities

Guidance: In Microsoft Defender for Cloud, enable Microsoft Defender for Storage account. Enable Diagnostic Settings for the Storage account and send logs to a Log Analytics Workspace. Onboard your Log Analytics Workspace to Microsoft Sentinel as it provides a security orchestration automated response (SOAR) solution. This allows for playbooks (automated solutions) to be created and used to remediate security issues.

Responsibility: Customer

2.8: Centralize anti-malware logging

Guidance: Use Microsoft Defender for Cloud and enable Microsoft Defender for Storage for detecting malware uploads to Azure Storage using hash reputation analysis and suspicious access from an active Tor exit node (an anonymizing proxy).

Responsibility: Customer

2.9: Enable DNS query logging

Guidance: Azure DNS Analytics (Preview) solution in Azure Monitor gathers insights into DNS infrastructure on security, performance, and operations. Currently this does not support Azure Storage accounts however you can use third-party dns logging solution.

Responsibility: Customer

Identity and Access Control

For more information, see the Azure Security Benchmark: Identity and Access Control.

3.1: Maintain an inventory of administrative accounts

Guidance: Azure Active Directory (Azure AD) has built-in roles that must be explicitly assigned and are queryable. Use the Azure AD PowerShell module to perform ad hoc queries to discover accounts that are members of administrative groups.

Responsibility: Customer

3.2: Change default passwords where applicable

Guidance: Azure Storage accounts nor Azure Active Directory (Azure AD) have the concept of default or blank passwords. Azure Storage implements an access control model that supports Azure role-based access control (Azure RBAC) as well as Shared Key and Shared Access Signatures (SAS). A characteristic of Shared Key and SAS authentication is that no identity is associated with the caller and therefore security principal permission-based authorization cannot be performed.

Responsibility: Customer

3.3: Use dedicated administrative accounts

Guidance: Create standard operating procedures around the use of dedicated administrative accounts that have access to your Storage account. Use Microsoft Defender for Cloud Identity and access management to monitor the number of administrative accounts.

You can also enable a Just-In-Time / Just-Enough-Access by using Azure Active Directory (Azure AD) Privileged Identity Management Privileged Roles for Microsoft Services, and Azure Resource Manager.

Responsibility: Customer

3.4: Use Azure Active Directory single sign-on (SSO)

Guidance: Wherever possible, use Azure Active Directory (Azure AD) SSO instead of configuring individual stand-alone credentials per-service. Use Microsoft Defender for Cloud Identity and Access Management recommendations.

Responsibility: Customer

3.5: Use multi-factor authentication for all Azure Active Directory-based access

Guidance: Enable Azure Active Directory (Azure AD) multifactor authentication and follow Microsoft Defender for Cloud Identity and access management recommendations to help protect your Storage account resources.

Responsibility: Customer

3.6: Use secure, Azure-managed workstations for administrative tasks

Guidance: Use PAWs (privileged access workstations) with multifactor authentication configured to log into and configure Storage account resources.

Responsibility: Customer

3.7: Log and alert on suspicious activities from administrative accounts

Guidance: Send Microsoft Defender for Cloud Risk Detection alerts into Azure Monitor and configure custom alerting/notifications using Action Groups. Enable Microsoft Defender for Storage account to generate alerts for suspicious activity. Additionally, use Azure Active Directory (Azure AD) Risk Detections to view alerts and reports on risky user behavior.

Responsibility: Customer

3.8: Manage Azure resources from only approved locations

Guidance: Use Conditional Access named locations to allow access from only specific logical groupings of IP address ranges or countries/regions.

Responsibility: Customer

3.9: Use Azure Active Directory

Guidance: Use Azure Active Directory (Azure AD) as the central authentication and authorization system. Azure provides Azure role-based access control (Azure RBAC) for fine-grained control over a client's access to resources in a storage account. Use Azure AD credentials when possible as a security best practice, rather than using the account key, which can be more easily compromised. When your application design requires shared access signatures for access to Blob storage, use Azure AD credentials to create a user delegation shared access signatures (SAS) when possible for superior security.

Responsibility: Customer

3.10: Regularly review and reconcile user access

Guidance: Review the Azure Active Directory (Azure AD) logs to help discover stale accounts which can include those with Storage account administrative roles. In addition, use Azure Identity Access Reviews to efficiently manage group memberships, access to enterprise applications that may be used to access Storage account resources, and role assignments. User access should be reviewed on a regular basis to make sure only the right Users have continued access.

You can also use shared access signature (SAS) to provide secure delegated access to resources in your storage account without compromising the security of your data. You can control what resources the client may access, what permissions they have on those resources, and how long the SAS is valid, among other parameters.

Also, review anonymous read access to containers and blobs. By default, a container and any blobs within it may be accessed only by a user that has been given appropriate permissions. You can use Azure Monitor to alert on anonymous access for Storage accounts using anonymous authentication condition.

One effective way to reduce the risk of unsuspected user account access is to limit the duration of access that you grant to users. Time-limited SAS URIs are one effective way to automatically expire user access to a Storage account. Additionally, rotating Storage Account Keys on a frequent basis is a way to ensure that unexpected access via Storage Account keys is of limited duration.

Responsibility: Customer

3.11: Monitor attempts to access deactivated credentials

Guidance: Use Storage Analytics to logs detailed information about successful and failed requests to a storage service. All logs are stored in block blobs in a container named $logs, which are automatically created when Storage Analytics is enabled for a storage account.

Create Diagnostic Settings for Azure Active Directory (Azure AD) user accounts, sending the audit logs and sign-in logs to a Log Analytics Workspace. You can configure desired Alerts within Log Analytics Workspace.

To monitor authentication failures against Azure Storage Accounts, you can create alerts to notify you when certain thresholds have been reached for storage resource metrics. Additionally, use Azure Monitor to alert on anonymous access for Storage accounts using anonymous authentication condition.

Responsibility: Customer

3.12: Alert on account sign-in behavior deviation

Guidance: Use Azure Active Directory (Azure AD)'s Risk and Identity Protection features to configure automated responses to detected suspicious actions related to your Storage account resources. You should enable automated responses through Microsoft Sentinel to implement your organization's security responses.

Responsibility: Customer

3.13: Provide Microsoft with access to relevant customer data during support scenarios

Guidance: In support scenarios where Microsoft needs to access customer data, Customer Lockbox (Preview for Storage account) provides an interface for customers to review and approve or reject customer data access requests. Microsoft will not require, nor request access to your organization's secrets stored within Storage account.

Responsibility: Customer

Data Protection

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

4.1: Maintain an inventory of sensitive Information

Guidance: Use tags to assist in tracking Storage account resources that store or process sensitive information.

Responsibility: Customer

4.2: Isolate systems storing or processing sensitive information

Guidance: Implement isolation using separate subscriptions, management groups, and storage accounts for individual security domains such as environment, and data sensitivity. You can restrict your Storage Account to control the level of access to your storage accounts that your applications and enterprise environments demand, based on the type and subset of networks used. When network rules are configured, only applications requesting data over the specified set of networks can access a storage account. You can control access to Azure Storage via Azure RBAC (Azure RBAC).

You can also configure Private Endpoints to improve security as traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet.

Responsibility: Customer

4.3: Monitor and block unauthorized transfer of sensitive information

Guidance: For Storage account resources storing or processing sensitive information, mark the resources as sensitive using Tags. To reduce the risk of data loss via exfiltration, restrict outbound network traffic for Azure Storage accounts using Azure Firewall.

Additionally, use Virtual network service endpoint policies to filter egress virtual network traffic to Azure Storage accounts over service endpoint, and allow data exfiltration to only specific Azure Storage accounts.

Responsibility: Customer

4.4: Encrypt all sensitive information in transit

Guidance: You can enforce the use of HTTPS by enabling Secure transfer required for the storage account. Connections using HTTP will be refused once this is enabled. Additionally, use Microsoft Defender for Cloud and Azure Policy to enforce Secure transfer for your storage account.

Responsibility: Shared

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 a Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.Storage:

Name
(Azure portal)		 Description Effect(s) Version
(GitHub)
Secure transfer to storage accounts should be enabled Audit requirement of Secure transfer in your storage account. Secure transfer is an option that forces your storage account to accept requests only from secure connections (HTTPS). Use of HTTPS ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking Audit, Deny, Disabled 2.0.0

4.5: Use an active discovery tool to identify sensitive data

Guidance: Data identification features are not yet available for Azure Storage account and related resources. Implement third-party solution if required for compliance purposes.

Responsibility: Customer

4.6: Use Role-based access control to control access to resources

Guidance: Azure Active Directory (Azure AD) authorizes access rights to secured resources through Azure role-based access control (Azure RBAC). Azure Storage defines a set of Azure built-in RBAC roles that encompass common sets of permissions used to access blob or queue data.

Responsibility: Customer

4.8: Encrypt sensitive information at rest

Guidance: Azure Storage encryption is enabled for all storage accounts and cannot be disabled. Azure Storage automatically encrypts your data when it is persisted to the cloud. When you read data from Azure Storage, it is decrypted by Azure Storage before being returned. Azure Storage encryption enables you to secure your data at rest without having to modify code or add code to any applications.

Responsibility: Customer

4.9: Log and alert on changes to critical Azure resources

Guidance: Use Azure Monitor with the Azure Activity Log to create alerts for when changes take place to Storage account resources. You can also enable Azure Storage logging to track how each request made against Azure Storage was authorized. The logs indicate whether a request was made anonymously, by using an OAuth 2.0 token, by using Shared Key, or by using a shared access signature (SAS). Additionally, use Azure Monitor to alert on anonymous access for Storage accounts using anonymous authentication condition.

Responsibility: Customer

Vulnerability Management

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

5.1: Run automated vulnerability scanning tools

Guidance: Follow recommendations from Microsoft Defender for Cloud to continuously audit and monitor the configuration of your storage accounts.

Responsibility: Customer

5.4: Compare back-to-back vulnerability scans

Guidance: Not applicable; Microsoft performs vulnerability management on the underlying systems that support Storage accounts.

Responsibility: Customer

5.5: Use a risk-rating process to prioritize the remediation of discovered vulnerabilities

Guidance: Use the default risk ratings (Secure Score) provided by Microsoft Defender for Cloud.

Responsibility: Customer

Inventory and Asset Management

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

6.1: Use automated asset discovery solution

Guidance: Use Azure Resource Graph to query and discover all resources (including Storage accounts) within your subscription(s). Ensure you have appropriate (read) permissions in your tenant and are able to enumerate all Azure subscriptions as well as resources within your subscriptions.

Responsibility: Customer

6.2: Maintain asset metadata

Guidance: Apply tags to Storage account resources giving metadata to logically organize them into a taxonomy.

Responsibility: Customer

6.3: Delete unauthorized Azure resources

Guidance: Use tagging, management groups, and separate subscriptions, where appropriate, to organize and track Storage accounts and related resources. Reconcile inventory on a regular basis and ensure unauthorized resources are deleted from the subscription in a timely manner.

Also, use Microsoft Defender for Storage to detect unauthorized Azure Resources.

Responsibility: Customer

6.4: Define and maintain inventory of approved Azure resources

Guidance: You will need to create an inventory of approved Azure resources as per your organizational needs.

Responsibility: Customer

6.5: Monitor for unapproved Azure resources

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types

  • Allowed resource types

In addition, use the Azure Resource Graph to query for and discover resources within the subscriptions. This can help in high security-based environments, such as those with Storage accounts.

Responsibility: Customer

6.7: Remove unapproved Azure resources and software applications

Guidance: Customer may prevent resource creation or usage with Azure Policy as required by the customer's company policies.

Responsibility: Customer

6.9: Use only approved Azure services

Guidance: Use Azure Policy to put restrictions on the type of resources that can be created in customer subscriptions using the following built-in policy definitions:

  • Not allowed resource types
  • Allowed resource types

Additional information is available at the referenced links.

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 a Microsoft Defender plan for the related services.

Azure Policy built-in definitions - Microsoft.ClassicStorage:

Name
(Azure portal)		 Description Effect(s) Version
(GitHub)
Storage accounts should be migrated to new Azure Resource Manager resources Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management Audit, Deny, Disabled 1.0.0

Azure Policy built-in definitions - Microsoft.Storage:

Name
(Azure portal)		 Description Effect(s) Version
(GitHub)
Storage accounts should be migrated to new Azure Resource Manager resources Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management Audit, Deny, Disabled 1.0.0

6.11: Limit users' ability to interact with Azure Resource Manager

Guidance: Use the Azure Conditional Access to limit users' ability to interact with Azure Resource Manager by configuring "Block access" for the "Microsoft Azure Management" App. This can prevent the creation and changes to resources within a high security environment, such as those with Storage accounts.

Responsibility: Customer

Secure Configuration

For more information, see the Azure Security Benchmark: Secure Configuration.

7.1: Establish secure configurations for all Azure resources

Guidance: Use Azure Policy aliases in the Microsoft.Storage namespace to create custom policies to audit or enforce the configuration of your Storage account instances. You may also use built-in Azure Policy definitions for Azure Storage account such as:

  • Audit unrestricted network access to storage accounts
  • Deploy Microsoft Defender for Storage
  • Storage accounts should be migrated to new Azure Resource Manager resources
  • Secure transfer to storage accounts should be enabled

Use recommendations from Microsoft Defender for Cloud as a secure configuration baseline for your Storage accounts.

Responsibility: Customer

7.3: Maintain secure Azure resource configurations

Guidance: Use Azure Policy [deny] and [deploy if not exist] to enforce secure settings across your storage account resources.

Responsibility: Customer

7.5: Securely store configuration of Azure resources

Guidance: Use Azure Repos to securely store and manage your code like custom Azure policies, Azure Resource Manager templates, Desired State Configuration scripts etc. To access the resources you manage in Azure DevOps, you can grant or deny permissions to specific users, built-in security groups, or groups defined in Azure Active Directory (Azure AD) if integrated with Azure DevOps, or Azure AD if integrated with TFS.

Responsibility: Customer

7.7: Deploy configuration management tools for Azure resources

Guidance: Leverage Azure Policy to alert, audit, and enforce system configurations for Storage account. Additionally, develop a process and pipeline for managing policy exceptions.

Responsibility: Customer

7.9: Implement automated configuration monitoring for Azure resources

Guidance: Leverage Microsoft Defender for Cloud to perform baseline scans for your Azure Storage account resources.

Responsibility: Customer

7.11: Manage Azure secrets securely

Guidance: Azure Storage automatically encrypts your data when it is persisted it to the cloud. You can use Microsoft-managed keys for the encryption of the storage account, or can manage encryption with their own keys. If you are using customer-provided keys, you can leverage Azure Key Vault to securely store the keys.

Additionally, rotate Storage Account Keys on a frequent basis to limit the impact of loss or disclosure of Storage Account keys.

Responsibility: Customer

7.12: Manage identities securely and automatically

Guidance: Authorize access to blobs and queues within Azure Storage Accounts with Azure Active Directory (Azure AD) and Managed Identities. Azure Blob and Queue storage support Azure AD authentication with managed identities for Azure resources.

Managed identities for Azure resources can authorize access to blob and queue data using Azure AD credentials from applications running in Azure Virtual Machines r, function apps, virtual machine scale sets, and other services. By using managed identities for Azure resources together with Azure AD authentication, you can avoid storing credentials with your applications that run in the cloud.

Responsibility: Customer

7.13: Eliminate unintended credential exposure

Guidance: Implement Credential Scanner to identify credentials within code. Credential Scanner will also encourage moving discovered credentials to more secure locations such as Azure Key Vault.

Responsibility: Customer

Malware Defense

For more information, see the Azure Security Benchmark: Malware Defense.

8.2: Pre-scan files to be uploaded to non-compute Azure resources

Guidance: Use Microsoft Defender for Storage for detecting malware uploads to Azure Storage using hash reputation analysis and suspicious access from an active Tor exit node (an anonymizing proxy).

You can also pre-scan any content for malware before uploading to non-compute Azure resources, such as App Service, Data Lake Storage, Blob Storage, and others to meet your organizations requirements.

Responsibility: Customer

Data Recovery

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

9.1: Ensure regular automated back-ups

Guidance: The data in your Microsoft Azure storage account is always automatically replicated to ensure durability and high availability. Azure Storage copies your data so that it is protected from planned and unplanned events, including transient hardware failures, network or power outages, and massive natural disasters. You can choose to replicate your data within the same data center, across zonal data centers within the same region, or across geographically separated regions.

You can also enable Azure automation to take regular snapshots of the blobs.

Responsibility: Customer

9.2: Perform complete system backups and backup any customer-managed keys

Guidance: In order to back up data from Storage account supported services, there are multiple methods available including using azcopy or third-party tools. Immutable storage for Azure Blob storage enables users to store business-critical data objects in a WORM (Write Once, Read Many) state. This state makes the data non-erasable and non-modifiable for a user-specified interval.

Customer-managed/provided keys can be backed within Azure Key Vault using Azure CLI or PowerShell.

Responsibility: Customer

9.3: Validate all backups including customer-managed keys

Guidance: Periodically perform data restoration of your Key Vault Certificates, Keys, Managed Storage Accounts, and Secrets, with the following PowerShell commands:

Restore-AzKeyVaultCertificate Restore-AzKeyVaultKey Restore-AzKeyVaultManagedStorageAccount Restore-AzKeyVaultSecret

Note: If you want to copy data to and from your Azure Table storage service, then install AzCopy version 7.3.

Responsibility: Customer

9.4: Ensure protection of backups and customer-managed keys

Guidance: To enable customer-managed keys on a storage account, you must use an Azure Key Vault to store your keys. You must enable both the Soft Delete and Do Not Purge properties on the key vault. Key Vault's Soft Delete feature allows recovery of deleted vaults and vault objects such as keys, secrets, and certificates. If backing Storage account data to Azure Storage blobs, enable soft delete to save and recover your data when blobs or blob snapshots are deleted. You should treat your backups as sensitive data and apply the relevant access and data protection controls as part of this baseline. Additionally, for improved protection, you may store business-critical data objects in a WORM (Write Once, Read Many) state.

Responsibility: Customer

Incident Response

For more information, see the Azure Security Benchmark: Incident Response.

10.1: Create an incident response guide

Guidance: Build out an incident response guide for your organization. Ensure that there are written incident response plans that define all roles of personnel as well as phases of incident handling/management from detection to post-incident review.

Responsibility: Customer

10.2: Create an incident scoring and prioritization procedure

Guidance: Microsoft Defender for Cloud assigns a severity to each alert to help you prioritize which alerts should be investigated first. The severity is based on how confident Microsoft Defender for Cloud is in the finding or the analytics used to issue the alert as well as the confidence level that there was malicious intent behind the activity that led to the alert.

Additionally, clearly mark subscriptions (for ex. production, non-prod) using tags and create a naming system to clearly identify and categorize Azure resources, especially those processing sensitive data. It is your responsibility to prioritize the remediation of alerts based on the criticality of the Azure resources and environment where the incident occurred.

Responsibility: Customer

10.3: Test security response procedures

Guidance: Conduct exercises to test your systems’ incident response capabilities on a regular cadence to help protect your Azure resources. Identify weak points and gaps and revise plan as needed.

Responsibility: Customer

10.4: Provide security incident contact details and configure alert notifications for security incidents

Guidance: Security incident contact information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that your data has been accessed by an unlawful or unauthorized party. Review incidents after the fact to ensure that issues are resolved.

Responsibility: Customer

10.5: Incorporate security alerts into your incident response system

Guidance: Export your Microsoft Defender for Cloud alerts and recommendations using the Continuous Export feature to help identify risks to Azure resources. Continuous Export allows you to export alerts and recommendations either manually or in an ongoing, continuous fashion. You may use the Microsoft Defender for Cloud data connector to stream the alerts to Microsoft Sentinel.

Responsibility: Customer

10.6: Automate the response to security alerts

Guidance: Use the Workflow Automation feature in Microsoft Defender for Cloud to automatically trigger responses via "Logic Apps" on security alerts and recommendations to protect your Azure resources.

Responsibility: Customer

Penetration Tests and Red Team Exercises

For more information, see the Azure Security Benchmark: Penetration Tests and Red Team Exercises.

11.1: Conduct regular penetration testing of your Azure resources and ensure remediation of all critical security findings

Guidance: Follow the Microsoft Rules of Engagement to ensure your Penetration Tests are not in violation of Microsoft policies. Use Microsoft’s strategy and execution of Red Teaming and live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.

Responsibility: Shared

Next steps