如何在多账户环境下配置并实现安全事件自动化响应

Original URL: https://thinkwithwp.com/cn/blogs/security/how-to-perform-automated-incident-response-multi-account-environment/

面对安全事件，响应速度的快慢直接决定着事件造成的后续影响。自动化事件响应能够帮助我们提升安全保障能力，迅速减少受影响的资源范围，同时也将减少安全团队的重复工作强度。但在自动化层面，除了能够实现标准化响应的功能，我们还需要认真考虑种种可能出现的意外状况。

在本文中，我们将从一套现成的模板与对应模式出发，使用原生AWS工具以最低程度的代码编写量将自动事件响应流程扩展到AWS的多账户环境中。另外，我们还将探讨如何以资源标签为基础，设置例外事件处理机制。

安全响应无疑是个广泛而深刻的主题，因此本文只能提供一部分可供参考的备选解决方案。事件响应属于各类组织所实施的总体治理、风险与合规性（GRC）计划中的组成部分。关于更多详细信息，请参阅如何扩展云环境下的治理、风险与合规性程序。

重要说明：在引入自动化机制时，请务必谨慎。在非生产环境中，请仔细测试每一项自动响应，确保不在关键业务应用程序中使用未经充分测试的自动事件响应功能。

解决方案的优势与收益

在本文描述的解决方案中，您可以使用AWS Systems Manager自动化执行大多数事件响应步骤。您可以自主编写针对性事件响应策略，也可以使用预先编写的现成运行模版。AWS能够维护这些现有运行模版（自动化文档），保证您无需额外维护自动化代码库。AWS运行手册当中涵盖多种预定义用例，例如：启用Amazon Simple Storage Service (S3) 存储桶加密、打开Jira通知单或者终止Amazon Elastic Compute Cloud (EC2) 实例等等。这些操作的每次执行均已在AWS Systems Manager中进行了充分记录并具有可重复性。在少数情况下，没有现成的事件响应自动化模版，本文还在模板中提供三个附加的AWS Lambda函数，用以执行必要的事件响应操作。这些Lambda函数只需少量的代码修改即可使用，且在AWS原生工具之外没有外部工具依赖性。

大家可以使用集中安全账户在自动化运行模版中执行事件响应操作，且无需通过服务账户手动执行任何事件监控及事件响应操作。在本文中，我们将具体探讨以下几种模式：

• 根据Amazon GuardDuty警报或AWS Config发现结果对事件做出自动响应。
• 为包括主安全账户与多个服务账户的多账户环境设置部署模板。所有账户资源必须处于同一AWS Region，并且属于同一AWS Organization组织架构。
• AWS Systems Manager能够自动执行许多AWS托管自动化模版（您需要首先访问AWS管理控制台，才能通过链接查看所有自动化模版）。目前已上线Systems Manager自动化功能的AWS Ragions，详见此链接。
• 预先编写的Lambda函数能够：
  • 将允许的（开放的）安全组限制为约束条件更严格的CIDR（无类域间路由），包括限定该安全组的VPC（虚拟私有网络）范围。这样可以防止出现已知的网络配置错误，例如开放的安全组。
  • 通过将可能受到威胁的EC2实例添加到一个空的安全组，并删除其现有的安全组，来实现受威胁EC2的自动隔离。。
  • 通过将拒绝所有的策略添加到该主体，来阻止AWS Identity and Access Management（IAM）的用户或角色。
  • 将通知发送至Amazon Simple Notification Service (Amazon SNS) ，配合自动响应操作发布警报提示。
• 对不应执行操作进行例外处理。本文建议大家基于AWS资源标签，进行分散式例外处理。
• 将GuardDuty发现告警结果与AWS Security Hub集成，并自定义告警事件操作响应。这种方式主要用于手动执行某些特殊的、不适合自动响应处理的补救措施。
• 自定义AWS Config规则，用于对任意端口上的允许（开放）安全组进行检测。
• 可扩展的将其它安全服务发现结果映射到CloudWatch Events规则模式中定义的事件响应操作。本文将提供一个示例，说明如何扩展新的发现结果与响应操作。

本解决方案适用性说明

本方案仅向您展示如何对属于同一AWS Organization和Region的账户进行自动化安全响应的入门。更多关于开发安全事件响应综合方案信息，请参阅如何在AWS环境中准备并响应安全事件。

本解决方案与AWS Config补救措施之间的区别

AWS Config补救功能可在单个AWS账户中使用AWS Systems Manager修复不合规资源。在本文中的解决方案包括GuardDuty警报与AWS Config，这是一种通过中央安全账户管理的多账户环境解决方案，基于资源标签异常处理规则，同时配合使用AWS Lambda函数实现其他安全响应操作。

如何选项适合的事件响应方法

我们可以选择多种技术模式与解决方案实现安全事件响应。在为您企业选择合适的解决方案时，应该考虑到响应操作灵活性、所需要的资源以及安全工程师的技能水平。此外，您还应考虑解决方案对于外部代码和应用程序的依赖性、软件许可成本以及您组织对AWS服务熟悉程度和使用经验。

如果您希望在本方案之外，进一步拓展AWS Systems Manager的灵活性与扩展性，建议您使用AWS Step Functions，具体请参考如何在AWS环境中准备并响应安全事件，以及《运行手册、事件报告与事件响应DIY指南》。您也可以为运行模版创建相应工作流，并完全控制所有可行的响应操作选项。

本解决方案总体架构

在AWS上多账户事件响应架构图如图1所示。

图1：多账户事件响应架构图

在您的服务账户中，我们需要监控并执行事件响应的环境，具体步骤如下：

• 将GuardDuty发现结果转发到CloudWatch Events服务。
• 将AWS Config合规性状态变更记录转发到CloudWatch Events服务。
• 通过CloudWatch Events服务总线，将GuardDuty与AWS Config的汇总数据转发至中央安全账户。

在您的中央安全账户中：

• 使用CloudWatch Events规则将服务账户中的各种事件映射到一项或者多项响应操作。根据事件模式的定义，每项规则都对应一项事件响应操作，并根据一条或多条发现结果触发执行操作。如果存在例外规则，则不执行响应操作。

可以采取的可能操作清单包含：

1. 触发由安全帐户中的Lambda函数StratSsmAutomation调用的Systems Manager自动化模版。

2. 通过调用Lambda函数IsolateEc2为EC2实例附加一个空安全组并删除原安全组，来隔离EC2实例。这要求事件响应角色在于目标服务账户中。

3. 通过调用Lambda函数BlockPrincipal拒绝所有策略来阻止IAM主体，这要求事件响应角色在目标服务账户中。

4. 通过调用Lambda函数ConfineSecurityGroup，为安全组配置安全CIDR。这种处理方式要求事件响应角色在目标服务账户之内。

5. 将发现结果发送至SNS主题，在方案之外进行处理。例如，通过人工评估或仅作为参考。

• 在调用安全账户中AWS Systems Manager，并指定相同服务账户和AWS Regions中的目标。
• 由安全账户执行Systems Manager自动化操作策略，是针对服务账户中的资源。例如：EC2、S3或者IAM资源。
• 直接由安全账户针对服务账户执行响应操作。例如，通过IAM角色隔离可能受到入侵的EC2实例。
• 使用Security Hub自定义操作手动触发安全响应。这种方式适用于需要在执行操作之前进行深入调查的复杂发现的手动响应操作。

安全事件响应操作的决策

您首先需要明确信息安全策略决策，然后创建相应的自动化安全响应列表。其中需要考虑的因素包括：资源的分类，以及自动化技术的复杂程度。本文建议从较常见、不太复杂事例入手，确保尽快获得效果，并随着经验的积累而逐步提升响应操作复杂性。另外，您组织内由许多利益相关方。例如：业务、IT运营、信息安全以及风险与合规团队等，都应参与到自动化事件响应操作的决策中。当然，也需要得到高层管理团队的支持以建立完善的执行策略。

安全事件响应的例外规则

在某些特殊情况下，采取自动响应操作不是明智的。例如，您可能不希望自动响应操作涉及核心生产数据库服务器的事件，因为一旦发生意外操作将对业务运营产生重大影响。相反，在实际响应之前，您需要人工判断并进行相应操作。在有些情况下，您也许明确知晓哪些资源不需要进行警报提示。例如：有意开放安全组作为公共Web服务器时发出报警。为了处理这些例外场景，有一套专门的解决方案。您可以在安装期间自由定义具体的标签名称。例如：为AWS资源添加一条SecurityException标签，则不会执行响应操作。

其中，如表1所示，为本解决方案模板中实现的响应示例。您可以根据组织的实际情况采用不同的操作与不同的响应优先级。您可以在Active Finding Types当中找到最新GuardDuty发现结果列表，并在AWS Config Managed Rules中找到AWS Config的最新列表。

环境安装

• 在安全账户中，选择 Launch Stack以启用模板。另外，您也可以通过GitHub获取最新代码。
• 为安全账户提供以下参数（参见图2）：
  • S3 bucket with sources：此存储桶包含所有源，例如Lambda函数及模板。如果您不需要对源进行自定义，则可保留默认文本。
  • Prefix for S3 bucket with sources：用于全部对象的前缀。如果您不需要对源进行自定义，则可保留默认文本。
  • Security IR-Role names: 安全账户中Lambda函数在执行响应操作时所必需的角色。此角色由服务账户中启动的栈负责创建。
  • Security exception tag: 用于定义安全例外的标签名称。带有此标签的资源不会根据安全发现结果而自动更改。例如，您可以为公开网站中的获准开放安全组添加例外标记。
  • Organization ID: 您的AWS组织ID，用于授权将CloudWatch Events转发至安全账户。您的各账户必须为同一AWS组织内的成员。
  • Allowed network range IPv4: 此CIDRv4范围用于限制所有未被标记为例外的开放安全组。
  • Allowed network range IPv6: 此CIDRv6范围用于限制所有未被标记为例外的开放安全组。
  • Isolate EC2 findings: 用于对EC2实例进行隔离的全部GuardDuty发现结果的列表，以逗号分隔。
  • Block principal finding: 策略阻止特定角色或用户的所有GuardDuty发现结果的列表，以逗号分隔。

图2：安全账户中的堆栈启动页面

• 在各服务账户中，选择 Launch Stack以启动模板。

另外，您也可以通过GitHub获取最新代码，或者为示例代码提交贡献。

• 为各个服务账户提供以下参数：
  • S3 bucket with sources：此存储桶包含所有源，例如Lambda函数及模板。如果您不需要对源进行自定义，则可保留默认文本。
  • Prefix for S3 bucket with sources：用于全部对象的前缀。如果您不需要对源进行自定义，则可保留默认文本。
  • Security IR-Role names: 安全账户中Lambda函数在执行响应操作时所必需的角色。此角色由服务账户中启动的栈负责创建。
  • Security account ID: CloudWatch Events将被转发至此中央安全账户。
  • Enable AWS Config: 定义您是否需要在此栈中启用AWS Config。如果您已经启用了AWS Config，则可保留默认值false。
  • Create SNS topic: 仅在启用AWS Config并希望变更配置以实现指向SNS的流式传输（可选）时，才需要提供SNS主题名称。如果不需要，请将此字段留空。
  • SNS topic name: 如果启用WS Config，则在此处创建SNS主题名称。默认文本为Config。
  • Create S3 bucket for AWS Config: 如果您启用了AWS Config，则模板会为AWS Config创建一个S3存储桶。
  • Bucket name for AWS Config: 为AWS Config所创建S3存储桶的名称。默认文本为 config-bucket-{AccountId}。
  • Enable GuardDuty: 如果您尚未在服务账户中启用GuardDuty，则可在这部分中启用。

环境测试

在完成两套栈的部署之后，您可以任选一个服务账户通过以下操作步骤完成环境测试。在测试之前，您可以使用Security_Alerts_[Your_Stack] 前缀订阅SNS主题以收取安全事件通知。

• 创建并打开安全组0.0.0.0/0，且不添加任何例外标签。几分钟之后，安全组即被限制在您通过栈定义的安全CIDR之内。
• 创建一个S3存储桶，但不启用加密。几分钟之后，存储桶创建完成并采用默认AES-256加密。
• 要在GuardDuty中阻止IAM实体，您可以在GuardDuty面板的Threat List当中定义一份恶意IP列表，而后创建一个测试角色或者用户。当通过该IP执行API调用时，随之生成的GuardDuty发现结果将自动触发对IAM角色或用户的阻止操作。
• 您可以部署Amazon GuardDuty tester 并生成相应发现结果，例如Trojan:EC2/DNSDataExfiltration 或者 CryptoCurrency:EC2/BitcoinTool.B!DN.。此GuardDuty发现结果将删除现有安全组并附加一个新的空安全组，对EC2实例进行隔离。然后可以将此新的空组配置为稍后进行取证访问。

响应操作的例外

如果资源被标记为SecurityException，则代表不会执行响应操作。标签名称为安全账户中CloudFormation栈的参数，您可以在安装时进行自定义。标签的值没有经过验证，但最好参考标准文档（例如Jira问题解答）提供的值。这样，您可以构建批准的审核链。例如：

Tag name:  SecurityException
Tag value: Jira-1234

请保证只能由相应的角色，对安全标签进行设置或修改。您可以通过两种方式实现这种效果。第一种方法是将deny语句附加到所有没有分配此标记的策略中。例如：下面权限策略中显示了拒绝IAM，EC2和S3服务的拒绝此标签的设置，删除和编辑的策略声明示例。此策略不禁止使用资源，例如：使用此标签启动或停止EC2实例。关于更多详细信息，请参阅基于标签键控制访问操作。

{
        {
            "Sid": "S3-Sec-Tag",
            "Effect": "Deny",
            "A ction": [
                "s3:PutBucketTagging",
                "s3:PutObjectTagging"
            ],
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringLikeIfExists": {
                    "aws:TagKeys": "TAG-NAME-SecurityException"
                }
            }
        },
        {
            "Sid": "EC2-VPC-Sec-Tag",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringLikeIfExists": {
                    "aws:TagKeys": "TAG-NAME-SecurityException"
                }
            }
        }
    ]
}

在以上策略中，您需要将TAG-NAME-SecurityException 修改匹配您自己的标签名称。

第二种方式是使用标签策略，管理多个AWS账户中的标签。

集中式与分散式例外管理

添加安全标签是一种分散式方法。在这种方法中，您不需要中央例外数据库来记录补救异常。中央例外数据库要求您知道每个单独的资源ID来设置例外，但这种要求有时缺乏可行性。 Amazon EC2 Auto Scaling 就是个很好的示例，您可能无法预先知晓EC2实例的ID。在扩展事件中，实例ID无法预先确定或预先批准。此外，中央例外数据库还必须与资源的生命周期保持同步。例如：在实例规模收缩事件当中。因此，在资源上使用标签是一种分散方法。如果需要，自动规模伸缩在启动配置中可以传播安全例外标签，具体示例请参阅标记您的自动规模伸缩EC2实例。

您可以管理IAM策略及角色，并以集中方式在AWS CodePipeline之内进行标记。这样，您就可以为安全例外建立起集中的实施点，但将资源标签的存储分散到资源本身。

使用AWS资源组，您能够随时为所有清单及审计提议找到与之对应的资源及安全标签。关于更多详细信息，请参阅在AWS资源组中构建查询与组。

监控安全警报

您可以订阅带有Security_Alerts_[Your_Stack]前缀的SNS主题，借此收取关于安全事件或执行失败的通知信息。

每项操作的执行都由CloudWatch Events所触发，且各事件也将生成对应的CloudWatch指标。在CloudWatch rules下，您可以看到由服务账户转发而来的各事件规则，或者中央安全账户中触发的具体响应操作。对于各项CloudWatch规则，您可以勾选规则旁的复选框以查看对应指标，如图3所示，而后选择Show metrics for the rule。

图3：CloudWatch中的GuardDuty Events转发指标

自定义创建新规则

与发现结果相对应的响应操作由安全账户中的CloudWatch Events规则进行定义。如果您希望定义新的响应操作，只需要更新中央安全账户即可。您无需调整服务账户设置，因为服务账户只负责将事件转发至安全账户。

例如：您的团队决定创建一项新的SSM操作（终止EC2实例），并通过GuardDuty发现结果Backdoor:EC2/C&CActivity.B!DNS进行触发。在安全账户中，前往AWS管理控制台中的CloudWatch处，通过以下操作步骤创建一项新规则（详见图4）：

图4：创建CloudWatch规则

• 转到CloudWatch Events并创建一项新规则。在“ Event Pattern事件模式”中的“ Build custom event pattern构建自定义事件模式”下，定义以下JSON：
  {
  "detail-type": [
    "GuardDuty Finding"
  ],
  "source": [
    "aws.guardduty"
  ],
  "detail": {
    "type": [
      "Backdoor:EC2/C&CActivity.B!DNS"
    ]
  }
}
• 将规则目标设置为Lambda函数，以执行SSM StratSsmAutomation。使用输入转换器可自定义Lambda函数的调用参数。

在Input paths map部分：
{
   "resourceId":"$.detail.resource.instanceDetails.instanceId",
   "account":"$.account"
}

在Input template字段当中，输入以下内容：
{
   "account":<account>,
   "resourseType":"ec2:instance",
   "resourceId":<resourceId>,
   "AutomationDocumentName":"AWS-TerminateEC2Instance",
   "AutomationParameters":{
      "InstanceId":[
      <resourceId>  
      ]
   }
}

您将待执行的SSM自动化模版名称作为输入参数进行传递。在本用例中，模版名称为AWS-TerminateEC2Instance，而参数则是名为AutomationParameters的JSON结构。

现在，我们已经创建了一项新的响应操作，可随时测试。

故障排查

安全账户中发生的所有自动化执行，都将被记录在AWS Systems Manager的Automation Execution之下。您也可以参考AWS Systems Manager自动化文档。

如果Lambda函数执行失败，则会触发一项CloudWatch警报，且通知将被发送至具有 Security_Alerts_[Your_Stack]前缀的SNS主题处。安全账户中的Lambda函数执行将记录在Lambda函数的CloudWatch日志组内，您可以通过日志了解Lambda函数是否得到成功执行。

Security Hub集成

AWS Security Hub汇总来自GuardDuty以及其他提供商的警报信息。要使用Security Hub聚合警报，必须首先激活Security Hub，而后部署本解决方案。接下来，我们通过主安全账户对当前环境账户发送邀请。关于更多详细信息，请参阅AWS Security Hub中的主账户与成员账户。

与Security Hub的集成需要手动触发，不是自动响应体系的一部分。如果发现结果需要在触发操作之前的安全调查，则适合使用Security Hub手动触发机制。

在Security Hub控制台上，选择发现并使用右上角处的Actions下拉菜单以触发响应，具体如图5所示。此时将由CloudWatch事件调用自动响应操作，例如通过Lambda函数隔离EC2实例。该Lambda函数将从服务账户处提取GuardDuty发现结果，并可相应执行以下几种操作：Isolate EC2 Instance、Block Principal或者Send SNS Notification.。

只能选择一个资源来执行。如果选择多个资源，则不会执行响应，对应的Lambda日志消息将显示在CloudWatch Logs中。

图5：Security Hub集成

解决方案的成本

解决方案的具体成本，取决于您AWS账户中实际生成的事件以及所选择的AWS区域。一般来说，每个账户每月的费用可能只为几美元。您可以参阅 GuardDuty费率说明、AWS System Manager中的自动化费率说明以及AWS Config pricing中的六项AWS Config规则进行成本建模。AWS Lambda与Amazon CloudWatch的预期成本可控制在最低水平，甚至可能已经包含在您的免费套餐当中。您也可以选择使用Security Hub，详见AWS Security Hub费率说明。

总结

在本文中，我们了解了如何使用AWS原生功能部署自动化事件响应框架。您可以轻松扩展这套框架以满足当前及未来的实际需求。如果您需要进一步扩展，请联系 AWS 专业服务或者AWS合作伙伴。如果您有其他技术问题，请参阅 Amazon GuardDuty或者AWS Config论坛。再次强调，本文介绍的解决方案仅为阐述自动化安全响应概念的示例，无法作为全面的解决方案使用。

如果您对本文有任何建议或反馈，请在评论区中与我们交流。

如果希望了解关于AWS Security的更多操作方法、新闻与功能公告，请在 Twitter上关注我们。

本篇作者