Share via

Encryption with customer-managed keys in Microsoft Cloud for Sovereignty

  • Article

Customers who plan to implement Microsoft Cloud for Sovereignty might require the use of data encryption features to satisfy data sovereignty requirements. Customers with strict data sovereignty requirements should develop plans to implement key management in the cloud. This article guides cloud architects, cryptographic system owners, and other technical decisions-makers to develop a plan for implementing platform-level encryption in Azure. Planning for encryption at the platform level usually involves identifying key management requirements, making technology choices, and selecting designs and configuration choices for the Azure services to be used. This process involves making technical decisions across three domains:

  • Define key management requirements: What does your organization need to do to protect sensitive customer data and sensitive cryptographic material?
  • Select data encryption features to protect customer data: How, where, and when should you encrypt customer data in Azure?
  • Select key management solutions to protect customer keys: What key store should you use to protect data encryption keys that are used to encrypt customer data in Azure?

Define key management requirements

Requirements for key management can include technical requirements about the cryptographic services that are used and operational requirements related to performance, security, and sovereignty. The recommended starting point for making decisions about when and how to encrypt data in Azure workloads is an organization's data classification system. By aligning encryption requirements with data classifications, rather than specific systems or solutions, organizations have more flexibility to select the optimal level of encryption during workload migration planning.

Basing encryption requirements on data classification also allows for a tiered approach, where workloads with lower criticality can take advantage of simpler solutions while reserving the most complex configurations for workloads with a higher level of inherent risk. An example of this approach would be to allow the use of Microsoft-managed keys to encrypt storage accounts for development environments while requiring production storage accounts to use Customer-managed encryption keys.

After an organization clearly understands how their encryption requirements relate to their data classifications, they can begin the process of feature selection for the Azure services they plan on consuming. Some of these features can operate differently than similar on-premises systems, so organizations are encouraged to familiarize themselves with how encryption works in Azure and review recommendations and best practices for designing encryption solutions. The following articles provide additional perspectives on some of the technical choices that customers need to make and can be a useful starting point for starting a conversation about an organization's cloud key management objectives.

Select data encryption features

Many Azure services enable encryption using keys that are generated, stored, and managed entirely by Azure, without any customer interaction. These Platform-Managed Keys can help organizations implement encryption with little operational overhead. However, customers with strict data sovereignty requirements may need to select specific platform encryption features to protect sensitive data while at rest in a given Azure service.

For highly sensitive data, many commonly used Azure services allow customers to implement double encryption using Customer-Managed Keys (CMK). Implementing customer managed keys in Azure services can help customers protect the data that is stored in those services from unauthorized access.

Implementing customer managed keys in Azure can increase the cost and complexity of a workload, so organizations are encouraged to evaluate the need for this feature for each workload and data classification level. Implementing customer managed keys for only the workloads and data types that need it can help reduce the operational overhead for workloads that don't handle sensitive data.

If Customer Managed Keys are required, they need to be configured for each respective Azure service. Organizations can help streamline deployment or migration planning efforts by establishing organization-wide standards and repeatable design patterns for implementing these features. The following articles provide more information about how data-at-rest encryption is configured in Azure:

Learn how to configure commonly used Azure services to encrypt data-at-rest using Customer-Managed keys:

Select key management solutions

While features such as double encryption with customer managed keys can help protect customer data that is maintained in Azure services, cloud-based key management solutions help protect the encryption keys and other cryptographic materials that are used to encrypt sensitive data. Customers with strict data sovereignty requirements should select a suitable key management solution based on their assurance needs and the risk profile of their workloads.

Workloads that handle sensitive data might benefit from the added assurance provided by solutions like Azure Managed HSM provide, including FIPS-140-2 Level-3 validated hardware security modules that feature extra security controls to protect stored cryptographic material.

The following articles provide guidance that customers can use to select an appropriate key store for their identified scenarios. It also provides information about how Microsoft manages cryptographic services that are used by customers as part of their encryption solution.

Operations models for key management

Azure Key Vault implements role-based access control in different ways, depending on whether you are using the Standard/Premium tier of Azure Key Vault or Azure Key Vault Managed HSM. These differences in access control can impact the way an organization uses these features. This section describes these differences, and how they might affect the way an organization chooses to design their operational processes for cloud key management.

Compliance constraints for FIPS-140 Level-3 validation

FIPS-140 Level-3 validation requires identity-based operator identification. These safeguards are deployed and validated in the underlying HSM hardware that supports the Key Vault services in Azure. As a result, the RBAC features in Azure Key Vault are reliant on the RBAC capabilities of the underlying hardware.

Azure Key Vault Managed HSM takes advantage of the local RBAC assignments that are implemented at the hardware-level and allow role assignments at the scope of the security domain (for example, HSM-wide) or on a per-key basis. This means that key creation requires administrative permissions over the entire security domain, since permissions cannot be assigned for a key that does not yet exist. The impact of this design is that anyone that needs to store a key in an mHSM instance must either have full permissions for all keys stored in that security domain, or request keys from a centralized team that has those required permissions over the security domain. This represents a shift from the guidance for Azure Key Vault that recommends creating separate key vaults for each application.

Key management operations in Azure Key Vault Managed HSM

In order to develop operational processes for key management, customers should determine if they require Azure Key Vault Managed HSM as part of their solution architecture. Organizations that are planning to use managed HSM should first familiarize themselves with the access control models used for both administration and cryptographic operations, and understand how role-based access control is assigned.

Learn more about access control in managed HSM:

Organizations that are planning on using Azure Key Vault HSM should review the list of built-in RBAC roles and permitted operations for managed HSM and specifically plan for addressing the following operations scenarios:

  • Creation of a new key in managed HSM
  • Management operations of an existing key using the control plane, such as key updates or key rotation
  • Data plane usage of an existing key by an application or service

Currently, the only way to assign permissions to create a new key is to assign a role such as Crypto User that also includes other permissions like key rotation and deletion. As a result, granting an application team member the needed permissions to create their own keys in managed HSM can likely violate least privilege principles, since that user would also have administrative permissions for all the keys in the HSM. This problem can be solved by introducing a centralized team with the elevated permissions who can facilitate key creation requests, or introducing automation that can facilitate new key creation requests through IT service management processes that leverage the Managed HSM REST API.

Related content