Amazon SCS-C02: 容器与 Serverless 安全 — 学习指南

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 注入到任务 sidecar 执行环境中的 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 并获取实例配置文件（instance profile）的凭证，而这些凭证的权限通常远高于任务角色。这完全违背了最小权限原则。

当无法迁移到 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 Protection 和控制平面日志

GuardDuty 提供分层的容器检测功能：

EKS Protection 分析 EKS 审计日志，以检测可疑的 Kubernetes API 活动——例如匿名访问、创建特权 pod、对系统 pod 执行 exec 操作。
Runtime Monitoring 部署一个基于 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）的 CVE 进行持续扫描。基本扫描是在推送时进行的一次性扫描，且仅涵盖操作系统包；增强型扫描是持续性的，并包含应用程序依赖项，而大多数现代漏洞都存在于这些依赖项中。

当这两个服务都启用时，发现结果会自动流入 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 扩展来实现可感知轮换的自动缓存。

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 控制台中返回发现结果。它是免费的，但不执行持续重新扫描，不统一覆盖操作系统和编程语言包，并且没有与 Security Hub 的原生集成。增强扫描由 Amazon Inspector 提供支持，同时覆盖操作系统包和应用程序语言包（Python、Java、Node.js、Go、Ruby、.NET）。Inspector 根据更新的漏洞情报持续监控已推送的镜像，因此即使在镜像推送一周后披露的 CVE，也无需重新构建即可产生发现结果。

增强扫描在注册表级别（按区域）启用，并通过每个存储库的包含筛选器使用通配符模式，例如 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 聚合

必须在需要扫描的每个账户和区域中启用 Amazon Inspector。在 AWS Organizations 设置中，安全工具账户被指定为 Inspector 的委托管理员，这允许它启用扫描、为新成员账户设置自动注册以及查看聚合的发现结果。忘记委托——或忘记切换自动注册——是一个微妙的故障模式：加入组织的新账户会静默地将容器推送到 ECR，而这些容器永远不会被扫描，这在没有任何错误提示的情况下破坏了覆盖保证。

当 Inspector 和 AWS Security Hub 都启用，并且 Security Hub 的 Inspector 集成也开启时，Inspector 的发现结果会自动流入 AWS Security Hub。然后，Security Hub 将发现结果规范化为 AWS 安全发现格式 (ASFF)，将它们与 GuardDuty、Macie 和 Config 的发现结果相关联，并且——当与委托的 Security Hub 管理员以及跨区域聚合相结合时——提供了一个单一管理平台。针对 Security Hub 发现结果的 EventBridge 规则可以将关键 CVE 路由到 Lambda 以自动创建工单，为有问题的镜像打上 quarantine=true 标签，或通过管道门禁阻止部署。

集中式扫描和跨账户 CI/CD

对于多账户容器工作负载，推荐的模式是以一个加固的中央注册表账户为核心：

中央账户： 托管经过 KMS 加密的 ECR 存储库，并启用了增强扫描、不可变标签和镜像签名（通过与 AWS Signer 集成的 Notation/Sigstore）。
构建账户： 运行 CodeBuild/CodePipeline 作业，这些作业负责构建、推送到中央 ECR、等待 Inspector 的发现结果，并根据严重性阈值进行门禁控制。
工作负载账户（开发/预发/生产）： 通过跨账户权限从中央注册表拉取镜像。

跨账户读取访问需要两个层面的权限：消费账户中的 IAM 策略，授予 ecr:GetDownloadUrlForLayer、ecr:BatchGetImage 和 ecr:GetAuthorizationToken 权限；以及中央账户中 ECR 存储库上的存储库策略，允许特定的消费账户或角色访问。

{
  "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。

常见陷阱

仅依赖推送时扫描： 基础的推送时扫描可以捕获推送时已知的漏洞，但对那些已存在于注册表中、后续才被披露 CVE 的镜像无能为力。PCI DSS 和 FedRAMP 等审计框架要求进行持续的漏洞评估，这强制要求使用 CONTINUOUS_SCAN 频率的增强型扫描，并结合 Security Hub 进行结果聚合。单次推送时的快照无法满足此项控制要求。

当要求静态加密时，忽略在 ECR 上使用 KMS： 默认的 AES-256 加密是真正的加密，但对于那些要求客户管理密钥、密钥轮换记录以及基于每个主体的 kms:Decrypt 审计跟踪的合规性制度，AWS 拥有的密钥无法满足其要求。由于每个存储库的加密类型是不可变的，这个问题必须在创建时就解决——“我们稍后再开启”是不可能的，除非重新创建存储库。

忘记 Inspector 委派管理员或自动注册： 如果没有为 Inspector 设置委派管理员，每个账户所有者都必须独立地启用扫描并转发发现结果，这在操作上是不可行的，并且会产生覆盖差距。如果没有为新成员账户自动启用，每个通过 Control Tower 或 Organizations 创建的新账户启动时 Inspector 都是禁用的，因此其 ECR 镜像不会被扫描，即使中心账户的 Security Hub 中没有显示任何发现结果——这是一个静默的假阴性，而不是一个明显的错误。

实践问题：用例场景

场景： Meridian Financial 公司在一个多账户 AWS 环境中运营，其中生产 EKS 集群、ECS 服务以及多个 ECR 注册表分布在生产、开发和一个专用的安全账户中。他们的工程团队通过 CI/CD 流水线将容器镜像推送到 ECR 并部署到 EKS/ECS，而安全团队则维护一个用于监控和合规的中心化账户。

挑战： 最近一次部署交付了一个带有高危漏洞的容器，该漏洞在生产前未被检测到。调查人员发现 EKS 控制平面日志有限，且扫描结果分散在各个账户中，这减慢了修复速度。

推荐方法：

启用 ECR 存储库级别的保护：强制执行镜像标签不可变性，应用存储库策略以限制特定 IAM 角色的推送/拉取权限，并使用专用的 AWS KMS 客户管理密钥 (CMK) 对存储库进行静态加密。
开启推送时镜像扫描（基础），并为 ECR 启用 Amazon Inspector 增强型镜像扫描以生成漏洞发现结果；将 Inspector 与 AWS Security Hub 集成，以集中汇总跨账户的各严重性级别的结果。
实现中心化的跨账户扫描：配置 ECR 复制，或授予安全账户中的 CodeBuild/CodePipeline 角色跨账户拉取权限，以便安全账户可以使用 Inspector 和任何其他 SCA/DAST 工具扫描每个镜像，并将产物存储在用安全账户的 CMK 加密的中心化 S3 存储桶中。
强制执行 CI/CD 门禁：添加一个流水线扫描阶段（使用 CodeBuild/CodePipeline 或带有 STS assume-role 的 GitHub Actions），该阶段查询 Inspector/Security Hub 的发现结果，并对包含高危/严重发现结果的镜像自动阻止或要求批准。
提升 EKS 可观察性：在中心化的日志记录账户中，将 EKS 控制平面日志（API、Audit、Authenticator、ControllerManager、Scheduler）发送到 CloudWatch Logs，为 EKS API 事件启用 CloudTrail，并使用 Container Insights 和 GuardDuty 进行运行时监控。

基本原理： 该方法应用了深度防御策略：加密和保护注册表，使用 Inspector 实现自动化增强型扫描，在 Security Hub 中集中化发现结果以实现一致的策略执行，在 CI/CD 中设置部署门禁，并启用 EKS 控制平面日志以进行快速检测和取证，这与 AWS 的最小权限和集中化监控的最佳实践相一致。

← 漏洞、补丁与主机安全 · 所有领域 · 事件响应与取证 →

练习这些题目 → · 在 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: 容器与 Serverless 安全 — 学习指南

ECS Exec 和运行时排查，无需 SSH

在 EC2 上阻止容器访问 IMDS

GuardDuty 运行时监控、EKS Protection 和控制平面日志

使用 ECR 增强型扫描进行镜像扫描

实践问题：用例场景

Lambda：授权方、密钥和执行角色

ECR 加密和存储库保护

镜像扫描：基础、增强和 Inspector

Inspector 集成和 Security Hub 聚合

集中式扫描和跨账户 CI/CD

EKS 控制平面日志记录和可观测性

常见陷阱

实践问题：用例场景

Pass the whole exam — not just this question

Related guides

一次订阅。所有考试。