Details of the Microsoft Cloud for Sovereignty Baseline Confidential Policies Regulatory Compliance built-in initiative
The following article details how the Azure Policy Regulatory Compliance built-in initiative definition maps to compliance domains and controls in Microsoft Cloud for Sovereignty Baseline Confidential Policies. For more information about this compliance standard, see Microsoft Cloud for Sovereignty Baseline Confidential Policies. To understand Ownership, review the policy type and Shared responsibility in the cloud.
The following mappings are to the Microsoft Cloud for Sovereignty Baseline Confidential Policies controls. Many of the controls are implemented with an Azure Policy initiative definition. To review the complete initiative definition, open Policy in the Azure portal and select the Definitions page. Then, find and select the [Preview]: Sovereignty Baseline - Confidential Policies Regulatory Compliance built-in initiative definition.
Important
Each control below is associated with one or more Azure Policy definitions. These policies may help you assess compliance with the control; however, there often is not a one-to-one or complete match between a control and one or more policies. As such, Compliant in Azure Policy refers only to the policy definitions themselves; this doesn't ensure you're fully compliant with all requirements of a control. In addition, the compliance standard includes controls that aren't addressed by any Azure Policy definitions at this time. Therefore, compliance in Azure Policy is only a partial view of your overall compliance status. The associations between compliance domains, controls, and Azure Policy definitions for this compliance standard may change over time. To view the change history, see the GitHub Commit History.
SO.1 - Data Residency
Azure products must be deployed to and configured to use approved regions.
ID: MCfS Sovereignty Baseline Policy SO.1 Ownership: Shared
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Allowed locations | This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups, Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the 'global' region. | deny | 1.0.0 |
| Allowed locations for resource groups | This policy enables you to restrict the locations your organization can create resource groups in. Use to enforce your geo-compliance requirements. | deny | 1.0.0 |
| Azure Cosmos DB allowed locations | This policy enables you to restrict the locations your organization can specify when deploying Azure Cosmos DB resources. Use to enforce your geo-compliance requirements. | [parameters('policyEffect')] | 1.1.0 |
SO.3 - Customer-Managed Keys
Azure products must be configured to use Customer-Managed Keys when possible.
ID: MCfS Sovereignty Baseline Policy SO.3 Ownership: Shared
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| [Preview]: Azure Recovery Services vaults should use customer-managed keys for encrypting backup data | Use customer-managed keys to manage the encryption at rest of your backup data. By default, customer data is encrypted 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/AB-CmkEncryption. | Audit, Deny, Disabled | 1.0.0-preview |
| Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | Encrypting OS and data disks using customer-managed keys provides more control and greater flexibility in key management. This is a common requirement in many regulatory and industry compliance standards. | Audit, Deny, Disabled | 1.0.1 |
| HPC Cache accounts should use customer-managed key for encryption | Manage encryption at rest of Azure HPC Cache with customer-managed keys. By default, customer data is encrypted 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. | Audit, Disabled, Deny | 2.0.0 |
| Managed disks should be double encrypted with both platform-managed and customer-managed keys | High security sensitive customers who are concerned of the risk associated with any particular encryption algorithm, implementation, or key being compromised can opt for additional layer of encryption using a different encryption algorithm/mode at the infrastructure layer using platform managed encryption keys. The disk encryption sets are required to use double encryption. Learn more at https://aka.ms/disks-doubleEncryption. | Audit, Deny, Disabled | 1.0.0 |
| MySQL servers should use customer-managed keys to encrypt data at rest | Use customer-managed keys to manage the encryption at rest of your MySQL servers. 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. | AuditIfNotExists, Disabled | 1.0.4 |
| PostgreSQL servers should use customer-managed keys to encrypt data at rest | Use customer-managed keys to manage the encryption at rest of your PostgreSQL servers. 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. | AuditIfNotExists, Disabled | 1.0.4 |
| Queue Storage should use customer-managed key for encryption | Secure your queue storage with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. | Audit, Deny, Disabled | 1.0.0 |
| SQL managed instances should use customer-managed keys to encrypt data at rest | Implementing Transparent Data Encryption (TDE) with your own key provides you with increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement. | Audit, Deny, Disabled | 2.0.0 |
| SQL servers should use customer-managed keys to encrypt data at rest | Implementing Transparent Data Encryption (TDE) with your own key provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement. | Audit, Deny, Disabled | 2.0.1 |
| Storage account encryption scopes should use customer-managed keys to encrypt data at rest | Use customer-managed keys to manage the encryption at rest of your storage account encryption scopes. 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 about storage account encryption scopes at https://aka.ms/encryption-scopes-overview. | Audit, Deny, Disabled | 1.0.0 |
| Storage accounts should use customer-managed key for encryption | Secure your blob and file storage account with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. | Audit, Disabled | 1.0.3 |
| Table Storage should use customer-managed key for encryption | Secure your table storage with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. | Audit, Deny, Disabled | 1.0.0 |
SO.4 - Azure Confidential Computing
Azure products must be configured to use Azure Confidential Computing SKUs when possible.
ID: MCfS Sovereignty Baseline Policy SO.4 Ownership: Shared
| Name (Azure portal) |
Description | Effect(s) | Version (GitHub) |
|---|---|---|---|
| Allowed resource types | This policy enables you to specify the resource types that your organization can deploy. Only resource types that support 'tags' and 'location' will be affected by this policy. To restrict all resources please duplicate this policy and change the 'mode' to 'All'. | deny | 1.0.0 |
| Allowed virtual machine size SKUs | This policy enables you to specify a set of virtual machine size SKUs that your organization can deploy. | Deny | 1.0.1 |
Next steps
Additional articles about Azure Policy:
- Regulatory Compliance overview.
- See the initiative definition structure.
- Review other examples at Azure Policy samples.
- Review Understanding policy effects.
- Learn how to remediate non-compliant resources.