Amazon SCS-C02: 漏洞、修補與主機安全 — 學習指南
屬於 AWS Security Specialty SCS-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
Amazon Inspector：跨 EC2、Lambda 與 ECR 的增強型掃描
Amazon Inspector 是一項持續性、由代理程式支援的漏洞管理服務，可發現在 EC2 執行個體、儲存於 ECR 的容器映像檔，以及 Lambda 函式（包含應用程式碼與相依性層）中的 CVE。在帳戶層級啟用 Inspector 會自動納入所有符合條件的資源——沒有逐一資源選擇加入的工作流程——且掃描結果會自動以標準化的 ASFF 格式推送到 AWS Security Hub，當需要一個集中式的安全狀態儀表板時，這是正確的整合模式。
針對 EC2，Inspector 採用混合式掃描模型。SSM Agent（搭配 AWS 提供的關聯）會收集軟體清單，用於無代理程式風格的網路可達性與套件評估；而深度主機評估則要求代理程式正在執行，且執行個體可透過 SSM 存取。這就是為什麼「僅限無代理程式」的方法是個陷阱：若沒有 SSM Agent 的路徑（或在需要時 Inspector 基於代理程式的深度檢測），您只會得到淺層的結果——如網路曝險和從資訊清單衍生的 CVE——但會錯失執行期函式庫清單、非受管套件與組態。混合模式才是大多數生產環境真正需要的。
針對 Lambda，Inspector 執行兩種掃描類型：標準掃描（掃描 Layer 和函式相依性中的套件漏洞）與程式碼掃描（對函式程式碼進行靜態分析，以找出注入攻擊漏洞、寫死的密鑰和不安全的 API）。一項關鍵的資格規則是：Lambda 函式必須在過去 90 天內至少被叫用過一次才能被掃描。閒置或已封存的函式會默默地從 Inspector 的掃描範圍中移除。那些以為「Inspector 已啟用，所以每個函式都有涵蓋到」的團隊，在稽核人員要求提供關於罕見執行函式的證據時，就會嘗到苦果。補救方法是透過 EventBridge 定期叫用函式，或是接受此排除情況並將其文件化。
針對 ECR，增強型掃描（由 Inspector 提供支援）取代了基於 Clair 的舊版基本掃描。增強型掃描同時支援推送時掃描與對已在登錄檔中的映像檔進行持續掃描，因此，針對先前已推送映像檔新揭露的 CVE，不需重新推送即可產生新的掃描結果。在登錄檔層級啟用增強型掃描，並針對每個儲存庫設定篩選條件（例如，prod/* 持續掃描，sandbox/* 僅推送時掃描）以控制成本。
委派管理與抑制規則
在多帳戶的 AWS Organizations 設定中，從管理帳戶為 Inspector 指定一個委派管理員帳戶。該委派管理員可以看到跨成員帳戶的彙總結果，並控制整個組織的掃描組態。這避免了為了擷取結果而授予跨帳戶 IAM 角色，並防止了逐一帳戶零散地啟用 Inspector 的反模式。
抑制規則讓安全團隊能夠過濾雜訊，而無需刪除結果。規則可以根據資源標籤、嚴重性、CVE ID 或 ECR 儲存庫等屬性進行匹配。為了讓開發/測試環境的 Lambda 結果不要出現在生產環境的儀表板上，可以應用一條基於標籤 Environment=dev 的抑制規則——這些結果仍然存在於底層資料儲存庫中以供稽核，但它們會從預設視圖中被排除，如果設定了，也會從 Security Hub 中排除。不要為了達到此目的而停用開發帳戶的 Inspector；這樣做會讓您失去捕捉到有漏洞的產物從開發環境晉升到生產環境的能力。
映像檔晉升的 CI/CD 閘門控制
增強型 ECR 掃描產生的結果會與映像檔 digest（不僅是標籤）綁定，這才是管線必須查詢的對象。標準的模式是：建置映像檔 → 推送到 ECR（觸發推送時掃描）→ 輪詢或等待掃描完成 → 如果存在高或嚴重等級的結果，則建置失敗 → 否則更新 ECS/EKS 的任務/部署。
buildspec.yml 中一個最小的 CodeBuild 步驟：
post_build:
commands:
DIGEST=$(aws ecr describe-images --repository-name $REPO \
--image-ids imageTag=$TAG --query 'imageDetails[0].imageDigest' -o text)
aws inspector2 list-findings \
--filter-criteria "{\"ecrImageHash\":[{\"comparison\":\"EQUALS\",\"value\":\"$DIGEST\"}],\"severity\":[{\"comparison\":\"EQUALS\",\"value\":\"HIGH\"},{\"comparison\":\"EQUALS\",\"value\":\"CRITICAL\"}]}" \
--query 'findings[].findingArn' --output text > findings.txt
- if [ -s findings.txt ]; then echo "Blocking - CVEs found"; exit 1; fi
在這個階段未能設置閘門控制——僅相信「Inspector 會提醒我們」——是典型的錯誤：警報是非同步到達的，而且是在有漏洞的映像檔已經在執行之後。閘門控制必須與晉升同步。同樣地，僅根據標籤而非 digest 進行閘門控制是不安全的，因為標籤是可變的；兩次使用相同標籤的推送會混淆掃描結果。
Patch Manager、修補基準與修補群組
SSM Patch Manager 運作基於三個基本元件：
修補基準 (Patch baseline): 定義自動核准規則、已核准的修補程式、已拒絕的修補程式，以及根據嚴重性/分類的合規等級。
修補群組 (Patch group): 一個金鑰剛好為
Patch Group的標籤，其值會將執行個體註冊到特定的修補基準。維護時段 (Maintenance window):
AWS-RunPatchBaseline執行掃描或安裝任務的排程時段。
對於一個要求開發環境立即自動核准所有安全性修補程式，而生產環境則在 7 天的浸泡期後僅自動核准嚴重/重要等級的修補程式，同時拒絕核心套件的環境，您需要建立兩個修補基準。開發環境的基準使用一個 ApproveAfterDays: 0 的核准規則，涵蓋所有安全性分類。生產環境的基準則使用 ApproveAfterDays: 7、ComplianceLevel: CRITICAL，篩選 Classification=Security 且 Severity in [Critical, Important]，並將 kernel* 加入到拒絕的修補程式清單中，並設定 BlockAllPatchesFromRejectedList。執行個體被標記為 Patch Group=Dev 或 Patch Group=Prod，且每個修補群組都註冊到對應的修補基準。合規性會透過 Patch Compliance 報告彙總，並可匯出到 S3 以供集中稽核。
單一的「帶有邏輯」的修補基準無法表達開發與生產環境的差異——修補基準對於每個註冊的群組是靜態的。不要試圖使用不同的維護時段來偽造這種行為；維護時段控制的是修補何時執行，而不是哪些修補程式被核准。
即時通知管道
若要針對新的發現結果在 Slack 或 Microsoft Teams 上發出警報，營運效率最高的串接方式是：
Inspector 將發現結果透過
aws.inspector2事件來源發送到 EventBridge。EventBridge 規則 依嚴重性（例如
HIGH、CRITICAL）進行過濾，並以一個 SNS 主題為目標。SNS 主題 有一個 AWS Chatbot 訂閱，對應到 Slack 頻道或 Teams 工作區。
Chatbot 直接訂閱 SNS — 不要在中間放置 Lambda 來重新格式化訊息，因為 Chatbot 原生就能呈現 Inspector 的發現結果。一個 EventBridge 模式範例如下：
{
"source": ["aws.inspector2"],
"detail-type": ["Inspector2 Finding"],
"detail": { "severity": ["HIGH", "CRITICAL"] }
}
這裡有兩個要避免的陷阱：透過 Security Hub 路由會增加延遲，且如果自訂洞見設定錯誤，可能會遺失嚴重性的粒度；而使用 SES 或自訂的 webhook Lambda 會增加維運負擔，卻沒有增加 Chatbot 原生已提供的功能。
實務問題：使用案例情境
情境： Meridian Financial 公司營運一個多帳戶的 AWS Organization，用以支援面向客戶的 Web 服務、批次分析以及無伺服器事件處理器。他們的 CI/CD 管道會將容器映像檔推送到 Amazon ECR，他們為舊有工作負載託管 EC2 機群，並為較新的服務使用 Lambda；一個位於安全帳戶中的中央安全團隊，必須管理跨帳戶的漏洞可見性與修補作業。
挑戰： 最近一個包含高嚴重性函式庫的映像檔被晉升到生產環境，因為在 CI/CD 中並未強制執行掃描，且跨環境的 EC2 執行個體修補作業不一致，這留下了曝險視窗和過多雜訊的發現結果，讓團隊不堪負荷。
建議方法：
- 從安全帳戶啟用橫跨 EC2、Lambda 和 ECR 的 Amazon Inspector 增強型掃描，方法是在 AWS Organizations 中設定委派管理，如此一來掃描、發現結果和抑制規則便可被集中管理。
- 設定 ECR 映像檔在推送時進行掃描，並將掃描閘門整合到 CodePipeline/CodeBuild 中：阻擋映像檔的晉升，直到 Inspector/ECR 的掃描結果符合嚴重性閾值，並透過建置步驟呈現發現結果。
- 實作 AWS Systems Manager Patch Manager，為每個環境定義修補基準和修補群組，排定維護時段以進行「先非生產環境」的部署，並使用 SSM Automation 文件來自動化核准重大的 CVE 修復。
- 使用 Amazon EventBridge 建立一個即時通知管道，以擷取 Inspector 的發現結果和 SSM 的合規性事件，將它們路由到 Amazon SNS 和一個輕量級的 AWS Lambda，該 Lambda 會豐富化、去重複並將有優先級的警報發布到 Slack 並建立追蹤工單。
- 自動化圍堵與修復：使用由 EventBridge 觸發的 SSM Automation 或 Lambda 執行手冊，來隔離受影響的 EC2/Lambda 版本或觸發映像檔重建，並透過委派管理帳戶僅對已追蹤的誤報套用 Inspector 抑制規則，以減少雜訊。
理由： 集中式的 Inspector 管理、CI/CD 閘門管控、Patch Manager 修補基準，以及由 EventBridge 驅動的管道，遵循了 AWS 的最佳實踐，透過強制執行自動化預防、一致的修補，以及有優先級且可稽核的回應，同時減少了警報疲勞。
使用 Amazon Inspector 進行漏洞探索
Amazon Inspector 是 AWS 上主要的託管式漏洞評估服務，它在三個與主機安全相關的層面上運作：EC2 執行個體、Amazon ECR 中的容器映像檔，以及 Lambda 函式。當在帳戶或 Organizations 層級（透過 Inspector 主控台中的委派管理員）啟用時，它會執行持續性、無代理程式或基於 SSM 的掃描，而非排程的單一時間點掃描。這種持續性的態勢很重要，因為 CVE 的資訊來源每日都在變動；上週的快照可能早已過時。
對於 EC2，Inspector 依賴 SSM Agent 來列舉已安裝的套件和核心版本，然後將它們與供應商公告和國家漏洞資料庫進行關聯比對。發現結果包含 CVE 識別碼、CVSS 分數、受影響的套件、已修復的版本，以及網路可達性情境（網路可達性規則會識別透過 ENI、安全群組、NACL 和路由表暴露於網際網路的連接埠）。由於掃描依賴 SSM，一個在其執行個體設定檔上缺少 AmazonSSMManagedInstanceCore 託管策略的 EC2 執行個體，將根本不會出現在 Inspector 的結果中——這是一個值得記住的無聲失敗。
對於 ECR，Inspector 支援兩種掃描模式：
基本掃描： 免費，使用開源的 Clair 引擎，僅在推送時或隨需執行。
增強型掃描： 由 Inspector 提供支援，當新的 CVE 發布時，會持續重新掃描映像檔（包括作業系統套件和應用程式語言套件，如 Python、Node、Java），即使在推送事件發生很久之後也是如此。
一個常見的陷阱是將 ECR 的「推送時掃描」視為足夠的主機安全性。事實並非如此。「推送時掃描」在建置時驗證映像檔，但執行中的容器繼承了該映像檔外加任何的漂移，且底層的 EC2 或 Fargate 主機有其自身的核心和作業系統套件，必須獨立進行修補。增強型掃描結合 EC2 主機掃描彌補了這個差距。所有 Inspector 的發現結果都應被路由到 AWS Security Hub，它會將這些結果標準化為 ASFF 格式，並透過 EventBridge 實現跨帳戶彙總、去重複以及下游的自動化。
Patch Manager 與全機隊修復
AWS Systems Manager Patch Manager 透過實際修復 Inspector 所發現的問題，來補足其功能。Inspector 回答的是「哪些 CVE 會影響我？」，而 Patch Manager 回答的則是「缺少哪些修補程式，以及如何安全地安裝它們？」
Patch Manager 透過 patch baselines (修補基準) 運作——這是一種宣告式的規則，用來定義哪些修補程式可被核准，其依據包含分類 (安全性、重大、錯誤修復)、嚴重性，以及自動核准延遲 (例如，在安全性修補程式發布七天後核准，以確保供應商的穩定性)。AWS 為每個作業系統提供預設的基準 (例如 AWS-AmazonLinux2DefaultPatchBaseline、AWS-WindowsPredefinedPatchBaseline 等)，但正式環境的機隊通常會使用自訂的基準，並透過執行個體上的 Patch Group 標籤與 patch groups 綁定。
一個典型的掃描與修補工作流程會使用兩種操作：
Scan (掃描)：回報合規性狀態，但不安裝任何東西；結果會顯示在 Patch Manager 的合規性儀表板和 Config 中。
Install (安裝)：套用已核准的修補程式，並且對許多作業系統而言，會重新開機。
這些操作通常透過 maintenance windows (維護時段) 來排程，並以 AWS-RunPatchBaseline 文件為目標。對於緊急的零時差攻擊情境，Patch Manager 提供 Patch Now 功能，這是一個隨選執行的動作，可以繞過維護時段的排程。建議的模式是建立一個範圍狹窄的修補基準，只核准修復該漏洞的特定 KB 或套件，鎖定受影響的 patch group，執行 Patch Now，並將執行輸出串流到一個集中的 S3 儲存貯體和 CloudWatch Logs 群組。這個集中的日誌就成為您的稽核成品——為稽核人員或事件應變提供修復證明。
實務問題：使用案例情境
情境： Meridian Financial 公司在一個多帳號的 AWS 環境中營運，擁有數百個 EC2 執行個體 (Windows 和 Amazon Linux) 以及一個小型的 EKS 叢集，用以支援面向客戶的服務。他們使用 AWS Organizations、AWS Systems Manager 進行維運工具管理，並在一個共享的映像檔帳號中維護 AMI，但他們在各帳號之間缺乏一致的自動化漏洞掃描或協調的修補程式部署。
挑戰： 一個影響 OpenSSL 的 CVE 被公開揭露，Amazon Inspector 在多個執行個體上回報了高風險的發現項目，但修補工作一直不一致，其中一個正式環境的服務因延遲修復而經歷了一次短暫的攻擊嘗試。
建議方法：
- 在所有帳號和區域啟用 Amazon Inspector，以執行映像檔和執行中執行個體的漏洞掃描，並將高嚴重性的發現項目轉發到 AWS Security Hub 和一個 EventBridge 自訂事件匯流排。
- 使用 AWS Systems Manager Inventory 來識別受影響的執行個體，並根據其重要性進行標記；建立一個包含所需 OpenSSL 修復程式的 Patch Manager 基準，並設定針對 Windows/Linux 的規則。
- 建立一個 EventBridge 規則，當 Inspector 的發現項目達到定義的嚴重性時，觸發一個 SSM Automation 文件，將執行個體 ID 列表傳遞給一個 Automation runbook，該 runbook 會調用 Patch Manager 或 Run Command 來套用修補程式並在需要時重新開機。
- 對於有狀態或高風險的服務，使用 EC2 Image Builder 來烘焙已修補的 AMI，並透過受控的藍/綠部署或滾動部署來更新 Auto Scaling 群組或 EKS 節點群組，藉此協調滾動更新，並使用 Route 53/ALB 的運作狀態檢查來驗證服務健康狀況。
- 修復完成後，重新執行 Amazon Inspector 以驗證發現項目已解決，更新 SSM Compliance 報告，並透過 SNS 將摘要發送給資安團隊；將該 Automation runbook 保存在 Systems Manager Automation 程式庫中，以供未來重複執行全機隊範圍的回應。
基本原理： 此方法利用 Amazon Inspector 進行持續的探索，使用 Systems Manager Patch Manager 和 Automation 進行受控的自動化修復，並透過基於映像檔的重建來實現不可變基礎設施，這與 AWS 在偵測、自動化回應和最小化衝擊半徑方面的最佳實踐相符。
# Example: focused baseline for an urgent CVE
Name: emergency-openssl-cve
OperatingSystem: AMAZON_LINUX_2
ApprovalRules:
PatchRules:
- PatchFilterGroup:
PatchFilters:
- Key: PRODUCT
Values: [AmazonLinux2]
- Key: CVE_ID
Values: [CVE-2024-XXXXX]
ApproveAfterDays: 0
ComplianceLevel: CRITICAL
透過在 Systems Manager Explorer 中設定委派管理員帳號，並啟用 resource data sync，可以實現集中化的合規性管理。這會將每個帳號的修補合規性狀態彙總到一個單一的 S3 儲存貯體中，然後可以使用 Athena 進行查詢或在 QuickSight 中進行視覺化。
Session Manager 用於可稽核的管理
傳統基於 SSH 的存取有三個結構性弱點：長期的金鑰資料存放在操作人員的筆記型電腦上、port 22 必須是可連線的 (即使只是透過堡壘主機)，以及若無額外工具，shell 活動不會被集中記錄。Session Manager 消除了這三個弱點。
Session Manager 透過 SSM Agent 到 SSM 端點的對外 HTTPS 連線，來建立一個互動式 shell 的通道。沒有傳入的連接埠、沒有 SSH 金鑰對，也沒有堡壘主機。存取權限由 IAM 政策授權 (ssm:StartSession，範圍可限定於執行個體標籤或 ARN)，且每個工作階段都可以記錄到 CloudWatch Logs 或 S3，並可選擇性地使用 KMS 加密。在 Linux 上，工作階段預設以 ssm-user 身分執行；sudo 行為由執行個體的 sudoers 設定檔控制，而非 IAM。
對於新的機隊，正確的強化模式是：啟動執行個體時不使用 EC2 金鑰對，附加一個帶有 AmazonSSMManagedInstanceCore 的執行個體設定檔，將執行個體放置在具有 ssm、ssmmessages 和 ec2messages 的 VPC 端點的私有子網路中，並在 Session Manager 的偏好設定層級強制執行工作階段日誌記錄。在採用 Session Manager 的同時繼續分發 SSH 金鑰是一個陷阱：它保留了 Session Manager 本應消除的攻擊面，並留下了一個未被記錄的存取通道。請從您的 AMI 烘焙流程中移除 authorized_keys 的配置。
使用 CloudWatch Agent 進行主機遙測
統一的 CloudWatch 代理程式會收集 EC2 hypervisor 無法看到的作業系統層級指標（記憶體、磁碟、每個程序的 CPU）和日誌檔案。它的設定是透過一個 JSON 檔案，該檔案通常儲存在 Parameter Store 中，然後使用 amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c ssm:AmazonCloudWatch-linux 來套用。
此代理程式最常見的操作失敗原因是執行個體設定檔缺少 IAM 權限。代理程式至少需要：
logs:CreateLogGroup（除非群組已預先建立）
logs:CreateLogStream
logs:PutLogEvents
logs:DescribeLogStreams
cloudwatch:PutMetricData（用於自訂指標）
ssm:GetParameter（從 Parameter Store 取得設定）
受管政策 CloudWatchAgentServerPolicy 包含了這些權限。當權限不足時，代理程式雖然能成功啟動，且在 systemctl status 中顯示為健康狀態，但日誌永遠不會送達 CloudWatch — 失敗訊息只會出現在 /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log 中。任何仰賴集中化日誌的主機安全設計，都必須驗證日誌是否確實送達，而不只是檢查代理程式的狀態。
總結
整個防禦循環是：Inspector 發現主機和容器映像檔上的 CVE，發現項目流入 Security Hub 進行彙總，Patch Manager 透過排定的維護時段或在緊急情況下使用 Patch Now 進行修補，Session Manager 提供唯一的管理存取路徑，而 CloudWatch 代理程式則將修補證據和執行階段日誌串流至一個集中化的帳戶。每個控制措施都與其他措施環環相扣：沒有 Patch Manager 的 Inspector 只會產生無人處理的報告；沒有集中化日誌的 Patch Manager 無法產生稽核軌跡；沒有適當 IAM 的 Session Manager 會導致權限過多或過少；而沒有正確日誌權限的 CloudWatch 代理程式則會產生一種具有可見度的假象。
← 治理、組態與自動化 · 所有領域 · 容器與無伺服器安全 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →