KMS

Subdecks (1)

Cards (65)

  • AWS KMS (Key Management Service)
    • Easy way to control access to your data, AWS manages keys for us
    • Fully integrated with IAM for authorisation
    • Seamlessly integrated into:
    • • Amazon EBS: encrypt volumes
    • • Amazon S3: Server-side encryption of objects
    • • Amazon Redshift: encryption of data
    • • Amazon RDS: encryption of data
    • • Amazon SSM: Parameter store
    • • Etc...
    • But you can also use the CLI / SDK
  • KMS – KMS KeyTypes: Symmetric (AES-256 keys)
    First offering of KMS, single encryption key that is used to Encrypt and Decrypt
    • AWS services that are integrated with KMS use Symmetric KMS keys
    • Necessary for envelope encryption
    • You never get access to the KMS key unencrypted (must call KMS API to use)
  • KMS – KMS KeyTypes: Asymmetric (RSA & ECC key pairs) - Latest offering
    • Public (Encrypt) and Private Key (Decrypt) pair
    • Used for Encrypt/Decrypt, or Sign/Verify operations
    • The public key is downloadable, but you can’t access the Private Key unencrypted
    • Use case: encryption outside of AWS by users who can’t call the KMS API
  • Types of KMS Keys: Customer Managed Keys
    Create, manage and use, can enable or disable
    • Possibility of rotation policy (new key generated every year, old key preserved)
    • Can add a Key Policy (resource policy) & audit in CloudTrail
    • Leverage for envelope encryption
  • Types of KMS Keys: AWS Managed Keys
    • Used by AWS service (aws/s3,aws/ebs,aws/redshift)
    Managed by AWS (automatically rotated every 1 years)
    • View Key Policy & audit in CloudTrail
  • Types of KMS Keys: AWS Owned Keys
    Created and managed by AWS, use by some AWS services to protect your resources
    • Used in multiple AWS accounts, but they are not in your AWS account
    • You can’t view, use, track, or audit
  • Types of KMS Keys
  • KMS Key Material Origin
    Identifies the source of the key material in the KMS key. Can’t be changed after creation.
    KMS (AWS_KMS) – default
    • AWS KMS creates and manages the key material in its own key store.
    External (EXTERNAL)
    • You import the key material into the KMS key.
    • You’re responsible for securing and managing this key material outside of AWS.
    Custom Key Store (AWS_CLOUDHSM)
    • Another option is to use a custom key store, called AWS CloudHSM. Allows you to create the key material directly within your HSM cluster and manage the key material there.
  • KMS Key Source – Custom Key Store (CloudHSM)
    Integrate KMS with CloudHSM cluster as a Custom Key Store.
    • Key materials are stored in a CloudHSM cluster that you own and manage.
    • The cryptographic operations are performed in the HSMs.
    Use cases:
    • You need direct control over the HSMs.
    • KMS keys needs to be stored in a dedicated HSMs.
  • KMS Key Source - External
    • Import your own key material into KMS key, Bring Your Own Key (BYOK).
    You’re responsible for key material’s security, availability, and durability outside of AWS.
    • Must be 256-bit Symmetric key (Asymmetric is NOT supported).
    Can’t be used with Custom Key Store (CloudHSM).
    Manually rotate your KMS key (Automatic Key Rotation is NOT supported).
  • KMS Multi-Region Keys.
    • A set of identical KMS keys in different AWS Regions that can be used interchangeably (~ same KMS key in multiple Regions).
    Encrypt in one Region and decrypt in other Regions (No need to re-encrypt
    or making cross-Region API cals).
    • Multi-Region keys have the same key ID, key material, automatic rotation,...
    • KMS Multi-Region are NOT global (Primary + Replicas).
  • KMS Multi-Region Keys.

    • Each Multi-Region key is managed independently.
    • Only one primary key at a time, can promote replicas into their own primary.
    • Use cases: Disaster Recovery, Global Data Management (e.g, DynamoDB Global Tables), Active-Active Applications that span multiple Regions, Distributed Signing applications, etc.
    • To have a global client-side encryption to be able to encrypt client-side in one Region and to decrypt client-side in another Region.
  • KMS Multi-Region Keys
    It's not recommended to use Multi-Region key, except in very specific use cases because KMS likes to have the fact that a key is bounded to a single Region.
  • DynamoDB Global Tables and KMS Multi-Region Keys Client-Side encryption.
    • We can encrypt specific attributes client-side in our DynamoDB table using the Amazon DynamoDB Encryption Client. Only available to specific clients, not even to DBAs.
    • Combined with Global Tables, the client-side encrypted data is replicated to other regions.
  • DynamoDB Global Tables and KMS Multi-Region Keys Client-Side encryption.
    • If we use a multi-region key, replicated in the same region as the DynamoDB Global table, then clients in these regions can use low- latency API calls to KMS in their region to decrypt the data client-side.
    • Using client-side encryption we can protect specific fields and guarantee only decryption if the client has access to an API key.
  • Global Aurora and KMS Multi-Region Keys Client-Side encryption.
    • We can encrypt specific attributes client-side in our Aurora table using the AWS Encryption SDK.
    • Combined with Aurora Global Tables, the client-side encrypted data is replicated to other regions.
  • Global Aurora and KMS Multi-Region Keys Client-Side encryption.
    • If we use a multi-region key, replicated in the same region as the Global Aurora DB, then clients in these regions can use low-latency API calls to KMS in their region to decrypt the data client-side.
    • Using client-side encryption we can protect specific fields and guarantee only decryption if the client has access to an API key, we can protect specific fields even from DBAs.
  • How does KMS work?
    AWS KMS is replacing the term customer master key (CMK) with AWS KMS key and KMS key. The concept has not changed.
  • Envelope Encryption
    • KMS Encrypt API call has a limit of 4 KB
    • If you want to encrypt >4 KB, we need to use Envelope Encryption
    • The main API that will help us is the GenerateDataKey API
  • *** Envelope Encryption ***
    GenerateDataKey API
    A) When GenerateDataKey API, both types sent
  • *** Envelope Encryption ***
    Decrypt envelope data
  • Encryption SDK
    • The AWS Encryption SDK implemented Envelope Encryption for us
    • The Encryption SDK also exists as a CLI tool we can install
    • Implementations for Java, Python, C, JavaScript
  • Encryption SDK
    Feature - Data Key Caching:
    re-use data keys instead of creating new ones for each encryption.
    • Helps with reducing the number of calls to KMS with a security trade-off.
    • Use LocalCryptoMaterialsCache (max age, max bytes, max number of messages that should be encrypted)
  • KMS Symmetric – API Summary (Endpoints)
    Encrypt: encrypt up to 4 KB of data through KMS.
    Decrypt: decrypt up to 4 KB of data (including Data Encryption Keys)
    GenerateRandom: Returns a random byte string
  • KMS Symmetric – API Summary (Endpoints)
    GenerateDataKey: generates a unique symmetric data key (DEK).
    • returns a plaintext copy of the data key.
    • AND a copy that is encrypted under the CMK that you specify.
  • KMS Symmetric – API Summary (Endpoints)
    GenerateDataKeyWithoutPlaintext:
    • Generate a DEK to use at some point (not immediately)
    • DEK that is encrypted under the CMK that you specify (must use Decrypt later)
  • KMS Automatic Key Rotation
    • AWS-managed KMS Keys: automatically rotated every 1 year.
    • For Customer-Managed KMS Key.
    • • Automatic key rotation is optionally enabled, will happen every 1 year.
    • • Previous key is kept active so you can decrypt old data.
    • • New Key has the same KMS Key ID (only the backing key is changed).
  • KMS Manual Key Rotation
    (for Customer-Managed KMS Key and Imports)
    • When you want to rotate key every 90 days, 180 days, etc...
    New Key has a different KMS Key ID.
    • Keep the previous key active so you can decrypt old data.
    • Better to use aliases in this case (to hide the change of key for the application).
    • Good solution to rotate KMS Key that are not eligible for automatic rotation (like asymmetric CMK).
  • KMS Key Deletion
    Generated Keys (from within KMS)
    • No expiration date.
    • Cannot be deleted immediately, mandatory 7 to 30 days waiting period.
    • • You can cancel key deletion during the waiting period.
    • • During the waiting period, the KMS Key cannot be used for Encrypt / Decrypt.
    • • Everything will be deleted at the end of the waiting period.
    • You may manually disable it immediately instead (to re-enable it later).
  • KMS Key Deletion
    Imported Keys:
    • You may set an expiration period on the Key.
    • KMS will delete the key material.
    • You can also delete the key material on demand.
    • The metadata is kept so you can re-import in the future.
    • You may manually disable it and schedule for deletion (everything is deleted).
    AWS managed keys or AWS owned keys cannot be deleted.
  • KMS Key Deletion – CloudWatch Alarm
    (How can we detect a key that is being deleted if being used?)
    • Use CloudTrail, CloudWatch Logs, CloudWatch Alarms and SNS to be notified when someone tries to use a CMK that’s ”Pending deletion” in a cryptographic operation (Encrypt, Decrypt, ...)
  • KMS Key Deletion – Notifications
    • To be notified of Keys being deleted or disabled.
    • Using CloudTrail + EventBridge.
    A) When you know never want to delete any KMS keys.
  • KMS Multi Region Key Deletion
    Deleting Replica Key
    Less risky, can always be re-created from the Primary Key (if it exists).
    • Must be scheduled (7 to 30 days).
  • KMS Multi Region Key Deletion
    Deleting Primary Key
    • Cannot happen until all Replicas have
    • If you want to delete a Primary Key but keep Replicas, promote another one as Primary and then delete the “old Primary Key”
    • Must be scheduled (7 to 30 days after the replicas are deleted)
    if you delete first replicas and then you delete the primary key, you have a minimum waiting period of 14 days in total.
  • KMS - What type of KMS key is used for encrypting very large volumes of data?
    Data Encryption Keys (DEKs). A KMS key can generate, encrypt and decrypt DEKs
  • Automatic key rotation is supported only on what type of KMS encryption keys?
    Symmetric - with key material that AWS KMS generates (Origin = AWS_KMS)
  • KMS Keys - Automatic rotation generates new key material every year (optional for customer managed keys). Does the key change?
    No. The Key ID remains the same, only its material changes so no need to change the code
  • What types of KMS keys do NOT support automatic key rotation, but CAN be rotated manually?
    Asymmetric KMS keys, KMS keys in custom key stores (CloudHSM), KMS keys with imported key material, HMAC KMS keys
  • For manual KMS key rotation, do you need to change your app code?
    Manual rotation is creating a new KMS key with a different key ID, so does need updating, unless an Alias is used