Amazon SAP-C02: 安全性、身分識別與合規性 — 學習指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

屬於 AWS Solutions Architect Professional SAP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

身分與存取管理：原則性控管與聯合身分

身分管理的設計應圍繞著短期、最低權限的憑證，以及身分信任與權限授予之間的明確分離。所有運算和跨帳戶存取都應使用 IAM 角色，避免使用長期的 IAM 使用者存取金鑰，並利用 STS 取得臨時憑證。對於企業級 SAML 或 OIDC 聯合身分，應設定一個集中的身分提供者 (IdP)，並使用會話標籤 (session tags) 啟用屬性型存取控制，讓權限跟隨使用者和群組，無需進行每個帳戶的使用者管理。IAM Identity Center (IAM Identity Center) 提供全組織範圍的權限集 (permission sets)、SCIM 自動配置 (provisioning) 將群組推送到 AWS，並與來自 IdP 的 MFA 強制執行整合，以滿足強認證要求。使用權限邊界 (permission boundaries) 和受管政策 (managed policies) 來輔助身分控制以限制權限提升，並執行 IAM Access Analyzer 來偵測非預期的資源存取。AWS Organizations 中的服務控制政策 (SCPs) 透過拒絕跨 OU 的整個操作類別來提供護欄 (guardrails)，但它們本身不授予權限——信任政策和權限政策仍然是必要的。常見的陷阱包括過於寬鬆的萬用字元操作或主體、依賴根帳戶、第三方存取時缺少外部 ID (external IDs)，以及角色鏈接 (role chaining) 延長了有效的會話範圍。權衡點在於營運開銷與更嚴格的精細度之間：高度精細的角色需要更多管理，但能顯著減少爆炸半徑 (blast radius)。

金鑰、私密資料與加密：生命週期與跨帳戶模式

加密是靜態 (at-rest) 和傳輸中 (in-transit) 控制的基礎；決策應在金鑰所有權、營運控制和效能之間取得平衡。當您需要精細的金鑰政策、跨帳戶授權、可稽核性或自動輪換時，請使用 AWS KMS 客戶自管金鑰 (customer-managed CMKs)。為了服務管理的便利性，AWS 受管金鑰可減少營運開銷，但限制了政策控制。信封加密 (Envelope encryption) 透過使用資料金鑰進行大量加密，並用 KMS 來包裝 (wrapping) 金鑰，從而減輕對大型資料負載的效能影響。跨帳戶或跨區域使用需要明確的金鑰政策和授權 (Grants)；避免在沒有相應金鑰政策的情況下，僅授予 IAM 權限。Secrets Manager 提供輪換工作流程，並與 RDS 及其他服務原生整合，而 SSM Parameter Store (SecureString) 對於較小的需求是一個成本較低的選擇；兩者都應使用 VPC 端點以避免公開的出口流量 (public egress)。常見的架構陷阱包括在金鑰政策中授予 kms:* 或過於寬鬆的解密 (Decrypt) 權限、忘記允許 Lambda 執行角色同時擁有 IAM 和 KMS 權限，以及忽略為全球分佈式工作負載所使用的金鑰進行多區域複寫。成本效能的權衡包括每次請求的 KMS 成本和輕微增加的延遲，與客戶自管金鑰控制所帶來的安全效益之間的取捨。

偵測、監控與稽核：遙測、偵測性控制與自動化

偵測性控制與預防性控制同等重要；監控工具應集中化、不可變且可搜尋。啟用多區域、多帳戶的 AWS CloudTrail，並開啟日誌檔案驗證，並將日誌傳送到一個集中、存取受控且設定了生命週期政策的 S3 帳戶。將 CloudTrail、VPC Flow Logs 和 DNS 日誌饋送到一個集中的分析管道——例如 CloudWatch Logs、Kinesis Data Firehose 和 SIEM——以進行保留和警報。GuardDuty 為帳戶和工作負載行為提供受管的威脅偵測；指定一個委派管理員來匯總整個 Organization 的發現項目，並透過 EventBridge 自動化回應，以觸發 Lambda 教戰手冊 (playbooks) 或 Systems Manager Automation。Security Hub 匯總各種標準和發現項目 (CIS、PCI、自訂規則)，並可協調優先的修復工作。AWS Config 和 Config Rules 可實現持續的合規性檢查和組態漂移偵測，並使用 SSM Automation 進行修復。典型的陷阱包括單一區域的 CloudTrail、保留期不足或日誌非不可變、未經調校的嘈雜警報，以及缺乏委派管理員來擴展偵測規模。權衡取決於保留成本與鑑識和合規需求之間：較長的保留期有助於調查，但會增加 S3 和查詢成本。

應用程式層防禦、WAF、Shield 與多帳戶治理

保護面向網際網路的應用程式需要分層控制和集中化的政策管理。將 AWS WAF 部署在邊緣 (CloudFront) 和/或區域性的 ALB 上，以過濾 OWASP 等級的威脅、機器人流量，並實施速率限制 (rate limiting)。對於多帳戶的規則管理，請使用 AWS Firewall Manager 搭配一個委派的安全帳戶，將 WAFv2 規則群組、Shield Advanced 訂閱以及集中化的安全政策推展到各個 OU。Shield Advanced 為大規模事件提供 DDoS 緩解和成本保護，但費用高昂；請權衡您應用程式的 SLA 和 DDoS 風險暴露程度與訂閱價格。使用集中化的 Web ACL、受管規則群組 (managed rule groups) 和精細的 IP 集更新，以減少營運開銷並避免保護不一致的情況。架構上的陷阱包括僅依賴網路層的安全群組 (security groups)、未能集中化部署規則（導致組態漂移），或在需要全球 CDN 保護時僅在區域性部署 WAF。效能上的權衡取捨包括：因檢查而可能增加的延遲、自訂規則的複雜性，以及在惡意流量到達來源伺服器前就將其阻擋所獲得的彈性。確保 WAF 的日誌記錄、指標，並與 Security Hub/GuardDuty 整合，以實現一致的事件應變。

實務問題：使用案例情境

情境：OmniApps Ltd. 有一個 AWS Organization，其中包含一個管理帳戶、一個託管 Transit Gateway 的集中化網路帳戶，以及位於 eu-west-1 和 us-east-1 的多個工作負載帳戶。他們在 VPC 中運行私有的應用程式堆疊，這些堆疊中的 ALB 位於私有子網路，並透過 CloudFront 對外公開，且需要集中化的身分和安全控制。

挑戰：OmniApps 必須使用公司基於 SAML 的 MFA 來集中化存取、強制實施全組織範圍的安全護欄 (guardrails)、跨帳戶管理 WAF 規則和 DDoS 保護，並確保秘密和金鑰只能透過私有網路路徑存取。

建議方法：

在管理帳戶中啟用 IAM Identity Center，並連接到強制執行 MFA 的公司 SAML IdP；設定 SCIM 自動化佈建，並為最小權限的跨帳戶存取建立權限集合 (permission sets)。
在 Organizations 中實施服務控制政策 (SCP)，以拒絕未受管理的根使用者操作，並要求啟用 CloudTrail/Config；指定一個安全帳戶作為 Security Hub、GuardDuty 和 Firewall Manager 的委派管理員。
從安全帳戶使用 AWS Firewall Manager，將 AWS WAFv2 Web ACL 和 AWS Managed Rules 部署到跨帳戶的 CloudFront 發行版和 ALB；針對每個關鍵應用程式評估是否需要訂閱 Shield Advanced。
將 CloudTrail 日誌集中到一個安全的日誌記錄帳戶中，並使用安全帳戶中的多區域 CMK 進行加密，透過明確的 KMS 金鑰政策和 Grants 授權給日誌處理器進行解密，並為 KMS 和 Secrets Manager 啟用 VPC 端點以進行私有存取。

理由：集中化的身分識別和委派的安全管理可減少管理上的摩擦和爆炸半徑，而 Firewall Manager 和集中化的日誌記錄則提供了與專業架構最佳實踐一致的政策強制執行和鑑識能力。

← 網路與混合式連線 · 所有領域 · 運算與 Auto Scaling →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →