Protecting data in the cloud almost always comes down to one practical question: where and how should encryption be applied. The answer changes depending on whether data is sitting still in a disk or database, or moving between systems over the network. This article walks through the difference between encryption at rest and in transit, how key management works across the three major cloud providers, and what frameworks like ISO 27001 and NIST actually require, plus how Brazil's LGPD fits in for companies operating there.
Encryption at rest vs in transit: what each one protects
Encryption at rest protects stored data: files in an object storage bucket, disk volumes, backups, databases. The goal is to make sure that even if someone gains physical or logical access to the storage medium, the data stays unreadable without the correct key.
Encryption in transit protects data while it moves across the network, between a client and a server, between services inside the cloud, or between different regions of the same provider. This is where protocols like TLS for HTTPS connections and VPNs for internal traffic come in.
In practice, the two types are complementary, not interchangeable. Data can be well protected at rest and still leak if the connection carrying it doesn't use TLS. Likewise, an API well protected by HTTPS doesn't stop an unprotected disk volume from being accessed directly by someone with excessive privileges.
Across the three major providers, a large part of encryption in transit between internal infrastructure is already handled by the provider itself. But under the shared responsibility model, it's up to the customer to enable encryption at rest on services like disks (EBS), managed databases (RDS), and storage buckets, enforce HTTPS in their own applications, and choose the right key strategy.
How envelope encryption works
AWS, Azure, and Google Cloud all follow a similar pattern for key management known as envelope encryption. The idea is simple: instead of using the master key directly to encrypt large volumes of data, the system generates a local key, called a Data Encryption Key (DEK), which does the actual encrypting.
That DEK is, in turn, protected by a Key Encryption Key (KEK), which never leaves the key management service (KMS). This design cuts down on the number of calls to the KMS during bulk operations, which helps with cost and latency without compromising the security of the master key.
Best practices recommended by Google Cloud include using AES-256-GCM for DEKs, never storing a DEK in plaintext, and rotating KEKs regularly. These principles hold, with small variations, across any provider that follows the same pattern.
Key management: AWS KMS, Azure Key Vault, and Google Cloud KMS
All three services solve the same problem with different emphases:
- AWS KMS: operates within the shared responsibility model. AWS handles encryption in transit across its own infrastructure, but the customer decides between an AWS-owned key or a customer-managed key (CMK), which offers more control over rotation and access policies.
- Azure Key Vault: unifies management of secrets, certificates, and cryptographic keys in a single service, which is particularly useful in hybrid scenarios where on-premises and cloud workloads coexist.
- Google Cloud KMS: stands out for its global key distribution and tight integration with IAM, supporting both customer-managed keys (CMEK) and customer-supplied keys (CSEK).
If the strategy involves an external or third-party KMS, it's worth checking whether it has FIPS 140-3 validation by consulting the NIST CMVP public list.
What LGPD actually requires (and what it doesn't)
A common point of confusion, especially for companies handling data from Brazil, is assuming that the LGPD (Brazil's data protection law, Law 13.709/2018) mandates encryption outright. That's not quite accurate. Article 46 of the law requires data controllers to adopt "technical and administrative security measures" to protect personal data, but the text doesn't explicitly name encryption as a requirement.
What the law does say, in Article 46's first paragraph, is that Brazil's data protection authority (ANPD) may establish minimum technical standards, taking into account the "current state of technology." So far, that means encryption is a widely adopted best practice, not a literal legal mandate.
The same article's second paragraph reinforces the privacy by design concept: security measures should be considered from the conception of a product or service, not bolted on after it's already in production. In practice, that means decisions about where and how to encrypt data should be part of the architecture from day one, not an afterthought.
Compliance checklist: ISO 27001, ISO 27017, ISO 27018, and CIS Benchmarks
For teams looking for a more concrete technical bar, international standards are a useful reference:
- ISO/IEC 27001:2022, under Annex A control 8.24 ("Use of cryptography"), requires a formal policy covering encryption standards, key management, and applicable legal aspects.
- ISO/IEC 27017:2015 adds controls specific to cloud services on top of ISO 27002, including data segregation between customers and network security.
- ISO/IEC 27018:2019 focuses on protecting personal data (PII) in public cloud when the provider acts as a processor, guiding encryption of PII both at rest and in transit.
- CIS Benchmarks for AWS, Azure, and GCP offer practical level 1 and level 2 recommendations, including the use of customer-managed keys (CMK) for disk volumes.
On the key management side specifically, NIST SP 800-57 Part 1 Revision 5 remains the current reference. A Revision 6 has been open for public comment since late 2025, but it isn't the official version yet, so Rev. 5 is still the one to build on. NIST SP 800-53 Rev. 5 brings the SC-13 and SC-28 controls, which tools like AWS Security Hub reference to require customer-managed KMS keys for encryption at rest.
Common mistakes that weaken encryption
Having encryption enabled isn't a guarantee of protection if the management around it is weak. The most common mistakes include:
- Leaving buckets or volumes on default settings without checking whether encryption at rest is actually turned on.
- Defaulting to the provider's standard key when the use case called for a customer-managed key with its own rotation and revocation controls.
- Not rotating keys regularly, even when the provider offers automatic rotation.
- Relying on encryption alone without securing the authentication of key material, which can let an attacker substitute the key and bypass protection even with encryption turned on.
Flaws identified between 2024 and 2025 in some end-to-end encrypted cloud storage platforms illustrate exactly this risk: without proper key authentication, attackers were able to substitute the encryption key without the victim noticing. The practical lesson is that key management needs to be just as robust as the encryption algorithm itself.
Conclusion
Cloud encryption works best as a combination of well thought out decisions: protecting data at rest and in transit, adopting the envelope encryption pattern, deliberately choosing between provider-managed and customer-managed keys, and aligning all of it with relevant frameworks like ISO 27001, ISO 27017/27018, and NIST guidelines. None of these choices need to be made in isolation or under pressure.
If your company wants to review its cloud encryption and key management strategy, Cloud Minds Trusted can help map the current setup and prioritize next steps.