TL;DR——用 ec2:CidrIp IAM 條件金鑰擋掉 security group 的 0.0.0.0/0： 掛一條 SCP（或 IAM 政策），當 ec2:CidrIp——IPv6 則用 ec2:CidrIpv6——等於 0.0.0.0/0 且打在 22、3389 等敏感埠時，Deny 掉 ec2:AuthorizeSecurityGroupIngress（與 ec2:AuthorizeSecurityGroupEgress）。這是預防性的：開放規則根本不會被建立。AWS Firewall Manager 的 Common Security Group 政策則是偵測／矯正性的：規則建立之後才標記或移除它。在 SCS-C02 中，當預防性 SCP（ec2:CidrIp）與偵測性 Firewall Manager 控制同時出現時，預防性勝出。
什麼是安全部署、IaC 與 Firewall Manager？
安全部署、IaC 與 Firewall Manager 是 SCS-C02 Domain 6.2 的核心能力群，目標是把 AWS 資源的佈建過程轉化為可審查、可稽核、均勻受保護的供應鏈。不讓工程師在主控台隨意點按，安全部署、IaC 與 Firewall Manager 把每次資源建立都包在範本化的基礎架構即程式碼（IaC）裡，掃描這些範本的安全缺陷，透過 drift detection 確保生產環境不會悄悄偏離核准的基準，透過 Service Catalog 發布預先核准的產品目錄，透過 AWS Organizations 管理標籤，並透過 AWS Firewall Manager 把周邊防火牆規則廣播到組織中的每一個帳號。在 SCS-C02 考試中，安全部署、IaC 與 Firewall Manager 出現在約 8–12% 的情境題中，而且幾乎每道多帳號治理題都能簡化為「哪個安全部署、IaC 與 Firewall Manager 原語適用於這裡？」只要你能判斷正確答案是 CloudFormation stack policy、Service Catalog launch constraint、Firewall Manager WAF policy、Tag Policy、RAM share，還是 Backup Vault Lock，就能拿下這個 domain。
本學習筆記涵蓋安全部署、IaC 與 Firewall Manager的所有職責：使用 cfn-nag、CloudFormation Guard 與 Checkov 強化 CloudFormation 範本；stack 與 stack-set 層級的 drift detection；帶有 launch constraints 與 TagOptions 的 Service Catalog portfolio；透過 Organizations Tag Policy 的多帳號標籤策略；帶有 WAF、Shield Advanced、Network Firewall、Security Group 與 DNS Firewall 政策的 AWS Firewall Manager；AWS RAM 跨帳號資源共享；帶有 Vault Lock 的 AWS Backup 跨組織計畫；以及串連這一切的 IaC pipeline 模式。從頭讀到尾，你將完整掌握安全部署、IaC 與 Firewall Manager——無論是考試當天還是真實世界的安全審查。
安全部署、IaC 與 Firewall Manager 是 SCS-C02 Domain 6 的能力集，涵蓋：強化的 CloudFormation / Service Catalog 佈建、CloudFormation drift detection、Organizations 全組織標籤與 SCP 強制執行、AWS Firewall Manager 周邊政策扇出、AWS RAM 跨帳號資源共享，以及 AWS Backup 全組織受保護備份計畫。這是 AWS 讓「預設安全、大規模運作」在作業上真正落地的方式。
Reference: AWS Well-Architected — Security Pillar: Secure Workloads
白話文解釋 安全部署、IaC 與 Firewall Manager
安全部署、IaC 與 Firewall Manager 不是一個服務，是一整套「怎麼用紀律把雲蓋好」的工具箱。下面用三個不同的類比，讓你 30 秒就抓住精神。
類比一：工地與藍圖（Construction Site）
把 AWS 帳號想成一塊巨大的工地。安全部署、IaC 與 Firewall Manager 就是工地總監的三件套：第一是藍圖（CloudFormation / Service Catalog 範本）—— 沒有藍圖不准動工；第二是驗收清單（cfn-nag、Guard、Checkov、drift detection）—— 蓋完跟藍圖對不上就要重做；第三是全工地統一的安全圍籬（AWS Firewall Manager），不管哪個分包商蓋的房子，外牆鐵絲網規格都由總監統一拉過去。沒有這三件套，每個工人各蓋各的，最後就是違建大集合。
類比二：中央廚房與分店（Central Kitchen）
想像你經營連鎖餐廳：總部有中央廚房，每家分店只能用中央配送的食材與配方。Service Catalog Portfolio 就是中央廚房的「核准菜單」—— 分店主廚只能從這份菜單點 EC2 / RDS / Lambda 套餐，且只能用 launch constraint 指定的 IAM role 來執行。CloudFormation StackSet 是把同一份食譜瞬間下放到 100 家分店；drift detection 是稽核員每週去分店突擊檢查，菜被改過就抓出來。Tag Policy 是「每盤菜必須貼上 Owner / DataClassification 標籤」的總部規定，沒貼或貼錯，AWS Config 立刻黑名單。AWS Firewall Manager 則是「全國分店的防盜門鎖規格由總部統一」—— 任何一家自行換鎖（建立 noncompliant security group）會被自動改回來。
類比三：艦隊管制（Fleet Command）
CloudFormation 是單艦的作戰手冊；StackSet 是整支艦隊同步收到的命令；Service Catalog 是艦隊司令部核發的武器清單（離開清單的東西，艦長不能自己裝）；Tag Policy 是艦上每個櫃子都要貼識別標籤；AWS Firewall Manager 是艦隊統一的雷達／防空火控，旗艦把規則一發布，所有艦同時生效；AWS RAM 是跨艦的物資共用（共享 Transit Gateway、子網），讓盟艦不用各自買新的 Transit Gateway；AWS Backup 是艦隊統一的黑盒子備份計畫，並用 Vault Lock 把黑盒子焊死，連艦長都刪不掉，這才能對付勒索與內鬼。把這幾個齒輪兜起來，就是安全部署、IaC 與 Firewall Manager。
安全部署、IaC 與 Firewall Manager 三層心法：Template（CloudFormation / Guard / Checkov）→ Catalog（Service Catalog / StackSet）→ Control（Firewall Manager / Tag Policy / RAM / Backup Vault Lock）。考題拿到先判斷它在問哪一層。
Reference: AWS Security Best Practices — Architecting for Security at Scale
CloudFormation 範本強化
CloudFormation 是安全部署、IaC 與 Firewall Manager 的基石。強化範本意味著在 change set 執行前就捕捉到安全缺陷。
靜態掃描工具：cfn-nag、CloudFormation Guard、Checkov
SCS-C02 考試景觀中有三大工具：
- cfn-nag — Ruby 為底，內建約 70 條規則。標記萬用字元 IAM、開放 security group、未加密磁碟區。輸出快速且詳細；與大多數 CI runner 整合良好。
- CloudFormation Guard（
cfn-guard） — AWS 原生、policy-as-code DSL。你可以撰寫像AWS::S3::Bucket Properties.BucketEncryption EXISTS這樣的規則。當題目說「AWS 支援的 policy-as-code」時，這就是答案。 - Checkov — Bridgecrew / Prisma 開源工具。支援多語言（CFN、Terraform、Kubernetes）。非常適合混用多種 IaC 的環境。情境同時使用 CloudFormation 與 Terraform 時，通常選這個。
題目說「AWS 原生、宣告式規則、以類 Ruby DSL 由 AWS 維護」→ 選 CloudFormation Guard。說「開源、跨 CFN / Terraform / Kubernetes 多語言」→ 選 Checkov。說「快速、強主觀意見、內建即可找出萬用字元 IAM 與開放 SG」→ 選 cfn-nag。安全部署、IaC 與 Firewall Manager 很少選「以上皆是」——選最具體的那個工具。
Reference: AWS Blog — Validating AWS CloudFormation templates with cfn-guard
Parameter 限制、NoEcho 與動態參考
範本裡放 secret 是最典型的反模式。安全部署、IaC 與 Firewall Manager 規定三種控制：
- Parameter 限制 —
AllowedValues、AllowedPattern、MinLength、MaxLength在 stack 建立前就拒絕格式錯誤的輸入。對於防止 IAM 政策接受*作為 resource 尤其關鍵。 - NoEcho —
NoEcho: true在 DescribeStacks 輸出與 CloudTrail 中遮蔽參數值。搭配Type: String用於舊式需求。 - 動態參考 —
{{resolve:ssm-secure:/prod/db/password:1}}與{{resolve:secretsmanager:prod/api/key:SecretString:apiKey}}。範本永遠不儲存 secret；CloudFormation 在部署時以 deployer 的 IAM 權限解析。
SCS-C02 常見陷阱：考生誤以為 NoEcho 會加密值。它不會。NoEcho 只是抑制主控台與 DescribeStacks 中的顯示。明文值仍然傳入 CloudFormation，可能出現在 stack drift 日誌中。對於真正的 secret，請使用 Secrets Manager 動態參考 {{resolve:secretsmanager:...}}，讓 secret 從不進入範本。安全部署、IaC 與 Firewall Manager 將 NoEcho 視為縱深防禦，而非主要保護。
Reference: AWS CloudFormation — Do not embed credentials in your templates
Stack Policy 與終止保護
Stack policy 是 JSON 文件，在 UpdateStack 時保護指定邏輯資源不被意外更新或替換。與 IAM 不同。終止保護（Termination protection）則完全阻止 DeleteStack。兩者合力保護安全部署、IaC 與 Firewall Manager 態勢中的生產關鍵資源（資料庫、KMS CMK、VPC）。
CloudFormation Drift Detection
Drift = 範本預期狀態與實際資源設定之間的差異。Drift detection 是安全部署、IaC 與 Firewall Manager 的第二根支柱。
單一 Stack 與 Stack-Set Drift
DetectStackDrift 對單一 stack 執行，針對每個資源回傳 IN_SYNC、MODIFIED、DELETED 或 NOT_CHECKED。DetectStackSetDrift 跨整個 StackSet（所有帳號與區域）運作。當情境說「1,000 個 spoke 帳號，偵測任何帳號偏離 SCP 對齊基準」時，stack-set drift 是正確答案。
- Drift 是偵測性的，不是預防性的——它不阻擋變更，只是回報。
- Drift detection 免費（無每次呼叫費用），但有速率限制。
- 並非每個屬性都支援 drift 感知（請查閱支援資源矩陣）。
- IAM、S3、EC2、Lambda、RDS、KMS——均涵蓋。
- 某些巢狀屬性（例如 S3 bucket 生命週期規則）僅在資源層級回報 drift。
- Drift 狀態必須重新偵測；不是即時的。
- AWS Config 規則
CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK持續評估，是考試回答「持續 drift 合規」的正確答案。
Reference: Detecting unmanaged configuration changes to stacks and resources
自動化 Drift 修復
參考架構：EventBridge 規則 → CloudFormation drift detection 排程 → Lambda → SNS / Step Functions → 自動回復或警報。搭配 AWS Config 規則 CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK，讓不合規的 stack 觸發 Config 合規變更事件，再由 Systems Manager Automation 執行修復 runbook（AWSConfigRemediation-RestoreCloudFormationStackDrift）。這是安全部署、IaC 與 Firewall Manager 期望你認出的標準模式。
AWS Service Catalog：核准的 Portfolio
Service Catalog 把 CloudFormation 範本轉為產品（product），組成portfolio，並授予特定主體（IAM user、role、group，甚至透過 StackSet sharing 授予整個 OU）存取權。這就是安全部署、IaC 與 Firewall Manager 讓開發者自助服務而不需接觸原始範本的方式。
Portfolio、Product 與版本
Product 包裝一份 CloudFormation 範本（或 Terraform Open Source / Cloud config）。Product 存在於 portfolio 中。每個 product 有多個版本，管理員可以棄用舊版本，同時保留其可啟動性以供回滾。
Launch Constraints（關鍵）
Launch constraint 指定 Service Catalog 代表使用者啟動 product 時所假扮的 IAM role。這是讓沒有 S3、RDS 或 VPC 權限的開發者能啟動整個 stack 的魔法——Service Catalog 假扮（assume）特權 role。
沒有 launch constraint，終端使用者必須擁有範本建立的每個資源的權限。有了 launch constraint，使用者只需要 servicecatalog:ProvisionProduct 加上產品存取權。安全部署、IaC 與 Firewall Manager 使用這個模式讓開發者快速自助服務，而不直接授予他們生產環境權限。搭配 permissions boundary 搭配 launch role，防止範本被惡意利用時 role 被濫用。
Reference: Service Catalog launch constraints
TagOptions 與 AppRegistry
TagOptions 是 Service Catalog 機制，在佈建時強制要求必要的標籤 key 與值清單——不管使用者想不想，每個啟動的 product 都會帶上指定標籤。AppRegistry 整合會自動把每個已佈建的 product 加入 Application metadata bundle，讓你能跨帳號查看「屬於應用程式 X 的所有資源」。
透過 Organizations 共享 Portfolio
Portfolio 可透過 Organizations 整合與某個 OU 或整個組織共享。對超過 5 個帳號的公司來說，這比逐帳號共享更為適合。
多帳號標籤策略
標籤驅動成本分配、安全自動化（例如「自動加密標記 DataClassification=PII 的磁碟區」）、事件回應路由（IRContact=team-x@），以及透過 ABAC 的存取控制。安全部署、IaC 與 Firewall Manager 把標籤視為第一類治理控制。
AWS Organizations Tag Policy
Tag Policy（一種組織政策類型）定義哪些標籤 key 被允許、允許的值，以及是否強制區分大小寫。可在 root、OU 或帳號層級附加 Tag Policy。Tag Policy 預設不會阻擋不合規的標籤操作——它們產生合規訊號，由 AWS Config 和 Tag Policy 報告浮現。
單靠 Tag Policy 無法阻止開發者建立標籤錯誤的 EC2 執行個體。要阻擋動作，你需要帶有 aws:RequestTag/Confidentiality 或 aws:TagKeys 條件的 Service Control Policy (SCP)。常見考試陷阱：情境說「我們需要強制執行標籤——應該用什麼？」答案通常是 SCP 用於防止 + Tag Policy 用於可視性 + Config 規則 required-tags 用於偵測。安全部署、IaC 與 Firewall Manager 三層都用。
Reference: Tag policies — Organizations
標準安全標籤 Key
大多數企業安全基準至少規定以下標籤 key：
DataClassification— Public / Internal / Confidential / RestrictedConfidentiality— 同樣概念，範圍更窄Owner— 團隊信箱或通訊群組清單IRContact— 事件回應聯絡人Environment— prod / staging / devCostCenter— 用於費用分攤ComplianceScope— PCI / HIPAA / SOC2 / none
自動修復：由 EventBridge 觸發的 Lambda（tag:UntagResource 或不合規的 aws.config 事件）重新套用標準標籤集，或將資源隔離。
AWS Firewall Manager：全組織網路安全
AWS Firewall Manager 是安全部署、IaC 與 Firewall Manager 的周邊核心。一個中央管理員帳號發布 Firewall Manager policy，AWS 自動將規則部署到組織中的每個帳號。
你必須背起來的前置條件
- AWS Organizations 已啟用所有功能（不只是合併帳單）。
- AWS Config 在政策目標的每個成員帳號與區域中已啟用。
- 從組織管理帳號指定 Firewall Manager 委派管理員帳號。
- 每個成員帳號都存在 Firewall Manager service-linked role（政策推送時自動建立）。
- 對於 Shield Advanced 政策，Firewall Manager 管理員帳號必須有有效的 Shield Advanced 訂閱。
Reference: Getting started with AWS Firewall Manager
政策類型
| 政策類型 | 部署內容 | 典型用途 |
|---|---|---|
| WAF (v2) | 跨 CloudFront、ALB、API Gateway、AppSync 的 WebACL 關聯 | 全組織 OWASP Top 10 基準 |
| WAF Classic | 舊版 WAF 規則 | 避免使用；遷移至 WAF v2 |
| Shield Advanced | 對合格資源的 Shield Advanced 保護 | 每個 ALB / CF distribution 的 DDoS 覆蓋 |
| Security Group（Common） | 參考 SG 主要政策 / 稽核政策 | 自動附加基準 SG 並稽核過度寬鬆的規則 |
| Network Firewall | VPC Network Firewall 上的有狀態 / 無狀態規則 | 集中出口過濾 |
| DNS Firewall（Route 53 Resolver） | Resolver DNS Firewall 規則群組 | 全組織封鎖已知惡意網域 |
| Palo Alto Cloud NGFW | 第三方 NGFW 分發 | 廠商管理的周邊 |
政策模式：稽核 vs 強制
Firewall Manager 政策有兩種模式：
- Auto-remediate（強制） — Firewall Manager 修改不合規的資源以符合政策。
- Audit only（僅稽核） — Firewall Manager 回報不合規，但不變更任何東西。
考試偏好先稽核、後強制作為安全的推行模式，尤其是可能中斷工作負載的 SG common policy。
Firewall Manager 政策可依 OU、帳號清單或所有帳號為目標。以標籤為基礎的範圍（include / exclude by tag）讓你可以說「所有帳號，除了標記 firewall-manager:exempt=true 的帳號」。排除項目要謹慎使用——每個豁免都是一個等待被揭發的稽核發現。安全部署、IaC 與 Firewall Manager 把豁免視為有時間限制且需追蹤的項目。
Reference: AWS Firewall Manager policies
AWS RAM：跨帳號資源共享
AWS Resource Access Manager (RAM) 是安全部署、IaC 與 Firewall Manager 跨帳號發布共享基礎架構（單一 Transit Gateway、集中子網、Route 53 Resolver 規則）的方式，讓各帳號不必各自重建。
可共享資源
SCS-C02 高價值可共享資源精選：
- Transit Gateway 及 Transit Gateway 路由表
- VPC 子網（接收方在 owner 的子網中運行 ENI——IP 規劃一次，多次共享）
- Route 53 Resolver 規則
- License Manager 授權設定
- AWS Outposts
- AWS Network Firewall 規則群組
- AWS Glue catalog 與 Lake Formation 資料表
- Capacity Reservations
僅組織內共享——安全預設值
透過 RAM 共享時，優先選擇**「只允許與你的組織共享」**。這會拒絕對外部 AWS 帳號 ID 的共享邀請，消除「不小心把 Transit Gateway 共享給攻擊者帳號」這整類風險。
把子網或 Transit Gateway 共享給任意外部 AWS 帳號 ID，就讓該帳號能在你的 VPC 中運行 ENI / 路由封包。安全部署、IaC 與 Firewall Manager 規定任何生產網路資源只能組織內共享。用 aws ram list-resource-shares --resource-owner SELF 與 AWS Config 規則 ram-resource-share-external-account-block 稽核外部共享。
AWS Backup：跨組織計畫與 Vault Lock
AWS Backup 集中化 S3、EBS、EFS、FSx、RDS、DynamoDB、Aurora、Storage Gateway、EC2 執行個體、Neptune、DocumentDB、Redshift 等的備份政策。安全部署、IaC 與 Firewall Manager 使用 AWS Backup 在組織規模滿足合規框架（PCI-DSS req 9、HIPAA、ISO 27001）。
備份計畫、Selection 與 Vault
備份計畫包含規則：排程、保留期、生命週期（冷儲存轉換）、複製動作（到另一區域 / 帳號），以及目標 vault。Resource selection 使用標籤（backup:tier=critical）或資源 ARN。備份 vault 是加密的目的地，由 vault 存取政策管理。
跨帳號 / 跨區域複製
備份規則中的 copy-action 把復原點複製到另一帳號或區域的 vault。目的地 vault 必須透過 vault 存取政策信任來源，KMS key 必須允許跨帳號解密。這滿足了考試常見的「勒索軟體摧毀帳號 A——從帳號 B 的已鎖定 vault 復原」情境。
AWS Backup Vault Lock（合規模式）
Vault Lock 有兩種模式：
- Governance mode（治理模式） — 具有正確權限（
backup:DeleteRecoveryPoint豁免）的 IAM 主體仍可刪除復原點。適合非受規範的工作負載。 - Compliance mode（合規模式） — 一旦冷卻期（最多 3 天）過後，任何人——包括 AWS 帳號 root user——都無法在保留期到期前縮短保留期或刪除復原點。等同 WORM。考試回答「防勒索軟體備份」/ SEC 17a-4(f) / FINRA / CFTC 要求的正確答案。
一旦 Vault Lock 進入合規模式且冷卻期結束，你無法縮短保留期、無法停用 Vault Lock，也無法在保留期到期前刪除復原點——即使你刪除並重新建立 AWS 帳號也一樣。先在 governance mode 測試。安全部署、IaC 與 Firewall Manager 只對受法律規範的保留要求使用 Vault Lock 合規模式。
Reference: AWS Backup Vault Lock
AWS Backup Audit Manager
Backup Audit Manager 持續評估資源是否按照框架（一組控制，例如「所有 prod 的 RDS 必須有每日備份且保留 35 天」）受到保護。輸出送入 AWS Config，匯聚至 Security Hub 與組織合規儀表板。
端到端保護 IaC Pipeline
強化的範本只是故事的一半。安全部署、IaC 與 Firewall Manager 要求部署範本的 pipeline 同樣安全。
參考 Pipeline
開發者推送 → CodeCommit / GitHub
↓
CodeBuild（lint、單元測試、cfn-nag / Guard / Checkov 掃描）
↓ 通過
CodePipeline 手動核准（用於生產環境）
↓
CodeBuild deploy stage 假扮 deployer-role（最小權限、permissions boundary）
↓
CloudFormation ChangeSet → 審查 → 執行
↓
EventBridge: CFN_CREATE_COMPLETE → drift-detect 排程 + Config 評估
最小權限 Deployer Role
deployer-role 應是唯一允許建立生產 stack 的 role。綁定 permissions boundary，列出允許的服務（s3、lambda、dynamodb、iam:PassRole 只到特定 role），並明確拒絕 iam:CreateUser、iam:CreateAccessKey、organizations:* 等。
簽署的 Artifact 與 S3 Object Lock
CodePipeline artifact 存放在 S3 應使用 S3 Object Lock（Compliance mode）與 bucket key 加密以防竄改。CodeArtifact + GPG 簽章涵蓋相依套件完整性。Signer 搭配 Lambda code signing 確保只有已簽署的 Lambda 套件才能部署。
在每個生產 Lambda 上設定 CodeSigningConfig。CFN 範本引用 signing profile；未簽署或被竄改的 artifact 部署會失敗。這在安全部署、IaC 與 Firewall Manager pipeline 中關閉了「透過 npm 相依套件的供應鏈攻擊」這扇門。
Reference: AWS Lambda — Configuring code signing
SCS-C02 Domain 6.2 常見陷阱
安全部署、IaC 與 Firewall Manager 情境中六個反覆出現的陷阱。
陷阱一：應選 Firewall Manager 卻選了 Config Rule
題目說「把 WAF Web ACL 以相同規則部署到 200 個帳號」，用 Config rule + Lambda 修復雖然可行但脆弱。Firewall Manager 是專門為此設計的，也是考試答案。
陷阱二：應選 SCP 卻選了 Firewall Manager
題目是「防止任何帳號在 port 22 建立 0.0.0.0/0 的 SG」，帶有 ec2:AuthorizeSecurityGroupIngress 與 ec2:CidrIp 條件的 SCP 是預防性的。Firewall Manager Common Security Group Policy 是偵測 / 修復性的。當兩者都能用時，預防勝過偵測。
陷阱三：忘記 Tag Policy 不會阻擋
請參閱前面的 trap callout——Tag Policy 產生合規訊號；SCP 才會阻擋。
陷阱四：NoEcho ≠ 加密
請參閱 CloudFormation 強化段落的 trap callout。
陷阱五：忽略 StackSet 的權限模型
Self-managed permissions 需要手動建立 AWSCloudFormationStackSetExecutionRole / AdministrationRole。Service-managed 委派給 AWS Organizations（全組織部署必須使用這個）。新的 org 請選 service-managed。
陷阱六：Vault Lock Governance vs Compliance
治理模式 ≠ 合規模式。題目提到「受規範的保留」、「WORM」、「防勒索軟體」、「連 root 都刪不掉」——就是 compliance mode。
安全部署、IaC 與 Firewall Manager vs 替代模式
安全部署、IaC 與 Firewall Manager 與鄰近解決方案的比較：
| 目標 | 原生安全部署、IaC 與 Firewall Manager 原語 | 替代方案 |
|---|---|---|
| 標準架構自助服務 | Service Catalog Portfolio + launch constraint | 手工 CFN + 每位開發者 IAM 權限 |
| 把 WAF 部署到 200 個帳號 | Firewall Manager WAF policy | 自訂 Lambda + Config |
| 阻止無標籤資源建立 | 帶有 aws:TagKeys 的 SCP |
Lambda 偵測 + 回復（較慢、較吵） |
| 偵測範本 drift | Stack drift / StackSet drift + Config rule | 外部 diff 工具（較脆弱） |
| WORM 備份 | AWS Backup Vault Lock（compliance） | S3 Glacier Vault Lock（舊式） |
| 跨帳號 Transit Gateway | RAM 共享 Transit Gateway，僅限組織內 | 每帳號 Transit Gateway + peering（昂貴且複雜） |
考試當天操作決策樹
- 題目提到「drift」或「與範本不同步」 → CloudFormation drift detection 或
CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK。 - 題目提到「藍圖」、「核准架構」、「開發者自助服務」 → Service Catalog with launch constraints。
- 題目提到「跨所有帳號部署 WAF / Shield / Network Firewall / Resolver DNS Firewall」 → AWS Firewall Manager。
- 題目提到「缺少標籤就阻止資源建立」 → SCP（預防性）。
- 題目提到「回報哪些資源缺少必要標籤」 → Tag Policy + AWS Config
required-tags。 - 題目提到「跨帳號共享 Transit Gateway / 子網 / Resolver 規則」 → AWS RAM 且僅限組織內共享。
- 題目提到「防勒索軟體」、「WORM」、「連 root 都刪不掉」 → AWS Backup Vault Lock compliance mode。
- 題目提到「範本中的 secret」或「範本中的憑證」 → 動態參考到 Secrets Manager / SSM Parameter Store SecureString。
- 題目提到「Lambda 供應鏈完整性」 → Signer + Lambda code signing config。
- 題目提到「部署前掃描範本安全問題」 → CodeBuild 中的 cfn-nag / CloudFormation Guard / Checkov。
安全部署、IaC 與 Firewall Manager 最佳實踐清單
- 每個 CFN 範本在 CI 中通過
cfn-guard與checkov。 - 範本中無明文 secret；全部使用
{{resolve:secretsmanager:...}}。 - Stack drift detection 透過 EventBridge 排程每晚執行。
- 每個帳號中都已啟用 AWS Config 規則
CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK。 - Service Catalog portfolio 全組織共享；launch constraint 假扮帶有 permissions boundary 的強化 role。
- Tag Policy 附加在 OU 層級，強制執行
Owner、DataClassification、Environment、CostCenter。 - SCP 阻止建立缺少必要標籤的資源。
- Firewall Manager 委派管理員帳號與組織管理帳號分開。
- Firewall Manager WAF + Shield + Network Firewall + DNS Firewall 政策涵蓋所有帳號。
- AWS RAM 共享範圍限縮為僅組織內。
- AWS Backup 集中計畫帶有跨區域 + 跨帳號 copy action。
- 目標帳號的 backup vault 對受規範資料使用 Vault Lock compliance mode。
- CodePipeline deployer role 有 permissions boundary；無
iam:CreateUser權限。 - 生產 Lambda function 使用 Signer 核發的 code signing config。
- AppRegistry application bundle 每個 Service Catalog product 以利資源可視性。
常見問題——安全部署、IaC 與 Firewall Manager
Q1：在安全部署、IaC 與 Firewall Manager 的脈絡下，AWS Firewall Manager 與 AWS WAF 有什麼差異？
AWS WAF 是資料平面服務，在 CloudFront、ALB、API Gateway 或 AppSync 檢查 HTTP 流量。AWS Firewall Manager 是控制平面協調器，把 WAF（及其他）設定推送到組織中的每個帳號。安全部署、IaC 與 Firewall Manager 使用 Firewall Manager，讓單一安全團隊能強制要求 WAF 規則，而不需每個應用程式團隊自行設定 WAF。
Q2：AWS Backup Vault Lock compliance mode 可以被移除嗎？
不行。一旦冷卻期結束（你在套用鎖定時設定 0–72 小時），任何人——包括 AWS 帳號 root user、AWS Support，甚至關閉再重開帳號——都無法在保留期到期前刪除復原點或縮短保留期。這是刻意設計的。在安全部署、IaC 與 Firewall Manager 下套用 compliance mode 前，先在 governance mode 測試。
Q3：CloudFormation drift detection 能防止 drift 發生嗎？
不行。Drift detection 純粹是偵測性的——它回報哪些資源的線上狀態與範本預期狀態不同。要防止 drift，你必須把 drift detection 與阻止直接主控台修改的 Service Control Policy、IAM 最小權限 deployer role，以及可能自動回復未授權變更的 Config 修復三者結合。安全部署、IaC 與 Firewall Manager 把 drift detection 視為饋送修復 pipeline 的關鍵偵測控制。
Q4：什麼時候應該用 Service Catalog launch constraint，什麼時候用終端使用者的 IAM 權限？
當範本佈建的資源是終端使用者沒有直接權限建立的（例如，開發者啟動以 KMS CMK 加密的 RDS product），就用 launch constraint。Launch constraint role 在 stack 佈建期間假扮特權身份，使用者只需要 servicecatalog:ProvisionProduct。這是安全部署、IaC 與 Firewall Manager 中最小權限自助服務的標準模式。
Q5：AWS Organizations Tag Policy 與 Service Control Policy 在標籤強制執行上有什麼關係？
Tag Policy 定義標準（哪些標籤 key 被允許、允許的值、大小寫敏感性）並產生合規訊號。SCP 則用來強制執行標籤——例如，拒絕 ec2:RunInstances 除非帶有具允許值的 DataClassification 標籤。安全部署、IaC 與 Firewall Manager 兩者都用：Tag Policy 是規則書，SCP 是閘門，AWS Config 是稽核軌跡。
Q6：為什麼 AWS Firewall Manager 需要啟用 AWS Config？
Firewall Manager 透過讀取 AWS Config 的資源設定歷史來評估資源是否符合政策。若未在每個成員帳號和區域中啟用 Config，Firewall Manager 就無法偵測哪些資源需要修復。這就是為什麼安全部署、IaC 與 Firewall Manager 把 Config 列為與 Organizations 和委派管理員帳號並列的硬性前置條件。
Q7：透過 AWS RAM 共享 Transit Gateway 和跨帳號 VPC peering 是一樣的嗎？
不一樣。RAM 共享的 Transit Gateway 讓多個帳號把各自的 VPC 連接到單一 Transit Gateway，路由集中在 owner 帳號的 Transit Gateway 路由表中。VPC peering 是點對點且非傳遞性的。對於跨帳號超過幾個 VPC 的情況，RAM 共享的 Transit Gateway 在作業和成本上都更優越，也是安全部署、IaC 與 Firewall Manager 偏好的多帳號網路模式。
相關主題
- 稽核、日誌、CloudTrail 與 Config — SCS-C02 學習筆記
- 帳號結構：Organizations 與 Control Tower — SCS-C02 學習筆記
- 威脅偵測：GuardDuty 與 Security Hub — SCS-C02 學習筆記
- 資料保護：KMS 與 Secrets Manager — SCS-C02 學習筆記
- 網路邊緣防護：WAF 與 Shield — SCS-C02 學習筆記
掌握安全部署、IaC 與 Firewall Manager，你就擁有了 SCS-C02 作業治理三分之一的版圖。搭配 SCS-C02 題庫的練習題，在考試前一晚重看上面的決策樹，確保萬全。