Security Control v3: Data protection

Data Protection covers control of data protection at rest, in transit, and via authorized access mechanisms, including discover, classify, protect, and monitor sensitive data assets using access control, encryption, key and certificate management in Azure.

DP-1: Discover, classify, and label sensitive data

Security Principle: Establish and maintain an inventory of the sensitive data, based on the defined sensitive data scope. Use tools to discover, classify and label the in- scope sensitive data.

Azure Guidance: Use tools such as Microsoft Purview, Azure Information Protection and Azure SQL Data Discovery and Classification to centrally scan, classify and label the sensitive data that reside in the Azure, on-premises, Microsoft 365, and other locations.

Implementation and additional context:

• Data classification overview
• Label your sensitive data using Microsoft Purview
• Tag sensitive information using Azure Information Protection
• How to implement Azure SQL Data Discovery
• Microsoft Purview data sources

Customer Security Stakeholders (Learn more):

• Application Security and DevOps
• Data Security
• Infrastructure and endpoint security

DP-2: Monitor anomalies and threats targeting sensitive data

Security Principle: Monitor for anomalies around sensitive data, such as unauthorized transfer of data to locations outside of enterprise visibility and control. This typically involves monitoring for anomalous activities (large or unusual transfers) that could indicate unauthorized data exfiltration.

Azure Guidance: Use Azure Information protection (AIP) to monitor the data that has been classified and labeled.

Use Azure Defender for Storage, Azure Defender for SQL and Azure Cosmos DB to alert on anomalous transfer of information that might indicate unauthorized transfers of sensitive data information.

Note: If required for compliance of data loss prevention (DLP), you can use a host based DLP solution from Azure Marketplace or a Microsoft 365 DLP solution to enforce detective and/or preventative controls to prevent data exfiltration.

Implementation and additional context:

• Enable Azure Defender for SQL
• Enable Azure Defender for Storage

Customer Security Stakeholders (Learn more):

• Security operations
• Application security and DevOps
• Infrastructure and endpoint security

DP-3: Encrypt sensitive data in transit

Security Principle: Protect the data in transit against 'out of band' attacks (such as traffic capture) using encryption to ensure that attackers cannot easily read or modify the data.

Set the network boundary and service scope where data in transit encryption is mandatory inside and outside of the network. While this is optional for traffic on private networks, this is critical for traffic on external and public networks.

Azure Guidance: Enforce secure transfer in services such as Azure Storage, where a native data in transit encryption feature is built in.

Enforce HTTPS for workload web application and services by ensuring that any clients connecting to your Azure resources use transportation layer security (TLS) v1.2 or later. For remote management of VMs, use SSH (for Linux) or RDP/TLS (for Windows) instead of an unencrypted protocol.

Note: Data in transit encryption is enabled for all Azure traffic traveling between Azure datacenters. TLS v1.2 or later is enabled on most Azure PaaS services by default.

Implementation and additional context:

• Double encryption for Azure data in transit
• Understand encryption in transit with Azure
• Information on TLS Security
• Enforce secure transfer in Azure storage

Customer Security Stakeholders (Learn more):

• Security architecture
• Infrastructure and endpoint security
• Application Security and DevOps
• Data Security

DP-4: Enable data at rest encryption by default

Security Principle: To complement access controls, data at rest should be protected against 'out of band' attacks (such as accessing underlying storage) using encryption. This helps ensure that attackers cannot easily read or modify the data.

Azure Guidance: Many Azure services have data at rest encryption enabled by default at the infrastructure layer using a service-managed key.

Where technically feasible and not enabled by default, you can enable data at rest encryption in the Azure services, or in your VMs for storage level, file level, or database level encryption.

Implementation and additional context:

• Understand encryption at rest in Azure
• Data at rest double encryption in Azure
• Encryption model and key management table
• Security architecture

Customer Security Stakeholders (Learn more):

• Infrastructure and endpoint security
• Application Security and DevOps
• Data Security

DP-5: Use customer-managed key option in data at rest encryption when required

Security Principle: If required for regulatory compliance, define the use case and service scope where customer-managed key option is needed. Enable and implement data at rest encryption using customer-managed key in services.

Azure Guidance: Azure also provides encryption option using keys managed by yourself (customer-managed keys) for certain services. However, using customer-managed key option requires additional operational efforts to manage the key lifecycle. This may include encryption key generation, rotation, revoke and access control, etc.

Implementation and additional context:

• Encryption model and key management table
• Services that support encryption using customer-managed key
• How to configure customer managed encryption keys in Azure Storage

Customer Security Stakeholders (Learn more):

• Security architecture
• Infrastructure and endpoint security
• Application Security and DevOps
• Data Security

DP-6: Use a secure key management process

Security Principle: Document and implement an enterprise cryptographic key management standard, processes, and procedures to control your key lifecycle. When there is a need to use customer-managed key in the services, use a secured key vault service for key generation, distribution, and storage. Rotate and revoke your keys based on the defined schedule and when there is a key retirement or compromise.

Azure Guidance: Use Azure Key Vault to create and control your encryption keys life cycle, including key generation, distribution, and storage. Rotate and revoke your keys in Azure Key Vault and your service based on the defined schedule and when there is a key retirement or compromise.

When there is a need to use customer-managed key (CMK) in the workload services or applications, ensure you follow the best practices:

• Use a key hierarchy to generate a separate data encryption key (DEK) with your key encryption key (KEK) in your key vault.
• Ensure keys are registered with Azure Key Vault and implement via key IDs in each service or application.

If you need to bring your own key (BYOK) to the services (i.e., importing HSM-protected keys from your on-premises HSMs into Azure Key Vault), follow the recommended guideline to perform the key generation and key transfer.

Note: Refer to the below for the FIPS 140-2 level for Azure Key Vault types and FIPS compliance level.

• Software-protected keys in vaults (Premium & Standard SKUs): FIPS 140-2 Level 1
• HSM-protected keys in vaults (Premium SKU): FIPS 140-2 Level 2
• HSM-protected keys in Managed HSM: FIPS 140-2 Level 3

Implementation and additional context:

• Azure Key Vault overview
• Azure data encryption at rest--Key Hierarchy
• BYOK(Bring Your Own Key) specification
• Identity and key management

Customer Security Stakeholders (Learn more):

• Security architecture
• Application Security and DevOps
• Data Security

DP-7: Use a secure certificate management process

Security Principle: Document and implement an enterprise certificate management standard, processes and procedures which includes the certificate lifecycle control, and certificate policies (if a public key infrastructure is needed).

Ensure certificates used by the critical services in your organization are inventoried, tracked, monitored, and renewed timely using automated mechanism to avoid service disruption.

Azure Guidance: Use Azure Key Vault to create and control the certificate lifecycle, including creation/import, rotation, revocation, storage, and purge of the certificate. Ensure the certificate generation follows the defined standard without using any insecure properties, such as insufficient key size, overly long validity period, insecure cryptography and so on. Setup automatic rotation of the certificate in Azure Key Vault and Azure service (if supported) based on the defined schedule and when there is a certificate expiration. If automatic rotation is not supported in the front application, use a manual rotation in Azure Key Vault.

Avoid using self-signed certificate and wildcard certificate in your critical services due to the limited security assurance. Instead, you can create public signed certificate in Azure Key Vault. The following CAs are the current partnered providers with Azure Key Vault.

• DigiCert: Azure Key Vault offers OV TLS/SSL certificates with DigiCert.
• GlobalSign: Azure Key Vault offers OV TLS/SSL certificates with GlobalSign.

Note: Use only approved Certificate Authority (CA) and ensure the known bad CA root/intermediate certificates and certificates issued by these CAs are disabled.

Implementation and additional context:

• Get started with Key Vault certificates
• Certificate Access Control in Azure Key Vault
• Identity and key management
• Security architecture

Customer Security Stakeholders (Learn more):

• Application Security and DevOps
• Data Security

DP-8: Ensure security of key and certificate repository

Security Principle: Ensure the security of the key vault service used for the cryptographic key and certificate lifecycle management. Harden your key vault service through access control, network security, logging and monitoring and backup to ensure keys and certificates are always protected using the maximum security.

Azure Guidance: Secure your cryptographic keys and certificates by hardening your Azure Key Vault service through the following controls:

• Restrict the access to keys and certificates in Azure Key Vault using built-in access policies or Azure RBAC to ensure the least privileges principle are in place for management plane access and data plane access.
• Secure the Azure Key Vault using Private Link and Azure Firewall to ensure the minimal exposure of the service
• Ensure separation of duties is place for users who manages encryption keys not have the ability to access encrypted data, and vice versa.
• Use managed identity to access keys stored in the Azure Key Vault in your workload applications.
• Never have the keys stored in plaintext format outside of the Azure Key Vault.
• When purging data, ensure your keys are not deleted before the actual data, backups and archives are purged.
• Backup your keys and certificates using the Azure Key Vault. Enable soft delete and purge protection to avoid accidental deletion of keys.
• Turn on Azure Key Vault logging to ensure the critical management plane and data plane activities are logged.

Implementation and additional context:

• Azure Key Vault overview
• Azure Key Vault security best practices
• Use managed identity to access Azure Key Vault
• Identity and key management

Customer Security Stakeholders (Learn more):

• Security architecture
• Application Security and DevOps
• Data Security