SSL and Encryption at Rest: Protecting Data Both in Transit and on Disk

There are exactly two moments in a piece of data’s life when an attacker might grab it: while it’s moving from one machine to another, and while it’s sitting still on a disk somewhere. Encryption is how you protect both moments — and the frustrating thing is that getting one right does nothing for the other. A server with a perfect HTTPS setup can still leak everything if someone walks off with the hard drive. A fully encrypted disk does nothing if passwords cross the network in plain text.

This article ties those two halves together. We’ll look at encryption in transit (the SSL/TLS side, the part most people already half-know) and encryption at rest (the disk and database side, the part most people forget), and we’ll be honest about what each one actually protects you from — because that’s where most of the real mistakes hide.

The two states of data

Picture any single piece of sensitive data — a customer’s password, a credit card number, a private message. Over its lifetime it spends time in two different conditions:

• In transit — it’s moving across a network: from a browser to a server, from one server to another, between a server and its database. While it’s on the wire, anyone who can see the network traffic can read it unless it’s encrypted.
• At rest — it’s stored somewhere and not moving: written to a hard drive, saved in a database file, sitting in a backup archive. While it’s at rest, anyone who gets access to that storage can read it unless it’s encrypted.

(There’s a third state people sometimes mention — in use, meaning data loaded into a running program’s memory — but protecting that is a specialized, advanced topic. For almost everyone, “in transit” and “at rest” are the two you must handle.)

The whole point of this article is simple: these are two separate problems with two separate solutions, and you need both. Encrypting transit doesn’t encrypt your disk. Encrypting your disk doesn’t encrypt the network. Skip either one and you’ve left a door wide open.

        ┌─────────────┐        in transit         ┌─────────────┐
        │   Browser   │ ───── (TLS / HTTPS) ─────► │   Server    │
        └─────────────┘   encrypted on the wire    └──────┬──────┘
                                                          │
                                                   at rest │ (disk / DB
                                                          ▼  encryption)
                                                  ┌─────────────────┐
                                                  │  Stored data    │
                                                  │  encrypted on   │
                                                  │  the disk       │
                                                  └─────────────────┘

Encryption in transit: SSL/TLS

Let’s start with the half you’ve probably met before. Every time you see https:// and a padlock in the address bar, data between your browser and that server is encrypted in transit using TLS — Transport Layer Security. You’ll also hear it called SSL out of habit; SSL was the older protocol that TLS replaced, and the name stuck even though real SSL is long dead and insecure. When someone says “an SSL certificate” today, they almost always mean a TLS certificate.

What TLS gives you, in plain terms:

• Confidentiality — anyone watching the network (your coffee-shop Wi-Fi, an internet provider, an attacker on the same network) sees only scrambled bytes, not the actual content.
• Integrity — the data can’t be silently altered in flight without the change being detected.
• Authentication — the certificate proves you’re really talking to the server you think you are, not an impostor in the middle.

Here’s the key mental model: TLS protects data only while it’s traveling between two endpoints. The moment it arrives at the server and gets decrypted, TLS is done — it has no opinion about what happens to that data afterward. That’s exactly why transit encryption alone isn’t enough.

If you want the full mechanics of how the handshake works and what a certificate really is, that’s covered on its own. This article assumes you grasp the idea and focuses on how it slots into the bigger encryption picture. (See SSL, TLS, and HTTPS for the protocol details, and SSL certificates in practice for how you actually obtain and install one.)

Transit encryption isn’t just the public website

People remember to put HTTPS on the front door — the public website. They forget the internal connections. Data also travels in transit when:

• your application server talks to its database on another machine,
• one microservice calls another,
• a server pulls from a message queue or cache,
• you back up data over the network to remote storage.

Every one of those hops is a network connection, and every one of them can be sniffed if it’s unencrypted. A serious setup encrypts internal traffic too, not just the public-facing edge. “It’s only on our private network” is a weak defense — internal networks get breached, and once an attacker is inside, plaintext internal traffic is a buffet.

Encryption at rest: protecting the disk

Now the half people forget. Encryption at rest means the data stored on a disk is encrypted, so that if someone gets hold of the physical drive — or a stolen disk image, or a backup file — they get scrambled nonsense instead of your customers’ information.

Why does this matter if the server is locked in a data center? Because “getting the data” doesn’t require breaking into the building:

• A failed drive gets sent back to the manufacturer or thrown away — with your data still readable on it.
• A cloud provider decommissions hardware, and a disk isn’t perfectly wiped.
• An attacker copies a virtual machine’s disk image or snapshot.
• A backup file ends up on a misconfigured, publicly readable storage bucket.
• Someone with limited access to one part of the system reads raw database files they shouldn’t.

In every one of these cases, transit encryption does absolutely nothing — the data is at rest. Encryption at rest is the layer that turns “we lost a hard drive full of customer records” into “we lost a hard drive full of useless ciphertext.”

There are a few common levels at which you can apply it, and they’re not mutually exclusive:

• Full-disk encryption (FDE) — the entire disk is encrypted. Everything written to it is encrypted automatically; everything read is decrypted on the fly, transparently, as long as the system is unlocked. This protects against a stolen or improperly disposed physical disk. It does not protect a running, unlocked server from an attacker who already has access — by then the disk is decrypted and readable.
• Filesystem- or volume-level encryption — a specific volume or partition is encrypted rather than the whole disk. Same idea, finer scope.
• Database / application-level encryption — specific fields or the whole database are encrypted by the database engine or the application itself, often called Transparent Data Encryption (TDE) in database land. This can protect sensitive columns even from someone who can read the raw files, and lets you encrypt only what truly needs it.

  COARSE                                                    FINE
  ───────────────────────────────────────────────────────────►
  Full-disk         Volume / filesystem        Database / per-field
  encryption        encryption                 encryption
  (whole drive)     (one partition)            (specific data)
  protects against  protects against           protects even from
  stolen disk       stolen partition           someone reading raw files

The thing that makes or breaks encryption: keys

Here’s the part that decides whether all of the above is real protection or theater: encryption is only as strong as how you manage the keys. Encrypting data scrambles it using a secret key. Anyone who has the key can unscramble it. So the security of your data quietly becomes the security of your keys.

This leads to some uncomfortably common own-goals:

• Storing the encryption key in the same place as the encrypted data — like leaving the key taped to the lock. If an attacker steals the disk and the key sitting next to it, the encryption bought you nothing.
• Hard-coding keys into source code that ends up in a Git repository.
• Using a weak, guessable passphrase to protect a strong key.
• Never rotating keys, so a single leaked key compromises years of data.

Doing it properly means keeping keys separate from the data they protect, restricting who and what can access them, and having a plan to rotate (replace) them. Larger setups use dedicated key management — a hardware security module (HSM) or a managed key service — whose entire job is to guard keys and hand out the ability to encrypt or decrypt without ever exposing the raw key itself. The concept scales down too: at minimum, the key to your encrypted data should never live next to that data, and never in your code.

A worked example: one piece of data, both protections

Let’s trace a single password reset to see both layers doing their jobs.

1. A user, Jane Doe, types her new password into a form and hits submit.
2. In transit (TLS): the password travels from her browser to the ACY Partner Indonesia server over HTTPS. On the way, it’s encrypted — the café Wi-Fi she’s on sees only ciphertext.
3. The server receives the request and TLS decrypts it, because the application needs to actually work with the password.
4. The application doesn’t store the password directly — it hashes it (a one-way transformation, different from encryption) before saving. That’s a separate best practice, but worth noting: passwords specifically should be hashed, not just encrypted.
5. At rest: that hash, along with the rest of Jane’s record, is written to a database whose underlying disk is encrypted. If someone later steals the drive or the backup, they get ciphertext.
6. When the system needs the data back, it’s decrypted using a key that’s stored separately and access-controlled — not sitting in a file next to the database.

Notice how transit encryption (step 2) and at-rest encryption (step 5) protect completely different moments. Remove either one and there’s a window where Jane’s data is exposed.

Hashing vs. encryption — a quick but important aside

Because they get mixed up constantly: encryption is reversible, hashing is not. Encryption scrambles data so that someone with the key can unscramble it back to the original — you use it when you’ll need the original again (like reading a stored credit card to charge it). Hashing turns data into a fixed-length fingerprint that cannot be turned back — you use it when you only ever need to check a value, never recover it. Passwords are the classic case: you don’t need to know a user’s password, only whether what they typed matches, so you store a hash, not an encrypted copy. Mixing these up — encrypting passwords when you should hash them — is a frequent and serious mistake.

How this fits with everything else

Encryption is one layer in a stack, not a magic shield. It pairs with the other security work on a server: keeping the software that implements the encryption patched and current (a flaw in a TLS library can undo all of it — see keeping software updated), locking down who can reach the machine at all, and the broader habits covered in server hardening basics. Encryption protects data even if other defenses fail — but it works best as part of a layered approach, not as the only wall.

One place at-rest encryption is easy to forget: backups. A backup is a perfect, portable copy of all your data, and it often lives somewhere less guarded than the production server. If your database is encrypted but your nightly backups are written in plain text to a remote bucket, you’ve encrypted the front door and left the spare key under the mat. Backups deserve the same at-rest treatment as live data — a point worth keeping in mind when you read about backup strategies.

Wrapping up

Here’s the whole picture in one place:

• Data is vulnerable in two states: in transit (moving across a network) and at rest (stored on a disk). Each needs its own encryption, and one doesn’t cover the other.
• In transit is handled by TLS (still casually called SSL) — it encrypts data on the wire, gives you confidentiality, integrity, and authentication, but only while data is between two endpoints.
• Don’t forget internal transit: database connections, service-to-service calls, and backups over the network all need encrypting too, not just the public website.
• At rest is handled by full-disk, volume, or database-level encryption — it protects data on stolen drives, leaked snapshots, and exposed backups. Full-disk encryption mainly protects a powered-off or removed disk, so layer database-level encryption on top for sensitive data.
• Key management is the real linchpin: keep keys separate from the data they protect, control access to them, and rotate them. Encryption with the key sitting next to the data barely counts.
• Hashing (one-way, for things you only need to check, like passwords) is not the same as encryption (reversible, for things you need to recover). Don’t confuse the two.

Get both halves right — encrypt the journey and encrypt the destination, with keys kept safe — and you’ve closed the two biggest, simplest holes through which sensitive data leaks. It’s the difference between a stolen disk being a catastrophe and being a non-event.