手册

Auto Scaling 组中一个可能受损的 EC2 实例需要调查，同时将中断降至最低。

→从 ELB 目标组中注销，从 Auto Scaling 组中移除，并应用一个限制性的“取证”安全组，拒绝除取证工作站访问外的所有流量。

原因: 这将在保持实例易失性状态（内存、运行进程）不变的情况下，将其从网络中隔离出来，以便进行取证分析。立即终止会破坏证据。

自动化由 GuardDuty 发现触发的多步骤事件响应工作流（例如，快照、隔离、通知）。

→使用 EventBridge 规则捕获特定发现并触发 AWS Step Functions 状态机。状态机通过错误处理和重试逻辑编排操作序列。

原因: Step Functions 为多步骤工作流提供强大的编排功能，确保可靠性和状态管理，这优于单个庞大的 Lambda 函数。

在运行中的 ECS Fargate 或 EC2 容器中检测运行时威胁（例如，加密挖矿、权限提升），而无需部署 sidecar 代理。

→启用 Amazon GuardDuty ECS Runtime Monitoring。对于 EC2，将 GuardDuty 安全代理部署为 DaemonSet。对于 Fargate，使用自动化代理配置。

原因: 这提供了无代理（针对 Fargate）或集中管理（针对 EC2）的运行时威胁检测，可以在不修改应用程序任务的情况下捕获容器内的行为。

参考↗

自动修复特定的 AWS Security Hub 发现，例如公开可用的 S3 存储桶。

→创建一个 EventBridge 规则，匹配特定的发现类型（例如，`S3.1`），并触发 Lambda 函数或 SSM Automation 文档来执行修复。

原因: 这是 Security Hub 自动化响应的原生、事件驱动模式，提供近乎实时的、有针对性的修复。

一个 IAM 访问密钥已公开泄露。控制事件并评估影响范围。

→1. 禁用已泄露的访问密钥。2. 向用户/角色附加一个拒绝所有操作的内联策略，以使活动的 STS 会话失效。3. 审查 CloudTrail 日志中所有使用该密钥进行的 API 调用。4. 清除攻击者创建的任何未经授权的资源或 IAM 委托人。

原因: 禁用密钥可以阻止未来的使用。拒绝所有操作的策略对于撤销在密钥禁用 *之前* 创建的活动会话至关重要。CloudTrail 提供审计跟踪以评估损害。

使用公司特定或行业特定的威胁情报源来增强 GuardDuty 威胁检测。

→将包含恶意 IP 地址/CIDR 的纯文本文件上传到 S3。在 GuardDuty 中创建并激活一个新的威胁情报集，指向该 S3 文件。

原因: 这允许您使用自定义 IOC 增强 GuardDuty 的托管威胁情报，当您的资源与这些指定的 IP 通信时生成发现。

识别在特定端口上对互联网开放网络路径的 EC2 实例，同时考虑所有网络配置。

→启用 Amazon Inspector 并审查其网络可达性发现。

原因: Inspector 执行从 IGW 到实例的完整网络路径分析，评估安全组、NACL 和路由表以确定实际可达性。这比仅仅检查单个安全组规则更准确。

调查安全发现的全部范围，可视化所有相关实体和历史行为。

→使用 Amazon Detective。导航到实体配置文件（例如，针对 EC2 实例或 IAM 角色），查看行为图以及相关 API 调用、网络连接和 GuardDuty 发现的时间线。

原因: Detective 自动关联来自 CloudTrail、VPC Flow Logs 和 GuardDuty 的日志，提供上下文分析，与手动日志关联相比，显著加快了根本原因调查。

以防篡改、可查询的方式存储审计日志（例如 CloudTrail、VPC Flow Logs）以进行长期保留，满足合规性要求。

→将日志传送到已启用 S3 对象锁定合规模式的 S3 存储桶。使用 Amazon Athena 进行查询。

原因: 合规模式下的对象锁定可防止任何人（包括根用户）删除或修改，确保日志的不可变性。Athena 提供对存储日志的即席 SQL 查询功能。

参考↗

集中收集整个 AWS Organization 的所有管理和数据事件。

→在管理账户中，创建 CloudTrail 组织跟踪。为了捕获对象级别数据，请使用高级事件选择器来记录高价值资源的特定事件类型（例如 S3 PutObject、Lambda Invoke）。

原因: 组织跟踪会自动记录所有成员账户的事件。高级事件选择器对于通过仅定位必要资源来经济高效地记录大量数据事件至关重要。

对整个组织多年来的 CloudTrail 事件执行复杂的、基于 SQL 的分析。

→启用 AWS CloudTrail Lake 并创建一个具有所需保留期（最长 7 年）的组织级事件数据存储。使用内置的 SQL 查询编辑器进行分析。

原因: CloudTrail Lake 提供了一个专门为 CloudTrail 事件构建的托管、不可变的数据存储和查询引擎，无需管理 S3、Glue 和 Athena 进行日志分析。

监控 VPC 内资源发出的所有 DNS 查询，用于威胁搜寻或故障排除。

→启用 Route 53 Resolver DNS Query Logging，并将其配置为将日志发送到 CloudWatch Logs、S3 或 Kinesis Data Firehose。

原因: 这提供了对 VPC 内 DNS 解析活动的详细可见性，捕获了查询的域、源实例和响应，这对于检测基于 DNS 的威胁至关重要。

使用标准模式将来自各种 AWS 和第三方源的安全日志集中并规范化到数据湖中。

→部署 Amazon Security Lake。它会自动收集数据并将其规范化为 Open Cybersecurity Schema Framework (OCSF) 格式，然后以 Parquet 格式存储在 S3 中。

原因: Security Lake 自动化了安全数据湖的创建和管理，减少了构建自定义 ETL 管道进行规范化的操作开销。

自动化合规性审计的证据收集，以符合 SOC 2、PCI DSS 或 HIPAA 等框架。

→使用 AWS Audit Manager。选择一个预构建的框架，该框架会自动从 AWS 服务（CloudTrail、Config、Security Hub）收集证据，并将其映射到特定的合规性控制。

原因: Audit Manager 自动化并集中化了证据收集过程，显著减少了准备和进行合规性审计所需的手动工作。

自动发现和分类所有 S3 存储桶中的敏感数据（PII、PHI、财务数据）。

→启用 Amazon Macie 并配置自动敏感数据发现作业。使用托管数据标识符识别常见数据类型，并为专有格式创建自定义数据标识符。

原因: Macie 为 S3 数据分类提供了托管、可扩展的解决方案。要抑制对已知非敏感数据（例如测试数据）的发现，请使用 Macie 允许列表。

对 S3 存储桶强制执行多项安全控制，例如要求使用特定密钥进行 SSE-KMS 加密并拒绝 HTTP 请求。

→使用包含多个 `Deny` 语句和条件键的存储桶策略：`aws:SecureTransport: false`、`s3:x-amz-server-side-encryption: "aws:kms"` 和 `s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`。

原因: 存储桶策略提供细粒度的资源级控制。在拒绝语句中使用多个条件键是对存储桶强制执行分层安全态势的标准方法。

确保所有新的 EBS 卷都使用特定的客户管理型 KMS 密钥进行加密，在整个组织范围内。

→在每个区域的账户设置中默认启用 EBS 加密，并指定 CMK。应用 SCP，如果 `encrypted` 参数为 `false`，则拒绝 `ec2:CreateVolume`，作为预防性防护措施。

原因: 默认设置提供了便利，而 SCP 提供了硬性强制防护措施，为 EBS 的静态数据加密创建了深度防御方法。

使用 AWS KMS 加密大型（大于 4KB）数据对象。

→使用信封加密。调用 `KMS:GenerateDataKey` 获取明文数据密钥和加密数据密钥。使用明文密钥在本地加密大型对象。将加密对象和加密数据密钥一起存储。丢弃明文密钥。

原因: KMS Encrypt API 有 4KB 的限制。信封加密允许加密任何大小的数据，同时小数据密钥受 KMS 保护，与通过 KMS 流式传输数据相比，降低了成本和延迟。

参考↗

在多个 AWS 区域中使用相同的加密密钥，以实现灾难恢复或全球应用程序一致性。

→在一个区域中创建 KMS 多区域主密钥，并在其他区域中创建副本密钥。在一个区域中使用密钥加密的数据可以使用另一个区域中的副本密钥解密。

原因: 多区域密钥共享相同的密钥材料和密钥 ID，从而实现了跨区域数据可移植性，而无需进行跨区域 API 调用进行解密。

安全存储和自动轮换应用程序使用的凭证（例如，数据库密码、API 密钥）。

→将凭证存储在 AWS Secrets Manager 中。使用自定义或 AWS 提供的 Lambda 轮换函数配置自动轮换。应用程序在运行时通过 IAM 角色检索密钥。

原因: Secrets Manager 是一款专为整个密钥生命周期构建的服务，包括安全存储、访问控制、审计和自动轮换，降低了硬编码或过期凭证的风险。

管理网站的公共 TLS 证书和内部微服务通信 (mTLS) 的私有证书。

→使用 AWS Certificate Manager (ACM) 获取与 ELB/CloudFront 集成的免费公共证书。使用 ACM Private CA 创建私有证书颁发机构，为内部服务颁发和管理私有证书。

原因: 这分离了公共和私有 PKI，为每个用例使用适当的工具。ACM 处理公共证书生命周期，而 ACM Private CA 提供完全托管的私有 PKI 层次结构。

以不可变的方式存储数据，固定保留期内，即使是根用户也无法删除。

→在存储桶上启用 S3 对象锁定。在合规模式下设置对象的保留期。

原因: 合规模式是最强的 WORM（一次写入，多次读取）控制，可防止任何用户删除。治理模式可以被授权委托人绕过。

在强制保留期内保护备份不被删除（例如，由于勒索软件或凭证泄露）。

→启用 AWS Backup Vault Lock 的合规模式，并设置最短保留期。

原因: 合规模式下的保管库锁定使备份保管库符合 WORM 标准，防止任何用户（包括根用户）在保留期到期前删除恢复点。

处理高度敏感数据，其中数据绝不能暴露给操作系统、虚拟机管理程序或 AWS 运营商。

→使用 AWS Nitro Enclaves 创建加密隔离的计算环境。使用 KMS 证明来确保只有经过验证的 enclave 才能解密数据。

原因: Nitro Enclaves 使用硬件级证明创建受信任的执行环境，提供 AWS 上最强级别的使用中数据保护。

在 AWS 外部使用物理存储和管理在本地 HSM 中的加密密钥来使用 AWS 服务。

→配置 KMS External Key Store (XKS)，它将 KMS 的加密操作代理到外部密钥管理器。

原因: XKS 允许客户在 AWS 外部保持对其密钥材料的控制，以满足主权或合规性要求，同时仍与支持 KMS 的 AWS 服务集成。

通过预防性和检测性控制，在整个组织中强制执行严格的“无公共 S3 存储桶”策略。

→从管理账户在组织级别启用 S3 Block Public Access。通过一个 SCP 进行补充，如果策略允许公共访问，则拒绝 `s3:PutBucketPolicy` 等操作。使用 AWS Config 检测偏差。

原因: 这种分层方法提供了一个默认的阻止（组织设置）、一个阻止错误配置的预防性防护措施 (SCP)，以及一个用于持续监控的检测性控制 (Config)。

使用集中式安全设备（例如 AWS Network Firewall）检查所有 VPC 间和互联网出站流量。

→创建一个专用的检查 VPC。使用 Transit Gateway 连接所有 VPC。配置 TGW 路由表，将所有流量通过检查 VPC 发送。在 TGW 附件上启用设备模式以实现对称路由。

原因: 这是集中式流量检查的标准中心辐射模型，提供了可伸缩性和一致的策略实施，而无需复杂的 VPC 对等网格。

保护（在 CloudFront/ALB 上的）Web 应用程序免受 OWASP Top 10 威胁、机器人和账户接管攻击。

→将 AWS WAF 与 AWS 托管规则（例如 `AWSManagedRulesCommonRuleSet`）、机器人控制托管规则组和账户接管防护 (ATP) 托管规则组关联。

原因: 这种分层方法使用多个托管规则组来实现广泛保护（通用）、自动化流量检测（机器人控制）和专门的登录端点安全（ATP）。

在不将 SaaS API 服务暴露给互联网的情况下，从客户 VPC 提供安全、私密的访问。

→创建一个由网络负载均衡器 (NLB) 支持的 AWS PrivateLink 终端节点服务。客户在其 VPC 中创建接口 VPC 终端节点以访问该服务。

原因: PrivateLink 将流量保持在 AWS 私有骨干网络上，避免了公共互联网，消除了对复杂 VPC 对等连接、VPN 或 IP 白名单的需求。它是私有 SaaS 连接的标准、可扩展模式。

限制 S3 存储桶访问，使其内容只能通过 CloudFront 分配访问。

→使用 CloudFront Origin Access Control (OAC)。更新 S3 存储桶策略，仅允许来自 CloudFront 分配的服务委托人访问，并以特定的分配 ARN 作为条件。

原因: OAC 是当前推荐的方法，优于旧版 Origin Access Identity (OAI)。它支持所有 S3 功能，包括 SSE-KMS，并遵循安全最佳实践。

在不开放 SSH/RDP 端口或管理堡垒主机的情况下，为私有子网中的 EC2 实例提供安全、可审计的 shell 访问。

→在 EC2 实例上安装 SSM Agent。使用 AWS Systems Manager Session Manager 进行访问。IAM 策略控制谁可以启动会话。会话活动可以记录到 CloudWatch Logs 和 S3。

原因: Session Manager 通过加密隧道提供安全的、基于浏览器或 CLI 的访问，消除了入站端口、堡垒主机和 SSH 密钥的需求，同时提供了完整的可审计性。

实施 DNS 级别过滤，以防止 VPC 资源解析已知的恶意域。

→使用托管域列表（用于恶意软件、C2）和自定义阻止列表配置 Route 53 Resolver DNS Firewall。将防火墙规则组与 VPC 关联。

原因: 这在 VPC 级别提供了一个集中式、托管的 DNS 过滤服务，在最早的时刻（DNS 解析）阻止恶意活动，而无需基于主机的代理。

为三层 Web 应用程序实施最小权限网络控制。

→为每个层创建单独的安全组。ALB SG 允许来自 `0.0.0.0/0` 的入站 443 流量。App SG 仅允许来自 ALB SG 的入站流量。DB SG 仅允许来自 App SG 的数据库端口上的入站流量。

原因: 使用安全组引用作为源提供了动态的、与 IP 无关的微细分，确保每一层只能由其相邻的、授权的层访问。

为在 EKS 上运行的应用程序授予细粒度的 Pod 级别 AWS 权限，避免使用共享的节点 IAM 角色。

→在 EKS 集群上启用 IAM Roles for Service Accounts (IRSA)。为应用程序创建具有特定权限的 IAM 角色。使用 IAM 角色 ARN 标注应用程序的 Kubernetes 服务账户。

原因: IRSA 根据 Pod 的服务账户直接向 Pod 提供临时凭证，在 Pod 级别实施最小权限，消除了权限过高的节点角色的安全风险。

基于用户身份和设备安全态势，为内部 Web 应用程序提供无 VPN 访问。

→部署 AWS Verified Access。将其与企业 IdP 集成作为用户信任提供者，并与设备管理解决方案集成作为设备信任提供者。创建每个应用程序的访问策略。

原因: Verified Access 专为零信任访问而构建，根据同时考虑用户和设备上下文的策略评估每个请求，消除了对网络边界安全的依赖。

允许开发人员创建 IAM 角色，但防止他们创建可能提升其自身权限的角色。

→创建一个定义最大允许权限的权限边界策略。在开发人员的 IAM 策略中，通过 `iam:PermissionsBoundary` 条件键，将 `iam:CreateRole` 权限设置为必须附加此特定边界。

原因: 权限边界设定了 IAM 实体可以拥有的最大权限。这通过确保开发人员创建的任何角色都受边界限制来防止权限提升，无论他们附加了什么身份策略。

参考↗

阻止任何成员账户中的任何用户（包括管理员）执行高风险操作，例如禁用 CloudTrail 或删除一个公共 S3 存储桶。

→将包含受限操作（例如 `cloudtrail:StopLogging`、`s3:DeleteBucket`）的 `Deny` 语句的服务控制策略 (SCP) 应用于根或相关的组织单位 (OU)。

原因: SCP 是 AWS Organizations 中的终极防护栏。它们为账户中的所有委托人设置了最大权限，并且 SCP 中的显式拒绝不能被账户内的任何 IAM 策略覆盖。

为应用程序或用户提供安全、可审计的跨账户访问。

→在目标账户中，创建一个 IAM 角色，其信任策略指定源账户的委托人 ARN。在源账户中，授予该委托人对目标角色执行 `sts:AssumeRole` 操作的权限。应用程序使用 STS AssumeRole 获取临时凭证。

原因: 这是跨账户访问的标准模式。它使用临时的、短期的凭证，并且可以通过 CloudTrail 在两个账户中进行完整审计。

将 IAM Identity Center 与外部身份提供商 (IdP)（例如 Okta、Azure AD）集成，并自动化用户/组预置。

→在 IAM Identity Center 中将外部 IdP 配置为身份源。通过 SCIM 启用自动预置以同步用户和组。将权限集分配给同步的组。

原因: SCIM（跨域身份管理系统）提供身份的自动化、近实时同步，消除了手动用户管理，并确保 AWS 访问由 IdP 驱动。

根据标签授予对资源（例如 EC2）的访问权限，其中委托人只能管理带有其自己的团队/部门名称标签的资源。

→使用公共键（例如 `Team`）为 IAM 委托人（用户/角色）和资源（EC2 实例）打上标签。创建一个 IAM 策略，允许在条件中比较 `aws:PrincipalTag/Team` 和 `aws:ResourceTag/Team` 的操作。

原因: 基于属性的访问控制 (ABAC) 提供了一种可扩展的权限模型，当添加新资源或团队时，无需更新策略。权限是根据标签动态确定的。

账户 B 中的委托人需要读取账户 A 中使用账户 A 中的 KMS 密钥加密的 S3 对象。

→需要三个权限：1) 账户 A 中的 S3 存储桶策略必须允许来自账户 B 的委托人。2) 账户 A 中的 KMS 密钥策略必须允许来自账户 B 的委托人执行 `kms:Decrypt` 操作。3) 账户 B 中的委托人需要一个允许 `s3:GetObject` 和 `kms:Decrypt` 的 IAM 策略。

原因: 访问 KMS 加密数据需要来自数据服务 (S3) 和加密服务 (KMS) 的权限。KMS 密钥策略是一种资源策略，对于授予跨账户访问至关重要。

了解当多个策略（IAM、资源、SCP、边界）应用时，最终的权限结果。

→评估逻辑是：任何策略中的显式拒绝始终覆盖任何允许。如果不存在拒绝，则任何适用策略中的显式允许都授予访问权限。有效权限是所有适用策略的交集。

原因: 这是 IAM 的一个基本概念。显式拒绝是最强大的声明，并作为硬性“否决”。理解这一点是排除访问问题故障的关键。

阻止 IAM 用户或角色将高权限角色传递给 AWS 服务（例如 EC2），这会提升其权限。

→在用户/角色的 IAM 策略中限定 `iam:PassRole` 权限。将 `Resource` 元素限制为实体被授权传递的特定、最小权限角色 ARN。

原因: 带有通配符（`"Resource": "*"`）的 `iam:PassRole` 存在重大的权限提升风险。将其限定到特定的、低权限角色是一项关键的安全控制。

仅当登录尝试被认为是高风险时（例如，新设备、异常位置）才要求用户进行 MFA 挑战。

→在 Cognito 用户池中启用高级安全功能，并配置基于风险的 MFA 强制执行的自适应身份验证。

原因: 这比每次登录都要求 MFA 提供更好的用户体验，同时通过仅对异常登录尝试应用挑战来增强安全性。

允许使用私有 PKI 的本地服务器访问 AWS 服务，而无需长期 AWS 凭证。

→配置 IAM Roles Anywhere。使用私有 CA 证书创建信任锚。创建将证书映射到 IAM 角色的配置文件。服务器使用其证书获取临时 AWS 凭证。

原因: 这通过利用现有 PKI 将 IAM 角色扩展到外部工作负载，消除了在本地管理 AWS 访问密钥的需求。

在资源预置 *之前*，阻止部署 CloudFormation 模板中定义的非合规资源。

→启用 AWS Control Tower 主动式控制。这些控制使用 CloudFormation 钩子在预置前根据策略（用 cfn-guard 编写）验证资源配置。

原因: 这是一种“左移”控制，可在源头防止错误配置，比在部署后检测和修复它们更有效。