Sharing an RDS database with an external auditor
When an auditor, a partner or another team inside the business needs to inspect the contents of a production database, the right mechanism is a shared snapshot rather than access to the running instance. It gives them a complete, point-in-time copy in their own account, on their own instance, with no network path to production and no credentials on the live database.
The approach
Section titled “The approach”Take an encrypted manual snapshot, share the snapshot with the auditor’s AWS account, and grant that account access to the KMS key the snapshot is encrypted with. The auditor copies the snapshot into their account and restores an instance from the copy.
This works because it:
- keeps the data encrypted at every stage;
- hands over a consistent copy as of one moment, which is what an audit wants;
- is controlled entirely through KMS key policy and snapshot attributes, so access is revocable;
- leaves the auditor operating their own instance, at their own cost, with no route into the production VPC.
The mechanics that catch people out
Section titled “The mechanics that catch people out”Only manual snapshots can be shared. An automated backup cannot be shared directly. Copy it to a manual snapshot first, then share the copy. The same applies to snapshots produced by AWS Backup.
A snapshot encrypted with the default AWS-managed KMS key cannot be shared at all.
This is the step most often missed. The default aws/rds key’s policy cannot be changed,
so no other account can be granted use of it. Copy the snapshot to a new snapshot
encrypted with a customer managed key, and share that.
The recipient needs access to the key, not just the snapshot. Grant the auditor’s
account kms:DescribeKey, kms:CreateGrant, kms:Decrypt, kms:GenerateDataKey and
kms:ReEncrypt* on the customer managed key, through the key policy. Sharing the
snapshot without the key produces a snapshot the recipient can see and cannot use.
An encrypted shared snapshot cannot be restored directly. The recipient must first copy it into their own account — re-encrypting it with a key they own — and restore from that copy. Unencrypted snapshots can be restored directly, which is one of the few practical differences between the two.
A snapshot can be shared with up to 20 AWS accounts. Encrypted snapshots can never be made public; only unencrypted ones can, and doing so exposes the data to every AWS account, so it is almost never appropriate.
Multi-AZ DB cluster snapshots cannot be shared, and snapshots using an option group with permanent or persistent options cannot be shared either — which affects some Oracle and SQL Server configurations.
Afterwards
Section titled “Afterwards”Sharing is revoked by removing the account from the snapshot’s restore attribute, and independently by removing its grant on the KMS key. Revoking after the auditor has copied the snapshot does not remove their copy — the copy is theirs, encrypted under their own key. Treat the hand-over as a data transfer, with whatever retention and deletion terms that implies, rather than as a permission that can be taken back.