Found Public RDS Snapshots

RDS Snapshots that are available publicly mean that any AWS customer can clone the data on those snapshots to their own RDS instance.

Details ¶

AWS RDS is a relational database hosting service that provides a near fully managed solution for database applications and infrastructure. This includes auxiliary services such as backup management as part of the RDS offering. Unlike a traditional database application where you have complete control over the service and its backups, RDS provides a snapshot utility as the primary backup solution. RDS Snapshots can be automated and are utilised as both a restore point for the original database as well as a base volume to create new databases from.

Snapshots have their own permission sets and are able to be publicly shared with all AWS customers. While there are specific use cases where sharing an entire database is intentional - such as preloaded databases for open-source projects or datasets - these scenarios represent a small fraction of actual use cases. Most data is intended to remain private and public sharing is likely a mistake.

Remediation ¶

Auditing your RDS configurations can help identify any publicly shared database snapshots as publicly shared snapshots are labelled as Public snapshots. Any snapshots that have been publicly shared should be reviewed to determine what data is on each snapshot and therefore what the consequences of making that data public includes. If your organization has no intention of sharing data for open-source purposes, policies should be established to prohibit public sharing. One easy policy that also ensures an improved security posture is to enforce all RDS snapshots with required AWS KMS Key encryption. Encrypting RDS snapshots using AWS KMS Keys blocks accidental public snapshot permissions as even if the snapshot is made public the underlying AWS KMS key will block unauthorised decryption actions.

For organizations considering open-source solutions, it is recommended to create a dedicated AWS account to serve as the source for such projects. This account should have minimal permissions, reduced access to sensitive data and be kept separate from commercial or enterprise-focused AWS accounts to ensure better security and manageability. This enables different levels of data protection to be isolated to different AWS accounts removing the need to juggle multiple levels of data sensitivity within a single AWS account. It also reduces the blast radius for an AWS account which will have some level of identity within the industry such that sensitive data is not included inside an account which will be publicly known.

Dealing with Unintentionally Shared Data ¶

If data is shared unintentionally, it is crucial to assess the sensitivity of the exposed data as the sensitivity of the data will dictate the response. For less critical cases, the incident can be resolved by deleting the affected snapshot and implementing policies to prevent future accidental sharing. This would be the case when sharing an empty database or data that does not include any sensitive elements such as a generic data schema, dummy data and generic logins. However, if the data includes regulated or sensitive information, the response may escalate to requiring a formal regulatory disclosure.

When addressing a data breach, it is important to seek architectural guidance to determine the most effective response. This includes referencing both legal requirements and organizational policies to ensure compliance and minimize potential impact including detailing the scope of the data and potential consequences. We’ve provided support in these scenarios and can advise with both full or partial context: