Data Security Controls

KMS key access is governed by a key policy (the resource policy on the key) combined with IAM identity policies. The key policy is the authoritative grant — IAM alone is never enough.

Key policy basics: a default key policy grants the AWS account root user full key access; from there, IAM policies can grant key actions to other principals (but only because the root grant exists). To remove this, scope the key policy to specific principals.

Cross-account access pattern:

{
  "Sid": "AllowCrossAccount",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::CONSUMER_ACCOUNT:root" },
  "Action": ["kms:Decrypt", "kms:DescribeKey", "kms:CreateGrant"],
  "Resource": "*"
}

The consumer account's role still needs kms:Decrypt in its identity policy — this is two-layer (resource + identity) authorization, like S3 cross-account access.

Condition keys worth memorising:

• kms:ViaService — restricts the key to be used only through a specific AWS service. E.g. "kms:ViaService": "s3.us-east-1.amazonaws.com" means this key can only encrypt/decrypt via S3 in us-east-1. Defends against credentials being misused to decrypt the key through unintended services.
• kms:CallerAccount — restricts to a specific account. Combined with ViaService for fine-grained scoping.
• aws:SourceArn — restricts to a specific resource (e.g. only requests from one specific Lambda function or RDS instance).
• kms:EncryptionContext — requires a specific encryption-context dict to be passed; the same context must be supplied at decrypt time. Used as a sub-key for envelope encryption scenarios.

Grants vs key policy:

• Key policies are static — edit them and you change permanent permissions.
• Grants are temporary, programmatic — created via kms:CreateGrant, can be revoked or expire. AWS services (e.g. RDS encryption, EBS encryption) create grants automatically when they need temporary access.

For short-lived workloads needing temporary key access, grants are the pattern. For permanent integration, key policy.

ViaService restriction example (a common SAA scenario):

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/AppRole" },
  "Action": ["kms:Encrypt", "kms:Decrypt"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "s3.us-east-1.amazonaws.com",
      "kms:CallerAccount": "123456789012"
    }
  }
}

This role can encrypt/decrypt via this key — but only when the request comes through S3 in us-east-1 from account 123456789012. Misuse via SQS / Lambda / direct KMS API is denied.

S3 supports four server-side encryption options. Since January 2023, SSE-S3 is enabled by default on every new bucket. The exam tests when to upgrade to a more controlled option.

SSE-S3 (AES-256 with AWS-managed keys):

• AWS manages key creation, rotation, and storage entirely.
• Free; no KMS API charges.
• NO CloudTrail audit of individual encrypt/decrypt operations.
• Use for: default for non-sensitive data, public marketing content.

SSE-KMS with AWS-managed key (aws/s3):

• AWS-managed key per region; free.
• Adds KMS API charges per encrypt/decrypt request.
• CloudTrail logs every key use (full audit trail).
• Key policy not editable — fine for general compliance, not for cross-account.
• Use for: compliance audit needs without cross-account complexity.

SSE-KMS with customer-managed key:

• You create the key; ~$1/key/month + per-request charges.
• Full key policy control: cross-account, conditions, ViaService.
• Auto rotation (yearly) opt-in.
• Use for: multi-tenant isolation (key-per-tenant), cross-account encrypted access, regulatory compliance.

SSE-C (Customer-Supplied Key):

• Caller provides the encryption key in every PUT/GET request (HTTPS only).
• AWS doesn't store the key — caller responsible for key management.
• No KMS API costs (KMS is bypassed entirely).
• No CloudTrail of key use.
• Use for: rare scenarios where customer MUST hold the key entirely outside AWS.

DSSE-KMS (Dual-layer SSE-KMS):

• Each object encrypted twice with two independent KMS calls.
• ~2× KMS request cost.
• Required for FedRAMP High workloads.
• Use for: government / defense workloads with explicit dual-layer requirement.

Decision pattern:

• 'Default encryption / public marketing content' → SSE-S3 (auto-on).
• 'Compliance audit / who decrypted what' → SSE-KMS (any flavour).
• 'Cross-account encrypted access' → SSE-KMS with customer-managed key.
• 'Multi-tenant data isolation' → SSE-KMS with separate customer-managed key per tenant.
• 'FedRAMP High / dual-layer' → DSSE-KMS.
• 'Customer must hold the key' → SSE-C.

Bucket-level enforcement — combine with a bucket policy denying non-encrypted uploads:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::our-bucket/*",
  "Condition": {
    "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
  }
}

This denies any PUT that doesn't specify SSE-KMS — guarantees no plaintext ever lands in the bucket.

AWS Certificate Manager (ACM) issues free TLS/SSL certificates for AWS services. The exam tests when ACM works, where the certificate must live, and how validation + renewal happen.

Where ACM-issued certificates can be used:

• CloudFront — certificate MUST be in us-east-1 (regardless of where your origin is).
• ALB / NLB / API Gateway / App Runner — certificate must be in the SAME region as the resource.
• Route 53 — used for ACM-issued certs validated via DNS in the hosted zone.

Issuance and validation:

1. Request certificate: list domain names (FQDN + optional wildcards like *.example.com).
2. Pick validation method:
   • DNS validation (preferred): ACM gives you a CNAME record to add to your domain's DNS. Once propagated, ACM auto-validates and issues. Auto-renewal happens automatically every year as long as the CNAME stays in place.
   • Email validation: ACM sends approval emails to standard addresses (admin@, hostmaster@, webmaster@) for the domain. Requires manual click to approve, every renewal (every year). Don't use unless you have to.
3. Certificate issued → install on the AWS resource.

Auto-renewal:

• DNS-validated certificates renew automatically 60 days before expiry. ACM checks the CNAME, validates, reissues. Zero downtime if the certificate is attached to a managed AWS resource (CloudFront, ALB).
• Email-validated certificates DON'T auto-renew — you must respond to a new email approval every year. Exam common trap: 'why did my ALB stop accepting HTTPS?' → email validation expired.

Private CA (ACM Private CA):

• ACM also offers a managed private CA for internal certificates (services that talk to each other internally over TLS).
• ~$400/month per CA hierarchy + per-certificate fee.
• Used for mutual-TLS (mTLS) on internal services.

Importing third-party certificates:

• You can import certs from external CAs (DigiCert, Let's Encrypt, etc.). Stored in ACM, usable on AWS services.
• Imported certs DON'T auto-renew — you must re-import the renewed cert. ACM sends expiry notifications via CloudWatch.

Public vs private certificates:

• ACM public certs (from Amazon Trust Services) are trusted by browsers worldwide. Free.
• ACM private certs (from your ACM Private CA) are trusted only by clients that trust the private CA. For internal mTLS.

Exam patterns:

• 'CloudFront with custom domain' → ACM cert in us-east-1.
• 'ALB HTTPS in us-west-2' → ACM cert in us-west-2.
• 'Internal microservices mTLS' → ACM Private CA + per-service private certs.
• 'Imported cert from Let's Encrypt' → no auto-renewal; CloudWatch alarm on expiry.

S3 Block Public Access (BPA) is the strongest defense against accidental public bucket exposure. It applies at three levels and uses an explicit override hierarchy.

Four settings, each toggle-able:

1. BlockPublicAcls — prevents new public ACLs from being applied. Existing public ACLs remain (unless setting #2 is also on).
2. IgnorePublicAcls — ignores all public ACLs (existing or new). The bucket / object isn't removed; ACLs are just not honored.
3. BlockPublicPolicy — prevents new bucket policies that grant public access.
4. RestrictPublicBuckets — even if a bucket policy somehow grants public access, only AWS principals + AWS services can access; anonymous internet requests are blocked.

Level hierarchy (most restrictive wins):

1. Organization level (S3 Block Public Access at the Organizations level) — applies to every account in every member account. Cannot be overridden by member account admins.
2. Account level — per-account setting. Overrides bucket-level if more restrictive.
3. Bucket level — per-bucket setting. Applies to that bucket only.
4. Object level — individual object ACLs (still subject to all the above).

Trap the exam loves: a bucket policy that allows s3:GetObject from "Principal": "*" and BPA is on at the account level. Outcome: BPA wins; bucket is not public. The policy is evaluated but the public-access result is suppressed by BPA. This is correct — BPA was designed exactly to override misconfigurations.

Organization-wide enforcement pattern:

To enforce 'no S3 bucket can ever be public anywhere in our Organization':

1. AWS Organizations → S3 BPA at root level → all four settings enabled.
2. Optional SCP at root denying s3:PutPublicAccessBlock so member account admins can't disable BPA.
3. AWS Config rule s3-bucket-public-access-prohibited to detect any drift.

When to disable BPA: only for intentional public static-website hosting. Even then, prefer CloudFront in front of a private bucket (with Origin Access Control) to expose content while keeping the bucket itself private.

SCPs vs BPA: SCPs can deny S3 actions (PutBucketPolicy, PutObjectAcl) but cannot inspect bucket policy content. BPA inspects content — it's the only way to enforce 'no public exposure' regardless of how a bucket policy is written. The exam answer for organizational guarantee is BPA at the org level, not SCP.

Amazon Macie scans S3 buckets for PII, PHI, financial data, and credentials. It's S3-only — no other data sources. Cost is per-GB scanned + per-object analyzed; petabyte-scale buckets are expensive to scan fully.

Two finding types:

1. Policy findings — public buckets, unencrypted buckets, ACL grants to anonymous. Discovered continuously, free.
2. Sensitive data findings — actual PII detected in objects. Requires running a discovery job; costs per GB.

Managed identifiers (built-in regex + dictionary patterns):

• PII: Social Security numbers (US), passport numbers (many countries), driver's licenses, credit card numbers, IBANs, bank account numbers.
• PHI: medical record numbers, NPI, diagnosis codes.
• Credentials: AWS access keys, OAuth tokens, SSH keys, X.509 private keys.
• Country-specific: tax IDs, national IDs for ~30+ countries.

Managed identifiers are accurate (high precision, low false-positive rate). Use them by default.

Custom data identifiers — your own regex + keywords:

Regex: ^[A-Z]{2}\d{6}$  (e.g. employee ID format)
Keywords: ["employee", "emp_id"]
Maximum match distance: 50 characters
Ignore words: ["test", "sample"]

Use for: company-specific identifiers (employee IDs, internal codes), regulated data formats unique to your domain.

Cost-control patterns:

1. Bucket inclusions / exclusions: scope a job to specific buckets only. Don't scan obvious-non-PII buckets (build artifacts, log archives older than 90 days).
2. Object filtering: include only specific file extensions / prefixes / tags. E.g. scan only s3://uploads/ prefix where users put data, not s3://thumbnails/.
3. Sampling depth: Macie samples a percentage of objects rather than scanning every one. Set sampling depth to balance cost vs coverage.
4. One-time vs scheduled jobs: full one-time scan after migration; then monthly incremental scans on critical buckets.
5. Findings aggregation: route Macie findings to Security Hub via EventBridge for cross-account visibility.

Multi-account deployment:

• Enable Macie at the Organizations level via the delegated administrator account.
• Designate one account (typically security tooling account) as the Macie administrator; it gets visibility into all member accounts' findings.

Common exam scenario:

'After migration, audit S3 buckets across all accounts for PII without disrupting workloads' → Macie via Organizations + delegated administrator + one-time discovery job + scope to migration buckets + custom data identifier for company-specific employee IDs.

AWS CloudHSM provides dedicated, FIPS 140-2 Level 3 validated Hardware Security Modules in your VPC. You control the keys entirely; AWS provides the hardware. Required for workloads with strict regulatory requirements like 'must store keys in a dedicated HSM', FedRAMP Moderate/High with HSM mandate, or government/defense.

Cluster topology:

A CloudHSM cluster = 1+ HSM instances in your VPC. Each HSM is ~$1.45/hr = ~$1 000/month. For production HA, run 2+ HSMs in different AZs (otherwise AZ failure = key loss).

Keys are replicated synchronously across HSMs in the same cluster. Operations are load-balanced.

Setup steps (mechanical, but the exam may test the sequence):

1. Create cluster — choose VPC + 2+ subnets in different AZs.
2. Initialize cluster — generate the cluster's CA certificate; sign it.
3. Activate HSMs — set the Crypto Officer (CO) credentials. CO administrates the HSM; can't perform crypto operations (separation of duties).
4. Create Crypto Users (CU) — application identities that do encrypt/decrypt/sign/verify. Each CU has its own keys.
5. Connect clients — install the CloudHSM Client SDK on EC2 instances, configure cluster endpoint, authenticate as a CU.

Client SDK options:

• PKCS #11 — standard cryptographic API; works with most languages.
• JCE (Java Cryptography Extension) — Java apps.
• CNG (Cryptography Next Generation) — Windows / .NET.
• OpenSSL Dynamic Engine — for apps using OpenSSL APIs.

Common integration patterns:

1. TLS offload: nginx/Apache uses CloudHSM via OpenSSL engine to sign TLS handshakes. Private key never leaves the HSM.
2. Code signing: build pipeline signs releases with a CloudHSM-stored signing key. Compliance-required for signed software.
3. Database encryption: Oracle TDE / SQL Server TDE encrypts at the database engine layer using CloudHSM-stored keys.
4. Custom AWS KMS Custom Key Store: bridge CloudHSM + KMS — KMS API on top of HSM-stored keys. Lets AWS services (S3, EBS) use HSM-backed keys transparently while you retain key custody.

Backup:

CloudHSM auto-backs up the cluster to S3 (encrypted, AWS-managed). Backups are tied to your cluster's CA certificate — restoring requires the original CA.

vs KMS:

• KMS = FIPS 140-2 Level 2 (Level 3 for some operations); shared-tenancy under the hood; AWS controls the hardware. Cheaper, simpler.
• CloudHSM = FIPS 140-2 Level 3; single-tenant hardware in YOUR VPC; you control. Required only when the spec explicitly mandates HSM custody.

Exam triggers for CloudHSM:

• 'FIPS 140-2 Level 3' → CloudHSM.
• 'Customer must control key material entirely' → CloudHSM (or imported key material in KMS, depending on context).
• 'Dedicated hardware' → CloudHSM.
• Otherwise → KMS is the default.