Chapter 7: Applying Encryption in Cloud Services

In Chapter 2, Securing Compute Services, to Chapter 6, Monitoring and Auditing Your Cloud Environments, we covered the fundamental building blocks of cloud services (from compute, storage, and networking services to Identity and Access Management (IAM) services, to auditing, threat management, and incident response).

This chapter will cover various concepts regarding encryption – including the differences between symmetric and asymmetric encryption, Key Management Services (KMSes), secrets management services, and using encryption in transit and at rest in cloud environments.

Since encryption is a common security best practice that is used to allow data confidentiality, and since many cloud services already have built-in support for encryption (unlike on-premises environments, which require a lot of effort to maintain encryption keys), it is crucial to understand how encryption works and how it is implemented in the various cloud services.

Failing to encrypt sensitive data (such as credit card information, healthcare data, Personally Identifiable Information (PII), and more) puts us at risk of data exposure, as well as potential lawsuits from customers and regulators.

Encryption in the cloud is also important because of multi-tenancy (encryption at rest) and public APIs (encryption in transit).

In this chapter, we will cover the following topics:

• Introduction to encryption
• Best practices for deploying KMSes
• Best practices for deploying secrets management services
• Best practices for using encryption in transit
• Best practices for using encryption at rest
• Encryption in use

Technical requirements

For this chapter, you need to have a solid understanding of cryptographic concepts such as symmetric algorithms, asymmetric algorithms, encryption in transit, and encryption at rest.

Introduction to encryption

Encryption is the process of converting plain text into cipher text. The easiest way to explain why we need encryption is to imagine a scenario where we wish to transfer a file containing sensitive information (such as patient medical records) between two computers over an untrusted network such as the public internet, without being revealed by an untrusted third party.

Another example is a retail website, which processes the credit card information of its customers when they purchase products from the website.

To follow the Payment Card Industry Data Security Standard (PCI DSS), a standard for storing and processing credit card information, the retail company must encrypt all credit card information in transit and at rest.

Let's use a common three-tier architecture as an example – with front web servers (behind the load balancer for high availability), an application server (for processing the business logic), and a backend database (for storing purchase information).

To protect credit card information, we need to do the following:

• Configure the SSL certificate on the load balancer (for encryption in transit).
• Configure the SSL certificate on the web servers (for encryption in transit).
• Configure the SSL certificate between the web servers and the application server (for encryption in transit).
• If the application server stores credit card information (even for a short period) in its local hard drive, we must configure full disk encryption (for encryption at rest).
• Configure full database encryption on the backend database (for encryption at rest).
• To make sure all the encryption keys are stored securely, we need to store them in a secured location (such as a KMS, as explained later in this chapter).

The following is the terminology we need to understand:

• Plaintext: The original human-readable form of information.
• Ciphertext: The result of encryption being done on plaintext – a non-human readable form of information.
• Encryption: The process of converting plaintext into ciphertext.
• Decryption: The process of converting ciphertext back into its original form of plaintext.
• Encryption key: A string that, together with an encryption algorithm, can encode or decode ciphertext.
• Encryption algorithm: A mathematical algorithm that's used in cryptography that, together with an encryption key, allows us to encrypt or decrypt a message.

For more information, please refer to the following resources:

Encryption (according to Wikipedia):

https://en.wikipedia.org/wiki/Encryption

Cryptographic Algorithm:

https://www.sciencedirect.com/topics/computer-science/cryptographic-algorithm

Data Encryption:

https://www.sciencedirect.com/topics/computer-science/data-encryption

An Overview of Cryptography:

https://www.garykessler.net/library/crypto.html

Symmetric encryption

Symmetric encryption is a way to transfer data between two parties while using the same encryption key for both the encryption and decryption processes.

Symmetric encryption is commonly used for the following purposes:

• Encrypting data at rest (such as PII, credit card information, and healthcare information)
• Validating that the sender of a message is who they claim to be
• Generating random numbers (as part of the cryptographic process)

The following diagram shows the process of converting plaintext into ciphertext and vice versa using symmetric encryption:

Figure 7.1 – Symmetric encryption

The following are the pros of symmetric encryption:

• Small ciphertext size
• Suitable for transferring large amounts of data
• Low CPU resources
• Small encryption key size
• Fast encryption time (compared to asymmetric encryption)

The following are the cons of symmetric encryption:

• Considered less secure than asymmetric encryption since both parties are using the same encryption key
• Considered less confidential than asymmetric encryption since both parties are using the same encryption key

Advanced Encryption Standard (AES)

AES is considered the de facto standard that's used today in both on-premises and the public cloud for encryption at rest. It was developed by NIST in 2001 and comes in variable key sizes – the most commonly used key size is 256-bit.

For more information, please refer to the following resources:

Symmetric-key algorithm:

https://en.wikipedia.org/wiki/Symmetric-key_algorithm

Advanced Encryption Standard:

https://en.wikipedia.org/wiki/Advanced_Encryption_Standard

Asymmetric encryption

Asymmetric encryption is a way to transfer data between two parties. However, unlike symmetric encryption, in asymmetric encryption (also known as public-key cryptography or public-key encryption), we use two different keys (private and public) that are linked together mathematically.

In asymmetric encryption, the public key can be shared with anyone and is used to encrypt a message. The private key must be safely guarded and is used for two purposes – decrypting the message and signing the message to ensure message integrity (the message was not tampered with in the process).

Asymmetric encryption is commonly used for the following purposes:

• Creating digital signatures
• Distributing sessions keys for use cases such as the TLS protocol

The following diagram shows the process of converting plaintext into ciphertext and vice versa using asymmetric encryption:

Figure 7.2 – Asymmetric encryption (public-key encryption)

The following are the pros of asymmetric encryption:

• Large ciphertext size (compared to symmetric encryption)
• Large encryption key size (for example, RSA 2,048-bit or higher)
• Considered much safer than symmetric encryption since there are two keys involved in the process and you cannot reveal the private key from the public key
• Considered more confidential than symmetric encryption since there are two keys and the private key (as implied, this must be kept private) is required to decrypt the message

The following are the cons of symmetric encryption:

• Suitable for transferring small amounts of data
• High CPU resources
• Slow encryption time (compared to symmetric encryption)

Rivest Shamir Adleman (RSA)

RSA is one of the most used protocols for encryption at transit, key establishment, and digital signatures. RSA security relies on factoring two large prime numbers (also known as the factoring problem). The recommended key size begins at 2,048-bit or higher.

Elliptical Curve Cryptography (ECC)

ECC is mostly used for key agreements, digital signatures, and pseudo-random generators.

It has a small key size (compared to the RSA algorithm) and is based on the algebraic structure of elliptic curves over finite fields.

The recommended key sizes for ECC are 256-bit (for NSA secret message classifications) and 384-bit (for NSA top-secret message classifications).

For more information, please refer to the following resources:

Public-key cryptography:

https://en.wikipedia.org/wiki/Public-key_cryptography

RSA (cryptosystem):

https://en.wikipedia.org/wiki/RSA_(cryptosystem)

Elliptic-curve cryptography:

https://en.wikipedia.org/wiki/Elliptic-curve_cryptography

Summary

In this section, we reviewed the fundamental concepts regarding encryption, what the differences are between symmetric and asymmetric encryption, and when to use each type of encryption (including common encryption algorithms).

Best practices for deploying KMSes

All major public cloud providers have implementations of a managed KMS – a secured location (or a vault) for generating, storing, and retrieving encryption keys.

The following are some important concepts in the key management field:

• Key Encryption Key (KEK): This is used for generating other encryption keys. The KEK is stored inside the KMS and never leaves it since it wraps (encrypts) other keys in the hierarchy below it.
• Data Encryption Key (DEK): This is used for encrypting the data itself. The DEK is stored near the data itself. KMSes keep a history of DEKs and keep this information in metadata near the data itself, which allows the encrypted service to know which DEK version to use.
• Master Encryption Key (MEK): This is used for encrypting and decrypting the DEK in transit.
• Key Generation: The idea of regenerating new encryption keys to avoid the potential of the key being revealed by an external third party due to a static encryption key (a key that has not been replaced in a very long time) being used for a long time.

AWS Key Management Service (KMS)

AWS KMS is Amazon's key management service.

It allows you to generate and store cryptographic keys in a FIPS 140-2 standard.

AWS KMS generates AES256 symmetric encryption keys for encryption at rest, as well as RSA 2,048-bit (up to 4,096-bit) and ECC 256-bit (up to 512-bit), for encryption, digital signing, and signature verification.

The following are examples of common services that use AWS KMS:

• Amazon S3 (object storage): Protects against unauthorized access to object storage
• Amazon EBS (block storage): Protects against unauthorized access to block storage or snapshots
• Amazon RDS (managed relational database): Protects against unauthorized access to managed databases (usually from within the operating system)

The following are some best practices regarding AWS KMS:

• Use IAM policies to grant access to a specific encryption key using an API (such as the ability to tag a resource, but not to read an encryption key).
• For better control over your encryption keys, specify the key's ARN inside the IAM policy.
• Use the AWS IAM Access Analyzer API to detect external entities with access to AWS KMS keys.
• Use Amazon S3 bucket keys to create unique data keys for objects inside an S3 bucket, which lower the number of requests between S3 and AWS KMS (offers better performance for encrypting/decrypting objects, caching encryption closer to data, and lowering the cost per total number of requests to AWS KMS).
• To secure access from your VPC to AWS KMS, use AWS PrivateLink, which avoids sending network traffic outside your VPC, through a secure channel, using an interface VPC endpoint.
• Use AWS CloudTrail to log all API calls that are made through AWS KMS.
• Use Amazon CloudWatch events to log events concerning CMK key imports, rotation, or deletion.
• Use Amazon CloudWatch alarms to send you notifications about CMK keys that are about to be deleted.
• Enforce the use of MFA for any user with access to AWS KMS (using the AWS console or using APIs).
• For services that support encryption at rest, use AWS managed keys, stored inside AWS KMS, to protect data at rest.
• For highly sensitive environments that support encryption at rest, use Customer Master Keys (CMKs) to protect data at rest while controlling the encryption keys.
• For highly sensitive environments, encrypt log data inside Amazon CloudWatch using an AWS KMS customer-managed key and grant CloudWatch service access to the encryption key.
• If you're using AWS CMKs, and if you have encryption keys that you are not using, disable them through either the AWS KMS console or through an API call.
• Make sure that KMS key rotation is enabled for all your CMKs.
• If you are using your own CMK, regularly rotate your keys. Keys that we leave unchanged increase the risk of key compromise by an unauthorized entity.
• As a best practice, rotate all encryption keys every 365 days (a balance between security and administrative overhead).
• Use tagging (also known as labeling) to have a better understanding of which CMK belongs to which AWS resource.
• Use symmetric encryption with AWS KMS to encrypt data at rest (such as objects inside Amazon S3). Use asymmetric encryption with AWS KMS to sign files and validate that they have not been changed.
• Use AWS Config to monitor for AWS KMS configuration changes.
• Before permanently closing an AWS account that contains sensitive data, delete the CMKs to avoid revealing your data to an unwanted third party.
• If you need to prove that you created the CMKs and not AWS, KMS lets you generate encryption keys on-premises and import them into the AWS KMS service (also known as "bring your own key"). The drawback of this is that AWS cannot rotate your imported keys.

For more information, please refer to the following resources:

Customer master keys (CMKs):

https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys

Logging AWS KMS API calls with AWS CloudTrail:

https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html

Monitoring with Amazon CloudWatch:

https://docs.aws.amazon.com/kms/latest/developerguide/monitoring-cloudwatch.html

Creating an Amazon CloudWatch alarm to detect usage of a customer master key that is pending deletion:

https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html

Enabling and disabling keys:

https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html

Using IAM policies with AWS KMS:

https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html

Connecting to AWS KMS through a VPC endpoint:

https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html

Multi-Factor Authentication:

https://docs.aws.amazon.com/whitepapers/latest/kms-best-practices/multi-factor-authentication.html

AWS-managed and Customer-managed CMKs:

https://docs.aws.amazon.com/whitepapers/latest/kms-best-practices/aws-managed-and-customer-managed-cmks.html

AWS Key Management Service Best Practices:

https://docs.aws.amazon.com/whitepapers/latest/kms-best-practices/introduction.html

How to use AWS Config to determine compliance of AWS KMS key policies to your specifications:

https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-determine-compliance-of-aws-kms-key-policies-to-your-specifications/

Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-key.html

How to use an AWS IAM Access Analyzer API to automate the detection of public access to AWS KMS keys:

https://aws.amazon.com/blogs/security/how-to-use-aws-iam-access-analyzer-api-to-automate-detection-of-public-access-to-aws-kms-keys/

Rotating AWS KMS keys:

https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

Importing key material in AWS KMS keys:

https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html

Encrypt log data in CloudWatch Logs using AWS Key Management Service:

https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html

AWS CloudHSM

AWS CloudHSM is the Amazon-managed cloud-based Hardware Security Module (HSM). It is a FIPS 140-2 Level 3 validated HSM. It is meant to comply with regulated environments such as banks or government agencies. It is a single-tenant key for storage and acts as dedicated hardware for a single customer. The HSM device is tamper-resistant and tamper-proof, which means that any attempt to breach the physical device will cause all the keys to be erased. The Federal Information Processing Standard (FIPS) is a US government standard for cryptographic modules (both hardware and software).

AWS CloudHSM generates AES256 symmetric encryption keys for encryption at rest, as well as RSA 2,048-bit (up to 4,096-bit) and ECC 256-bit (up to 512-bit) for encryption, digital signing, and signature verification.

Since it is a hardware-based module, it contains TLS/SSL acceleration and Oracle Transparent Database Encryption (TDE) acceleration.

The following are some best practices regarding AWS CloudHSM:

• Use AWS CloudHSM to offload TLS processing from highly intensive web servers.
• Use AWS CloudHSM to store your organizational PKI Certificate Authority (CA) private key.
• Always deploy a cluster of AWS CloudHSM modules for high availability, in a different availability zone.
• To overcome the CloudHSM capacity to create new keys, add another CloudHSM module.
• Create an IAM group, add users to that IAM group, and grant the required permissions on AWS CloudHSM to the target IAM group.
• Enforce the use of MFA for any user with access to the AWS CloudHSM console.
• Use CloudHSM Management Utility (CMU) to generate local users that perform actions directly on the CloudHSM appliance (mostly for appliance maintenance).
• Enforce the use of MFA for local users with the Crypto Officer (CO) role.
• Use IAM policies to grant access to an encryption key.
• For better control over your encryption keys, specify the key ARN inside the IAM policy.
• Create a private subnet inside your VPC and deploy the AWS CloudHSM cluster nodes inside this private subnet.
• To secure access from your VPC to AWS CloudHSM, use AWS PrivateLink, which avoids sending network traffic outside your VPC, through a secure channel, using an interface VPC endpoint.
• Use a dedicated EC2 instance to connect to and manage AWS CloudHSM.
• Use security groups to control access between the EC2 instance and AWS CloudHSM.
• Generate an SSL certificate to connect to and manage AWS CloudHSM.
• Use tagging (also known as labeling) to have a better understanding of which CMK belongs to which AWS resource.
• Use symmetric encryption with AWS CloudHSM to encrypt data at rest (such as objects inside Amazon S3).
• Use asymmetric encryption with AWS CloudHSM to sign files and validate they have not been changed.
• Use AWS CloudTrail to log all API calls that have been made through AWS CloudHSM.
• Use Amazon CloudWatch Logs to monitor the events of AWS CloudHSM, such as creating/deleting/changing a password for local CloudHSM users or creating/deleting keys.

For more information, please refer to the following resources:

Create IAM Administrative Groups:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/create-iam-user.html

Identity and Access Management for AWS CloudHSM:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/identity-access-management.html

AWS CloudHSM and VPC endpoints:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/cloudhsm-vpc-endpoint.html

Create a Private Subnet:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/create-subnets.html

Reconfigure SSL with a New Certificate and Private Key:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/getting-started-ssl.html

Best Practices for AWS CloudHSM:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/best-practices.html

Managing Two-Factor Authentication (2FA) for Crypto Officers:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/manage-2fa.html

Working With AWS CloudTrail and AWS CloudHSM:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/get-api-logs-using-cloudtrail.html

Working With Amazon CloudWatch Logs and AWS CloudHSM:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/get-hsm-audit-logs-using-cloudwatch.html

CloudHSM best practices to maximize performance and avoid common configuration pitfalls:

https://aws.amazon.com/blogs/security/cloudhsm-best-practices-to-maximize-performance-and-avoid-common-configuration-pitfalls/

AWS CloudHSM Clusters:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/clusters.html

Improve Your Web Server's Security with SSL/TLS Offload in AWS CloudHSM:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/ssl-offload.html

AWS CloudHSM FAQs:

https://aws.amazon.com/cloudhsm/faqs/

Azure Key Vault

Azure Key Vault is the Azure key management, secrets management, and certificate management service. It allows you to generate and store cryptographic keys in a FIPS 140-2 Level 2 standard.

Azure Key Vault generates RSA 2,048-bit (up to 4,096-bit) and ECC 256-bit (up to 512-bit) for encryption, digital signing, and signature verification.

The following are examples of common services that use Azure Key Vault:

• Azure Blob storage (object storage): Protects against unauthorized access to object storage
• Azure Managed Disks (block storage): Protects against unauthorized access to block storage or snapshots
• Azure SQL (managed SQL database): Protects against unauthorized access to managed databases (usually from within the operating system)

The following are some best practices regarding Azure Key Vault:

• Use Azure Key Vault to store Azure storage account keys.
• Use Azure Key Vault to store x509 certificates, such as your organizational PKI CA private key.
• Use Azure Key Vault to store passwords, instead of storing them in cleartext in code or scripts (such as PowerShell scripts).
• Use Azure Key Vault to store client application secrets, instead of storing them in cleartext in your code (such as Java or DotNet code).
• Use Azure Key Vault to store SSH keys for accessing VMs using SSH, without storing the SSH keys locally on a desktop.
• Use Azure Key Vault to store connection strings to databases (instead of storing cleartext credentials inside code or scripts).
• Use Azure Key Vault to store access keys for various Azure services (from the Redis Cache service, Azure Cosmos DB, Azure Event Hubs, and more).
• Use Azure Role-Based Access Control (RBAC) to configure minimal access to Azure Key Vault.
• Enforce the use of MFA for users with access to the Azure Key Vault console or through an API.
• Use Azure AD Privileged Identity Management (PIM) to control access to Azure Key Vault. For the highest level of access control to Azure Key Vault, create a different AD group for each Azure Key Vault (for example, split them between Prod and Dev) and use Azure PIM to control Just-in-Time (JIT) access to each Key Vault by different members of your organization, according to their job requirements (owner for creating new keys, reader for accessing keys, and so on).
• Use virtual network service endpoints to control access from your VNet to Azure Key Vault.
• Use tagging (that is, labeling) to have a better understanding of which key vault belongs to which Azure resource.
• As a best practice, rotate all the encryption keys every 365 days (a balance between security and administrative overhead).
• Enable Azure Key Vault logging and send the logs to Azure Log Analytics Workspace.
• Forward the logs from Azure Log Analytics Workspace to Azure Sentinel for further analysis.
• Use Key Vault insights (within Azure Monitor) to gather information about performance, failure, and latency issues.
• Enable Azure Defender for Key Vault for advanced threat protection for Azure Key Vault.
• Use Azure Security Center to monitor for compliance issues related to Azure Key Vault.
• Enable soft delete and purge protection to avoid accidental key deletion.

For more information, please refer to the following resources:

Best practices to use Key Vault:

https://docs.microsoft.com/en-us/azure/key-vault/general/best-practices

Virtual network service endpoints for Azure Key Vault:

https://docs.microsoft.com/en-us/azure/key-vault/general/overview-vnet-service-endpoints

Enable Key Vault logging:

https://docs.microsoft.com/en-us/azure/key-vault/general/howto-logging?tabs=azure-cli

Monitoring and alerting for Azure Key Vault:

https://docs.microsoft.com/en-us/azure/key-vault/general/alert

Monitoring your key vault service with Key Vault insights:

https://docs.microsoft.com/en-us/azure/azure-monitor/insights/key-vault-insights-overview

Introduction to Azure Defender for Key Vault:

https://docs.microsoft.com/en-us/azure/security-center/defender-for-key-vault-introduction

Azure security baseline for Key Vault:

https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/key-vault-security-baseline

Key types, algorithms, and operations:

https://docs.microsoft.com/en-us/azure/key-vault/keys/about-keys-details

Manage storage account keys with Key Vault and the Azure CLI:

https://docs.microsoft.com/en-us/azure/key-vault/secrets/overview-storage-keys

About Azure Key Vault certificates:

https://docs.microsoft.com/en-us/azure/key-vault/certificates/about-certificates

Azure Key Vault recovery management with soft delete and purge protection:

https://docs.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery

Authentication in Azure Key Vault:

https://docs.microsoft.com/en-us/azure/key-vault/general/authentication

Azure Key Vault security:

https://docs.microsoft.com/en-us/azure/key-vault/general/security-features

Azure Dedicated/Managed HSM

Azure Managed HSM and Azure Dedicated HSM are the Azure managed cloud-based Hardware Security Modules (HSMs). They are FIPS 140-2 Level 3 validated HSMs. They are meant to comply with regulated environments such as banks or government agencies.

An HSM device is tamper-resistant and tamper-proof, which means that any attempt to breach the physical device will cause all the keys to be erased.

Federal Information Processing Standards (FIPS) is a US government standard for cryptographic modules (both hardware and software).

Azure Dedicated HSM generates AES256 symmetric encryption keys for encryption at rest, as well as RSA 2,048-bit (up to 4,096-bit) and ECC 256-bit (up to 512-bit) for encryption, digital signing, and signature verification.

The following are some best practices regarding Azure Dedicated/Managed HSM:

• Use Azure Managed HSM to store Azure storage account keys.
• Use Azure Managed HSM to store x509 certificates, such as your organizational PKI CA private key.
• Use Azure RBAC to configure minimal access to Azure Managed HSM.
• Enforce the use of MFA for users with access to the Azure Managed HSM console or through an API.
• Regularly back up your Azure Managed HSM.
• Use virtual network service endpoints to control access from your VNet to Azure Managed HSM.
• Use tagging (that is, labeling) to have a better understanding of which key vault belongs to which Azure resource.
• Enable Azure Managed HSM logging and send the logs to Azure Log Analytics Workspace.
• Forward the logs from Azure Log Analytics Workspace to Azure Sentinel for further analysis.
• Import the encryption keys from your on-premises HSM to Azure Managed HSM (also known as bring your own keys).
• Import your on-premises HSM Security Domain into Azure Managed HSM so that you can share an existing security domain.
• Enable soft-delete and purge protection to avoid accidental key deletion.

For more information, please refer to the following resources:

Azure Dedicated HSM documentation:

https://docs.microsoft.com/en-us/azure/dedicated-hsm/

What is Azure Key Vault Managed HSM?:

https://docs.microsoft.com/en-us/azure/key-vault/managed-hsm/overview

Frequently asked questions (FAQs):

https://docs.microsoft.com/en-us/azure/dedicated-hsm/faq

Managed HSM local RBAC built-in roles:

https://docs.microsoft.com/en-us/azure/key-vault/managed-hsm/built-in-roles

General availability: Azure Managed HSM Private Link:

https://azure.microsoft.com/en-us/updates/azure-managed-hsm-private-link-ga-announcement/

Managed HSM logging:

https://docs.microsoft.com/en-us/azure/key-vault/managed-hsm/logging

Integrate Managed HSM with Azure Private Link:

https://docs.microsoft.com/en-us/azure/key-vault/managed-hsm/private-link

Key types, algorithms, and operations:

https://docs.microsoft.com/en-us/azure/key-vault/keys/about-keys-details

Import HSM-protected keys to Managed HSM (BYOK):

https://docs.microsoft.com/en-us/azure/key-vault/managed-hsm/hsm-protected-keys-byok

Managed HSM soft delete and purge protection:

https://docs.microsoft.com/en-us/azure/key-vault/managed-hsm/recovery

About the Managed HSM Security Domain:

https://docs.microsoft.com/en-us/azure/key-vault/managed-hsm/security-domain

Google Cloud Key Management Service (KMS)

Google Cloud KMS is GCP's key management service. It allows you to generate and store cryptographic keys in a FIPS 140-2 Level standard as a software-based solution or a FIPS 140-2 Level 3 standard as a hardware-based HSM.

FIPS is a US government standard for cryptographic modules (both hardware and software).

The HSM device is tamper-resistant and tamper-proof, which means that any attempt to breach the physical device will cause all the keys to be erased.

Use Google Cloud HSM to comply with regulated environments such as banks or government agencies – if required, Google also supports Hosted Private HSMs.

Google Cloud KMS generates AES256 symmetric encryption keys for encryption at rest, as well as RSA 2,048-bit (up to 4,096-bit) and ECC 256-bit (up to 384-bit) for encryption, digital signing, and signature verification.

The following are some examples of common services that use Google Cloud KMS:

• Google Cloud Storage (object storage): Protects against unauthorized access to object storage
• Google Persistent Disk (block storage): Protects against unauthorized access to block storage or snapshots
• Google Cloud SQL (managed relational database): Protects against unauthorized access to managed databases (usually from within the operating system)

The following are some best practices regarding Google Cloud KMS:

• Use Google Cloud IAM to manage permissions to Google Cloud KMS.
• Ensure your Cloud IAM policy does not allow anonymous or public access to your Cloud KMS keys.
• Use tagging (also known as labeling) to have a better understanding of which Cloud KMS keys belong to which GCP resource.
• As a best practice, rotate all your encryption keys every 365 days (a balance between security and administrative overhead).
• Enable Cloud KMS audit logs to monitor Cloud KMS activity.
• Admin activity audit logs are enabled by default and cannot be disabled.
• Explicitly enable Data access audit logs to log activities that are performed on Google Cloud KMS.
• Limit the access to audit logs to a minimum number of employees, to avoid possible deletion or changes being made to the audit logs.
• Enable automatic key rotation to avoid possible key compromise.
• If you are not using previous versions of your encryption keys, manually disable them.
• For highly sensitive environments, where you have an HSM on-premises, use Cloud External Key Manager (Cloud EKM) to store your encryption keys outside Google data centers.
• For large-scale environments with multiple GCP projects, use VPC Service Controls to enforce access restrictions over your Cloud KMS, based on the identity of your IP address.

For more information, please refer to the following resources:

Cloud Key Management Service QuickStart:

https://cloud.google.com/kms/docs/quickstart

Cloud Key Management Service deep dive:

https://cloud.google.com/security/key-management-deep-dive

Using IAM with Cloud KMS:

https://cloud.google.com/kms/docs/iam

Permissions and roles:

https://cloud.google.com/kms/docs/reference/permissions-and-roles

Cloud KMS audit logging information:

https://cloud.google.com/kms/docs/audit-logging

Hosted Private HSM:

https://cloud.google.com/kms/docs/hosted-private-hsm

Cloud External Key Manager:

https://cloud.google.com/kms/docs/ekm

Rotating keys:

https://cloud.google.com/kms/docs/rotating-keys

Enabling and disabling key versions:

https://cloud.google.com/kms/docs/enable-disable

Customer-managed encryption keys (CMEK):

https://cloud.google.com/kms/docs/cmek

VPC Service Controls supported products and limitations:

https://cloud.google.com/vpc-service-controls/docs/supported-products#table_kms

Summary

In this section, we learned how to secure KMSes based on AWS, Azure, and GCP infrastructure (both software-based and hardware-based KMSes) – from authorization and network access control to auditing and monitoring.

Best practices for deploying secrets management services

All major cloud providers have a secrets management service.

The term secrets refers to database credentials, API keys, tokens, usernames/passwords, and more. The fundamental concept behind secrets management services is to allow you to store such sensitive information in a secured location, with authorization and audit mechanisms, while allowing users and service accounts to securely retrieve secrets, without having to store the information in cleartext in configuration files.

Since the cloud environment is highly dynamic, it is recommended to have a central and secure repository for storing, generating, and retrieving secrets.

DevOps teams can benefit from secrets management services by redirecting their code to the secrets management services, instead of embedding sensitive information (secrets, credentials, access keys, and more) inside cleartext code.

AWS Secrets Manager

AWS Secrets Manager is Amazon's managed secrets service.

The following are some of the services that support the use of secrets inside AWS services:

• Secrets inside AWS Lambda functions
• Passwords for connecting to Amazon RDS (Aurora, MySQL, PostgreSQL, Oracle, MariaDB, and Microsoft SQL Server)
• Secrets inside Amazon DocumentDB
• Secrets inside Amazon RedShift

AWS Secrets Manager allows you to create, store, rotate, label, and manage the versioning of your secrets. Secrets managed by AWS Secrets Manager are encrypted and stored inside AWS KMS.

The following are some best practices regarding AWS Secrets Manager:

• Create an IAM group, add service accounts (or applicative accounts) to the IAM group, and grant the required permissions on AWS Secrets Manager to the target IAM group.
• Use IAM policies to control minimal access to secrets for your users and applications.
• To centrally store secrets from multiple AWS regions, enable Replica Secret and update a Replica Secret encryption key.
• Use tagging (that is, labeling) to have a better understanding of which secret belongs to which AWS resource.
• Make sure secret rotation is enabled.
• Store all sensitive information (such as passwords hints) inside secret values that can be retrieved from AWS Secrets Manager.
• Use client-side caching to improve performance when storing secrets inside the AWS Secrets Manager service.
• Avoid storing sensitive information (such as secrets) inside your log files.
• Run all your AWS resources that need access to AWS Secrets Manager inside your VPC.
• For services that operate outside your VPC, use AWS CodeBuild to access secrets from the AWS Secrets Manager service.
• To secure access from your VPC to AWS Secrets Manager, use AWS PrivateLink, which avoids sending network traffic outside your VPC, through a secure channel, using interface VPC endpoints.
• Use AWS CloudTrail to monitor all API activities that are performed through AWS Secrets Manager.
• Use Amazon CloudWatch Logs to monitor for secrets pending deletion or secret rotation.
• Use AWS Config to monitor for changes in your secrets.
• For services that support the use of AWS Secrets Manager, encrypt secrets using an AWS Secrets Manager encryption key inside AWS KMS.
• For highly sensitive environments, encrypt secrets using your CMK inside AWS KMS.

For more information, please refer to the following resources:

Overview of managing access permissions to your Secrets Manager secrets:

https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_overview.html

AWS Secrets Manager best practices:

https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html

Using Secrets Manager with VPC endpoints:

https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html

How AWS Secrets Manager uses AWS KMS:

https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html

Monitoring the use of your AWS Secrets Manager secrets:

https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html

Google Secret Manager

Google Secret Manager is the GCP-managed secrets service for managing API keys, passwords, certificates, and more.

This service supports the following types of secrets inside GCP services:

• Environment variables inside Google Cloud Build
• Secrets inside Google Cloud Code
• Secrets inside Google Cloud Functions
• Environment variables inside Google Cloud Run
• Secrets inside Google Compute Engine
• Secrets inside Google Kubernetes Engine
• Secrets inside Google Config Connector

Google Secret Manager allows you to create, store, rotate, label, and manage the versioning of your secrets.

Secrets managed by Google Secret Manager are encrypted and stored inside Google Cloud KMS.

The following are some best practices regarding Google Secret Manager:

• Use Google IAM and IAM roles to configure minimal access to secrets for both IAM users and your applications.
• Use IAM Recommender to identify over-privileged identities.
• Use IAM conditions to limit access to secrets.
• If you have any secrets and you are not using them anymore, disable old secret versions before they are deleted to avoid the possibility that you might need an old version if it is destroyed, and the data becomes inaccessible.
• Enable Cloud Secret Manager audit logs to monitor Cloud Secret Manager activity.
• Admin activity audit logs are enabled by default and cannot be disabled.
• Explicitly enable data access audit logs to log activities that are performed on Google Cloud Secret Manager.
• Limit access to audit logs to a minimum number of employees to avoid possible deletion or changes being made to the audit logs.
• Enable automatic key rotation to avoid possible key compromise.
• For highly sensitive environments, encrypt your secrets using Customer-Managed Encryption Keys (CMEKs).
• For large-scale environments with multiple GCP projects, use VPC Service Controls to enforce access restrictions over Cloud Secret Manager based on identity (service account or user) or IP addresses.

For more information, please refer to the following resources:

Access control (IAM):

https://cloud.google.com/secret-manager/docs/access-control

Enforce least privilege with role recommendations:

https://cloud.google.com/iam/docs/recommender-overview

Overview of VPC Service Controls:

https://cloud.google.com/vpc-service-controls/docs/overview

Secret Manager Audit Logging:

https://cloud.google.com/secret-manager/docs/audit-logging

Rotation of secrets:

https://cloud.google.com/secret-manager/docs/rotation-recommendations

Enabling Customer-Managed Encryption Keys (CMEKs) for Secret Manager:

https://cloud.google.com/secret-manager/docs/cmek

Secret Manager Best Practices:

https://cloud.google.com/secret-manager/docs/best-practices

Summary

In this section, we learned how to manage secrets using managed services in both AWS and GCP, from authorization to key rotation, encryption, auditing, and monitoring.

Best practices for using encryption in transit

The idea behind encryption in transit is to allow two parties to share messages over a publicly exposed network, in a secure way, while retaining message confidentiality and integrity.

IPSec

IPSec is the most commonly used protocol for encryption at transit, mainly for site-to-site VPN and VPN tunnels. IPSec resides on layer 3 of the OSI model.

The following are some best practices regarding IPSec:

• Use the IKEv2 protocol for security association (SA).
• Use AES-GCM for encryption.
• Use HMAC-SHA256 (or higher) for integrity.
• When supported by both the client and the server, use certificate-based authentication instead of a pre-shared key.
• Use an up-to-date VPN client (to avoid known vulnerabilities).

For more information, please refer to the following resources:

Internet Protocol Security (IPSec):

https://en.wikipedia.org/wiki/IPsec

Guide to IPSec VPNs:

https://csrc.nist.gov/publications/detail/sp/800-77/rev-1/final

Transport Layer Security (TLS)

TLS is one of the most used protocols for encryption at transit.

It replaced the old Secure Sockets Layer (SSL) protocols, which had security flaws, and is now considered the de facto standard for encryption over the public internet.

TLS combines asymmetric encryption for session negotiation between a client and a server (symmetric key generation and copying between the client and the server) with symmetric encryption for securely transferring messages.

Even though TLS relies on TCP (the transport layer of the OSI model), it is considered application layer encryption (the HTTPS of the HTTP protocol) or layer 7 of the OSI model.

Common use cases include web browsers (client) and web servers (server) such as eCommerce sites. In the context of cloud services, almost all cloud service providers' APIs use TLS for encryption in transit.

The following are some best practices regarding TLS:

• Websites, APIs, or applications that reside in a private subnet or serve internal organization employees use certificates signed by a trusted internal CA.

  Note

  As a best practice, avoid using self-signed certificates since they cannot be verified or trusted.

• For any publicly facing websites, APIs, or applications, use a certificate signed by a well-known public CA.
• Make sure that the certificate is valid (the domain name matches the DNS name) and that the certificate hasn't expired or been revoked.
• Avoid using wildcard certificates – always make sure that the certificate name matches the server's FQDN.
• Avoid using certificates with short validity periods (such as LetsEncrypt certificates).
• When using Kubernetes, use mTLS to encrypt traffic between pods and authenticate both the server and client with each other.
• The minimum recommended TLS protocol version is 1.2, and when you have hardware/software to support it, it is recommended to migrate to TLS 1.3 and drop the support for previous versions of TLS and all versions of SSL protocols.
• Disable the use of weak protocols (any version of SSL and TLS that's lower than 1.2).
• Disable the use of weak cipher suites (such as 3DES/DES/RC2/IDEA).
• Use an RSA private key with a minimum size of 2,048-bit.
• Use the signature algorithm of SHA256.
• Enable the use of Strict Transport Security (HSTS).
• Enable the use of Perfect Forward Secrecy (PFS).
• Use ssllabs.com to test the score of your TLS protocol.
• If you wish to inspect encrypted traffic in cloud services, use SSL termination (for services that support this capability). SSL termination allows you to open encrypted traffic (for example, on your load balancer or frontend web server) by temporarily decrypting the traffic, inspecting it using devices or software that support traffic inspection (such as IPS, WAF, data leak prevention, and more), and finally encrypt the traffic again, before it reaches the next hop (for example, between the load balancer and the web servers).

For more information, please refer to the following resources:

Transport Layer Security:

https://en.wikipedia.org/wiki/Transport_Layer_Security

SSL and TLS Deployment Best Practices:

https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

SSL Server Rating Guide:

https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide

SSL Server Test:

https://www.ssllabs.com/ssltest

Anthos Service Mesh by example: mTLS:

https://cloud.google.com/service-mesh/docs/by-example/mtls

AWS Elastic Load Balancing: Support for SSL Termination:

https://aws.amazon.com/blogs/aws/elastic-load-balancer-support-for-ssl-termination/

Summary

In this section, we learned about the best practices for encrypting data in transit with the most common protocols – IPSec (for VPN tunnels) and TLS (for applications such as web servers and APIs) – for algorithm selection, as well as how to disable the use of weak and vulnerable ciphers.

Best practices for using encryption at rest

The idea behind encryption at rest is to protect data once it has been saved into storage or a database or has been accessed by an untrusted third party.

Object storage encryption

When you're encrypting object storage, each file (or object) is encrypted separately.

Encryption/decryption process

The following workflow explains the process of extracting an encrypted object from object storage:

• The DEK is stored near the object itself, and the object metadata specifies which encryption key version to use.
• The entire DEK is wrapped with a KEK.
• The KEK is stored inside a key-managed service.
• When a request for accessing an object is made, the authorized service (or application) sends a request to the key managed service to locate the KEK and to decrypt the specific DEK.
• The decrypted DEK is sent via a TLS/SSL channel from the KMS to the object storage. The object itself is decrypted using the decrypted DEK.

The following diagram shows the preceding workflow of extracting an encrypted object from object storage:

Figure 7.3 – Object storage encryption

In the following sections, we will review the different types of encryption keys that AWS, Azure, and GCP support for object storage.

AWS and object storage encryption

AWS S3 supports the following types of encryption keys:

• Server-side encryption with Amazon S3 Managed Keys (SSE-S3):
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by AWS.
  • Recommended for all S3 bucket encryption.
• Server-side encryption with CMKs stored in AWS KMS (SSE-KMS):
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside AWS KMS.
  • AWS KMS offers an additional layer of control by configuring access control to the encryption keys.
  • An additional audit trail is enabled using AWS CloudTrail for those who used the CMKs.
  • Recommended for highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside S3 buckets.
• Server-side encryption with customer-provided keys (SSE-C):
  • When you upload a file, Amazon S3 encrypts it using AES256.
  • Files are encrypted by the customer before the file is uploaded to S3.
  • Amazon does not have any access to the encryption key.

For more information, please refer to the following resource:

Protecting data using server-side encryption:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html

Azure and Blob Storage encryption

Azure Blob Storage supports the following types of encryption keys:

• Microsoft-managed keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by Azure.
  • Encryption keys are stored inside the Microsoft key store.
  • Recommended for all blob storage encryption.
• Customer-managed keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside Azure Key Vault or Azure Key Vault HSM.
  • Azure Key Vault offers an additional layer of control by configuring access control for the encryption keys.
  • Recommended for highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside Azure Blob Storage or Azure Files.

For more information, please refer to the following resources:

Azure Storage encryption for data at rest:

https://docs.microsoft.com/en-gb/azure/storage/common/storage-service-encryption

Customer-managed keys for Azure Storage encryption:

https://docs.microsoft.com/en-us/azure/storage/common/customer-managed-keys-overview

GCP and object storage encryption

Google Cloud Storage supports the following types of encryption keys:

• Google-managed encryption keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by GCP.
  • Recommended for all object storage encryption.
• Customer-managed encryption keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside Google Cloud KMS.
  • Google Cloud KMS offers an additional layer of control by configuring access control to the encryption keys.
  • Recommended for highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside Google Cloud Storage.
• Customer-supplied encryption keys:
  • AES256-based encryption at rest.
  • Files are encrypted by the customer before the files are uploaded to Google Cloud Storage.
  • GCP does not have any access to the encryption key.

For more information, please refer to the following resources:

Google-managed encryption keys:

https://cloud.google.com/storage/docs/encryption/default-keys

Customer-managed encryption keys:

https://cloud.google.com/storage/docs/encryption/customer-managed-keys

Customer-supplied encryption keys:

https://cloud.google.com/storage/docs/encryption/customer-supplied-keys

Block storage encryption

When using block storage encryption, a single DEK is used to encrypt the entire block storage (also known as a disk volume). When you're using snapshots, a single encryption key is used to encrypt the entire snapshot.

The DEK is wrapped by a KEK, which is stored inside a secure vault (KMS).

In the following sections, we will review how AWS, Azure, and GCP support different types of encryption keys for block storage.

AWS and block storage encryption

AWS block storage (EBS) supports the following types of encryption keys:

• AWS-managed CMKs:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by AWS.
  • Recommended for all types of EBS volume encryption.
• Customer-managed CMKs:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside AWS KMS.
  • AWS KMS offers an additional layer of control by configuring access control to the encryption keys.
  • Use AWS CloudTrail to check who used the CMKs.
  • Recommended for highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside EBS volumes.

For more information, please refer to the following resources:

How Amazon Elastic Block Store (Amazon EBS) uses AWS KMS:

https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html

Amazon EBS volume encryption:

https://docs.aws.amazon.com/kms/latest/cryptographic-details/ebs-volume-encryption.html

Azure Managed Disks encryption

Azure Managed Disks supports the following types of encryption keys:

• Platform-managed keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by Azure.
  • Recommended for all managed disks, snapshots, and images of VMs.
• Customer-managed keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside Azure Key Vault or Azure Key Vault HSM.
  • Azure Key Vault offers an additional layer of control by configuring access control to the encryption keys.
  • Recommended for highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside managed disks, snapshots, and images of VMs.

For more information, please refer to the following resources:

Server-side encryption of Azure Disk Storage:

https://docs.microsoft.com/en-us/azure/virtual-machines/disk-encryption#server-side-encryption-versus-azure-disk-encryption

Use the Azure portal to enable server-side encryption with customer-managed keys for managed disks:

https://docs.microsoft.com/en-us/azure/virtual-machines/disks-enable-customer-managed-keys-portal

GCP Persistent Disks encryption

Google Persistent Disks supports the following types of encryption keys:

• Google-managed encryption keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by GCP.
  • Recommended for all persistent disks.
• Customer-managed encryption keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside Google Cloud KMS.
  • Google Cloud KMS offers an additional layer of control by configuring access control to the encryption keys.
  • Recommended for new persistent disks in highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside Google Persistent Disks.
• Customer-supplied encryption keys:
  • AES256-based encryption at rest.
  • Files are encrypted by the customer before the files are uploaded to Google Persistent Disk.
  • GCP does not have any access to the encryption key.

For more information, please refer to the following resources:

Helping to protect resources by using Cloud KMS keys:

https://cloud.google.com/compute/docs/disks/customer-managed-encryption

Encrypt disks with customer-supplied encryption keys:

https://cloud.google.com/compute/docs/disks/customer-supplied-encryption

Full database encryption

When using full database encryption (sometimes called Transparent Data Encryption (TDE), a single DEK is used to encrypt the entire database, logs, backups, and snapshots.

The DEK is warped by the KEK, which is stored inside a secured vault (KMS).

In the following sections, we will review what types of encryption keys AWS, Azure, and GCP support for managed databases.

Amazon RDS encryption

Amazon RDS supports the following types of encryption keys:

• AWS-managed CMKs:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by AWS.
  • Recommended for regular RDS database encryption.
• Customer-managed CMKs:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside AWS KMS.
  • AWS KMS offers an additional layer of control by configuring access control to the encryption keys.
  • Use AWS CloudTrail to check who used the CMKs.
  • Recommended for highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside RDS databases.

For more information, please refer to the following resource:

Encrypting Amazon RDS resources:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html

Azure SQL Transparent Data Encryption (TDE)

Azure SQL TDE supports the following types of encryption keys:

• Service-managed transparent data encryption:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by Azure.
  • Recommended for all Azure SQL databases.
• Customer-managed transparent data encryption – Bring Your Own Key:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside Azure Key Vault or Azure Key Vault HSM.
  • Azure Key Vault offers an additional layer of control by configuring access control to the encryption keys.
  • Recommended for highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside Azure SQL.

For more information, please refer to the following resources:

Transparent data encryption for SQL Database, SQL Managed Instance, and Azure Synapse Analytics:

https://docs.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-tde-overview?tabs=azure-portal

Azure SQL Transparent Data Encryption with customer-managed keys:

https://docs.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-overview

Google Cloud SQL encryption

Google Cloud SQL supports the following types of encryption keys:

• Google-managed encryption keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by GCP.
  • Recommended for all Google Cloud SQLs.
• Customer-managed encryption keys:
  • AES256-based encryption at rest.
  • The encryption keys are generated, rotated, and maintained by the customers and stored inside Google Cloud KMS.
  • Google Cloud KMS offers an additional layer of control by configuring access control to the encryption keys.
  • Recommended for new persistent disks in highly sensitive environments that store sensitive data (such as PII, credit card information, healthcare data, and more) inside Google Cloud SQL.

For more information, please refer to the following resources:

Overview of customer-managed encryption keys (CMEK):

https://cloud.google.com/sql/docs/sqlserver/cmek

Using customer-managed encryption keys (CMEK):

https://cloud.google.com/sql/docs/sqlserver/configure-cmek

Row-level security

Row-level security is a relatively new concept that's meant to resolve access 
permissions to shared resources, such as databases serving multiple customers in a multi-tenant environment.

It allows you to encrypt data in a more granular way while granting access permissions to the encrypted content based on row, column, or field (depending on the service's capabilities).

For more information on AWS row-level security, please refer to the following resources:

Multi-tenant data isolation with PostgreSQL Row Level Security:

https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/

Using Row-Level Security (RLS) to Restrict Access to a Dataset in Amazon QuickSight:

https://docs.aws.amazon.com/quicksight/latest/user/restrict-access-to-a-data-set-using-row-level-security.html

Applying row-level and column-level security on Amazon QuickSight dashboards:

https://aws.amazon.com/blogs/big-data/applying-row-level-and-column-level-security-on-amazon-quicksight-dashboards/

Achieve finer-grained data security with column-level access control in Amazon Redshift:

https://aws.amazon.com/blogs/big-data/achieve-finer-grained-data-security-with-column-level-access-control-in-amazon-redshift/

Using field-level encryption to help protect sensitive data in Amazon CloudFront:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html

For more information on Azure row-level security, please refer to the following resources:

Azure SQL Row-Level Security:

https://docs.microsoft.com/en-us/sql/relational-databases/security/row-level-security?view=azuresqldb-current

Azure Data Explorer Row Level Security:

https://docs.microsoft.com/en-us/azure/data-explorer/kusto/management/rowlevelsecuritypolicy

For more information on Google row-level security, please refer to the following resources:

Introduction to BigQuery row-level security:

https://cloud.google.com/bigquery/docs/row-level-security-intro

Working with row-level security:

https://cloud.google.com/bigquery/docs/managing-row-level-security

Summary

In this section, we learned about the best practices for encrypting data at rest using the AWS, Azure, and GCP storage services (through object storage, block storage, full database storage, and row-level security).

Encryption in use

At this point, we understand the concept of protecting data using encryption in transit and encryption at rest. There is still one place we need to protect data – while the data is being used in the server's memory; that is, encryption in use.

AWS Nitro Enclaves

AWS offers its customers a unique architecture that creates an isolated environment for storing sensitive information (such as PII, credit card numbers, and healthcare data), which separates customers' data from the EC2 instance itself while using AWS KMS for data encryption.

For more information, please refer to the following resources:

AWS Nitro Enclaves:

https://aws.amazon.com/ec2/nitro/nitro-enclaves/

How AWS Nitro Enclaves uses AWS KMS:

https://docs.aws.amazon.com/kms/latest/developerguide/services-nitro-enclaves.html

Azure Confidential Computing

Azure Confidential Computing uses hardware to isolate data. Data can be encrypted in use by running it in a Trusted Execution Environment (TEE).

Azure Confidential Computing is based on Intel SGX hardware, and it supports both Azure VMs and Azure Kubernetes Service to allow customers to securely store sensitive information (such as PII, credit card numbers, healthcare data, and more).

For more information, please refer to the following resources:

Azure confidential computing:

https://docs.microsoft.com/en-us/azure/confidential-computing/

Confidential computing nodes on Azure Kubernetes Service:

https://docs.microsoft.com/en-us/azure/confidential-computing/confidential-nodes-aks-overview

Google Confidential Computing

Google Confidential Computing uses hardware to isolate data. Data can be encrypted in use by running it in a TEE.

Google Confidential Computing is based on AMD SEV hardware (2nd Gen AMD EPYC CPUs), and it supports both Google confidential VMs and Google confidential GKEs to allow customers to securely store sensitive information (such as PII, credit card numbers, and healthcare data).

For more information, please refer to the following resources:

Google Confidential VM and Compute Engine:

https://cloud.google.com/compute/confidential-vm/docs/about-cvm

Using Confidential GKE Nodes:

https://cloud.google.com/kubernetes-engine/docs/how-to/confidential-gke-nodes

Summary

In this section, we learned about the various alternatives that AWS, Azure, and GCP offer customers for protecting data in use (from AWS Nitro Enclaves to Azure and Google Confidential Computing).

Summary

In this chapter, we focused on the various encryption alternatives based on AWS, Azure, and GCP.

We began by introducing the concepts of encryption (symmetric and asymmetric algorithms). We continued by introducing the best practices for using KMSes (access control, auditing, and monitoring). Then, we started talking about secrets management services (access control, auditing, and monitoring).

Throughout this chapter, we had a long discussion about encryption in transit and encryption at rest, and we concluded with a short conversation about encryption in use. Following the shared responsibility model, customers can use their own encryption keys, which increases their ability to control the data that's stored in the cloud.

Knowing about the available options for encryption will allow you to choose the most suitable solution for each service you are using in the cloud.

In the next chapter, we will review common security threats to cloud computing (data breaches, misconfiguration, insufficient IAM, account hijacking, insider threats, insecure APIs, and the abuse of cloud services).