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 的每個請求成本時，請選擇原生的地理限制。

用於私有內容的 Signed URL 與 Signed Cookie 比較

CloudFront 支援兩種方式來提供經授權的私有內容，同時將源站（S3 儲存貯體、ALB 或媒體源站）隱藏在 origin access control 或自訂標頭之後：

• Signed URL： 每個 URL 都帶有簽章和政策。適合單一檔案下載，或當您需要每個檔案的存取控制時（例如，一次性的軟體安裝程式連結）。

• Signed cookie： 客戶端從您的驗證服務一次性地收到 CloudFront-Policy、CloudFront-Signature 和 CloudFront-Key-Pair-Id 這組 cookie。所有後續對符合路徑模式的請求都會自動獲得授權，無需重寫 URL。

對於 HLS 影片串流，單次播放就會根據 manifest 檔案擷取數千個 .ts 片段，使用 signed cookie 會簡單得多。在 manifest 中為每個片段 URL 重寫一個獨立的 signed URL 是可行的，但會增加延遲和複雜性。在訂閱者對您的內部使用者儲存區進行身份驗證後，設定 cookie，並將其範圍限定在串流路徑模式。

一個用於萬用字元 signed cookie 的標準政策如下所示：

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

將此與 origin access control (OAC) 或在源站由 WAF 驗證的秘密自訂標頭配對使用，這樣使用者就無法繞過 CloudFront 直接存取源站。

AWS WAF：受管規則、ATP 與基於速率的規則

當工作負載位於 CloudFront 後方時，應將 Web ACL 附加到 CloudFront distribution，而不是區域性的 ALB。附加在邊緣可以在數百個 POPs 中的一個終止惡意請求——這離攻擊者更近——從而減少 DDoS 期間的源站負載，並降低源站的出口流量，因為被封鎖的流量永遠不會進入您的 VPC。若只將 WAF 附加到 ALB，意味著大量流量攻擊仍會到達區域性負載平衡器並消耗 LCU，且跨區域的攻擊是由單一區域處理，而非由全球邊緣網路處理。

要結合的關鍵規則群組：

• AWS 受管規則集： AWSManagedRulesCommonRuleSet (OWASP top-10 風格)、AWSManagedRulesKnownBadInputsRuleSet 和 AWSManagedRulesAmazonIpReputationList 提供了廣泛的保護，幾乎無需調整。

• 帳戶盜用防護 (ATP)： AWSManagedRulesATPRuleSet 會檢查您指定的登入端點、追蹤憑證填充攻擊模式、將提交的憑證與外洩憑證資料庫進行比對，並封鎖重複使用外洩密碼的機器人。設定時需提供確切的登入路徑以及使用者名稱和密碼的 JSON 本文欄位名稱。

• 基於速率的規則： 在 5 分鐘的視窗內，限制來自任何單一 IP 的請求數量（例如 2,000 個請求）。可依 URI 或方法限定其範圍，這樣對 /search 的爬取就不會影響對 / 的匿名瀏覽。速率規則可緩解第七層的大量流量攻擊和暴力列舉攻擊。

一個精簡的 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 (N. Virginia) 的 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 功能。將受管或自訂的政策附加到快取行為 (cache behavior) 上，以新增 HSTS、CORS、安全性及自訂標頭。這應該是預設的選擇——無需程式碼、沒有冷啟動、也沒有每次調用的成本。

• Lambda@Edge (檢視者回應或來源回應)： 當您需要動態邏輯時使用，例如根據請求屬性變化 CSP nonces 或重寫標頭。這犧牲了簡易性以換取靈活性，並增加了每次請求的成本。

受管的回應標頭政策 SecurityHeadersPolicy 只需一次附加，即可涵蓋常見的基準線。

常見陷阱解析

使用電子郵件驗證來申請公開的 ACM 憑證是脆弱的，這正是因為續約依賴於人類去讀取那些多數組織不會監控或會轉到垃圾郵件的通用地址郵件。透過 Route 53 進行 DNS 驗證則完全移除了人為環節。

將 WAF 僅附加到 ALB 在紙面上看起來是等效的，但這會迫使攻擊流量進入您的 Region 並消耗 ALB 的容量。附加在 CloudFront 上的邊緣 WAF 會在全球數百個 POPs 進行阻擋，因此分散式洪水攻擊會被全球性地吸收，且來源的輸出流量保持在低水平——這在 DDoS 期間至關重要。

假設 CloudFront 會自動新增安全性標頭會導致滲透測試失敗。該分發會代理來源傳送的任何標頭；您必須明確地附加一個回應標頭政策或 Lambda@Edge 函數來注入 X-Frame-Options: DENY、HSTS 和 CSP。

實務問題：使用案例情境

情境： Meridian Financial 在 AWS 上運行一個全球分佈的客戶入口網站和一個內部報告入口網站。公開流量透過 Amazon CloudFront 路由到 Application Load Balancer 以處理動態 API，並路由到 S3 來源以提供私密報告；DNS 位於 Route 53 中，TLS 憑證由 AWS Certificate Manager (ACM) 簽發。

挑戰： 攻擊者正從數個國家爬取資料和進行帳號的憑證填充攻擊，他們繞過 CloudFront 直接攻擊來源端點來下載私密報告，導致來源過載和資料外洩。

建議方法：

1. 將 CloudFront 設定為唯一的公開進入點，並應用 CloudFront 地理位置限制 (Geo Restriction) 來阻擋有攻擊行為的國家；啟用 Origin Access Control (OAC) 並鎖定 S3/ALB 來源政策，以便只有 CloudFront 能夠擷取來源內容。
2. 使用 CloudFront 簽章 URL (短 TTL) 來提供每個使用者的私密報告，而不是使用簽章 Cookie，這樣每次下載都經過個別授權且可稽核。
3. 將 AWS WAF 附加到 CloudFront distribution，使用 AWS Managed Rules，啟用 AWS WAF Bot Control (進階威脅防護)，並建立基於速率的規則以及 CAPTCHA 挑戰，以緩解爬取和憑證填充攻擊。
4. 在 ACM 中（對於 CloudFront distribution 需在 us-east-1）使用 Route 53 的 DNS 驗證來佈建 TLS 憑證，並將 Route 53 Alias 記錄發佈到 CloudFront distro。
5. 在 Route 53 託管區域上啟用 DNSSEC，啟用 CloudFront 和 WAF 的存取日誌到 S3，並建立 CloudWatch 警報和選用的 AWS Shield Advanced 以提供 DDoS 的可見性和警示。

理由： 透過 OAC 和 WAF 強制所有流量通過 CloudFront，可實施最小權限的來源存取；地理位置限制和基於速率/WAF 的保護可阻止濫用流量；簽章 URL 提供對每個物件的授權；而使用 DNSSEC 的 ACM+DNS 驗證則確保了符合 AWS 最佳實踐的可信賴 TLS 和 DNS 完整性。

AWS WAF 規則及其與 ALB 和 CloudFront 的整合

AWS WAF 是一個第 7 層防火牆，它會根據由排序規則組成的 Web ACL 來評估 HTTP(S) 請求。每個規則會檢查請求屬性（URI、標頭、內文、查詢字串、來源 IP），並回傳一個終止動作（Allow、Block、Challenge、CAPTCHA）或一個非終止動作（Count）。Web ACL 可附加到 CloudFront distribution、Application Load Balancer、API Gateway、AppSync、Cognito 使用者集區以及 App Runner 服務。當附加到 CloudFront 時，ACL 會在邊緣運行，且必須在 us-east-1 (Global) 範圍內建立；對於 ALB，則必須與負載平衡器位於相同的 Region。

基於速率的規則會追蹤在一個滾動的五分鐘視窗內，來自單一 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 集 (IP sets) 是可重複使用的 CIDR 範圍列表，可由規則透過 IPSetReferenceStatement 引用。當您有一個確定的封鎖/允許清單時——例如，地理位置受限的管理端點或來自威脅情資來源的已知惡意範圍——它們是正確的基礎元件。

自訂規則使用邏輯運算子 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 增加了增強的偵測能力、全年無休的 Shield Response Team 支援、攻擊期間擴展資源的成本保護，以及應用程式層攻擊的可見性。然而，當攻擊發生時，它不會自動發送電子郵件或簡訊。通知必須透過 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 事件。

AWS Network Firewall 搭配自動化 Lambda 封鎖

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 指標和日誌項目，以找出誤報（false positives）——即那些本來會被封鎖的合法流量。只有在調整排除項目後，才將動作切換為 Block。若未經 Count 階段就直接將受管規則部署為 Block，通常會導致服務中斷，例如當 SizeRestrictions_BODY 規則封鎖了合法的大型上傳端點，或 CrossSiteScripting_BODY 規則對富文本編輯器的酬載觸發時。補救措施不是停用整個群組，而是為特定誤觸的規則新增一個範圍縮減陳述式（scope-down statement）或規則動作覆寫。

將 WAF 指標（BlockedRequests、AllowedRequests、CountedRequests）與 CloudWatch 警報配對，如此一來，當封鎖請求突然飆升——或允許流量突然崩潰——就會呼叫值班工程師，從而形成邊緣保護與營運感知之間的閉環。

實務問題：使用案例情境

情境： Meridian Financial 在一個多可用區 (multi-AZ) VPC 中運行一個面向客戶的 Web 應用程式，使用 Application Load Balancers (ALBs) 作為 ECS 服務的前端，並透過 CloudFront 分發靜態和動態內容。該團隊使用 AWS WAF，但對於網路層威脅的自動化有限，且各服務的記錄不一致。

挑戰： 最近一次針對登入端點的容量攻擊和應用層流量高峰，導致 ALB CPU 耗盡，同時還在探測憑證填充 (credential stuffing)；資安團隊需要快速的 DDoS 緩解、一致的來源保護、自動封鎖惡意 IP，以及安全地推出更嚴格的規則。

建議方法：

1. 在 ALB 前端啟用 CloudFront 以進行全球邊緣緩解，設定 ALB 只接受來自 CloudFront 的流量，方法是驗證一個自訂的來源標頭，並使用 CloudFront 管理的前綴列表或已知的 IP 範圍來限制傳入存取。
2. 部署 AWS WAFv2，搭配使用 AWS 受管規則集以及自訂的基於速率和機器人偵測規則；將 WAF 附加到 CloudFront 分發和 ALB。初期將新的自訂規則設定為 COUNT 模式以收集遙測資料。
3. 將帳戶註冊到 AWS Shield Advanced 並關聯 CloudFront 分發和 ALB；使用 Shield/DDoS 指標建立 CloudWatch 指標警報，並將警報轉發到 SNS 主題，以進行值班通知和觸發應變手冊 (runbook)。
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 →