KMS

CMK (customer master key)

In AWS Key Management Service (KMS), CMK stands for Customer Master Key. It is a fundamental component of KMS and is used to encrypt and decrypt data in AWS services and applications securely. CMKs are created, owned, and managed by AWS customers, allowing them to have control over their encryption keys.

Some points for exam

• Automatic key rotation
  • AWS KMS doesn't rotate the backing keys of CMKs that are pending deletion
  • Automatic key rotation is not supported for imported keys, asymmetric keys, or keys generated in an AWS CloudHSM cluster using the AWS KMS custom key store feature
• A CMK that is pending deletion cannot be used in any cryptographic operation
• You can schedule the CMK for deletion with a default waiting period of 30 days

Envelope Encryption

Envelope encryption is a data encryption technique where a data encryption key (DEK) is used to encrypt the actual data, and this DEK is further encrypted using a master key, known as the Key Encryption Key (KEK). The encrypted DEK, along with the encrypted data, forms an "envelope" that provides an additional layer of security and separation of responsibilities. Envelope encryption ensures that sensitive data remains protected and allows for efficient and secure key management.

Source: AWS KMS Envelope Encryption

The full steps to encrypt and decrypt a data in the envelope encryption manner

1. The symmetric key is generated from software or hardware.
2. The generated symmetric data key is used to encrypt plaintext data.
3. The key encrypts data using an algorithm such as AES and generates encrypted ciphertext data.
4. The encrypted data is stored in targeted storage.
5. As the data key needs to be stored with ciphered data, the data key needs to be encrypted further. The user gets the customer master key stored in the key management systems to encrypt the data key.
6. The data key is encrypted using the master key. Your master key is the key encryption key as it encrypts the data encryption key. Only the master key can encrypt multiple data keys, and it is securely stored in the key management systems, with restricted access.
7. The master key encrypts the data key, and encrypted data key store along with
   ciphered data in storage, where master key securely stores in key management system with restricted access.

If a user wants to decrypt data, then they first need a master key that has, in turn, an encrypted data encryption key. This master key can be stored in a separate access system such as a hardware security module (HSM) or software-based key management service provided by cloud providers such as AWS. Let's look into this in more detail.

Reference: Envelope encryption

KMS with EBS volume

Amazon EBS works with AWS KMS to encrypt and decrypt your EBS volume. You can encrypt both the boot and data volumes of an EC2 instance. When you create an encrypted EBS volume and attach it to a supported instance type, the following types of data are encrypted:

• At rest
  • Data at rest inside the volume
  • All snapshots created from the volume
  • All volumes created from those snapshots
• In-flight
  • All data moving between the volume and the instance

KMS with SQS

You can choose to have SQS encrypt messages stored in both Standard and FIFO queues using an encryption key provided by AWS Key Management Service (KMS).

KMS with System manager parameter store

With AWS Systems Manager Parameter Store, you can create SecureString parameters, which are parameters that have a plaintext parameter name and an encrypted parameter value.

Secure String parameters vs KMS

Secure String parameters - Only one API Call Parameter Store uses AWS KMS to encrypt and decrypt the parameter values* of Secure String parameters. *To retrieve the decrypted value you only need to do one API call.

KMS with SSM Parameter store - 2 API Calls If you encrypt first with KMS then store in SSM Parameter store, it requires two API calls to get the decrypted value which is not effiecient.

Share a CMK to users and roles in another account

To permit the usage of a CMK to users and roles in another account, you must use two different types of policies:

• Since Key policies are the primary way to control access to CMKs in AWS KMS, the key policy for the CMK must give the external account (or users and roles in the external account) permission to use the CMK.
• IAM policies in the external account must delegate the key policy permissions to its users and roles. These policies are set in the external account and give permissions to users and roles in that account.

KMS with CodeBuild

• Q: How to make the build artifacts to be automatically encrypted at the end?
• A: Specify a KMS key to use AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications.

For AWS CodeBuild to encrypt its build output artifacts, it needs access to an AWS KMS customer master key (CMK).

By default, AWS CodeBuild uses the AWS-managed CMK for Amazon S3 in your AWS account. The following environment variable provides these details: CODEBUILD_KMS_KEY_ID: The identifier of the AWS KMS key that CodeBuild is using to encrypt the build output artifact (for example, arn:aws:kms:region-ID:account-ID:key/key-ID or alias/key-alias).

KMS with Kinesis Data Streams

Server-side encryption is a feature in Amazon Kinesis Data Streams that automatically encrypts data before it's at rest by using an AWS KMS customer master key (CMK) you specify.

Data is encrypted before it's written to the Kinesis stream storage layer, and decrypted after it’s retrieved from storage. As a result, *your data is encrypted at rest * within the Kinesis Data Streams service. This allows you to meet strict regulatory requirements and enhance the security of your data.

KMS with CloudWatch log group

Log group data is always encrypted in CloudWatch Logs. You can optionally use AWS AWS Key Management Service for this encryption. If you do, the encryption is done using an AWS KMS (AWS KMS) customer master key (CMK). Encryption using AWS KMS is enabled at the log group level, by associating a CMK with a log group, either when you create the log group or after it exists.

To associate the CMK with an existing log group, you can use the associate-kms-key command. You can use the create-log-group command to associate the CMK with a log group when you create it.

Some other notes After you associate a CMK with a log group, all newly ingested data for the log group is encrypted using the CMK. This data is stored in an encrypted format throughout its retention period. CloudWatch Logs decrypts this data whenever it is requested. CloudWatch Logs must have permissions for the CMK whenever encrypted data is requested.

SSL

Based on its respective DB engine, configure the database to use SSL and use the root certificates which are readily available from AWS.

Root certificate

A root certificate that works for all regions can be downloaded from the AWS website. It is the trusted root entity and should work in most cases but might fail if your application doesn't accept certificate chains.

If your application doesn't accept certificate chains, download the AWS Region–specific certificate from AWS.

SSE-KMS vs SSE-S3

SSE-KMS is similar to SSE-S3 but comes with some additional benefits over SSE-S3. Unlike SSE-S3 you can create and manage encryption keys yourself or you can use a default CMK key that is unique to you for the service that is being used (S3 in this case) and the region you are working in.

When you create a CMK using KMS instead of using default CMK you get more flexibility as you can create, rotate and disable the encryption keys whilist with SSE-S3 everything are managed by AWS.

As KMS is integrated with Cloudtrail with SSE-KMS you can also audit the usage of the key like when, by whom, for what purpose the key was used whilist SSE-S3 does not provide the ability to audit trail the usage of the encryption keys. You can also give separate permissions for the use of an envelope key.