Azure security baseline for Container Registry
This security baseline applies guidance from the Azure Security Benchmark version 2.0 to Container Registry. 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 Container Registry.
Note
Controls not applicable to Container Registry, and those for which the global guidance is recommended verbatim, have been excluded. To see how Container Registry completely maps to the Azure Security Benchmark, see the full Container Registry security baseline mapping file.
Network Security
For more information, see the Azure Security Benchmark: Network Security.
NS-1: Implement security for internal traffic
Guidance: Limit access to your private Azure container registry from an Azure virtual network to ensure that only approved resources can access the registry. For cross-premises scenarios, you can also configure firewall rules to allow registry access only from specific IP addresses. From behind a firewall, configure firewall access rules and service tags to access your container registry.
Restrict access to an Azure container registry using an Azure virtual network or firewall rules
Configure rules to access an Azure container registry behind a firewall
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.ContainerRegistry:
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Container registries should not allow unrestricted network access | Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific public IP addresses or address ranges. If your registry doesn't have an IP/firewall rule or a configured virtual network, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: https://aka.ms/acr/portal/public-network and here https://aka.ms/acr/vnet. | Audit, Deny, Disabled | 1.1.0 |
NS-2: Connect private networks together
Guidance: When you enable private endpoint for your Azure Container Registry resources you'll need to establish private network connectivity. Use Azure ExpressRoute or Azure Virtual Private Network (VPN) to create private connections between Azure datacenters which host your container registries and on-premises infrastructure in a colocation environment. To connect two or more virtual networks in Azure, use virtual network peering.
Network traffic between peered virtual networks is private and is kept on the Azure backbone network.
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.ContainerRegistry:
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Container registries should use private link | Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network.By mapping private endpoints to your container registries instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/acr/private-link. | Audit, Disabled | 1.0.1 |
NS-3: Establish private network access to Azure services
Guidance: Use Azure Private Link to enable private access to Container Registry from your virtual networks without crossing the internet.
Private access is another defense in-depth measure to the authentication and traffic security offered by Azure services.
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.ContainerRegistry:
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Container registries should use private link | Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network.By mapping private endpoints to your container registries instead of the entire service, you'll also be protected against data leakage risks. Learn more at: https://aka.ms/acr/private-link. | Audit, Disabled | 1.0.1 |
NS-4: Protect applications and services from external network attacks
Guidance: Protect your Azure Container Registry resources against attacks from external networks. Configuring them with Private Link to prevent external network access to your Container Registries. In situations where virtual networks and Private Link cannot be used, Container Registry allows specifying firewall access rules to limit access to certain networks.
Azure Container Registry isn't intended to host web applications. It's a managed, private Docker registry service. Other network-based application security like web application firewalls, or DDoS do not apply to this service.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
NS-6: Simplify network security rules
Guidance: For resources that need access to your container registry, use virtual network service tags for the Azure Container Registry service 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 "AzureContainerRegistry" 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.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
NS-7: Secure Domain Name Service (DNS)
Guidance: Container Registry doesn't expose its underlying DNS configurations. These settings are maintained by Microsoft.
Responsibility: Microsoft
Microsoft Defender for Cloud monitoring: None
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: Container Registry 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. Resources include: - The Azure portal
Azure Storage
Azure Linux and Windows virtual machines
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.
Securing Azure AD should be a high priority in your organization's cloud security practice. provides an identity secure score to help you compare your identity security posture to Microsoft's best practice recommendations. Use the score to gauge how closely your configuration matches best practice recommendations, and to make improvements in your security posture.
The Azure Container Registry service supports a set of built-in Azure roles that provide different levels of permissions to an Azure container registry. Use Azure role-based access control (Azure RBAC) to assign specific permissions to users, service principals, or other identities that need to interact with a registry. For example, use it to assign permissions to pull or push container images.
There are several ways to authenticate with an Azure container registry. Each is applicable to one or more registry usage scenarios.
Recommended ways include:
- Authenticate to a registry directly via individual login
- Applications and container orchestrators can perform unattended, or "headless," authentication by using an Azure AD service principal
- If you use a container registry with Azure Kubernetes Service (AKS) or another Kubernetes cluster, see Scenarios to authenticate with Azure Container Registry from Kubernetes.
For more information, see:
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
IM-2: Manage application identities securely and automatically
Guidance: Container Registry supports multiple ways to authenticate against a customer registry:
Managed identities (preferred) - Customers may authenticate against their Container Registry using system identities, or user-assigned identities.
Azure AD applications - Customers may use an Azure AD application/service principal to authenticate to their Container Registry.
For more information, see:
- Use a managed identity to authenticate to an Azure container registry
- Container Registry authentication with service principals
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
IM-3: Use Azure AD single sign-on (SSO) for application access
Guidance: Container Registry uses Azure AD to provide identity and access management to Azure resources, cloud applications, and on-premises applications. Identities include enterprise identities like employees, and external identities like partners, vendors, and suppliers. Azure AD enables single sign-on (SSO) to manage and secure access to your organization's on-premises and cloud data and resources.
Connect all your users, applications, and devices to Azure AD. Azure AD offers seamless, secure access, and greater visibility and control.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
IM-7: Eliminate unintended credential exposure
Guidance: Container Registry allows customers to deploy resource configurations as Azure Resource Manager templates that may potentially contain identities and secrets. We recommend you implement Credential Scanner to identify credentials within code or configurations. Credential Scanner will also encourage moving discovered credentials to more secure locations like Azure Key Vault.
For GitHub, you can use the native secret scanning feature to identify credentials or other forms of secrets within the code.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
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 assigned to these two roles can delegate administrator roles:
Global Administrator/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 in Azure AD Privileged Identity Management (PIM). Also, this role 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 and protect these accounts at an elevated level. Users with this privilege can directly or indirectly read and modify every resource in your Azure environment.
You can 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.
Create standard operating procedures around the use of dedicated administrative accounts.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PA-3: Review and reconcile user access regularly
Guidance: Container Registry uses Azure AD accounts to manage its resources and review user accounts. Access assignments regularly to make sure the accounts and their access are valid. You can use Azure AD access reviews to review group memberships, enterprise application access, and role assignments. Azure AD reporting can provide logs to help discover stale accounts.You can also create access review report workflows in Azure AD PIM to ease the review process.
You can also configure Azure AD PIM to alert you when there are too many administrator accounts. PIM can 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.
The Azure Container Registry service supports a set of built-in Azure roles that provide different levels of permissions to an Azure container registry. Use Azure RBAC to assign specific permissions to users, service principals, or other identities that need to interact with a registry. For example, use it to assign permissions to pull or push container images.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PA-6: Use privileged access workstations
Guidance: Secured, isolated workstations are critically important for the security of sensitive roles like administrator, developer, and critical service operator. Use highly secured user workstations and/or Azure Bastion for administrative tasks. Use Azure AD, Microsoft Defender Advanced Threat Protection (ATP), and/or Microsoft Intune to deploy a secure and managed user workstation for administrative tasks. The secured workstations can be centrally managed to enforce secured configuration like:
Strong authentication
Software and hardware baselines
Restricted logical and network access.
For more information, see:
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PA-7: Follow just enough administration (least privilege principle)
Guidance: Container Registry integrates with Azure RBAC to manage its resources. With RBAC, you manage Azure resource access through role assignments. You can assign roles to users, groups, service principals, and managed identities. Certain resources have pre-defined, built-in roles. You can inventory or query these roles through tools like Azure CLI, Azure PowerShell, or the Azure portal. Limit the privileges you assign to resources through Azure RBAC to what the roles require. This practice complements the JIT approach of Azure AD PIM. Review roles and assignments periodically.
Use built-in roles to allocate permissions, and only create custom roles when required. The Azure Container Registry service supports a set of built-in Azure roles that provide different levels of permissions to an Azure container registry. Use Azure RBAC to assign specific permissions to users, service principals, or other identities that need to interact with a registry. For example, use it to assign permissions to pull or push container images.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PA-8: Choose approval process for Microsoft support
Guidance: In support scenarios where Microsoft needs to access customer data, Container Registry supports Customer Lockbox. It provides an interface for you to review and approve or reject customer data access requests.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
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, and specific controls in Azure services like encryption. To ensure consistent access control, align all types of access control with your enterprise segmentation strategy. Inform the enterprise segmentation strategy about the location of sensitive or business critical data and systems. For the underlying platform (managed by Microsoft), Microsoft treats all customer content as sensitive and guards against customer data loss and exposure. To ensure customer data within Azure remains secure, Microsoft has implemented some default data protection controls and capabilities.
By creating tokens, a registry owner can provide users or services with scoped, time-limited access to repositories to pull or push images or perform other actions. A token provides more fine-grained permissions than other registry authentication options, which scope permissions to an entire registry.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
DP-3: Monitor for unauthorized transfer of sensitive data
Guidance: Turn on the audit logs feature for Azure Container Registry and monitor who does push and pull operations on the registry. Set alerts and forward these logs to your SIEM. Set up triggers for activity that is suspicious or forms an irregular pattern of access.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
DP-4: Encrypt sensitive information in transit
Guidance: To complement access controls, protect data in transit against "out of band" attacks (like traffic capture) using encryption to ensure that attackers can't easily read or modify the data.
Azure Container Registry enforces data encryption in transit to the service and requires all secure connections from servers and applications to use TLS 1.2. Enable TLS 1.2 by using any recent docker client (version 18.03.0 or later). Support for TLS 1.0 and 1.1 is retired.
Responsibility: Shared
Microsoft Defender for Cloud monitoring: None
DP-5: Encrypt sensitive data at rest
Guidance: To complement access controls, Container Registry encrypts data at rest to protect against "out of band" attacks (like accessing underlying storage) using encryption. It helps ensure that attackers can't easily read or modify the data.
Azure provides encryption for data at rest by default. For highly sensitive data, you have options to implement more encryption at rest on all Azure resources where available. Azure manages your encryption keys by default, but Azure also provides options to manage your own keys (customer-managed keys) for certain Azure services to meet regulatory requirements.
Responsibility: Microsoft
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.ContainerRegistry:
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Container registries should be encrypted with a customer-managed key | Use customer-managed keys to manage the encryption at rest of the contents of your registries. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at https://aka.ms/acr/CMK. | Audit, Deny, Disabled | 1.1.2 |
Asset Management
For more information, see the Azure Security Benchmark: Asset Management.
AM-1: Ensure security team has visibility into risks for assets
Guidance: Make sure security teams are granted Security Reader permissions in your Azure tenant and subscriptions, so they can monitor for security risks by using Microsoft Defender for Cloud.
Monitoring for security risks could be the responsibility of a central security team or a local team, depending on how you structure responsibilities. Always aggregate security insights and risks centrally within an organization.
You can apply Security Reader permissions broadly to an entire tenant's Root Management Group, or scope permissions to specific management groups or subscriptions.
Note: Getting visibility into workloads and services might require more permissions.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
AM-2: Ensure security team has access to asset inventory and metadata
Guidance: Make sure that security teams have access to a continuously updated inventory of assets on Azure, like Container Registry. Security teams often need this inventory to evaluate their organization's potential exposure to emerging risks, and as an input to continuous security improvements. Create an Azure AD group to contain your organization's authorized security team and assign it read access to all Container Registry resources. You can simplify the process with a single high-level role assignment in your subscription.
Apply tags to your Azure resources, resource groups, and subscriptions to logically organize them into a taxonomy. 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.
Use Azure Virtual Machine Inventory to automate the collection of information about software on virtual machines. Software Name, Version, Publisher, and Refresh Time are available from the Azure portal. To get access to install dates and other information, enable guest-level diagnostics and bring the Windows Event Logs into a Log Analytics Workspace.
Use Microsoft Defender for Cloud Adaptive Application Controls to specify which file types a rule might or might not apply to.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
AM-3: Use only approved Azure services
Guidance: Use Azure Policy to audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within their subscriptions. You can also use Azure Monitor to create rules to trigger alerts when a non-approved service is detected.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
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: Use the Microsoft Defender for Cloud built-in threat detection capability and enable Microsoft Defender for your Container Registry resources. Microsoft Defender for Container Registry provides another layer of security intelligence. It detects unusual and potentially harmful attempts to access or exploit your Container Registry resources.
Forward any logs from Container Registry to your SIEM, which can be used to set up custom threat detections. Make sure you're monitoring 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. Alerts can be sourced from log data, agents, or other data.
Microsoft Defender for Cloud security alerts reference guide
Azure Container Registry logs for diagnostic evaluation and auditing
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
LT-2: Enable threat detection for Azure identity and access management
Guidance: Azure AD provides the following user logs. You can view the logs in Azure AD reporting. You can integrate with Azure Monitor, Microsoft Sentinel, or other SIEM and monitoring tools for sophisticated monitoring and analytics use cases.
- Sign-ins - The sign-ins report provides information about the usage of managed applications and user sign-in activities.- Audit logs - Provides traceability through logs for all changes made by various Azure AD features. Audit logs include changes made to any resource within Azure AD. Changes include adding or removing users, apps, groups, roles, and policies.
- Risky sign-ins - An indicator for sign-in attempts by someone who might not be the legitimate owner of a user account.
- Users flagged for risk - A risky user is an indicator for a user account that might have been compromised.Microsoft Defender for Cloud can also alert you about certain suspicious activities like an excessive number of failed authentication attempts. Deprecated accounts in the subscription can also trigger alerts. Microsoft Defender for Cloud can also alert you about suspicious activities like an excessive number of failed authentication attempts, or about deprecated accounts.
In addition to basic security hygiene monitoring, Microsoft Defender for Cloud's Threat Protection module can collect more in-depth security alerts from:
- Individual Azure compute resources like VMs, containers, and app service
- Data resources like Azure SQL Database and Azure Storage
- Azure service layers
This capability gives you visibility into account anomalies in individual resources.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
LT-3: Enable logging for Azure network activities
Guidance: Enable these logs:
Network Security Group (NSG) resource logs
NSG flow logs
Azure Firewall logs
Collect the logs for security analysis. Use them to support incident investigations, threat hunting, and security alert generation. You can send the flow logs to an Azure Monitor Log Analytics workspace and then use Traffic Analytics to provide insights.
Container Registry doesn't produce or process DNS query logs.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
LT-4: Enable logging for Azure resources
Guidance: Activity logs are available automatically. The logs contain all PUT, POST, and DELETE, but not GET, operations for Container Registry resources. You can use activity logs to find errors when troubleshooting, or to monitor how users modified resources.
Enable Azure resource logs for Container Registry. You can use Microsoft Defender for Cloud and Azure Policy to enable resource logs and log data collecting. These logs can be critical for investigating security incidents and for forensic exercises.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
LT-6: Configure log storage retention
Guidance: For storage accounts or Log Analytics workspaces that store Container Registry logs, set a log retention period that meets your organization's compliance regulations.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
LT-7: Use approved time synchronization sources
Guidance: Azure Container Registry doesn't support configuring your own time synchronization sources. The Container Registry service relies on Microsoft time synchronization sources, and isn't exposed to customers for configuration.
Responsibility: Microsoft
Microsoft Defender for Cloud monitoring: None
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: You can use Azure Blueprints to automate deployment and configuration of services and application environments in a single blueprint definition. Environments for:
Azure Resources Manager templates
Azure RBAC controls and policies
Use Azure Blueprints to automate deployment and configuration of Azure Container Registry resource including:
- Azure Resources Manager templates
- Azure RBAC role assignments
- Azure Policy assignments
Use Azure Policy or Microsoft Defender for Cloud to maintain security configurations for all Azure Container Registry resources. Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.
Working with security policies in Microsoft Defender for Cloud
Audit compliance of Azure container registries using Azure Policy
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PV-2: Sustain secure configurations for Azure services
Guidance: Use Microsoft Defender for Cloud to monitor your configuration baseline. Use Azure Policy [deny] and [deploy if not exist] to enforce secure configuration across Azure compute resources including VMs, containers, and others.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PV-5: Securely store custom operating system and container images
Guidance: Container Registry allows customers to manage operating system images or container images. Use Azure Shared Image Gallery to share your images with different users, service principals, or Azure AD groups within your organization. Store container images in Azure Container Registry and use Azure RBAC to ensure that only authorized users have access.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PV-6: Perform software vulnerability assessments
Guidance: Container Registry allows service deployment in its environment.
Follow recommendations from Microsoft Defender for Cloud for performing vulnerability assessments on your deployed services:
- Azure virtual machines
- Container images
- SQL servers
Microsoft Defender for Cloud has a built-in vulnerability scanner for virtual machine, container images, and SQL database.
As required, export scan results at consistent intervals and compare the results with previous scans to verify that vulnerabilities have been remediated. When using vulnerability management recommendations suggested by Microsoft Defender for Cloud, you can pivot into the selected solution's portal to view historical scan data.
Microsoft performs vulnerability management on the underlying systems that support Container Registry.
How to implement Microsoft Defender for Cloud vulnerability assessment recommendations
Azure Container Registry integration with Microsoft Defender for Cloud
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 an Microsoft Defender plan for the related services.
Azure Policy built-in definitions - Microsoft.ContainerRegistry:
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Vulnerabilities in Azure Container Registry images should be remediated | Container image vulnerability assessment scans your registry for security vulnerabilities on each pushed container image and exposes detailed findings for each image (powered by Qualys). Resolving the vulnerabilities can greatly improve your containers' security posture and protect them from attacks. | AuditIfNotExists, Disabled | 2.0.0 |
PV-7: Rapidly and automatically remediate software vulnerabilities
Guidance: Not applicable. This recommendation is intended for compute resources. Azure Container Registry doesn't deploy customer-facing compute resources which customers would need to configure.
Responsibility: Shared
Microsoft Defender for Cloud monitoring: None
PV-8: Conduct regular attack simulation
Guidance: As required, conduct penetration testing or red team activities on your Azure resources. Make sure to fix of all critical security findings.
Follow the Microsoft Cloud Penetration Testing Rules of Engagement to ensure your penetration tests don't violate Microsoft policies. Use Microsoft's Red Teaming strategy and execution. Do live site penetration testing against Microsoft-managed cloud infrastructure, services, and applications.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
Endpoint Security
For more information, see the Azure Security Benchmark: Endpoint Security.
ES-3: Ensure antimalware software and signatures are updated
Guidance: Ensure antimalware signatures are updated rapidly and consistently.
Follow the recommendations in Microsoft Defender for Cloud: Compute & Apps to ensure all endpoints are up to date with the latest signatures. Microsoft Antimalware will automatically install the latest signatures and engine updates by default.
Microsoft handles antimalware for the underlying platform through regular updates and deployments
How to deploy Microsoft Antimalware for Azure Cloud Services and Virtual Machines
Endpoint protection assessment and recommendations in Microsoft Defender for Cloud
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
Backup and Recovery
For more information, see the Azure Security Benchmark: Backup and Recovery.
BR-1: Ensure regular automated backups
Guidance: The data in your Microsoft Azure container registry is always automatically replicated to ensure durability and high availability. Azure Container Registry copies your data so that it is protected from planned and unplanned events.
Optionally, geo-replicate a container registry to maintain registry replicas in multiple Azure regions or regions with Availability Zones enabled.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
BR-2: Encrypt backup data
Guidance: System data is encrypted at rest using Microsoft managed key.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
BR-3: Validate all backups including customer-managed keys
Guidance: Container Registry maintains backup of its own critical system data. Periodically ensure that you can restore backed-up customer-managed keys.
Use encryption at rest on all Azure resources. By default, all data in an Azure container registry is encrypted at rest using Microsoft-managed keys.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
BR-4: Mitigate risk of lost keys
Guidance: Make sure you have measures in place to prevent and recover from the loss of Azure Backup encryption keys. Enable soft delete and purge protection in Azure Key Vault to protect keys against accidental or malicious deletion.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
Next steps
- See the Azure Security Benchmark V2 overview
- Learn more about Azure security baselines
Povratne informacije
Pošalјite i prikažite povratne informacije za