為什麼 SCS-C02 這麼重視邊緣安全
邊緣安全(Edge Security)是一門把防護控制推到離來源(Origin)愈遠愈好的學問——推到 AWS 全球邊緣網路上,也就是請求最初抵達的地方。在 SCS-C02 考試中,邊緣安全是 Domain 3(基礎架構安全,佔 20%)裡產值最高的主題之一,而且邊緣安全題目還會橫跨其他 Domain 出現,因為所有在 AWS 上執行的公開服務都必須先回答一個邊緣安全問題:誰可以和我的應用程式對話、從哪裡來、每分鐘幾次、透過哪個協定?
本指南從 SCS-C02 的視角深入探討邊緣安全。我們涵蓋 Amazon CloudFront 作為前門、AWS WAF 作為檢查層、AWS Shield Standard 與 Shield Advanced 作為 DDoS 層、Route 53 作為解析層,以及 Elastic Load Balancing(ALB 與 NLB)作為區域分流層。我們將每個控制項對應到 OWASP Top 10 類別、分散式阻斷服務(DDoS)攻擊向量、地理限制、速率限制、signed URLs 與 signed cookies、受管規則群組、Bot Control 以及 CAPTCHA,最後討論邊緣日誌與監控。
這不是一場產品行銷導覽,而是一趟帶著取捨觀點深入邊緣安全的旅程——正是考試所測試的那種觀點。讀完之後,你將能夠為公開網站、無伺服器應用程式和行動應用程式後端設計分層邊緣安全架構,也會清楚知道 Shield Advanced 每月 3,000 美元在什麼情境下值得、在什麼情境下不值得。
分層 Web 應用程式架構(縱深防禦)
幾乎所有 SCS-C02 邊緣安全題目的參考架構都長這樣:
Client
│
▼
Route 53 (DNS, DNSSEC, geo-routing)
│
▼
CloudFront (TLS, edge caching, OAC, signed URLs)
│
▼
AWS WAF (Web ACL, managed rules, rate-based, Bot Control)
│
▼
AWS Shield Standard / Advanced (L3/L4/L7 DDoS)
│
▼
ALB / NLB / API Gateway (regional load balancing, edge association)
│
▼
Auto Scaling Group / Lambda / ECS (compute)
│
▼
RDS / DynamoDB / S3 (data tier)
每一層執行不同的控制。邊緣安全不是單一產品——它是一個堆疊。考試最愛測試你是否理解哪個控制屬於哪一層。例如,geo-restriction 可以在 CloudFront geo-restriction 或 AWS WAF geo-match rules 兩處執行;選擇哪個取決於你是否只需要一個禮貌的 403 頁面(CloudFront),還是需要把地理條件和其他請求屬性(例如 URI 路徑或標頭)組合起來(WAF)。大規模邊緣安全的關鍵在於為正確的控制選擇正確的層。
邊緣安全是你代表來源(Origin)向公開網際網路提出的合約。所有面向公開網際網路的 AWS 服務都必須有明確的邊緣安全政策。Well-Architected Security Pillar 將此視為所有正式環境服務不可妥協的基本要求。 Source ↗
為什麼要在邊緣做縱深防禦
單一層可能失效。邊緣安全的假設是:
- DNS 可能被污染,因此我們在 Route 53 使用 DNSSEC。
- TLS 可能被降級,因此我們在 CloudFront 和 ELB 強制使用 TLSv1.2 及以上版本。
- WAF 規則可能有盲點,因此我們用 Shield 分層抵禦大流量 DDoS。
- Shield 無法阻止應用程式層濫用,因此我們在 WAF 中加入 Bot Control 和速率限制規則。
- WAF 無法修補有漏洞的程式碼,因此我們仍需持續修補和強化來源(Origin)。
每一層獨立運作。若 WAF 漏掉某個攻擊特徵,Shield 仍可吸收大流量攻擊。若 Shield 緩解了流量,CloudFront 的邊緣快取可以吸收剩餘的請求。這就是 AWS 意義上的邊緣安全。
Amazon CloudFront 作為前門
CloudFront 是 AWS 的內容交付網路(CDN),也是標準的邊緣安全入口。從 SCS-C02 的角度來看,CloudFront 同時承擔五項工作:TLS 終止、快取、將請求交給 AWS WAF 進行檢查、透過 AWS Shield 吸收 DDoS,以及透過 Origin Access Control(OAC)驗證來源身分。
TLS 終止與現代協定
CloudFront 透過安全政策支援 TLSv1.2 和 TLSv1.3。考試要求你知道,TLSv1.2_2021 及更新的安全政策是合規服務(HIPAA、PCI DSS、FedRAMP)唯一可接受的選擇。用於 CloudFront 的自訂 SSL 憑證必須從 us-east-1 的 AWS Certificate Manager(ACM)取得——這個細節是考試反覆出現的陷阱。
你附加到 CloudFront distribution 的 ACM 憑證必須在 us-east-1(北維吉尼亞)區域申請,無論你的 Origin 在哪裡。其他區域的憑證不會出現在 CloudFront 控制台中。考試最愛把一個有效的 ACM 憑證放在 eu-west-1,然後問你為什麼 CloudFront 找不到它。
Source ↗
Origin Access Control(OAC)取代 Origin Access Identity(OAI)
對於 S3 來源,現代最佳實務是使用 OAC,它利用 SigV4 來驗證 CloudFront 對 S3 的身分。OAC 支援 KMS 加密的儲存桶和跨區域儲存桶,而舊版的 OAI 無法使用 SigV4 簽署請求,在某些操作中也無法讀取使用 aws:kms 金鑰加密的物件。新的設計應一律使用 OAC。從 OAI 遷移至 OAC 有文件記載,且是常見的考題情境。
Signed URLs 與 Signed Cookies
CloudFront signed URLs 和 signed cookies 讓你無需 IAM 即可授權個別的觀看者。Signed URLs 用於單次下載(安裝程式、私人影片、PDF 報告)。Signed cookies 用於一個 Session 中需要授權多個物件的情況,例如自適應位元率影片串流。兩者都依賴一個私密金鑰,該金鑰會簽署一份描述資源、到期時間、可選的 IP 位址限制以及可選的日期時間範圍的政策。
在 SCS-C02 中,請記住 signed URLs 和 signed cookies 與 WAF 無關;它們在 CloudFront 層執行觀看者授權。它們也是「我想在沒有 IAM 憑證的情況下與外部使用者共用私人 S3 物件」這個問題的標準邊緣安全答案。
欄位層級加密
欄位層級加密(Field-Level Encryption,FLE)在 CloudFront 邊緣使用 RSA 公鑰,對 application/x-www-form-urlencoded POST 主體中最多 10 個敏感欄位進行加密。只有持有私鑰的服務才能解密這些欄位。FLE 不適合一般的 TLS 應用,但當題目說「我們無法信任中間微服務看到信用卡號碼」時,它就是正確的邊緣安全答案。
CloudFront Geo-Restriction
CloudFront geo-restriction(也稱為地理封鎖功能)是一個 distribution 層級的國家代碼允許清單或拒絕清單(ISO 3166-1 alpha-2)。它向被封鎖的觀看者回傳 403 頁面。設定簡單、免費,且在邊緣執行。
當你需要對整個 distribution 進行全面的國家封鎖時,使用 CloudFront geo-restriction。當你需要將地理條件與路徑、標頭或方法組合,或需要針對不同國家採取不同動作(Allow、Count、CAPTCHA、Block)時,使用 AWS WAF geo-match rules。 Source ↗
AWS WAF:Web ACL、規則與受管規則群組
AWS WAF 是邊緣安全的請求檢查層。它保護 CloudFront distributions、Application Load Balancers、API Gateway REST APIs、AppSync GraphQL APIs、Cognito 使用者集區、App Runner 服務和 Verified Access 執行個體。政策的基本單位是 Web 存取控制清單(Web ACL),其中包含一個有序的規則清單和一個預設動作。
Web ACL 範圍:CLOUDFRONT 與 REGIONAL
Web ACL 有一個範圍。CLOUDFRONT 範圍是全域的,無論你在哪裡運作,都在 us-east-1 建立;它只能與 CloudFront distributions 關聯。REGIONAL 範圍是每區域的,只能與區域資源(ALB、API Gateway、AppSync、Cognito、App Runner)關聯。你無法在 CloudFront distribution 和區域 ALB 之間共用一個 Web ACL;你需要部署兩個 Web ACL,並使用 AWS Firewall Manager 讓它們保持同步。
Web ACL 是 AWS WAF 的頂層政策物件。它包含一個有序的規則清單、一個預設動作(Allow 或 Block)、一個 CloudWatch 指標名稱以及一個可選的日誌目的地。每個規則都有一個優先順序;規則按優先順序評估,直到觸發終止動作為止。Web ACL 的範圍限定為 CloudFront(全域)或 REGIONAL。 Source ↗
規則陳述式與動作
每個 AWS WAF 規則都有一個陳述式(比對條件)和一個動作。陳述式包括位元組比對、SQL injection、跨站腳本攻擊(XSS)、大小限制、geo-match、IP 集、正規表示式模式集、標籤比對和速率限制。動作包括 Allow、Block、Count、CAPTCHA 和 Challenge。CAPTCHA 向觀看者顯示視覺謎題;Challenge 是一種靜默的 JavaScript 工作量證明,可在沒有使用者摩擦的情況下偵測無頭瀏覽器和機器人。
AWS 受管規則
AWS 受管規則(Managed Rules)是由 AWS 威脅研究團隊維護的精選規則群組。與邊緣安全最相關的受管規則群組是:
AWSManagedRulesCommonRuleSet(CRS)——涵蓋 OWASP Top 10 一般類別,包括 SQL injection(SQLi_BODY、SQLi_QUERYARG)和 XSS。AWSManagedRulesSQLiRuleSet——更深入的 SQL injection 防護。AWSManagedRulesKnownBadInputsRuleSet——知名漏洞利用,如 Log4Shell 和遠端程式碼執行攻擊酬載。AWSManagedRulesAmazonIpReputationList——已知機器人和威脅行為者的 IP 信譽清單。AWSManagedRulesAnonymousIpList——VPN、代理、Tor 出口節點、代管服務提供商。AWSManagedRulesBotControlRuleSet——Bot Control 通用功能。AWSManagedRulesATPRuleSet——帳號接管預防(Account Takeover Prevention,登入端點保護)。AWSManagedRulesACFPRuleSet——帳號建立欺詐預防(Account Creation Fraud Prevention,註冊表單保護)。
Bot Control、ATP 和 ACFP 是付費規則群組(每次請求另計費用);其他規則群組免費。所有受管規則群組都支援在規則層級進行覆寫(動作覆寫、範圍縮小陳述式),無需分叉。
為 SCS-C02 記住這個對應關係:
- A03:2021 Injection(SQLi)→ CRS 規則
SQLi_BODY,加上AWSManagedRulesSQLiRuleSet - A03:2021 Injection(XSS)→ CRS 規則
CrossSiteScripting_BODY - A05:2021 Security Misconfiguration →
AWSManagedRulesKnownBadInputsRuleSet - A07:2021 Authentication Failures → ATP 規則群組 + 在
/login上使用速率限制規則 - A06:2021 Vulnerable Components(Log4Shell)→
AWSManagedRulesKnownBadInputsRuleSet - Bot 濫用 →
AWSManagedRulesBotControlRuleSetSource ↗
速率限制規則:5 分鐘視窗與聚合金鑰
速率限制規則(Rate-based rules)在每個聚合金鑰(aggregate key)上以滾動的 5 分鐘視窗計算請求數。預設金鑰是來源 IP 位址,但你也可以依轉發 IP(當 CloudFront 在前方時)、標頭值(x-api-key)、查詢參數,或結合多個屬性的複合金鑰進行聚合。速率限制規則是應對憑證填充(Credential Stuffing)、爬蟲和 L7 基本 DDoS 的標準邊緣安全答案。
設定限制為 2,000 的速率限制規則代表:若單一聚合金鑰在過去 5 分鐘內超過 2,000 個請求,該規則就會觸發(Block、CAPTCHA、Challenge 或 Count)。它不會在恰好第 2,001 個請求時觸發——它會在 30 秒到一分鐘的評估延遲後觸發,考試可能用這點做為干擾選項。
範圍縮小陳述式
範圍縮小陳述式(Scope-down statement)縮小速率限制規則(或受管規則群組)的適用範圍。例如,你可能只想在 /login 上套用速率限制規則,而不是在 /static/* 上。範圍縮小陳述式是一個常規的 AWS WAF 陳述式(URI、標頭、方法),在計算速率之前先過濾流量。
標籤驅動規則
Bot Control、ATP 和多個 CRS 規則會發出標籤(例如 awswaf:managed:aws:bot-control:bot:category:scraping_framework)。Web ACL 中後續的規則可以比對這些標籤並採取不同的動作。標籤驅動規則讓你可以建立單一決策管線:「如果 Bot Control 說是已驗證的搜尋引擎,允許;如果 Bot Control 說是自動化工具且速率超過 200,封鎖;否則計數」。標籤是 SCS-C02 的最愛。
CAPTCHA 與 Challenge 動作
CAPTCHA 在觸發時向觀看者顯示謎題。成功解答後,會在 CAPTCHA 權杖 cookie 中儲存結果,有效期為設定的免疫時間(預設 300 秒)。Challenge 是靜默的:它注入 JavaScript 執行工作量證明,並儲存 Challenge 權杖。當人工互動可以接受時,CAPTCHA 是正確的邊緣安全答案;當 API 和後端呼叫不允許人工摩擦時,Challenge 是正確答案。
AWS Shield:Standard 與 Advanced
AWS Shield 是 DDoS 防護服務。考試持續測試它的兩個層級。
Shield Standard
Shield Standard 是自動的、免費的,且對每個 AWS 帳戶預設啟用。它防護常見的 L3 和 L4 DDoS,例如 SYN floods、UDP 反射和放大攻擊。它整合在 Route 53、CloudFront 和 ELB 中;你無法關閉它,也無法設定它。Shield Standard 是基礎的邊緣安全 DDoS 層。
Shield Advanced
Shield Advanced 是一個每月每個組織 3,000 美元的付費訂閱(需簽訂一年合約),額外提供:
- L3、L4 和 L7 的防護(後者透過與 AWS WAF 的緊密整合實現)。
- 基於健康狀態檢查的應用程式層 DDoS 偵測。
- 存取 AWS Shield Response Team(SRT,前身為 DRT)的權限,SRT 可在攻擊期間代你撰寫或修改 Web ACL 規則(須經你同意)。
- 費用保護:退還可歸因於 DDoS 事件的擴展費用(CloudFront 資料傳輸、ALB 容量單位、Route 53 查詢、EC2 費用)。
- 全球威脅儀表板與詳細的攻擊診斷。
- 自動應用程式層 DDoS 緩解:啟用後,Shield Advanced 可在事件期間自動在你的 Web ACL 中建立速率限制規則。
- 涵蓋 EC2/NLB 上的 Elastic IPs、AWS Global Accelerator、CloudFront、Route 53 託管區域和 ALB。
要獲得費用保護退款並與 Shield Response Team 接洽,你的 AWS 帳戶必須具備 Business Support 或 Enterprise Support。沒有這些,你仍然可以獲得 DDoS 偵測,但無法使用 SRT 通話橋接或費用保護點數。涉及 Shield Advanced 費用合理性論證的 SCS-C02 題目往往取決於這個依存關係。 Source ↗
Shield Advanced 何時是正確答案
考試會給你情境題。當以下至少兩個條件為真時,Shield Advanced 是正確的邊緣安全答案:服務是面向公開網際網路且對營收至關重要的;客戶需要 24x7 SRT 接洽;客戶需要費用保護以應對攻擊期間的擴展費用;客戶需要跨 AWS Organization 的集中可視性。如果只有一個條件為真,Shield Standard 加上 AWS WAF 速率限制規則通常就足夠了。
Route 53 安全功能
Route 53 是 AWS 邊緣安全的 DNS 層。從 SCS-C02 的角度來看,相關的 Route 53 控制項是託管區域的 DNSSEC、健康狀態檢查驅動的容錯移轉,以及地理位置路由。
託管區域的 DNSSEC
Route 53 支援公開託管區域的 DNSSEC 簽署。啟用 DNSSEC 會在 AWS KMS 中建立金鑰簽署金鑰(Key-Signing Key,KSK),並在父區域發布委派簽署者(Delegation Signer,DS)記錄。這可防止 DNS 欺騙和快取污染。對於在 Route 53 Domains 註冊的網域,DS 記錄會自動在登記機構發布;對於在外部註冊的網域,你必須在你的登記機構手動發布 DS 記錄。
Route 53 KSK 的 KMS 金鑰必須是客戶自管的非對稱金鑰(ECC_NIST_P256,用途為 SIGN_VERIFY),且必須位於 us-east-1。對稱金鑰、AWS 受管金鑰或任何其他區域的金鑰都將失敗。考試最愛這個陷阱。
Source ↗
健康狀態檢查與容錯移轉
Route 53 健康狀態檢查透過 HTTP、HTTPS 或 TCP 評估端點可及性,也可以評估 CloudWatch 警示的狀態。結合容錯移轉路由政策,Route 53 可以自動從 DNS 回應中移除不健康的端點。從邊緣安全的角度來看,這一點很重要,因為 DDoS 事件期間的健康狀態檢查失敗可以用來觸發 Shield Advanced 的應用程式層偵測。
地理位置路由
地理位置路由根據觀看者的國家(來自 EDNS Client Subnet 擴展)回應不同的 IP 位址。當你必須基於資料主權原因將特定國家的受眾保留在特定區域時,它是正確的邊緣安全答案。它本身不是一個安全控制;它必須與 WAF geo-match rules 結合才能真正封鎖流量。
邊緣負載平衡:ALB、NLB 與 API Gateway
邊緣安全在區域負載平衡器繼續運作。三種模式主導:
- L7 的 ALB(Application Load Balancer):支援 AWS WAF 關聯、監聽器規則、HTTPS 的雙向 TLS(mTLS),以及目標群組健康狀態檢查。
- L4 的 NLB(Network Load Balancer):無法直接與 WAF 關聯。在 NLB 前方使用 CloudFront,或將 WAF 移至 API Gateway。
- API Gateway:REST APIs 支援 WAF 和簽署請求;HTTP APIs 使用 Lambda 授權方和 JWT 驗證。
ALB 自 2023 年起支援 mTLS,這是 IoT 裝置、B2B 合作夥伴或車隊管理的正確邊緣安全答案,這些場景中用戶端必須使用 X.509 憑證向負載平衡器進行身分驗證。在 SCS-C02 中,ALB 的 mTLS 有時是 API Gateway 用戶端憑證的正確替代方案。
Geo-Restriction:在哪裡執行
Geo-restriction 可以在三個地方執行,各有取捨:
- CloudFront distribution 層級 geo-restriction(國家代碼允許清單或拒絕清單)——最簡單、免費、回傳 403、套用於整個 distribution。
- AWS WAF geo-match rule——靈活,可與路徑、方法、標頭組合,支援多種動作(Allow、Block、Count、CAPTCHA),可縮小範圍。
- Route 53 地理位置路由——不封鎖流量,只解析到不同的 IP;不是安全控制。
對於 SCS-C02,經驗法則是:如果需求是「封鎖來自 X 國的所有流量」,CloudFront geo-restriction 就足夠了。如果需求是「允許 X 國存取 /api/public/* 但對 /api/login 強制 CAPTCHA」,你必須使用 WAF。
速率限制:形式與模式
速率限制是 TLS 之後最常見的邊緣安全控制。AWS WAF 速率限制規則支援多種形式:
- 每個來源 IP——預設值;每個 IP 一個限制。捕捉單一 IP 濫用。
- 每個轉發 IP——當 CloudFront 在前方時,評估
X-Forwarded-For。當 WAF 在 CloudFront 後方的 ALB 上時需要使用。 - 每個聚合金鑰——標頭、查詢參數、IP、國家和標籤的複合。用於 API 金鑰速率限制。
- 每個標頭(例如
Authorization)——用於 Token 速率限制。 - 使用
RateBasedStatementCustomKey的自訂金鑰——多維度聚合。
將速率限制規則與範圍縮小陳述式配對,使限制只套用在你想要的地方。一個常見的邊緣安全模式是:/login 上每個來源 IP 100 次請求/5 分鐘,動作為 CAPTCHA;/api/* 上每個 Authorization 標頭 5,000 次請求/5 分鐘,動作為 Block;/static/* 上不限制。
OWASP Top 10 與邊緣對應
OWASP Top 10(2021 年版)是 SCS-C02 邊緣安全題目中最常被引用的威脅模型。對應到 AWS 邊緣控制:
- A01 存取控制失效——部分:物件存取使用 signed URLs/cookies;ALB 前端應用使用 ALB 驗證;精細控制使用 Verified Access。
- A02 加密失效——CloudFront 和 ALB 的 TLS 政策;ACM 憑證管理;敏感欄位使用 FLE。
- A03 注入攻擊——CRS 和 SQLi 受管規則群組;自訂正規表示式模式集。
- A04 不安全設計——超出邊緣安全範疇;在程式碼審查中處理。
- A05 安全性設定錯誤——Known Bad Inputs 規則群組;邊緣資源的 AWS Config 規則。
- A06 易受攻擊和過時的元件——Known Bad Inputs(Log4Shell、Spring4Shell);運算層的 Inspector。
- A07 身分驗證與授權失效——ATP 規則群組;
/login上的速率限制規則;Cognito MFA。 - A08 軟體與資料完整性失效——程式碼簽署;CloudFront signed URLs。
- A09 安全記錄與監控失效——WAF 日誌至 S3/Firehose/CloudWatch;CloudFront 存取日誌;Shield Advanced 指標。
- A10 伺服器端請求偽造(SSRF)——來源端的 IMDSv2;不直接是邊緣控制。
對於 SCS-C02,A03 和 A07 是產值最高的邊緣控制,因為它們完全可以用 AWS WAF 解決。考試很少問 A04,因為那是程式碼問題。
DDoS 分層防禦實戰
真實世界的 DDoS 防禦劇本結合了所有層:
- L3/L4 大流量(UDP flood、SYN flood)——Shield Standard 在邊緣自動吸收。CloudFront、Global Accelerator 和 Route 53 是具有大量聚合容量的 anycast 網路。
- L7 HTTP flood(GET flood)——CloudFront 快取吸收可快取的流量;AWS WAF 速率限制規則封鎖不可快取的熱點請求;Bot Control 標籤識別有組織的機器人群。
- L7 複雜攻擊(low-and-slow、slowloris)——Shield Advanced 應用程式層緩解,加上 ALB 連線閒置逾時調整。
- 反射與放大攻擊——邊緣的 Shield Standard 在網路邊界封鎖。
CloudFront 在 DDoS 期間的首要任務是在邊緣吸收可快取的請求。確保來源(Origin)上的 Cache 標頭設定正確,讓 CloudFront 能夠從快取提供服務,而不是將請求轉發到 Origin。「我們即使使用了 CloudFront 仍在遭受 DDoS 攻擊」的首要原因,是 Origin 每個回應都帶有 Cache-Control: no-store。
Source ↗
邊緣日誌與監控
看不到就無法防禦。邊緣日誌是 SCS-C02 考試中 Domain 2 與 Domain 3 的重疊區域。
CloudFront 存取日誌
CloudFront 將每個請求的存取日誌寫入 S3 儲存桶(標準日誌,幾分鐘內近即時)或寫入 CloudWatch Logs 和 Kinesis Data Streams(即時日誌,毫秒級延遲)。標準日誌免費;即時日誌按每行日誌計費,但允許串流 SIEM 整合。在 SCS-C02 中,當需求是「攻擊發生後 60 秒內發出警示」時,即時日誌是正確的邊緣安全答案。
AWS WAF 日誌
AWS WAF 可以記錄到三個目的地:S3 儲存桶(透過 Kinesis Data Firehose)、Amazon CloudWatch Logs,或 Kinesis Data Firehose 到自訂目的地。每行日誌包含比對的規則、動作、標籤和(截斷的)請求。控制台中的取樣請求與完整日誌不同——取樣請求只是用於診斷目的的樣本。考試會問哪個目的地支援哪個功能;記住 S3 透過 Firehose 是合規保留最具成本效益的選擇。
Shield Advanced 指標與日誌
Shield Advanced 在 CloudWatch 中提供應用程式層 DDoS 指標,並在偵測到或緩解攻擊時在 EventBridge 上發出事件。全球威脅儀表板顯示整個 AWS 網路的攻擊模式。與 Shield Response Team 的接洽透過 AWS Support Center 進行;SRT 可以在事件期間審查你的 Web ACL。
Firewall Manager 集中管理
AWS Firewall Manager 跨 AWS Organization 套用 WAF Web ACLs、Shield Advanced 防護、安全群組基準線、Network Firewall 政策和 DNS Firewall 規則。在 SCS-C02 中,當需求是「在 12 個帳戶的 200 個 ALB 上強制執行 WAF 速率限制規則」時,Firewall Manager 是正確的邊緣安全答案。Firewall Manager 需要 AWS Organizations 和一個啟用了 AWS Config 的成員帳戶。
白話文解釋
Edge security 聽起來很抽象,我們用三個台灣日常生活的類比來說明,挑你最有感覺的那個記住即可。
類比一:機場海關(多層防線)
把你的 AWS 應用想像成桃園國際機場,每一個進來的旅客就是一個 HTTP request。Edge security 就是從入境大廳到行李轉盤之間所有的管制關卡:
- 護照查驗台(Route 53 DNSSEC):確認旅客持有真實文件,沒人能偽造你的地址讓訪客迷路到假機場。
- X 光機與安全掃描器(AWS WAF 受管規則群組 CRS、SQLi、XSS):行李裡藏了危險物品(惡意 Payload)就在這裡攔下。
- 海關人員詢問可疑旅客(Bot Control + CAPTCHA):一看就是機器人行為,就讓你填驗證碼或直接請出去。
- 機場保全快速反應部隊(Shield Advanced SRT):有人想衝卡,立刻出動處理緊急狀況。
- 機場整棟建築的防彈結構(Shield Standard):就算有一萬個人同時衝大門(DDoS L3/L4),建築本身不會垮。
- 特定國籍不發登機證(CloudFront geo-restriction):台灣入境規定說不行的國籍,連進來排隊的機會都沒有。
- 同一個旅客五分鐘內試圖過安檢十次(rate-based rule):直接請到小房間好好談談。
每一層獨立運作、缺一不可。X 光機沒發現炸彈,海關還能盤問;海關也漏了,保全還能即時反應。WAF 規則漏掉某個 0-day,Shield 仍可擋住流量;Shield 擋住量,CloudFront 快取還能吸收剩餘請求。
類比二:保全大樓門禁(縱深管制)
想像 CloudFront 是頂級辦公大樓的警衛室,AWS WAF 是各樓層的門禁刷卡機,Shield 是大樓的鋼筋混凝土結構,Route 53 是大樓地址簿。
- 警衛室(CloudFront)驗查訪客身分證(TLS 憑證)、發臨時通行證(signed URL)、把常客的需求提前備好(cache)。
- 門禁刷卡機(WAF)只讓有授權的員工進對應樓層,外送員只能在一樓等候,列入黑名單的地址直接拒絕(geo-match)。
- 鋼筋混凝土結構(Shield)讓你不怕突發衝擊,就算有幾千個假裝送貨的人同時堵在大廳(DDoS),大樓本身不會倒。
- 地址簿(Route 53 + DNSSEC)確保沒人偷改你大樓的門牌,把客戶導去隔壁山寨辦公室。
當有人瘋狂按一百次對講機騷擾住戶(credential stuffing),警衛室啟動限速規則(rate-based rule),第一百零一次直接斷線。
類比三:夜市入口安檢(白名單與黑名單)
把 AWS WAF 的 Web ACL 想成夜市入口的保全安檢規則手冊。每位客人(HTTP 請求)走進來,保全依序對照手冊:
- 規則一:持本地身分證(geo-match allow),歡迎入場。
- 規則二:包包裡藏著奇怪的工具(SQL injection 特徵),當場請出去。
- 規則三:同一個人五分鐘內來闖了三十次(rate-based),請離開並暫列觀察名單。
- 規則四:穿著像正常遊客但動作像機器(Bot Control label),請先填驗證碼(CAPTCHA)再進去。
- 規則五(default):以上都沒中,請進,好好逛。
受管規則群組(managed rule groups)就是 AWS 預先整理好的「夜市常見違規行為清單」,CRS 是通用版,SQLi 是專門對付那種把危險物品藏在滷味裡的客人。Shield 則是夜市廣場本身的鋼筋水泥結構,颱風(DDoS)來的時候,整個場子還撐得住。Edge security 就是這份手冊加上鋼筋水泥的完整戰力。
三種常見服務類型的邊緣安全設計
SCS-C02 考試指南明確提及三種服務類型。以下說明每種類型的邊緣安全堆疊有何不同。
公開網站(行銷網站或電子商務)
- CloudFront distribution,使用
TLSv1.2_2021安全政策,以及us-east-1的 ACM 憑證。 - AWS WAF Web ACL,包含 CRS、IP Reputation、Anonymous IP、Known Bad Inputs。
/checkout/*上依Authorization標頭聚合的速率限制規則。- Bot Control 通用功能用於爬蟲防護。
- Shield Standard 預設包含;若網站對營收至關重要則使用 Shield Advanced。
- Route 53 在頂點網域啟用 DNSSEC。
- CloudFront 存取日誌至 S3,保留週期 1 年。
無伺服器應用程式(API Gateway + Lambda)
- API Gateway REST API(或為節省成本使用 HTTP API),配備自訂網域和 ACM 憑證。
- API Gateway stage 上的 AWS WAF Web ACL;受管規則包含 CRS + Known Bad Inputs。
- 依
x-api-key標頭的速率限制規則;API Gateway usage plans 的節流配額。 - 用於 Token 驗證的 Lambda 授權方;用於使用者層級驗證的 Cognito 使用者集區授權方。
- API Gateway 上的 Shield Standard(免費);若 API 至關重要則使用 Shield Advanced。
- WAF 日誌至 Kinesis Firehose 再至 S3。
行動應用程式後端
- CloudFront 在 ALB 或 API Gateway 前方,用於全球 TLS 終止和 DDoS 吸收。
- AWS WAF,在
/login使用 ATP 規則群組,在/signup使用 ACFP 規則群組。 - ALB 的雙向 TLS(mTLS)用於裝置綁定憑證(高保證),或在 Lambda 授權方進行 App Attest / Play Integrity 驗證。
- Bot Control 目標功能用於用戶端挑戰。
- Cognito 使用者集區啟用 MFA 用於終端使用者身分。
- WAF 和 CloudFront 即時日誌透過 Kinesis 傳送至 SIEM。
常見考試陷阱與反模式
AWS WAF 無法與 Network Load Balancer 關聯。NLB 只有 L4,沒有 HTTP 請求的概念讓 WAF 進行檢查。如果題目將 WAF 放在 NLB 上,那是錯誤的。NLB 前端應用的正確邊緣安全模式是在 NLB 前方部署 CloudFront,並在 CloudFront distribution 上套用 WAF。 Source ↗
其他需要避免的常見反模式:
- 將 ACM 憑證放在
eu-west-1供 CloudFront 使用(必須是us-east-1)。 - 忘記 Web ACL 範圍必須與資源類型相符(CLOUDFRONT 對應 REGIONAL)。
- 期望 Shield Standard 緩解 L7 DDoS——它做不到。
- 當需要基於路徑的例外時仍依賴 CloudFront geo-restriction。
- 對新的 S3 來源使用 OAI 而不是 OAC。
- 在靜態資源路徑上設定速率限制規則卻沒有範圍縮小,導致快取命中的請求淹沒該規則。
常見問答
Q1:邊緣安全上何時應選擇 Shield Advanced 而非 Shield Standard?
當以下至少兩個條件為真時,Shield Advanced 是合理的選擇:服務對營收至關重要、客戶需要 24x7 SRT 接洽、客戶需要費用保護以應對 DDoS 期間的擴展費用,或客戶必須透過 Firewall Manager 跨 AWS Organization 集中管理防護。每月 3,000 美元的定價加上必備的 Business 或 Enterprise Support,意味著 Shield Advanced 很少適合非營收或內部服務。
Q2:Geo-Restriction 應在 CloudFront 還是 AWS WAF 執行?
當需求是對整個 distribution 進行全面的國家封鎖時,使用 CloudFront distribution 層級 geo-restriction。當需求將地理條件與路徑、方法或標頭結合,或需要針對不同國家採取不同動作(Allow、Block、CAPTCHA、Challenge、Count)時,使用 AWS WAF geo-match rules。WAF geo-match 也提供僅計數模式,讓你在執行前先觀察影響。
Q3:AWS WAF 能阻止 OWASP A01 存取控制失效嗎?
只有部分能力。WAF 可以在 CloudFront 邊緣執行 signed URL 或 signed cookie 規則,並且可以對未驗證的路徑進行速率限制以減緩列舉攻擊。真正的存取控制是程式碼層面的問題,屬於應用程式授權方(Lambda 授權方、Cognito、IAM 授權方或 Verified Permissions)的職責範圍。在 SCS-C02 中,「阻止存取控制失效」的正確答案很少單獨指向 WAF。
Q4:AWS WAF 中 CAPTCHA 與 Challenge 動作的差異是什麼?
CAPTCHA 向觀看者顯示一個可見的謎題,必須解答;成功後建立一個 CAPTCHA 權杖 cookie,有效期為設定的免疫時間。Challenge 是一個靜默的 JavaScript 工作量證明,在觀看者的瀏覽器中執行;成功後建立一個 Challenge 權杖。當人工互動可以接受時(登入、註冊),使用 CAPTCHA。對於 API 端點和後端呼叫,在偏好無感知驗證的情況下,使用 Challenge。兩者都會產生每次請求的額外費用。
Q5:Shield Advanced 費用保護實際上如何運作?
當 AWS Shield 偵測到受防護資源遭受 DDoS 事件,且該事件造成擴展相關費用增加(CloudFront 資料傳出、Route 53 查詢、ALB 容量單位、EC2 小時數)時,你可以透過 AWS Support 提交點數申請。AWS 會在其偵測系統中審查攻擊特徵,並針對可歸因於攻擊的增量費用發放服務點數。費用保護需要 Business 或 Enterprise Support,以及在事件發生時該資源上已有效的 Shield Advanced 訂閱。
Q6:AWS WAF 日誌與 CloudFront 存取日誌相同嗎?
不同。AWS WAF 日誌記錄每個請求的檢查結果,包括比對的規則、動作和標籤——它們回答「WAF 是否封鎖了這個請求,為什麼?」CloudFront 存取日誌記錄 distribution 上的每個觀看者請求——它們回答「邊緣提供了什麼?」要獲得完整的邊緣安全可視性,兩者都需要。WAF 日誌傳送至 S3(透過 Firehose)、CloudWatch Logs 或自訂 Firehose 目的地。CloudFront 標準日誌直接傳送至 S3;即時日誌傳送至 Kinesis Data Streams。
Q7:我可以在 CloudFront distribution 和 ALB 之間共用一個 Web ACL 嗎?
不行。Web ACL 範圍是二元的:CLOUDFRONT 範圍的 Web ACL 只能附加到 CloudFront distributions;REGIONAL 範圍的 Web ACL 只能附加到區域資源(ALB、API Gateway、AppSync、Cognito、App Runner、Verified Access)。若要在兩者上執行相同的邊緣安全政策,建立兩個 Web ACL,並使用 AWS Firewall Manager 跨 AWS Organization 保持它們同步。
總結:邊緣安全答題模式
當你閱讀 SCS-C02 邊緣安全題目時,逐一檢查這份清單:
- 有公開流量嗎?→ 在前方放 CloudFront,毫無疑問。
- 需要 L7 檢查(SQLi、XSS、OWASP)嗎?→ AWS WAF 搭配受管規則。
- 服務對營收至關重要且有 24x7 SLO 嗎?→ Shield Advanced。
- 需要 geo-restriction 嗎?→ 全面封鎖用 CloudFront;精細控制用 WAF。
- 需要速率限制嗎?→ WAF 速率限制規則搭配範圍縮小。
- 有機器人濫用的疑慮嗎?→ Bot Control + ATP/ACFP 用於高價值表單。
- 需要跨帳戶集中管理嗎?→ Firewall Manager。
- 需要即時警示嗎?→ CloudFront 即時日誌 + WAF 日誌傳送至 CloudWatch。
AWS 上的邊緣安全不是魔法。它是一個紀律嚴明的控制堆疊——DNS、TLS、請求檢查、DDoS 吸收、速率限制、機器人防禦和集中可視性——你針對每個服務進行組合。掌握各層及其之間的取捨,SCS-C02 的邊緣安全題目就會變得可以預測。祝你考試順利。