PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 3 / c3.4
Efficient Data ProtectionSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. 🤝 SharedAWS Shared Responsibility Model: who implements and operates this control. Customer = you own it; AWS = AWS operates it and you inherit it; Shared = both have obligations.

c3.4 Protect cryptographic keys with AWS KMS

Restrict access to the cryptographic keys used to protect account data to the fewest possible custodians and store them securely, with separation of duties from the data they protect.

Quick Wins
Foundational
Efficient
Optimized
Effort: High Impact: High Applies to CDE: Yes

Requirement 3

Protect Stored Account Data

PCI sub-requirements coveredCoverage shown per PCI DSS v4.0.1 sub-control. “Covered” = addressed by this AWS recommendation. “Roadmap” = technical, planned. “Your responsibility” = organizational/process control. “Out of scope” = physical or third-party control not implemented in AWS.

3.6 Cryptographic keys used to protect stored account data are secured
  • 3.6.1 Procedures to protect cryptographic keys against disclosure/misuse Covered
3.7 Key-management processes and procedures for cryptographic keys are defined and implemented
  • 3.7.1 Key-management: generation of strong keys Covered
  • 3.7.2 Key-management: secure distribution of keys Covered
  • 3.7.3 Key-management: secure storage of keys Covered
  • 3.7.4 Key-management: key changes at cryptoperiod end Covered
  • 3.7.5 Key-management: retirement/replacement/destruction of keys Covered
  • 3.7.6 Manual cleartext key operations use split knowledge/dual control Your responsibility
  • 3.7.7 Prevention of unauthorized substitution of keys Covered
  • 3.7.8 Key custodians formally acknowledge responsibilities Your responsibility
  • 3.7.9 SP shares keys with customers with documented guidance (SP only) Your responsibility

How to implement on AWS

Use AWS KMS with customer managed keys (CMKs) for CDE data. Restrict key usage and administration with key policies and IAM policies (separating who administers the key from who administers the data). Enable key rotation. Log all key usage with CloudTrail. For cryptographic module requirements, consider AWS CloudHSM (FIPS 140-2/3).

Practical implementation

How this control is implemented in each reference architecture:

Protect the CDE keys with a customer managed KMS key, separate who administers the key from who administers the data, rotate, and log every key use.

  1. Use a customer managed KMS key for the data tier and write a key policy that grants use to the data services but administration only to the security role, enforcing separation of duties.
    Data tier (CDE) AWS KMS IAM
  2. Enable automatic annual key rotation on the CMK.
    Data tier (CDE) AWS KMS
  3. Log all key use and administration (Encrypt, Decrypt, ScheduleKeyDeletion) with CloudTrail for review.
    Account logging CloudTrail
  4. If a dedicated FIPS 140-2/3 cryptographic module is required, use AWS CloudHSM as the key store.
    Data tier (CDE) CloudHSM

How to validate: The key policy shows key admins are distinct from data admins, rotation is enabled, and CloudTrail contains the key-usage events.

Avoid: Letting the same role administer both the key and the data it protects. Separate the duties so no single identity can both manage and decrypt.

Single-account, 3-tier →

Keep keys per account, administer them centrally from the security team, and stream key-usage logs to the log-archive account.

  1. Keep customer managed KMS keys per CDE account (no shared data keys across accounts) so a compromise stays contained.
    Each CDE workload account AWS KMS
  2. Separate key administrators (security team) from data owners using cross-account IAM roles referenced in the key policy.
    Security tooling account → CDE accounts IAM AWS Organizations
  3. Deliver CloudTrail key-usage events to the central log-archive account for tamper-resistant review.
    Log archive account CloudTrail Amazon S3

How to validate: Each CDE account has its own CMK with rotation, key admin roles are centralized/separated, and key-usage events arrive in the log-archive account.

Avoid: One org-wide KMS key administered by the workload teams. Centralize key administration and scope keys per account for isolation and separation of duties.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserveinterview

Testing procedures

  • Examine key-management policies and procedures to verify processes protect keys against disclosure and misuse (3.6.1); examine access lists to verify access to cleartext key components is restricted to the fewest custodians (3.6.1.3).
  • Where key-encrypting keys are used, verify they are at least as strong as the data keys they protect and stored separately (3.6.1.2.c).
  • Examine procedures and observe processes for the key lifecycle: generation, distribution, storage, cryptoperiod changes, retirement/replacement, split knowledge/dual control (3.7.1 through 3.7.8).

Evidence in AWS

  • KMS key policies and IAM policies evidencing limited custodians and separation of duties.
  • KMS key rotation enabled.
  • CloudTrail events for key use/administration (Encrypt, Decrypt, ScheduleKeyDeletion).
  • Documentation of key lifecycle procedures.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 3.6 — Processes that protect cryptographic keys used to protect stored account data against disclosure and misuse are defined and implemented.
  • 3.7 — Cryptographic keys are managed securely throughout their lifecycle (generation, distribution, storage, change, retirement, and protection against substitution).

AWS services

AWS KMS AWS CloudHSM AWS IAM AWS CloudTrail

Learning resources

References

  • AWS Security Maturity Model: Key management
  • PCI DSS v4.0.1 Requirements 3.6, 3.7