Amazon SCS-C02: 容器與無伺服器安全 — 學習指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

使用 ECS Exec 進行執行期檢查，無需 SSH

ECS Exec 提供一個進入執行中容器（包含 Fargate 任務）的互動式 shell，無需暴露 SSH、堡壘主機或公用 IP。它透過 AWS 注入到任務側邊車執行環境中的 SSM agent 來運作。因為沒有 SSH 精靈、沒有金鑰資料、也沒有需要保護的傳入網路路徑，所以維運開銷極小，且每個會話都可透過 CloudTrail 進行稽核，並可（選擇性地）記錄到 S3 或 CloudWatch Logs。

必須同時滿足三個要求，ECS Exec 才能運作：

任務角色權限： 任務角色（而非執行角色）需要 ssmmessages:CreateControlChannel、ssmmessages:CreateDataChannel、ssmmessages:OpenControlChannel 和 ssmmessages:OpenDataChannel 權限。執行角色只負責拉取映像檔和寫入日誌；執行期的 SSM 流量是透過任務角色流動，因為容器程序是採用該角色的身份。
服務或任務組態： 服務必須在建立或更新時加上 --enable-execute-command。這個旗標會為新任務開啟 enableExecuteCommand；現有的任務必須被替換。
容器映像檔支援： 容器映像檔中需要有 shell（/bin/sh 或 /bin/bash）。

一個典型的檢查流程如下：

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

工程師可以從該 shell 將日誌複製到 S3、觸發記憶體傾印（heap dump），或讀取 /proc 進行鑑識。另一種方法——試圖透過 SSH 連接到容器，或重新啟動任務以啟用除錯代理——在 Fargate 上要嘛會失敗，要嘛會銷毀您試圖收集的證據。

在 EC2 上阻擋容器存取 IMDS

一個常見的誤解是，EC2 執行個體上的 IMDSv2 躍點限制（hop-limit）設定可以保護該執行個體上的容器。事實並非如此，至少在預設的 bridge 或 host 網路模式下不行：容器共享主機的網路命名空間或 NAT 橋接，因此可以連到 169.254.169.254 並取得執行個體設定檔的憑證，而這些憑證的權限通常遠高於任務角色。這完全違背了最小權限原則。

當無法遷移到 Fargate 時，解決方法有兩部分：

為任務使用 awsvpc 網路模式。 每個任務都會獲得自己的 ENI 和網路命名空間。IMDS 流量不再能透明地到達主機的鏈路本機端點。
在容器執行個體的 /etc/ecs/ecs.config 中設定 ECS_AWSVPC_BLOCK_IMDS=true。 這會告知 ECS agent 安裝一條 iptables 規則，丟棄從 awsvpc 任務發往 169.254.169.254 的封包。

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

將此方法與一個最小權限的執行個體設定檔（基本上只包含 ECS agent 所需的權限：AmazonEC2ContainerServiceforEC2Role）以及為應用程式權限設定的個別任務 IAM 角色結合使用。將執行個體的 IMDS 躍點限制設為 1 並要求使用 IMDSv2 是一種有用的深度防禦措施，但不能作為替代方案——因為請求源自於主機，bridge 模式的容器仍然可以在躍點 1 到達 IMDS。

GuardDuty 執行期監控、EKS 保護與控制平面日誌

GuardDuty 提供分層的容器偵測功能：

EKS Protection 分析 EKS 的稽核日誌，以偵測可疑的 Kubernetes API 活動——例如匿名存取、建立特權 pod、或對系統 pod 執行 exec。
執行期監控 部署一個基於 eBPF 的感測器（在 EKS 中作為託管附加元件，或在 ECS/Fargate 中作為 SSM 管理的代理），觀察容器內的程序、檔案和網路活動。它會揭露如反向 shell、加密貨幣挖礦二進位檔，以及從 Pod 或任務內部進行的憑證外洩等發現項目。

除非 EKS 控制平面的稽核日誌確實被傳送到 CloudWatch Logs，否則 EKS Protection 毫無用處。在叢集上至少啟用 audit 和 authenticator 這兩種日誌類型：

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

若沒有這些日誌，GuardDuty 就沒有資料平面可以檢查 EKS Protection 的發現項目——這是一個常見的陷阱，因為維運人員啟用了 GuardDuty 功能，卻關閉了叢集的日誌組態，然後納悶為什麼都沒出現 Kubernetes 相關的發現項目。

使用 ECR 增強型掃描進行映像檔掃描

ECR 增強型掃描由 Amazon Inspector 提供支援，可持續掃描容器映像檔中的作業系統與語言套件（Python、Node、Java、Go、Ruby）的 CVEs。基本掃描是在推送時進行的一次性掃描，且只涵蓋作業系統套件；增強型掃描則是持續性的，並包含應用程式相依套件，而這正是大多數現代漏洞所在之處。

當這兩項服務都啟用時，發現項目會自動流向 Security Hub，提供一個單一管理平台來檢視合規性，並讓您能撰寫 EventBridge 規則來使不合規的 CI/CD 建置失敗。一個典型的強制執行模式：

實務問題：使用案例情境

情境： NovaTech 公司在混合運算環境中執行面向客戶的微服務：包含數個建於 EC2 上的 ECS 叢集、一個用於資料處理的 EKS 叢集，以及用於事件處理的無伺服器 Lambda。映像檔儲存在 ECR，維運團隊使用 SSM 進行主機存取，而已啟用的 GuardDuty/CloudWatch 對於容器和控制平面元件的可視性卻不一致。

挑戰： 一個生產環境的容器出現可疑的對外連線，且一位工程師發現某個 Pod 能夠存取 EC2 執行個體中繼資料服務，這有憑證外洩的風險；映像檔的漏洞和不足的控制平面日誌，可能隱藏了問題的根本原因。

建議方法：

為任務啟用 ECS Exec，並要求使用 AWS Systems Manager Session Manager 進行主機和容器執行期的檢測 (ECS Exec + SSM)，從而移除對 SSH 的需求，並確保所有會話活動都記錄到 CloudTrail 和 CloudWatch Logs。
在 EC2 執行個體上強制使用 IMDSv2 (執行個體中繼資料服務設定為 HttpTokens=required, hop limit=1)，並應用主機層級的網路規則，從容器的網路命名空間中阻擋 169.254.169.254，使容器無法查詢執行個體中繼資料。
為容器和 Lambda 開啟 Amazon GuardDuty 執行期監控與惡意軟體防護，並將發現的結果轉發到 Security Hub 和 EventBridge，以執行自動化的圍堵劇本。
透過將控制平面日誌 (audit, authenticator, controllerManager, scheduler) 傳送到 CloudWatch Logs 來強化 EKS，採用 IAM Roles for Service Accounts (IRSA)，並強制實施准入控制 (Pod Security 或 OPA Gatekeeper) 以限制高風險的權能。
啟用 Amazon ECR 增強型映像檔掃描 (Inspector/ECR 掃描) 並設定推送時掃描，同時將掃描結果整合到 CI 流程中，透過 EventBridge + Lambda 來阻擋或隔離有問題的映像檔以強制執行。
集中化遙測資料：將 CloudTrail、GuardDuty 的發現、EKS 控制平面日誌以及 ECR 掃描結果傳送到一個集中的 S3/Lambda/Security Hub 管線，並將資料提供給 AWS Config 規則以達成持續合規。

理由： 此一系列步驟移除了基於 SSH 的存取方式、防止中繼資料憑證被竊、提供執行期偵測與自動化應對、強制實施映像檔的健康管理，並提供了控制平面的可視性——這與 AWS 的最小權限、縱深防禦及集中式可觀測性等最佳實踐相符。

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

將掃描整合到管線中，才能使其從儀表板上的演練，轉變為真正的管控措施。

Lambda：授權方、機密與執行角色

Lambda 函數層級的安全性有三個經常被混淆的面向：

資源政策 (函數政策)： 控制哪些主體 (API Gateway、EventBridge、其他帳戶) 可以叫用此函數。API Gateway 上的 Lambda 授權方是 HTTP 呼叫者的身份閘門——它們會回傳一個 IAM 政策，API Gateway 在叫用後端函數前會快取並強制執行此政策。
執行角色： 函數程式碼在執行期所擔任的身份。其信任政策必須包含 lambda.amazonaws.com，並且必須授予 logs:CreateLogGroup、logs:CreateLogStream 和 logs:PutLogEvents 權限，CloudWatch Logs 才能正常運作。如果日誌遺失，修復方法幾乎總是在執行角色上——而不是 Lambda 主控台，主控台僅是呈現 CloudWatch 收到的任何日誌。單獨依賴「主控台日誌」是一個診斷陷阱：沒有執行角色的權限意味著沒有日誌串流，主控台也就不會顯示任何東西。
機密擷取： 絕不要將憑證以明文形式寫死在環境變數中。應將它們儲存在 Secrets Manager 或 SSM Parameter Store SecureString 中，並在冷啟動時擷取：

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

執行角色需要對該 CMK 擁有 ssm:GetParameter 和 kms:Decrypt 權限。將機密快取在模組範疇內，這樣暖啟動的叫用就能避免 API 呼叫；對於更高吞吐量的函數，可使用 Secrets Manager Lambda extension 來進行具備自動輪替感知能力的快取。

ECR 加密與儲存庫保護

Amazon ECR 預設使用 AES-256 搭配 AWS 自管金鑰來加密所有靜態映像檔，但受監管的工作負載通常要求使用客戶自管的 KMS 金鑰，以便金鑰輪替、金鑰政策和 CloudTrail 的可稽核性都由客戶掌控。KMS 加密只能在儲存庫建立時進行設定；一個現有的 ECR 儲存庫事後無法從 AES-256 切換到 KMS。因此，遷移時需要建立一個新的、經 KMS 加密的儲存庫，複製或重新推送映像檔，更新下游的取用者，然後刪除舊的儲存庫。從一個經 KMS 加密的儲存庫拉取映像檔的跨帳戶取用者，除了需要 ECR 的讀取權限外，還必須被授予對該 CMK 的 kms:Decrypt 權限，否則即使儲存庫政策允許該主體，拉取操作也會因 KMS 存取錯誤而失敗。

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

不可變標籤可以防止標籤劫持攻擊，這種攻擊會在掃描後，將一個已驗證的 v1.2.3 標籤悄悄地用惡意映像檔覆寫。

映像檔掃描：基本、增強與 Inspector

ECR 提供兩種掃描模式。基本掃描使用開源的 Clair CVE 資料庫，只在推送 (或手動觸發) 時執行，並在 ECR 主控台中回報結果。這項功能是免費的，但它不會執行持續重新掃描，也無法同時涵蓋作業系統 (OS) 和程式語言套件，並且沒有與 Security Hub 的原生整合。增強掃描由 Amazon Inspector 提供支援，涵蓋作業系統套件和應用程式語言套件 (Python、Java、Node.js、Go、Ruby、.NET)。Inspector 會根據最新的漏洞情報持續監控已推送的映像檔，因此即使某個 CVE 在映像檔推送一週後才被揭露，仍然會產生一個發現項目，而無需重新建置。

增強掃描是在登錄檔層級 (每個 Region) 啟用，並透過每個儲存庫的包含篩選條件 (inclusion filters)，使用如 prod-* 或 team-a/* 的萬用字元模式來設定。對於「掃描大部分儲存庫，但排除沙箱/實驗性儲存庫」這種常見需求，這是正確的控制方法——您應該定義正向的篩選條件來列出應掃描的對象，而不是對個別儲存庫設定反向的排除規則。

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Inspector 整合與 Security Hub 彙總

必須在需要掃描的每個帳戶和 Region 中啟用 Amazon Inspector。在 AWS Organizations 的設定中，安全工具帳戶會被指定為 Inspector 的委派管理員，這使其能夠啟用掃描、為新成員帳戶設定自動註冊，並檢視彙總的發現項目。忘記委派——或忘記切換自動註冊——是一種很細微的故障模式：新加入組織的帳戶會默默地將容器推送到 ECR，而這些容器從未被掃描，這在沒有任何錯誤訊息的情況下，破壞了掃描覆蓋率的保證。

當這兩項服務都啟用，且 Security Hub 的 Inspector 整合功能開啟時，Inspector 的發現項目會自動流入 AWS Security Hub。接著，Security Hub 會將發現項目標準化為 AWS 安全發現項目格式 (ASFF)，並將其與 GuardDuty、Macie 和 Config 的發現項目相互關聯，再結合委派的 Security Hub 管理員以及跨 Region 彙總功能，呈現出一個單一管理平台 (single pane of glass)。針對 Security Hub 發現項目的 EventBridge 規則可以將關鍵的 CVE 路由到 Lambda 以自動建立工單、用 quarantine=true 標籤標記有問題的映像檔，或透過 pipeline 閘門來阻擋部署。

集中式掃描與跨帳戶 CI/CD

對於多帳戶容器工作負載，建議的模式是以一個強化的中央登錄檔帳戶為核心：

中央帳戶： 託管經過 KMS 加密的 ECR 儲存庫，並啟用增強掃描、不可變標籤 (immutable tags) 和映像檔簽署 (透過與 AWS Signer 整合的 Notation/Sigstore)。
建置帳戶： 執行 CodeBuild/CodePipeline 任務，進行建置、推送到中央 ECR、等待 Inspector 的發現項目，並根據嚴重性閾值進行閘門控制。
工作負載帳戶 (開發/預備/生產)： 透過跨帳戶權限從中央登錄檔拉取映像檔。

跨帳戶讀取存取需要兩個層級的權限：一個在消費者帳戶中的 IAM 政策，授予 ecr:GetDownloadUrlForLayer、ecr:BatchGetImage 和 ecr:GetAuthorizationToken 權限；以及一個在中央帳戶 ECR repo 上的儲存庫政策 (repository policy)，允許特定的消費者帳戶或角色存取。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

由於 ECR 儲存庫政策是基於資源的，存取權限由身分政策和資源政策的交集決定——省略任何一個層級都會導致 AccessDeniedException。當涉及 KMS 時，KMS 金鑰政策也必須授予跨帳戶主體 kms:Decrypt 的權限。

EKS 控制平面日誌記錄與可觀測性

對於 EKS，其託管的控制平面無法直接存取，因此與安全相關的 Kubernetes 事件只有在明確啟用控制平面日誌記錄時才會被揭露。有五種日誌類型可用：api、audit、authenticator、controllerManager 和 scheduler。audit 日誌是價值最高的安全產物——它記錄了對叢集發出的每一次 API 呼叫，並透過 IAM authenticator 解析出呼叫者身分——而 authenticator 日誌則記錄了 IAM 到 Kubernetes RBAC 的映射決策。所有類型的日誌都會串流到 CloudWatch Logs 的 /aws/eks/<cluster>/cluster 日誌群組中，從那裡可以訂閱到 Kinesis Data Firehose、轉發到 S3 或傳送到 SIEM。

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

使用 GuardDuty EKS Protection (節點上的執行期威脅偵測) 來補充控制平面日誌，並使用 IRSA (IAM Roles for Service Accounts) 而非節點執行個體描述檔，這樣稽核日誌就能將 AWS API 活動歸因於特定的 pod。

常見陷阱

只依賴推送時掃描 (scan-on-push)： 基本的推送時掃描只能抓到推送當下已知的漏洞，但對於那些已經存在於 registry 中的映像檔，事後才揭露的 CVEs 就無能為力了。像 PCI DSS 和 FedRAMP 這類的稽核框架要求持續性的漏洞評估，這強制規定要使用 CONTINUOUS_SCAN 頻率的增強型掃描，並搭配 Security Hub 進行彙總。單次推送的快照式掃描無法滿足這項控制要求。

當要求靜態加密時，卻忽略在 ECR 上使用 KMS： 預設的 AES-256 加密的確是貨真價實的加密，但對於那些要求客戶自管金鑰 (customer-managed keys)、金鑰輪替紀錄，以及針對每個 principal 留下 kms:Decrypt 稽核軌跡的合規性制度而言，使用 AWS 自有金鑰是無法滿足的。由於每個 repository 的加密類型是不可變的，這個問題必須在建立時就解決——想著「我們之後再開啟」是不可能的，除非重建整個 repo。

忘記設定 Inspector 委派管理員或自動註冊： 如果沒有為 Inspector 設定委派管理員，每個帳號的擁有者都必須各自獨立地啟用掃描並轉發結果，這在操作上是不可行的，而且會產生覆蓋率的缺口。如果沒有為新成員帳號啟用自動啟用 (auto-enable for new member accounts)，那麼每個透過 Control Tower 或 Organizations 建立的新帳號，其 Inspector 預設都是停用的。如此一來，即使中央帳號的 Security Hub 顯示沒有任何發現，這些帳號裡的 ECR 映像檔也都是未經掃描的——這是一種無聲的偽陰性 (false-negative)，而不是一個明顯的錯誤。

實務問題：使用案例情境

情境： Meridian Financial 公司在一個多帳號的 AWS 環境中營運，其生產環境的 EKS 叢集、ECS 服務，以及多個 ECR registry 分散在 prod、dev 和一個專用的安全帳號中。他們的工程團隊透過 CI/CD pipeline 將容器映像檔推送到 ECR，並部署到 EKS/ECS，而安全團隊則維護一個中央帳號，用於監控與合規。

挑戰： 最近一次的部署，交付了一個帶有高嚴重性漏洞的容器，但在進入生產環境前並未被偵測到。調查人員發現 EKS control plane 的日誌有限，且掃描結果分散在各個帳號中，導致修復速度緩慢。

建議方法：

啟用 ECR repository 層級的保護：強制執行映像檔標籤不可變性 (image tag immutability)、套用 repository 政策以限制特定 IAM role 的推送/拉取權限，並使用專屬的 AWS KMS 客戶自管金鑰 (CMK) 對 repository 進行靜態加密。
開啟推送時映像檔掃描 (基本)，並啟用 Amazon Inspector 對 ECR 的增強型映像檔掃描以產出漏洞發現；將 Inspector 與 AWS Security Hub 整合，以便跨帳號集中彙總嚴重性等級。
實作集中式跨帳號掃描：設定 ECR 複寫，或授予安全帳號中的 CodeBuild/CodePipeline role 跨帳號的拉取權限，讓安全帳號能使用 Inspector 及任何額外的 SCA/DAST 工具掃描每一個映像檔，並將產出的成品儲存在一個使用安全帳號 CMK 加密的集中式 S3 bucket 中。
強制執行 CI/CD 閘門：在 pipeline 中增加一個掃描階段 (可使用 CodeBuild/CodePipeline 或帶有 STS assume-role 的 GitHub Actions)，該階段會查詢 Inspector/Security Hub 的發現，並自動阻擋或要求審批帶有高/嚴重等級發現的映像檔。
提升 EKS 的可觀測性：將 EKS control plane 的日誌 (API、Audit、Authenticator、ControllerManager、Scheduler) 啟用並傳送到一個集中式日誌帳號的 CloudWatch Logs 中，為 EKS API 事件啟用 CloudTrail，並使用 Container Insights 和 GuardDuty 進行執行階段監控。

基本原理： 此方法應用了深度防禦 (defense-in-depth) 的概念：加密並保護 registry、使用 Inspector 自動化增強型掃描、在 Security Hub 中集中化發現以達成一致的政策執行、在 CI/CD 中設置部署閘門，以及啟用 EKS control plane 日誌以利快速偵測與鑑識，這一切都符合 AWS 的最低權限 (least-privilege) 和集中式監控的最佳實務。

← 漏洞、修補與主機安全 · 所有領域 · 事件應變與鑑識 →

練習這些題目 → · 在 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.

通過考試 →

瀏覽 Amazon →

Amazon SCS-C02: 容器與無伺服器安全 — 學習指南

使用 ECS Exec 進行執行期檢查，無需 SSH

在 EC2 上阻擋容器存取 IMDS

GuardDuty 執行期監控、EKS 保護與控制平面日誌

使用 ECR 增強型掃描進行映像檔掃描

實務問題：使用案例情境

Lambda：授權方、機密與執行角色

ECR 加密與儲存庫保護

映像檔掃描：基本、增強與 Inspector

Inspector 整合與 Security Hub 彙總

集中式掃描與跨帳戶 CI/CD

EKS 控制平面日誌記錄與可觀測性

常見陷阱

實務問題：使用案例情境

Pass the whole exam — not just this question

Related guides

一份訂閱。所有考試。