examhub .cc 用最有效率的方法,考取最有價值的認證
Vol. I
本篇導覽 約 32 分鐘

工作負載與應用程式保護

6,400 字 · 約 32 分鐘閱讀

AWS 上的應用程式安全,是一組受管 AWS 服務的集合,分別部署在工作負載的前方周圍內部,用來阻擋網路攻擊、偵測威脅、驗證使用者身分,並確保機密憑證不外洩至原始碼中。在 SAA-C03 考試中,你必須知道哪個 AWS 服務解決哪種問題:AWS WAF 對應 HTTP 層攻擊、AWS Shield 對應大量封包與協定型 DDoS、AWS Firewall Manager 對應跨多個 AWS 帳號的集中式政策管理、Amazon GuardDuty 對應智慧型威脅偵測、Amazon Cognito 對應終端使用者驗證,以及 AWS Secrets Manager / AWS Systems Manager Parameter Store 對應憑證儲存。應用程式安全是 VPC 網路安全主題的 Task 1.2 對應項目,在 SAA-C03 情境題中大約每十題就有一題與此相關。

SAA-C03 的 Domain 1 佔總分 30%,應用程式安全是其中情境題最多的子主題之一。你會看到像這樣的描述:「保護公開網頁應用程式免受 SQL injection 攻擊」、「緩解針對 CloudFront 發行版的大量 DDoS 攻擊」、「偵測遭入侵的 EC2 執行個體」、「讓手機 App 使用者以 Google 帳號登入」,或者「在應用程式程式碼以外存放資料庫密碼」。每個描述都明確對應到某一個 AWS 應用程式安全服務——本指南教你在考場上立即完成這個對應。

什麼是 AWS 上的應用程式層安全?

AWS 應用程式安全保護的是工作負載中位於網路層之上的部分:使用者發送的 HTTPS 請求、微服務發出的 API 呼叫、應用程式啟動時載入的憑證、客戶看到的登入畫面。網路層安全(安全群組、網路 ACL、NAT gateway)依 IP 位址與連接埠過濾流量;應用程式安全則依 HTTP 方法、URL 路徑、SQL 關鍵字、TLS 憑證、OAuth token,或行為異常來過濾流量。

AWS 應用程式安全服務可分為四大類,你必須能夠背誦:

  • 請求層邊緣防護 — AWS WAF 過濾 HTTP/HTTPS 請求;AWS Shield 吸收 DDoS 洪流;AWS Firewall Manager 在多個 AWS 帳號間統一執行 WAF 與 Shield 政策。
  • 威脅偵測與回應 — Amazon GuardDuty 關聯 AWS CloudTrail、VPC Flow Logs、DNS 日誌及 Amazon EKS 稽核日誌,標記遭入侵的資源;Amazon Macie 探索 Amazon S3 中的敏感資料;AWS Security Hub 彙整各項發現結果。
  • 面向客戶應用程式的身分管理 — Amazon Cognito 為你的終端使用者提供註冊、登入及聯合身分驗證功能(注意:不適用於內部員工——員工身分管理屬於 AWS IAM Identity Center 的範疇)。
  • 機密與憑證管理 — AWS Secrets Manager 儲存並自動輪換憑證;AWS Systems Manager Parameter Store 儲存明文與加密的組態設定。
  • AWS WAF:受管 Web 應用程式防火牆,可在 Amazon CloudFront、Application Load Balancer、Amazon API Gateway、Amazon Cognito、AWS App Runner 及 AWS Verified Access 上檢查 HTTP/HTTPS 請求。
  • AWS Shield:AWS DDoS 防護服務;Shield Standard 自動啟用且免費,Shield Advanced 為付費訂閱並提供進階防護。
  • Amazon GuardDuty:智慧型威脅偵測服務,分析日誌並產生具有「低/中/高」嚴重性的發現結果。
  • Amazon Cognito:為應用程式終端使用者提供身分管理;使用者集區(user pools) 負責驗證(目錄),身分集區(identity pools) 負責授權存取 AWS 資源(聯合身分)。
  • AWS Secrets Manager:專屬機密儲存服務,具備自動輪換功能。
  • Reference: https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html

為什麼應用程式安全對 SAA-C03 很重要

SAA-C03 的應用程式安全題目幾乎都是情境題:「你的網頁應用程式持續遭受 SQL injection 攻擊——哪個 AWS 服務可以阻擋?」、「你的公開網站遭遇大規模 SYN flood——哪個 AWS 服務是為此設計的?」、「你的手機 App 使用者以 Google 登入——哪個 AWS 服務管理身分集區?」。每個正確答案都是一個 AWS 服務名稱,而每個干擾選項則是聽起來相似的鄰近 AWS 服務。精確掌握每個應用程式安全 AWS 服務的適用範圍,是提升 Domain 1 應用程式安全題分數最有效的方法。

白話文解釋 Application Security

將應用程式安全詞彙對應到具體的生活場景,記憶效果更好。以下三個類比涵蓋了 SAA-C03 所有主要的應用程式安全概念。

類比一:夜市攤位的三層安全機制

想像台灣夜市在假日夜晚的景象。AWS Shield攤位外圍的鐵馬護欄和糾察隊,當數千人同時湧入試圖衝進攤區時,他們吸收人潮壓力、防止踩踏事故——對應大規模的 DDoS 洪流。AWS WAF入口處的驗票員,逐一核查每位訪客的身分和規定(太年輕?穿著不符規定?帶了噴漆?),不符合的一律拒於門外——對應逐一檢查 HTTP 請求內容。Amazon GuardDuty便衣安全主任,在攤區內巡邏,注意到那個反覆溜進員工區的客人、3 分鐘內用盜刷信用卡買了 40 杯飲料的人,以及 ID 符合業界黑名單的訪客,即時向團隊回報並升級處理。夜市需要這三層:Shield 擋人潮、WAF 管入口、GuardDuty 顧場內。少了任何一層,那個類別的攻擊就沒有防禦。

AWS Firewall Manager連鎖夜市的總部管理處,將同一套驗票規則推送到全台 47 個夜市據點,只要某城市出現新的偽造票券,隔天一早所有據點都會更新拒絕清單。

類比二:飯店房卡系統

大型連鎖飯店的房卡系統完美對應 Amazon Cognito 與憑證服務。櫃台接待人員就是 Amazon Cognito 使用者集區——他們核對你的訂房紀錄、驗證身分、要求輸入 PIN 碼(MFA),然後發給你一張房卡。這張房卡證明你是誰(驗證)。但房卡本身無法開啟行政貴賓廳、游泳池或停車場——必須個別授權才行。第二層就是 Amazon Cognito 身分集區——它接收你的房卡(使用者集區 token,或 Google/Apple/Facebook 登入 token),並發給你可存取應用程式允許使用之特定 AWS 資源的短期憑證。透過 Hosted UI社群登入,就像飯店接受合作航空公司的常旅客卡,免去你重新登記的麻煩——Amazon Cognito 可聯合 Google、Apple、Facebook、Amazon,或任何 OIDC/SAML 提供者。

AWS Secrets Manager飯店後台辦公室的保險箱——它儲存主 Wi-Fi 密碼、房務系統的資料庫憑證和航空公司 API 金鑰。員工不會把這些寫在便利貼上;他們在需要時從保險箱取出,用完歸還。保險箱還會定期自動換鎖,就算前任員工記住了舊密碼,過期後也無法使用。AWS Systems Manager Parameter Store員工休息室的白板——記錄著「早餐供應時間 7–10 點」這類非敏感組態,另有一個小型上鎖格子偶爾存放密碼,但它不會自動輪換任何東西。

類比三:機場的安全防護層次

一座國際機場的層層防禦,完全對應你在 AWS 應用程式前面部署的各個安全服務。AWS Shield Standard機場外圍的圍欄和防車輛衝撞護欄——永遠開啟、從不另收費用,無需任何設定就能阻擋明顯的大規模攻擊。AWS Shield Advanced全天候待命的反恐特勤小組——需支付委任費用,有專屬應變團隊(AWS Shield Response Team),提供費用保護保險,並與 AWS WAF 整合以建立客製化攻擊規則。AWS WAF安檢通道——每件隨身行李(HTTP 請求)都要通過 X 光機(規則手冊:managed rule groups,涵蓋 SQL injection 和 XSS 等常見攻擊模式,加上自訂規則);危險物品遭到阻擋,通過的才能繼續前行。Rate-based rules登機門地勤人員,發現同一個人在 20 分鐘內試圖搭乘 14 班航班,立刻將其攔下。

Amazon GuardDuty機場警察分析室,關聯航班名單、監視器畫面和監控名單——對每筆發現結果標記低/中/高嚴重性,讓第一線人員判斷是派巡邏警員還是特勤部隊出動。

考試當天,當題目出現「DDoS 防護」,就想起夜市外圍的護欄和糾察隊(Shield)。當出現「SQL injection」或「封鎖特定國家的請求」,就想起安檢通道(WAF)。當出現「偵測遭入侵的 EC2 執行個體」,就想起機場警察分析室(GuardDuty)。Reference: https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html

AWS WAF — Web ACL 規則、速率限制與 Managed Rule Groups

AWS WAF(Web Application Firewall)根據一組規則檢查傳入的 HTTP 和 HTTPS 請求,對每個請求執行允許、封鎖、計數或質詢的動作。AWS WAF 可部署在六個 AWS 整合點:Amazon CloudFront 發行版Application Load BalancerAmazon API Gateway REST APIAWS AppSync GraphQL APIAmazon Cognito 使用者集區,以及 AWS App Runner 服務(另加 AWS Verified Access)。這份清單很重要——AWS WAF 無法附加到 Network Load Balancer,這是 SAA-C03 常見陷阱之一。

Web ACL 與規則

Web ACL(Web 存取控制清單)是你附加到受保護資源的 AWS WAF 政策物件。在 Web ACL 內可新增規則,規則分為三種:

  • 一般規則(Regular rules) — 靜態條件,用來比對特定請求屬性:URL 路徑、HTTP 方法、標頭值、查詢字串、請求主體內容、來源 IP、地理位置國家、大小限制、SQL injection 模式或跨站腳本攻擊(XSS)模式。
  • 速率型規則(Rate-based rules) — 在 5 分鐘滑動視窗內計算每個來源 IP(或其他彙整鍵,如標頭或轉送 IP)的請求數,對超過閾值的來源執行封鎖。速率型規則是 AWS WAF 針對暴力破解登入防護、爬蟲節流及應用程式層 DDoS 緩解的答案。
  • 規則群組參考(Rule group references) — 指向一組規則的捷徑,可以是 AWS 受管、Marketplace 或客戶自建的規則群組。

每條規則都有優先順序(數字越小越先評估)和動作:Allow、Block、Count(用於測試)或 CAPTCHA/Challenge。

AWS Managed Rule Groups

你不需要自己撰寫每一條規則。AWS Managed Rule Groups 是由 AWS 預先建立並持續維護的規則套件,涵蓋最常見的攻擊模式,是 SAA-C03 情境的預設起點:

  • Core rule set(CRS) — OWASP Top 10 通用防護。
  • Known bad inputs — 與已知漏洞相關的請求模式。
  • SQL database — 針對常見資料庫的 SQL injection 模式。
  • Linux / Windows / PHP / WordPress 作業系統規則群組 — 針對特定作業系統的攻擊模式。
  • IP reputation lists — Amazon IP 信譽清單(惡意行為者)及匿名 IP 清單(VPN/Tor/代理)。
  • Bot Control — 偵測並緩解常見的機器人流量(付費附加功能)。
  • Account takeover prevention(ATP) — 針對登入端點的暴力破解防護(付費附加功能)。
  • Account creation fraud prevention(ACFP) — 假帳號註冊防護(付費附加功能)。

AWS Marketplace 也提供來自 F5、Fortinet、Imperva 和 Trustwave 等廠商的第三方受管規則群組——當情境需要特殊規則集時很實用。

速率型規則深入說明

AWS WAF 的速率型規則在滾動式 5 分鐘視窗內計算每個來源 IP(或可設定的彙整鍵)的請求數,並封鎖超過設定閾值的來源。最低速率限制為每 5 分鐘 100 次請求,最高為每 5 分鐘 20,000,000 次請求。速率型規則可搭配 scope-down 條件,使限制只套用於特定 URL 路徑(例如 /login)。

SAA-C03 很喜歡「保護 /login 端點免受暴力破解」或「防止爬蟲大量存取產品目錄」這類情境。兩者的答案都是 AWS WAF 速率型規則,搭配 5 分鐘滑動視窗,並視需要加上 scope-down 條件鎖定特定路徑。不要與 Amazon API Gateway throttling 混淆,後者是依 stage/API key 計算,用途不同。Reference: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html

AWS WAF 可附加的資源

受保護的 AWS 服務 是否支援?
Amazon CloudFront 發行版 支援(全球範圍)
Application Load Balancer(ALB) 支援(區域範圍)
Amazon API Gateway REST API 支援(區域範圍)
AWS AppSync GraphQL API 支援(區域範圍)
Amazon Cognito 使用者集區 支援(區域範圍)
AWS App Runner 服務 支援(區域範圍)
AWS Verified Access 執行個體 支援(區域範圍)
Network Load Balancer(NLB) 不支援 — NLB 僅為 Layer 4
Amazon EC2 執行個體(直接附加) 不支援 — 請在前面加上 ALB 或 CloudFront

SAA-C03 反覆出現「將 AWS WAF 附加到 NLB」的陷阱選項。AWS WAF 是 HTTP/HTTPS 的 Layer-7 服務,而 NLB 是 Layer 4,兩者無法整合。若情境描述的是保護 TCP 型工作負載,適用的控制措施是 AWS Shield 和安全群組;若要使用 AWS WAF,必須在工作負載前方加上 Amazon CloudFront 或 Application Load Balancer。Reference: https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html

AWS Shield Standard 與 Shield Advanced — DDoS 緩解分層

AWS Shield 是 AWS 的受管 DDoS 防護服務。每個 AWS 帳號都會自動獲得免費的 AWS Shield Standard,並可選擇以高額月費訂閱 AWS Shield Advanced,取得進階防護、專屬回應支援及費用保護。SAA-C03 要求你精確掌握這兩個層級的差異。

AWS Shield Standard — 免費、自動啟用

AWS Shield Standard 對所有 AWS 客戶永遠開啟,無需額外費用。它自動防禦最常見的網路層和傳輸層 DDoS 攻擊:

  • SYN/UDP floods
  • 反射攻擊(Reflection attacks)(DNS、NTP、SSDP 等)
  • 其他 Layer 3 和 Layer 4 大量封包攻擊

Shield Standard 透明整合於 Amazon CloudFrontAmazon Route 53AWS Global Accelerator 及 Elastic Load Balancing 服務中。無需設定,直接生效。

AWS Shield Advanced — 付費、進階防護

AWS Shield Advanced 是一項訂閱服務,費用約為每月 USD 3,000,需簽訂 1 年合約,依 AWS Organization 計費(一個訂閱涵蓋所有連結的 AWS 帳號)。訂閱後可獲得:

  • 進階 DDoS 偵測與緩解 — 防禦規模更大、更複雜的攻擊,搭配 AWS WAF 可支援 Layer 7(應用程式層)攻擊防護。
  • AWS Shield Response Team(SRT) — 全天候專業團隊,可在攻擊進行中即時介入。
  • 費用保護 — AWS 會退還因 DDoS 事件造成的擴容費用(Amazon EC2、Amazon CloudFront、ELB、Amazon Route 53、AWS Global Accelerator),讓你不因吸收攻擊而蒙受財務損失。
  • 即時攻擊可視性 — 透過 AWS WAF 日誌、Amazon CloudWatch 指標及 AWS Shield 主控台。
  • 自動應用程式層 DDoS 緩解 — 針對受保護的 Amazon CloudFront 資源,透過 AWS 受管的 AWSManagedRulesAnonymousIpListAWSManagedRulesAmazonIpReputationList 及 Shield 專屬規則。
  • 全球威脅環境儀表板與攻擊報告。
  • AWS WAF 免費包含 — 在 Shield Advanced 受保護資源上使用 AWS WAF 不另計費。
  • AWS Firewall Manager 使用費包含 — Shield Advanced 政策的 Firewall Manager 使用費不另計。

Shield Advanced 保護的資源包括:Amazon CloudFront 發行版、AWS Global Accelerator 標準加速器、Amazon Route 53 託管區域、Application Load Balancer、Classic Load Balancer、Network Load Balancer,以及 Elastic IP 位址(Amazon EC2)。

  • Shield Standard — 免費、自動啟用、防禦 Layer 3/4 常見攻擊、適用所有 AWS 帳號。
  • Shield Advanced — 約 USD 3,000/月1 年合約,依 AWS Organization 計費。
  • Shield Advanced 包含 AWS WAF — 受保護資源上使用 WAF 不另計費。
  • Shield Response Team(SRT) — 全天候專業 DDoS 應變,僅 Shield Advanced 提供。
  • 費用保護 — DDoS 事件造成的擴容費用退還(Shield Advanced)。
  • 受保護資源類型:Amazon CloudFront、AWS Global Accelerator、Amazon Route 53、ALB、CLB、NLB、Elastic IP。
  • Reference: https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html

SAA-C03 中 Shield Standard 與 Shield Advanced 的選擇

情境線索 正確層級
「標準 SYN flood 攻擊公開網頁應用程式」 Shield Standard(自動啟用,已在運作)
「遊戲/金融/廣告科技平台,業務衝擊極高」 Shield Advanced
「需要攻擊進行中 24/7 DDoS 專家介入」 Shield Advanced(SRT)
「防止 DDoS 擴容造成帳單暴增」 Shield Advanced(費用保護)
「應用程式層 DDoS(HTTP flood)」 Shield Advanced + AWS WAF 速率型規則
「保護 NLB 免受大量封包 DDoS」 Shield(Standard 或 Advanced);AWS WAF 無法附加到 NLB

AWS Shield 緩解的是 DDoS(大量封包、協定,以及搭配 Advanced + WAF 的應用程式層洪流)。AWS WAF 封鎖的是依內容判定的惡意 HTTP 請求(SQL injection、XSS、惡意 User Agent、地理封鎖、依來源 IP 速率限制)。情境提到「SYN flood」→ Shield;提到「SQL injection」→ WAF;提到「每秒 100 萬次 HTTP 請求來自 5 萬個 IP 打向登入頁」→ 需要 Shield Advanced + WAF 速率型規則同時使用。Reference: https://docs.aws.amazon.com/waf/latest/developerguide/shield-chapter.html

AWS Firewall Manager — 跨多個 AWS 帳號的集中式政策管理

AWS Firewall Manager 是 AWS WAF、AWS Shield Advanced、AWS Network Firewall、Amazon Route 53 Resolver DNS Firewall、Amazon VPC 安全群組,以及來自 Palo Alto Networks、Fortinet 和 Check Point 的第三方防火牆的多帳號、多資源管理層。在 SAA-C03 中,只要情境提到多個 AWS 帳號AWS Organizations統一套用相同規則,答案就是 Firewall Manager。

AWS Firewall Manager 的功能

  • 在整個 AWS Organization 中統一套用 AWS WAF 規則群組、Shield Advanced 防護、安全群組基準、AWS Network Firewall 政策,以及 Route 53 Resolver DNS Firewall 規則
  • 自動修復(Auto-remediation) — 當新的 AWS 帳號加入 AWS Organization,或有人建立新的 Amazon CloudFront 發行版或 Application Load Balancer 時,Firewall Manager 自動附加所需的政策。
  • 持續合規稽核 — 偵測不合規的資源,並可選擇自動修復。
  • 集中可視性 — 跨整個 AWS Organization 查看 WAF、Shield、Network Firewall 和安全群組的組態。

前提條件

Firewall Manager 有三個 SAA-C03 很愛考的硬性前提條件:

  1. AWS 帳號必須屬於已啟用所有功能的 AWS Organization
  2. 必須指定一個 Firewall Manager 管理員帳號(委派管理員)。
  3. 必須在 Firewall Manager 執行政策的每個 AWS 帳號和 Region 中啟用 AWS Config

當 SAA-C03 題目提到「20 個 AWS 帳號」、「在 Organization 中統一套用 WAF 規則」、「跨所有 VPC 的安全基準」或「自動將新 AWS 帳號納管」,答案就是 AWS Firewall Manager。AWS WAF 本身只作用於單一帳號、單一資源;Firewall Manager 是企業規模的統一管理層。Reference: https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html

Amazon GuardDuty — 智慧型威脅偵測

Amazon GuardDuty 是 AWS 受管的威脅偵測服務。它持續分析各類日誌來源,識別異常行為、遭入侵的資源及已知惡意活動,產生具有嚴重性層級的發現結果(findings),供你的維運團隊(或 AWS Security Hub、Amazon EventBridge、AWS Lambda)做出回應。GuardDuty 不需要代理程式、不需要基礎設施、也不需要轉送日誌——每個 AWS Region 只需一鍵啟用即可。

GuardDuty 分析的日誌來源

  • AWS CloudTrail 管理事件 — AWS 帳號上的 API 呼叫。
  • AWS CloudTrail S3 資料事件 — Amazon S3 的物件層級讀寫。
  • Amazon VPC Flow Logs — 往返 Amazon EC2 的網路流量後設資料。
  • Amazon Route 53 DNS 查詢日誌 — 來自 VPC 內部的 DNS 查詢(Route 53 Resolver 查詢)。
  • Amazon EKS 稽核日誌 — Amazon EKS 叢集的 Kubernetes API 活動。
  • Runtime monitoring — 適用於 Amazon EKS、Amazon ECS on Fargate 及 Amazon EC2 執行個體(Linux)的 GuardDuty 代理程式。
  • Amazon RDS 登入活動 — 適用於 Amazon Aurora MySQL/PostgreSQL。
  • Amazon S3 Malware Protection — 掃描新上傳的 S3 物件。
  • Lambda Protection — 分析 AWS Lambda 的網路活動。

你不需要把日誌送到 GuardDuty——GuardDuty 直接從控制層原生讀取日誌。這也是 GuardDuty 通常被稱為「無代理程式」的原因(可選的 Runtime Monitoring 代理程式除外)。

GuardDuty 偵測的威脅類別

GuardDuty 將發現結果依**類型(finding types)**分類為數個類別:

  • 偵察(Reconnaissance) — 連接埠掃描、來自 VPC 外部的異常 API 探索呼叫。
  • 執行個體入侵(Instance compromise) — 加密貨幣挖礦、惡意程式命令與控制、異常對外連線、後門通訊。
  • 帳號入侵(Account compromise) — 異常 AWS API 呼叫、從匿名代理登入、IAM 使用者憑證從異常地理位置使用、停用 AWS CloudTrail 或 AWS Config。
  • 儲存桶入侵(Bucket compromise) — 異常 Amazon S3 API 呼叫、含敏感資料的公開儲存桶被建立、資料外洩模式。
  • Kubernetes 入侵(Kubernetes compromise) — 匿名 API 呼叫、提權、可疑的 pod exec/attach。
  • 惡意程式(Malware) — 由選配的惡意程式防護附加功能掃描到的檔案。
  • 已知惡意行為者(Known bad actors) — 來自 AWS 威脅情報及第三方情報來源(Proofpoint、CrowdStrike)的 IP 和域名。

發現結果嚴重性

每筆 GuardDuty 發現結果都帶有 0.1 到 8.9 的嚴重性分數,對應三個嚴重性層級:

  • 低(Low)— 1.0 到 3.9 — 值得調查的可疑活動,但非立即威脅(例:連接埠探測)。
  • 中(Medium)— 4.0 到 6.9 — 暗示資源可能已遭入侵的活動(例:對已知命令與控制域名的對外連線)。
  • 高(High)— 7.0 到 8.9 — 強烈顯示資源已遭入侵,需立即回應(例:EC2 執行個體進行加密貨幣挖礦)。

嚴重性決定路由方式——使用 Amazon EventBridge 規則:高嚴重性發出警報、中嚴重性建立工單、低嚴重性僅記錄日誌。

  • = 1.0 – 3.9(調查)
  • = 4.0 – 6.9(可能已入侵,應回應)
  • = 7.0 – 8.9(已入侵,立即行動)
  • GuardDuty 為區域性服務——須依每個 AWS Region 分別啟用。
  • GuardDuty 支援委派管理員,可彙整整個 AWS Organization 的發現結果。
  • Reference: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html

GuardDuty vs Inspector vs Macie — 三者易混淆比較

SAA-C03 很愛考 GuardDuty、Amazon Inspector 和 Amazon Macie 三者之間的混淆。請熟記下表。

AWS 服務 範疇 典型發現結果
Amazon GuardDuty 跨帳號、網路及工作負載的威脅偵測 「EC2 執行個體正在與已知惡意程式 C2 域名通訊」
Amazon Inspector EC2、ECR 容器映像及 Lambda 的漏洞評估 「EC2 執行個體安裝了 CVE-2023-12345(OpenSSL RCE)」
Amazon Macie Amazon S3 中的敏感資料探索 「S3 儲存桶 customer-docs 含有 2,400 個帶有 PII(信用卡號)的物件」

GuardDuty 監控的是攻擊者與異常行為(日誌中的主動威脅)。Amazon Inspector 掃描的是軟體漏洞與 CVE(靜態弱點)。Amazon Macie 掃描 Amazon S3 中的敏感資料(PII/PHI 分類)。情境提到「修補管理」→ Inspector。「在 S3 中找 PII」→ Macie。「EC2 遭入侵」→ GuardDuty。Reference: https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html

Amazon Macie — Amazon S3 中的 PII 探索

Amazon Macie 使用機器學習和模式比對,探索並分類 Amazon S3 中的敏感資料——包括信用卡號、社會安全號碼、AWS 存取金鑰、駕照號碼、健康資料,以及客戶自訂的正規表達式模式。Macie 回報哪些儲存桶含有敏感資料、資料的數量與嚴重性,以及這些儲存桶是否公開存取、是否與其他 AWS 帳號共用,或是否未加密。

在 SAA-C03 中,當情境描述「找出 S3 中的 PII」、「找出哪些 S3 儲存桶含有信用卡號」或「符合 GDPR/HIPAA 資料分類要求」,Macie 就是正確答案。如果情境是「加密 S3 儲存桶」(答案是 SSE-KMS/SSE-S3),或「偵測異常的 S3 API 呼叫」(答案是 GuardDuty),則 Macie 不適用。

Amazon Cognito — 使用者集區與身分集區

Amazon Cognito 是 AWS 為應用程式終端使用者提供的身分管理服務——登入手機 App 的客戶、進入網頁遊戲的玩家、在 SaaS 上註冊的訪客。Cognito 不適用於你的內部員工(那屬於 AWS IAM Identity Center 的範疇)。SAA-C03 對使用者集區與身分集區之間的區別考得非常頻繁。

Amazon Cognito 使用者集區(User Pools)— 驗證(目錄)

Amazon Cognito 使用者集區是一個受管使用者目錄,負責處理:

  • 使用者名稱+密碼、電子郵件+密碼或手機號碼+密碼的註冊與登入
  • Hosted UI — AWS 託管、可客製化的登入頁面,位於 <domain>.auth.<region>.amazoncognito.com,你的應用程式可以跳轉到此頁面,無需自行建立登入畫面。Hosted UI 內建支援登入、註冊、密碼重設及社群聯合身分驗證。
  • 社群聯合身分驗證(Social federation) — 以 Facebook、Google、Apple、Amazon 或任何 OIDC/SAML 2.0 身分提供者(Microsoft Entra ID、Okta、Ping)登入。無論使用者以密碼還是社群帳號登入,都會以統一身分的形式留在你的使用者集區中。
  • MFA(SMS 或 TOTP)及依風險的自適應驗證。
  • 帳號復原、電子郵件/SMS 驗證及自訂屬性。
  • Lambda triggers — 用於登入前、驗證前、確認後及自訂訊息邏輯。
  • JSON Web Token(JWT) — 登入成功後,使用者集區回傳 ID token(身分聲明)、access token(API 授權)及 refresh token。

你的應用程式後端透過驗證 JWT 來授權 API 呼叫。對於「讓使用者登入並讓應用程式信任他們」的情境,單獨使用使用者集區就已足夠。

Amazon Cognito 身分集區(Identity Pools)— 授權存取 AWS 資源(聯合身分)

Amazon Cognito 身分集區(亦稱為聯合身分)是一個獨立的 Cognito 資源,其任務是將登入 token 交換為短期 AWS 憑證。輸入來源可以是:

  • Cognito 使用者集區 JWT(最常見的模式——使用者集區+身分集區組合使用)。
  • 社群登入 token(Google、Apple、Facebook、Amazon)。
  • SAML 2.0 斷言。
  • OIDC token。
  • 「開發者驗證」的自訂身分。

身分集區將登入對應到一個 IAM 角色,並透過 AWS STS 回傳臨時 AWS 憑證。你的手機或網頁應用程式使用這些憑證直接呼叫 AWS 服務——上傳照片到 Amazon S3、讀取 DynamoDB 資料表、呼叫 Lambda 函式——裝置上無需任何長期 AWS 憑證。

身分集區支援已驗證與**未驗證(訪客)**角色,讓你可以為尚未登入的使用者授予有限的 AWS 存取權。

使用者集區 vs 身分集區 — 並排比較

問題 使用者集區 身分集區
主要用途 驗證(你是誰?) 授權存取 AWS(你可以呼叫哪些 AWS 資源?)
輸出 JWT(ID、access、refresh) 臨時 AWS STS 憑證
使用者目錄 有——儲存使用者、密碼、MFA 無——依賴其他身分來源
社群/SAML 聯合身分 有——聯合進入集區 有——聯合進入 IAM 角色
需要存取 AWS 資源時 單獨使用不足 有——搭配使用者集區或社群 IdP
只需要「讓使用者登入」時 單獨使用即可 不需要
Hosted UI 無——身分集區僅提供 API

SAA-C03 的陷阱剛好與問題反向。「讓使用者登入手機 App」→ 使用者集區。「讓手機 App 以每位使用者的權限直接呼叫 Amazon S3 和 Amazon DynamoDB」→ 使用者集區+身分集區(集區負責驗證,身分集區發出 AWS 憑證)。「讓沒有帳號的訪客上傳一個檔案到 S3」→ 身分集區搭配未驗證角色。Reference: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html

Hosted UI 與社群聯合身分驗證

Cognito Hosted UI 是與你的使用者集區域名關聯的 AWS 託管、符合 OAuth 2.0/OIDC 標準的登入頁面。Hosted UI 處理完整的 OAuth 授權碼流程,你的應用程式只需跳轉到 Hosted UI 並處理回呼。Hosted UI 支援客製化標誌、背景和 CSS,並原生呈現已設定的外部身分提供者(Google、Facebook、Apple、Amazon、SAML IdP、OIDC IdP)的登入按鈕。

當使用者選擇「以 Google 登入」,Cognito 與 Google 完成 OAuth 交換,將 Google 身分對應到你的使用者集區中的聯合使用者,並像使用者以密碼登入一樣簽發 JWT。使用者成為正式的 Cognito 使用者——你可以附加屬性、在 Lambda trigger 中讀取其身分,並要求 MFA。

SAA-C03 有時會將 Amazon Cognito 作為「讓公司員工以企業帳號登入多個 AWS 帳號」情境的答案。這是錯誤的——員工身分管理屬於 AWS IAM Identity Center(前稱 AWS SSO)的範疇。Amazon Cognito 是為你的應用程式終端使用者設計的,不是為建置該應用程式的公司工程師。Reference: https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html

AWS WAF 與 Cognito 使用者集區整合

AWS WAF 可直接附加到 Amazon Cognito 使用者集區,保護註冊和登入端點免受暴力破解、憑證填充和帳號接管攻擊。這是相對較新的整合,SAA-C03 開始將它納入「保護 Cognito 登入免受暴力破解」的正確答案:為使用者集區配對一個 AWS WAF Web ACL,其中包含針對 /oauth2/token 路徑的速率型規則,以及 AWS Managed Rules Account Takeover Prevention 群組。

AWS Secrets Manager 與 AWS Systems Manager Parameter Store

應用程式需要在執行階段載入資料庫密碼、第三方 API 金鑰、OAuth 客戶端機密和 SSL 私鑰——這些機密不應存在於原始碼、EC2 user-data 或容器映像中。AWS 提供兩種憑證儲存服務,SAA-C03 會直接對比測試。

AWS Secrets Manager — 專屬機密服務,以輪換為核心

AWS Secrets Manager 是專屬的機密儲存服務,具備以下定義性功能:

  • 自動輪換 — 內建整合 Amazon RDS、Amazon Redshift、Amazon DocumentDB 和 Amazon ElastiCache;其他任何機密可透過 AWS Lambda 函式進行自訂輪換。
  • 預設靜態加密 — 使用 AWS KMS(AWS 受管或客戶受管金鑰)。
  • 細粒度 IAM 政策和資源政策 — 支援跨帳號機密共用。
  • 自動版本控制 — 帶有暫存標籤(AWSCURRENT、AWSPREVIOUS、AWSPENDING),實現零停機輪換。
  • 整合 Amazon RDS、Redshift、DocumentDB — 輪換 Lambda 端對端處理主使用者密碼輪換,無需修改應用程式。
  • JSON 或鍵值結構 — 用於多欄位機密。
  • 定價 — 約 USD 0.40 每個機密每月,加上 USD 0.05 每 10,000 次 API 呼叫

當需要輪換、需要跨帳號機密共用,或機密保護高價值資源(如 RDS 主使用者)時,選用 Secrets Manager。

AWS Systems Manager Parameter Store — 免費、通用型

AWS Systems Manager Parameter Store 是通用型組態與機密儲存服務,標準層免費(較高配額的付費進階層每個進階參數約 USD 0.05/月)。

  • 三種參數類型StringStringListSecureStringSecureString 使用 AWS KMS 加密。
  • 無內建輪換 — 可以透過 EventBridge+Lambda 自行撰寫輪換腳本,但這不是原生功能。
  • 階層式命名/app/prod/db/password/app/prod/db/host,可依前綴查詢。
  • 自動歷史版本控制
  • 整合 AWS CloudFormation、AWS CodeBuild、AWS CodePipeline、Lambda、EC2、ECS
  • 標準層 — 每個參數最大 4 KB,每個 AWS 帳號最多 10,000 個參數,免費。
  • 進階層 — 每個參數最大 8 KB,最多 100,000 個參數,支援政策(到期、無變更提醒),付費。

對於一般組態(功能旗標、URL、調校參數)及不要求輪換的低風險機密,使用 Parameter Store。當需求明確要求輪換,或需要 Amazon RDS 憑證輪換時,使用 Secrets Manager。

並排比較

功能 AWS Secrets Manager AWS Systems Manager Parameter Store
主要用途 需要輪換的機密 組態+輕量機密
內建輪換 (RDS、Redshift、DocumentDB、自訂 Lambda) (需自行以 Lambda+EventBridge 實作)
費用 約 USD 0.40 / 機密 / 月+API 呼叫 免費(標準層),進階層付費
最大值大小 最大 64 KB 標準層 4 KB / 進階層 8 KB
跨帳號資源政策 有(進階層)
階層式命名 標籤 (原生路徑)
整合 RDS 受管輪換
KMS 加密 永遠加密 僅 SecureString 類型

如果 SAA-C03 情境強調自動輪換資料庫憑證(尤其是 Amazon RDS 主密碼),答案是 AWS Secrets Manager。如果情境是免費、階層式儲存組態或較不敏感的機密,答案是 AWS Systems Manager Parameter Store。如果情境說「以最低成本儲存幾個 API 金鑰,不需要輪換」,優先選 Parameter Store SecureString。Reference: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html

進階模式:Parameter Store 支援特殊的 aws:secretsmanager 參數類型,可解參照到 Secrets Manager 的機密。這讓你能在整個基礎設施中統一使用 Parameter Store 路徑,同時將需要輪換的敏感憑證保存在 Secrets Manager 中。當 SAA-C03 情境同時要求階層式命名和輪換時非常實用。Reference: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html

保護對外連線 — VPN 與 AWS Direct Connect

應用程式安全也涵蓋流量如何抵達。兩項 AWS 服務可安全地將內部部署網路連線到 AWS:

  • AWS Site-to-Site VPN — 透過公共網際網路,在你的內部部署 Customer Gateway 與 Virtual Private Gateway 或 AWS Transit Gateway 之間建立 IPsec 通道。已加密、成本低(低時費+標準出口費)、可快速部署。每條通道的吞吐量通常最高約 1.25 Gbps,受網際網路狀況影響。
  • AWS Direct Connect — 從你的資料中心到 AWS Direct Connect 站點的專用實體光纖連線。連接埠速度 1、10 或 100 Gbps,具有穩定延遲,流量不經過公共網際網路。預設不加密——若需端對端加密,需在 Direct Connect 上疊加 IPsec VPN。

SAA-C03 應用程式安全情境的選擇邏輯:若需求是**「加密」、「快速」、「低成本」** → Site-to-Site VPN。若需求是**「穩定頻寬」、「低延遲」、「混合雲生產環境」** → AWS Direct Connect。若需求是「加密且穩定頻寬」 → AWS Direct Connect+VPN 疊加

AWS Certificate Manager(ACM)— TLS 終止與自動更新

AWS Certificate Manager(ACM) 為 AWS 資源提供免費公開 TLS 憑證並自動更新。ACM 簽發的憑證可直接附加到 Amazon CloudFront 發行版Application Load BalancerNetwork Load BalancerAmazon API Gateway REST APIAWS Elastic Beanstalk 環境。只要 DNS 驗證或電子郵件驗證在到期前通過,ACM 就會自動更新憑證。

SAA-C03 應用程式安全考試中 ACM 的重點事項:

  • ACM 公開憑證免費
  • ACM 簽發的憑證無法匯出 — 綁定到 AWS 資源使用。
  • Amazon CloudFront 使用的 ACM 憑證必須在 us-east-1(北維吉尼亞)簽發,無論發行版的邊緣節點在哪裡。
  • 私有憑證(內部服務)需要 AWS Private CA(前稱 ACM Private CA),為付費附加服務。
  • TLS 終止可在 CloudFront、ALB 或 NLB 進行(NLB 的 TLS passthrough 僅支援 TCP)。

應用程式安全必背數字與重點

熟記以下清單——涵蓋 SAA-C03 應用程式安全題目中絕大多數的數字型與分類型陷阱。

  • AWS WAF 速率型規則 — 5 分鐘滾動視窗;閾值範圍 100 到 20,000,000 次請求每 5 分鐘
  • AWS WAF 可附加到:CloudFront、ALB、API Gateway、AppSync、Cognito 使用者集區、App Runner — 不支援 NLB、不支援直接掛在 EC2 上
  • AWS Shield Standard — 免費、自動啟用、適用所有 AWS 帳號、防禦 Layer 3/4 常見攻擊。
  • AWS Shield Advanced — 約 USD 3,000/月,1 年合約,依 AWS Organization 計費;包含 WAF、SRT、費用保護。
  • AWS Firewall Manager — 需要 AWS Organizations+AWS Config;集中管理 WAF、Shield Advanced、安全群組、Network Firewall、Route 53 Resolver DNS Firewall。
  • Amazon GuardDuty — 區域性服務;嚴重性低 1.0–3.9、中 4.0–6.9、高 7.0–8.9;委派管理員可彙整 Organization 發現結果。
  • Amazon Inspector — EC2、ECR 映像、Lambda 的漏洞掃描。
  • Amazon Macie — Amazon S3 中的 PII 探索。
  • Amazon Cognito 使用者集區 — 驗證/目錄;回傳 JWT;支援 Hosted UI 和社群聯合身分驗證。
  • Amazon Cognito 身分集區 — 授權存取 AWS 資源;回傳臨時 STS 憑證;支援訪客(未驗證)角色。
  • AWS Secrets Manager — 約 USD 0.40 每個機密每月;內建 RDS、Redshift、DocumentDB 輪換。
  • AWS Systems Manager Parameter Store — 標準層免費;標準最大 4 KB / 進階最大 8 KB;無內建輪換。
  • CloudFront 使用的 ACM 憑證必須在 us-east-1 簽發
  • Reference: https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html

常見考試陷阱 — SAA-C03 應用程式安全

每次 SAA-C03 考試至少會出現其中一個陷阱。先學會模式,再看答案選項。

陷阱一:Shield vs WAF

AWS Shield 緩解 DDoS(大量封包、協定,以及搭配 Advanced 的應用程式層洪流)。AWS WAF 封鎖依內容判定的惡意 HTTP 請求(SQL injection、XSS、惡意 User Agent、地理封鎖、速率限制)。情境提到 「SYN flood」「大量封包攻擊」 → Shield。提到 「SQL injection」「XSS」「對特定 URL 路徑進行速率限制」 → WAF。若是針對銀行或遊戲平台的大規模 HTTP 洪流 → Shield Advanced+WAF 速率型規則

陷阱二:GuardDuty vs Inspector vs Macie

  • GuardDuty = 攻擊者/異常行為偵測(日誌中的主動威脅)。
  • Inspector = 軟體漏洞掃描器(EC2、ECR、Lambda 上的 CVE)。
  • Macie = Amazon S3 中的 PII/PHI 探索。

任何將 GuardDuty 用於「修補管理」或將 Macie 用於「威脅偵測」的答案選項都是干擾選項。

陷阱三:Cognito 使用者集區 vs 身分集區

  • 使用者集區 = 驗證目錄;回傳 JWT。適用於「讓使用者登入應用程式」。
  • 身分集區 = 聯合到 IAM 角色;回傳 AWS STS 憑證。適用於「讓應用程式以每位使用者的權限直接呼叫 Amazon S3 / DynamoDB」。
  • 使用者集區+身分集區組合 = 最常見的真實場景模式。

陷阱四:Cognito vs IAM Identity Center

  • Cognito = 應用程式的終端使用者(客戶、手機/網頁應用程式使用者)。
  • IAM Identity Center = 員工(登入 AWS 帳號的公司內部人員)。

陷阱五:Secrets Manager vs Parameter Store

情境提到**「輪換」「RDS 主密碼」** 或 「跨帳號機密共用」Secrets Manager。提到**「免費」「組態參數」「階層式路徑」** 或 「最低成本」Parameter Store。兩者都用 AWS KMS 加密;輪換是關鍵決策依據。

陷阱六:WAF 無法附加到 NLB

AWS WAF 是 Layer 7(HTTP/HTTPS)服務。NLB 是 Layer 4(TCP/UDP/TLS)服務。WAF 無法附加到 NLB。若要對 NLB 前方的工作負載套用 WAF 防護,需在 NLB 前面加上 Amazon CloudFront,或若工作負載是 HTTP,則改用 Application Load Balancer。

陷阱七:Firewall Manager 需要 AWS Organizations+Config

任何在獨立 AWS 帳號上使用 Firewall Manager,或未啟用 AWS Config 的答案選項,都是錯誤的。Firewall Manager 嚴格限定為多帳號、Organization 層級的 AWS 服務。

陷阱八:Shield Advanced 費用保護不是自動退款

Shield Advanced 費用保護會退還受保護資源上因 DDoS 事件所造成的擴容費用——但需要你開立 AWS Support 案件並引用攻擊事件,且只適用於特定服務(CloudFront、ELB、EC2、Global Accelerator、Route 53)造成的擴容部分。這不是自動的帳單折扣。

應用程式安全 vs 網路安全 — 範疇界線

應用程式安全與網路安全有所重疊,但涵蓋不同層次:

  • 網路安全(VPC 主題):安全群組(有狀態)、網路 ACL(無狀態)、NAT gateway、VPC endpoint、AWS Network Firewall、Amazon VPC Traffic Mirroring、Route 53 Resolver DNS Firewall——在 Layer 3/4 運作,依 IP 和連接埠過濾。
  • 應用程式安全(本主題):AWS WAF、AWS Shield、Amazon GuardDuty、Amazon Cognito、AWS Secrets Manager、AWS Certificate Manager——在 Layer 7 及以上運作,依 HTTP 內容、token、行為或身分過濾。

兩者都是必要的。典型的 SAA-C03「縱深防禦」答案會層疊多個服務:安全群組+NACL(網路)+AWS WAF(應用程式)+Shield Advanced(DDoS)+GuardDuty(偵測)+Cognito(身分)+KMS(加密)+Secrets Manager(憑證)。

實務情境對應 — Task 1.2 應用程式安全

  • 「封鎖公開網頁層的 SQL injection」 → AWS WAF 搭配 AWS Managed Rules SQL database 規則群組
  • 「阻止針對 /login 的暴力破解攻擊」 → AWS WAF 速率型規則,範圍限定 /login,可選擇性加上 Account Takeover Prevention 受管規則群組。
  • 「保護公開網站免受大量 DDoS 攻擊,並提供全天候專家回應」 → AWS Shield Advanced
  • 「自動將相同 WAF 規則集套用到 20 個 AWS 帳號」 → AWS Firewall Manager
  • 「偵測正在進行加密貨幣挖礦的遭入侵 EC2 執行個體」 → Amazon GuardDuty
  • 「找出哪些 Amazon S3 儲存桶含有信用卡號」 → Amazon Macie
  • 「掃描 EC2 執行個體的未修補 CVE」 → Amazon Inspector
  • 「讓手機 App 使用者以 Google 登入並上傳照片到 Amazon S3」 → Amazon Cognito 使用者集區+身分集區
  • 「儲存並自動輪換 Amazon RDS 主密碼」 → AWS Secrets Manager
  • 「免費儲存大量樹狀結構的組態值」 → AWS Systems Manager Parameter Store(標準層)
  • 「為 CloudFront 發行版簽發加密 TLS 憑證」 → AWS Certificate Manager,需在 us-east-1 簽發

FAQ — 應用程式安全與防護熱門問題

Q1:什麼情況下使用 AWS WAF vs AWS Shield vs AWS Firewall Manager?

AWS WAF 依內容規則(SQL injection、XSS、速率限制、地理封鎖)過濾 HTTP/HTTPS 請求,可附加到 Amazon CloudFront、Application Load Balancer、Amazon API Gateway、AWS AppSync、Amazon Cognito 使用者集區和 AWS App Runner。AWS Shield 緩解 DDoS——Shield Standard 自動啟用且免費,適用所有 AWS 帳號的 Layer 3/4 防護;Shield Advanced 為付費訂閱(約 USD 3,000/月),增加應用程式層 DDoS 緩解(搭配 AWS WAF)、AWS Shield Response Team 及費用保護。AWS Firewall Manager 是 AWS WAF 和 AWS Shield Advanced 之上的多帳號政策引擎,同時涵蓋安全群組和 AWS Network Firewall,需要 AWS Organizations 和 AWS Config。三者通常同時使用:Shield 吸收洪流、WAF 依內容過濾、Firewall Manager 在 Organization 中的每個 AWS 帳號統一執行相同規則。

Q2:AWS WAF 速率型規則實際上做什麼?

速率型規則在滾動式 5 分鐘視窗內計算每個來源 IP(或可設定的彙整鍵,如標頭或轉送 IP)的請求數,並封鎖超過設定閾值的來源(最低每 5 分鐘 100 次請求,最高 20,000,000 次)。你通常會搭配 scope-down 條件,使限制只套用於特定 URL 路徑,例如 /login/api/search。這是 AWS WAF 實作暴力破解登入防護、爬蟲節流和應用程式層 DDoS 緩解的基本元素——也是 SAA-C03 的核心考試模式。

Q3:Amazon Cognito 使用者集區和身分集區有什麼差異?什麼時候需要兩者並用?

使用者集區是受管使用者目錄——處理註冊、登入、MFA、密碼重設、Hosted UI 及社群聯合身分驗證(Google、Apple、Facebook、Amazon、OIDC、SAML)。登入成功後,使用者集區回傳 JSON Web Token(ID、access、refresh),你的後端可以驗證這些 token。身分集區(亦稱聯合身分)將登入 token——來自使用者集區、社群提供者或 SAML/OIDC——交換為對應到 IAM 角色的短期 AWS STS 憑證,使客戶端應用程式可以直接呼叫 AWS 服務。如果你的應用程式只需要驗證使用者並與自己的後端通訊,單獨使用使用者集區就夠了。如果應用程式還需要從客戶端以每位使用者的權限直接呼叫 Amazon S3、Amazon DynamoDB 或 AWS Lambda,則需要在使用者集區之上加上身分集區。

Q4:如何選擇 AWS Secrets Manager 和 AWS Systems Manager Parameter Store?

如果需求包含自動輪換(尤其是 Amazon RDS、Amazon Redshift 或 Amazon DocumentDB 主憑證)、具有資源政策的跨帳號機密共用,或正式的機密生命週期管理,選擇 AWS Secrets Manager(約 USD 0.40 每個機密每月)。如果需求是免費或最低成本階層式組態儲存最大 4 KB 的標準參數,或偶爾存放不需輪換的機密,選擇 AWS Systems Manager Parameter Store(標準層免費;進階層增加政策和 8 KB 限制,需付費)。兩者都使用 AWS KMS 加密;輪換和原生 Amazon RDS 整合是決策關鍵。

Q5:Amazon GuardDuty 能偵測到哪些 AWS CloudTrail 單獨無法發現的威脅?

AWS CloudTrail 是每個 AWS API 呼叫的日誌——它是原始紀錄。Amazon GuardDuty 將 CloudTrail 管理事件、CloudTrail S3 資料事件、Amazon VPC Flow Logs、Amazon Route 53 DNS 日誌、Amazon EKS 稽核日誌、Amazon RDS 登入活動及選配的 Runtime Monitoring 代理程式,與 AWS 威脅情報和機器學習模型進行分析,然後產生帶有低(1.0–3.9)、中(4.0–6.9)、高(7.0–8.9)嚴重性分數的發現結果。GuardDuty 能告訴你「這台 EC2 執行個體正在與已知的加密貨幣挖礦命令與控制域名通訊」,或「這個 IAM 使用者的存取金鑰正從從未使用過的地理位置被存取」——這些都是 CloudTrail 單獨無法得出的結論。CloudTrail 捕捉「發生了什麼」;GuardDuty 判斷「這是不是攻擊」。

Q6:AWS WAF 可以保護 Network Load Balancer 或直接掛在 EC2 執行個體上嗎?

不行。AWS WAF 檢查 HTTP/HTTPS(Layer 7),只能附加到 Amazon CloudFront、Application Load Balancer、Amazon API Gateway、AWS AppSync、Amazon Cognito 使用者集區、AWS App Runner 和 AWS Verified Access。Network Load Balancer 在 Layer 4(TCP/UDP/TLS passthrough)運作,不具備 HTTP 感知能力,因此 AWS WAF 沒有任何東西可以檢查。若要對 NLB 前方的工作負載套用 WAF 防護,需在 NLB 前面加上 Amazon CloudFront,或若工作負載是 HTTP,則改用 Application Load Balancer。AWS Shield 仍然可以保護 NLB 和 Elastic IP。

Q7:AWS Shield Advanced 能保護我在 DDoS 攻擊期間不會產生巨額帳單嗎?

是的——AWS Shield Advanced 費用保護會退還因 DDoS 事件在受保護的合格資源上觸發的擴容費用(Amazon CloudFront 資料傳輸、Application Load Balancer 和 Classic Load Balancer 時數、Amazon Route 53 查詢、Amazon EC2 執行個體、AWS Global Accelerator 資料傳輸)。這不是自動退款——你必須開立 AWS Support 案件並引用攻擊事件,且退款只適用於可歸因於該攻擊的擴容部分。搭配 AWS Shield Response Team 和使用 AWS WAF 的應用程式層 DDoS 緩解,費用保護是高可用性公開工作負載(遊戲、金融、廣告科技)訂閱 Shield Advanced 的主要原因之一。

延伸閱讀

官方資料來源