Encryption and Data Protection

The same file, two different risks

A support engineer debugging an issue captures network traffic between an app and its database while sitting in a coffee shop. If that connection is not encrypted, the engineer, or anyone else on the same Wi-Fi running the same capture, can read every password and every field moving through it, in plain text, as it happens.

Now picture a different moment entirely: months later, a decommissioned backup drive from that same database is sold or discarded without being wiped, and someone plugs it in. If the data on it was never encrypted, they can read it directly off the disk, no network capture required.

Same data, two completely different attack points, months apart. Protecting against one does nothing to protect against the other, which is why cloud platforms treat them as two separate controls: encryption in transit for data on the move, and encryption at rest for data sitting still.

Encryption at rest: AES-256 and server-side encryption

Encryption at rest protects data written to storage, disks, backups, database files, so that anyone who gains access to the physical or logical storage medium without authorization sees only unreadable ciphertext. The standard mechanism across every major cloud provider is AES-256, the 256-bit Advanced Encryption Standard block cipher, applied automatically or on request to data as it's written.

AWS calls its default approach server-side encryption: the storage service itself encrypts data before writing it and decrypts it on the way back out, all inside the service, using keys managed through a key management system. A customer typically doesn't touch the cipher directly; they choose a key management option and the storage service handles the rest.

Encryption in transit: TLS

Encryption in transit protects data while it's moving between two points on a network, a mobile app and a server, a load balancer and an application instance, one microservice and another. The standard mechanism is TLS, Transport Layer Security, which wraps a connection so that anyone capturing the raw network traffic sees only ciphertext, not the request or response itself.

As of mid-2024, every AWS API endpoint requires at least TLS 1.2 and supports TLS 1.3, the newer, faster version of the protocol. That baseline reflects an industry-wide pattern: older TLS versions and their predecessor, SSL, get retired as cryptographic weaknesses accumulate, and current guidance keeps pushing the accepted minimum forward.

The gap in the middle: data in use

Notice what neither protection covers. Once a request reaches the application server, the data has to be decrypted in memory, briefly, for the application to actually do anything with it, run a calculation, render a page, check a condition. That in-memory state is sometimes called data in use, and it sits outside what standard at-rest and in-transit encryption reach. It is a narrower, more specialized problem, and it is why "encrypted everywhere" is a simplification: encryption at rest and in transit cover the overwhelming majority of a request's journey, but not the instant the application is actively working with the plaintext.

Key management: separating who can decrypt from who holds the key

Encrypting data is only half the problem; controlling who can decrypt it is the other half, and that is what a key management service does. AWS KMS runs inside hardware security modules built so that plaintext keys never leave the module, not even for AWS's own employees. A request to encrypt or decrypt something is authorized independently through the same IAM permissions covered in the previous lesson, which means access to the data and access to the key that unlocks it are two separately controlled layers. Compromising one does not automatically hand over the other, and every use of a key gets logged, giving an auditable trail of exactly when and by whom a piece of data was decrypted.

The boundary: managed key service versus dedicated hardware

Most workloads use a managed key service like AWS KMS: shared, multi-tenant hardware behind a simple API, with AWS handling provisioning, patching, and availability. Some workloads, usually driven by a specific regulatory requirement, need a dedicated hardware security module instead, like AWS CloudHSM, giving the customer direct administrative control over single-tenant hardware they alone manage. The decision rule is narrow: default to the managed service, and reach for dedicated hardware only when a compliance requirement specifically mandates single-tenant control, since that option trades convenience for a burden of scaling and administration the customer now owns.

Misconception: encryption replaces access control

It's tempting to treat "everything is encrypted" as the end of the security conversation. It is not. Encryption protects data against someone who steals the storage medium or intercepts the network traffic without authorization. It does nothing to stop someone who already holds valid, authorized credentials, whether a legitimate employee or an attacker who has phished one, from reading data they're permitted to access, because the whole point of encryption is that authorized access decrypts it correctly. That is exactly the gap the previous lesson's IAM controls exist to close, and the two protections are meant to work together, not substitute for each other.

Exam cues: at rest or in transit

Where this leaves you

Encryption at rest and encryption in transit protect the same data at two different points in its journey, and a complete design needs both, since covering one leaves the other wide open. Neither one, though, decides who is allowed to ask for that data in the first place; that job stayed with identity and access management in the previous lesson. Together, the two controls answer "who can act" and "what happens if a disk or a network gets compromised anyway." The next lesson turns to a related question: how a team proves, to an auditor or a regulator, that both controls are actually in place.