Profile Applicability:
Level 1
Description:
This check ensures that Amazon Neptune clusters are deployed in private subnets and not in public subnets. Public subnets expose the Neptune cluster to the internet, which could pose a security risk by allowing unauthorized access to the database.
Rationale:
Deploying Neptune clusters in private subnets helps ensure that the database is isolated from the public internet. Public subnets could allow inbound traffic to the database from the internet, increasing the risk of unauthorized access. By using private subnets, the database is protected from direct internet access and can only be accessed from authorized resources within the VPC, such as EC2 instances or internal services.
Impact:
If a Neptune cluster is in a public subnet, it could be exposed to malicious internet traffic, increasing the risk of data breaches, unauthorized access, and other security vulnerabilities. Ensuring that the cluster is deployed in a private subnet mitigates this risk.
Default Value:
By default, when a Neptune cluster is launched, it can be associated with either public or private subnets. The default setting may not always enforce private subnet deployment, so this check is necessary to ensure compliance.
Pre-requisites:
AWS Account with sufficient permissions to view and manage Neptune clusters.
Permissions: neptune:DescribeDBClusters, ec2:DescribeSubnets.
Neptune cluster deployment details, including VPC and subnet information.
Remediation:
Test Plan:
Using AWS Console:
Sign in to the AWS Management Console.
Navigate to Amazon Neptune Console.
Go to the Clusters section under Neptune.
Select the Neptune cluster you want to examine.
In the Details section, under the VPC & Subnet information, check the subnet associated with the cluster.
Public Subnet: If the subnet has a route to the internet (via an Internet Gateway), the cluster is in a public subnet.
Private Subnet: If the subnet does not have a route to the internet and is associated with a NAT Gateway, it is a private subnet.
Using AWS CLI:
Run the following AWS CLI command to list all Neptune clusters:
aws neptune describe-db-clusters --query 'DBClusters[*].{ClusterId:DBClusterIdentifier,SubnetGroup:DBSubnetGroup}'Use the following command to get the subnet information for the Neptune cluster:
aws ec2 describe-subnets --subnet-ids <subnet-id> --query 'Subnets[*].{SubnetId:SubnetId,MapPublicIpOnLaunch:MapPublicIpOnLaunch}'
Review the output:
If MapPublicIpOnLaunch is set to true, the subnet is a public subnet.
If MapPublicIpOnLaunch is set to false, the subnet is a private subnet.
Implementation Plan:
Using AWS Console:
Navigate to the Neptune Console.
Select your cluster.
Check the subnet associated with the cluster in the details section.
Modify the subnet:
If the cluster is in a public subnet, modify the cluster’s subnet group to use private subnets. You can do this by editing the DB subnet group to exclude the public subnet and include private subnets.
Apply the changes and confirm that the cluster is now using private subnets.
Using AWS CLI:
Modify the DB subnet group by creating a new subnet group with private subnets:
aws neptune create-db-subnet-group --db-subnet-group-name <new-subnet-group-name> --subnet-ids <private-subnet-id-1> <private-subnet-id-2>
Modify the Neptune cluster to use the new subnet group:
aws neptune modify-db-cluster --db-cluster-identifier <cluster-id> --db-subnet-group-name <new-subnet-group-name>
Verify the changes by describing the cluster and checking the associated subnet group.
Backout Plan:
If the cluster deployment in private subnets causes issues or impacts functionality:
Revert the cluster to use the original subnet group by specifying the previous subnet group name:
aws neptune modify-db-cluster --db-cluster-identifier <cluster-id> --db-subnet-group-name <original-subnet-group-name>
Verify the Neptune cluster’s accessibility and functionality after the backout.