Data Protection Architecture Reference
Data Protection Architecture Reference
CIPHER Training Module -- Comprehensive encryption, key management, and data lifecycle security
Table of Contents
- Encryption at Rest
- Encryption in Transit
- Encryption in Use
- Envelope Encryption Pattern
- Key Hierarchy Design
- Key Rotation Strategies
- Secrets Management Architecture
- Data Classification and Handling
- Tokenization vs Encryption
- Data Masking and Anonymization
- Secure Deletion and Crypto-Shredding
- Backup Encryption
- Algorithm Reference
- Anti-Patterns and Common Failures
1. Encryption at Rest
Protection of stored data across all persistence layers. Defense against physical theft, unauthorized disk access, insider threats, and backup compromise.
1.1 Full Disk Encryption (FDE)
Encrypts entire block devices transparently. OS and applications read/write without awareness.
| Platform | Technology | Algorithm | Notes |
|---|---|---|---|
| Linux | LUKS2 / dm-crypt | AES-256-XTS | Default for modern distros; supports multiple key slots |
| Windows | BitLocker | AES-256-XTS | Requires TPM 1.2+ for boot protection; supports recovery keys |
| macOS | FileVault 2 | AES-256-XTS | Integrated with Secure Enclave on Apple Silicon |
| Cloud | AWS EBS encryption | AES-256 | Uses AWS KMS; enabled per-volume or as account default |
| Cloud | GCP Persistent Disk | AES-256 | Default encryption; CMEK optional via Cloud KMS |
| Cloud | Azure Disk Encryption | AES-256 | Uses Azure Key Vault for key management |
Limitations of FDE:
- Protects only against offline attacks (stolen disk, decommissioned hardware)
- Data is decrypted transparently when the OS is running -- no protection against authenticated users, application-layer compromise, or memory scraping
- Does not protect data in transit between disk and application
- Cloud provider FDE does not protect against provider-side access unless using CSEK
When FDE is insufficient: Multi-tenant environments, compliance requiring field-level audit trails, protection against privileged insiders, database-level access control.
1.2 File-Level Encryption
Encrypts individual files or directories. Granular control over what is protected.
| Tool | Backend | Use Case |
|---|---|---|
| eCryptfs | AES-256-CBC + HMAC | Linux home directory encryption |
| fscrypt | AES-256-XTS + AES-256-CTS | Linux filesystem-native (ext4, f2fs) |
| VeraCrypt | AES/Serpent/Twofish cascade | Portable encrypted volumes |
| age | X25519 + ChaCha20-Poly1305 | Modern file encryption, scriptable |
| GPG | RSA/ECC + AES-256 | Legacy but widely deployed |
SOPS for structured files: Mozilla SOPS encrypts values within YAML/JSON/ENV/INI files while preserving keys (structure) in plaintext. This enables version control diffs on encrypted configuration.
# .sops.yaml -- declarative encryption policy
creation_rules:
- path_regex: production/.*\.yaml$
kms: arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID
age: age1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
- path_regex: staging/.*\.yaml$
age: age1yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
SOPS internals:
- Symmetric encryption: AES-256-GCM for data values
- Each KMS/PGP/age recipient gets a wrapped copy of the data key
- MAC integrity verification prevents tampering
- Key groups enable m-of-n threshold schemes (multiple independent key groups; decryption requires satisfying at least one complete group)
sops rotatere-encrypts with updated keys;sops updatekeyssyncs with.sops.yaml- Decryption order configurable:
--decryption-order age,pgp(offline methods before online)
1.3 Database Encryption
Transparent Data Encryption (TDE)
Encrypts data files at the storage engine level. Application code unchanged.
| Database | TDE Support | Key Management |
|---|---|---|
| PostgreSQL | pgcrypto extension; native TDE in PG 16+ | External KMS or file-based |
| MySQL/MariaDB | InnoDB tablespace encryption | keyring plugin (file, KMIP, Vault) |
| SQL Server | TDE with certificate hierarchy | Database Master Key -> Certificate -> DEK |
| MongoDB | Encrypted Storage Engine (Enterprise) | KMIP, AWS KMS, Azure Key Vault, GCP KMS |
| Oracle | TDE (tablespace or column) | Oracle Wallet or OKV |
TDE limitations: Protects data on disk only. Decrypted in buffer pool -- visible to anyone with database query access. Does not protect against SQL injection, application compromise, or privileged DBA access.
Column-Level Encryption
Encrypts specific columns containing sensitive data. Data remains encrypted in memory and query results unless explicitly decrypted by authorized code paths.
-- PostgreSQL with pgcrypto
INSERT INTO users (email, ssn_encrypted)
VALUES (
'user@example.com',
pgp_sym_encrypt('123-45-6789', current_setting('app.encryption_key'))
);
-- Decrypt
SELECT pgp_sym_decrypt(ssn_encrypted, current_setting('app.encryption_key'))
FROM users WHERE id = 1;
Trade-offs:
- Cannot index encrypted columns (unless using deterministic encryption, which leaks equality)
- Cannot perform range queries on encrypted data
- Application must manage encryption/decryption logic
- Key distribution to application tier required
Application-Level Encryption (ALE)
Data encrypted before it reaches the database. Maximum control, maximum complexity.
from aws_encryption_sdk import EncryptionSDKClient, CommitmentPolicy
from aws_encryption_sdk.key_providers.kms import KMSMasterKeyProvider
client = EncryptionSDKClient(
commitment_policy=CommitmentPolicy.REQUIRE_ENCRYPT_REQUIRE_DECRYPT
)
provider = KMSMasterKeyProvider(key_ids=["arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID"])
# Encrypt with context binding (AAD)
ciphertext, header = client.encrypt(
source=plaintext_bytes,
key_provider=provider,
encryption_context={"tenant_id": "acme", "field": "ssn"}
)
AWS Encryption SDK patterns:
- Envelope encryption: DEK encrypts data, master key wraps DEK
- Multi-keyring:
AwsKmsMultiKeyringwraps DEK with multiple KMS keys -- any single key can decrypt (redundancy + multi-region) - Discovery keyring:
AwsKmsDiscoveryKeyringfor decryption without pre-specifying key ARNs (useDiscoveryFilterto restrict by AWS account + partition) - Encryption context (AAD): Non-secret key-value pairs bound to ciphertext. Verified on decrypt. Appears in CloudTrail. Use for tenant isolation, field identification, audit correlation
- Caching CMM:
CachingCryptoMaterialsManagercaches data keys to reduce KMS API calls. Setmax_age,max_bytes_encrypted,max_messages_encryptedlimits - Streaming: File-like objects for large payloads without full memory load
- Key commitment:
REQUIRE_ENCRYPT_REQUIRE_DECRYPTpolicy prevents algorithm downgrade attacks - Message format: Header (algorithm suite, encrypted data keys per wrapping key) + ciphertext + auth tag
When to use ALE:
- Data must be protected from database administrators
- Multi-tenant isolation at the crypto level
- Compliance requires end-to-end encryption (data encrypted from client to storage)
- Data transits multiple systems and must remain protected throughout
1.4 Database Connection Security
OWASP mandates: "Configure the database to only allow encrypted connections" with TLSv1.2+ using modern ciphers (AES-GCM or ChaCha20-Poly1305) and certificate verification.
Hardening checklist:
- Disable default/sample databases (Northwind, AdventureWorks)
- Disable dangerous features:
xp_cmdshell,xp_dirtree, CLR execution (SQL Server);FILEprivilege (MySQL) - Run
mysql_secure_installationfor MySQL/MariaDB - Never use built-in admin accounts (
root,sa,SYS) for application access - Implement row-level security where supported
- Separate database accounts per environment (dev/staging/prod)
- Store credentials outside web root, never in source code
2. Encryption in Transit
Protection of data moving between systems. Defense against eavesdropping, MITM, and tampering.
2.1 TLS (Transport Layer Security)
The baseline for all network communication.
Minimum configuration (2026):
- TLS 1.3 preferred; TLS 1.2 minimum
- TLS 1.0, 1.1, SSL 3.0: DISABLED
- Certificate validation: mandatory (no
verify=False, noInsecureSkipVerify)
TLS 1.3 cipher suites (all AEAD, all with PFS):
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS 1.2 recommended suites (ECDHE for PFS):
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
Certificate management:
- ECDSA P-256 or P-384 certificates preferred over RSA (smaller, faster)
- RSA minimum 2048-bit; prefer 4096-bit for longevity
- OCSP stapling enabled
- CAA DNS records to restrict issuance
- Certificate Transparency monitoring
- Automated renewal (ACME/Let's Encrypt or internal PKI)
Perfect Forward Secrecy (PFS): Ephemeral key exchange (ECDHE) ensures compromise of the server's long-term key does not retroactively compromise past session traffic. TLS 1.3 mandates PFS for all connections. [CONFIRMED]
2.2 Mutual TLS (mTLS)
Both client and server authenticate via certificates. Required for zero-trust service-to-service communication.
Architecture:
Service A Service B
| |
|-- Client cert + Server cert--|
| (both verified by CA) |
| |
Internal PKI (Vault PKI, CFSSL, step-ca)
Implementation patterns:
- Service mesh (Istio/Linkerd): Automatic mTLS between sidecars; application unaware
- Vault PKI engine: Dynamic short-lived certificates (TTL minutes to hours); automatic rotation
- SPIFFE/SPIRE: Workload identity framework; X.509 SVIDs for service authentication
mTLS certificate lifecycle:
- Service requests certificate from PKI (Vault, step-ca)
- PKI validates identity (K8s service account, AWS IAM role, etc.)
- Short-lived certificate issued (1-24h TTL)
- Certificate auto-renewed before expiry
- CRL/OCSP for revocation (or just let short-lived certs expire)
2.3 WireGuard
Modern VPN protocol. Simple, fast, cryptographically opinionated.
| Property | Value |
|---|---|
| Key exchange | Curve25519 (ECDH) |
| Symmetric encryption | ChaCha20-Poly1305 |
| Hashing | BLAKE2s |
| MAC | Poly1305 |
| Key derivation | HKDF |
Use cases: Site-to-site VPN, remote access, overlay networking (Tailscale, Netmaker), cloud interconnect.
Security properties: Minimal attack surface (~4,000 lines of code), no cipher negotiation (eliminates downgrade attacks), silent to unauthenticated packets (stealth), 1-RTT handshake.
2.4 IPSec
Legacy but still dominant in enterprise and cloud provider interconnects.
| Mode | Protection | Use Case |
|---|---|---|
| Transport | Payload only | Host-to-host |
| Tunnel | Entire packet (new IP header) | Site-to-site VPN, cloud interconnect |
Components: IKEv2 for key exchange, ESP for encryption (AES-256-GCM), AH for authentication only (rarely used alone).
When IPSec over WireGuard: Regulatory compliance requiring FIPS-validated crypto modules, interoperability with legacy equipment, cloud provider VPN gateways (AWS VPN, Azure VPN Gateway).
2.5 Application-Layer Encryption
For end-to-end protection where transport encryption terminates at a proxy/load balancer:
- gRPC: Native TLS support; mTLS via channel credentials
- Message queues: TLS for broker connections + message-level encryption for payload confidentiality through brokers
- Email: S/MIME or PGP for message-level; STARTTLS for transport
- Signal Protocol: Double Ratchet for forward secrecy + future secrecy in messaging
3. Encryption in Use
Protection of data during processing. The hardest problem in applied cryptography.
3.1 Confidential Computing (Hardware Enclaves)
Trusted Execution Environments (TEEs) create hardware-isolated memory regions.
| Technology | Vendor | Protection |
|---|---|---|
| Intel SGX | Intel | Application-level enclaves; encrypted memory pages |
| Intel TDX | Intel | VM-level isolation; encrypted VM memory |
| AMD SEV-SNP | AMD | VM-level; encrypted memory + integrity + nested paging |
| ARM CCA | ARM | Realm management; hardware-enforced isolation |
| AWS Nitro Enclaves | AWS | Isolated VM with no persistent storage, no network |
| Azure Confidential VMs | Azure | SEV-SNP or TDX backed |
| GCP Confidential VMs | GCP | SEV-SNP backed |
Threat model: Protects against:
- Cloud provider infrastructure administrators
- Compromised hypervisor
- Physical access to server hardware
- Co-tenant attacks
Does NOT protect against:
- Bugs in the enclave code itself
- Side-channel attacks (some mitigated in newer generations)
- Denial of service by the host
Attestation flow:
- Enclave generates attestation report (signed by hardware)
- Report contains code measurement (hash of loaded code)
- Remote party verifies report against expected measurement
- Establishes encrypted channel to enclave
- Sensitive data sent only after attestation succeeds
3.2 Homomorphic Encryption (HE)
Computation on encrypted data without decryption. Theoretically ideal, practically limited.
| Scheme | Operations | Performance | Libraries |
|---|---|---|---|
| BFV/BGV | Addition + multiplication (bounded depth) | ~1000x overhead | SEAL, HElib |
| CKKS | Approximate arithmetic on reals | ~100-1000x overhead | SEAL, Lattigo |
| TFHE | Boolean circuits (arbitrary computation) | ~10000x per gate | concrete, tfhe-rs |
Practical use cases (2026): Private set intersection, encrypted database lookups, privacy-preserving analytics, secure aggregation in federated learning.
Not practical for: General-purpose computation, real-time systems, anything requiring low latency.
3.3 Secure Multi-Party Computation (MPC)
Multiple parties compute a function over their inputs without revealing inputs to each other.
Protocols: Garbled circuits (Yao), secret sharing (Shamir, replicated), oblivious transfer.
Real-world deployments: Private auction systems, joint financial crime detection, privacy-preserving key management (threshold signatures, distributed key generation).
3.4 Memory Protection Techniques
For sensitive data in application memory:
| Language | Unsafe | Secure Alternative |
|---|---|---|
| Java/.NET | String (immutable, GC-managed) |
byte[] / char[] (manually zeroed) |
| Python | str (immutable) |
bytearray (mutable, zeroable) |
| Rust | Stack allocation | secrecy::Secret<T> (zeroed on drop) |
| C/C++ | Stack/heap | sodium_mlock() + sodium_memzero() |
| Go | []byte |
memguard library |
OS-level protections:
mlock()/VirtualLock(): Prevent memory from being swapped to diskmadvise(MADV_DONTDUMP): Exclude from core dumpsprctl(PR_SET_DUMPABLE, 0): Disable ptrace attachment
4. Envelope Encryption Pattern
The foundational pattern for scalable data encryption. Used by AWS KMS, GCP Cloud KMS, Azure Key Vault, and HashiCorp Vault transit engine.
4.1 Architecture
+------------------+
| Master Key | (HSM / Cloud KMS -- never exported)
+--------+---------+
|
wraps / unwraps
|
+--------v---------+
| KEK (Key | (Stored in KMS; may have multiple versions)
| Encryption Key)|
+--------+---------+
|
wraps / unwraps
|
+--------v---------+
| DEK (Data | (Generated locally; unique per data object)
| Encryption Key)|
+--------+---------+
|
encrypts / decrypts
|
+--------v---------+
| Plaintext Data |
+------------------+
4.2 Encryption Flow
1. Application requests new DEK from KMS
2. KMS generates DEK, returns {plaintext_DEK, wrapped_DEK}
3. Application encrypts data with plaintext_DEK (AES-256-GCM)
4. Application stores {ciphertext, wrapped_DEK, encryption_context} together
5. Application discards plaintext_DEK from memory (zero + free)
4.3 Decryption Flow
1. Application reads {ciphertext, wrapped_DEK, encryption_context}
2. Application sends wrapped_DEK + encryption_context to KMS
3. KMS unwraps DEK (verifies encryption context), returns plaintext_DEK
4. Application decrypts ciphertext with plaintext_DEK
5. Application discards plaintext_DEK from memory
4.4 Why Envelope Encryption
| Concern | Direct KMS Encryption | Envelope Encryption |
|---|---|---|
| Data size limit | 4-64 KiB (KMS API limit) | Unlimited |
| Latency | Every encrypt/decrypt hits KMS | KMS call only for key operations |
| Throughput | Bounded by KMS API rate limits | Local crypto at hardware speed |
| Key rotation | Re-encrypt all data | Re-wrap DEKs only (or generate new DEKs for new writes) |
| Offline operation | Impossible | Possible with cached DEKs |
4.5 GCP Cloud KMS Implementation
GCP-specific details:
- Cloud KMS designed to manage KEKs; direct encryption limited to 64 KiB
- Key hierarchy: Project -> Key Ring (regional) -> Key -> Key Version
- CMEK (Customer-Managed Encryption Keys): You control keys in Cloud KMS; integrated with Cloud Storage, Compute Engine, Cloud SQL, BigQuery, Datastore
- CSEK (Customer-Supplied Encryption Keys): You supply AES-256 key for specific operations; available for Cloud Storage and Compute Engine (largely superseded by key import to CMEK)
- DEK best practices per GCP: generate new DEK per write operation; never store plaintext DEK; never share DEK across tenants; use AES-256-GCM
4.6 AWS Encryption SDK Implementation
The SDK abstracts envelope encryption into a clean API:
- Keyring generates and wraps DEKs
- Multi-keyring wraps DEK with multiple KMS keys for redundancy/multi-region
- Encryption context provides AAD binding (appears in CloudTrail for audit)
- Caching CMM reduces KMS API calls by caching plaintext DEKs with configurable limits (max age, max bytes encrypted, max messages)
- Key commitment (
REQUIRE_ENCRYPT_REQUIRE_DECRYPT) prevents an attacker from crafting ciphertext decryptable under multiple keys
5. Key Hierarchy Design
5.1 Three-Tier Hierarchy
Tier 1: Root / Master Key
- Stored in HSM (FIPS 140-2 Level 3+) or cloud KMS
- Never exported, never directly used for data encryption
- Split using Shamir's Secret Sharing (m-of-n threshold)
- Minimal number of operations: wraps Tier 2 keys only
Tier 2: Key Encryption Keys (KEKs)
- Wrapped by master key
- Purpose-specific: one KEK per service, tenant, or data classification
- Stored encrypted in key management system
- Rotated on schedule (90 days typical) or on compromise
Tier 3: Data Encryption Keys (DEKs)
- Generated per data object, session, or operation
- Wrapped by appropriate KEK
- Stored alongside encrypted data (wrapped form only)
- Short-lived: generate new DEK per write; never rotate (just generate new)
5.2 Key Generation Requirements
Per OWASP and NIST SP 800-133:
- Generate within cryptographic modules (FIPS 140-2/140-3 validated)
- Use CSPRNG exclusively -- never PRNG
Secure random number generators by language:
| Language | UNSAFE (PRNG) | SECURE (CSPRNG) |
|---|---|---|
| C | random(), rand() |
getrandom(2) |
| Java | Math.random(), java.util.Random |
java.security.SecureRandom |
| Python | random module |
secrets module |
| Node.js | Math.random() |
crypto.randomBytes() |
| Go | math/rand |
crypto/rand |
| Rust | rand::rngs::mock |
rand::rngs::OsRng, ChaCha-based CSPRNGs |
| PHP | rand(), mt_rand() |
random_bytes(), random_int() |
| .NET/C# | Random() |
RandomNumberGenerator |
UUID warning: UUIDv1 is NOT random (timestamp + MAC). UUIDv4 randomness depends on implementation. Neither is a substitute for cryptographic key generation. [CONFIRMED]
5.3 Key Strength Requirements
Per NIST SP 800-57 and CNSA 2.0:
- KEK strength must equal or exceed the strength of the keys it protects
- Single-purpose keys: each key serves exactly one purpose (encryption, authentication, signing, key wrapping)
- Rationale: limits blast radius on compromise, avoids operational conflicts in lifecycle management
Minimum key lengths (2026, non-quantum-resistant):
| Algorithm | Minimum | Recommended |
|---|---|---|
| AES | 128-bit | 256-bit |
| RSA | 2048-bit | 4096-bit |
| ECC (NIST curves) | P-256 | P-384 |
| ECC (modern) | Curve25519 | Curve25519 |
| HMAC | 256-bit | 512-bit |
5.4 Key Storage Architecture
Hierarchy of preference (most to least secure):
- HSM (FIPS 140-2 Level 3+) -- keys never leave hardware boundary
- Cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) -- managed HSM-backed
- Vault (HashiCorp) with auto-unseal to cloud KMS
- Dedicated key management server with encrypted storage
- OS-level secure storage (Keychain, DPAPI, kernel keyring)
Absolutely prohibited:
- Hardcoded in source code
- Committed to version control
- Stored in environment variables (exposed via
/proc/self/environ,phpinfo(), crash dumps) - Stored unencrypted on filesystem
- Same storage location as the data they protect
5.5 HashiCorp Vault Key Architecture
Seal/Unseal mechanism:
- Vault encrypts all data with a master encryption key
- Master key is encrypted by the unseal key
- Unseal key split via Shamir's Secret Sharing (default: 5 shares, threshold 3)
- Auto-unseal delegates to cloud KMS (AWS KMS, GCP KMS, Azure Key Vault) or HSM (PKCS#11)
Transit secrets engine (encryption as a service):
- Vault manages keys; applications send data to Vault for encrypt/decrypt
- Supported key types: AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, RSA-2048/4096, ECDSA P-256/P-384/P-521, Ed25519
- Convergent encryption: deterministic output for same plaintext + context (enables encrypted search)
- Key versioning: encrypt with latest version, decrypt with any version
- Named keys with independent rotation policies
PKI secrets engine:
- Full CA hierarchy: root CA -> intermediate CA(s) -> leaf certificates
- Dynamic certificate issuance: short-lived certs (minutes to hours)
- CRL and OCSP responder built-in
- Supports ACME protocol
- Cross-signing for CA migration
6. Key Rotation Strategies
6.1 Rotation Triggers
Per OWASP:
- Compromise (suspected or confirmed): Immediate rotation + re-encryption
- Cryptoperiod expiration: Per NIST SP 800-57 schedules
- Volume threshold: ~34 GB (2^35 bytes) for 64-bit block ciphers (3DES); much higher for AES
- Algorithm vulnerability: New attack published against algorithm in use
- Personnel change: Key custodian leaves organization
- Compliance mandate: PCI DSS, HIPAA, SOX rotation requirements
Critical principle: Rotation processes must be tested and in place BEFORE they are needed. [CONFIRMED]
6.2 Rotation Patterns
Pattern 1: Generate New DEK (Preferred)
New writes -> new DEK -> wrapped by current KEK version
Old reads -> old wrapped DEK -> unwrapped by appropriate KEK version
No re-encryption of existing data required
Best for: High-volume data stores, object storage, event streams.
Pattern 2: KEK Version Rotation
1. Create new KEK version in KMS
2. New DEK wrapping uses new KEK version
3. Background process re-wraps old DEKs with new KEK version
4. Old KEK version disabled after all DEKs re-wrapped
5. Old KEK version destroyed after retention period
Best for: Scheduled compliance rotation, key custodian changes.
Pattern 3: Full Re-encryption
1. Generate new key material
2. Decrypt all data with old key
3. Re-encrypt all data with new key
4. Verify integrity
5. Destroy old key material
Best for: Small datasets, algorithm migration, post-compromise recovery. Expensive for large datasets.
Pattern 4: Dual-Read Rotation (Secrets)
Phase 1: Add new credential alongside old (both valid)
Phase 2: Update all consumers to use new credential
Phase 3: Verify no traffic uses old credential
Phase 4: Revoke old credential
Best for: Database passwords, API keys, service credentials.
6.3 Vault Transit Key Rotation
# Rotate to new key version
vault write -f transit/keys/my-key/rotate
# Set minimum decryption version (prevents use of old versions)
vault write transit/keys/my-key min_decryption_version=5
# Re-wrap existing ciphertext with latest key version (no plaintext exposure)
vault write transit/rewrap/my-key ciphertext="vault:v2:..."
Vault re-wrap is a key operation: ciphertext is decrypted with old version and re-encrypted with new version entirely within Vault -- plaintext never leaves Vault's memory boundary.
7. Secrets Management Architecture
7.1 Secret Lifecycle
Creation -> Storage -> Distribution -> Usage -> Rotation -> Revocation -> Destruction
| | | | | | |
CSPRNG Encrypted Secure Audit Auto- Immediate Crypto-
generate at rest channel logged mated on breach erase
Four critical phases per OWASP: Creation (minimum privileges), Rotation (regular automated), Revocation (immediate on compromise), Expiration (time-based deactivation).
User credentials exception: Regular rotation is NOT recommended for user passwords. Rotate only on suspected/confirmed compromise. Forced periodic rotation leads to weaker passwords. [CONFIRMED -- NIST SP 800-63B]
7.2 HashiCorp Vault Architecture
Core capabilities:
- Secure secret storage: Encrypts before writing to backend (Consul, Raft, S3, GCS)
- Dynamic secrets: On-demand credentials for databases, cloud providers, PKI -- automatic revocation via lease expiry
- Encryption as a service: Transit engine -- applications never handle raw keys
- Leasing and renewal: Every secret has a TTL; revocation is automatic or explicit
- Revocation: Single secret, tree of secrets, or all secrets from a specific auth method
Auth methods: Token, AppRole, Kubernetes (service account), AWS IAM, GCP IAM, OIDC/JWT, LDAP, TLS certificates, userpass.
Policy model: HCL policies grant capabilities (create, read, update, delete, list, sudo, deny) on paths. Default deny. Policies attached to tokens via auth methods.
Audit devices: File, syslog, socket. Every request and response logged. Sensitive values HMAC'd in audit log (verifiable without exposing secrets).
Namespaces (Enterprise): Multi-tenant isolation within single Vault cluster. Each namespace has independent auth, policies, secrets engines.
7.3 Cloud Provider Secrets Management
| Feature | AWS Secrets Manager | GCP Secret Manager | Azure Key Vault |
|---|---|---|---|
| Encryption | AES-256 via KMS | Google-managed or CMEK | HSM-backed (FIPS 140-2 L2/L3) |
| Rotation | Lambda-based auto | Cloud Functions | App-managed |
| Versioning | Staging labels | Automatic versioning | Version-based |
| Access control | IAM resource policy | IAM + Secret-level | Vault-level (not secret-level) |
| Audit | CloudTrail | Cloud Audit Logs | Azure Monitor |
| Cross-region | Replication supported | Regional | Regional |
Azure Key Vault caveat: Permissions are at the vault level, not per-secret. Separate Key Vaults required for production/development segregation. [CONFIRMED -- OWASP]
7.4 Kubernetes Secrets Management
Native Kubernetes Secrets
Base64-encoded (NOT encrypted) by default. Stored in etcd. Readable by anyone with RBAC access to the namespace.
Hardening: Enable encryption at rest in etcd (EncryptionConfiguration with AES-CBC or AES-GCM provider backed by KMS). This is table stakes, not optional.
Sealed Secrets (Bitnami)
Architecture:
- Controller (cluster-side): Holds private key; decrypts SealedSecret CRDs into native Secrets
- kubeseal (client-side): Encrypts using controller's public certificate
Scoping:
| Scope | Binding | Use Case |
|---|---|---|
strict (default) |
Namespace + name in ciphertext | Multi-tenant; prevents secret relocation |
namespace-wide |
Namespace only | Dynamic secret naming within namespace |
cluster-wide |
No binding | Dev/single-namespace clusters |
Operational details:
- Certificates auto-renew every 30 days
- Public key is non-sensitive; distribute freely
- Encrypted SealedSecret CRDs safe to commit to Git
- Controller creates ownerReference: deleting SealedSecret garbage-collects the Secret
- Backup private key from
kube-systemnamespace for disaster recovery - Offline decryption possible with backed-up private key
External Secrets Operator (ESO)
CRDs:
- SecretStore / ClusterSecretStore: Connection config for external backend
- ExternalSecret: Declares which secrets to sync and target K8s Secret format
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend
kind: SecretStore
target:
name: db-secret
data:
- secretKey: password
remoteRef:
key: secret/data/production/db
property: password
Supported backends: AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, CyberArk, 1Password, Akeyless, Pulumi ESC, and more.
Advanced features:
- Push Secrets: Bidirectional -- push K8s secrets TO external stores
- Generators: Dynamic secret generation without external backend
- Templating: Transform and compose secret values during sync
- Webhook provider: Arbitrary HTTP endpoints as secret sources
Pattern Comparison
| Pattern | GitOps Safe | External Store | Dynamic Secrets | Complexity |
|---|---|---|---|---|
| Sealed Secrets | Yes (encrypted in repo) | No (self-contained) | No | Low |
| External Secrets | Yes (reference only) | Yes (required) | Yes (via Vault) | Medium |
| Vault Agent Sidecar | No (runtime injection) | Yes (Vault) | Yes | High |
| CSI Secret Store Driver | No (runtime mount) | Yes (multiple) | Yes | Medium |
7.5 Secret Injection Patterns
Ranked by security (most to least secure):
-
Sidecar/init container: Dedicated container fetches secrets, writes to shared in-memory volume (
emptyDirwithmedium: Memory), terminates. Application reads from mount. No secret in pod spec. -
CSI Secret Store Driver: Secrets mounted as files via CSI volume. Fetched at pod start from external store. Supports Vault, AWS, Azure, GCP.
-
Mounted volumes (orchestrator-managed): K8s Secret mounted as volume. Secret exists in etcd (encrypted if configured).
-
Environment variables: Accessible to all processes in container. Appears in
kubectl describe pod. Visible in/proc/*/environ. Least preferred.
Anti-patterns:
docker ENVordocker ARGin Dockerfile (leak in image layers and inspect output).envfiles baked into container images- Secrets in CI/CD pipeline logs
- Single shared credential across multiple services
7.6 Secret Detection and Response
Shift-left detection tools:
- IDE plugins (pre-write)
- Pre-commit hooks (pre-commit)
- PR/MR scanning (pre-merge)
- Repository scanning (post-commit)
Tools: Yelp Detect Secrets (~20 secret type signatures), truffleHog, gitleaks, GitHub secret scanning, GitLab secret detection.
Types to detect: API keys, AWS access keys, GCP service account keys, private keys (RSA, EC, PGP), passwords/credentials, connection strings, session tokens, JWTs, 2FA backup codes, SSH keys.
Incident response for leaked secrets:
- Revoke exposed credential immediately
- Rotate with new automated generation
- Delete from code history (
git filter-repo), logs, and all systems - Audit access logs for unauthorized use during exposure window
- Post-mortem to prevent recurrence
7.7 Audit Logging Requirements
Minimum audit scope for secrets management:
- Request source (user, system, role, IP)
- Approval/rejection status with reason
- Usage timing and principal identity
- Expiration and post-expiration access attempts
- Authentication and authorization failures
- Rotation events (old version, new version, initiator)
- Administrative actions (policy changes, backend config)
- Synchronized timestamps across infrastructure (NTP)
8. Data Classification and Handling
8.1 Classification Levels
| Level | Label | Examples | Encryption Requirement |
|---|---|---|---|
| 1 | Public | Marketing content, public docs | Integrity protection (signing) |
| 2 | Internal | Internal wikis, org charts | Encryption in transit; at rest optional |
| 3 | Confidential | Financial data, contracts, source code | Encryption at rest + in transit; access logging |
| 4 | Restricted | PII, PHI, payment data, credentials | Encryption at rest + in transit + field-level; strict access control; audit logging; retention limits |
| 5 | Top Secret | Encryption keys, master secrets, incident details | HSM storage; hardware isolation; need-to-know access; no copies |
8.2 Handling Procedures by Classification
Restricted data (Level 4):
- Encrypted at rest with AES-256-GCM or ChaCha20-Poly1305
- Column-level or application-level encryption (not just TDE)
- TLS 1.3 in transit; mTLS for service-to-service
- Access requires authentication + authorization + audit log entry
- Retention policy enforced (auto-delete after period)
- Cross-border transfer controls (GDPR Art. 44-49)
- Breach notification trigger (GDPR Art. 33: 72 hours; HIPAA: 60 days)
- Data subject access/deletion rights (GDPR Art. 15, 17)
Top Secret data (Level 5):
- HSM-only key storage; keys never exported
- Confidential computing for processing (enclaves/TEE)
- Air-gapped systems where feasible
- Two-person integrity for key operations
- Physical access controls for hardware
- No cloud storage unless cloud provider offers adequate controls (CSEK + confidential VMs)
8.3 Regulatory Mapping
| Regulation | Data Types | Key Requirements |
|---|---|---|
| GDPR | EU personal data | Encryption referenced as safeguard (Art. 32); pseudonymization; breach notification 72h; right to erasure |
| HIPAA | PHI (Protected Health Info) | Encryption = safe harbor from breach notification; BAAs required; minimum necessary |
| PCI DSS 4.0 | Cardholder data | Strong crypto for storage + transmission; key management procedures; quarterly key rotation |
| SOX | Financial records | Integrity controls; access logging; retention requirements |
| CCPA/CPRA | California consumer data | Reasonable security measures; right to delete; opt-out of sale |
| DORA | Financial sector (EU) | ICT risk management; encryption requirements; incident reporting |
9. Tokenization vs Encryption
9.1 Comparison
| Property | Encryption | Tokenization |
|---|---|---|
| Reversibility | Yes (with key) | Yes (with token vault) or No (irreversible) |
| Output format | Ciphertext (different length/format) | Token preserves format (same length, same type) |
| Mathematical relationship | Ciphertext derived from plaintext + key | No mathematical relationship (lookup table) |
| PCI DSS scope | System remains in scope | Tokenized system exits scope |
| Performance | Fast (symmetric), no network call | Requires token vault lookup (network call) |
| Scalability | Unlimited (local operation) | Token vault is bottleneck |
| Analytics on protected data | Not possible (without decryption) | Format-preserving tokens enable partial analytics |
9.2 When to Use Tokenization
- PCI DSS scope reduction: Replace PAN with token; only token vault is in scope
- Format preservation required: Systems expecting 16-digit card numbers, 9-digit SSNs
- Third-party data sharing: Share tokens instead of real data; de-tokenize only when needed
- Legacy system integration: Systems that cannot handle ciphertext format
9.3 When to Use Encryption
- Data must be recoverable by the holder: Encrypted files, encrypted databases
- High-volume, low-latency: No network call needed for symmetric crypto
- End-to-end protection: Data encrypted from origin to destination
- Regulatory requirement for encryption specifically: HIPAA safe harbor
9.4 Format-Preserving Encryption (FPE)
NIST-approved: FF1 and FF3-1 (NIST SP 800-38G). Encrypts data while preserving format (e.g., 16-digit input -> 16-digit output). Bridges encryption and tokenization properties but with smaller ciphertext space (reduced security margin for short inputs).
10. Data Masking and Anonymization
10.1 Techniques Spectrum
| Technique | Reversibility | Data Utility | Privacy Level |
|---|---|---|---|
| Pseudonymization | Reversible (with mapping) | High | Moderate (still personal data under GDPR) |
| Generalization | Irreversible | Medium | High (k-anonymity) |
| Suppression | Irreversible | Low | Very High |
| Perturbation | Irreversible | Medium | High (differential privacy) |
| Synthetic data | N/A (no real data) | Variable | Complete |
10.2 Pseudonymization
Replace identifying fields with pseudonyms. Reversible with the mapping table.
GDPR Art. 4(5): Pseudonymized data is still personal data. Processing rules still apply. However, pseudonymization is recognized as a security measure (Art. 32) and may reduce breach notification obligations.
Implementation: HMAC-based (deterministic, supports joins across datasets) or random mapping (stronger privacy, requires lookup table).
10.3 Dynamic Data Masking
Data masked at query time based on user role. Original data unchanged in storage.
-- PostgreSQL row-level security + column masking
CREATE POLICY pii_mask ON customers
USING (current_user = 'analyst')
WITH CHECK (false);
-- View-based masking
CREATE VIEW customers_masked AS
SELECT
id,
CASE WHEN current_user IN ('admin', 'pii_reader')
THEN email
ELSE regexp_replace(email, '(.).*(@.*)', '\1***\2')
END AS email,
CASE WHEN current_user IN ('admin', 'pii_reader')
THEN ssn
ELSE 'XXX-XX-' || right(ssn, 4)
END AS ssn
FROM customers;
10.4 Differential Privacy
Mathematical guarantee: output of a query is statistically indistinguishable whether any single individual's data is included or not.
Privacy budget (epsilon): Lower epsilon = stronger privacy = more noise = less utility. Typical range: 0.1 (strong) to 10 (weak). Budget is consumed with each query; once exhausted, no more queries permitted.
10.5 k-Anonymity, l-Diversity, t-Closeness
- k-anonymity: Every record is indistinguishable from at least k-1 other records on quasi-identifiers
- l-diversity: Each equivalence class has at least l distinct values for sensitive attributes
- t-closeness: Distribution of sensitive attribute in each class is within distance t of overall distribution
11. Secure Deletion and Crypto-Shredding
11.1 Why Deletion is Hard
- SSDs: Wear leveling, over-provisioning, and TRIM behavior make sector-level overwrite unreliable
- Cloud storage: Multi-tenant storage, replication, snapshots, and backup systems retain copies
- Databases: WAL, redo logs, replication streams, and backup retention preserve deleted data
- Memory: Swap files, core dumps, hibernation files may contain copies
11.2 Crypto-Shredding
The only reliable deletion method for data at scale: destroy the encryption key, rendering all data encrypted under that key irrecoverable.
Requirements:
- All data encrypted with a dedicated key (per-tenant, per-purpose, or per-record)
- Key stored in a key management system with reliable destruction capability
- Key destruction is auditable and irreversible
- No copies of the key exist outside the KMS
Implementation pattern:
1. Assign unique DEK per tenant (or per data subject for GDPR Art. 17)
2. Wrap DEK with KEK in KMS
3. On deletion request:
a. Destroy DEK in KMS (schedule destruction with cooling period)
b. Verify no DEK copies exist in caches, backups, replicas
c. After cooling period, KMS permanently destroys key material
d. Encrypted data remains on disk but is cryptographically irrecoverable
4. Optionally: overwrite ciphertext blocks for defense in depth
GDPR Right to Erasure (Art. 17): Crypto-shredding is accepted as a valid technical measure for implementing the right to be forgotten, provided the key destruction is verifiable and the encryption was applied correctly.
11.3 Secure Deletion by Medium
| Medium | Method | Confidence |
|---|---|---|
| HDD | NIST 800-88 Clear/Purge (overwrite) or Destroy (degauss/shred) | High (for Destroy) |
| SSD | ATA Secure Erase + TRIM + crypto-erase (if supported) | Medium (wear leveling risk) |
| NVMe | NVMe Format with Crypto Erase | High (if implemented correctly) |
| Cloud storage | Crypto-shredding (delete key); rely on provider deletion SLA | Medium (trust provider) |
| RAM | Zero memory + deallocate; reboot for assurance | High |
| Backup tapes | Physical destruction or crypto-shredding of backup key | High |
11.4 Key Destruction Protocol
1. Identify all copies of key material (primary, backup, replicas, caches)
2. Schedule destruction with cooling period (7-30 days for recovery from accidental deletion)
3. Revoke all access to the key immediately (prevents new encrypt/decrypt)
4. After cooling period: permanently delete from all locations
5. Audit log: record destruction event, operator, timestamp, key identifier
6. Verify: attempt decryption with destroyed key to confirm failure
12. Backup Encryption
12.1 Backup Encryption Requirements
Backups contain the same (or more) sensitive data as production systems. They must receive equal or greater protection.
| Principle | Implementation |
|---|---|
| Encrypt before transfer | Encrypt at source; never send plaintext to backup destination |
| Separate key management | Backup encryption keys separate from production data keys |
| Key escrow for recovery | Backup keys must be recoverable even if primary KMS is lost |
| Test restoration | Regularly verify decryption of backups (untested backups are not backups) |
| Retention-aligned key lifecycle | Keys must outlive backup retention period |
| Geographic separation | Keys and encrypted backups in different locations/regions |
12.2 Backup Encryption Patterns
Pattern 1: Envelope encryption for backups
1. Generate backup-specific DEK
2. Encrypt backup data with DEK (AES-256-GCM, streaming for large backups)
3. Wrap DEK with backup KEK (stored in separate KMS from production)
4. Store {encrypted_backup, wrapped_DEK} at backup destination
5. Store backup KEK in disaster recovery KMS (different region/provider)
Pattern 2: Age-encrypted backups (simple, scriptable)
# Encrypt
tar czf - /data | age -r age1recipient... > backup-2026-03-14.tar.gz.age
# Decrypt
age -d -i key.txt backup-2026-03-14.tar.gz.age | tar xzf -
Pattern 3: Database-native encrypted backups
# PostgreSQL with gpg
pg_dump mydb | gpg --encrypt --recipient backup@org.com > mydb.dump.gpg
# MySQL with openssl
mysqldump mydb | openssl enc -aes-256-gcm -pass file:/path/to/keyfile > mydb.dump.enc
12.3 Backup Key Management
The backup key dilemma: If the KMS is lost (disaster), you need backup keys to restore. But backup keys stored outside the KMS are a security risk.
Solutions:
- Multi-KMS wrapping: Wrap backup DEK with keys from two independent KMS providers (e.g., AWS KMS + Vault). Either can unwrap.
- Shamir split of backup master key: Split into n shares, threshold m. Distribute shares to separate custodians/locations. Reconstruct only during disaster recovery.
- Paper key escrow: Print key material, store in tamper-evident envelopes in physically secure locations (bank vault, separate facility). Test annually.
- HSM backup/restore: HSM vendors provide secure key backup/restore between HSM units.
13. Algorithm Reference
13.1 Recommended Algorithms (2026)
Symmetric encryption (AEAD required):
| Algorithm | Key Size | Use Case | Notes |
|---|---|---|---|
| AES-256-GCM | 256-bit | General purpose | 96-bit nonce; 2^32 message limit per key+nonce pair |
| AES-128-GCM | 128-bit | Acceptable where 256 unnecessary | Same nonce constraints |
| ChaCha20-Poly1305 | 256-bit | Software implementations, mobile | No AES-NI dependency; constant-time |
| XChaCha20-Poly1305 | 256-bit | Large nonce requirement | 192-bit nonce; safe with random nonces |
| AES-256-GCM-SIV | 256-bit | Nonce-misuse resistance | Slightly slower; safe if nonce reused (reduced to deterministic encryption) |
Asymmetric encryption:
| Algorithm | Key Size | Use Case |
|---|---|---|
| X25519 + HKDF | 256-bit | Key agreement (ECDH) |
| RSA-OAEP | 4096-bit | Key wrapping (legacy interop) |
| ECIES (Curve25519) | 256-bit | Hybrid encryption |
Digital signatures:
| Algorithm | Key Size | Use Case |
|---|---|---|
| Ed25519 | 256-bit | General purpose signing |
| ECDSA P-256/P-384 | 256/384-bit | Certificate-based PKI |
| RSA-PSS | 4096-bit | Legacy interop |
Hashing:
| Algorithm | Output | Use Case |
|---|---|---|
| SHA-256 | 256-bit | General purpose |
| SHA-384/512 | 384/512-bit | Higher security margin |
| BLAKE2b | Variable | Fast hashing, MAC |
| BLAKE3 | Variable | Very fast, parallelizable |
| SHA-3 (Keccak) | Variable | Alternative construction to SHA-2 |
Password hashing (NOT for data encryption):
| Algorithm | Parameters | Notes |
|---|---|---|
| Argon2id | m=47104 KiB, t=1, p=1 (minimum) | Preferred; memory-hard + time-hard |
| bcrypt | cost=12+ | Widely supported; 72-byte input limit |
| scrypt | N=2^17, r=8, p=1 | Memory-hard; less tunable than Argon2 |
13.2 Deprecated / Prohibited
| Algorithm | Status | Reason |
|---|---|---|
| DES / 3DES | PROHIBITED | 64-bit block; Sweet32 attack |
| RC4 | PROHIBITED | Statistical biases; broken |
| MD5 | PROHIBITED for security | Collision attacks; use only for checksums |
| SHA-1 | PROHIBITED for security | Collision attacks (SHAttered, 2017) |
| RSA < 2048-bit | PROHIBITED | Factorable with modern hardware |
| AES-ECB | PROHIBITED | Preserves plaintext patterns |
| AES-CBC without MAC | PROHIBITED | Padding oracle attacks (POODLE, Lucky13) |
| PKCS#1 v1.5 padding | DEPRECATED | Bleichenbacher attacks; use OAEP |
| Blowfish (non-bcrypt) | DEPRECATED | 64-bit block; replaced by AES |
13.3 Post-Quantum Readiness
NIST PQC standards (finalized 2024):
- ML-KEM (CRYSTALS-Kyber): Key encapsulation; replace ECDH/RSA key exchange
- ML-DSA (CRYSTALS-Dilithium): Digital signatures; replace ECDSA/Ed25519
- SLH-DSA (SPHINCS+): Stateless hash-based signatures; conservative alternative
Migration strategy:
- Inventory all cryptographic usage (algorithms, key sizes, protocols)
- Prioritize: harvest-now-decrypt-later data (long-term secrets, classified data)
- Deploy hybrid schemes: classical + PQC (e.g., X25519 + ML-KEM)
- Monitor CNSA 2.0 timeline for compliance deadlines
- Plan for larger key sizes and signatures (ML-KEM-768: ~1 KB public key; ML-DSA-65: ~2 KB signature)
13.4 Nonce/IV Management
| Mode | Nonce Size | Generation Strategy | Failure Mode |
|---|---|---|---|
| AES-GCM | 96-bit | Counter (preferred) or random | Nonce reuse: catastrophic (auth key recovery) |
| ChaCha20-Poly1305 | 96-bit | Counter or random | Nonce reuse: catastrophic |
| XChaCha20-Poly1305 | 192-bit | Random (safe) | Nonce reuse: still bad but negligible collision probability |
| AES-GCM-SIV | 96-bit | Random (safe) | Nonce reuse: deterministic encryption (leaks equality) |
| AES-CTR | Variable | Counter (must be unique) | Reuse: XOR of plaintexts leaked |
| AES-CBC | 128-bit | Random, unpredictable | Predictable IV: chosen-plaintext attacks |
Rule: Let the cryptographic library manage nonce generation when possible. If manual, use a counter for GCM; use random for XChaCha20-Poly1305 or GCM-SIV. NEVER reuse a nonce with the same key. [CONFIRMED]
14. Anti-Patterns and Common Failures
14.1 Cryptographic Anti-Patterns
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Rolling your own crypto | Subtle bugs lead to total compromise | Use vetted libraries (libsodium, OpenSSL, AWS Encryption SDK) |
| ECB mode | Preserves plaintext block patterns | Use authenticated modes (GCM, ChaCha20-Poly1305) |
| Encrypt without authenticate | Ciphertext malleable; padding oracles | Always use AEAD (AES-GCM, ChaCha20-Poly1305) |
| CBC + HMAC in wrong order | MAC-then-encrypt enables padding oracle | Encrypt-then-MAC, or use AEAD |
| Hardcoded keys | Extractable from binaries, repos | External key management (KMS, Vault) |
| Reusing nonces | Catastrophic for GCM/CTR modes | Counter-based or sufficiently large random nonces |
| Key = password hash | Low entropy; offline brute-forceable | Use KDF (HKDF, Argon2) to derive keys from passwords |
| Encrypting password for storage | Reversible; insider can decrypt | Hash with Argon2id/bcrypt (one-way) |
| Base64 as "encryption" | Encoding is not encryption | Actually encrypt with proper algorithms |
14.2 Key Management Anti-Patterns
| Anti-Pattern | Risk | Correct Approach |
|---|---|---|
| Keys in environment variables | /proc/self/environ, crash dumps, logs |
Fetch from KMS/Vault at runtime |
| Keys in source code / VCS | Permanent exposure in git history | Secret management system; pre-commit scanning |
| Same key for multiple purposes | Compromise of one purpose compromises all | Dedicated key per purpose (NIST SP 800-57) |
| No key rotation process | Unlimited exposure window | Automated rotation with tested procedures |
| KEK weaker than DEK | Attacker targets weakest link | KEK strength >= DEK strength |
| Keys stored alongside encrypted data | Single breach exposes both | Separate storage locations/systems |
| No key backup/escrow | Key loss = data loss | Secure backup with separate access control |
| Manual key distribution | Human error, exposure | Automated via KMS, Vault, or PKI |
14.3 Secrets Management Anti-Patterns
| Anti-Pattern | Risk | Correct Approach |
|---|---|---|
| Secrets in Dockerfiles (ENV/ARG) | Leaked in image layers, docker inspect | Runtime injection via sidecar/mount |
.env files in container images |
Extracted from image; persisted in registry | External secrets management |
| Shared credentials across services | Blast radius of compromise is unbounded | Per-service credentials with least privilege |
| Manual rotation | Drift, human error, delays | Automated rotation (Lambda, Vault dynamic secrets) |
| Secrets in CI/CD logs | Visible to anyone with log access | Mask in pipeline config; use OIDC for cloud auth |
| Long-lived API keys | Extended exposure window | Short-lived tokens, dynamic secrets |
| No audit logging on secret access | Cannot detect unauthorized access | Comprehensive audit with alerting |
Appendix A: Decision Matrix
Choosing an Encryption Strategy
Is the data at rest?
|
+-> Structured (database)?
| |
| +-> Need to query encrypted fields? -> Deterministic encryption or tokenization
| +-> DBA must not see plaintext? -> Application-level encryption
| +-> Compliance checkbox only? -> TDE (but understand its limits)
| +-> Column contains PII/PCI? -> Column-level encryption + key per tenant
|
+-> Unstructured (files)?
| |
| +-> Full disk protection sufficient? -> FDE (LUKS, BitLocker)
| +-> Need file-level granularity? -> age, GPG, or SOPS (for config)
| +-> Cloud object storage? -> Envelope encryption (SSE-KMS + CMEK)
|
+-> Secrets/credentials?
|
+-> Kubernetes? -> External Secrets Operator or Sealed Secrets
+-> Multi-cloud? -> Vault (cloud-agnostic)
+-> AWS-only? -> AWS Secrets Manager
+-> Need dynamic DB creds? -> Vault dynamic secrets engine
Is the data in transit?
|
+-> Browser to server? -> TLS 1.3 (mandatory)
+-> Service to service? -> mTLS (via service mesh or Vault PKI)
+-> Site to site VPN? -> WireGuard (preferred) or IPSec (legacy/compliance)
+-> Database connections? -> TLS with certificate verification
+-> Message queue payloads? -> TLS for transport + message-level encryption
Is the data in use?
|
+-> Cloud processing of sensitive data? -> Confidential VMs (SEV-SNP, TDX)
+-> Multi-party computation? -> MPC protocols
+-> Analytics on encrypted data? -> Homomorphic encryption (limited use cases)
+-> Key operations? -> HSM / enclave-based key management
Choosing a Key Management Solution
What is your deployment model?
|
+-> Single cloud provider?
| -> Use provider KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault)
| -> Add Vault for application-layer secrets and dynamic credentials
|
+-> Multi-cloud or hybrid?
| -> Vault as primary KMS (auto-unseal with cloud KMS)
| -> Cloud KMS as unseal/root key provider only
|
+-> On-premises?
| -> HSM (Thales Luna, Utimaco) + Vault
| -> KMIP protocol for interoperability
|
+-> Kubernetes-native?
-> External Secrets Operator (sync from any backend)
-> Sealed Secrets (GitOps, no external dependency)
-> CSI Secret Store Driver (runtime mount)
Appendix B: Compliance Quick Reference
| Control | PCI DSS 4.0 | HIPAA | GDPR | NIST 800-53 |
|---|---|---|---|---|
| Encryption at rest | Req 3.5 (strong crypto) | 164.312(a)(2)(iv) | Art. 32 (appropriate measures) | SC-28 |
| Encryption in transit | Req 4.2 (strong crypto) | 164.312(e)(1) | Art. 32 | SC-8 |
| Key management | Req 3.6, 3.7 | 164.312(a)(2)(iv) | Art. 32 | SC-12 |
| Access control | Req 7 (least privilege) | 164.312(a)(1) | Art. 25 (by design) | AC-3 |
| Audit logging | Req 10 (track access) | 164.312(b) | Art. 30 (records) | AU-2 |
| Data retention | Req 3.1 (minimize) | 164.530(j) (6 years) | Art. 5(1)(e) (limitation) | SI-12 |
| Secure deletion | Req 3.1 (render irrecoverable) | 164.310(d)(2)(i) | Art. 17 (right to erasure) | MP-6 |
| Breach notification | Req 12.10 (incident response) | 164.408 (60 days) | Art. 33 (72 hours) | IR-6 |
Sources: OWASP Cryptographic Storage Cheat Sheet, OWASP Key Management Cheat Sheet, OWASP Secrets Management Cheat Sheet, OWASP Database Security Cheat Sheet, HashiCorp Vault documentation, Mozilla SOPS documentation, Bitnami Sealed Secrets documentation, External Secrets Operator documentation, AWS Encryption SDK documentation, Google Cloud KMS Envelope Encryption documentation, NIST SP 800-57/800-88/800-133, CNSA 2.0 Suite.