Skip to content

MCSB_v1 - Data Protection

ID Control Domain CIS Controls v7.1 ID(s) CIS Controls v8 ID(s) NIST SP800-53 r4 ID(s) PCI-DSS v3.2.1 ID(s) Recommendation Security Principle Azure Guidance Implementation and additional context AWS Guidance Implementation and additional context: AWS Foundational Security Best Practices controls AWS Config Rule (WIP) Azure Policy CIS AWS Foundations Benchmark 1.4.0 Customer Security Stakeholders:
DP-1 Data Protection 13.1 - Maintain an Inventory of Sensitive Information 3.2 - Establish and Maintain a Data Inventory RA-2: SECURITY CATEGORIZATION A3.2 Discover, classify, and label sensitive data 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. Use tools such as Microsoft Purview, which combines the former Azure Purview and Microsoft 365 compliance solutions, 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. Data classification overview: Replicate your data from various sources to a S3 storage bucket and use AWS Macie to scan, classify and label the sensitive data stored in the bucket. AWS Macie can detect sensitive data such as security credentials, financial information, PHI and PII data, or other data pattern based on the custom data identifier rules. Data Classification Process: nan nan [Preview]: Sensitive data in your SQL databases should be classified 2.3.1 Ensure that encryption is enabled for RDS Instances Application Security and DevOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
14.5 - Utilize an Active Discovery Tool to Identify Sensitive Data 3.7 - Establish and Maintain a Data Classification Scheme SC-28: PROTECTION OF INFORMATION AT REST https://docs.microsoft.com/azure/cloud-adoption-framework/govern/policy-compliance/data-classification https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification-process.html (Automated)
3.13 - Deploy a Data Loss Prevention Solution You may also use the Azure Purview multi-cloud scanning connector to scan, classify and label the sensitive data residing in a S3 storage bucket. Data Security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-data-security
Labeling in the Microsoft Purview Data Map: AWS Marketplace - DLP Solution:
https://docs.microsoft.com/azure/purview/create-sensitivity-label Note: You can also use third-party enterprise solutions from AWS marketplace for the purpose of data discovery classification and labeling https://aws.amazon.com/marketplace/search/results?searchTerms=DLP Infrastructure and endpoint security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-infrastructure-endpoint
Tag sensitive information using Azure Information Protection:
https://docs.microsoft.com/azure/information-protection/what-is-information-protection
How to implement Azure SQL Data Discovery:
https://docs.microsoft.com/azure/sql-database/sql-database-data-discovery-and-classification
Microsoft Purview data sources:
https://docs.microsoft.com/azure/purview/purview-connector-overview#purview-data-sources
DP-2 Data Protection 13.3 - Monitor and Block Unauthorized Network Traffic 3.13 - Deploy a Data Loss Prevention Solution AC-4: INFORMATION FLOW ENFORCEMENT A3.2 Monitor anomalies and threats targeting sensitive data 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. Use Azure Information protection (AIP) to monitor the data that has been classified and labeled. Enable Azure Defender for SQL: Use AWS Macie to monitor the data that has been classified and labeled, and use GuardDuty to detect anomalous activities on some resources (S3, EC2 or Kubernetes or IAM resources). Findings and alerts can be triaged, analyzed, and tracked using EventBridge and forwarded to Microsoft Sentinel or Security Hub for incident aggregation and tracking. GuardDuty S3 finding types: nan nan Azure Defender for open-source relational databases should be enabled nan Security operations: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security
14.7 - Enforce Access Control to Data through Automated Tools SI-4: INFORMATION SYSTEM MONITORING https://docs.microsoft.com/azure/azure-sql/database/azure-defender-for-sql https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html Azure Defender for Storage should be enabled
Use Microsoft Defender for Storage, Microsoft Defender for SQL, Microsoft Defender for open-source relational databases, and Microsoft Defender for Cosmos DB to alert on anomalous transfer of information that might indicate unauthorized transfers of sensitive data information. You may also connect your AWS accounts to Microsoft Defender for Cloud for compliance checks, container security, and endpoint security capabilities. Azure Defender for SQL servers on machines should be enabled Application security and DevOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
Enable Azure Defender for Storage: Amazon S3 protection in Amazon GuardDuty: Azure Defender for Azure SQL Database servers should be enabled
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. https://docs.microsoft.com/azure/storage/common/storage-advanced-threat-protection?tabs=azure-security-center Note: If required for compliance of data loss prevention (DLP), you can use a host-based DLP solution from AWS Marketplace. https://docs.aws.amazon.com/guardduty/latest/ug/s3-protection.html Azure Defender for SQL should be enabled for unprotected SQL Managed Instances Infrastructure and endpoint security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-infrastructure-endpoint
Azure Defender for SQL should be enabled for unprotected SQL Managed Instances
Enable Microsoft Defender for Azure Cosmos DB:
https://learn.microsoft.com/azure/defender-for-cloud/defender-for-databases-enable-cosmos-protections?tabs=azure-portal
Enable Microsoft Defender for open-source relational databases and respond to alerts:
https://learn.microsoft.com/azure/defender-for-cloud/defender-for-databases-usage
DP-3 Data Protection 14.4 - Encrypt All Sensitive Information in Transit 3.10 - Encrypt Sensitive Data In Transit SC-8: TRANSMISSION CONFIDENTIALITY AND INTEGRITY 3.5 Encrypt sensitive data in transit 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. Enforce secure transfer in services such as Azure Storage, where a native data in transit encryption feature is built in. Double encryption for Azure data in transit: Enforce secure transfer in services such as Amazon S3, RDS and CloudFront, where a native data in transit encryption feature is built in. TLS security policies in Elastic Load Balancer: CloudFront distributions should require encryption in transit nan Kubernetes clusters should be accessible only over HTTPS 2.1.2 Ensure S3 Bucket Policy is set to deny HTTP requests (Manual) Security architecture: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-architecture
3.6 https://docs.microsoft.com/azure/security/fundamentals/double-encryption#data-in-transit https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#tls-security-policies Classic Load Balancer listeners should be configured with HTTPS or TLS termination Only secure connections to your Azure Cache for Redis should be enabled
4.1 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. Enforce HTTPS for web application workloads and services by ensuring that any clients connecting to your Azure resources use transport 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. Enforce HTTPS (such as in AWS Elastic Load Balancer) for workload web application and services (either on the server side or client side, or on both) by ensuring that any clients connecting to your AWS resources use TLS v1.2 or later. Application load balancers should be configured to drop HTTP headers FTPS only should be required in your Function App Infrastructure and endpoint security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-infrastructure-endpoint
Understand encryption in transit with Azure: AWS Transfer SFTP and FTPS: Application Load Balancer should be configured to redirect all HTTP requests to HTTPS Secure transfer to storage accounts should be enabled
For remote management of Azure virtual machines, use SSH (for Linux) or RDP/TLS (for Windows) instead of an unencrypted protocol. For secure file transfer, use the SFTP/FTPS service in Azure Storage Blob, App Service apps, and Function apps, instead of using the regular FTP service. https://docs.microsoft.com/azure/security/fundamentals/encryption-overview#encryption-of-data-in-transit For remote management of EC2 instances, use SSH (for Linux) or RDP/TLS (for Windows) instead of an unencrypted protocol. For secure file transfer, use AWS Transfer SFTP or FTPS service instead of a regular FTP service. https://aws.amazon.com/aws-transfer-family/getting-started/?pg=ln&cp=bn Connections to Elasticsearch domains should be encrypted using TLS 1.2 FTPS should be required in your Web App Application Security and DevOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
S3 buckets should require requests to use Secure Socket Layer Windows web servers should be configured to use secure communication protocols
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 services by default. And some services such as Azure Storage and Application Gateway can enforce TLS v1.2 or later on the server side. Information on TLS Security: Note: All network traffic between AWS data centers is transparently encrypted at the physical layer. All traffic within a VPC and between peered VPCs across regions is transparently encrypted at the network layer when using supported Amazon EC2 instance types. TLS v1.2 or later is enabled on most AWS services by default. And some services such as AWS Load Balancer can enforce TLS v1.2 or later on the server side. Function App should only be accessible over HTTPS Data Security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-data-security
https://docs.microsoft.com/security/engineering/solving-tls1-problem Latest TLS version should be used in your API App
FTPS only should be required in your API App
Enforce secure transfer in Azure storage: Web Application should only be accessible over HTTPS
https://docs.microsoft.com/azure/storage/common/storage-require-secure-transfer?toc=/azure/storage/blobs/toc.json#require-secure-transfer-for-a-new-storage-account API App should only be accessible over HTTPS
Enforce SSL connection should be enabled for PostgreSQL database servers
Enforce SSL connection should be enabled for MySQL database servers
Latest TLS version should be used in your Web App
Latest TLS version should be used in your Function App
DP-4 Data Protection 14.8 - Encrypt Sensitive Information at Rest 3.11 - Encrypt Sensitive Data at Rest SC-28: PROTECTION OF INFORMATION AT REST 3.4 Enable data at rest encryption by default 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. Many Azure services have data at rest encryption enabled by default at the infrastructure layer using a service-managed key. These service-managed keys are generated on the customer’s behalf and automatically rotated every two years. Understand encryption at rest in Azure: https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest#encryption-at-rest-in-microsoft-cloud-services Many AWS services have data at rest encryption enabled by default at the infrastructure/platform layer using an AWS-managed customer master key. These AWS-managed customer master keys are generated on the customer's behalf and rotated automatically every three years. AWS Protecting Data at Rest: API Gateway REST API cache data should be encrypted at rest nan Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources 2.1.1 Ensure all S3 buckets employ encryption-at-rest (Manual) Security architecture: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-architecture
3.5 https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-data-at-rest.html CloudTrail should have encryption at rest enabled Transparent Data Encryption on SQL databases should be enabled 2.1.2 Ensure S3 Bucket Policy is set to deny HTTP requests (Manual)
Where technically feasible and not enabled by default, you can enable data at rest encryption in the Azure services, or in your VMs at the storage level, file level, or database level. Data at rest double encryption in Azure: https://docs.microsoft.com/azure/security/fundamentals/encryption-models Where technically feasible and not enabled by default, you can enable data at rest encryption in the AWS services, or in your VMs at the storage level, file level, or database level DynamoDB Accelerator (DAX) clusters should be encrypted at rest Automation account variables should be encrypted 2.2.1 Ensure EBS volume encryption is enabled (Manual) Infrastructure and endpoint security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-infrastructure-endpoint
Attached EBS volumes should be encrypted at rest Service Fabric clusters should have the ClusterProtectionLevel property set to EncryptAndSign 2.3.1 Ensure that encryption is enabled for RDS Instances
Encryption model and key management table: EBS default encryption should be enabled (Automated) Application Security and DevOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
https://docs.microsoft.com/azure/security/fundamentals/encryption-models Amazon EFS should be configured to encrypt file data at rest using AWS KMS
Elasticsearch domains should have encryption at-rest enabled Data Security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-data-security
Amazon Elasticsearch Service domains should encrypt data sent between nodes
RDS DB instances should have encryption at rest enabled
RDS cluster snapshots and database snapshots should be encrypted at rest
S3 buckets should have server-side encryption enabled
SNS topics should be encrypted at rest using AWS KMS
AWS WAF Classic global web ACL logging should be enabled
Amazon SQS queues should be encrypted at rest
DynamoDB Accelerator (DAX) clusters should be encrypted at rest
DP-5 Data Protection 14.8 - Encrypt Sensitive Information at Rest 3.11 - Encrypt Sensitive Data at Rest SC-12: CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT 3.4 Use customer-managed key option in data at rest encryption when required 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 also provides an encryption option using keys managed by yourself (customer-managed keys) for most services. Encryption model and key management table: AWS also provides an encryption option using keys managed by yourself (customer-managed customer master key stored in AWS Key Management Service) for certain services. AWS Services Integrated with AWS KMS: nan nan SQL managed instances should use customer-managed keys to encrypt data at rest nan Security architecture: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-architecture
SC-28: PROTECTION OF INFORMATION AT REST 3.5 https://docs.microsoft.com/azure/security/fundamentals/encryption-models https://aws.amazon.com/kms/features/ SQL servers should use customer-managed keys to encrypt data at rest
3.6 Azure Key Vault Standard, Premium, and Managed HSM are natively integrated with many Azure Services for customer-managed key use cases. You may use Azure Key Vault to generate your key or bring your own keys. AWS Key Management Service (KMS) is natively integrated with many AWS services for customer-managed customer master key use cases. You may either use AWS Key Management Service (KMS) to generate your master keys or bring your own keys. PostgreSQL servers should use customer-managed keys to encrypt data at rest Infrastructure and endpoint security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-infrastructure-endpoint
Services that support encryption using customer-managed key: https://docs.microsoft.com/azure/security/fundamentals/encryption-models#supporting-services AWS-managed and Customer-managed CMKs: Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest
However, using the customer-managed key option requires additional operational effort to manage the key lifecycle. This may include encryption key generation, rotation, revoke, and access control, etc. However, using the 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. https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt Container registries should be encrypted with a customer-managed key Application Security and DevOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
How to configure customer managed encryption keys in Azure Storage: https://docs.microsoft.com/azure/storage/common/storage-encryption-keys-portal Cognitive Services accounts should enable data encryption with a customer-managed key
Storage accounts should use customer-managed key for encryption Data Security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-data-security
MySQL servers should use customer-managed keys to encrypt data at rest
Azure Machine Learning workspaces should be encrypted with a customer-managed key
DP-6 Data Protection nan nan IA-5: AUTHENTICATOR MANAGEMENT 3.6 Use a secure key management process 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. 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. Require a certain cryptographic type and minimum key size when generating keys. Azure Key Vault overview: Use AWS Key Management Service (KMS) to create and control your encryption keys life cycle, including key generation, distribution, and storage. Rotate and revoke your keys in KMS and your service based on the defined schedule and when there is a key retirement or compromise. AWS-managed and Customer-managed CMKs: IAM users' access keys should be rotated every 90 days or less nan Key Vault keys should have an expiration date nan Identity and key management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-identity-keys
SC-12: CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT https://docs.microsoft.com/azure/key-vault/general/overview https://docs.aws.amazon.com/whitepapers/latest/kms-best-practices/aws-managed-and-customer-managed-cmks.html Secrets Manager secrets should have automatic rotation enabled Key Vault secrets should have an expiration date
SC-28: PROTECTION OF INFORMATION AT REST When there is a need to use customer-managed key (CMK) in the workload services or applications, ensure you follow the best practices: When there is a need to use customer-managed customer master key in the workload services or applications, ensure you follow the best practices: Secrets Manager secrets configured with automatic rotation should rotate successfully Security architecture: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-architecture
- Use a key hierarchy to generate a separate data encryption key (DEK) with your key encryption key (KEK) in your key vault. Azure data encryption at rest--Key Hierarchy: - Use a key hierarchy to generate a separate data encryption key (DEK) with your key encryption key (KEK) in your KMS. Importing key material in AWS KMS keys: Secrets Manager secrets should be rotated within a specified number of days
- Ensure keys are registered with Azure Key Vault and implemented via key IDs in each service or application. https://docs.microsoft.com/azure/security/fundamentals/encryption-atrest#key-hierarchy - Ensure keys are registered with KMS and implement via IAM policies in each service or application. https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html Application Security and DevOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
To maximize the key material lifetime and portability, 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. BYOK(Bring Your Own Key) specification: To maximize the key material lifetime and portability, bring your own key (BYOK) to the services (i.e., importing HSM-protected keys from your on-premises HSMs into KMS or Cloud HSM). Follow the recommended guideline to perform the key generation and key transfer. Secure transfer of keys into to CloudHSM: Data Security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-data-security
https://docs.microsoft.com/azure/key-vault/keys/byok-specification https://aws.amazon.com/premiumsupport/knowledge-center/cloudhsm-import-keys-openssl/
Note: Refer to the below for the FIPS 140-2 level for Azure Key Vault types and FIPS compliance/validation level. Note: AWS KMS uses shared HSM infrastructure in the backend. Use AWS KMS Custom Key Store backed by AWS CloudHSM when you need to manage your own key store and dedicated HSMs (e.g. regulatory compliance requirement for higher level of key security) to generate and store your encryption keys.
- Software-protected keys in vaults (Premium & Standard SKUs): FIPS 140-2 Level 1 Creating a custom key store backed by CloudHSM:
- HSM-protected keys in vaults (Premium SKU): FIPS 140-2 Level 2 Note: Refer to the below for the FIPS 140-2 level for FIPS compliance level in AWS KMS and CloudHSM https://docs.aws.amazon.com/kms/latest/developerguide/key-store-concepts.html
- HSM-protected keys in Managed HSM: FIPS 140-2 Level 3 - AWS KMS default: FIPS 140-2 Level 2 validated
Azure Key Vault Premium uses a shared HSM infrastructure in the backend. Azure Key Vault Managed HSM uses dedicated, confidential service endpoints with a dedicated HSM for when you need a higher level of key security. - AWS KMS using CloudHSM: FIPS 140-2 Level 3 (for certain services) validated
- AWS CloudHSM: FIPS 140-2 Level 3 validated
Note: For secrets management(credentials, password, API keys etc.), use AWS Secrets Manager.
DP-7 Data Protection nan nan IA-5: AUTHENTICATOR MANAGEMENT 3.6 Use a secure certificate management process 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). Use Azure Key Vault to create and control the certificate lifecycle, including the 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 supported Azure services based on the defined schedule and when a certificate expires. If automatic rotation is not supported in the frontend application, use a manual rotation in Azure Key Vault. Get started with Key Vault certificates: Use AWS Certificate Manager (ACM) 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 ACM and supported AWS services based on the defined schedule and when a certificate expires. If automatic rotation is not supported in the frontend application, use manual rotation in ACM. In the meantime, you should always track your certificate renewal status to ensure the certificate validity. AWS Certificate Manager - Check a certificate's renewal status: [CloudFront.7] CloudFront distributions should use custom SSL/TLS certificates nan [Preview]: Certificates should have the specified maximum validity period nan Identity and key management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-identity-keys
SC-12: CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT https://docs.microsoft.com/azure/key-vault/certificates/certificate-scenarios https://docs.aws.amazon.com/acm/latest/userguide/check-certificate-renewal-status.html
SC-17: PUBLIC KEY INFRASTRUCTURE CERTIFICATES Ensure certificates used by the critical services in your organization are inventoried, tracked, monitored, and renewed timely using automated mechanism to avoid service disruption. Avoid using a self-signed certificate and wildcard certificate in your critical services due to the limited security assurance. Instead, you can create public signed certificates in Azure Key Vault. The following Certificate Authorities (CAs) are the partnered providers that are currently integrated with Azure Key Vault. Avoid using a self-signed certificate and wildcard certificate in your critical services due to the limited security assurance. Instead, create public-signed certificates (signed by the Amazon Certificate Authority) in ACM and deploy it programmatically in services such as CloudFront, Load Balancers, API Gateway etc. You also can use ACM to establish your private certificate authority (CA) to sign the private certificates. Security architecture: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-architecture
- DigiCert: Azure Key Vault offers OV TLS/SSL certificates with DigiCert. Certificate Access Control in Azure Key Vault:
- GlobalSign: Azure Key Vault offers OV TLS/SSL certificates with GlobalSign. https://docs.microsoft.com/azure/key-vault/certificates/certificate-access-control Note: Use only an approved CA and ensure that known bad CA root/intermediate certificates issued by these CAs are disabled. Application Security and DevOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
Note: Use only approved CA and ensure that known bad root/intermediate certificates issued by these CAs are disabled. Data Security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-data-security
DP-8 Data Protection nan nan IA-5: AUTHENTICATOR MANAGEMENT 3.6 Ensure security of key and certificate repository 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. Secure your cryptographic keys and certificates by hardening your Azure Key Vault service through the following controls: Azure Key Vault overview: For cryptographic keys security, secure your keys by hardening your AWS Key Management Service (KMS) service through the following controls: Security best practice for AWS Key Management Service: IAM customer managed policies should not allow decryption actions on all KMS keys nan Key vaults should have purge protection enabled nan Identity and key management: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-identity-keys
SC-12: CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT - Implement access control using RBAC policies in Azure Key Vault Managed HSM at the key level to ensure the least privilege and separation of duties principles are followed. For example, ensure separation of duties are in place for users who manage encryption keys so they do not have the ability to access encrypted data, and vice versa. For Azure Key Vault Standard and Premium, create unique vaults for different applications to ensure the least privilege and separation of duties principles are followed. https://docs.microsoft.com/azure/key-vault/general/overview - Implement access control using key policies (key-level access control) in conjunction with IAM policies (identity-based access control) to ensure the least privilege and separation of duties principles are followed. For example, ensure separation of duties are in place for users who manage encryption keys so they do not have the ability to access encrypted data, and vice versa. https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys Azure Defender for Key Vault should be enabled
SC-17: PUBLIC KEY INFRASTRUCTURE CERTIFICATES - Turn on Azure Key Vault logging to ensure critical management plane and data plane activities are logged. - Use detective controls such as CloudTrails to log and track the usage of keys in KMS and alert you on critical actions. AWS KMS keys should not be unintentionally deleted Key vaults should have soft delete enabled Security architecture: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-architecture
- Secure the Azure Key Vault using Private Link and Azure Firewall to ensure minimal exposure of the service Azure Key Vault security best practices: - Never store keys in plaintext format outside of KMS. Security in AWS Certificate Manager: [Preview]: Azure Key Vault should disable public network access
- Use managed identity to access keys stored in Azure Key Vault in your workload applications. https://docs.microsoft.com/azure/key-vault/general/best-practices - When keys need to be deleted, consider disabling keys in KMS instead of deleting them to avoid accidental deletion of keys and cryptographic erasure of data. https://docs.aws.amazon.com/acm/latest/userguide/security.html [Preview]: Private endpoint should be configured for Key Vault Application Security and DevOps: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-application-security-devsecops
- When purging data, ensure your keys are not deleted before the actual data, backups and archives are purged. - When purging data, ensure your keys are not deleted before the actual data, backups and archives are purged. Resource logs in Key Vault should be enabled
- Backup your keys and certificates using Azure Key Vault. Enable soft delete and purge protection to avoid accidental deletion of keys.When keys need to be deleted, consider disabling keys instead of deleting them to avoid accidental deletion of keys and cryptographic erasure of data. Use managed identity to access Azure Key Vault: - For bring your own key (BYOK) uses cases, generate keys in an on-premise HSM and import them to maximize the lifetime and portability of the keys. Data Security: https://docs.microsoft.com/azure/cloud-adoption-framework/organize/cloud-security-data-security
- For bring your own key (BYOK) use cases, generate keys in an on-premises HSM and import them to maximize the lifetime and portability of the keys. https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-nonaad
- Never store keys in plaintext format outside of the Azure Key Vault. Keys in all key vault services are not exportable by default. For certificates security, secure your certificates by hardening your AWS Certificate Manager (ACM) service through the following controls:
- Use HSM-backed key types (RSA-HSM) in Azure Key Vault Premium and Azure Managed HSM for the hardware protection and the strongest FIPS levels. Overview of Microsoft Defender for Key Vault: - Implement access control using resource-level policies in conjunction with IAM policies (identity-based access control) to ensure the least privilege and separation of duties principles are followed. For example, ensure separation of duties is in place for user accounts: user accounts who generate certificates are separate from the user accounts who only require read-only access to certificates.
https://learn.microsoft.com/azure/defender-for-cloud/defender-for-key-vault-introduction - Use detective controls such as CloudTrails to log and track the usage of the certificates in ACM, and alert you on critical actions.
Enable Microsoft Defender for Key Vault for Azure-native, advanced threat protection for Azure Key Vault, providing an additional layer of security intelligence. - Follow the KMS security guidance to secure your private key (generated for certificate request) used for service certificate integration.