# Ensure RDS snapshots and cluster snapshots are not public

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292220564869-ensure-rds-snapshots-and-cluster-snapshots-are-not-public
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that no Amazon RDS DB snapshot or DB cluster snapshot is public. A public snapshot is shared with all AWS accounts, so any AWS customer can copy it or restore a database from it. Snapshots that are private or shared only with specific AWS account IDs pass.

**Rationale**

A public snapshot is a full copy of the database that anyone with an AWS account can restore. This can expose personal data, secrets and password hashes, reveal the database schema and provide credentials that allow attackers to move to other systems. Keeping snapshots private, and sharing them only with specific trusted accounts when required, applies least privilege. Encrypting snapshots with a customer managed KMS key adds further control, because encrypted snapshots cannot be made public.

**Impact**

-   Prevents anyone outside the organization from copying or restoring the database
    
-   Reduces the risk of data exposure and credential theft
    
-   Accounts that relied on the public snapshot lose access unless they are added as specific shared accounts
    

**Default Value**

DB snapshots and DB cluster snapshots are private by default. A snapshot becomes public only if its visibility is explicitly set to public.

**Pre-Requisites**

-   IAM permissions: rds:DescribeDBSnapshots, rds:DescribeDBClusterSnapshots, rds:DescribeDBSnapshotAttributes, rds:DescribeDBClusterSnapshotAttributes, rds:ModifyDBSnapshotAttribute and rds:ModifyDBClusterSnapshotAttribute
    
-   A list of the AWS account IDs, if any, that legitimately need access to the snapshot
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon RDS console and select **Snapshots**.
    
3.  Select a manual DB snapshot or DB cluster snapshot and choose **Actions**, then **Share snapshot**.
    
4.  Check that **DB snapshot visibility** is set to **Private**.
    
5.  Repeat for each snapshot in each region in use.
    
6.  If any snapshot is public, follow the implementation steps.
    

**CLI:**

List the DB snapshots and DB cluster snapshots:

aws rds describe-db-snapshots --region <REGION> --query "DBSnapshots\[\].\[DBSnapshotIdentifier,SnapshotType\]" --output table  
aws rds describe-db-cluster-snapshots --region <REGION> --query "DBClusterSnapshots\[\].\[DBClusterSnapshotIdentifier,SnapshotType\]" --output table

Show the accounts that can restore a DB snapshot:

aws rds describe-db-snapshot-attributes --region <REGION> --db-snapshot-identifier <SNAPSHOT\_ID> --query "DBSnapshotAttributesResult.DBSnapshotAttributes\[?AttributeName=='restore'\].AttributeValues"

Show the accounts that can restore a DB cluster snapshot:

aws rds describe-db-cluster-snapshot-attributes --region <REGION> --db-cluster-snapshot-identifier <CLUSTER\_SNAPSHOT\_ID> --query "DBClusterSnapshotAttributesResult.DBClusterSnapshotAttributes\[?AttributeName=='restore'\].AttributeValues"

A snapshot fails if the restore attribute values include all.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon RDS console and select **Snapshots**.
    
3.  Select the public snapshot and choose **Actions**, then **Share snapshot**.
    
4.  Set **DB snapshot visibility** to **Private**.
    
5.  If needed, add only the specific AWS account IDs that must have access.
    
6.  Choose **Save**.
    
7.  Repeat for each affected snapshot in each region in use.
    

**CLI:**

Make a DB snapshot private:

aws rds modify-db-snapshot-attribute --region <REGION> --db-snapshot-identifier <SNAPSHOT\_ID> --attribute-name restore --values-to-remove all

Make a DB cluster snapshot private:

aws rds modify-db-cluster-snapshot-attribute --region <REGION> --db-cluster-snapshot-identifier <CLUSTER\_SNAPSHOT\_ID> --attribute-name restore --values-to-remove all

**Backout Plan**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon RDS console and select **Snapshots**.
    
3.  Select the snapshot and choose **Actions**, then **Share snapshot**.
    
4.  Set **DB snapshot visibility** to **Public** and choose **Save**.
    

**CLI:**

aws rds modify-db-snapshot-attribute --region <REGION> --db-snapshot-identifier <SNAPSHOT\_ID> --attribute-name restore --values-to-add all  
aws rds modify-db-cluster-snapshot-attribute --region <REGION> --db-cluster-snapshot-identifier <CLUSTER\_SNAPSHOT\_ID> --attribute-name restore --values-to-add all

Note: rolling back makes the full database copy available to every AWS account again. Share with specific account IDs instead whenever possible.

**Reference**

-   [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER\_ShareSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html)
    
-   [https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshots-public-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshots-public-prohibited.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot-attribute.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot-attribute.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-snapshot-attribute.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-snapshot-attribute.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.
