Encryption at Rest & In Transit

## What "encryption at rest" means in AWS Server-side encryption at rest is a property of the storage layer, not of your application. When you write an object to S3, a block to an EBS volume, a row to an RDS instance or an item to DynamoDB, the service encrypts the bytes before they are persisted and decrypts them when they are read back. The client sends and receives plaintext; the ciphertext exists only on AWS's storage media and in the backups and snapshots derived from it. The key material comes from one of two places. Some services use keys the service manages internally, and some use AWS KMS. In the KMS case the service does not encrypt megabytes under the KMS key directly — it asks KMS for a data key, uses that to encrypt the payload, and stores the protected form of the data key alongside the data. From your side the important consequence is simply that a KMS call happens on the data path, and that call is itself authorized. The crucial word is *transparent*. There is no ciphertext to handle, no key to ship to your application, and no code change: ```bash aws s3api get-object --bucket reports --key q3.csv out.csv # S3 decrypts server-side; out.csv is plaintext, no key material touched the client ``` ## The threat model it actually addresses At-rest encryption defends against an adversary who obtains the *storage*, not an adversary who obtains a *credential*. Concretely: - **Media disposal.** A drive leaves an AWS data centre. Without encryption the residual blocks are readable; with it they are not. - **Copies that escape the service API.** A snapshot copied to another account, a database backup restored somewhere unintended, an EBS volume detached and attached to a different instance. Encryption means the copy is inert without the corresponding key permission — and for KMS-backed volumes and snapshots, that permission is a separate thing you control. - **Compliance obligations.** Many regimes and customer contracts require the control regardless of the threat, and "encrypted at rest with a customer managed key" is the checkbox they are actually asking about. ## What it does not address It does not protect against anything that arrives through the front door: - **A leaked or over-permissioned credential.** A stolen access key with `s3:GetObject` reads plaintext. The bytes being encrypted on disk is irrelevant to the API call. - **A public or over-broad resource policy.** An encrypted bucket that is publicly readable is a publicly readable bucket. This is the single most common misconception in interviews. - **Application-layer bugs.** SQL injection, a broken authorization check, an object-reference flaw — all of them run as an authorized principal. - **Compromise of the compute.** Whoever controls a running EC2 instance sees the file system in plaintext; the EBS encryption boundary is below the OS. - **Data in transit or in use.** Encryption at rest says nothing about whether the connection was TLS, and nothing about memory. Those are separate controls. ## Where it does become access control There is one real exception, and it is worth naming because it is the reason teams choose a customer managed KMS key over a service default. When the data is encrypted under a KMS key you own, reading it requires *two* authorizations: the service action (`s3:GetObject`) and the key action (`kms:Decrypt`). The key policy is evaluated on its own, so it can deny a principal that the resource policy allows. That gives you a second, independently administered lever — useful for separating duties between a data team and a security team, for making cross-account sharing explicit, and for revoking access to an entire dataset by editing one policy rather than hunting through many. ## How to talk about it The answer an interviewer is listening for has three beats: it protects the media and the copies, it is transparent to authorized callers so it is not an access control, and the KMS key policy is the part that *is* one. Saying "we encrypt everything at rest" as if it were a security posture — rather than one layer beneath least-privilege IAM, resource policies, network boundaries and logging — is what marks a weak answer. Encryption at rest is close to free and you should turn it on everywhere; just do not let it stand in for the controls that actually decide who may read the data.