Encryption (At Rest/In Transit)
Overview
Data security fundamentals cover how sensitive data is protected in its two basic states: while it moves across a network and while it sits in storage. Encryption in transit protects data on the wire while encryption at rest protects data on disk, and a secure system applies both.
Key Concepts
Encryption in transit protects data as it travels between a client and a server, or between services. It is provided by TLS (Transport Layer Security), the protocol underneath HTTPS, which encrypts the connection so anyone sniffing the network sees only ciphertext. TLS also authenticates the server through certificates, which defeats man-in-the-middle attacks.
Encryption at rest protects stored data so that stealing a disk, a backup, or a database file yields only ciphertext. It can be applied at several layers: full-disk encryption, transparent database encryption, or fine-grained field-level encryption of specific columns such as passwords or card numbers. Its security depends on key management - keys are held in a dedicated key management service (KMS) or hardware security module, rotated periodically, and never stored beside the data they protect.
The two protections are complementary and cover different threats: encryption in transit does nothing for a stolen backup, and encryption at rest does nothing for a sniffed connection. Both are usually paired with strong authentication and authorization, which controls who can request the data in the first place.
| Aspect | Encryption in transit | Encryption at rest |
|---|---|---|
| Protects data that is | Moving across a network | Stored on disk or in a backup |
| Typical mechanism | TLS / HTTPS | Disk, database, or field-level encryption |
| Threat addressed | Eavesdropping, man-in-the-middle | Stolen disk, leaked backup |
| Key concern | Certificate management | Key management (KMS) |
Trade-offs
Encryption adds CPU cost and a little latency, though hardware acceleration makes TLS overhead negligible for most systems. The harder problem is operational: key management is where real-world encryption usually fails - lost keys mean lost data, and leaked keys void the protection entirely. Encryption at rest also does nothing against an attacker who compromises the running application, because the app sees decrypted data; that threat needs authorization and field-level controls instead.
Interview Tips
- Name both states explicitly - "encrypt in transit with TLS and at rest with a managed KMS" - because candidates often mention only one.
- Call out that key management, not the choice of cipher, is the hard part.
- For especially sensitive fields such as passwords or payment data, mention field-level encryption or hashing on top of the blanket protections.
Summary
- Data must be protected in two states: in transit across the network and at rest in storage.
- Encryption in transit uses TLS, the basis of HTTPS, to defeat eavesdropping and man-in-the-middle attacks.
- Encryption at rest keeps stored data as ciphertext so a stolen disk or backup is useless.
- Key management through a KMS is the hardest and most critical part of encryption at rest.
- The two are complementary and pair with authentication and authorization to control access.