AWS Key Management Service (KMS)

Identifier	Guardrail	Rationale	Remediation	References	Policy	IAM Actions
IAM-KMS-1	Check that the root principal is included in the KMS Key Policy.	Key lockout will occur if there are no principals that have access to the key policy. For example, say only IAM users or IAM Roles or included in the key policy. If the IAM users and IAM Roles are either deleted or they are removed from the key policy, no principal has access to the key policy. Ensuring root is included on the key policy means that in exceptional circumstances the root user can reestablish delegation to the appropriate IAM Role. This is not recommending daily or frequent root usage, rather this root is included as a precautionary measure for exceptional circumstances. The AWS Account root user is included with all created AWS Accounts. Root user is superadmin and can’t be deleted.	Add root principal to key policy.	https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-root-enable-iam https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html	KMS Key Policy
IAM-KMS-2	Check that either only authorized principals or no principals can delete imported key material.	This is a potentially destructive action. Deletes key material that you previously imported. This operation makes the specified customer master key (CMK) unusable until the key material is reimported. All encrypted data is unreadable and unable to be decrypted until the customer reimports the exact same key material. A decision should be made if any break-glass roles should have this capability. These authorized roles should be whitelisted and all other rules should trigger a violation.	Permission kms:DeleteImportedKeyMaterial should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to delete imported key material.	https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys-delete-key-material.html	nan	kms:DeleteImportedKeyMaterial
IAM-KMS-3	Check that either only authorized principals or no principals can delete CMKs.	Deleting a CMK is a destructive and potentially dangerous operation. When a CMK is deleted, all data that was encrypted under the CMK is unrecoverable. Even in development this can be disruptive as there might be unnecessary downtime. The preventive control is to avoid ununauthorized capability of deleting CMKs. Relying on the 7 day waiting period and notificatons require appropriate detective controls.	Permission kms:ScheduleKeyDeletion should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to delete CMKs	https://docs.aws.amazon.com/kms/latest/APIReference/API_ScheduleKeyDeletion.html	nan	kms:ScheduleKeyDeletion
IAM-KMS-4	Check that either only authorized principals or no principals can disable CMKs.	If you disable a CMK, it cannot be used to encrypt or decrypt data until you re-enable it. This has immediate effectiveness. This could potentially incur downtime in a production environment. Even in development this can be disruptive as there might be unnecessary downtime.	Permission kms:DisableKey should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to disable CMKs.	https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html	nan	kms:DisableKey
IAM-KMS-5	Check that either only authorized principals or no principals can place a new KMS key policy.	Users with the PutKeyPolicy permission for a CMK can completely replace the key policy for a CMK with a different key policy of their choice.	Permission kms:PutKeyPolicy should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to put key policy.	https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf	nan	kms:PutKeyPolicy
IAM-KMS-6	Check that if an AWS Service requires access to CMKs (e.g., encryption at rest), to scope access to the specific AWS Service arn via kms:ViaService.	The kms:ViaService condition key limits use of an AWS KMS customer master key (https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys) (CMK) to requests from specified AWS services. You can specify one or more services in each kms:ViaService condition key.	Specify the kms:ViaService condition.	https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service	KMS Key Policy
IAM-KMS-7	Check that either only authorized principals or no principals can disable key rotation.	Disabling key rotation will prevent the CMK from automatic annual rotation.	Permission kms:DisableKeyRotation should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to disable CMKs.	https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html	nan	kms:DisableKeyRotation
IAM-KMS-8	Check for separation of duties regarding managing the key and cryptographic usage of the key.	Maintaining separation of duties for sensitive and confidential data for key management and cryptographic key usage helps reduce the risk of unauthorized administrative access to the data. In addition, having a dedicated cryptographic key usage role helps reduce the risk of accidental management misconfiguration to the keys.	Check that the key administrator and cryptographic key usage role maintain separate IAM actions for admin and usage. Examplekey admin hereandkey user here.		nan
IAM-KMS-9	Check that only authorized administrative Principals are allowed AWS KMS administrative permissions.	AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. It is important that access control to the management of your keys is only performed by authorized administrative key management administrators.	Verify that KMS administrative and modification permissions are explicitly denied to non-whitelisted Principals and that the KMS modification permissions don’t exist in an Allow statement for any unauthorized principal.	https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html	nan	kms:CancelKeyDeletion kms:ConnectCustomKeyStore kms:CreateAlias kms:CreateCustomKeyStore kms:CreateGrant kms:CreateKey kms:DeleteAlias kms:DeleteCustomKeyStore kms:DeleteImportedKeyMaterial kms:DisableKey kms:DisableKeyRotation kms:DisconnectCustomKeyStore kms:ImportKeyMaterial kms:PutKeyPolicy kms:RetireGrant kms:RevokeGrant kms:ScheduleKeyDeletion kms:TagResource kms:UntagResource kms:UpdateAlias kms:UpdateCustomKeyStore kms:UpdateKeyDescription