周边安全 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

周边安全

通过进行简短的调查来影响 AWS 安全参考架构 (AWS SRA) 的未来。

本节扩展了 AWS SRA 指南,为在 AWS 平台上构建安全边界提供了建议,其中深入探讨了 AWS 周边服务,以及这些服务如何适应 AWS SRA 定义的 OU。

在本指南的上下文中,周边被定义为应用程序连接到互联网的边界。周边的安全性包括安全的内容分发、应用程序层保护和分布式拒绝服务(DDoS)缓解措施。AWS 周边服务包括亚马逊 CloudFront、AWS WAF、AWS Shield、亚马逊 Route 53 和 AWS Global Accelerator。这些服务旨在提供对 AWS 资源和内容分发的安全、低延迟、高性能的访问。您可以将这些外围服务与其他安全服务(例如 Amazon GuardDuty 和 AWS Firewall Manager)一起使用,以帮助为您的应用程序构建安全的边界。

多种周边安全架构模式可用于满足不同的组织需求。本节重点介绍两种常见模式:在中央(网络)账户中部署周边服务,以及将部分周边服务部署到个人工作负载(应用程序)账户。本节涵盖两种架构的优势及其主要注意事项。

在单个网络账户中部署周边服务

下图建立在基准 AWS SRA 的基础上,旨在说明将周边服务部署到网络账户的架构。

将周边服务部署到网络账户

将周边设备服务部署到单个网络账户有以下好处:

  • 这种模式支持诸如高度监管行业之类的用例,在这些用例中,您希望将整个组织的周边服务管理限制在单个专业团队中。

  • 该模式可简化限制网络组件的创建、修改和删除所需的配置。

  • 该模式可简化检测,因为检查在一个地方进行,从而减少了日志聚合点。

  • 您可以创建自定义最佳实践资源,例如 CloudFront 策略和边缘函数,并在同一个账户中跨分配共享这些资源。

  • 该模式通过减少实施更改的地点,简化对配置错误敏感的业务关键型资源 [例如内容分发网络(CDN)缓存设置或 DNS 记录] 的管理。

以下各节将深入介绍每项服务,并讨论架构方面的注意事项。

亚马逊 CloudFront

Amazon CloudFront 是一项内容分发网络 (CDN) 服务,专为实现高性能、安全性和开发者便利性而构建。对于面向互联网的公共 HTTP 终端节点,我们建议您使用 CloudFront 来分发面向互联网的内容。 CloudFront 是一种反向代理,可作为全球应用程序的单一入口点。它还可以与 AWS WAF 和边缘功能(例如 Lambda @Edge)和 CloudFront 函数结合使用,以帮助创建安全且可自定义的内容交付解决方案。

在此部署架构中,包括边缘功能在内的所有 CloudFront 配置都部署到网络帐户中,并由集中式网络团队管理。只有网络团队中获得授权的员工才能访问此账户。想要更改 AWS WAF 的 CloudFront 配置或 Web 访问控制列表 (Web ACL) 的应用程序团队应向网络团队申请这些更改。我们建议您建立工作流,例如工单系统,供应用程序团队请求进行配置更改。

在这种模式中,动态和静态来源都位于各个应用程序账户中,因此访问这些来源需要跨账户权限和跨账户角色。来自 CloudFront 分配的日志配置为发送到日志存档帐户。

AWS WAF

AWS WAF 是一种 Web 应用程序防火墙,让您能够监控转发到受保护 Web 应用程序资源的 HTTP 和 HTTPS 请求。此服务可以帮助保护您的资源免受常见 Web 漏洞攻击和容量威胁,以及更复杂的威胁,例如账户创建欺诈、未经授权访问用户账户以及试图逃避检测的机器人。AWS WAF 可以帮助保护以下资源类型: CloudFront 分配、Amazon API Gateway REST API、应用程序负载均衡器、AWS GraphQL AppSync API、Amazon Cognito 用户池、AWS App Runner 服务和 AWS 验证访问实例。

在此部署架构中,AWS WAF 附加到网络账户中配置的 CloudFront 分配。当您使用配置 AWS WAF 时 CloudFront,外围占用空间会扩展到 CloudFront 边缘站点,而不是应用程序 VPC。这可以将恶意流量过滤到更靠近该流量来源的地方,并有助于限制恶意流量进入您的核心网络。

虽然 Web ACL 部署在网络账户中,但我们建议您使用 AWS Firewall Manager 来集中管理 Web ACL,并确保所有资源都合规。将安全工具账户设置为 Firewall Manager 的管理员账户。部署带自动修复功能的 Firewall Manager 策略,强制您账户中的所有(或选定) CloudFront 分配都附有 Web ACL。

通过配置对 S3 存储桶的跨账户存取权限,您可以将完整的 Amazon WAF 日志发送到日志存档账户中的 S3 存储桶。有关更多信息,请参阅有关此主题的 AWS re:Post 文章

AWS Shield 和 AWS Route 53 运行状况检查

AWS Shield Standard 和 AWS Shield Advanced 可为网络和传输层(第 3 层和第 4 层)以及应用程序层(第 7 层)的 AWS 资源提供保护,以抵御分布式拒绝服务(DDoS)攻击。Shield Standard 是自动包含的,除了已为 AWS WAF 和其他 AWS 服务支付的费用外,无需额外费用。Shield Advanced 为您的亚马逊 EC2 实例、Elastic Load Balancing 负载均衡器、 CloudFront 分布和 Route 53 托管区域提供扩展的 DDoS 事件保护。如果您拥有高知名度的网站,或者您的应用程序容易出现频繁的 DDoS 事件,请考虑使用 Shield Advanced 提供的其他功能。

本节重点介绍 Shield Advanced 的配置,因为 Shield Standard 不可由用户配置。

要配置 Shield Advanced 以保护您的 CloudFront 分配,请将网络账户订阅到 Shield Advanced。在该账户中,添加 Shield Response Team(SRT)支持,并提供 SRT 团队在 DDoS 事件期间访问您的 Web ACL 所需的权限。在活动的 DDoS 事件期间,您可以随时联系 SRT,为您的应用程序创建和管理自定义缓解措施。通过提前配置访问权限,SRT 可以灵活地调试和修改 Web ACL,而无需在事件期间管理权限。

使用具有自动修复功能的 Firewall Manager,将您的 CloudFront 发行版添加为受保护的资源。如果您还有其他面向互联网的资源,例如应用程序负载均衡器,则可以考虑将其添加为 Shield Advanced 受保护资源。但是,如果您的数据流中有多个 Shield Advanced 受保护的资源(例如,您的 Application Load Balancer 是其来源 CloudFront),我们建议您仅使用入口点作为受保护的资源,以减少 Shield Advanced 的重复数据传出 (DTO) 费用。

启用主动参与功能,让 SRT 可以主动监控您的受保护资源并根据需要与您联系。要有效地配置主动参与功能,请为您的应用程序创建 Route 53 运行状况检查并将其与 CloudFront 分布相关联。Shield Advanced 在评估事件时使用运行状况检查作为额外的数据点。应正确定义运行状况检查,以减少检测误报。有关识别运行状况检查的正确指标的更多信息,请参阅 AWS 文档中的 Best practices for using health checks with Shield Advanced。如果您检测到 DDoS 攻击尝试,可以联系 SRT 并为您的支持计划选择可用的最高严重性等级。

AWS Certificate Manager 和 AWS Route 53

AWS Certificate Manager(ACM)可帮助您预置、管理和续订公有及私有 SSL/TLS X.509 证书。当您使用 ACM 管理证书时,使用强大的加密和密钥管理最佳实践,可以安全地保护和存储证书私钥。

ACM 部署在网络账户中,以便为 CloudFront 分发生成公共 TLS 证书。需要使用 TLS 证书才能在观看者和之间建立 HTTPS 连接 CloudFront。有关更多信息,请参阅CloudFront 文档。ACM 提供 DNS 或电子邮件验证来验证域所有权。我们建议您使用 DNS 验证而不是电子邮件验证,因为使用 Route 53 管理公有 DNS 记录时,您可以直接通过 ACM 更新记录。只要证书正在使用中,并且别名记录保持存在,ACM 就会自动续订 DNS 验证的证书。

CloudFront 访问日志和 AWS WAF 日志

默认情况下, CloudFront 访问日志存储在网络账户中,AWS WAF 日志通过使用 Firewall Manager 日志记录选项聚合到安全工具账户中。我们建议您在日志归档账户中复制这些日志,以便集中式安全团队可以出于监控目的访问它们。

设计注意事项
  • 在此架构中,单个网络团队上的大量依赖项可能会影响您快速做出更改的能力。

  • 监控每个账户的服务限额。服务限额(也称为限制)是您的 AWS 账户使用的服务资源或操作的最大数量。有关更多信息,请参阅 AWS 文档中的 AWS service quotas

  • 向工作负载团队提供特定指标可能会增加复杂性。

  • 应用程序团队对配置的访问权限受到限制,这可能会导致等待网络团队代表他们实施更改的开销。

  • 在单个账户中共享资源的团队可能会争夺相同的资源和预算,这可能会导致资源分配方面的挑战。我们建议您建立相应机制,以向使用网络账户中部署的周边服务的应用程序团队收取费用。

在单个应用程序账户中部署周边服务

下图说明了在单个应用程序账户中独立部署和管理周边服务的架构模式。

将周边服务部署到单个应用程序账户

将周边服务部署到应用程序账户有几个好处:

  • 这种设计为各个工作负载账户提供了根据需求自定义服务配置的自主权。这种方法消除了对专业团队在共享账户中实施资源变更的依赖,并让每个团队中的开发人员能够独立管理配置。

  • 每个账户都有自己的服务限额,因此应用程序所有者不必在共享账户的限额范围内工作。

  • 这种设计将恶意活动影响限制在特定账户范围内并防止攻击蔓延到其他工作负载,以帮助遏制该影响。

  • 它消除了变更风险,因为影响范围仅限于相关工作负载。您还可以使用 IAM 来限制可以实施变更的团队,从而在工作负载团队和集中式网络团队之间实现逻辑上的分离。

  • 通过分散网络入口和出口的实施,但拥有通用的逻辑控制(通过使用 AWS Firewall Manager 等服务),您可以调整网络控制以适应特定工作负载,同时继续满足最低的控制目标标准。

以下各节将深入介绍每项服务,并讨论架构方面的注意事项。

亚马逊 CloudFront

在此部署架构中,Amazon CloudFront 配置(包括边缘功能)在各个应用程序账户中管理和部署。这可以验证每个应用程序所有者和工作负载账户是否都有根据其应用程序需求配置周边服务的自主权。

动态和静态来源位于同一个应用程序账户中, CloudFront 分配对这些来源具有账户级别的访问权限。来自 CloudFront分配的日志存储在本地的每个应用程序帐户中。可以将日志复制到日志归档账户,以满足合规性和监管需求。

AWS WAF

在此部署架构中,AWS WAF 附加到应用程序账户中配置的 CloudFront 分配。与之前的模式一样,我们建议您使用 AWS Firewall Manager 集中管理 Web ACL,并确保所有资源都合规。应将常见 AWS WAF 规则(例如 AWS 托管核心规则集和 Amazon IP 信誉列表)添加为默认规则。这些规则会自动应用于应用程序账户中任何符合条件的资源。

除了 Firewall Manager 强制执行的规则外,每个应用程序所有者还可以将与其应用程序安全相关的 AWS WAF 规则添加到 Web ACL 中。这为每个应用程序账户提供了灵活性,同时仍保留了对安全工具账户的总体控制权。

使用 Firewall Manager 日志记录选项将日志集中在一起,并将其发送到安全工具账户中的 S3 存储桶。每个应用程序团队都有权查看其应用程序的 AWS WAF 控制面板。您可以使用诸如 Amazon 之类的服务来设置控制面板 QuickSight。如果发现任何误报或需要对 AWS WAF 规则进行其他更新,则可以将应用程序级别的 AWS WAF 规则添加到 Firewall Manager 部署的 Web ACL 中。日志将复制到日志归档账户并归档以进行安全调查。

AWS Global Accelerator

AWS Global Accelerator 让您可以创建加速器,以提高本地和全球用户的应用程序性能。Global Accelerator 为您提供静态 IP 地址,这些地址可作为托管在一个或多个 AWS 区域中的应用程序的固定入口点。您可以将这些地址与区域性 AWS 资源或端点相关联,例如应用程序负载均衡器、网络负载均衡器、EC2 实例和弹性 IP 地址。这让流量能够以尽可能靠近您用户的方式进入 AWS 全球网络。

Global Accelerator 目前不支持跨账户来源。因此,它会部署到与来源端点相同的账户中。在每个应用程序账户中部署加速器,并将其作为 AWS Shield Advanced 的受保护资源添加到同一个账户中。Shield Advanced 缓解措施将只允许有效的流量到达 Global Accelerator 侦听器端点。

AWS Shield Advanced 和 AWS Route 53 运行状况检查

要配置 AWS Shield Advanced 以帮助保护您的 CloudFront 分配,您需要为每个应用程序账户订阅 Shield Advanced。您应该配置诸如访问 Shield Response Team(SRT)和账户级别的主动参与等功能,因为这些功能应在与资源相同的账户中进行配置。使用带自动修复功能的 Firewall Manager 将您的 CloudFront 分配添加为受保护资源,并将该策略应用于每个账户。每个 CloudFront 分配的 Route 53 运行状况检查应部署在同一个账户中并与资源相关联。

Amazon Route 53 和 ACM

当您使用诸如亚马逊之类的服务时 CloudFront,应用程序账户需要访问托管根域名的账户,才能创建自定义子域名并应用由 Amazon Certifice Manager (ACM) 或第三方证书颁发的证书。您可以使用 Amazon Route 53 区域委托,将公共域从中央共享服务账户委托给个别应用程序账户。区域委托让每个账户都能创建和管理特定于应用程序的子域,例如 API 或静态子域。每个账户中的 ACM 允许每个应用程序账户根据自己的需求管理证书审查和验证流程(组织验证、扩展验证或域验证)。

CloudFront 访问日志、全球加速器流日志和 AWS WAF 日志

在这种模式中,我们在单个应用程序账户的 S3 存储桶中配置 CloudFront 访问日志和全球加速器流日志。想要分析日志以进行性能调整或减少误报的开发人员可以直接访问这些日志,不必请求访问中央日志归档。本地存储的日志还可以支持区域合规性要求,例如数据驻留或 PII 模糊处理。

使用 Firewall Manager 日志记录将完整的 AWS WAF 日志存储在日志归档账户的 S3 存储桶中。应用程序团队可以使用使用 Amazon 等服务设置的仪表板查看日志 QuickSight。此外,每个应用程序团队都可以从自己的账户访问采样的 AWS WAF 日志,以便快速调试。

我们建议您将日志复制到位于日志归档账户中的集中式数据湖。通过聚合集中式数据湖中的日志,您可以全面了解 AWS WAF 资源和分配的所有流量。这有助于安全团队集中分析和应对全球安全威胁模式。

设计注意事项
  • 这种模式将网络和安全管理的责任转移给了账户所有者和开发人员,这可能会增加开发过程的开销。

  • 决策中可能存在不一致之处。您应建立有效的沟通、模板和培训,确保服务配置正确并遵循安全建议。

  • 人们依赖自动化,并且对基准安全控制措施和特定于应用程序的控制措施有明确的期望。

  • 使用 Firewall Manager 和 AWS Config 等服务,确保部署的架构符合安全最佳实践。此外,配置 AWS CloudTrail 监控以检测任何错误配置。

  • 将日志和指标聚合到一个集中位置进行分析,可能会增加复杂性。

用于周边安全配置的其他 AWS 服务

动态来源:应用程序负载均衡器

您可以将 Amazon 配置 CloudFront 为使用 App lication Load Balancer 源进行动态内容传输。此设置允许您根据请求路径、主机名或查询字符串参数等各种因素,将请求路由到不同的应用程序负载均衡器来源。

应用程序负载均衡器来源部署在应用程序账户中。如果您的 CloudFront 分配位于网络账户中,则必须为 CloudFront 分配设置跨账户权限才能访问 Application Load Balancer 来源。来自应用程序负载均衡器的日志将发送到日志归档账户。

为了帮助防止用户在不经过的情况下直接访问 Application Load Balancer CloudFront,请完成以下高级步骤:

  • 配置 CloudFront 为向应用程序负载均衡器发送的请求添加自定义 HTTP 标头,并将应用程序负载均衡器配置为仅转发包含自定义 HTTP 标头的请求。

  • 使用 AWS 管理的前缀列表来 CloudFront 自 Application Load Balancer 安全组。这限制了从属于面向源服务器的 IP 地址到您的 Application Load Balancer 的入站 HTTP/HTTPS 流量。 CloudFront

有关更多信息,请参阅 CloudFront文档中的限制对应用程序负载均衡器的访问权限

静态起源:亚马逊 S3 和 AWS Elemental MediaStore

您可以配置 CloudFront 为使用 Amazon S3 或 AWS Elemental MediaStore 源进行静态内容分发。这些来源部署在应用程序账户中。如果您的 CloudFront 分配位于网络账户中,则必须为网络账户中的 CloudFront 分配设置跨账户权限才能访问来源。

要验证您的静态源端点是否只能通过公共互联网访问 CloudFront ,而不是直接通过公共互联网访问,您可以使用源站访问控制 (OAC) 配置。有关限制访问的更多信息,请参阅 CloudFront文档中的限制访问 Amazon S3 MediaStore 源和限制访问源。

AWS Firewall Manager

AWS Firewall Manager 简化了多个账户和资源的管理和维护任务,包括 AWS WAF、AWS Shield Advanced、Amazon VPC 安全组、AWS Network Firewall 和 Amazon Route 53 Resolver DNS Firewall,以提供各种保护。

将安全工具账户委托为 Firewall Manager 的默认管理员账户,并使用它来集中管理组织账户中的 AWS WAF 规则和 Shield Advanced 保护。使用 Firewall Manager 集中管理常见的 AWS WAF 规则,同时让每个应用程序团队可以灵活地将特定于应用程序的规则添加到 Web ACL 中。这有助于在组织范围内强制执行安全策略,例如针对常见漏洞的防护,同时允许应用程序团队添加特定于其应用程序的 AWS WAF 规则。

使用 Firewall Manager 日志记录,将 AWS WAF 日志集中到安全工具账户的 S3 存储桶中,然后将日志复制到日志归档账户,这样您就可以将其归档以进行安全调查。此外,将 Firewall Manager 与 AWS Security Hub 集成,以便在 Security Hub 中集中可视化配置详细信息和 DDoS 通知。

有关其他建议,请参阅本指南安全工具账户部分中的 AWS Firewall Manager

AWS Security Hub

Firewall Manager 与 Security Hub 之间的集成会向 Security Hub 发送四种类型的调查发现:

  • 未得到 AWS WAF 规则适当保护的资源

  • 未得到 AWS Shield Advanced 适当保护的资源

  • Shield Advanced 调查发现,表明 DDoS 攻击正在进行中

  • 使用不当的安全组

来自所有组织成员账户的这些调查发现会聚合到 Security Hub 委托管理员(安全工具)账户中。安全工具账户可以在一个地方聚合、整理和优先处理您的安全提醒或调查发现。使用 Amazon Ev CloudWatch ents 规则将调查结果发送到票务系统或创建自动补救措施,例如屏蔽恶意 IP 范围。

有关其他建议,请参阅本指南安全工具账户部分中的 AWS Security Hub

亚马逊 GuardDuty

您可以使用 Amazon 提供的威胁情报 GuardDuty 根据 GuardDuty 发现自动更新 Web ACL。例如,如果 GuardDuty 检测到可疑活动,则可以使用自动化来更新 AWS WAF IP 集中的条目,并将 AWS WAF Web ACL 应用于受影响的资源,以便在您执行其他调查和补救措施时阻止来自可疑主机的通信。安全工具帐户是的委托管理员帐户 GuardDuty。因此,您应该使用具有跨账户权限的 AWS Lambda 函数来更新应用程序账户中的 AWS WAF IP 集。

有关其他建议,请参阅本指南安全工具账户部分 GuardDuty中的 Amazon

AWS Config

AWS Config 是 Firewall Manager 的先决条件,部署在 AWS 账户中,包括网络账户和应用程序账户。此外,使用 AWS Config 规则来验证部署的资源是否符合安全最佳实践。例如,您可以使用 AWS Config 规则来检查每个 CloudFront 分配是否都与 Web ACL 关联,或者强制将所有 CloudFront 分配配置为将访问日志传送到 S3 存储桶。

有关一般建议,请参阅本指南安全工具账户部分中的 AWS Config