Encryption at Rest¶
Statement¶
Every byte of ClaimGuard data that is stored — application state on disk, snapshots of that disk, files in Google Cloud Storage, secrets in Secret Manager — is encrypted at rest with AES-256 under Google-managed encryption keys (GMEK). This is the GCP default and applies automatically; we have not opted out.
Customer-managed encryption keys (CMEK), application-layer column
encryption, and database-level Transparent Data Encryption (TDE) are
not in place today. Those are the gaps that keep this control at
partial rather than fully implemented.
For the algorithms used to derive and verify the application's own secrets (passwords, JWTs), see Cryptography.
Implementation¶
Coverage¶
| Storage location | Encryption | Key class | Notes |
|---|---|---|---|
VM boot disk deepfakebench3 (claim-guard-app-1) |
AES-256 | GMEK | GCP default; cannot be disabled. |
Daily snapshots of the boot disk (claim-guard-daily policy) |
AES-256 | GMEK | Inherits from source disk; see Backups. |
| GCS buckets (image-upload buckets used by the c2pa tool) | AES-256 | GMEK | GCP default. |
Secret Manager (claim-guard-jwt-secret, claim-guard-database-url, claim-guard-google-api-key, claim-guard-support-webhook-url) |
AES-256 | GMEK | See Secrets management. |
| Postgres data files (on the VM boot disk) | AES-256 | GMEK | Encryption is at the disk layer, not at the DB layer. No TDE. |
Cloud Logging buckets (_Required, _Default) |
AES-256 | GMEK | See Audit logging. |
What "GMEK" means in practice¶
- Each persistent disk and snapshot is encrypted with a unique data-encryption key (DEK) that itself is wrapped by a Google-managed key-encryption key (KEK) in Google's KMS.
- Key generation, rotation, and destruction are operated by Google. We do not see, hold, or rotate the keys.
- Decryption happens transparently at the storage layer — the application reads plaintext through the normal POSIX / object APIs.
- An attacker with the raw bytes of a snapshot tarball or disk image cannot decrypt it without Google's KMS access.
What we explicitly chose not to do (yet)¶
- CMEK on compute disks, snapshots, GCS, or Secret Manager. A CMEK setup would let us hold the KEK in our own KMS keyring, with a rotation cadence we control and an audit trail of key access. This is a typical SOC 2 Type II / ISO 27001 ask and is on the roadmap.
- Application-layer column encryption on Postgres for the most sensitive PII fields. The data we store today (claim narratives, file references, user contact details) is risk-rated low at current scale. This is the right place to revisit before the first regulated-customer onboarding.
- TDE / pgcrypto. Postgres on the VM does not perform per-row or per-column encryption. The disk layer is where the encryption story lives, which means a privileged process on the VM sees plaintext rows — exactly as it would on any vanilla Postgres install.
- Per-field encryption of the JWT secret material in Secret Manager using a CMEK — Secret Manager payloads are already encrypted at rest under GMEK; adding CMEK is the same trade-off as above.
What this means for backups¶
Snapshots inherit the source disk's encryption — they are GMEK-encrypted end-to-end and cannot be opened outside Google's infrastructure. See Backups for the snapshot policy itself, the recovery procedure, and known gaps (no off-region replication; no CMEK on snapshots).
What this means for secrets¶
The Secret Manager payload is encrypted at rest under GMEK; access is
audit-logged in _Required; bindings are per-secret on the
claim-guard-vm service account. See
Secrets management for the
full chain.
Status¶
partial — verified 2026-04-29.
What's in place:
- AES-256 GMEK encryption on every storage primitive in scope (VM disk, snapshots, GCS, Secret Manager, Cloud Logging).
- No mixed plaintext / encrypted regions; no opt-out is configured anywhere.
- The encryption story is identical between production data and backups — restoring from a snapshot does not pass through any unencrypted intermediate state.
Known gaps¶
- No CMEK. All keys are Google-managed. We do not control rotation cadence or hold key-access audit trails for the KEK layer.
- No application-layer column encryption for sensitive PII columns in Postgres. Risk-rated low at current scale.
- No TDE. Encryption is at the disk layer; a privileged process on the VM sees plaintext rows.
- No off-region replication of snapshots.
Roadmap¶
- CMEK for snapshots, GCS, and Secret Manager. Larger effort; appropriate to land in the SOC 2 Type II / ISO 27001 cycle.
- Column-level encryption of high-sensitivity fields, contingent on the first regulated-customer requirement.
- Cross-region snapshot copy — see Backups roadmap.
- Postgres → Cloud SQL with PITR (plan step A2.3) — closes the TDE-equivalent gap by moving to a managed database with encryption, point-in-time recovery, and audit-logged access.