Amazon AWS SCS-C03: KMS Key Policy Design
AWS KMS key-policy design determines who can use an encryption key, who can administer it, and whether IAM permissions or cross-account access have any effect. Every KMS key has exactly one key policy, and AWS documents key policies as the primary authorization mechanism for KMS keys. That means a well-designed key policy is part of the security boundary for every S3 bucket, database, secret, log archive, or application that depends on the key.
Unlike ordinary IAM identity policies, a KMS key policy is regional and controls one KMS key. IAM policies can be used in addition to the key policy when the policy enables account-level IAM permissions. Grants can delegate specific KMS operations to principals or AWS services. Effective access therefore depends on the key policy, IAM, grants, organization guardrails, conditions, and the calling service context.
KMS key-policy engineering belongs inside AWS Security Engineering.
Keep key administrators and users separate
Key administrators need actions such as managing aliases, policy, rotation, or lifecycle; key users need cryptographic operations such as encrypt, decrypt, or generate data key.
AWS encryption is safer when one application role cannot also rewrite the key policy that limits it.
Separation of duties is especially important for log, backup, and security keys that protect evidence from workload administrators.
Understand the account-enabling statement
Default KMS key policies commonly include a statement that enables the AWS account to use IAM policies to delegate permissions.
Without key-policy permission that enables IAM authorization, an IAM allow can have no effect on the key.
Operators should recognize this model before spending time adding more IAM permissions to a principal the key policy never allows.
Grant only required key actions
AWS recommends least privilege and specifying exact key ARNs.
Application roles generally need a small set of cryptographic actions, not kms:*.
Administrative actions such as PutKeyPolicy, ScheduleKeyDeletion, or CreateGrant deserve especially tight control because they can change the protection boundary or persistence of the key.
Use conditions to bind key use
KMS supports condition keys for encryption context, grants, key spec, ViaService, and other request characteristics.
Encryption-context conditions can ensure a key is used only when the request carries expected application or resource context.
Service-scoped conditions can reduce the chance that a principal uses a key directly in a different workflow than intended.
Design cross-account use from both sides
Cross-account KMS access normally requires the key policy in the owning account to name the external principal/account and IAM policy in the external account to allow the KMS action.
Cross-account protection should use narrow principal, resource, service, and context conditions rather than trust an entire external account more broadly than necessary.
Test both encrypt and decrypt paths with the exact role used by the workload.
Use grants for service workflows
AWS services and delegated workflows can use grants for temporary or scoped permissions on a KMS key.
Grants are useful when permission must be created without rewriting the key policy for every resource operation.
Monitor who can create grants, constrain grant creation with supported conditions, and clean up grants according to service lifecycle.
Protect key deletion and policy changes
Deletion of a customer-managed KMS key can make encrypted data unrecoverable after the waiting period.
Restrict ScheduleKeyDeletion, alert on key state changes, and require strong change control around key-policy updates.
For critical data, verify that backup and disaster-recovery plans include the keys and policies required to decrypt restored data.
Use multi-Region keys only for a requirement
Multi-Region KMS keys can share key material across paired primary/replica keys in different Regions while each key keeps its own key policy and regional identity.
Use them when cross-Region cryptographic interoperability materially simplifies the application or disaster-recovery design.
Do not choose multi-Region keys solely because the application uses multiple Regions; many services can use independent regional keys successfully.
Audit key use and ownership
CloudTrail records KMS API activity and can support investigation of key management and cryptographic use.
For SCS-C03, durable key design is key owner → admin/user separation → exact actions → conditions → cross-account trust → grants → deletion protection → audit.
KMS security is strongest when the policy is small enough to understand and every broad permission has an explicit business reason.
KMS key policies should identify the purpose and owner of the key. A key named only by an opaque generated alias can become difficult to review years later. Tags, aliases, description, and infrastructure-as-code should connect the key to a workload, environment, data class, and administrative team.
The key-policy statement that enables IAM delegation is powerful because it allows the account to use IAM policies for key access. Security teams should understand that removing or changing this statement can break roles that previously relied on IAM, while keeping it means IAM administrators in the account may be able to grant key permissions subject to their own limits.
Key administrators often need management actions but not decrypt permission. Separate the policy statements so the team that rotates aliases or changes policy cannot automatically decrypt production data. Conversely, application roles should not receive policy-management actions simply because they need Decrypt or GenerateDataKey.
Use kms:ViaService when a key should be usable only through a specific integrated AWS service. This can limit a principal from using KMS directly for unrelated ciphertext while still allowing a service such as S3 or another supported service to use the key on the principal’s behalf.
Encryption context can create strong binding between ciphertext and application/resource metadata. Policies can require expected encryption-context keys or values. Applications must preserve the same context for decryption, so this control should be designed deliberately and documented as part of the cryptographic interface.
Grant constraints matter when applications or AWS services create grants. Conditions such as kms:GrantIsForAWSResource can help restrict grant creation to intended service-integrated flows. A principal with unrestricted grant authority can effectively delegate significant key use even when its normal IAM policy appears narrow.
Aliases should not be confused with keys. Access policies that name an alias or use alias-related conditions have specific KMS semantics; rotation or alias reassignment can change which key an application reaches. Critical applications should know whether they pin a key ARN or intentionally follow an alias.
Automatic key rotation changes key material while preserving the KMS key identity for supported customer-managed symmetric encryption keys. It does not rotate application credentials or change IAM policy. Rotation should be enabled according to compliance and cryptographic policy, while application data continues to reference the same key.
Multi-Region keys keep related cryptographic key material across Regions but maintain separate regional KMS key resources and policies. Administrators should manage policy consistency explicitly and understand that deleting or disabling one replica is a regional operation. Use multi-Region only when cross-Region ciphertext compatibility is a requirement.
Service-managed keys and AWS-owned keys can reduce administrative burden, but they provide different degrees of customer policy control. Choose customer-managed KMS keys when the workload requires explicit key policy, independent lifecycle, cross-account grants, or audit/control features that the service-managed option cannot provide.
Cross-account access should be tested from the target role session, not from an administrator. The key policy can allow an account while the consuming role’s IAM policy omits the action, or vice versa. Both sides are required for common cross-account KMS use.
KMS throttling and quotas can become reliability concerns for high-volume cryptographic workloads. Envelope encryption and service-integrated data keys reduce direct KMS calls for large data operations, but architects should still monitor request rates and service quotas where one key protects a high-throughput system.
Key policy changes should go through code review and policy validation. A malformed key policy can lock out expected administrators or unintentionally grant broad access. Keep tested break-glass recovery consistent with AWS KMS safety mechanisms instead of relying on manual console changes during an incident.
CloudTrail logging of KMS calls can reveal unusual decrypt activity, grant creation, key disablement, and policy changes. Correlate that activity with identity, application, and data-access evidence. A spike in Decrypt calls can be meaningful even when every request is technically authorized.
The strongest key policy is deliberately boring: few principals, clear admin/user separation, exact actions, narrow conditions, documented cross-account use, protected deletion, and auditable lifecycle. Complexity should come only from a real cryptographic requirement, not from years of accumulated exceptions.
Key policy review should include service integration requirements. Some AWS services create grants or require specific service-principal access patterns, and a policy that is too restrictive can break backup, logging, storage, or database operations. Use the service’s current KMS documentation rather than copying a key policy from an unrelated workload.
Deletion protection should include owner notification and recovery planning. ScheduleKeyDeletion has a waiting period, but that window is useful only if monitoring notices the event and an authorized team knows whether to cancel it. Alert on disable and deletion scheduling for keys that protect critical production, logs, or backups.
Key inventory should identify unused and orphaned keys. A customer-managed key that no active workload uses can still cost money and preserve old access relationships. Before retirement, verify snapshots, backups, encrypted objects, and historical data do not still require it; after that review, decommission through the controlled key lifecycle.