Skip to content
Software Architecture Guide

Encrypt Data

Explanation

Section titled “Explanation”

Encrypt Data is a security tactic (see Security Tactic). It protects confidentiality: only intended parties can read the data. It covers data at rest (stored) and data in transit (moving over a network).

Data at rest. Access control decides who may read data. Encryption adds a second layer. If someone bypasses access control or copies data out, they still cannot read it without the key.

Data in transit. TLS is a standard protocol for encrypting network traffic. Done correctly, it stops attackers from reading the traffic. It also protects against tampering and replay of intercepted requests. Azure uses TLS for traffic to its services. TLS provides authentication, privacy and integrity. Forward secrecy gives each connection its own unique keys. Between datacenters, over links the provider does not physically control, Azure encrypts packets in the network hardware. This helps prevent wiretapping and man-in-the-middle attacks.

Keys matter as much as the algorithm. Good practice from the sources:

  • Treat key management as a formal, tested process. It covers generation, storage, distribution, deployment, rotation and decommissioning.
  • Generate keys randomly with a cryptographically secure function.
  • Rotate keys by criteria such as the end of a set usage period, called the cryptoperiod.
  • Never hard-code keys in source code. Never commit them to version control.
  • Use cloud key management services and hardware security modules (HSMs, dedicated devices that hold keys) where possible. Azure Key Vault and Managed HSM spare teams from running this hardware. They also keep key material out of direct application access.

Cloud options. AWS offers envelope encryption and client-side encryption. A wrapping key protects a unique data key for each object. CloudHSM provides a managed HSM used by a single customer. With customer-managed keys, you control rotation and access policy. Default service-managed keys are run by the provider. AWS advises mapping keys to data classifications instead of using one key for everything. It also warns against overly permissive key access.

Example

Section titled “Example”

A shop stores customer records in a database and serves them through a web app. The team encrypts the database storage, so a stolen disk copy is unreadable. The web app only accepts TLS connections, so nobody on the network can read orders. Payment data gets its own key, separate from the key for marketing data. Keys live in a cloud key service, never in the code, and rotate on a schedule.

Trade-offs

Section titled “Trade-offs”

The supplied facts do not quantify costs. They do show that encryption shifts the risk to keys. Keys need generation, storage, rotation and decommissioning processes, and these need testing. Using one key for all data, or giving broad key access, weakens the protection. Customer-managed keys give more control, but your team then owns rotation and access policy. Default service-managed keys leave that work to the provider.

Encryption protects data in transit and at rest, with keys held in a key service.

Diagram source 
flowchart LR
  C[Client] -- TLS encrypted --> A[Application]
  A -- encrypts with data key --> D[(Encrypted storage)]
  K[Key management service / HSM] -. provides keys .-> A

Checks

Section titled “Checks”
  • Stored private data is encrypted at rest as an extra layer on top of access control.
  • Traffic is encrypted in transit, for example with TLS.
  • Keys are mapped to data classifications, and key access is not overly permissive.
  • A formal, tested key management process covers generation, storage, rotation and decommissioning.
  • Keys are not hard-coded or committed to version control, and are held in a key management service or HSM.
Section titled “Related”

Sources

Section titled “Sources”