AWS Key Management Service
Using AWS KMS, generate and maintain cryptographic keys to protect your data. AWS Key Management Service is linked to the majority of AWS data encryption services. AWS KMS also integrates with AWS CloudTrail to log how your KMS keys are being used for auditing, regulatory, and compliance purposes.
The primary resource in AWS Key Management Service are AWS KMS keys, which are logical representations of cryptographic keys. There are three primary types of KMS keys:
- Customer managed keys are KMS keys that you generate.
- AWS managed keys are KMS keys generated in your account by AWS services on your behalf.
- AWS owned keys are KMS keys that can be used across multiple AWS accounts and are owned and controlled by an AWS service.
In the AWS Cloud, policies are used to control who can access resources and services. Resource-based policies, for example, link to a resource, such as an S3 bucket, and define supported actions, whose principals are allowed access, and any other conditions that need to be met. Permissions for users, groups, and roles are determined by identity-based policies in AWS Identity and Access Management. AWS Key Management Service policies limit key access, just like IAM policies do. Every KMS key must have a key policy, and each key may only have one key policy. The following should be considered when drafting policies that allow or forbid access to KMS keys:
- You have direct control over the key policy for customer-controlled keys, but not for AWS-owned or managed keys.
- Granular access to AWS Key Management Service API calls is made possible by key policies within an AWS account. Access to a KMS key cannot be granted via IAM policies unless the key policy expressly allows it. Permission-granting IAM policies are useless without the primary policy's approval.
- You can use an IAM policy to block access to a customer-managed key without the matching consent of the key policy.
- When developing key policies and IAM policies for multi-region keys, keep the following in mind:
- Key policies do not share characteristics with other multi-Region keys, nor are they copied or synchronized among related multi-Region keys.
- When a multi-Region key is created using the CreateKey and ReplicateKey actions, the default key policy is applied unless a key policy is specified in the request.
- Condition keys such as aws: RequestedRegion can be used to limit rights to a particular AWS Region.
- Grants can be used to grant access to a multi-Region primary key or replica key. A single grant cannot be used to grant permissions to more than one KMS key, even though they are related multi-Region keys.
When using AWS Key Management Service and creating key policies, the following encryption best practices as well as other security best practices should be considered:
Observe the guidance provided in the following AWS Key Management Service best practices materials:
Best practices for AWS Key Management Service grants (AWS KMS documentation)
Best practices for IAM policies (AWS KMS documents)
In accordance with the best practices for division of duties, keep the identities of those who handle keys and those who use them separate:
Administrator roles that create and remove keys shouldn't be able to use the key.
Certain services may only need to encrypt data; they shouldn't be permitted to decode it using the key.
Important policies should always be governed by the least privilege principle. Kms: should not be used for IAM or key policy activities since it gives the principal the power to manage and use the key.
To limit the use of customer-managed keys to specific AWS services, use the kms: ViaService condition key in the key policy.
If you have a choice between key types, customer managed keys are advised since they provide the most comprehensive control options, including the following:
Supervising authentication and access control
Keys to activate and deactivate
Altering the keys for AWS KMS
Tag keys
Creating aliases
Eliminating AWS KMS keys
No unauthorized principal should have AWS KMS modification permissions specified in an allow statement, and unauthorized principals must be expressly barred from administration and modification permissions for AWS Key Management Services.
To find instances of illegal usage of KMS keys, use the iam-customer-policy-blocked-kms-actions and iam-inline-policy-blocked-kms-actions rules in AWS Config. This prevents principals from using the decryption operations on any resource provided by the AWS Key Management Service.
Use service control policies (SCPs) in AWS Organizations to prevent unauthorized users or roles from destroying KMS keys directly via a command or the terminal.
Keep a CloudTrail log of all calls to the AWS Key Management Service API. This records the relevant event properties, such as the requests made, the requester, and the originating IP address.
If encryption is being employed, sensitive information shouldn't be included. CloudTrail stores the encryption context in plaintext JSON files that are accessible to anyone with access to the S3 bucket containing the data.
Set up events to notify you when specific actions, such as generating a key, altering customer managed key policies, or importing key material, are observed when monitoring the usage of customer managed keys. It is also recommended to use automated solutions, such as an AWS Lambda function that disables the key or does any other incident response tasks outlined in your company policy.
Multi-region keys are recommended for specific scenarios, such as compliance, disaster recovery, or backups. Multi-region keys have significantly different security features than single-region keys. The following rules should be adhered to while authorizing the development, management, and usage of multi-Region keys:
A multi-region key should only be allowed to be duplicated into AWS regions that require it.
Only allow multi-region keys to principals and jobs that explicitly need them.
0 Comments