组织级多子账号下强制AWS监听器启用TLS≥1.2的最佳方案

1. 优化SCP策略（通过请求参数匹配实现管控） #

虽然SCP不支持直接解析SslPolicy的加密版本，但可以通过请求参数字符串匹配拦截不合规操作：

• 编写SCP，拒绝所有创建/修改AWS::ElasticLoadBalancingV2::Listener的请求，除非请求中指定的SslPolicy属于TLS 1.2及以上的合规策略（比如ELBSecurityPolicy-TLS-1-2-2017-01、ELBSecurityPolicy-TLS13-1-2-2021-06等）。示例SCP代码：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "elasticloadbalancing:CreateListener",
        "elasticloadbalancing:ModifyListener"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "elasticloadbalancing:SslPolicy": [
            "ELBSecurityPolicy-TLS-1-2-*",
            "ELBSecurityPolicy-TLS13-*"
          ]
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}

• 配合组织级IAM权限边界，限制子账号IAM实体只能使用合规SSL策略，形成双重管控。

2. 简化AWS Config自定义规则的跨账号部署 #

如果之前觉得自定义Lambda规则不够灵活，可以通过以下方式降低维护成本：

• 启用AWS Config组织聚合器，在管理账号中创建自定义规则，借助AWSOrganizationsAccessRole自动同步规则到所有子账号，无需逐个配置权限。
• 规则逻辑中直接调用ELB API获取Listener的SslPolicy，对比合规策略列表标记不合规资源，还可配置自动修复（通过Lambda批量修改Listener的SSL策略）。
• 用AWS CloudFormation StackSets批量部署自定义规则模板到所有子账号，减少重复操作。

3. 用AWS Service Catalog从源头标准化ALB部署 #

通过Service Catalog创建预配置的ALB产品模板，从根源避免不合规资源：

• 在产品模板中固定AWS::ElasticLoadBalancingV2::Listener的SslPolicy参数为TLS 1.2及以上的合规值，禁止用户修改该参数。
• 搭配SCP限制子账号只能通过Service Catalog创建ALB，禁止直接调用ELB API或使用其他无管控方式创建负载均衡。

4. 用AWS Systems Manager批量修复存量资源 #

针对已存在的不合规Listener，可通过Systems Manager Automation批量处理：

• 创建自动化文档，遍历组织内所有账号的ALB Listener，检查SslPolicy并自动替换为合规策略。
• 利用Systems Manager跨账号执行能力，通过组织角色触发自动化任务，一次性完成存量资源的合规修复。

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