To ensure that Database Migration Service (DMS) instances are not accessible from the internet, either through the network or the API can be achieved by configuring DMS instances to use private subnets that do not have a route to the internet, creating security groups that allow traffic only from specific IP addresses or CIDR ranges, disabling public access, and using IAM policies and VPC endpoints to control and restrict access to DMS instances. By implementing this rule, the risk of unauthorized access and potential data breaches through the internet is minimized, and data stored in DMS instances can be better protected.
To ensure that your DMS (Database Migration Service) instances are not accessible via the internet, you can follow the steps below:
- Use a private subnet: When creating your DMS instance, place it in a private subnet that does not have a route to the internet. This will prevent any internet traffic from reaching your DMS instance.
- Use a security group: Create a security group that allows traffic only from specific IP addresses or CIDR ranges. This will restrict access to your DMS instance to only those IP addresses that you have explicitly allowed.
- Use IAM policies: Use IAM policies to control access to your DMS instance. For example, you can create an IAM policy that allows only specific users or roles to access your DMS instance.
- Disable public access: When creating your DMS instance, select "No" for "Publicly accessible". This will prevent your DMS instance from being accessible via the internet.
- Use VPC endpoints: You can use VPC endpoints to connect to your DMS instance without requiring internet access. VPC endpoints provide a secure and private connection between your VPC and DMS instance.
By following these steps, you can ensure that your DMS instances are not accessible via the internet, and only authorized users with the appropriate permissions can access them.
Note: Remediation steps provided by Lightlytics are meant to be suggestions and guidelines only. It is crucial to thoroughly verify and test any remediation steps before applying them to production environments. Each organization's infrastructure and security needs may differ, and blindly applying suggested remediation steps without proper testing could potentially cause unforeseen issues or vulnerabilities. Therefore, it is strongly recommended that you validate and customize any remediation steps to meet your organization's specific requirements and ensure that they align with your security policies and best practices.