# 基础设施保护
**Topics**
+ [SEC 5. 您如何保护您的网络资源？](sec-05.md)
+ [SEC 6. 您如何保护自己的计算资源？](sec-06.md)
# SEC 5. 您如何保护您的网络资源？
任何以某种形式连接至网络（互联网或专用网络）的工作负载都需要多层防御，以帮助防御基于外部和内部网络的威胁。
**Topics**
+ [SEC05-BP01 创建网络层](sec_network_protection_create_layers.md)
+ [SEC05-BP02 控制网络层中的流量流动](sec_network_protection_layered.md)
+ [SEC05-BP03 实施基于检查的保护](sec_network_protection_inspection.md)
+ [SEC05-BP04 自动执行网络保护](sec_network_auto_protect.md)
# SEC05-BP01 创建网络层
根据工作负载组件的逻辑分组，按照数据敏感性和访问权限要求，将网络拓扑划分成不同的层。区分需要接受来自互联网的入站访问的组件（例如公有 Web 端点）与只需要进行内部访问的组件（例如数据库）。
**期望结果：**网络中的各个层是完整的深度防御安全方法的一部分，是工作负载身份验证和授权策略的有力补充。根据数据敏感性和访问权限要求进行了分层，并采用合适的流量流动和控制机制。
**常见反模式：**
+ 您在单个 VPC 或子网中创建所有资源。
+ 在构造网络层时，您没有考虑数据敏感性要求、组件行为或功能。
+ 您使用 VPC 和子网的默认值，未考虑所有的网络层注意事项，而且也未考虑 AWS 托管服务对拓扑有何影响。
**建立此最佳实践的好处：**建立网络层是限制网络中不必要路径的第一步，尤其是在需要限制去往关键系统和数据的路径的情况下。通过这种方法，未经授权的操作者更难于访问您的网络，也更难导航到网络中的其它资源。彼此分隔的网络层带来的益处包括减少了检查系统的分析范围，例如进行入侵检测或恶意软件防御时。这可以减少误报的可能性和不必要的处理开销。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
在设计工作负载架构时，一种常见的做法是根据组件的职责将组件分隔到不同的层中。例如，Web 应用程序可以具有表示层、应用层和数据层。在设计网络拓扑时，您可以采用类似的方法。底层网络控制措施可用于强制执行工作负载的数据访问权限要求。例如，在三层 Web 应用程序架构中，您可以将静态的表示层文件存储在 [Amazon S3](https://aws.amazon.com/s3/) 中，并通过 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 等内容分发网络（CDN）来提供这些文件。应用层可以有公有端点，该端点由[应用程序负载均衡器（ALB）](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/)在 [Amazon VPC](https://aws.amazon.com/vpc/) 公有子网（类似于非军事区，简称 DMZ）中提供服务，并将后端服务部署到私有子网中。数据层中托管数据库和共享文件系统等资源，可以与应用层的资源位于不同的私有子网中。在每个这些层的边界（CDN、公有子网、私有子网），您都可以部署控制措施，仅允许授权流量穿过这些边界。
类似于根据工作负载组件的功能用途对网络层进行建模，此时同样需要考虑所处理数据的敏感性。以 Web 应用程序为例，虽然您的所有工作负载服务可能都位于应用层内，但不同的服务会处理具有不同敏感性级别的数据。在这种情况下，根据您的控制要求，您可能需要针对不同的数据敏感性来划分应用层，例如使用多个私有子网、同一个 AWS 账户 中的不同 VPC，甚至是不同 AWS 账户 中的不同 VPC。
网络层的另一个注意事项是工作负载组件的行为一致性。仍旧以上例来说明，在应用层中，您的服务可能接受来自最终用户或外部系统集成的输入，这些输入本质上比其它服务的输入风险更大。例如文件上传、要运行的代码脚本、电子邮件扫描等。将这些服务放在各自的网络层中，可以在这些服务周围建立更可靠的隔离边界，并可以防止它们的独特行为在检查系统中产生误报提醒。
在设计过程中，请考虑使用 AWS 托管服务会对您的网络拓扑造成什么影响。探索 [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) 等服务如何有助于简化跨网络层的工作负载组件互操作性。使用 [AWS Lambda](https://aws.amazon.com/lambda/) 时，除非有特殊的原因，否则应将该服务部署在您的 VPC 子网中。对于限制访问互联网网关的安全策略，确定如何利用 VPC 端点和 [AWS PrivateLink](https://aws.amazon.com/privatelink/) 来简化遵守这些策略所需的工作。
### 实施步骤
1. 查看您的工作负载架构。根据组件和服务提供的功能、所处理数据的敏感性及其行为，对组件和服务进行逻辑分组。
1. 如果组件需要响应来自互联网的请求，请考虑使用负载均衡器或其它代理来提供公有端点。探索通过使用 CloudFront、[Amazon API Gateway](https://aws.amazon.com/api-gateway/)、弹性负载均衡和 [AWS Amplify](https://aws.amazon.com/amplify/) 等托管服务来托管公有端点，从而转变安全控制模式。
1. 对于在计算环境中运行的组件，例如 Amazon EC2 实例、[AWS Fargate](https://aws.amazon.com/fargate/) 容器或 Lambda 函数，请根据您在第一步中的分组，将它们部署到私有子网中。
1. 对于完全托管式 AWS 服务，例如 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Kinesis](https://aws.amazon.com/kinesis/) 或 [Amazon SQS](https://aws.amazon.com/sqs/)，请考虑默认使用 VPC 端点来通过私有 IP 地址进行访问。
## 资源
**相关最佳实践：**
+ [REL02 计划网络拓扑](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)
+ [PERF04-BP01 了解联网对性能的影响](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_networking_understand_how_networking_impacts_performance.html)
**相关视频：**
+ [AWS re:Invent 2023 – AWS networking foundations](https://www.youtube.com/watch?v=8nNurTFy-h4)
**相关示例：**
+ [VPC 示例](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-examples-intro.html)
+ [使用 AWS Fargate、AWS PrivateLink，和网络负载均衡器在 Amazon ECS 上私密访问容器应用程序](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)
+ [使用 Amazon CloudFront 通过 VPC 在 Amazon S3 存储桶中提供静态内容](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html)
# SEC05-BP02 控制网络层中的流量流动
在网络的各层中，进一步对网络进行分段，从而将流量限制在对各个工作负载所必要的流动路径中。首先，将重点放在控制互联网或其它外部系统与工作负载和您环境之间的流量（*南北向*流量）上。然后，审查不同组件与系统之间的流量（*东西向*流量）。
**期望结果：**您只允许必要的网络流量流动，以便让工作负载的组件彼此通信，以及与其客户端和所依赖的任何其它服务进行通信。您在设计时充分考虑了各种因素，例如公有入口和出口与私有入口和出口的对比、数据分类、区域法规，以及协议要求。作为*最低权限原则*设计的一部分，您尽可能地使用点对点流动，而不是网络对等连接。
**常见反模式：**
+ 您采用基于边界的方法来保护网络，并且仅在网络层的边界控制流量流动。
+ 您假设一个网络层中的所有流量都经过了身份验证和授权。
+ 您对入口流量或出口流量进行了控制，但没有对两者均进行控制。
+ 您完全依靠工作负载组件和网络控制措施来对流量进行身份验证和授权。
**建立此最佳实践的好处：**这种做法有助于减少网络中未经授权移动的风险，并为您的工作负载增加了额外的授权层。通过执行流量流动控制，您可以限制安全事件的影响范围，同时加快检测和响应的速度。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
虽然通过网络层，您可以围绕工作负载中具有相似功能、数据敏感性级别和行为的组件来划定边界，不过您可以利用各种技术，在这些层中遵循最低权限原则来进一步划分组件，从而创建更精细的流量控制级别。在 AWS 中，网络层主要根据 Amazon VPC 中的 IP 地址范围使用子网进行定义。您也可以使用不同的 VPC 来定义层，例如按业务域来对微服务环境进行分组。使用多个 VPC 时，使用 [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) 来仲裁路由。虽然这种方法使用安全组和路由表在第 4 层上（IP 地址和端口范围）提供流量控制，不过您可以使用其它服务（例如 [AWS PrivateLink](https://aws.amazon.com/privatelink/)、[Amazon Route 53 Resolver DNS 防火墙](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)、[AWS Network Firewall](https://aws.amazon.com/network-firewall/) 和 [AWS WAF](https://aws.amazon.com/waf/)）实现进一步的控制。
了解工作负载的数据流动和通信要求并列出清单，这涉及到连接发起方、端口、协议和网络层等。评估可用于建立连接和传输数据的协议，从而选择符合您的保护要求的协议（例如，HTTPS 而不是 HTTP）。在网络边界和每个层中收集这些要求。确定这些要求后，探索仅允许所需流量流经每个连接点的选项。作为开始，一种很好的方法是在 VPC 中使用*安全组*，因为安全组可以连接到使用弹性网络接口（ENI）的资源，例如 Amazon EC2 实例、Amazon ECS 任务、Amazon EKS 容器组（pod）或 Amazon RDS 数据库。与第 4 层防火墙不同，安全组可以设定一条规则，按照标识符来允许其它安全组的流量，这样当组中的资源随着时间发生变化时，能尽可能减少更新工作。您还可以使用安全组，通过入站和出站规则来筛选流量。
当流量在 VPC 之间移动时，对于简单路由通常会使用 VPC 对等连接，对于复杂路由则使用 AWS Transit Gateway。使用这些方法，您可以在源网络和目标网络的 IP 地址范围之间，协调流量流动。但是，如果您的工作负载只需要在不同 VPC 中的特定组件之间的流量流动，请考虑使用 [AWS PrivateLink](https://aws.amazon.com/privatelink/) 进行点对点连接。为此，请确定哪些服务应充当产生器，哪些服务应充当使用器。为产生器部署兼容的负载均衡器，相应地启用 PrivateLink，然后接受使用器的连接请求。接下来，向产生器服务分配来自使用器 VPC 的私有 IP 地址，使用器可以使用该地址发出后续请求。这种方法减少了对网络对等连接的需求。评估 PrivateLink 时，请包括数据处理和负载均衡的成本。
虽然安全组和 PrivateLink 均可用于控制工作负载的组件之间的流量流动，不过还有另一个重要考虑因素，即如何控制允许您的资源访问哪些 DNS 域（如果有）。根据 VPC 的 DHCP 配置，您可以考虑使用两种不同的 AWS 服务来实现此目的。大多数客户使用默认的 Route 53 Resolver DNS 服务（也称为 Amazon DNS 服务器或 AmazonProvidedDNS），该服务可用于 VPC，地址为其 CIDR 范围 \$12。通过这种方法，您可以创建 DNS 防火墙规则，然后将规则关联到 VPC，用来确定对您提供的域列表采取哪些操作。
如果您不使用 Route 53 Resolver，或者想在域筛选之外，利用更深入的检查和流量控制功能来补充 Resolver，请考虑部署 AWS Network Firewall。此服务使用无状态或有状态规则检查单独的数据包，以确定是拒绝还是允许流量。您可以使用类似的方法，通过 AWS WAF 来筛选流向公有端点的入站 Web 流量。有关这些服务的更多指导信息，请参阅《[SEC05-BP03 实施基于检查的保护](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html)》。
### 实施步骤
1. 确定在工作负载的组件之间必需的数据流。
1. 对于入站和出站流量，采用深度防御方法应用多种控制措施，包括使用安全组和路由表。
1. 针对出入 VPC 和 VPC 之间的网络流量，使用防火墙定义精细的控制措施，例如 Route 53 Resolver DNS 防火墙、AWS Network Firewall 和 AWS WAF。考虑使用 [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) 来集中配置和管理整个企业的防火墙规则。
## 资源
**相关最佳实践：**
+ [REL03-BP01 选择如何划分工作负载](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html)
+ [SEC09-BP02 在传输中执行加密](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_transit_encrypt.html)
**相关文档：**
+ [VPC 的安全最佳实践](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
+ [AWS Network Optimization Tips](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [Guidance for Network Security on AWS](https://aws.amazon.com/solutions/guidance/network-security-on-aws/)
+ [Secure your VPC's outbound network traffic in the AWS 云](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/welcome.html)
**相关工具：**
+ [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)
**相关视频：**
+ [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc)
+ [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0)
+ [AWS re:Inforce 2023: Firewalls and where to put them](https://www.youtube.com/watch?v=lTJxWAiQrHM)
# SEC05-BP03 实施基于检查的保护
在各网络层之间设置流量检测点，确保传输中数据符合预期的类别和模式。 分析流量、元数据和模式，以便于更有效地识别、检测和响应事件。
**期望结果：**在各网络层之间穿行的流量均经过检查和授权。 允许和拒绝的决定基于明确的规则、威胁情报和偏离基线的行为。 流量越接近敏感数据，保护措施就越严格。
**常见反模式：**
+ 仅依赖基于端口和协议的防火墙规则，而不利用智能系统。
+ 根据当前可能发生变化的特定威胁模式制定防火墙规则。
+ 只检查从私有子网传输到公有子网或从公有子网传输到互联网的流量。
+ 没有网络流量基线视图，无法与异常行为对照。
**建立此最佳实践的好处：**检测系统允许您制定智能规则，例如仅当流量数据中存在特定条件时才允许或拒绝流量。根据最新的威胁情报，从 AWS 和合作伙伴提供的托管规则集获益，因为威胁状况会随着时间的推移而发生变化。 这减少了维护规则和研究折衷指标的开销，降低了误报的可能性。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
使用 AWS Network Firewall 或 AWS Marketplace 上其它可部署在[网关负载均衡器（GWLB）](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/)后面的[防火墙](https://aws.amazon.com/marketplace/search/results?searchTerms=firewalls)和[入侵防御系统](https://aws.amazon.com/marketplace/search/results?searchTerms=Intrusion+Prevention+Systems)（IPS，Intrusion Prevention Systems），对有状态和无状态网络流量进行细粒度控制。AWS Network Firewall 支持[与 Suricata 兼容](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html)的开源 IPS 规范，有助于保护您的工作负载。
AWS Network Firewall 和使用 GWLB 的供应商解决方案都支持不同的内联检查部署模型。 例如，您可以逐个 VPC 执行检查，在所检查 VPC 内集中进行检查，或者以混合模式进行部署，即东西向流量流经检查 VPC，而互联网入口则逐个 VPC 进行检查。 另一个考虑因素是，解决方案是否支持解包传输层安全性协议（TLS），从而能够对任一方向启动的流量进行深度数据包检查。有关这些配置的更多信息和深入细节，请参阅《[AWS Network Firewall 最佳实践指南](https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/)》。
如果您使用的是执行带外检查的解决方案，例如对来自以混杂模式运行的网络接口的数据包数据进行 pcap 分析，则可以配置 [VPC 流量镜像](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)。镜像流量计入接口的可用带宽，与非镜像流量收取相同的数据传输费用。您可以查看 [AWS Marketplace](https://aws.amazon.com/marketplace/solutions/infrastructure-software/cloud-networking) 上是否有这些设备的虚拟版本，它们可能支持在 GWLB 后面进行内联部署。
对于通过基于 HTTP 的协议进行事务处理的组件，应使用 Web 应用程序防火墙（WAF，Web Application Firewall）保护应用程序免受常见威胁。[AWS WAF](https://aws.amazon.com/waf) 是一种 Web 应用程序防火墙，可让您在将符合可配置规则的 HTTP(S) 请求发送到 Amazon API Gateway、Amazon CloudFront、AWS AppSync 或应用程序负载均衡器之前，监控并阻止这些请求。在评估 Web 应用程序防火墙的部署时，可以考虑深度数据包检查，因为有些防火墙要求在流量检查前终止 TLS。要开始使用 AWS WAF，您可以将 [AWS 托管式规则](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group) 与自己的规则结合使用，也可以使用现有的[合作伙伴集成](https://aws.amazon.com/waf/partners/)。
您可以使用 [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)，在整个 AWS 组织内集中管理 AWS WAF、AWS Shield Advanced、AWS Network Firewall 和 Amazon VPC 安全组。
## 实施步骤
1. 确定是可以通过检查 VPC 等方式宽泛地确定检查规则的范围，还是需要更细粒度的针对每个 VPC 的方法。
1. 对于内联检查解决方案：
1. 如果使用 AWS Network Firewall，则创建规则、防火墙策略和防火墙本身。配置完这些后，就可以[将流量路由到防火墙端点](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)以便启用检查。
1. 如果使用带有网关负载均衡器（GWLB）的第三方设备，请在一个或多个可用区内部署和配置设备。然后，创建 GWLB、端点服务、端点，并为流量配置路由。
1. 对于带外检查解决方案：
1. 在应该对入站和出站流量进行镜像的接口上，启用 VPC 流量镜像功能。您可以使用 Amazon EventBridge 规则调用 AWS Lambda 函数，以便在创建新资源时在接口上启用流量镜像功能。将流量镜像会话指向在设备前面处理流量的网络负载均衡器。
1. 对于入站 Web 流量解决方案：
1. 要配置 AWS WAF，首先要配置 Web 访问控制列表（Web ACL）。Web ACL 是众多规则的集合，具有连续处理的默认操作（ALLOW 或 DENY），可定义 WAF 如何处理流量。您可以创建自己的规则和组，也可以在 Web ACL 中使用 AWS 托管规则组。
1. 配置好 Web ACL 后，将 Web ACL 与 AWS 资源（如应用程序负载均衡器、API Gateway REST API 或 CloudFront 分配）关联，即可开始保护 Web 流量。
## 资源
**相关文档：**
+ [What is Traffic Mirroring?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)
+ [Implementing inline traffic inspection using third-party security appliances](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html)
+ [AWS Network Firewall example architectures with routing](https://docs.aws.amazon.com/network-firewall/latest/developerguide/architectures.html)
+ [Centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)
**相关示例：**
+ [部署网关负载均衡器的最佳实践](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)
+ [TLS inspection configuration for encrypted egress traffic and AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-egress-traffic-and-aws-network-firewall/)
**相关工具：**
+ [AWS Marketplace IDS/IPS](https://aws.amazon.com/marketplace/search/results?prevFilters=%257B%2522id%2522%3A%25220ed48363-5064-4d47-b41b-a53f7c937314%2522%257D&searchTerms=ids%2Fips)
# SEC05-BP04 自动执行网络保护
使用 DevOps 实践 [例如*基础设施即代码*（IaC）和 CI/CD 管道] 自动部署网络保护。 这些实践有助于您通过版本控制系统跟踪网络保护措施的变更，缩短部署变更所需的时间，并有助于检测网络保护措施是否偏离了您所需的配置。
**期望结果：**您可以使用模板来定义网络保护，并将模板提交到版本控制系统中。 当有新的变更时，自动管道就会启动，协调这些变更的测试和部署。 进行策略检查和其它静态测试，以便在部署之前验证变更。 您可以将变更部署到暂存环境中，以便验证控制措施是否按预期运行。 一旦控制措施获得批准，还可自动部署到生产环境中。
**常见反模式：**
+ 依靠各个工作负载团队各自定义完整的网络堆栈、保护措施和自动化。 不集中发布网络堆栈和保护措施的标准内容，供工作负载团队使用。
+ 依靠中央网络团队来定义网络、保护措施和自动化的所有方面。 不将网络堆栈和保护措施的特定工作负载方面委托给该工作负载的团队。
+ 在网络团队和工作负载团队之间的集中化和委托之间取得适当平衡，但不在 IaC 模板和 CI/CD 管道中应用一致的测试和部署标准。 没有在检查模板是否符合要求的工具中捕获所需的配置。
**建立此最佳实践的好处：**使用模板来定义网络保护，可以通过版本控制系统跟踪和比较随时间发生的变更。 使用自动化功能来测试和部署变更，可实现标准化和可预测性，增加成功部署的机会，减少重复的手动配置。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
[SEC05-BP02 控制网络层中的流量流动](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_layered.html)和 [SEC05-BP03 实施基于检查的保护](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html)中描述的许多网络保护控制措施都带有可根据最新威胁情报自动更新的托管规则系统。 保护 Web 端点的示例包括 [AWS WAF 托管规则](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html)和 [AWS Shield Advanced 自动应用层 DDoS 缓解](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html)。使用 [AWS Network Firewall 托管规则组](https://docs.aws.amazon.com/network-firewall/latest/developerguide/nwfw-managed-rule-groups.html)，也可随时更新低声誉域列表和威胁特征。
除了托管规则外，我们还建议您使用 DevOps 实践来自动部署网络资源、保护措施和您指定的规则。 您可以在 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 或您选择的其它*基础设施即代码*（IaC）工具中捕获这些定义，将其提交到版本控制系统，并使用 CI/CD 管道进行部署。 使用这种方法可获得 DevOps 在管理网络控制方面的传统优势，如更具可预测性的发布、使用 [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) 等工具进行自动测试，以及检测已部署环境与所需配置之间的偏差等。
根据您在 [SEC05-BP01 创建网络层](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_create_layers.html)中做出的决定，您可以采用集中管理方法创建 VPC，专用于入口、出口和检查流。 如 [AWS Security Reference Architecture（AWS SRA）](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture)所述，您可以在专用[网络基础设施账户](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)中定义这些 VPC。 您可以使用类似的技术，来集中定义其它账户中工作负载使用的 VPC、其安全组、AWS Network Firewall 部署、Route 53 Resolver 规则和 DNS Firewall 配置以及其它网络资源。 您可以通过 [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) 与其它账户共享这些资源。 通过这种方法，您可以将网络控制的自动测试和部署简化到网络账户中，只需管理一个目标即可。 您可以采用混合模式来实现这一点，即集中部署和共享某些控制措施，并将其它控制措施委托给各个工作负载团队及其各自的账户。
## 实施步骤
1. 确定网络和保护措施的哪些方面是集中定义的，哪些是工作负载团队可以维护的。
1. 创建环境来测试和部署对网络及其保护措施的变更。 例如，使用“网络测试”账户和“网络生产”账户。
1. 确定如何在版本控制系统中存储和维护模板。 将中央模板存储在有别于工作负载存储库的存储库中，而工作负载模板可存储在特定于该工作负载的存储库中。
1. 创建 CI/CD 管道来测试和部署模板。 定义测试方法，用于检查配置是否有误，以及模板是否符合公司标准。
## 资源
**相关最佳实践：**
+ [SEC01-BP06 自动部署标准安全控制措施](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls)
**相关文档：**
+ [AWS Security Reference Architecture - Network account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)
**相关示例：**
+ [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/)
+ [NetDevSecOps to modernize AWS networking deployments](https://aws.amazon.com/blogs/networking-and-content-delivery/netdevsecops-to-modernize-aws-networking-deployments/)
+ [Integrating AWS CloudFormation security tests with AWS Security Hub CSPM and AWS CodeBuild reports](https://aws.amazon.com/blogs/security/integrating-aws-cloudformation-security-tests-with-aws-security-hub-and-aws-codebuild-reports/)
**相关工具：**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [cfn\$1nag](https://github.com/stelligent/cfn_nag)
# SEC 6. 您如何保护自己的计算资源？
工作负载中的计算资源需要多层防御，以帮助抵御外部和内部威胁。计算资源包括 EC2 实例、容器、AWS Lambda 函数、数据库服务、IoT 设备等。
**Topics**
+ [SEC06-BP01 执行漏洞管理](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 从强化映像预置计算](sec_protect_compute_hardened_images.md)
+ [SEC06-BP03 减少人工管理工作和交互式访问](sec_protect_compute_reduce_manual_management.md)
+ [SEC06-BP04 验证软件完整性](sec_protect_compute_validate_software_integrity.md)
+ [SEC06-BP05 自动保护计算](sec_protect_compute_auto_protection.md)
# SEC06-BP01 执行漏洞管理
频繁扫描和修补您的代码、依赖项和基础设施中的漏洞，以帮助防御新的威胁。
**期望结果：**您的解决方案可以持续扫描工作负载，来发现软件漏洞、潜在缺陷和意外的网络泄露。您已经制定了流程和过程，可以根据风险评测标准来识别这些漏洞、确定其优先级并对其进行修复。此外，您还为计算实例实施了自动补丁管理。您的漏洞管理程序已集成到软件开发生命周期中，并提供了在 CI/CD 管道期间扫描源代码的解决方案。
**常见反模式：**
+ 未制定漏洞管理计划。
+ 在不考虑严重性或风险规避的情况下执行系统修补。
+ 使用已超过供应商提供的生命周期结束（EOL）日期的软件。
+ 在分析安全问题之前，将代码部署到生产环境中。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
漏洞管理是维护安全且稳健的云环境的一个关键环节。它涉及一个全面的流程，包括安全扫描、问题的识别和优先级排序，以及用于修复已识别漏洞的修补操作。自动化在此流程中起着举足轻重的作用，因为它有助于对工作负载进行持续扫描来发现潜在问题和意外的网络泄露，以及实施修复工作。
[AWS 责任共担模式](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html)是支撑漏洞管理的基本概念。根据该模式，AWS 负责保护底层基础设施的安全，包括运行 AWS 服务的硬件、软件、网络和设施。相反，您负责保护与 Amazon EC2 实例和 Amazon S3 对象等服务关联的数据、安全配置和管理任务。
AWS 提供一系列服务来支持漏洞管理计划。[Amazon Inspector](https://aws.amazon.com/inspector/) 持续扫描 AWS 工作负载中是否存在软件漏洞和意外网络访问，而 [AWS Systems Manager 补丁管理器](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html)则有助于管理跨 Amazon EC2 实例的修补工作。这些服务可以与 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 这一云安全态势管理服务集成，该服务可自动执行 AWS 安全检查，集中安全警报，并提供组织安全态势的全面视图。此外，[Amazon CodeGuru 安全防御工具](https://aws.amazon.com/codeguru/)使用静态代码分析，来识别 Java 和 Python 应用程序在开发阶段期间的潜在问题。
通过将漏洞管理实践纳入软件开发生命周期，您可以在漏洞引入生产环境之前主动解决漏洞，从而降低安全事件的风险，并最大限度地减少漏洞的潜在影响。
### 实施步骤
1. **了解责任共担模式：**查看 AWS 责任共担模式，来了解您在云端保护工作负载和数据的责任。AWS 负责保护底层云基础设施，而您负责保护您的应用程序、数据和所使用的服务。
1. **实施漏洞扫描**：配置漏洞扫描服务（例如 Amazon Inspector），以便自动扫描计算实例（例如虚拟机、容器或无服务器函数），来查找软件漏洞、潜在缺陷和意外的网络泄露。
1. **建立漏洞管理流程：**定义用于识别漏洞、确定漏洞优先级和修复漏洞的流程和过程。这可能包括制定定期漏洞扫描计划、建立风险评估标准以及根据漏洞严重程度定义修补时间表。
1. **设置补丁管理：**使用补丁管理服务，来自动执行为操作系统和应用程序修补计算实例的过程。您可以将服务配置为扫描实例中缺少的补丁，并按计划自动安装这些补丁。可以考虑使用 AWS Systems Manager 补丁管理器来提供此功能。
1. **配置恶意软件防护：**实施相应的机制来检测环境中的恶意软件。例如，可以使用诸如 [Amazon GuardDuty](https://aws.amazon.com/guardduty/) 之类的工具来分析、检测 EC2 和 EBS 卷中的恶意软件并发出警报。GuardDuty 还可以扫描新上传到 Amazon S3 的对象中是否存在潜在的恶意软件或病毒，并在它们被摄取到下游进程之前采取措施将其隔离。
1. **在 CI/CD 管道中集成漏洞扫描：**如果您使用 CI/CD 管道进行应用程序部署，请将漏洞扫描工具集成到您的管道中。诸如 Amazon CodeGuru 安全防御工具和开源选项之类的工具可以扫描源代码、依赖项和构件，来发现潜在的安全问题。
1. **配置安全监控服务：**设置安全监控服务（例如 AWS Security Hub CSPM），来全面了解您在多个云服务中的安全状况。该服务应从各种来源收集安全调查发现，并以标准化格式呈现它们，以便于确定优先级和进行补救。
1. **实施 Web 应用程序渗透测试**：如果您的应用程序是 Web 应用程序，并且您的组织具有必要的技能或可以聘请外部协助，请考虑实施 Web 应用程序渗透测试，以识别应用程序中的潜在漏洞。
1. **利用基础设施即代码实现自动化**：使用基础设施即代码（IaC）工具（例如 [AWS CloudFormation](https://aws.amazon.com/cloudformation/)）来自动部署和配置资源，包括前面提到的安全服务。这种做法有助于您在多个账户和环境中创建更加一致和标准化的资源架构。
1. **监控并持续改进**：持续监控漏洞管理计划的有效性，并根据需要进行改进。审核安全调查发现，评测补救工作的有效性，并相应地调整您的流程和工具。
## 资源
**相关文档：**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Lambda 安全性概述](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf)
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ 使用新的 Amazon Inspector 改进了云工作负载的自动化漏洞管理 ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ 使用 Amazon Inspector 和 AWS Systems Manager 自动执行 AWS 中的漏洞管理和修复 – 第 1 部分 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)
**相关视频：**
+ [保护无服务器和容器服务](https://youtu.be/kmSdyN9qiXY)
+ [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI)
# SEC06-BP02 从强化映像预置计算
通过从强化映像部署运行时环境，减少意外访问运行时环境的机会。只从可信注册表获取运行时依赖项（例如容器映像和应用程序库），并验证其签名。创建自己的专用注册表来存储可信映像和库，供构建和部署流程使用。
**期望结果：**您的计算资源是从强化的基准映像预置的。您只从可信注册表检索外部依赖项（例如容器映像和应用程序库），并验证其签名。这些依赖项存储在专用注册表中，供构建和部署流程参考。您会定期扫描和更新映像和依赖项，以便于应对任何新发现的漏洞。
**常见反模式：**
+ 从可信注册表获取映像和库，但在投入使用前不验证其签名或进行漏洞扫描。
+ 强化映像，但没有定期测试映像是否存在新漏洞或更新到最新版本。
+ 安装或不删除在映像预期生命周期内不需要的软件包。
+ 仅依靠打补丁来保持生产计算资源的最新状态。随着时间的推移，仅靠打补丁仍会导致计算资源偏离强化标准。打补丁也可能无法清除威胁行为者在安全事件中安装的恶意软件。
**建立此最佳实践的好处：**强化映像有助于减少在运行时环境中，可能允许未经授权的用户或服务进行意外访问的路径数量。如果发生任何意外访问，强化映像还可以缩小影响范围。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要强化系统，请从最新版本的操作系统、容器映像和应用程序库开始。应用补丁以解决已知问题。删除所有不需要的应用程序、服务、设备驱动程序、默认用户和其它凭证，尽量减小系统。采取其它任何必要操作，例如禁用端口，以便创建一个只拥有工作负载所需资源和功能的环境。在此基础上，您可以安装必要的软件、代理或其它进程，以满足监控工作负载或管理漏洞等目的的需要。
您可以遵循可信来源提供的指导，如[互联网安全中心](https://www.cisecurity.org/)（CIS，Center for Internet Security）以及美国国防信息系统局（DISA，Defense Information Systems Agency）的[安全技术实施指南（STIG）](https://public.cyber.mil/stigs/)，从而减轻强化系统的负担。我们建议您从 AWS 或 APN 合作伙伴发布的[亚马逊机器映像](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)（AMI）开始，并使用 AWS [EC2 Image Builder](https://aws.amazon.com/image-builder/)，以期综合使用 CIS 和 STIG 控制措施来自动配置。
虽然有可用的强化映像和 EC2 Image Builder 配方可应用 CIS 或 DISA STIG 建议，但您可能会发现，它们的配置会阻止您的软件成功运行。在这种情况下，您可以从未经强化的基础映像开始，安装软件，然后逐步应用 CIS 控制措施来测试其影响。对于任何阻止软件运行的 CIS 控制措施，请测试是否可以改为在 DISA 中实施更精细的强化建议。跟踪您能够成功应用的不同 CIS 控制措施和 DISA STIG 配置。在 EC2 Image Builder 中使用这些控制措施和配置，相应地定义映像强化配方。
对于容器化工作负载，[Amazon Elastic Container Registry（ECR）](https://aws.amazon.com/ecr/)[公共存储库](https://gallery.ecr.aws/docker)提供 Docker 的强化映像。您可以结合使用 EC2 Image Builder 与 AMI 来强化容器映像。
与操作系统和容器映像类似，您可以通过 pip、npm、Maven 和 NuGet 等工具，从公共存储库中获取代码包（或*库*）。我们建议您将私有存储库（例如在 [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) 中）与可信的公共存储库进行集成，来管理代码包。这种集成可为您处理代码包的检索、存储和保持最新状态。然后，您的应用程序构建流程就可以使用一些技术 [例如软件组成分析（SCA，Software Composition Analysis）、静态应用程序安全测试（SAST，Static Application Security Testing）和动态应用程序安全测试（DAST，Dynamic Application Security Testing）等]，与您的应用程序一起获取和测试这些代码包的最新版本。
对于使用 AWS Lambda 的无服务器工作负载，可使用 [Lambda 层](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)简化对代码包依赖项的管理。使用 Lambda 层将不同函数之间共享的一组标准依赖项配置到独立的存档中。您可以通过自己的构建流程来创建和维护层，从而能够以集中方式使您的函数保持最新状态。
## 实施步骤
+ 强化操作系统。使用来自可信来源的基础映像为基础，来构建强化的 AMI。使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/) 来帮助自定义安装在映像上的软件。
+ 强化容器化资源。配置容器化资源以符合安全最佳实践。当使用容器时，在您的构建管道中对您的映像存储库定期实施 [ECR 映像扫描](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html)，以便在您的容器中查找 CVE。
+ 在使用 AWS Lambda 实现无服务器时，请使用 [Lambda 层](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)来隔离应用程序函数代码和共享的依赖项库。为 Lambda 配置[代码签名](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html)，以便确保只有可信代码才能在您的 Lambda 函数中运行。
## 资源
**相关最佳实践：**
+ [OPS05-BP05 执行补丁管理](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_patch_mgmt.html)
**相关视频：**
+ [Deep dive into AWS Lambda security](https://www.youtube.com/watch?v=FTwsMYXWGB0)
**相关示例：**
+ [Quickly build STIG-compliant AMI using EC2 Image Builder](https://aws.amazon.com/blogs/security/quickly-build-stig-compliant-amazon-machine-images-using-amazon-ec2-image-builder/)
+ [Building better container images](https://aws.amazon.com/blogs/containers/building-better-container-images/)
+ [Using Lambda layers to simplify your development process](https://aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/)
+ [Develop & Deploy AWS Lambda Layers using Serverless Framework](https://github.com/aws-samples/aws-serverless-lambda-layers)
+ [Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST and DAST tools](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
# SEC06-BP03 减少人工管理工作和交互式访问
尽可能使用自动化方式来执行部署、配置、维护和调查任务。在紧急程序或安全（沙盒）环境中，如果自动化不可用，可以考虑手动访问计算资源。
**期望结果：**程序化脚本和自动化文档（运行手册）可捕获计算资源上的授权操作。这些运行手册可以通过变更检测系统自动启动，也可以在需要人工判断时手动启动。只有在无法实现自动化的紧急情况下，才允许直接访问计算资源。所有手动活动都会被记录下来并纳入审查流程，以便不断提高自动化能力。
**常见反模式：**
+ 使用 SSH 或 RDP 等协议对 Amazon EC2 实例进行交互式访问。
+ 维护个人用户登录信息，例如 `/etc/passwd` 或 Windows 本地用户。
+ 多个用户共用一个密码或私钥来访问实例。
+ 手动安装软件，手动创建或更新配置文件。
+ 手动更新或修补软件。
+ 登录实例来解决问题。
**建立此最佳实践的好处：**自动执行操作有助于降低意外更改和错误配置的操作风险。避免使用 Secure Shell（SSH）和远程桌面协议（RDP，Remote Desktop Protocol）进行交互式访问，可缩小计算资源的访问范围。这样可以消除一种执行未经授权操作的常见方式。可以在自动化文档和程序化脚本中捕获计算资源管理任务，这种机制以细粒度的方式定义和审计授权活动的全部范围。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
登录到实例上是一种传统的系统管理方法。安装服务器操作系统后，用户通常会手动登录，以便配置系统并安装所需的软件。在服务器的生命周期内，用户可能会登录服务器来更新软件、应用补丁、更改配置和解决问题。
然而，手动访问会带来一些风险。这需要一个能监听请求（如 SSH 或 RDP 服务）的服务器，这就可能为未经授权的访问提供潜在的路径。这还增加了与执行手动措施相关的人为出错风险。这些操作可能导致工作负载事件、数据损坏或毁坏或者其它安全问题。人工访问还需要防止共享凭证，从而增加了管理开销。
为了降低这些风险，您可以实施基于代理的远程访问解决方案，例如 [AWS Systems Manager](https://aws.amazon.com/systems-manager/)。AWS Systems ManagerAgent（SSM Agent）会启动一个加密通道，因此它不依赖于监听外部发起的请求。考虑配置 SSM Agent 以便[通过 VPC 端点建立此通道](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html)。
利用 Systems Manager 可以精细控制您与托管实例进行交互的方式。您可以定义要运行的自动化操作、谁可以运行以及何时运行。Systems Manager 可以打补丁、安装软件和更改配置，而无需与实例进行交互式访问。Systems Manager 还可提供对远程 Shell 的访问，并将会话期间调用的每条命令及其输出记录到日志和 [Amazon S3](https://aws.amazon.com/s3/) 中。[AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 会记录对 Systems Manager API 的调用，以供检查之用。
### 实施步骤
1. 在 Amazon EC2 实例上[安装 AWS Systems Manager Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)（SSM Agent）。检查 SSM Agent 是否包含在基本 AMI 配置中并能够自动启动。
1. 验证与 EC2 实例配置文件相关联的 IAM 角色是否包含 `AmazonSSMManagedInstanceCore` [托管 IAM 策略](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html)。
1. 禁止在实例上运行 SSH、RDP 和其它远程访问服务。为此，您可以运行在启动模板的用户数据部分内配置的脚本，或者使用 EC2 Image Builder 等工具构建自定义 AMI。
1. 确保适用于 EC2 实例的安全组入口规则不允许访问端口 22/tcp（SSH）或端口 3389/tcp（RDP）。使用 AWS Config 等服务对配置错误的安全组实施检测和提醒。
1. 在 Systems Manager 中定义适当的自动化操作、运行手册和运行命令。使用 IAM 策略来定义谁可以执行这些操作以及允许执行这些操作的条件。请在非生产环境中彻底测试这些自动化操作。请尽可能调用这些自动化操作，而不是以交互方式访问实例。
1. 必要时，使用 [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 提供对实例的交互式访问。启用会话活动日志记录，以便在 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 或 [Amazon S3](https://aws.amazon.com/s3/) 中保留审计跟踪记录。
## 资源
**相关最佳实践：**
+ [REL08-BP04 使用不可变基础设施进行部署](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_immutable_infrastructure.html)
**相关示例：**
+ [Replacing SSH access to reduce management and security overhead with AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/)
**相关工具：**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
**相关视频：**
+ [Controlling User Session Access to Instances in AWS Systems Manager Session Manager](https://www.youtube.com/watch?v=nzjTIjFLiow)
# SEC06-BP04 验证软件完整性
使用加密验证来验证工作负载使用的软件构件（包括映像）的完整性。 对软件进行加密签名，以防在计算环境中出现未经授权的更改。
**期望结果：**所有构件均从可信来源获得。供应商网站证书已通过验证。 下载的构件通过其签名进行加密验证。您自己的软件经过加密签名，并由您的计算环境进行验证。
**常见反模式：**
+ 信任信誉良好的供应商网站，从中获取软件构件，但忽视证书过期通知。 在未确认证书有效的情况下就继续下载。
+ 验证供应商网站证书，但是从这些网站下载的构件没有进行加密验证。
+ 仅依靠摘要或哈希值来验证软件的完整性。 哈希值可用于确定构件未在原始版本的基础上进行修改，但不能证实其来源正确。
+ 不签署您自己的软件、代码或库，即使它们仅用于自己的部署。
**建立此最佳实践的好处：**验证工作负载所依赖的构件是否完整，这有助于防止恶意软件进入计算环境。 对软件进行签名有助于防止未经授权的软件在计算环境中运行。 通过签署和验证代码，保护软件供应链。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
操作系统映像、容器映像和代码构件通常在分发时提供完整性检查，例如通过摘要或哈希值进行检查。 这样，客户端就可以通过计算自己的有效负载哈希值，并验证哈希值与发布的哈希值是否相同，来验证完整性。 虽然这些检查有助于验证有效负载是否未被篡改，但并不能证实有效负载来自原始来源（数据*出处*）。 验证数据出处时，需要有可信机构签发的证书对构件进行了数字签名。
如果在工作负载中使用下载的软件或构件，请检查提供商是否提供了用于验证数字签名的公钥。 以下这些示例说明 AWS 如何为我们发布的软件提供公钥和验证说明：
+ [EC2 Image Builder: Verify the signature of the AWSTOE installation download](https://docs.aws.amazon.com/imagebuilder/latest/userguide/awstoe-verify-sig.html)
+ [AWS Systems Manager：验证 SSM Agent 签名](https://docs.aws.amazon.com/systems-manager/latest/userguide/verify-agent-signature.html)
+ [Amazon CloudWatch：验证 CloudWatch 代理软件包的签名](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/verify-CloudWatch-Agent-Package-Signature.html)
将数字签名验证过程纳入您用于获取和强化映像的流程中，如 [SEC06-BP02 从强化映像预置计算](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html)中所述。
您可以使用 [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) 来协助管理签名验证过程，以及您自己的软件和构件的代码签名生命周期。 [AWS Lambda](https://aws.amazon.com/lambda/) 和 [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) 均实现了与 Signer 的集成，能够验证代码和映像的签名。 您可以参考“资源”部分中的示例，将 Signer 纳入持续集成和持续交付（CI/CD，Continuous Integration and Delivery）管道，以便自动验证签名并签署自己的代码和映像。
## 资源
**相关文档：**
+ [Cryptographic Signing for Containers](https://aws.amazon.com/blogs/containers/cryptographic-signing-for-containers/)
+ [Best Practices to help secure your container image build pipeline by using AWS Signer](https://aws.amazon.com/blogs/security/best-practices-to-help-secure-your-container-image-build-pipeline-by-using-aws-signer/)
+ [Announcing Container Image Signing with AWS Signer and Amazon EKS](https://aws.amazon.com/blogs/containers/announcing-container-image-signing-with-aws-signer-and-amazon-eks/)
+ [为 AWS Lambda 配置代码签名](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html)
+ [Best practices and advanced patterns for Lambda code signing](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/)
+ [Code signing using AWS Certificate Manager Private CA and AWS Key Management Service asymmetric keys](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/)
**相关示例：**
+ [Automate Lambda code signing with Amazon CodeCatalyst and AWS Signer](https://aws.amazon.com/blogs/devops/automate-lambda-code-signing-with-amazon-codecatalyst-and-aws-signer/)
+ [Signing and Validating OCI Artifacts with AWS Signer](https://aws.amazon.com/blogs/containers/signing-and-validating-oci-artifacts-with-aws-signer/)
**相关工具：**
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)
+ [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/)
+ [AWS Key Management Service](https://aws.amazon.com/kms/)
+ [AWS CodeArtifact](https://aws.amazon.com/codeartifact/)
# SEC06-BP05 自动保护计算
自动执行保护计算的操作，减少人工干预的需要。使用自动扫描检测计算资源中是否可能存在问题，并通过自动程序化响应或实例集管理操作进行修复。 在您的 CI/CD 流程中融入自动化功能，以最新的依赖项来部署值得信赖的工作负载。
**期望结果：**由自动化系统对计算资源进行所有扫描和修补。您可以使用自动验证来检查软件映像和依赖项是否来自可信来源，以及是否被篡改。自动检查工作负载是否有最新的依赖项，并对工作负载进行签名，以便在 AWS 计算环境中建立信任。 一旦检测到不合规的资源，就会启动自动修复措施。
**常见反模式：**
+ 遵循不可变基础设施的做法，但没有制定紧急修补或更换生产系统的解决方案。
+ 使用自动化技术来修复配置错误的资源，但没有手动覆盖机制。 在某些情况下，您可能需要调整要求，并且在进行这些更改之前需要暂停自动化操作。
**建立此最佳实践的好处：**自动化操作可以降低未经授权访问和使用计算资源的风险。 这有助于防止错误配置对生产环境产生影响，检测错误配置，并在发生错误配置时对其进行修复。 自动化操作还有助于检测未经授权的访问和使用计算资源的情况，从而缩短响应时间。 这反过来又能够缩小问题的总体影响范围。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
您可以应用安全性支柱实践中描述的自动化操作来保护计算资源。[SEC06-BP01 执行漏洞管理](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_vulnerability_management.html)描述了如何在 CI/CD 管道中使用 [Amazon Inspector](https://aws.amazon.com/inspector/)，以及如何持续扫描运行时环境，查看是否存在已知的通用漏洞披露（CVE，Common Vulnerabilities and Exposures）。 您可以遵循自动化运行手册，使用 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 来应用补丁或者利用新映像重新部署，从而始终使用最新的软件和库来更新计算实例集。 使用这些技术可减少对人工流程和交互式访问计算资源的需求。 请参阅《[SEC06-BP03 减少人工管理工作和交互式访问](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_reduce_manual_management.html)》，了解更多信息。
自动化操作在部署值得信赖的工作负载方面也发挥着作用，如《[SEC06-BP02 从强化映像预置计算](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html)》和《[SEC06-BP04 验证软件完整性](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_validate_software_integrity.html)》中所述。 您可以使用 [EC2 Image Builder](https://aws.amazon.com/image-builder/)、[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)、[AWS CodeArtifact](https://aws.amazon.com/codeartifact/) 和 [Amazon Elastic Container Registry（ECR）](https://aws.amazon.com/ecr/)等服务，来下载、验证、构造和存储经过强化和批准的映像和代码依赖项。 通过与 Inspector 配合使用，这些服务都可以在您的 CI/CD 流程中发挥作用，这样您的工作负载只有在确认其依赖项是最新的且来自可信来源时，才会进入生产阶段。 工作负载还经过签名，这样 [AWS Lambda](https://aws.amazon.com/lambda/) 和 [Amazon Elastic Kubernetes Service（EKS）](https://aws.amazon.com/eks/)等 AWS 计算环境就能在允许工作负载运行之前，验证工作负载是否未被篡改。
除了这些预防性控制措施之外，您还可以在计算资源的检测性控制中运用自动化。 例如，[AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 提供 [NIST 800-53 Rev. 5](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html) 标准，其中包括 [[EC2.8] EC2 实例应使用实例元数据服务版本 2（IMDSv2）](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-8)等检查内容。 IMDSv2 使用会话验证、阻止包含 X-Forwarded-For HTTP 标头的请求，以及设置网络 TTL 为 1 等技术，来阻止来自外部来源的流量检索有关 EC2 实例的信息。Security Hub CSPM 中的这项检查可检测 EC2 实例何时使用 IMDSv1 并启动自动修复措施。参阅《[SEC04-BP04 启动对不合规资源的修复](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html)》，了解有关自动化检测和修复的更多信息。
### 实施步骤
1. 利用 [EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/integ-compliance-products.html) 自动创建安全、合规且经过强化的 AMI。 您可以在基础 AWS 和 APN 合作伙伴映像中融入符合互联网安全中心（CIS，Center for Internet Security）基准或安全技术实施指南（STIG，Security Technical Implementation Guide）标准的控制措施，从而生成自己的映像。
1. 自动执行配置管理。使用配置管理服务或工具，在计算资源中自动实施和验证安全配置。
1. 使用 [AWS Config](https://aws.amazon.com/config/) 自动执行配置管理
1. 使用 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 自动管理安全性和合规性态势
1. 自动修补或替换 Amazon Elastic Compute Cloud（Amazon EC2）实例。AWSSystems Manager Patch Manager 使用安全相关的更新和其它类型的更新自动执行修补托管实例的流程。您可以使用 Patch Manager 来应用操作系统和应用程序的补丁。
1. [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
1. 自动扫描计算资源以便查找通用漏洞披露（CVE，Common Vulnerabilities and Exposures），并在构建管道中嵌入安全扫描解决方案。
1. [Amazon Inspector](https://aws.amazon.com/inspector/) –
1. [ECR 映像扫描](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html)
1. 考虑使用 Amazon GuardDuty 自动检测恶意软件和威胁，以便保护计算资源。在 AWS 环境中调用 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 函数时，GuardDuty 还可以识别出潜在问题。
1. [Amazon GuardDuty](https://aws.amazon.com/guardduty/)
1. 考虑采用 AWS 合作伙伴解决方案。AWS合作伙伴提供业界领先的产品，这些产品与您的本地环境中的现有控制措施等效、相同或与之集成。这些产品对现有 AWS 服务起到补充作用，使您能够在云端和本地环境中部署全面的安全架构，进而实现无缝效果更好的体验。
1. [基础结构安全性](https://aws.amazon.com/security/partner-solutions/#infrastructure_security)
## 资源
**相关最佳实践：**
+ [SEC01-BP06 自动部署标准安全控制措施](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html)
**相关文档：**
+ [Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/)
**相关视频：**
+ [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI)