AWS Key Management Service Best Practices For Encryption
AWS Key Management Service
Create and manage cryptographic keys to safeguard your data with AWS KMS. Most AWS data-encrypting services are connected with AWS Key Management Service. To record the usage of your KMS keys for auditing, regulatory, and compliance purposes, AWS KMS also connects with AWS CloudTrail.
AWS KMS keys, which are logical representations of cryptographic keys, are the main resource in AWS Key Management Service. KMS keys come in three main varieties:
KMS keys that you create are known as customer managed keys.
KMS keys created in your account by AWS services on your behalf are known as AWS managed keys.
KMS keys that are owned and managed by an AWS service and can be used across several AWS accounts are known as AWS owned keys.
Policies are used in the AWS Cloud to manage who has access to resources and services. For instance, resource-based policies link to a resource, like an S3 bucket, and specify which principals are permitted access, supported actions, and any other requirements that must be fulfilled. In AWS Identity and Access Management, identity-based policies determine user, group, and role permissions. Like IAM policies, AWS Key Management Service policies restrict key access. There must be a key policy for every KMS key, and each key may only have one key policy. When creating policies that grant or prohibit access to KMS keys, keep the following in mind:
For customer-controlled keys, you have direct control over the key policy; however, this is not the case for AWS-owned or managed keys.
Within an AWS account, key policies enable granular access to AWS Key Management Service API calls. You cannot use IAM policies to grant access to a KMS key unless specifically permitted by the key policy. IAM policies that provide permissions are ineffective without the main policy’s consent.
Without the key policy’s matching consent, you can use an IAM policy to prevent access to a customer-managed key.
Take into account the following while creating key policies and IAM policies for multi-region keys:
Key policies are neither duplicated or synced among related multi-Region keys, nor are they shared attributes of multi-Region keys.
Unless a key policy is given in the request, the default key policy is used when a multi-Region key is produced using the CreateKey and ReplicateKey actions.
To restrict permissions to a specific AWS Region, you can use condition keys like aws: RequestedRegion.
Permissions to a multi-Region main key or replica key can be granted via grants. Even though they are related multi-Region keys, a single grant cannot be utilized to provide permissions to more than one KMS key.
The following encryption best practices and other security best practices should be taken into account while utilizing AWS Key Management Service and developing key policies:
Follow the advice in the AWS Key Management Service best practices materials listed below:
AWS Key Management Service grant best practices (AWS KMS documentation)
IAM policy best practices (AWS KMS docs)
Keep the identities of individuals who administer keys and those who use them distinct in compliance with the best practice for separation of duties:
The key shouldn’t be usable by administrator roles that create and remove keys.
Some services might just need to encrypt data; they shouldn’t be allowed to use the key to decode it.
The least privilege principle should always be applied to important policy. Because it grants the principal authority to administer and use the key, kms: should not be used for actions in IAM or key policies.
Use the kms: ViaService condition key in the key policy to restrict the use of customer-managed keys to particular AWS services.
Customer managed keys are recommended if you have a choice between key types since they offer the most detailed control choices, such as the following:
Overseeing access control and authentication
Keys that enable and disable
Changing the AWS KMS keys
Keys for tagging
Making aliases
Getting rid of AWS KMS keys
Unauthorized principals must be specifically excluded from AWS Key Management Service administrative and modification permissions, and no unauthorized principal should have AWS KMS modification permissions listed in an allow statement.
Use the iam-customer-policy-blocked-kms-actions and iam-inline-policy-blocked-kms-actions rules in AWS Config to identify instances of unlawful use of KMS keys. Principals are unable to use the AWS Key Management Service decryption actions on any resource as a result.
To stop unauthorized users or roles from deleting KMS keys directly through a command or the terminal, implement service control policies (SCPs) in AWS Organizations.
Record calls to the AWS Key Management Service API in a CloudTrail log. This logs the pertinent event properties, including the requests made, the originating IP address making the request, and the requester.
Sensitive information shouldn’t be included if encryption is being used. Anyone with access to the S3 bucket holding the data can examine the plaintext JSON files that CloudTrail uses to store the encryption context.
When keeping an eye on how customer managed keys are being used, set up events to alert you when certain actions like creating a key, updating customer managed key policies, or importing key material are noticed. Automated responses, like an AWS Lambda function that disables the key or carries out any other incident response activities specified by your business policy, are also advised.
For certain situations, such compliance, disaster recovery, or backups, multi-region keys are advised. Compared to single-region keys, multi-region keys have substantially different security characteristics. When approving the creation, administration, and use of multi-Region keys, the following guidelines should be followed:
Principals should only be permitted to duplicate a multi-region key into AWS regions that need it.
Permit multi-region keys only for jobs that require them and only for principals who need them.
Read more on Govindhtech.com
