Profile Applicability:
Level 1
Description:
Amazon ElastiCache is a fully managed in-memory data store and cache service, supporting Redis and Memcached engines. ElastiCache clusters should be deployed in private subnets to prevent direct access from the public internet, enhancing security. This SOP ensures that ElastiCache clusters are not deployed in public subnets but rather in private subnets within a Virtual Private Cloud (VPC). By doing so, it limits access to the ElastiCache cluster and reduces exposure to the public internet, aligning with best practices for securing sensitive data and infrastructure.
Public subnets are typically used for resources that require internet access, such as load balancers or web servers. ElastiCache clusters, however, should be isolated in private subnets to prevent direct access and ensure better network segmentation.
Rationale:
Placing ElastiCache clusters in private subnets ensures that they are not directly accessible from the internet, enhancing security and reducing the attack surface. Only resources that need to access the cache, such as application servers in the private subnet or via NAT Gateways, should be allowed access. This improves security by:
Preventing unauthorized access from the internet.
Limiting exposure to attacks targeting publicly accessible endpoints.
Ensuring network isolation between the application layer and external services.
Impact:
Pros:
Improved Security: Prevents ElastiCache from being directly exposed to the internet, reducing the risk of unauthorized access.
Network Segmentation: Ensures that the ElastiCache cluster is isolated within the private network, limiting exposure to internal resources.
Regulatory Compliance: Meets security and compliance requirements for isolating sensitive resources, as required by standards such as SOC 2, PCI-DSS, or HIPAA.
Cons:
Configuration Complexity: May require additional configuration, such as setting up NAT Gateways or VPN connections, to allow internet-bound traffic from the private subnet.
Access Management: Requires careful management of which services can access the ElastiCache cluster, ensuring only authorized resources are allowed access.
Default Value:
By default, ElastiCache clusters are created in the same VPC subnet as specified during the cluster creation. If no explicit private subnet is chosen, the cluster could potentially be placed in a public subnet. This should be corrected during the cluster creation or modification process to ensure it's not using a public subnet.
Pre-requisite:
AWS IAM Permissions:
elasticache:DescribeCacheClusters
elasticache:ModifyCacheCluster
ec2:DescribeSubnets
AWS CLI installed and configured.
Knowledge of VPC subnets and ElastiCache configurations.
Remediation:
Test Plan:
Using AWS Console:
Sign in to the AWS Management Console.
Navigate to ElastiCache under Services.
Select Redis or Memcached and go to the Clusters page.
Choose the cluster you want to inspect.
Under Network Configuration, check the Subnet that the cluster is using.
Ensure that the subnet listed is a private subnet and does not have direct access to the internet (i.e., ensure Map Public IP on Launch is disabled).
Using AWS CLI:
To describe the cluster and check its subnet ID, run the following command:
aws elasticache describe-cache-clusters --query 'CacheClusters[*].{ClusterId:CacheClusterId,SubnetGroupName:CacheSubnetGroupName}'Identify the CacheSubnetGroupName and describe the subnets in that subnet group:
aws elasticache describe-cache-subnet-groups --cache-subnet-group-name <subnet-group-name>
Verify that the subnets listed are private subnets and not public subnets.
Implementation Steps:
Using AWS Console:
Sign in to the AWS Management Console
Navigate to ElastiCache.
Go to Redis or Memcached clusters and select the desired cluster.
Check the Network Configuration section:
Ensure the Cache Subnet Group includes only private subnets (i.e., subnets that do not have Auto-assign Public IP enabled).
If the cluster is in a public subnet, modify the subnet group:
Go to Subnet Groups in the ElastiCache Dashboard.
Modify the Cache Subnet Group to include private subnets only.
Apply the changes to the ElastiCache cluster.
Using AWS CLI:
To modify the Cache Subnet Group and ensure only private subnets are used, use the following command:
aws elasticache modify-cache-cluster \ --cache-cluster-id <cluster-id> \ --cache-subnet-group-name <new-private-subnet-group> \ --apply-immediately
Verify the modification by describing the cluster and checking that it uses private subnets:
aws elasticache describe-cache-clusters --query 'CacheClusters[*].{ClusterId:CacheClusterId,CacheSubnetGroupName:CacheSubnetGroupName}Backout Plan:
If the change to use a private subnet causes issues:
Identify the affected ElastiCache cluster and Cache Subnet Group.
Modify the Cache Subnet Group to include public subnets if necessary:
aws elasticache modify-cache-cluster \ --cache-cluster-id <cluster-id> \ --cache-subnet-group-name <public-subnet-group> \ --apply-immediately
Revert any other configurations that were modified during the change process.
Note:
If a private subnet requires access to the internet, configure NAT Gateways or VPN connections to allow outbound traffic for ElastiCache clusters that reside in private subnets.
Ensure proper security group configurations to limit access to ElastiCache clusters to only trusted instances or services.