According to AWS, Security is “job zero”. At DigitalCloudAdvisor, we embrace that principle from the heart and believe that security comes at the top of our priorities. Whether we think of the servers, applications, data, or users’ permissions, we follow best practices around Security straight from AWS itself. In this Case Study, I will expand on how to protect your AWS data using KMS.
AWS Key Management Service (KMS) is a managed service that enables you to easily encrypt your data using strong encryption algorithms. The service uses Hardware Security Modules (HSMs) that are FIPS 140-2 FIPS validation – AWS CloudHSM (amazon.com) validated. The service also provides key management capabilities, including rotating and managing encryption keys. Other AWS services can also use KMS keys for encryption, making integrating KMS into your existing AWS workflow easy. AWS KMS allows you to secure your data and meet compliance requirements while reducing the operational burden of managing encryption keys.
KMS Keys are the primary resource in AWS KMS and represent a logical representation of a cryptographic key. Each KMS Key contains metadata such as the Key ID, key specification, key usage, creation date, description, and key state. It also references the key material used when performing cryptographic operations with the key. It is important to note that the key material for a KMS Key never leaves AWS KMS unencrypted, providing an additional layer of security.
AWS KMS keys can be used to perform various cryptographic operations such as encrypting, decrypting, and re-encrypting data. Additionally, KMS can generate data keys that can be used outside the KMS service, allowing you to use them to encrypt data in other systems. It also provides additional functionality, such as key rotation, which allows you to easily change your encryption keys on a regular basis, enhancing the security of your data.
With AWS KMS, you have the ability to generate three types of keys: customer-managed keys, AWS-managed keys, and AWS-owned keys.
- Customer-managed keys are keys that you create and manage within your AWS account. You have full control over these keys and can use them for various cryptographic operations.
- AWS-managed keys are keys created by AWS services within your account but managed by AWS. These keys are typically used by AWS services that encrypt data by default, but you can also use them for your cryptographic operations.
- AWS-owned keys are created and managed by AWS services in a service account rather than in your account. These keys are typically used by AWS services that encrypt data by default, but you cannot access or manage these keys.
Different AWS services that integrate with AWS KMS differ in their support for KMS keys. Some services encrypt your data by default with an AWS-owned or AWS-managed key, while others support customer-managed keys. Some services support all types of keys, allowing you to choose the level of control and visibility you want.
What is key rotation?
When automatic rotation happens, optionally for the customer-managed keys, the rotation only changes the key material used for encryption; the KMS key remains the same.
Usually, companies use symmetric encryption, but you can create and use asymmetric encryption using AWS KMS as well. Asymmetric encryption is also known as public key cryptography, and that refers to this: any messages encrypted with a public key can only be decrypted with a private key; likewise, any messages encrypted with a private key can only be decrypted with a public key. As you probably realised, only one key is used for encryption and decryption when discussing symmetric encryption. Ok, but when you choose one against the other. Well, depends on your business compliance requirements.
Returning to the primary resource of the KMS, the keys have some quotas. Firstly, a KMS key can encrypt data up to 4KB in size, but a KMS key can generate, encrypt and decrypt what is known as Data Encryption Keys or DEK. We will go deeper into the DEKs later on. Other quotas as for now on the KMS keys are the following: you can manage 100000 KMS keys in your account, and this can be adjustable; you can create 50 aliases per KMS key per account, and this can also be adjustable; the Key policy document size can be up to 32KB and is not adjustable; you can have 50000 grants per KMS key, and that is adjustable.
So, as you should already know by now, in order to encrypt big data, you need to generate a DEK.
The most important aspect to understand is the Data Encryption Keys (DEKs) in AWS KMS. DEKs are used to encrypt and decrypt your data outside of the KMS service. KMS does not store, manage, or track your data keys or perform cryptographic operations with them.
AWS KMS supports the Generate Data Key without plaintext operation, which returns only an encrypted version of the data key. When you need to use the data key, you can ask KMS to decrypt it. After using the plaintext data key to encrypt data, removing it from memory as soon as possible is important to minimize the risk of the key being compromised.
You can store the encrypted data key with the encrypted data so it is available to decrypt the data later. This allows you to separate the key management from the encryption and decryption of the data, making it more secure.
So far, all sounds good, but…
What if a key becomes unusable due to an accident or malicious action?
This can significantly impact your ability to decrypt and access your data.
When a KMS key is disabled, scheduled for deletion, or its key material is deleted, the effect on the data keys encrypted by that KMS key and on data encrypted by the data key is delayed until the KMS key is used again. For example, if a key is scheduled for deletion, the key cannot be used to decrypt the data key and access the data until the key is reactivated or a new key is used to decrypt the data key.
It’s very important to have a plan in place to handle such scenarios, such as regularly backing up the key material and storing it in a secure location and having a plan to recover the key material in case of an emergency. AWS KMS also provides features to help protect keys from accidental deletion or disablement, such as key policies, rotation, and archiving. And it’s also important to have a disaster recovery plan in place in case of a key loss, and to regularly test the plan to ensure that it is effective.
It’s also important to have access controls in place, limit the number of people who can disable or delete keys, and monitor key usage and access to detect suspicious activity.
AWS KMS also provides CloudTrail to audit all API calls made on the KMS service. This can be useful for detecting suspicious actions and investigating potential security issues.
As we explore the different types of keys we can use in KMS, let’s examine how permissions work in KMS. AWS Identity and Access Management (IAM) helps an administrator securely control access to AWS resources. IAM administrators control who can be authenticated (signed in) and authorized (have permissions) to use AWS KMS resources.
Key policies are the primary mechanism for controlling access to KMS keys in AWS KMS. Every KMS key must have a key policy. You can also use IAM policies, grants, and key policies to control access to your KMS keys.
If you are using an Amazon Virtual Private Cloud (Amazon VPC), you can create an interface VPC endpoint to AWS KMS powered by AWS Private Link. You can also use VPC endpoint policies to determine which principals can access your AWS KMS endpoint, which API calls they can make, and which KMS key they can access.
Speak with us today to find out how DigitalCloudAdvisor can help you encrypt your data.
