Encryption, Secrets and Threat Protection

In part twenty-six we controlled who gets in. This part assumes the worst: a disk gets stolen, a password leaks, or someone attacks your site. What protects you then?

AWS KMS: the key safe #

We saw the types of encryption in S3. Behind most of them is KMS (Key Management Service): keys are created and used inside it and never leave it unencrypted, access is controlled by policies, and every use is recorded in CloudTrail.

Envelope encryption #

KMS doesn't encrypt your large files itself. It makes a data key that encrypts the file, and it encrypts that data key with your master key:

So even whoever steals the disk gets encrypted data with an encrypted key next to it. To decrypt, you need permission to ask KMS to open the data key, and that's where your control sits.

Types of keys #

Most keys are symmetric, one key for encrypting and decrypting that never leaves KMS. There are also asymmetric pairs, where the public key leaves KMS, for signing or for encryption by parties outside AWS.

Deleting a key is irreversible, because it destroys everything encrypted with it. So KMS imposes a waiting period of 7 to 30 days, during which you can cancel. To stop a key from being used in the meantime, disable it.

Key policies #

Every KMS key has a key policy, and unlike other resources, IAM alone isn't enough without it. The default policy lets the account's IAM policies grant access to the key.

This matters when copying encrypted data:

• To another Region: keys are Regional, so copying a snapshot re-encrypts it with a key in the destination Region.
• To another account: share the snapshot, and allow that account in the policy of a customer managed key. AWS managed keys, such as aws/ebs, can't be shared, so a snapshot encrypted with one must first be copied with your own key.

Multi-Region keys #

Multi-Region keys share the same key material and ID across Regions, so something encrypted in one Region can be decrypted in another without re-encrypting. They're not for everything, as AWS recommends single-Region keys by default. They suit cases such as client-side encryption of a field in Global Tables or Aurora Global.

CloudHSM: your own hardware #

With KMS, AWS manages the hardware holding your keys. If a regulation requires a hardware security module dedicated to you, AWS CloudHSM gives you a single-tenant cluster of FIPS-validated HSMs. AWS handles provisioning and backups, while you control the keys and users yourself. Choose it only when you must, because you take on more responsibility than with KMS.

Where do you keep passwords? #

Not in code, and not in Git. You have two services:

Parameter Store #

Its names form a hierarchy, such as /shop/prod/db-url, so an application can fetch a whole path, and IAM can allow /shop/prod/* only.

Secrets Manager #

The point here is rotation: the password changes on a schedule you set, and the function updates it in the database too. Your application asks for the current value each time, so it doesn't notice. We saw in part eight that RDS can manage its password here for you.

ACM: certificates without the hassle #

AWS Certificate Manager issues public TLS certificates for free when used with services like load balancers, CloudFront and API Gateway, and it renews them by itself.

• Validation: prove you own the domain by DNS, and it's best with Route 53, or by email.
• Validity: public certificates now last 198 days, under new industry rules, and renewal happens automatically about 45 days before expiry. The period will shorten further in the coming years, which is more reason to leave it to automation.
• Imported certificates: you can import your own, but ACM doesn't renew those, so set an alert on their expiry.
• Other servers: a normal ACM certificate can't be installed on your own server. If you need that, there are exportable certificates, for a fee.

Stopping attacks #

Here's how the protection layers sit together in a typical design:

WAF attaches to CloudFront, Application Load Balancer, API Gateway and AppSync, but not to a Network Load Balancer. If you need a fixed IP with WAF, put Global Accelerator in front of the load balancer. Rate-based rules are simple and effective: block any address sending more than a set number of requests.

Withstanding DDoS #

The earlier parts gave you most of what's needed already:

• CloudFront and Route 53 absorb attacks at the edge, far from your servers.
• Auto Scaling grows if something gets through, though watch the cost.
• A security group allows the load balancer only from CloudFront, so nobody can skip it.
• WAF with rate limits and Bot Control for attacks that look like normal requests.

Blocking one address: where? #

For protection at the VPC boundary, there's also Network Firewall, which we covered in part fourteen.

Detecting threats #

Prevention isn't everything. You also need something to tell you when something's wrong:

GuardDuty catches things like crypto mining, or credentials used from a strange place. Send its findings through EventBridge to SNS or Lambda so you act on them. It's one click to enable, so turn it on from the start in any serious account, as it has a free trial period.

Compliance documents: AWS Artifact #

An auditor asks for proof that AWS itself meets ISO or PCI standards? AWS Artifact gives you those reports on demand and free of charge, and it's also where you review and accept agreements with AWS. It covers AWS's side of the shared responsibility model, and proving your side is still up to you.

Hands-on: a key, a parameter and a secret #

From CloudShell, create a key with an easy name, and encrypt some text:

KEY_ID=$(aws kms create-key --description "Series demo key" \
  --query KeyMetadata.KeyId --output text)
aws kms create-alias --alias-name alias/series-demo --target-key-id $KEY_ID

CIPHER=$(aws kms encrypt --key-id alias/series-demo \
  --plaintext "my secret note" --cli-binary-format raw-in-base64-out \
  --query CiphertextBlob --output text)

echo $CIPHER

You'll see unreadable text. Decrypt it. For a symmetric key, there's no need to say which key:

aws kms decrypt --ciphertext-blob "$CIPHER" \
  --query Plaintext --output text | base64 -d; echo

Now see where the real control lies. Disable the key, and try again:

aws kms disable-key --key-id $KEY_ID

aws kms decrypt --ciphertext-blob "$CIPHER" \
  --query Plaintext --output text

aws kms enable-key --key-id $KEY_ID

You'll get a DisabledException. The data hasn't changed, but it's useless without the key. Now keep a password in Parameter Store, encrypted with the same key, and read it with and without decryption:

aws ssm put-parameter --name /series/prod/db-password \
  --type SecureString --key-id alias/series-demo --value "S3cret-pass"

aws ssm get-parameter --name /series/prod/db-password \
  --query Parameter.Value --output text

aws ssm get-parameter --name /series/prod/db-password --with-decryption \
  --query Parameter.Value --output text

aws ssm get-parameters-by-path --path /series/prod \
  --query "Parameters[].Name"

And a secret in Secrets Manager, in the way your application would read it:

aws secretsmanager create-secret --name series/api-key \
  --secret-string '{"key":"abc123"}' --query Name --output text

aws secretsmanager get-secret-value --secret-id series/api-key \
  --query SecretString --output text

Finally, what did all of this leave behind? CloudTrail has recorded who used the key, though it can take a few minutes:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=Decrypt \
  --max-results 3 --query "Events[].[EventName,Username,EventTime]" --output table

aws secretsmanager delete-secret --secret-id series/api-key \
  --force-delete-without-recovery
aws ssm delete-parameter --name /series/prod/db-password
aws kms delete-alias --alias-name alias/series-demo
aws kms schedule-key-deletion --key-id $KEY_ID --pending-window-in-days 7

Summary #

• KMS keeps your keys safe, uses envelope encryption, and records every use.
• Keys are Regional, and AWS managed keys can't be shared across accounts.
• Parameter Store for settings, and Secrets Manager for what must rotate.
• ACM certificates are free and renew themselves, and CloudFront needs them in us-east-1.
• WAF and Shield stop attacks, and GuardDuty, Inspector and Macie detect what gets through.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

You've protected yourself from people. What about a whole Region going down, or having to bring a data center over to AWS? In part twenty-eight we cover disaster recovery and migration.