ECS任务连接Elastic Cache集群的安全配置最佳实践咨询

你当前的安全组配置完全不符合生产环境最小权限要求，属于高危配置：

• 入站规则对0.0.0.0/0开放6379端口，等于公网任何IP都能尝试访问你的Redis集群，只要对应子网存在公网访问路径（比如绑定了互联网网关、NAT配置了端口映射、跨VPC对等连接未做访问限制），就存在被暴力破解、数据泄露、勒索删库的风险，和你给资源打Private=true的标签没有任何关系。
• 把ECS、CodeBuild、ElastiCache全部绑定同一个安全组，完全没有做权限边界拆分，一旦其中任意一个资源被攻破，攻击者可以无阻碍横向移动访问同安全组内的所有资源，没有任何访问控制拦截。
• 当前出方向全开放所有协议、所有IP的访问，也不符合最小权限要求，存在被利用做内网穿透、外带数据的风险。

非常建议你为ElastiCache单独配置专属的私有子网和独立安全组，这是AWS生产环境的标准最佳实践：

• 子网层面：给ElastiCache分配独立的私有子网段，子网不配置公网IP分配、不添加互联网网关路由，仅保留VPC内网路由、必要的VPC服务端点路由，从网络层直接掐断公网直达缓存集群的路径。
• 安全组层面：为ElastiCache创建独立的专属安全组，入站规则不要配置任何公网CIDR段，仅添加两条规则：分别允许ECS任务绑定的安全组、CodeBuild项目绑定的安全组作为来源，访问TCP 6379端口即可。安全组引用规则跨同VPC下的所有子网生效，哪怕你的ECS、CodeBuild和ElastiCache在不同子网，只要网络路由连通，访问就不会受影响，而且后续你扩容ECS实例、更换CodeBuild运行环境，只要资源绑定原有安全组，不需要修改ElastiCache的安全组规则就能正常访问，比写死CIDR段灵活度高很多。
• 原有共享安全组建议拆分废弃，ECS、CodeBuild分别绑定各自的独立安全组，出方向按业务实际需要开放最小范围的端口和目标地址，不要默认全通所有协议和地址。

你现在CodeBuild能正常访问缓存集群，本质是因为当前安全组开放了0.0.0.0/0的入站，不是因为同安全组有特殊豁免，拆分安全组后用安全组引用的方式配置规则，访问连通性不会有任何变化。

• 你现在使用*.cache.amazonaws.com格式的官方端点连接集群是完全正确的，这个端点是ElastiCache内置提供的服务域名，会自动解析到集群节点的私有IP，在集群发生故障转移、节点扩缩容、配置变更时，域名解析记录会自动更新，不需要你手动维护节点地址列表。
• 如果想要使用cache:6379这类短地址访问，可以通过VPC私有DNS配置实现：在VPC关联的私有DNS托管区添加CNAME记录，将自定义的短域名（比如cache）指向你的ElastiCache官方端点，同时把对应域名后缀配置到VPC的DNS搜索列表中，VPC内的所有资源就可以直接用短域名访问缓存，所有解析流量都在VPC内部完成，不会走公网链路。
• 如果要实现localhost:6379访问的效果，仅适合老应用硬编码了本地地址无法修改的场景：可以在ECS任务、CodeBuild运行环境中部署一个轻量端口转发进程（比如socat、轻量Redis代理），将本地6379端口的流量转发到ElastiCache端点即可，这个方案需要额外维护旁路转发进程，没有特殊需求不推荐使用。

内容的提问来源于stack exchange，提问作者diegoaguilar