運算工作負載安全性：Amazon Inspector、Systems Manager、EC2 Image Builder

為何運算工作負載安全性對 SCS-C02 至關重要

運算工作負載安全性是 AWS Certified Security – Specialty Domain 3 Task 3.3 的核心，也是 SCS-C02 考試期望你將弱點管理、修補、強化與憑證傳遞整合為一套完整敘事的地方。AWS 上的運算工作負載安全性並非單一服務——它是一門整合 Amazon Inspector、AWS Systems Manager、EC2 Image Builder、IAM 角色、IMDSv2、AWS Secrets Manager 以及 AWS Systems Manager Parameter Store 的學問。考試幾乎不會問「Inspector 的功能是什麼？」，而是會問「面對一個 EC2 執行個體艦隊與 ECR 映像，你要如何持續掃描、排定優先順序並修補漏洞？」——這就是運算工作負載安全性的實際應用。本主題建立你的肌肉記憶，讓你在考試中碰到任何運算工作負載安全性情境時，都能自動觸發正確的服務組合。

要答對運算工作負載安全性的題目，你需要內化四個心智模型：持續掃描（Inspector v2）、宣告式修補（Patch Manager）、不可變強化（Image Builder 黃金 AMI），以及最小權限憑證傳遞（執行個體角色、IMDSv2、Secrets Manager）。SCS-C02 的運算工作負載安全性也會滲入 Domain 1（Inspector 觸發嚴重發現時的事件回應自動化）與 Domain 2（修補合規性輸送至 Security Hub）。請把運算工作負載安全性視為偵測、治理與修補之間的結締組織，而非單一服務主控台裡的勾選項目。後續每個章節都從不同角度強化運算工作負載安全性。

Amazon Inspector v2 持續掃描架構

Amazon Inspector v2 是 AWS 運算工作負載安全性的基石。Inspector v2 是對原版 Inspector 的全面改寫——v2 引擎從以 Agent 為基礎的評估執行，轉型為對三種工作負載類型進行持續、帳號範圍的掃描：Amazon EC2 執行個體、Amazon ECR 中的容器映像，以及 AWS Lambda 函式（含 Lambda layer）。SCS-C02 上的運算工作負載安全性題目幾乎都預設 Inspector v2，除非明確說明否則；若題目提到「Inspector classic」，通常是干擾選項。

Inspector v2 持續對照由國家弱點資料庫（NVD）、廠商安全公告及 AWS 內部來源整理的 CVE 資料庫，評估工作負載。對於 EC2，Inspector v2 透過 AWS Systems Manager（SSM）agent 收集軟體物料清單（SBOM）；SSM agent 必須已安裝、正在執行，且網路可抵達 SSM 端點（在私有子網路中通常透過 VPC endpoint）。Inspector v2 隨後將已安裝的套件與已知 CVE 進行關聯，產出附有嚴重性分數的發現項目。對於 ECR，Inspector v2 在推送時掃描，並持續重新掃描新揭露的 CVE。對於 Lambda，Inspector 掃描已部署的套件及其相關 layer。

網路可達性發現項目

除了套件弱點，Inspector v2 也針對 EC2 執行個體產生網路可達性發現項目。這些發現項目整合 VPC 路由、安全群組、NACL、Internet Gateway 及 VPC peering，計算執行個體從網際網路或其他 VPC 的實際可達性——與已安裝套件無關。網路可達性發現項目是 Task 3.3（運算工作負載安全性）與 Task 3.4（網路疑難排解）之間的橋樑。在考試中，若情境描述「某執行個體的 SSH 連接埠可從 0.0.0.0/0 存取」，正確答案應是 Inspector 網路可達性，而非原始 VPC Flow Logs。

Inspector 發現項目嚴重性、漏洞利用可用性與優先排序

Inspector v2 為每個發現項目指派嚴重性（Critical、High、Medium、Low、Informational），根據基礎 CVSS v3 分數計算，並加入 Inspector 專屬分數，整合漏洞利用可用性、網路可達性及 CVE 年齡。運算工作負載安全性團隊鮮少有餘力修補所有發現項目；考試測驗的是你能否排定優先順序。標準優先排序層次為：具有已知漏洞利用且網路可達的 Critical 發現項目優先；無漏洞利用的 Critical 發現項目次之；網際網路面向執行個體上的 High 發現項目再次之；其餘最後處理。

Inspector 發現項目會使用 AWS Security Finding Format（ASFF）自動流入 AWS Security Hub。從 Security Hub，發現項目可路由至 Amazon EventBridge 進行自動修補。這是 SCS-C02 運算工作負載安全性自動化的標準模式：Inspector → Security Hub → EventBridge → Lambda 或 Systems Manager Automation。請牢記這個鏈路；它在情境題中反覆出現。

Inspector 發現項目修補工作流程

考試熱愛自動化模式。標準的運算工作負載安全性修補工作流程如下：

1. Inspector v2 對 EC2 艦隊提出 Critical CVE。
2. Inspector 透過 ASFF 將發現項目轉送至 Security Hub。
3. 在 Security Hub Findings - Imported 上設定、篩選條件為 severity.label = CRITICAL 的 EventBridge 規則觸發。
4. EventBridge 目標呼叫 AWS Step Functions 狀態機器，或直接呼叫 Systems Manager Automation runbook。
5. Step Functions 協調：為執行個體加上「patching pending」標籤、對執行個體呼叫 Patch Manager AWS-RunPatchBaseline、等待合規性確認、透過 Inspector 重新掃描驗證、透過 SNS 發送通知。
6. 若修補失敗，Step Functions 呼叫備援路徑：對執行個體建立快照、終止執行個體，並讓 Auto Scaling group 從新烘焙的黃金 AMI 啟動全新執行個體。

這個工作流程就是生產規模的運算工作負載安全性。考試不會要你寫 JSON，但會問你哪些服務協調哪個步驟。Step Functions 是工作流程超過兩步且有分支時的正確答案；Lambda 單獨執行是一次性修補的正確答案。

AWS Systems Manager Patch Manager 深度解析

AWS Systems Manager Patch Manager 是 AWS 原生的艦隊修補解答，支援 Linux、Windows 及 macOS 執行個體——包含以受管執行個體身分登錄的混合（地端）伺服器。Patch Manager 是繼 Inspector 之後，運算工作負載安全性的第二根支柱。Inspector 告訴你哪裡壞了；Patch Manager 負責修復它。

Patch Manager 有四個概念性構件：

• 修補基準（Patch baseline）：定義哪些修補程式被核准（依分類、嚴重性、廠商、產品）以及哪些被拒絕的規則集。AWS 發布預設基準（例如 AWS-AmazonLinux2DefaultPatchBaseline）；你可建立自訂基準以強制執行組織的運算工作負載安全性政策，例如「7 天後自動核准 Critical 與 Important 安全性修補程式，拒絕所有驅動程式更新」。
• 修補群組（Patch group）：以標籤為基礎的執行個體分組（Patch Group 標籤值），對應至特定基準。修補群組讓你對開發環境與生產環境的運算工作負載安全性層套用不同基準。
• 維護視窗（Maintenance window）：排定 Run Command 執行 AWS-RunPatchBaseline 文件的時間切片。維護視窗強制執行變更視窗、並行度與錯誤閾值。
• 修補合規性（Patch compliance）：執行後的評估，將每個執行個體的合規性回報至 Systems Manager Compliance，進而送往 Security Hub。

::memorize[Patch Manager 心智模型：

• 基準（Baseline） = 哪些修補程式算「已核准」
• 群組（Group） = 哪些執行個體套用哪個基準（透過標籤 Patch Group）
• 視窗（Window） = 修補何時執行
• 合規性（Compliance） = 修補是否成功？

若情境問「如何對開發環境與生產環境套用不同的修補政策？」，答案是使用不同基準的修補群組，而非獨立的維護視窗。請牢記這個區別——這是 SCS-C02 上最常考的運算工作負載安全性細節之一。]{href="https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-baselines.html"}

地端伺服器的混合式修補管理

Patch Manager 透過 Systems Manager 混合啟用，延伸至地端 Linux 與 Windows 伺服器。你產生一個混合啟用金鑰，在地端伺服器安裝 SSM agent，伺服器便以帶有 mi- 前綴（而非 i-）的受管執行個體身分登錄。從此刻起，Patch Manager 便與原生 EC2 執行個體一視同仁地對待它。這是「我們有地端 Windows 伺服器，且希望統一運算工作負載安全性修補」的唯一 AWS 原生答案；SCCM 等第三方工具不在 SCS-C02 的範疇內。

EC2 Image Builder 與強化黃金 AMI

修補執行中的執行個體是被動的做法。主動的運算工作負載安全性模式是黃金 AMI：一個強化、預先修補、預先設定的基礎映像，讓所有新執行個體從中啟動。EC2 Image Builder 是 AWS 的受管服務，用於排程建置、測試及發布黃金 AMI（與容器映像）。

Image Builder 有五個基本要素：

• 映像配方（Image recipe）：宣告父映像（例如最新版 Amazon Linux 2023 AMI）加上有序的元件清單。
• 元件（Component）：一份 YAML 文件，執行建置階段與測試階段的步驟。AWS 發布受管元件（CIS Level 1 強化、STIG 強化、CloudWatch agent 安裝）；你可自行撰寫自訂元件以滿足特定應用程式的運算工作負載安全性基準。
• 映像流水線（Image pipeline）：排程配方執行（cron 或隨需）並套用發布設定。
• 發布設定（Distribution configuration）：定義目標 Region、目標帳號、AMI 權限（以 KMS 加密）以及自動更新的啟動範本。
• 基礎設施設定（Infrastructure configuration）：宣告建置時的 EC2 執行個體類型、子網路、IAM instance profile 以及建置通知的 SNS 主題。

CIS Level 1 與 STIG 元件對 SCS-C02 的運算工作負載安全性尤為重要。CIS = 網際網路安全中心（Center for Internet Security）；STIG = 安全技術實作指南（Security Technical Implementation Guide，美國國防部）。兩者均施加主機層級的設定基準：停用未使用的服務、設定核心參數、設定 auditd、強化 sshd_config。請牢記，「我們需要符合 CIS 的強化 AMI」的最佳答案是搭配 AWS 受管 CIS 元件的 Image Builder，而非手工撰寫腳本。

IAM 執行個體角色與服務角色

了解哪個 IAM 角色扮演什麼功能，是核心的運算工作負載安全性技能。SCS-C02 區分：

• 執行個體角色（Instance role）（又稱 EC2 instance profile）：由在 EC2 執行個體上執行的程式碼所承擔的 IAM 角色。憑證透過執行個體中繼資料服務（IMDS）取得。使用案例：EC2 上的應用程式從 S3 讀取資料、寫入 CloudWatch 指標、從 Secrets Manager 取得機密。
• 服務角色（Service role）：由 AWS 服務代表你承擔以操作你的資源的 IAM 角色。使用案例：Image Builder 需要服務角色來建立 AMI；Systems Manager Automation 需要服務角色來呼叫其他 API；Lambda 需要執行角色。

兩者都是 IAM 角色，但信任政策不同。執行個體角色的信任政策列出 ec2.amazonaws.com 作為主體；服務角色的信任政策列出相關服務主體（imagebuilder.amazonaws.com、ssm.amazonaws.com、lambda.amazonaws.com）。

考試關鍵的權限是 iam:PassRole。若要將執行個體角色附加至 EC2 執行個體，執行 RunInstances 的 IAM 使用者或角色必須對被傳遞的角色擁有 iam:PassRole。若要將服務角色委派給 Image Builder，同樣需要 iam:PassRole。運算工作負載安全性的錯誤設定往往來自過於寬鬆的 iam:PassRole 授權——擁有 iam:PassRole on * 的開發人員可以將任何角色傳給任何 EC2 執行個體，包含過度授權的角色。

執行個體中繼資料服務 v2（IMDSv2）強制執行

IMDSv2 是 EC2 上最重要的單一運算工作負載安全性控制。舊版 IMDSv1 是對 http://169.254.169.254/latest/meta-data/iam/security-credentials/... 的純 HTTP GET 請求。伺服器端請求偽造（SSRF）攻擊惡意利用這一點：有弱點的網路應用程式被欺騙去代理請求，便能竊取執行個體角色的臨時憑證。

IMDSv2 透過三個控制修復了 SSRF：

1. 基於 Token 的工作階段：客戶端必須先對 /latest/api/token 發出帶有 X-aws-ec2-metadata-token-ttl-seconds 標頭的 PUT 請求，然後在每次 GET 請求中帶入回傳的 Token。僅轉發 GET 的 SSRF 即被阻擋。
2. 跳數限制（Hop limit）：中繼資料回應的 IP TTL 預設為 1，表示容器化的 SSRF 無法跨越 Docker 網路。預設跳數限制為 1；僅在容器確實需要存取 IMDS 時才調升至 2。
3. 必要模式（Required mode）：將執行個體中繼資料選項設為 HttpTokens=required，直接拒絕所有 IMDSv1 請求。這是生產環境的運算工作負載安全性基準。

在整個組織層級強制執行 IMDSv2，需要三個層次：

• 帳號層級預設：在 EC2 設定中設定「執行個體中繼資料預設值」為 HttpTokens = required，新執行個體即繼承此設定。
• AMI 中繼資料：將 imdsv2 = required 烘焙至黃金 AMI，讓衍生的啟動範本繼承它。
• SCP：在 ec2:MetadataHttpTokens != required 時拒絕 ec2:RunInstances。這是在 AWS Organizations 層級的防彈運算工作負載安全性護欄。

主機端防火牆與作業系統層級強化

安全群組與網路 ACL 是周界控制。運算工作負載安全性的縱深防禦需要在主機本身建立第二道防火牆：Linux 上的 iptables / nftables，Windows 上的 Windows Firewall。主機端防火牆在安全群組設定錯誤時限縮爆炸半徑，並讓你表達安全群組無法表達的政策——例如「這個使用者帳號只能連線至此本地連接埠」。

SCS-C02 期望你了解：

• 主機端防火牆由客戶管理；AWS 不為你設定 iptables。
• 設定應透過 Image Builder 元件烘焙至黃金 AMI，而非在每個執行中的執行個體上逐一設定。
• 主機端防火牆日誌（auditd、Windows 事件日誌）透過統一 CloudWatch agent 傳送至 CloudWatch Logs。
• CloudWatch agent 本身透過 Systems Manager State Manager（AWS-ConfigureAWSPackage）安裝，以確保艦隊一致性。

機密與憑證傳遞至運算資源

SCS-C02 專門有一個技能要點是「安全地將機密與憑證傳遞給運算工作負載」。應避免的運算工作負載安全性反模式：

• 在使用者資料腳本中寫死存取金鑰。
• 在環境變數中寫死存取金鑰。
• 將憑證烘焙至 AMI。
• 以明文設定檔儲存憑證。

AWS 原生的運算工作負載安全性模式：

• 對於 IAM 憑證：永遠不要自行傳遞。使用執行個體角色；SDK 透過 IMDSv2 自動探索憑證。
• 對於資料庫密碼、第三方 API 金鑰、OAuth Token：儲存於 AWS Secrets Manager。應用程式在啟動時透過 SDK 取得。依排程透過 Lambda 輪換函式進行輪換。
• 對於非敏感設定（功能旗標、Region 名稱）：使用 Systems Manager Parameter Store 標準參數。
• 對於敏感設定但量不足以合理使用 Secrets Manager 計費的：使用以 KMS 客戶受管金鑰加密的 Parameter Store SecureString 參數。

Secrets Manager Lambda extension 是無伺服器運算工作負載安全性的升級方案：一個 Lambda layer，以 sidecar 方式運作於函式旁，取得機密一次、在本地快取，並在 TTL 到期時重新整理。若無此 extension，每次呼叫都會產生一次 Secrets Manager API 呼叫——在大規模下成本昂貴。

使用 ECR Enhanced Scanning 掃描容器映像

Amazon ECR 提供兩種掃描模式，你必須在 SCS-C02 中加以區分：

• 基本掃描（Basic scanning）（免費）：使用開源的 Clair 引擎。僅在推送時掃描。CVE feed 涵蓋範圍有限（主要是作業系統套件）。
• 增強掃描（Enhanced scanning）（付費，由 Inspector v2 驅動）：持續掃描、更廣泛的 CVE feed、應用層語言套件（Python pip、Node npm、Java Maven）、Lambda 支援。

對於生產規模的運算工作負載安全性，增強掃描是正確答案。取捨在於成本：Inspector v2 依每月每個掃描映像計費。實驗室環境可使用基本掃描；生產環境不應如此。

ECR 映像掃描結果流入 Security Hub 的方式與 EC2 發現項目完全相同。同樣的運算工作負載安全性修補模式適用：增強掃描 → ASFF → Security Hub → EventBridge → CodeBuild 重建觸發 → 推送新映像 → ECS / EKS 服務重新整理。

修補合規性儀表板與報告

Systems Manager Compliance 匯總整個艦隊的修補狀態。每個執行個體在每次 Run Command 執行後回報每個修補程式的合規性；Compliance 在 SSM 主控台中以艦隊範圍百分比呈現此資訊。合規性資料傳送至：

• Security Hub：以 Patch Compliance ASFF 發現項目的形式，與 Inspector 和 GuardDuty 發現項目在同一個單一窗格上顯示。
• AWS Config：透過受管規則 ec2-managedinstance-patch-compliance-status-check，將不合規的執行個體標記為 NON_COMPLIANT，並觸發 Config 修補動作。
• Amazon QuickSight 或 Athena：透過將 Compliance 資料匯出至 S3 以建立自訂儀表板。

對於 SCS-C02 詢問「如何向稽核人員證明 95% 的艦隊已套用九月份 Microsoft 修補程式」的題目，答案鏈結是：Patch Manager 執行基準 → Compliance 記錄每個執行個體的狀態 → Config 規則評估 → Security Hub 匯總 → Audit Manager 建立證據包。運算工作負載安全性也是運算工作負載的可舉證性。

::memorize[SCS-C02 運算工作負載安全性服務地圖：

• 弱點偵測：Inspector v2（EC2、ECR、Lambda）
• 修補：Systems Manager Patch Manager（+ Run Command、Maintenance Windows）
• 強化 / 不可變映像：EC2 Image Builder
• 工作負載身分識別：IAM 執行個體角色（搭配 iam:PassRole 控制）
• 中繼資料保護：IMDSv2（HttpTokens=required，跳數限制 1）
• 主機防火牆：客戶管理的 iptables / Windows Firewall，透過 Image Builder 烘焙
• 機密：Secrets Manager（搭配輪換 Lambda）用於敏感資料；Parameter Store SecureString 用於低量場景
• 匯總：Systems Manager Compliance → Security Hub → EventBridge

請記住這七列表格，它直接對應到 Task 3.3 中所有的運算工作負載安全性技能要點。]{href="https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html"}

白話文解釋

類比 1：汽車保養廠的定期檢修 + 維修處理（Inspector + Patch Manager）

把每台 EC2 執行個體想像成一輛定期進廠的汽車。Amazon Inspector v2 就是「診斷儀器」——技師每次接車，機器就自動掃描全車系統，把所有異常代碼（CVE、弱點）記錄在維修單上。AWS Systems Manager Patch Manager 則是「維修師傅 + 工單系統」——維修單顯示需要更換哪個零件（patch），師傅依照「維修規範手冊」（patch baseline）備料換件，依照「排班表」（maintenance window）進行工作，最後將「完工紀錄」（compliance report）回傳給車廠總部稽核（Security Hub）。

Inspector 不會自己換零件；它只「診斷」。Patch Manager 不會自己找問題；它只「維修」。運算工作負載安全性就是要把「診斷」和「維修」串起來，加上 EventBridge 自動化當「總調度員」，一旦發現嚴重瑕疵立刻派工修繕。考試最常考的場景就是：「Inspector 發現 Critical CVE，怎麼自動修？」答案永遠是「Inspector → Security Hub → EventBridge → SSM Automation AWS-RunPatchBaseline」。

類比 2：便利商店的中央物流備料（EC2 Image Builder）

想像你管理一個有 50 間門市的便利商店連鎖（50 台 EC2 執行個體）。如果每間門市每天自己採購、自己決定商品擺放規格，結果一定是各家標準不一、食安漏洞此起彼落（compute workload security drift）。正確做法是建立一個中央物流中心（EC2 Image Builder）：每週固定時間，物流中心按照「商品規格書」（image recipe）加上「備品清單」（components：CIS 強化、STIG、CloudWatch agent）打包好一批「標準貨架組」（golden AMI），直接配送至所有門市。門市只需「上架即售」（launch instance from AMI），所有門市的衛生標準、陳列規格、設備版本完全一致。

當食品安全公告新規定（new CVE published），物流中心自動更新規格書，重新打包一批配送出去（pipeline rebuild → launch template update → Auto Scaling refresh）。舊批次的問題品項（vulnerable instances）全數下架回收。運算工作負載安全性的核心理念就是：不要在門市現場修補品質問題；在中央物流一次做對，全台配送。這就是不可變基礎設施（immutable infrastructure）的精神。

類比 3：社區大樓的門禁卡系統（IAM instance role + IMDSv2 + Secrets Manager）

想像 EC2 執行個體是社區大樓裡的住戶，他需要刷卡才能進出管制設施（S3、DynamoDB、Secrets Manager）。早期做法（IMDSv1）就像把門禁卡複製一張，貼在住戶信箱外面——任何路過的陌生人（SSRF 攻擊）都能拿走卡片複製使用。

IMDSv2 改成「兩段式驗證門禁」：住戶每次進門都要先按對講機 PUT 一個申請碼（token），拿到臨時授權才能刷卡。光是在外面刷一下（GET-only SSRF）是進不去的。Hop limit = 1 就像門禁只開放給「同一棟樓」的住戶（同一個 host），從隔壁棟翻牆過來（container 從 docker network 繞道）別想進入。

IAM instance role 是住戶的電子門禁資格憑證——他不需要隨身帶實體鑰匙（access key），管委會根據他的住戶身分動態核發當下需要的通行權（temporary credentials via STS）。Secrets Manager 則是「每月自動換密碼的保險箱組合鎖」——每 30 天組合碼自動換新（rotation Lambda），住戶每次都要重新查詢新密碼，舊密碼自動作廢。運算工作負載安全性的精髓是：永遠不要把通行密碼寫死在程式碼或 user data 裡——讓 AWS 動態核發、定期輪替、按需查詢。

Frequently Asked Questions

Q1：Amazon Inspector v2 與 Inspector classic 有何差異？SCS-C02 考哪個？

Inspector classic 是以 Agent 為基礎、按需執行的評估服務，對 EC2 執行個體執行排程掃描。Inspector v2（2026 年起正式更名為「Amazon Inspector」）是持續、帳號範圍的掃描器，涵蓋 EC2、ECR 及 Lambda，並使用 SSM agent 收集資料——無需獨立的 Inspector agent。SCS-C02 只考 Inspector v2。若你在答案選項中看到「assessment template」或「rules package」，這些是 Inspector classic 的詞彙，幾乎都是干擾選項。2026 年運算工作負載安全性的預設就是 v2。

Q2：Inspector v2 如何在沒有 Inspector 專屬 Agent 的情況下偵測弱點？

Inspector v2 搭便車利用已預先安裝於 Amazon Linux、Ubuntu（近期版本）及 Windows Server AMI 上的 AWS Systems Manager（SSM）agent。SSM agent 依排程收集軟體物料清單（SBOM）並透過內部控制平面轉送至 Inspector。對於 ECR，Inspector 直接從倉庫讀取映像 manifest。對於 Lambda，Inspector 讀取部署套件中繼資料。運算工作負載安全性的含義是：確保 SSM agent 透過執行個體設定檔（instance profile）及 AmazonSSMManagedInstanceCore 政策擁有 IAM 權限，並且網路可抵達 SSM 端點，否則 Inspector 會靜默略過該執行個體。

Q3：讓 EC2 執行個體可被 Inspector 掃描並被 Patch Manager 修補所需的最小 IAM 政策是什麼？

將 AWS 受管政策 AmazonSSMManagedInstanceCore 附加至執行個體角色。此政策授予 SSM agent 登錄、傳送心跳、取得 SSM 文件及回報清單所需的 API 權限。Patch Manager 與 Inspector v2 都依賴這個相同的基準。可選擇性加入 AmazonInspector2ManagedCisPolicy 以進行 CIS 基準掃描。請保持政策精確：永遠不要對執行個體角色授予 ssm:* 上的 * 權限。這是 SCS-C02 情境題中常見的運算工作負載安全性錯誤設定。

Q4：在運算工作負載安全性中，何時應使用 Secrets Manager 而非 Parameter Store SecureString？

以下情況使用 Secrets Manager：（1）機密需要自動輪換（資料庫密碼、OAuth Token）；（2）機密透過資源政策跨帳號共享；（3）需要與 RDS、Redshift 或 DocumentDB 的內建整合。以下情況使用 Parameter Store SecureString：（1）機密量少（每月讀取次數 < 10,000 次）；（2）輪換為手動或透過自訂 Lambda；（3）成本考量——Parameter Store 標準層免費，Secrets Manager 每個機密每月收 $0.40 外加每次 API 呼叫費用。對於純設定（非敏感），使用 Parameter Store 標準（String）參數。當需求中出現「自動輪換」時，考試答案通常選擇 Secrets Manager。

Q5：如何在整個 AWS Organization 中強制執行 IMDSv2？

三個層次，依強制力由弱至強：（1）帳號層級預設：在 EC2 主控台的「資料保護與安全性」中，將「執行個體中繼資料預設值」設定為 HttpTokens = required，新執行個體繼承此設定。（2）啟動範本：將 MetadataOptions: { HttpTokens: required, HttpPutResponseHopLimit: 1 } 烘焙至每個啟動範本。（3）服務控制政策（SCP）：在 Organizations OU 層級，於 ec2:MetadataHttpTokens != required 時拒絕 ec2:RunInstances——這是防彈護欄，因為它能阻止人工與自動化的繞過行為。大規模運算工作負載安全性永遠使用 SCP 作為最外層防護。

Q6：EC2 Image Builder 流水線產生什麼，以及如何部署至艦隊？

Image Builder 流水線執行配方、執行建置階段元件（安裝 agent、套用 CIS 強化）、執行測試階段元件（驗證強化）、產生 AMI（或容器映像），並套用發布設定，將 AMI 複製至目標 Region、與目標帳號共享，並可選擇性地以新 AMI ID 更新 Parameter Store 中的參數。若要部署至艦隊，可讓 Auto Scaling group 的啟動範本指向 Parameter Store 參照（例如 resolve:ssm:/golden-ami/amzn2-latest）；當 Image Builder 更新該參數時，ASG 執行個體重新整理便將艦隊滾動至新 AMI。這是 SCS-C02 上的標準運算工作負載安全性流水線模式。

Q7：運算工作負載安全性如何與 AWS Security Hub 整合以實現集中可視性？

Security Hub 匯總來自 Inspector v2（CVE、網路可達性）、Systems Manager Compliance（修補合規性）、AWS Config（資源合規性規則，含 ec2-imdsv2-check 與 ec2-managedinstance-patch-compliance-status-check）、GuardDuty（執行時期威脅）以及 IAM Access Analyzer 的發現項目。所有發現項目都正規化為 ASFF 格式，以嚴重性、資源及修補指引呈現於單一窗格上。從 Security Hub，EventBridge 規則扇出自動修補動作（Lambda、Step Functions、SSM Automation）。對於 SCS-C02，請記得：Security Hub 是匯總者，而非偵測者——Inspector 偵測，Patch Manager 修補，Security Hub 顯示。

Exam-Ready Summary

SCS-C02 的運算工作負載安全性可歸結為七服務模式：Amazon Inspector v2（持續掃描 EC2、ECR、Lambda）、AWS Systems Manager Patch Manager（依群組、基準、視窗套用修補程式）、EC2 Image Builder（烘焙強化黃金 AMI）、IAM（執行個體角色 + iam:PassRole 控制）、IMDSv2（基於 Token 的中繼資料、跳數限制 1、SCP 強制執行）、AWS Secrets Manager / Parameter Store（零寫死憑證）以及 AWS Security Hub（匯總、路由、自動化）。

請內化運算工作負載安全性自動化鏈路：Inspector 發現項目 → Security Hub ASFF → EventBridge 規則 → Step Functions 或 SSM Automation runbook → 修補 / 重建 / 重新整理 → Inspector 重新掃描確認。請內化不可變基礎設施的思維：只要可能，Image Builder 優先於就地修補。請內化憑證傳遞規則：永遠不要寫死、對 IAM 永遠使用角色、對敏感資料使用 Secrets Manager、對設定使用 Parameter Store。運算工作負載安全性是三個 Security Hub 支柱（偵測、回應、治理）與 Domain 3 最大任務的結締組織——給予它應有的學習時間。

繼續閱讀 Edge Security: CloudFront, WAF, Shield（Task 3.1）、Network Security: VPC Controls（Task 3.2）以及 Threat Detection: GuardDuty + Security Hub（Domain 1），完成基礎設施安全性與偵測鏈路。