Secrets and Sensitive Data

What it is

Sensitive data comes in two forms. Secrets are credentials your application uses, such as database passwords, API keys and tokens. Sensitive data is information about people, such as personally identifiable information (PII) and protected health information (PHI).

For secrets, the rule is never to put them in code, environment files or container images. For sensitive data, you find it, mask or redact it, and limit who can read it.

How it works

Secrets Manager and Parameter Store

Pick Secrets Manager when the question says rotate, or mentions database credentials. Pick Parameter Store for plain configuration, or when the least cost is the goal.

Secrets Manager details:

• Your code calls GetSecretValue. The role needs secretsmanager:GetSecretValue, plus kms:Decrypt if the secret uses a customer managed key.
• Rotation runs a Lambda function. Secrets Manager provides ready made rotation functions for supported Amazon RDS databases.
• Versions carry staging labels. AWSCURRENT is the live value and AWSPREVIOUS is the one before it.
• Caching the secret in your code (with the AWS provided caching components) cuts latency and API calls.
• A resource policy lets another account read the secret, and the secret must then use a customer managed key that the other account can use.

Parameter Store details:

• Types are String, StringList and SecureString.
• Call GetParameter with WithDecryption set to true to read a SecureString. The caller needs KMS permission as well.
• Parameters use a hierarchy such as /app/prod/db/host, and a policy can grant access to a whole path.

Lambda and ECS can also inject secrets into the environment, but a secret placed in a plain environment variable is visible to anything that reads the configuration. Fetching at run time is safer.

Finding and masking sensitive data

• Amazon Macie scans S3 buckets and reports sensitive data such as PII and credentials. It finds data; it does not block access.
• Amazon Comprehend detects PII in text. DetectPiiEntities returns each entity type with its position, so your code can replace it. A PII redaction job masks documents in bulk.
• Amazon CloudWatch Logs data protection policies audit and mask matching values in log events. Only principals with logs:Unmask see the originals. Masking applies to events ingested after the policy is set.
• Amazon Bedrock Guardrails can block or mask PII in model prompts and responses (covered later in this chapter).
• CloudFront field level encryption encrypts chosen form fields at the edge with a public key, so only the service holding the private key can read them.

Limiting access

Masking is not enough on its own. Combine it with least privilege.

• Allow s3:GetObject only on the prefix that holds the data, and use S3 access points to give each application its own entry point and policy.
• Encrypt with a customer managed KMS key whose key policy lists the few roles that may decrypt.
• Store only the fields you need. Tokenize or hash identifiers when the original value is not required.
• Keep sensitive values out of logs, error messages and URLs.

How the exam asks about this

• "Database credentials must rotate every 30 days with the least operational overhead" -> Secrets Manager with automatic rotation.
• "An application needs a plain configuration value at the lowest cost" -> Parameter Store standard parameter.
• "Find which S3 buckets contain PII" -> Amazon Macie.
• "Log events must not reveal credit card numbers" -> a CloudWatch Logs data protection policy.