Protect application data with cryptography

System and boundaries

Select one sensitive data class and trace it from collection to deletion. Example: an application receives a customer recovery credential, uses it through a worker, stores it for thirty days, includes a redacted reference in audit records, backs up the database, and deletes it after the recovery window.

Draw every component that sees plaintext, ciphertext, metadata, or a key:

• Browser or API client.
• Pomerium and transport endpoints.
• Application process and memory.
• Queue and worker.
• Database engine, logs, replicas, snapshots, and backups.
• Filesystem, disk, storage service, and provider control plane.
• Key service, HSM, caches, administrators, and recovery process.
• Support, export, observability, and analytics systems.

Mark adversaries and faults. Lost media, storage credential theft, database query access, backup operator, cloud administrator, application compromise, worker compromise, KMS administrator, malicious tenant, network observer, and accidental logging have different boundaries.

Request and decision flow

Use transport encryption for every untrusted network hop with peer authentication appropriate to the connection. Transport endpoints see plaintext. If the application must protect data from storage operators or database-only compromise, encrypt at the application before storage.

Choose layers by threat:

• Device or disk encryption protects lost or retired media when keys are not available with the media.
• Filesystem or volume encryption protects offline storage access and often shares runtime authority with the host.
• Database encryption can protect files and backups and usually exposes plaintext to the database engine and authorized queries.
• Column or application encryption can separate selected data from the database and requires application key access.
• Client-side or end-to-end encryption can exclude a server from plaintext and changes search, recovery, sharing, and abuse-control design.
• In-use protection can reduce selected host or provider threats and still relies on attestation, code integrity, side-channel assumptions, and endpoint safety.

For application encryption, use authenticated encryption and bind tenant, object, purpose, and format. Use envelope encryption and narrow key-service authorization when the key model needs it. Keep the storage record versioned.

Separate decisions:

1. Route access permits a caller to reach the application.
2. Object and action authorization permits the requested data operation.
3. Workload authorization permits a cryptographic operation on a named key.
4. Data-use policy permits plaintext to be used for the stated purpose.

No one decision implies the others.

Failure domains

Test compromise and operations:

• Database credential compromise without application or key-service access.
• Application compromise with key-service decrypt permission.
• Backup theft and restore into another environment.
• KMS policy drift, disabled key, quota, latency, and region loss.
• Plaintext leakage through logs, traces, errors, crash dumps, support bundles, or temporary files.
• Ciphertext moved across tenant, object, purpose, or environment.
• Key rotation with mixed writers, readers, replicas, and old backups.
• Lost key, destroyed key, and recovery administrator compromise.
• Deletion of a record whose ciphertext, plaintext, or key remains in another copy.

For each layer, state what remains exposed. Disk encryption can pass a lost-disk test and fail a database-query test. Application encryption can pass the database-only test and fail a compromised-worker test.

Design tradeoffs and residual risk

More encryption layers add key, availability, format, performance, search, index, backup, debugging, recovery, and migration work. One broad application key simplifies operations and expands compromise. Per-record keys limit blast radius and increase KMS operations and metadata. End-to-end encryption limits server visibility and can make recovery, sharing, policy, moderation, and support difficult.

Minimize data before encrypting it. Encryption reduces some consequences of retention but does not justify collecting unnecessary data. Record the exact threat each layer covers and do not claim general protection at rest.

Pomerium boundary

Pomerium can protect the browser or client route and provide TLS to configured upstreams. It can help control human access to databases, key consoles, and support tools. TLS ends where the configured connection ends.

Pomerium does not encrypt application records, authorize key operations, prevent plaintext logging, classify data, or manage retention. Application and platform owners must isolate direct paths and choose the key and data boundary that matches the threat.

Exercise

Choose one sensitive field. Draw a table with one row for every location and transition:

1. Plaintext or ciphertext state.
2. Identity and authorization decision.
3. Key or credential used.
4. Threats blocked by this layer.
5. Threats not blocked.
6. Backup and recovery behavior.
7. Retention and deletion behavior.
8. Test and evidence.

Run four tests: database-only access, backup restore, wrong-tenant ciphertext substitution, and key-service denial. Inspect logs, traces, errors, temporary files, and support output for plaintext.

Evaluation checklist

• Does the map include every endpoint, process, copy, backup, administrator, key, and recovery path?
• Is each encryption layer tied to a stated attacker and boundary?
• Are route, object, cryptographic-operation, and data-use permissions separate?
• Does ciphertext authenticate tenant, object, purpose, and format where required?
• Can backup restore, key loss, rotation, and regional failure recover without unsafe key copies?
• Are logs, traces, crashes, temporary files, exports, and support tools free of unnecessary plaintext?
• Is retained data minimized even when it is encrypted?