Encryption at rest and in transit

Why this matters

Servers hold the data an organisation most needs to protect, and that data is exposed in two situations: while it sits on disks, tapes and backups, and while it travels across networks. Encryption protects it in both, by making it unreadable to anyone without the right key.

Encryption is also easy to get wrong in ways that matter. A server can be encrypted and still leak everything to an attacker who logs in normally. A key can be protected so well that the organisation cannot recover its own data. And a certificate can expire and take a service down. This lesson covers the kinds of encryption used on servers, how they are managed, and exactly what each one does and does not protect against.

The lesson

Full-disk and volume encryption -- BitLocker and LUKS -- and the TPM

Encryption at rest protects stored data. The broadest form encrypts an entire disk or volume, so everything on it, including the operating system, temporary files and swap space, is unreadable without the key.

• BitLocker is Windows' built-in volume encryption, available on Windows Server as an optional feature.
• LUKS (Linux Unified Key Setup) is the standard for disk encryption on Linux, set up with the cryptsetup tool, often during installation.

Some drives also encrypt themselves in hardware; these are called self-encrypting drives (SEDs).

The question every disk encryption system must answer is where the key comes from at boot. On a desktop, a person can type a password. On a server that must restart unattended, that is impractical. The usual answer is the TPM (Trusted Platform Module), a chip on the motherboard that stores keys securely and releases them only if the boot process has not been tampered with. BitLocker can use the TPM to unlock the volume automatically, while an attacker who moves the disk to another machine gets nothing. On Linux, the key can be sealed to the TPM in a similar way, or retrieved from a key server on the network during boot, so that a server only unlocks when it is on its own network.

File-level and database encryption

Full-disk encryption protects everything on a disk against physical theft. More targeted encryption protects particular data even from people who can use the running system.

File-level encryption encrypts individual files or folders, such as with Windows' Encrypting File System (EFS), which ties encryption to a user's account so that other users, including some administrators, cannot read the files.

Database encryption comes in two main forms:

• Transparent data encryption (TDE), offered by SQL Server, Oracle and other databases, encrypts the database files and their backups on disk. It is transparent because applications need no changes: data is decrypted as the database reads it. It protects stolen files and backups, but not data queried through the database.
• Column-level or field-level encryption encrypts particular sensitive fields, such as card numbers or identity numbers, so even someone with access to the database sees only ciphertext unless they also hold the key.

The more targeted the encryption, the more it protects against insiders and compromised accounts, and the more work it takes to manage.

TLS for server services, and the certificates behind it

Encryption in transit protects data as it crosses a network. For most server services this is TLS (Transport Layer Security), the protocol behind HTTPS and also used to secure mail, directory lookups (LDAPS), databases and remote management. Older SSL versions and early TLS versions are insecure and should be disabled; current servers should use TLS 1.2 or 1.3. Other protocols protect other traffic: SSH for remote administration and file transfer, and IPsec for encrypting traffic between networks or hosts.

TLS depends on certificates. A server certificate contains the server's name and public key and is signed by a certificate authority (CA). Clients trust the certificate if it was signed by a CA they trust, if it names the server they connected to, and if it has not expired or been revoked. Public-facing services use certificates from public CAs; internal services often use an organisation's own internal CA, whose root certificate is distributed to its computers.

Certificates cause two familiar problems. A certificate whose name does not match the address users type produces warnings. And certificates expire: an expired certificate stops clients connecting, often all at once. Track expiry dates, and automate renewal where possible.

Key management, and recovery keys you can actually find

Encryption is only as strong as the protection of its keys, and only as useful as the organisation's ability to find them when needed.

Key management covers generating keys, storing them securely, controlling who can use them, rotating them periodically, and destroying them at the end of their life. Keys should never be stored alongside the data they protect. High security environments use a hardware security module (HSM), a dedicated device that stores keys and performs cryptographic operations without the keys ever leaving it. Cloud providers offer key management services for the same purpose.

The opposite risk is losing access. When a TPM detects a change, such as a motherboard replacement or a firmware update, BitLocker asks for its recovery key. If nobody can find that key, the data is gone, as surely as if the disk had been destroyed. Recovery keys must be escrowed: BitLocker can store them in Active Directory or a management service, and LUKS supports additional key slots holding a recovery passphrase kept in a secure vault. Test that recovery works before relying on it, and suspend BitLocker before planned firmware updates so the TPM does not lock the volume.

What encryption protects against, and what it does not

Encryption is often described as though it makes data safe. It protects against specific threats only.

Full-disk encryption protects against physical loss: a stolen server, a removed disk, a drive sent for repair or disposed of improperly, or a lost backup tape. It also makes retiring a disk simpler, since destroying the key makes the data unreadable.

It does not protect a running system. Once a server has booted and unlocked its volumes, the data is readable to anyone who can use the server: an attacker who has stolen an administrator's password, malware running on the server, or an application flaw that exposes data. To them, the disk is simply unencrypted.

TLS protects data from being read or altered on the network, but not at either end: the data is decrypted on arrival, and a compromised server or client sees it in full.

Encryption also does not stop ransomware, which does its damage by encrypting data itself, or protect data from being deleted, or replace access controls. That is why encryption is one layer among several in the security domain, next to accounts and permissions, hardening and physical security, rather than a single answer.