CompTIA SY0-701: 云、虚拟化与容器安全 — 学习指南

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

属于 CompTIA Security+ SY0-701 — 学习指南. 使用经过验证的答案练习： CompTIA 考试中心, 或参加限时模拟考试： ExamRoll.io.

现代企业很少在单一、独立的自有数据中心中运营。工作负载横跨公有云提供商、私有虚拟化集群、容器编排器和短暂的无服务器函数。每个抽象层都改变了威胁模型、控制层面，以及——至关重要地——谁对哪些安全控制负责。

责任共担模型

每个主流云提供商都发布了责任共担模型，该模型在客户和云服务提供商 (CSP) 之间划分了安全职责。分界线根据服务层级的不同而变化。

在基础设施即服务 (IaaS) 中——例如 Amazon EC2、Azure Virtual Machines、Google Compute Engine——CSP 负责保护物理设施、硬件、hypervisor 和网络结构。Hypervisor 之上的一切都属于客户：客户机操作系统、补丁、基于主机的防火墙、中间件、运行时、应用程序代码、身份配置以及数据本身。如果一家公司在 EC2 实例上部署 MySQL 数据库，那么保护该数据库完全是客户的责任。

在平台即服务 (PaaS) 中——例如 AWS RDS、Azure App Service、Google App Engine——提供商还额外管理操作系统、数据库引擎补丁和运行时。客户仍然负责应用程序代码、数据分类、访问控制、网络暴露规则和身份管理。

在软件即服务 (SaaS) 中——例如 Microsoft 365、Salesforce、Workday——提供商几乎处理整个技术栈。客户剩余的责任并非微不足道：账户的开通和注销、MFA 强制执行、数据分类、共享权限、DLP 配置以及与企业身份提供商的集成。一个配置错误的 SharePoint 站点将薪资数据暴露给“所有人”，这不是微软的泄露事件——而是租户管理员的责任。

一个长期存在的误解是，迁移到云端会将所有安全责任转移给提供商。涉及配置错误的 S3 存储桶、暴露的 Elasticsearch 集群和泄露的 API 密钥的数据泄露事件，几乎无一例外地都追溯到客户端的错误，而非 CSP 的失陷。

虚拟化和 Hypervisor 风险

虚拟化使用 hypervisor 将物理硬件池化为逻辑客户机。类型 1 (裸金属) hypervisor，如 VMware ESXi、Microsoft Hyper-V 和 KVM，直接在硬件上运行。类型 2 (托管型) hypervisor，如 VirtualBox，运行在通用操作系统之上，不适合生产工作负载。

主要的虚拟化特定威胁是虚拟机逃逸和hypervisor 失陷。当客户机内的恶意代码突破其虚拟化边界并在 hypervisor 或相邻虚拟机上执行时，就会发生虚拟机逃逸。历史案例包括 CVE-2015-3456 (VENOM，在 QEMU 的软盘控制器中) 和各种 VMware Tools 漏洞。由于单个 hypervisor 可能托管跨多个信任区域的数百个工作负载，一次成功的逃逸会带来不成比例的访问权限。

缓解措施包括严格的 hypervisor 补丁、最小化客户机附加组件和未使用的模拟硬件、将不同敏感性的工作负载分离到不同的集群上，以及隔离管理平面。vCenter 服务器、ESXi 管理接口和集群 API 必须位于专用的管理网络上，该网络只能从具有 MFA 的特权跳板机访问。

其他问题包括虚拟机蔓延（随着时间的推移，孤立的、未打补丁的虚拟机不断累积）和资源重用，即已停用虚拟机的内存或存储在分配给另一个租户之前未被正确清零。

容器、微服务和内核共享

容器将应用程序及其依赖项打包在一起，但与虚拟机不同，它们共享主机操作系统的内核。Docker、containerd 和 CRI-O 管理容器生命周期；Kubernetes 则大规模编排它们。这种轻量级隔离是一个特性——毫秒级启动、高密度部署——但也是主要风险。

容器隔离不等同于虚拟机隔离。从容器内部利用的内核漏洞可能会危及主机及其上的所有其他容器。命名空间 (PID、network、mount、UTS、IPC、user) 和 cgroups 提供了隔离，但它们是共享单一攻击面的软件结构。

容器安全需要在整个流程中进行控制：

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

镜像在部署前必须进行漏洞扫描（Trivy、Snyk、Clair），基于最小化的基础镜像（distroless 或 Alpine）构建，并且只能从强制执行镜像签名（Cosign、Notary）的可信镜像仓库中拉取。运行时保护工具（Falco、Aqua、Sysdig）监控容器行为，并对异常情况（如意外的进程执行或网络连接）发出警报。

云安全状况和 IAM

云 IAM 在一些重要方面与本地 Active Directory 不同。在 AWS 中，IAM 策略是附加到用户、组或角色的 JSON 文档，有效权限是基于身份的策略和基于资源的策略的交集，其中明确的拒绝 (deny) 总是优先：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

云安全状况管理 (CSPM) 工具持续扫描云配置，对照安全基准（CIS AWS Foundations、NIST）进行检查，标记出公开的 S3 存储桶、过于宽松的安全组、禁用的 CloudTrail 日志记录以及未加密的 EBS 卷。云访问安全代理 (CASB) 位于用户和云服务之间，为 SaaS 应用程序强制执行 DLP、访问策略和威胁检测。

实际案例：配置错误的 S3 存储桶泄露 PII

一家医疗保健初创公司将其患者信息采集表存储在一个 S3 存储桶中。该存储桶在一次开发冲刺期间被创建并赋予了公共读取权限，但在投入生产环境前从未收紧其权限。一名安全研究员通过结合使用 DNS 暴力破解和 AWS S3 存储桶枚举技术发现了这个存储桶。大约 87,000 条患者记录——包括姓名、出生日期、保险 ID 和主诉描述——都可以在未经身份验证的情况下被访问。这家初创公司既没有使用 CSPM 工具，也没有进行自动化配置扫描。一条用于检查 s3-bucket-public-read-prohibited 的基本 AWS Config 规则本可以在该存储桶创建后的几分钟内就标记出这一配置错误。该事件最终导致了 HHS 的调查、45 万美元的和解金以及声誉损害，这些因素共同促成了该公司最终以折价估值被收购。

← 应用与 Web 安全 · 所有领域 · 数据安全、隐私与密码学 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →