KMS

Solution Architect Associate

Developer Associate

Security Specialty

  • Managed service that makes it easy to create and control encryption keys
  • Uses Hardware Security Modules to protect the security of your keys.
  • KMS sits on multi-tenant hardware, CloudHSM is dedicated hardware to you
  • IAM is a global service, but Encrytpion keys are local to a region.
  • If a key is deleted, all data encrypted with that key is lost.
    • Keys can be immediately disabled, but there is a minimum wait time of 7 days to actually delete a key
    • As soon as a key is disabled/pending deletion, objects encrypted with this key are no longer accessible * Finally as soon as a key is deleted, any data encrypted with that key is unrecoverable.
  • You can grant another AWS account an ability to use a KMS key
  • If you make an object in S3 public, whether people have access depends on:
    • If encrypted with KMS and the user has the key, they can sign the request using AWS Signature v4 signing
    • If encrypted with S3 Encryption, users will have access to the public object
    • If a user has full admin access they will not be able to access the public S3 url, but they CAN open and download encrypted files. This is why its so important to limit who has full admin level access
    • If a user has the SystemsAdministrator managed policy, they will not be able to open files encrypted. You probably want to ensure that your AWS infrastructure admins are SystemsAdministrators not full AdministratorUsers
  • Keys can be generated directly by KMS, or imported from a 3rd party source
    • You first create a new key and select that you’re going to import a key material from an external source
    • You then create the key like usual, and at the end you are able to choose a wrapping algorithm. This wrapping key is only good for 24 hours. Download the import token.
    • The key material can be generated using a tool like OpenSSL, or another 3rd party provider.
    • You return to the AWS console and upload the encrypted key material, as well as the import token from above
  • Important note: You cannot re-use the same Import Token twice to generate a duplicate key.
    • You also cannot enable automatic key rotation if you are using Customer Master Keys.
    • **You can manually rotate the key, but you have to import the new key material into a new Customer Master Key and then rotate all of the data that uses it **
    • Also, ciphertexts are not portable between CMKs.
  • For customer generated master keys, you will be able to delete the key material immediately. Doing this technically bypasses the 7 day delete waiting period for data to be un-recoverable
  • The Customer Master Key consists of the following:
    • Alias (name of key)
    • Creation Date
    • Description
    • Key State (basically a status)
    • Key Material
  • You can NEVER export a customer master key
  • Two Types of CMKs
    • AWS Managed CMK for each service that integrates with KMS
    • You can create your own Customer Managed CMK that you generate by providing the Key Material during key creation
  • Why import your own key material?
    • Compliance requirements, prove an amount of randomness
    • Extend your existing processes to AWS (i.e. lift and shift)
    • To be able to delete key material without a 7-30 day wait
    • To be resilient to AWS failure by storing keys outside AWS
  • Considerations for Imported Key Materials
    • Availablity and durability are different - You are responsible for re-uploading key material if a key needs to be re-created due to outage/disaster
    • Secure Key Generation is up to you
    • No automatic rotation
    • Ciphertexts are not portable between CMKs
  • Read the AWS KMS FAQ Page!!!
  • Read the AWS White Paper on KMS Best Practices!!!
  • You cannot import a Public Key into KMS, you must create a key using a Key Material Origin.
    • Also, you cannot import a Key Pair into EC2 from KMS because you don’t have a public key
    • You can only use Cloud HSM for this, or you must manually control these keys outside AWS

KMS Key Rotation Options

  • Extensive re-use of encryption keys is not recommended
  • It is best practice to rotate keys on a regular basis
  • The frequency of key rotation is dependent upon local laws, regulations, or corporate policies
  • The method of rotation differs depending upon the type of key you’re using

AWS Managed Keys

  • Simplest option. By default this is done automatically every 3 years for you
  • When the CMK is due for rotation, a new backing key is created and marked as active for all new requests
  • The old key remains available so you can decrypt any existing ciphertext files

Customer Managed Keys (within AWS)

  • Can be configured to rotate automatically once per year, but this is disabled by default
  • The old backing key is saved so you can decrypt existing ciphertext files
  • You can also manually rotate your CMKs any time you’d like
  • Remember, if you delete a CMK you won’t be able to recover data encrypted by that key

Customer Managed Keys (Customer Provided)

  • Automatic key rotation is not available
  • You must rotate keys manually, and is a similar process to creating keys this way
  • You are in complete control of this rotation, but remember if you delete a CMK you won’t be able to recover data encrypted by that key

Using KMS with EBS

  • Once you provision a volume that’s attached to EC2 and encrypt it using KMS, that volume is always attached to that key.
    • You cannot snapshot it without encryption
    • You cannot change it to unencrypted
  • In order to encrypt a root volume for an EC2 instance: KNOW THIS!!!
    • Stop the instance and create a snapshot of the root volume
    • Deploy the snapshot as an AMI
    • Once the AMI is created, the image can then be made public or shared with another account
    • Then you copy the AMI, and during the copy process you have the ability to encrypt the AMI
      • You can choose the Customer Master Key that you’d like to
  • You can change the encryption type on an EBS volume, but you have to make a copy of the volume to do this

KMS Grants

  • Grants are an alternative access control mechanism to using a key policy
  • Allow you to programatically delegate the use of KMS CMKs to other AWS principals (i.e. another user)
  • Temparary, granular permissions can be granted (encrypt, decrypt, etc.)
  • Grants allow access only, not a deny
  • Use Key Policies for relatively static permissions, and for explicit denies. You can set up grants for tempoarary support needs
  • Grants are configured programitcally using the AWS CLI
    • create-grant: adds a new grant to the CMK and specifies who can use it and what they can do
    • list-grants: lists all grants for the CMK
    • revoke-grant: remove a previously created grant
  • When you create a grant, you get a grant token that can be passed to the KMS API

Key Policy Conditions - ViaService (KNOW THIS FOR THE EXAM)!!!

  • Policy conditions can be used to specifiy conditions within a Key Policy or an IAM Policy. This condition must be true for the policy to take effect
  • Ex: You may want a policy to take effect after a certain date
  • The most important one to know is kms:ViaService
    • Limits the use of a KMS key to requests that are from a particular service
  • Ex) Limit use of a key to EC2 and RDS in US West 2 Region:
"Condition": {
  "StringEquals": {
    "kms:ViaService": [
      "ec2.us-west-2.amazonaws.com",
      "rds.us-west-2.amazonaws.com"
    ]
  }
}

Cross Account Access to KMS CMKs

  • If you want to enable another account to encrypt/decrypt using your CMK you need to enable cross-account access
  • 2 Steps to take to get this to work:
    • Enable access in the Key Policy for the account which owns the CMK
    • Enable access to the KMS in the IAM Policy for the external account
< Previous: Inspector Next: Macie >