Data Security and Governance
Encryption, Masking, and Cross-Account Keys
CoreChoose masking or anonymization for usable data, configure KMS authorization, support cross-account key use, and protect data in transit or before transit.
Aligned to AWS Certified Data Engineer - Associate (DEA-C01) Version 1.1, verified August 25, 2026.
Why this matters
Encryption protects confidentiality through keys, while masking and anonymization change exposed values. Correct security design places each control at the data state, account, and use boundary it actually protects.
Must Know
- Use masking, tokenization, or anonymization according to reversibility, linkage, test realism, and policy requirements. Hiding a column in a UI does not transform the stored value.
- At-rest encryption requires the service to use an approved KMS key and the executing principal to have required permissions under the key and IAM policies.
- Cross-account KMS use requires the key-owning account to authorize the external principal in the key policy and the external account to delegate corresponding IAM permission.
- Sharing a key alias does not authorize use of the key.
- Use TLS for encryption in transit. Add client-side or other pre-transit encryption when policy requires protection before the receiving AWS service obtains plaintext.
- A private subnet or endpoint does not itself encrypt application traffic.
- Masking usable data and encrypting stored or transported data can be required together.
Compare and Distinguish
- Masking or anonymization versus encryption: exposure reduction in usable data differs from cryptographic confidentiality.
- KMS key policy versus IAM policy: key-side authorization and principal-side delegation are both required cross-account.
- Encryption at rest versus in transit versus before transit: stored, network, and client-side boundaries differ.
- Private connectivity versus TLS: path isolation differs from cryptographic transport protection.
Scenario examples
- A producer account encrypts S3 data under a customer-managed KMS key whose policy allows a consumer role; the consumer account also grants that role KMS use.
- Test data is tokenized at the publish boundary while the backing objects remain KMS-encrypted.
- A source encrypts before transfer and uses TLS because policy requires protection before service receipt and during transport.
Exam traps
- Calling encrypted values anonymous while authorized users can decrypt them.
- Adding IAM permission only in the consumer account for a cross-account KMS key.
- Treating an alias as a shareable authorization object.
- Equating a private endpoint with encryption in transit.
Key takeaways
- Select controls from data state and use requirements.
- Authorize cross-account KMS on both sides.
- Combine masking and encryption when their distinct protections are both required.
How it works
- The service encrypts or decrypts with an approved KMS key after both the calling principal and key policy authorize the operation.
- Masking or tokenization occurs at the governed publish boundary, while TLS or client-side encryption protects data during transfer.
When to use it
- Use masking or anonymization when consumers need usable data with reduced identity exposure, and KMS encryption for cryptographic confidentiality.
- Add pre-transit encryption when policy requires the source to protect data before AWS receives plaintext.
Security and governance implications
- Keep plaintext staging out of protected flows and limit decrypt permission to the workload and data states that require it.
- Test both approved and denied principals, especially for cross-account keys where one-sided permission is insufficient.
Common failure modes and diagnosis
- For KMS denial, compare the key ARN, Region, service integration, key policy, IAM policy, grants, and encryption context.
- For exposed values, identify whether masking happened before publication and whether any intermediate copy retained plaintext.
More detail
- 4.3.1: Apply data masking and anonymization according to compliance laws or company policies.
- 4.3.2: Use encryption keys to encrypt or decrypt data (for example, AWS KMS).
- 4.3.3: Configure encryption across AWS account boundaries.
- 4.3.4: Enable encryption in transit or before transit for data.
Ready for the quiz?
- Does the requirement concern usable-value exposure, stored ciphertext, transport protection, or protection before service receipt?
- Which key policy and IAM delegation authorize the exact principal when encrypted data crosses an account boundary?
Related objectives
- D4.3 — Task 4.3: Ensure data encryption and masking
- 4.3.1 — Apply data masking and anonymization according to compliance laws or company policies.
- 4.3.2 — Use encryption keys to encrypt or decrypt data (for example, AWS KMS).
- 4.3.3 — Configure encryption across AWS account boundaries.
- 4.3.4 — Enable encryption in transit or before transit for data.