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

# 减少攻击面
<a name="attack-surface-reduction"></a>

 在设计 AWS 解决方案时，另一个重要的考虑因素是限制攻击者瞄准您的应用程序的机会。这个概念被称为*减少攻击面*。未暴露在互联网上的资源更难受到攻击，这限制了攻击者瞄准应用程序可用性的选项。

 例如，如果您不希望用户直接与某些资源进行交互，请确保无法从 Internet 访问这些资源。同样，不要通过非通信所需的端口或协议接受来自用户或外部应用程序的流量。

 在下一节中， AWS 提供了最佳实践，以指导您减少攻击面并限制应用程序的互联网暴露。

# 混淆 AWS 资源 (、、) BP1 BP4 BP5
<a name="obfuscating-aws-resources-bp1-bp4-bp5"></a>

 通常，用户可以快速轻松地使用应用程序，而无需将 AWS 资源完全暴露在互联网上。

# 安全组和网络 ACLs (BP5)
<a name="security-groups-and-network-acls-bp5"></a>

 Amazon Virtual Private Cloud (AmazonVPC) 允许您配置逻辑上隔离的部分，您可以在 AWS 云 其中启动您定义的虚拟网络中的 AWS 资源。

 安全组和网络的ACLs相似之处在于，它们允许您控制对内部 AWS 资源的访问权限VPC。但是安全组允许您在实例级别控制入站和出站流量，而网络在VPC子网级别ACLs提供类似的功能。使用安全组或网络不收取额外费用ACLs。

 您可以选择是在启动实例时指定安全组，还是稍后将该实例与安全组关联。除非您创建*允许规则来允许*流量，否则所有流向安全组的 Internet 流量都将被隐式拒绝。

 例如，如果您在 Elastic Load Balancer 后面有 Amazon EC2 实例，则这些实例本身不必是可公开访问的，而应IPs仅具有私有性。相反，您可以使用允许访问 0.0.0.0/0（以避免连接跟踪问题——见下文）的安全组规则，以及目标组子网上的网络访问控制列表 (NACL)，为所需的目标侦听器端口提供 Elastic Load Balancance 访问权限，仅允许 Elastic Load Balancing IP 范围与实例通信。这可确保互联网流量无法直接与您的 Amazon EC2 实例通信，从而使攻击者更难了解和影响您的应用程序。

 创建网络时ACLs，可以指定允许和拒绝规则。如果您想明确拒绝某些类型的流量流向您的应用程序，则此功能非常有用。例如，您可以定义拒绝访问整个子网的 IP 地址（作为CIDR范围）、协议和目标端口。如果您的应用程序仅用于TCP流量，则可以创建一条规则来拒绝所有UDP流量，反之亦然。此选项在响应DDoS攻击时非常有用，因为它允许您在知道来源IPs或其他特征码时创建自己的规则来缓解攻击。

 如果您已订阅 AWS Shield Advanced，则可以将弹性 IP 地址注册为受保护资源。DDoS可以更快地检测到针对已注册为受保护资源的弹性 IP 地址的攻击，从而缩短缓解攻击的时间。检测到攻击时，DDoS缓解系统会读取与目标弹性 IP 地址相对应的网络ACL，并在 AWS 网络边界而不是子网级别强制执行攻击。这可以显著降低您受到多种基础设施层DDoS攻击影响的风险。

 有关配置安全组和网络ACLs以优化DDoS弹性的更多信息，请参阅[如何通过减少攻击面来帮助做好DDoS攻击准备](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/)。

 有关使用带有弹性 IP 地址的 Shield Advanced 作为受保护资源的更多信息，请参阅[订阅](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html)步骤 AWS Shield Advanced。

# 保护你的起源 (BP1,BP5)
<a name="protecting-your-origin-bp1-bp5"></a>

 如果您使用亚马逊 CloudFront 的来源位于您的内部VPC，则可能需要确保只有您的 CloudFront 配送才能将请求转发到您的来源。借助 Edge-to-Origin 请求标头，在将请求 CloudFront 转发到您的源时，您可以添加或覆盖现有请求标头的值。您可以使用 *Origin Custom Headers*（例如`X-Shared-Secret`标头）来帮助验证向您的源发出的请求是否来自发送 CloudFront。

 有关使用 Origin *自定义标头保护您的源的更多信息，请参阅向源*[请求[添加](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html)自定义标头](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html)和[限制对应用程序负载均衡器的访问](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html)。

 有关实施示例解决方案以自动轮换*源访问限制的 Origin 自定义标头*值的指南，请参阅[如何使用 AWS WAF 和 Secrets Manager 增强亚马逊 CloudFront 源安全性](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/)。

 或者，您可以使用[AWS Lambda](https://aws.amazon.com/lambda/)功能自动更新您的安全组规则，使其仅允许 CloudFront 流量。这有助于确保恶意用户无法绕过 CloudFront 和 AWS WAF 访问您的 Web 应用程序，从而提高源站的安全性。

 有关如何通过自动更新您的安全组以及`X-Shared-Secret`标题来保护您的来源的更多信息，请参阅[如何自动更新您的亚马逊安全组 CloudFront 和 AWS WAF 使用 AWS Lambda](https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/)。

 但是，该解决方案涉及额外的配置和运行 Lambda 函数的成本。为了简化这一点，我们现在引入了[AWS托管前缀列表，用于 CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list)限制仅从 CloudFront面向源的 IP HTTPS 地址发送到您的来源的入站 HTTP /流量。 AWS-managed 前缀列表由创建 AWS 和维护，无需支付额外费用即可使用。您可以在您的 (AmazonVPC) 安全组规则、子网路由表、常用安全组规则以及任何其他可以使用托管前缀列表的 AWS 资源中引用[托管前缀列表](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html)。 CloudFront AWS Firewall Manager

 有关使用亚马逊 AWS托管前缀列表的更多信息 CloudFront，请参阅[使用亚马逊托 AWS管前缀列表限制对您的来源的访问权限](https://aws.amazon.com/blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/)。 CloudFront

**注意**  
 如本文档其他部分所述，在请求泛滥期间，依靠安全组来保护您的来源可能会将[安全组连接跟踪](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)作为潜在的瓶颈。除非您能够 CloudFront 使用启用缓存的缓存策略来过滤恶意请求，否则最好依靠前面讨论的 O *rigin Custom Headers* 来帮助验证向您的源发出的请求是否来自安全组 CloudFront，而不是使用安全组。将自定义请求标头与 Application Load Balancer 侦听器规则一起使用可防止由于跟踪限制而导致的限制，这可能会影响与负载均衡器建立新连接，从而允许应用程序负载均衡器在发生攻击时根据流量的增加进行扩展。DDoS

# 保护API端点 (BP4)
<a name="protecting-api-endpoints-bp4"></a>

当你必须API向公众公开时，API前端就有可能成为DDoS攻击的目标。为了帮助降低风险，您可以使用 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 作为在亚马逊EC2或其他地方运行的应用程序的入口。 AWS Lambda通过使用 Amazon API Gateway，您无需在API前端使用自己的服务器，并且可以混淆应用程序的其他组件。通过使检测应用程序组件变得更加困难，可以帮助防止这些 AWS 资源成为DDoS攻击的目标。

 使用 Amazon API Gateway 时，您可以从两种类型的API终端节点中进行选择。第一个是默认选项：通过 Ama CloudFront zon 分配访问的边缘优化的API终端节点。但是，该发行版由 API Gateway 创建和管理，因此您无法对其进行控制。第二种选择是使用区域API终端节点，该终端节点可以从部署您的RESTAPI终端节点进行访问。 AWS 区域 AWS 建议您使用第二种终端节点并将其与您自己的 Amazon CloudFront 分销相关联。这使您可以控制 Amazon CloudFront 分发并能够 AWS WAF 用于应用程序层保护。此模式使您可以访问 AWS 全球边缘网络中扩展的DDoS缓解能力。

 使用 Amazon CloudFront 和 AWS WAF Amazon API Gateway 时，请配置以下选项：
+  为您的分配配置缓存行为，以将所有标头转发到 Gate API way 区域终端节点。通过这样做， CloudFront 会将内容视为动态内容并跳过缓存内容。
+  通过在 API Gateway 中设置[API密钥](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html)值，将分配配置为包含 Origin 自定义标头 x-api-key，保护您的API网关免受直接访问。
+  通过为每种方法配置标准或突发速率限制，保护后端免受过多流量的侵害RESTAPIs。

 有关使用 Amazon API Gateway APIs 进行创建的更多信息，请参阅 [Amazon API Gateway](https://aws.amazon.com/api-gateway/getting-started/) [入门](https://aws.amazon.com/api-gateway/getting-started/)。