 |
TL;DR
AWS KMS makes securing your information easy(ier) by abstracting the availability, physical security, and maintenance concerns of cryptographic implementations. Thanks to a first class integration in AWS you can benefit from tight integrations with the rest of the services they provide, all while providing exceptional logging to help meet compliance requirements. Have Amazon generate a key, or bring your own material. Use a customer master key to encrypt data blocks of up to 4KB or use envelope encryption to encrypt a data key which can protect data of any size.
KMS Introduction
AWS KMS simplifies encrypting your data by managing the creation and control of encryption keys and protects them using Hardware Security Modules. Want to know more about the security details? Read the AWS Key Management Service Cryptographic Details white paper.
This paper is organized based on the Cloud Adoption Framework Security Perspectives including Identity and Access Management (who can do things), Detective Controls (what is happening in your system), Infrastructure Security (shape your security policies for your needs), Data Protection (see what is encrypted and clean up what isn’t), and Incident Response.
Identify and Access Management
A salient point here is that there are different types of policies. Identity policies control resources in IAM like users, groups, and roles. Resource policies are policies attached directly to resources like S3 buckets or any other resource outside of IAM.
Identity (IAM) Policies
IAM policies alone can’t give access to a Customer Master Key but can be used in combination with a CMK policy. You can use IAM policies to enforce principles of least privilege, and remember that the policies are denied by default.
Resource (Key) Policies
AWS recommends updating the default CMK policy to apply to your org’s practice for least privilege because by default it enables any principals defined, AND the root user of the account to add IAM policies to reference the key. Requests to use an encrypted resource will be denied if the user hasn’t been granted permission to use both the resource and the encryption key. CMK’s can be restricted to specific services using `kms:ViaService` in the policy.
Protips:
- Be sure you understand policy statement evaluation because CMK policies are joined with IAM policies if you’ve enabled IAM access.
- Never include `kms:*` permissions in an IAM policy. This will allow an escalation of privileges.
- Explicit deny policies take precedence over implicit deny policies.
Sharing Keys Across Accounts
There are basically two options for sharing keys across accounts. The first pushes the complexity on the secondary account, the second takes the management complexity on the primary account.
- Include the root principal ARN of the secondary account inside the CMK key policy. Then delegate responsibility further throughout that account as needed.
- Manage permissions on all authorized users in the KMS key policy itself.
Encryption Context
Use the encryption context argument as an added layer of authentication for KMS API calls. This is an argument that you can configure as a conditional in the KMS policy. It is not encrypted and should not be considered sensitive.
This adds an extra layer of security because now the parties need to have IAM permissions, a policy that allows them to use the key, and also know the encryption context.
Multi-Factor Authentication (MFA)
You should require MFA at the policy level on all mission critical AWS API calls, but especially KMS. You can implement it for PutKeyPolicy, ScheduleKeyDeletion, DeleteAlias, and DeleteImportedKeyMaterial.
Auditing
If there’s one thing KMS has down, it’s auditability. Auditing requirements vary dramatically so be sure to comply with local regulations, but KMS makes it fairly easy with tight integrations with CloudTrail. Enable CloudTrail logging and all KMS API calls and Events will be logged and you can act on them accordingly with other services like Lambda and SNS.
Infrastructure Security
With AWS KMS, keys start with a customer master key. Those can encrypt up to 4KB of data, or they can be used as an envelope key and secure any size.
Customer managed customer master keys (that’s a mouthful) are generated by you, rotated yearly or on-demand, and can be deleted on demand.
Amazon managed customer master keys are generated by AWS and rotated every three years automatically. They cannot be deleted and are limited to specific AWS services.
You can only search keys cross account if the principal has explicit List* permissions AND via the CLI or SDK – not through the console.
Aliasing Keys
Key Aliases are to keys like DNS is to IP addresses – they abstract the users away from region specific ID’s and ARN’s. This allows multi-region apps to use the same alias to refer to keys in multiple regions without knowing the ID’s or ARN’s.
Aliases can’t be used in policies because they would allow for an escalation of privileges as the mapping of aliases to keys is done outside of the individual policies.
Envelope Encryption
AWS considers it a best practice to use at least 1 CMK per class of data. This defines a granular data control policy down to the key. They also recommend using envelope encryption to scale. Use the SDK to make this easier.
Data Protection Use Cases
Some common use cases include encrypting PCI data (KMS meets PCI DSS Level 1 certification), managing secrets in S3 by using prefix level bucket policies, encrypt Lambda environment variables (use the checkbox provided), encrypt data in the Parameter Store, and enforce data at rest encryption by enforcing S3 bucket policy encryption or EBS encryption.
Incident Response
Use CloudTrail, SNS, and Lambda to your advantage and take action on events and logs as needed. It’s recommended that this be automated and not require human intervention wherever possible.
It is possible to delete keys, but much preferred to disable them. Deleting an Amazon managed CMK is irreversible, and accordingly has a 7 day waiting period. You can delete a Customer Managed CMK immediately, but won’t be able to decrypt anything until you re-upload the key.
Conclusion
Security and encryption shouldn’t be taken lightly. Though it’s a bit of a dense read, definitely go through the original whitepaper for all of the best practices and recommendations when implementing your own key management.