At Rest encryption

At Rest Encryption

1) Why it is needed and what exactly we protect

Definition. Encryption at rest is the protection of data written to media (disks, snapshots, backups, objects, logs, memory dumps) so that unauthorized access to physical media or to "raw" storage does not reveal content.

• Block/file volumes, object storages, databases, queues/caveles, cache dumps, logs/trails, backups, export/import, VM/container snapshots, kernel/process dumps, swap/swap.
• Multi-lease scenarios: isolation between clients/projects/environments.

What we do not fully cover: theft of sessions in memory, attacks on a live process, application vulnerabilities, compromise of credentials. This requires in-flight encryption, strong authentication/authorization, rights minimization and monitoring (see related articles: "Authentication and authorization," "Signing and verifying requests").

2) Threat model and control objectives

• Loss/theft of media (disk, tape, USB, developer device).
• Unauthorized access to backups/snapshots/logs.
• Abuse of privileges at the platform/hypervisor/storage node level.
• Crossing tenants for configuration errors.
• "Littered" temporary files and dumps that fall into artifacts and images.

1. Confidentiality of data on the medium.

2. Cryptographic isolation of tenants/environments.

3. Key manageability (creation, storage, rotation, revocation).

4. Auditability (who used the key and when).

5. Minimization of operational risks in case of incidents.

3) Architecture fundamentals

We encrypt everything by default. Opt-out is not allowed without exceptions at the risk level.
Key hierarchy (envelope encryption). Root/KEK → DEK (data encryption keys) → database objects/files/pages.
KMS/HSM as a source of trust. KEK generation and storage in KMS/HSM, key wrapping/deployment operations are performed there.
Per-tenant/per-dataset keys. Granularity for isolation and rotation requirements.
Separation of duties. Platform commands ≠ tenant key owners; minimum privileges (PoLP).
Crypto-agility. Ability to safely migrate algorithms/key lengths.
Rotation as a process, not an event. Keys and data must support "rolling" replacement.

4) Encryption algorithms and modes

For objects/files/records: AES-256-GCM or AES-256-SIV (AEAD with authentication).
For block devices/volumes: AES-XTS-256/512 (protection against block permutations; not AEAD - use over file formats with MAC where integrity is important).

• TDE (Transparent Data Encryption) движка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE и пр.
• Field/line cryptography (FPE/deterministic encryption) - for search capabilities/joynes on encrypted fields; apply prudently.
• Key generation and storage: KEK - in KMS/HSM; DEK - in the memory of applications short-lived, during storage - only wrapped.

5) Key hierarchy and KMS/HSM

1. Root key (statutory, in HSM/KMS). Does not leave the HSM/KMS perimeter.

2. KEK (Key Encryption Key). For the project/environment/tenant. Manages the DEK lifecycle.

3. DEK (Data Encryption Key). Per object/file/table/segment. Short-lived, rotating non-stop.

• All wrapping/deployment operations are via KMS API with audit.
• Politicians: who can "use" the key ≠ who can "control" the key.
• Key geo-distribution: pin-to-region + dual-control for inter-region.
• A "two-check" model (two operators) is possible for high-risk operations.
• To isolate a strong level - separate key-rings per tenant.

6) Rotation, recall and compliance

DEK rotation: transparent and constant (rolling re-encryption at the object/page level).
KEK rotation: periodic (eg, every 6-12 months) + immediate recall if suspected of being compromised.
Revocation of access: through KMS policies; blocking unwrap operations = instant "crypto-destroyability" of data.
Audit logs: who, when, with what rights used the keys; store separately and also encrypt.
Regulations and standards: we focus on industry requirements (for example, GDPR/PCI permits/local regulators), we use certified cryptographic modules (for example, compliance with certification levels).

7) Patterns by storage type

7. 1 Block/file volumes and VM/containers

Full disk encryption (XTS) + key management via KMS (volume initialization during mount).
Protect swap, crash dumps, tmp directories, container overlay layers ,/AMI images.
Snapshots/snapshots - always encrypted with separate DEKs.

7. 2 Object storage

Envelope encryption: unique DEK per object; headers/metadata - no PII leaks.
Control access to the KMS key by tenants and environments.
Server-side encryption (SSE with its own KMS) or client-side (CSE) - choose according to the trust model.

7. 3 Databases

Enable TDE where available; bind database keys to KMS via plugin/extension.
For especially sensitive fields - application encryption (AEAD) before entering the database.
Redo logs/transaction logs, archive logs, dumps - encrypt separately, keys - separate.

7. 4 Logs/Trails/Metrics

Log format - without sensitive data by default (sanitation).
Log archives - separate keys and short TTL storage.
Access to reading logs - through a proxy service with A&A and audit.

7. 5 Backups and offline media

Always encrypt at the client before writing to tape/cloud.
Store keys separately (out-of-band), escrow with separate control.
For emergency cases, splitting the secret (for example, m-of-n) to restore master access.

8) Multi-tenant

Key to tenant: KEK-per-tenant + DEK-per-dataset.
Policy isolation: KMS namespaces, IAM boundaries, individual IDP roles.
Removal at the request of the client: "crypto-erase" - withdraw the tenant's KEK and destroy DEK.
Client reporting: compliance artifacts, key access logs, rotation confirmation.

9) Performance and operation

Hardware accelerations (AES-NI/x86, ARMv8 Crypto Extensions).
Hot path profiling: encrypt at I/O boundaries, avoid double encryption unnecessarily.
KMS session pools, caching wrapped DEKs in memory (with TTL and dump protection).
SLO/metrics: unwrap latency, proportion of "re-encrypted" objects, KMS errors, backup encryption speed.

10) Reference runbook

Step 0 - Data inventory. Catalog all repositories and leakage paths (tmp, dumps, export, analytics buckets).
Step 1 - key hierarchy design. We determine the KEK/DEK levels, granularity, regions, roles.
Step 2 - select modes/libraries. Approved algorithms, crypto libraries, version policies.
Step 3 - integration with KMS/HSM. Generation/wrapping/auditing, IAM policies, geo-pinning.
Step 4 - encryption per write. Enable by default, migration of existing data through the background reencryption.

Step 5 - rotation and emergency scenarios. Regulations, tests "key compromise," "KMS is not available."

Step 6 - monitoring and auditing. Dashboards, alerts, regular compliance reports.
Step 7 - training and "secure coding." Guides for engineers, prohibition of displaying secrets in logs/dumps.

11) Testing and verification

Crypto unit tests: correctness of AEAD (tag check), validation of failure when a byte is changed.
Failure-tests: disabling KMS, outdated key versions, forced KEK revocation.
Red/Blue tests: attempts to read the "raw" disk/snapshot/backup.
Compatibility check: migration of algorithms/key lengths (crypto-agility).
Library attestation: use only verified crypto modules; commit versions.

12) Frequent mistakes and how to avoid them

Double encryption without meaning. Extra latency and complexity. Hold a layer that gives the desired granularity and isolation.
Store keys next to data. Keys are always separate, under a different access model.
Forgotten artifacts. Unencrypted temporary files, CSV export, support dumps. Enable monitoring in CI/CD and Data Loss Prevention.
Lack of rotation. Make the rotation part of the pipeline/cron, not a manual procedure.
Logs with sensitive data. Enter a contract for log format and automatic sanitizers.

13) Mini recipes (pseudocode)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) Checklists

• Default encryption is enabled on all storage types.
• The key hierarchy is described and implemented; roles and IAM policies are configured.
• KMS/HSM integrated, key operations auditing enabled.
• DEK/KEK rotation is automated; compromise scenarios worked out.
• Backups, snapshots, logs and dumps - encrypted; keys are stored separately.
• Configured alerts for KMS errors, AEAD tag deviations, proportion of unencrypted artifacts.
• KMS unavailability and key revocation tests passed.

• Monthly report on key usage and access attempts.
• Crypto-agility plan and window for painless algorithm migration.
• Periodic Red-team to extract data from raw media.

15) Q&A (FAQ)

Q: Is full disk encryption sufficient?
A: For physical risks - yes, but for the isolation of tenants and flexible rotation better envelope with DEK-on-object/set.

Q: What to do when KEK is compromised?
A: Immediately recall KEK to KMS, re-release new, rewrap all DEKs, check logs and run RCA.

Q: How do we encrypt the fields we are looking for?
A: Use deterministic schemes or FPEs only in rigorous risk assessment (pattern leks). It is better to design queries so that sensitive fields do not require an indexed open view.

Q: Do I need a separate command for the keys?
A: The Crypto/KMS Operator is recommended as a role with separate rights and procedures.

• "Key Management and Rotation"
• "S2S Authentication"
• "Sign and Verify Requests"
• "Connect OAuth2/OpenID in Kernel"
• "Webhook Delivery Guarantees"