Disk Encryption and Key Custody for Cloud VMs

Encrypting cloud virtual machine disks is table stakes—until you ask who holds the keys, who can export snapshots, and what happens when someone clones a volume into another project. Disk encryption at rest without key custody discipline is theater. This article covers customer-managed keys versus platform-managed keys, snapshot and image exposure, and operational practices that keep data confidential when disks, backups, and replicas multiply.

The advice applies across major clouds—AWS KMS with encrypted EBS, Azure Key Vault with Disk Encryption Sets, GCP CMEK—and to self-managed hypervisors using LUKS or equivalent. Product names differ; the custody questions do not.

If your compliance narrative already says “all volumes encrypted,” dig one layer deeper: which keys, which identities may decrypt, and where plaintext copies still exist as snapshots, warehouse exports, or CI artifacts.

What disk encryption does and does not buy you

Encryption at rest protects against certain classes of physical and storage-backend exposure: discarded media handling, some backup mistakes, and casual access to raw blocks under a well-run provider model. It does not protect a running VM against an attacker who already has operating system root or the application’s cloud credentials. It also does not replace TLS, application-level encryption for high-sensitivity fields, or access control on APIs that serve the data.

Treat disk encryption as necessary defense-in-depth for block storage, not as a complete confidentiality architecture. Document that distinction for stakeholders who equate the word encrypted with the word safe.

Platform keys versus customer-managed keys

Platform-managed keys are convenient: the cloud encrypts volumes by default or with a checkbox, rotates material, and integrates with snapshots. You trust the provider’s boundary and IAM. Customer-managed keys put a key object under your IAM policies, allow stricter separation between storage admins and key admins, support customer-influenced rotation schedules, and enable cryptographic shredding by disabling the key. They also create availability risk: delete or disable the key incorrectly, and your data becomes permanently unreadable.

Choose customer-managed keys when regulatory or contractual requirements demand customer key control, when you need dual control between platform and security teams, or when you want consistent custody patterns across clouds. Stay on platform keys when the team cannot yet operate key policies safely, when availability risk of key misconfiguration exceeds the threat you are mitigating, or when the workload is low sensitivity. Many organizations use platform keys for non-production and customer-managed keys for production data stores—explicitly, with module interfaces that make the choice visible.

Separate duties: compute administrators should not unilaterally delete keys.
Require MFA and dual approval for key disable and schedule deletion.
Enable rotation features that do not require rewriting all data where available.
Tag keys by environment and data classification; block prod data on sandbox keys.
Log and alert on key policy changes and unusual Decrypt or GenerateDataKey volumes.
Document break-glass identities stored offline for disaster recovery.

Snapshots, images, and silent copies

Snapshots usually inherit encryption from the source volume, but sharing a snapshot with another account or publishing a machine image can expand who decrypts. Review default sharing. Prefer snapshots under the same customer-managed key and restrict who may create public or cross-account images from volumes that ever held secrets. CI pipelines that bake golden images should use dedicated keys and scrub secrets before imaging.

Cross-region replication and backup products may re-encrypt under a different key. Map those keys on your architecture diagram. A forgotten replica under a permissive key policy is a classic custody failure. When you decommission a project, inventory volumes, snapshots, machine images, and backup vaults—not only running instances.

Data warehouses and analytics exports often bypass disk encryption narratives entirely because data leaves the VM as object storage or SaaS extracts. Track those paths in the same custody register.

Boot volumes, data volumes, and runtime reality

Encrypt boot and data volumes. Verify current cloud documentation for your instance families and image types. Remember that memory, hibernation files, and crash dumps can hold plaintext. For higher assurance workloads, combine disk encryption with secure boot and policies that limit who can attach volumes to bastion hosts. Detached volumes in a shared account are a frequent lateral-movement prize—alert on attach events outside expected roles.

Databases and application-level encryption

Transparent disk encryption does not satisfy every requirement for field-level secrets. Tokens, credentials, and regulated identifiers often need application-level encryption with separate keys. Database engines may offer their own TDE; understand whether those keys are backed by your customer-managed keys. Avoid pointless double encryption; encrypt where it changes who can read data under realistic compromise scenarios.

Operational runbooks

Document key owners, rotation interval, and emergency disable steps.
Test restore of an encrypted volume after rotation during a scheduled drill.
Default deny snapshot sharing; require tickets for exceptions.
Include volume and snapshot inventory in cloud project offboarding.
Reference key identifiers explicitly in infrastructure as code for production.
Practice key disable in non-production so teams feel the blast radius safely.

Threat scenarios

Stolen laptop with a cloud console session: short sessions, MFA, and organization policies that deny volume sharing help. Malicious insider with compute admin rights: key policies that require a second team for decrypt on sensitive keys reduce solo export. Compromised CI role: scope pipeline identities so they cannot use production decrypt permissions. Legal process against the provider: understand what customer-managed keys do and do not change; they improve auditability and control, not magic invisibility.

Implementation sketch

In Terraform or equivalent, create keys with deletion windows, aliases, and policies allowing only specific roles to encrypt and decrypt. Pass key identifiers into modules for disks, managed databases, and object storage. Add policy-as-code checks that fail plans creating unencrypted volumes in production accounts. Continuously discover unencrypted disks with posture management tooling and assign owners to each finding.

Measuring whether the control works

For disk encryption and key custody, define leading and lagging indicators. Leading indicators show that engineers are using the control in new work: policy checks in CI, percentage of new resources compliant, time to close findings. Lagging indicators show outcomes: incidents related to the gap, audit exceptions, customer questionnaire failures. Review both in a monthly operations meeting so the control does not become a wiki page nobody reads.

Prefer metrics that teams can move weekly. “100% encrypted volumes” is good; “mean time to fix newly discovered unencrypted volumes under 48 hours” is better because it encodes response, not only steady state. Publish the metric next to ownership so orphaned dashboards do not appear.

Change management and exceptions

Every baseline needs an exception process with expiry. Exceptions should name the risk owner, compensating controls, and a review date. Infinite exceptions are how baselines die. Store them in the same system as infrastructure tickets, not in private chat. When an exception expires, the default is to enforce—not to silently renew.

Tie exceptions to environments. A sandbox exception must not clone into production through a shared Terraform module default. Policy-as-code should understand environment tags and fail closed when production resources request sandbox exceptions.

Training and onboarding

New engineers ship misconfigurations when the happy path is insecure. Put the secure defaults in templates and golden modules so the easy path is the right path. Pair that with a thirty-minute onboarding module that explains why the control exists, using one real incident story (internal or public). Fear without agency burns people out; agency without context invites creative bypasses.

Run occasional game days that break the control on purpose in a lab account—disable a key policy, open a public snapshot, skip an authz check—and ask participants to detect and fix. Muscle memory beats annual compliance training slides.

Vendor and SaaS boundaries

Your baseline must state what you expect from SaaS vendors: encryption at rest with documented key options, audit logs exportable to your SIEM, and clear statements on who can access customer data. Collect those answers once per vendor tier and revisit on contract renewal. Do not assume a SOC 2 logo replaces your custody questions.

When vendors hold keys or data, map the shared responsibility model in one page. Include what you still must configure (CMK, retention, admin MFA) so teams do not think “the vendor encrypts” means “we are done.”

Putting it into the next ninety days

Write the baseline in one page with must/should/may language.
Encode must-rules in CI and cloud policy; leave should-rules as reports.
Fix the top ten existing violations by blast radius, not by ease.
Assign owners and metrics; review after thirty days.
Schedule a tabletop that assumes the control failed.
Delete or expire any exception older than ninety days without review.

Baselines fail when they are aspirational novels. Keep them short, enforceable, and tied to the systems engineers already use. Improve them when incidents teach you something new—not when a binder needs more pages.

Disk encryption is a custody problem disguised as a checkbox. Prefer defaults that encrypt everything; elevate to customer-managed keys where separation of duty matters; hunt snapshots and images as carefully as running disks; and rehearse key loss as an availability incident. Done this way, encrypted at rest becomes a real control—not only a screenshot for a questionnaire.

Coordination with backup and DR teams

Backup systems often hold the largest copies of sensitive disks. Ensure backup vaults use equal or stronger key policies than primary volumes. Test restores into isolated accounts so restore testing does not create a weakly protected twin. DR runbooks should name the keys required in the failover region and the people who can enable them under dual control.

Immutable backups help ransomware resilience but complicate custody if the immutability role is too broad. Split who can configure retention from who can read backup data. Review cross-account backup shares the same way you review snapshot shares.

Practical rollout sequencing

For disk encryption and key custody, resist the urge to boil the ocean. Sequence work in layers that each reduce measurable risk. First, make the secure path the default in templates and golden modules so new work does not add debt. Second, detect exceptions in existing estates with automated inventory. Third, fix the highest blast-radius gaps. Fourth, only then pursue optimizations and nice-to-have integrations. Platform and security teams that skip straight to tooling catalogs often stall on political debates while production remains unchanged.

Time-box each layer. A two-week default-hardening sprint plus a four-week remediation push beats an open-ended transformation program. At the end of each box, demo something concrete: a policy that fails CI, a dashboard of remaining exceptions, or a runbook used in a drill.

Evidence for audits and customers

Auditors and enterprise customers increasingly ask not only whether a control exists but how you know it works continuously. Keep evidence lightweight: screenshots age poorly; pipeline logs, configuration-as-code history, and ticket trails age well. Map each baseline control to an artifact path—repository, dashboard, or alert—so answers take minutes instead of archaeology.

When customers ask about disk encryption and key custody, give them your one-page baseline, the metrics you track, and a recent example of a finding you closed. Specificity builds trust. Vague assurances invite deeper questionnaires.

Failure modes to watch

Documented standards that no pipeline enforces.
Tools deployed without owners or on-call.
Exceptions without expiry dates.
Metrics nobody reviews in a decision forum.
Security-only ownership of controls that require platform engineering to implement.
Copying peer company blogs without adapting to your architecture and threat model.

If two or more of these failure modes are present, pause new control adoption and repair the operating system around existing controls. Adding another product on top of ownerless findings increases noise without reducing risk.

Collaboration patterns that work

Embed security engineers with platform teams for implementation sprints rather than throwing PDF standards over the wall. Use office hours for design reviews. Keep a shared backlog visible to engineering managers so security work is planned alongside features. Celebrate remediations in engineering forums the same way you celebrate feature launches—culture follows recognition.

For cross-team controls, name a responsible team (R), an accountable manager (A), and consulted parties (C) explicitly. Ambiguous RACI is how tabletops discover that “someone” was supposed to rotate the keys.

Ninety-day improvement plan template

Week 1–2: draft or refresh the one-page baseline; agree must/should/may.
Week 3–4: encode must rules in CI and cloud policy; turn on reporting for should rules.
Week 5–8: remediate the top findings by blast radius; track weekly burn-down.
Week 9–10: run a drill or tabletop that assumes the control failed.
Week 11–12: review metrics, expire stale exceptions, publish what changed.

Reuse this template whenever you adopt a new baseline theme. Familiar structure lowers coordination cost and makes progress comparable across domains.

Closing perspective

Strong disk encryption and key custody practices are mostly about clarity, defaults, and feedback loops. Tools help, but only after ownership and measurement exist. Keep the written baseline short enough to read, strict enough to enforce, and alive enough to change when incidents teach you something new. That combination—more than any single product—predicts whether the next incident is merely painful or truly existential.

Start from the next change your team will merge. If that change can violate the baseline silently, you still have design work to do. If the pipeline would catch it, you are on the right path—keep going, measure, and harden the edges.