Amazon SCS-C02: 边缘与应用安全 — 学习指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

属于 AWS Security Specialty SCS-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

CloudFront 地理限制与国家级屏蔽

CloudFront 提供两种按国家/地区屏蔽流量的机制，选择哪种机制对成本和功能有重要影响。内置的地理限制功能（也称为 geoblocking）直接在分配（distribution）上配置，它在边缘节点根据查看者的 IP，对照国家/地区白名单或黑名单来评估请求。此功能免费，无需规则评估，并且在发生任何源站抓取之前返回 HTTP 403。对于简单的合规性场景——例如“屏蔽来自 X 国的访问者”——这是最便宜、最简单的选项。

另一种选择是 WAF 地理匹配语句，它更加灵活：您可以将国家/地区匹配与 URI 路径、标头、速率限制相结合，或对其进行否定（例如“仅允许 A 国访问 /admin”）。当逻辑是条件性的时候，就需要 WAF；仅靠地理限制无法表达“仅针对特定路径屏蔽 X 国”。当需求是统一的国家/地区屏蔽并且您希望避免 WAF 的按请求计费成本时，应选择原生的地理限制功能。

用于私有内容的签名 URL 与签名 Cookie 对比

CloudFront 支持两种方式来提供经授权的私有内容，同时通过源访问控制（origin access control）或自定义标头将源站（S3 存储桶、ALB 或媒体源站）隐藏起来：

• 签名 URL： 每个 URL 都带有签名和策略。非常适合单文件下载或需要按文件进行访问控制的场景（例如，一次性的软件安装程序链接）。

• 签名 Cookie： 客户端通过您的身份验证服务一次性收到 CloudFront-Policy、CloudFront-Signature 和 CloudFront-Key-Pair-Id 这组 Cookie。所有后续对匹配路径模式的请求都会被自动授权，无需重写 URL。

对于 HLS 视频流，单个播放会话会获取清单（manifest）中引用的数千个 .ts 片段，使用签名 Cookie 要简单得多。用不同的签名 URL 重写清单中的每个片段 URL 是可行的，但这会增加延迟和复杂性。在订阅者通过您的内部用户存储进行身份验证后设置 Cookie，并将其范围限定在流媒体路径模式内。

一个用于通配符签名 Cookie 的规范策略如下所示：

{
  "Statement": [{
    "Resource": "https://d123.cloudfront.net/videos/*",
    "Condition": {
      "DateLessThan": {"AWS:EpochTime": 1735689600},
      "IpAddress":    {"AWS:SourceIp": "203.0.113.0/24"}
    }
  }]
}

将其与源访问控制 (OAC) 或在源站由 WAF 验证的秘密自定义标头配对，这样用户就无法绕过 CloudFront 直接访问源站。

AWS WAF：托管规则、ATP 和基于速率的规则

当工作负载位于 CloudFront 之后时，应将 Web ACL 附加到 CloudFront 分配，而不是区域性的 ALB。边缘附加可在数百个 POP（接入点）之一终止恶意请求——更靠近攻击者——这可以在 DDoS 期间减少源站负载，并降低源站的出口流量，因为被阻止的流量永远不会穿越您的 VPC。仅将 WAF 附加到 ALB 意味着大流量洪水攻击仍会到达区域负载均衡器并消耗 LCU，并且跨区域攻击由单个区域处理，而不是由全球边缘网络处理。

要组合的关键规则组：

• AWS 托管规则集： AWSManagedRulesCommonRuleSet（OWASP top-10 风格）、AWSManagedRulesKnownBadInputsRuleSet 和 AWSManagedRulesAmazonIpReputationList 提供了广泛的覆盖范围，几乎无需调整。

• 账户盗用防护 (ATP)： AWSManagedRulesATPRuleSet 会检查您指定的登录端点，跟踪凭证填充模式，对照被盗凭证数据库检查提交的凭证，并阻止机器人重用泄露的密码。配置时需要提供确切的登录路径以及用户名和密码的 JSON 正文字段名称。

• 基于速率的规则： 限制任何单个 IP 在 5 分钟窗口内的请求数量（例如 2000 个请求）。按 URI 或方法限定其范围，这样对 /search 的抓取就不会影响对 / 的匿名浏览。速率规则可以缓解第 7 层的大流量攻击和暴力枚举。

一个精简的 WAF 规则块：

Rules:
  - Name: RateLimitLogin
    Priority: 1
    Action: { Block: {} }
    Statement:
      RateBasedStatement:
        Limit: 500
        AggregateKeyType: IP
        ScopeDownStatement:
          ByteMatchStatement:
            SearchString: /api/login
            FieldToMatch: { UriPath: {} }
            PositionalConstraint: STARTS_WITH
            TextTransformations: [{ Priority: 0, Type: LOWERCASE }]

ACM 证书、DNS 验证和 CloudFront

对于 CloudFront，无论您的源站位于何处，证书都必须在 us-east-1 (弗吉尼亚北部) 的 ACM 中预置——这是一项硬性要求，因为 CloudFront 是一项全球服务，它会从该区域读取证书。像 ALB 这样的区域性服务则从 ALB 所在的区域读取证书。

对于任何您希望自动续订的公共证书，请始终使用 DNS 验证，并在 Route 53 中配置 CNAME 记录。只要验证 CNAME 记录保持发布状态，ACM 就会自动续订通过 DNS 验证的证书；Route 53 使此过程变得非常简单（在请求过程中，控制台会提供“在 Route 53 中创建记录”的选项）。相比之下，电子邮件验证会向域下的五个地址（admin@、administrator@、hostmaster@、postmaster@、webmaster@）以及 WHOIS 联系人发送确认邮件。这些邮箱常常不存在或被公司邮件过滤器隔离，导致续订在到期前 60 天失败，并引发本可避免的服务中断。无法自动完成电子邮件验证的点击操作。

对于多区域 ALB，正确的续订模式是：为每个区域请求一个经 DNS 验证的 ACM 证书，在 Route 53 中发布一次验证 CNAME，将证书附加到 ALB 侦听器，然后让 ACM 处理续订和重新部署。人工参与在颁发证书后即告结束。

DNSSEC 和 Route 53

在 Route 53 托管区域上启用 DNSSEC 签名，以防止针对您域名的 DNS 欺骗和缓存中毒。Route 53 在 KMS 中管理 KSK（位于 us-east-1 的非对称 ECC 密钥）；您必须在域名注册商处发布 DS 记录。请注意，DNSSEC 签名保护的是您区域的解析过程——它不加密 DNS 流量（那是 DoH/DoT 的功能），也不影响 CloudFront 的 TLS。

响应标头：策略与 Lambda@Edge 对比

CloudFront 不会自动注入安全标头，例如 Strict-Transport-Security、X-Frame-Options、X-Content-Type-Options 或 Content-Security-Policy。如果您的源站无法修改（例如，一个旧版的 S3 站点、一个第三方源站），您有两个选择：

• 响应标头策略 (Response headers policy)： 一种原生的、声明式的 CloudFront 功能。将托管或自定义策略附加到缓存行为上，以添加 HSTS、CORS、安全和自定义标头。这应该是默认选择——无需代码、无冷启动、无单次调用成本。

• Lambda@Edge（查看器响应或源站响应）： 当您需要动态逻辑时使用，例如根据每个请求改变 CSP nonces 或基于请求属性重写标头。以简单性换取灵活性，并增加了按请求计费的成本。

托管的响应标头策略 SecurityHeadersPolicy 通过一次附加即可涵盖常见的基线安全要求。

常见陷阱解析

使用电子邮件验证来请求公共 ACM 证书是脆弱的，这正是因为续订依赖于人工读取发送到通用地址的邮件，而大多数组织不会监控这些地址，或者会将其路由到垃圾邮件。使用 Route 53 进行 DNS 验证则完全消除了人工环节。

在纸面上看，将 WAF 仅附加到 ALB 上似乎效果相同，但这会迫使攻击流量进入您的区域并消耗 ALB 容量。而附加在 CloudFront 上的边缘 WAF 在数百个 POP 节点进行拦截，因此分布式洪水攻击会被全球性地吸收，源站出口流量保持在低位——这在 DDoS 攻击期间至关重要。

假设 CloudFront 会自动添加安全标头会导致渗透测试失败。分发版只是代理源站发送的任何标头；您必须显式附加响应标头策略或 Lambda@Edge 函数来注入 X-Frame-Options: DENY、HSTS 和 CSP。

实际问题：用例场景

场景： Meridian Financial 在 AWS 上运行一个全球分布的客户门户和一个内部报告门户。公共流量通过 Amazon CloudFront 路由到用于动态 API 的 Application Load Balancer 和用于私有报告的 S3 源站；DNS 在 Route 53 中，TLS 证书由 AWS Certificate Manager (ACM) 颁发。

挑战： 攻击者正在从多个国家/地区抓取数据和进行凭据填充攻击，他们通过直接访问源站端点来绕过 CloudFront 下载私有报告，导致源站过载和数据泄露。

推荐方法：

1. 将 CloudFront 配置为唯一的公共入口点，并应用 CloudFront 地理位置限制（Geo Restriction）来阻止有攻击行为的国家/地区；启用源访问控制（OAC）并锁定 S3/ALB 源策略，以便只有 CloudFront 可以获取源站内容。
2. 使用 CloudFront 签名 URL（设置较短的 TTL）而不是签名 Cookie 来提供每个用户的私有报告，这样每次下载都经过单独授权且可审计。
3. 使用 AWS 托管规则将 AWS WAF 附加到 CloudFront 分发版，启用 AWS WAF Bot Control（高级威胁防护），并创建基于速率的规则外加 CAPTCHA 挑战，以缓解数据抓取和凭据填充攻击。
4. 在 ACM 中（对于 CloudFront 分发版需在 us-east-1 区域）使用 Route 53 进行 DNS 验证来配置 TLS 证书，并将 Route 53 别名（Alias）记录发布到 CloudFront 分发版。
5. 在 Route 53 托管区域上启用 DNSSEC，启用 CloudFront 和 WAF 访问日志记录到 S3，并创建 CloudWatch 警报和可选的 AWS Shield Advanced 以实现 DDoS 可见性和警报。

理由： 通过 OAC 和 WAF 强制所有流量经过 CloudFront，可以实施最小权限的源站访问；地理位置限制和基于速率的/WAF 保护可以阻止滥用流量；签名 URL 提供按对象的授权；而 ACM+DNS 验证与 DNSSEC 的结合，则根据 AWS 最佳实践确保了可信的 TLS 和 DNS 完整性。

AWS WAF 规则及其与 ALB 和 CloudFront 的集成

AWS WAF 是一个第 7 层防火墙，它根据由有序规则组成的 Web ACL 来评估 HTTP(S) 请求。每个规则都会检查请求属性（URI、标头、正文、查询字符串、源 IP），并返回一个终止操作（Allow、Block、Challenge、CAPTCHA）或一个非终止操作（Count）。Web ACL 可以附加到 CloudFront 分发版、Application Load Balancer、API Gateway、AppSync、Cognito 用户池和 App Runner 服务。当附加到 CloudFront 时，ACL 在边缘运行，并且必须在 us-east-1（全局）范围内创建；对于 ALB，它必须与负载均衡器位于同一区域。

基于速率的规则在五分钟的滚动窗口内跟踪来自单个 IP（或转发的 IP 标头，或聚合键，如 URI + IP 组合）的请求数量。当计数超过配置的阈值时，规则操作会触发，直到速率回落到限制以下。由于 AWS WAF 在数秒内持续更新攻击者列表，因此基于速率的规则是应对来自一小撮轮换 IP 的大流量滥用行为的经典解决方案——您不必手动维护一个 IP 集，并且在初始规则部署后，运维开销基本为零。

{
  "Name": "RateLimitPerIP",
  "Priority": 10,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimitPerIP"
  }
}

IP 集是可重用的 CIDR 范围列表，规则通过 IPSetReferenceStatement 引用它们。当您有一个确定的阻止/允许列表时——例如，有地理位置限制的管理员端点或来自威胁情报源的已知恶意范围——IP 集是正确的选择。自定义规则使用逻辑 AndStatement、OrStatement 和 NotStatement 运算符组合多个语句，让您可以表达诸如“阻止来自美国以外国家/地区且缺少特定标头的对 /login 的请求”之类的条件。

CloudFront 作为 DDoS 缓解层和源站保护

CloudFront 在 AWS 边缘吸收容量耗尽型和状态耗尽型攻击，远在流量到达您的 ALB 或 EC2 集群之前。每个边缘站点都会自动运行 AWS Shield Standard，免费提供 SYN 洪水攻击和反射攻击的缓解。将 CloudFront 置于 ALB 前方，可以将攻击面缩小到边缘网络，并启用边缘范围的 WAF、地理限制和 TLS 终止。

只有当攻击者无法通过直接访问 ALB 的 DNS 名称来绕过 CloudFront 时，这种缓解措施才有效。有两种机制可以加固此路径。首先，配置 CloudFront 注入一个秘密的自定义源站标头（例如 X-Origin-Verify: <random-value>），并配置一个 ALB 侦听器规则，对任何缺少该确切标头值的请求返回 403。通过 AWS Secrets Manager 定期轮换该秘密值。其次，将 ALB 安全组的入站规则限制为 AWS 托管的前缀列表 com.amazonaws.global.cloudfront.origin-facing，该列表包含 CloudFront 边缘的 IP 范围。

ALBListenerRule:
  Type: AWS::ElasticLoadBalancingV2::ListenerRule
  Properties:
    Actions:
      - Type: fixed-response
        FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
    Conditions:
      - Field: http-header
        HttpHeaderConfig:
          HttpHeaderName: X-Origin-Verify
          Values: ["!Ref OriginSecret"]
      - Field: http-header
        HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
    Priority: 1

如果只是将 WAF ACL 附加到 ALB 而不强制流量通过 CloudFront，会使 ALB 的终端节点可被公开解析。攻击者一旦发现该 DNS 名称（通过证书透明度日志、历史 DNS 记录或子域枚举），就可以直接攻击它，从而绕过所有边缘保护。这是“CloudFront + ALB”设计中最常见的架构错误。

Shield Advanced 指标、警报和通知

Shield Advanced 增加了增强的检测能力、7x24 小时访问 Shield 响应团队的权限、攻击期间扩展成本的保护以及应用层攻击的可见性。但是，它并不会在攻击发生时自动发送电子邮件或短信。通知必须通过 CloudWatch 进行明确配置。

Shield Advanced 在 AWS/DDoSProtection 命名空间中为每个受保护的资源发布 DDoSDetected 指标（攻击进行时值为 1）以及 DDoSAttackBitsPerSecond、DDoSAttackPacketsPerSecond 和 DDoSAttackRequestsPerSecond 指标。在 DDoSDetected >= 1 上创建一个 CloudWatch 警报，并将 SNS 主题作为警报操作；然后 SNS 会将通知分发到电子邮件、短信、聊天工具或 Lambda 响应器。

aws cloudwatch put-metric-alarm \
  --alarm-name ShieldDDoSDetected \
  --namespace AWS/DDoSProtection \
  --metric-name DDoSDetected \
  --statistic Maximum --period 60 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts

认为 Shield Advanced 会“自动给你发邮件”是一个常见的误解——如果没有配置 CloudWatch 警报和 SNS 订阅，唯一的信号来源是 Shield 控制台和 AWS Health Dashboard 事件。

使用自动化 Lambda 阻止功能的 AWS Network Firewall

Network Firewall 是一种有状态的、附加到 VPC 的第 3-7 层防火墙，用于检查穿越子网路由表的流量。其策略由无状态和有状态规则组组成；有状态规则组使用与 Suricata 兼容的语法。由于规则组是通过 API 管理的，因此它们是事件驱动自动化的理想目标。

一个常见的模式是响应 GuardDuty 的发现（例如 UnauthorizedAccess:EC2/RDPBruteForce 或 Backdoor:EC2/C&CActivity）。Security Hub 聚合该发现，EventBridge 匹配一个事件模式并调用一个 Lambda 函数，然后该 Lambda 函数调用 UpdateRuleGroup 来插入一条丢弃规则，目标是违规 IP 或受感染实例的 ENI。

def handler(event, _):
    ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
    new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
    rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
    rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
    nfw.update_rule_group(
        RuleGroupArn=RG_ARN,
        UpdateToken=rg["UpdateToken"],
        RulesSource={"RulesString": rules})

当您需要在 VPC 边缘阻止进出某个 EC2 实例或 CIDR 的双向流量时，Network Firewall 是正确的选择——WAF 仅检查发往受支持的第 7 层终端节点的 HTTP 请求，因此它无法阻止出站的 C2 流量或非 HTTP 协议。

使用 Count 进行日志记录、监控和安全部署

为每个 Web ACL 启用 WAF 日志记录，并将日志流式传输到 CloudWatch Logs、S3 或 Kinesis Data Firehose。日志包含匹配的规则、执行的操作、请求标头以及（通过编辑规则）经过脱敏处理的请求正文。控制台中的抽样请求可以提供快速概览，但每个规则仅保留最近 3 小时内的 100 个样本；完整的日志对于审计和取证是必不可少的。

Count 操作对于安全地部署规则至关重要。部署新的托管规则组（例如 AWSManagedRulesCommonRuleSet 或 Bot Control 规则组）时，应首先将规则操作覆盖设置为 Count。观察 CountedRequests CloudWatch 指标和日志条目，以发现误报——即本应被阻止的合法流量。只有在调整了排除项之后，才能将操作切换为 Block。如果在没有经过 Count 阶段的情况下直接将托管规则部署为 Block 模式，通常会导致服务中断，例如 SizeRestrictions_BODY 规则阻止了合法的大文件上传端点，或者 CrossSiteScripting_BODY 规则对富文本编辑器的负载触发了警报。补救措施不是禁用整个规则组，而是为发生误报的特定规则添加范围缩减语句或规则操作覆盖。

将 WAF 指标（BlockedRequests、AllowedRequests、CountedRequests）与 CloudWatch 警报结合使用，这样当阻止的请求突然激增——或允许的流量突然锐减时——就会通知待命工程师，从而形成从边缘防护到运营感知的闭环。

实践问题：用例场景

场景： Meridian Financial 在一个多可用区 VPC 中运行一个面向客户的 Web 应用程序，使用 Application Load Balancers (ALB) 作为 ECS 服务的前端，并通过 CloudFront 分发静态和动态内容。该团队使用 AWS WAF，但在网络层威胁的自动化处理和跨服务日志记录的一致性方面能力有限。

挑战： 最近一次容量型和应用层的流量激增攻击了登录端点，并在探测凭证填充时导致了 ALB CPU 耗尽；安全团队需要快速的 DDoS 缓解措施、一致的源站保护、自动阻止恶意 IP 以及安全地推出更严格的规则。

推荐方法：

1. 在 ALB 前端启用 CloudFront 以进行全局边缘缓解，通过验证自定义源站标头并将入站访问限制为 CloudFront 托管的前缀列表或已知 IP 范围，将 ALB 配置为仅接受来自 CloudFront 的流量。
2. 部署带有 AWS 托管规则集以及自定义的基于速率和机器人检测规则的 AWS WAFv2；将 WAF 关联到 CloudFront 分发和 ALB。初始阶段将新的自定义规则设置为 COUNT 模式以收集遥测数据。
3. 将账户注册到 AWS Shield Advanced，并关联 CloudFront 分发和 ALB；使用 Shield/DDoS 指标创建 CloudWatch 指标警报，并将警报转发到 SNS 主题，用于待命通知和运行手册触发。
4. 集中化日志：将 CloudFront、ALB、WAF 和 AWS Network Firewall 的日志流式传输到 Kinesis Data Firehose → S3，并启用 CloudWatch 指标/控制面板来监控来自 COUNT 模式的规则匹配计数。
5. 在 VPC 中部署带有状态化规则组的 AWS Network Firewall 并启用其日志记录；为可疑模式创建 CloudWatch 指标筛选器，并创建一个由警报触发的 Lambda 函数，以自动更新 Network Firewall 规则组，将被攻击的 IP 添加到拒绝列表中。
6. 在约定的观察窗口内，通过 COUNT 模式和控制面板观察流量后，将高置信度的 WAF 规则切换到 BLOCK 模式，并保持 Network Firewall 的自动更新，同时对规则组进行安全回滚和版本控制。

基本原理： 使用 CloudFront 作为边缘层，并结合 WAF 和 Shield Advanced，可提供分层的 DDoS 防护。同时，集中式日志记录、COUNT 模式的规则验证以及由 Lambda 驱动的自动化 Network Firewall 更新，提供了一种安全、可观察且自动化的网络防御方案，这与 AWS 的最佳实践相符。

← 网络与 VPC 安全 · 所有领域 · 治理、配置与自动化 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →