How to Audit Public Cloud Snapshots Before They Leak
Public cloud snapshots leak entire disks without touching a single production instance. One misconfigured EBS or RDS snapshot, or one long-lived Azure SAS grant, is a byte-for-byte copy of your data in a stranger’s hands. Audit them outside-in: enumerate every shared snapshot across providers, verify from an unprivileged account that it is truly readable, then lock sharing down and leave a guard in place so the exposure cannot quietly return.
AWS is explicit about the stakes: sharing an EBS snapshot publicly with all AWS accounts hands recipients every byte on that disk, because a shared snapshot exposes all of its data. The EBS snapshot sharing documentation shows the mechanism — a createVolumePermission group set to all — and pairs it with a blunt warning: share snapshots only with accounts you trust with all of your snapshot data.
Why Snapshots Slip Through
Snapshots inherit everything the source disk or database contained: credentials in home directories, application secrets, full customer tables. Sharing usually starts for a legitimate reason — a vendor migration, a support handoff, a one-off copy between accounts — and the revoke step never ships. Because snapshots live in a backup corner of the console, they escape the access reviews that focus on live IAM policy and object storage flags like the public access settings compared for S3, Azure Blob and GCS.
Encryption narrows the failure modes but does not close the case: only unencrypted EBS snapshots can be shared publicly, so customer-managed-key encryption silently removes the worst option — yet private sharing to a stale external account still hands over the same bytes.
Exposure Vectors to Enumerate
Build the inventory around the four sharing mechanisms that matter. Each row is its own check with its own readback command.
| Vector | What exposure looks like | Readback | Fix |
|---|---|---|---|
| EBS snapshot | createVolumePermission includes group all | aws ec2 describe-snapshots --owner-ids self, then inspect permissions per snapshot | Remove the all group |
| RDS manual snapshot | restore attribute contains all or unknown account IDs | aws rds describe-db-snapshot-attributes | Clear values; keep only accounts you can name |
| EBS-backed AMI | Public launch permission exposes the AMI’s snapshots | Describe images owned by the account; check the public flag | Remove launch permission or deregister |
| Azure managed snapshot | Active read-only SAS URI nobody remembers granting | Review activity logs for az snapshot grant-access | az snapshot revoke-access, re-issue short-lived |
Run the Audit in Order
- Enumerate owned snapshots in every active Region, not only the default one. Sharing is a per-snapshot attribute, and the block-public-access guard is Regional too.
- Flag every snapshot whose permissions include
all, or an account ID your billing owner cannot attribute to a current vendor or partner. Cross-check creation dates against change tickets. - Verify exposure from an outside account: attempt the describe and create-volume calls a recipient would make. Never trust the console filter alone — read the attribute directly.
- Unshare: remove the public group, trim stale account IDs, revoke SAS grants. Confirm with a second readback before you close the ticket.
- Hunt reuse while it was exposed. CloudTrail logs
SharedSnapshotCopyInitiatedwhen a shared snapshot is copied andSharedSnapshotVolumeCreatedwhen it is used to create a volume; route those events to incident review. - Record an owner and a next-review date per surviving share, so the next cycle starts from evidence instead of memory.
Database snapshots deserve the strictest readback. Amazon RDS caps each manual snapshot at up to 20 other AWS accounts, and setting visibility to Public makes the data restorable by every AWS account in the cloud. The RDS sharing guide warns against marking any snapshot with private information as Public, and the same restore attribute that grants access is what your audit reads.
Azure SAS Grants Count Too
Azure managed snapshots have no EBS-style public flag; the equivalent exposure is the SAS URI. A read-only SAS generated for an Azure managed snapshot can be used to copy or download the underlying VHD, and anyone holding the URL needs no Azure login at all. The official CLI sample shows the exact pattern to audit: az snapshot grant-access with an expiry in seconds, then a blob copy against the returned URI. Search your activity logs for grant-access calls, confirm each expiry against the task that justified it, and revoke anything with a duration measured in days.
Prevent Recurrence
Cleanup without a guard is a treadmill. Enable snapshot block public access: the block-all-sharing mode treats existing public snapshots as private, and block public access for EBS snapshots is a Regional, account-level setting that must be enabled in every Region you operate. Two gaps to plan for: it does not stop private sharing to stale accounts, and it does not prevent public sharing of EBS-backed AMIs, whose snapshots stay reachable through the image. Pair it with SCP guardrails that contain a compromised account so an over-broad share fails at the policy layer, and alert on snapshot attribute changes inside the logging baseline you already run.