Least Privilege / Separation of Duties - AWS Key Management Service Best Practices

Least Privilege / Separation of Duties

Key policies specify a resource, action, effect, principal, and conditions to grant access to CMKs. Key policies allow you to push more granular permissions to CMKs to enforce least privilege. For example, an application might make a KMS API call to encrypt data but there is no use case for that same application to decrypt data. In that use case, a key policy could grant access to the kms:Encrypt action but not kms:Decrypt and reduce the possibility for exposure. Additionally, AWS allows you to separate the usage permissions from administration permissions associated with the key. This means that an individual may have the ability to manipulate the key policy, but might not have the necessary permissions to use the key for cryptographic functions.

Given that your CMKs are being used to protect your sensitive information, you should work to ensure that the corresponding key policies follow a model of least privilege. This includes ensuring that you do NOT include kms:* permissions in an IAM policy. This policy would grant the principal both administrative and usage permissions on all CMKs to which the principal has access. Similarly, including kms:* permissions for the principals within your key policy gives them both administrative and usage permissions on the CMK.

It’s important to remember that explicit deny policies take precedence over implicit deny policies. When you use NotPrincipal in the same policy statement as "Effect: Deny", the permissions specified in the policy statement are explicitly denied to all principals except for the ones specified. A top-level KMS policy can explicitly deny access to virtually all KMS operations except for the roles that actually need them. This technique helps prevent unauthorized users from granting themselves KMS access.