Data Protection and Secrets in Cloud
The single most common cloud breach headline is "exposed storage bucket," and behind it sit the data-protection fundamentals: encrypt data at rest and in transit, control who can read it, and keep the keys and secrets out of reach. The cloud makes strong encryption and key management easy to turn on — and equally easy to leave data wide open by default.
This topic applies Chapter 2's cryptography and Chapter 3's secrets management to Meridian's cloud data, focusing on the controls that stop the public-bucket class of breach and the metadata-endpoint credential theft.
The Public-Resource Breach
Object storage left public — or granted to "anyone with the link" or "all authenticated users" too broadly — is the recurring cloud data leak. Default-private storage, explicit access policies, account-level public-access blocks, and continuous checks for public resources are the direct counter. The fix is not exotic; it is defaulting to private and continuously verifying that nothing drifted public.
Encryption at Rest and In Transit
Cloud encryption at rest is often one toggle (and increasingly default), and TLS (Chapter 2) protects data in transit. The real questions are key ownership — provider-managed versus customer-managed keys — and whether encryption is actually enabled everywhere sensitive data lives. Crucially, encryption does not fix authorization: encrypted data readable by the wrong identity is still exposed.
Key Management and Envelope Encryption
A cloud KMS holds master keys that never leave it and wraps the data keys applications use — Chapter 3's envelope model. Customer-managed keys give control and revocability, and access to the KMS becomes a critical IAM boundary (the previous topic): whoever can use the key can read the data, so KMS permissions deserve the same scrutiny as the data itself.
Secrets and the Metadata Endpoint
Application secrets come from a cloud secrets manager (Chapter 3), not environment variables or config. And the instance metadata endpoint that hands out role credentials must be hardened (IMDSv2-style) so an SSRF (Chapter 6) cannot lift the cloud credentials — a top real-world cloud-escalation path. Meridian's cloud data controls are concrete: default-private storage with public-access blocks and monitoring, encryption everywhere with customer-managed keys for the crown jewels, secrets from the manager, and a hardened metadata endpoint.
- Public or over-broadly-shared storage buckets — the archetypal cloud data breach — from permissive defaults or convenience grants.
- Assuming "encrypted at rest" is enough while the access policy lets the wrong identities read it; encryption does not fix authorization.
- Long-lived secrets in environment variables or config instead of a secrets manager (Chapter 3), and provider-managed keys where customer control was needed.
- An unhardened metadata endpoint, letting an SSRF (Chapter 6) steal instance role credentials — a direct path to cloud compromise.
- Never scanning for resources that have drifted public over time.
- Default storage to private, block public access at the account level, and continuously scan for exposed resources.
- Encrypt at rest and in transit everywhere sensitive data lives, using customer-managed KMS keys for crown jewels and guarding KMS access as a key IAM boundary.
- Source application secrets from a cloud secrets manager (Chapter 3), never environment or config, with rotation.
- Harden the instance metadata endpoint (IMDSv2-style) so SSRF cannot lift role credentials, and pair with least-privilege roles (previous topic).
- Treat encryption and authorization as separate controls that both must be right.
Knowledge Check
What is the archetypal cloud data breach, and its direct fix?
- A public storage bucket — fixed by defaulting to private
- A hypervisor breakout — fixed by patching the provider's own kernel
- A brute-forced encryption key — fixed by using much longer keys
- A DNS hijack — fixed by switching to a new domain registrar
Why doesn't encrypting data at rest, by itself, protect it in the cloud?
- It doesn't fix authorization — wrong identity still reads it
- Cloud encryption at rest can never actually be enabled
- Data that is encrypted at rest cannot be backed up
- Encryption at rest slows the whole application down far too much
Why must the instance metadata endpoint be hardened?
- An SSRF can otherwise lift the instance's role credentials
- It serves the application's static assets to users
- It encrypts the instance's attached disk
- Hardening it makes the whole instance boot noticeably faster
You got correct