4.3 基础设施与云安全

概述与动机

应用程序运行在基础设施之上，而如今这些基础设施大多是基于云的、软件定义的，并且始终处于变化之中。如今，一名工程师只需一条命令，就能以传统变更控制流程从未预见过的规模和速度，配置一个数据库、打通一条网络路径，或授予一项权限。正是这种能力，使得错误配置而非高深的漏洞利用，成为云上数据泄露的首要原因。一个意外公开的存储桶，或一个权限过宽的访问角色，都可能在几秒钟内暴露整个组织的数据。

对于大型企业而言，云基础设施跨越多个云服务商、数千个账户，混合了托管服务、容器和无服务器函数。其攻击面并非一道静态的边界，而是一个不断生长、蔓延的资源与身份集合。对于政府机构而言，同样的复杂性还要叠加严格的授权制度、数据驻留要求，以及塑造每一项架构选择的密级边界。在这两种场景下，身份层都已成为新的边界：谁可以对哪种资源做什么、在什么条件下可以做。

本章介绍如何保障这一基础的安全：身份与访问管理（IAM）、网络分段、加密与密钥管理、容器与无服务器工作负载的安全，以及持续的安全态势管理（）正是它让快速演变的云资产不至于逐渐偏离安全轨道。

核心原则

身份即边界。 访问决策取决于强身份验证和细粒度授权，而非网络位置。
始终最小权限。 每一个身份，无论是人还是机器，只获得所需的最小权限，不多不少。
分段以遏制。 划分网络和工作负载，使某一区域的入侵无法自由扩散。
无处不加密。 默认保护传输中和静态存储中的数据，并妥善管理密钥。
不可变且声明式。 将基础设施定义为代码（IaC），以不可变方式部署，并将漂移视为缺陷。
持续验证。 安全态势不是一次性审计，而要持续扫描和强制执行。
默认安全的配置。 任何资源的默认状态都应是锁定的，而非开放的。

建议

深思熟虑地设计身份与访问管理

IAM 是云安全中最重要，也是最常被管理不善的部分。

使用基于角色的访问控制（RBAC）按职能授予权限，在需要更细粒度、具备上下文感知能力的决策时（基于标签、环境、数据分类或时间），使用基于属性的访问控制（ABAC）。
消除长期存在的静态凭据，转而使用短期、自动签发的令牌以及工作负载身份联合。
对所有人工访问强制启用多因素认证（MFA），并对特权操作要求强身份验证。
严格执行最小权限原则：从零开始，逐步、有意识地添加权限。定期评审并清理未使用的权限，因为权限往往会不断累积。
职责分离，确保没有单一身份能够既发起又批准敏感变更。
使用专用账户或项目，在环境之间（生产、预发布、开发）以及业务单元之间建立硬性边界。

分段网络并对工作负载进行微分段

扁平化的网络一旦被攻破，攻击者就能横向自由移动。要划分并遏制。

在网络层面划分为多个层级和区域，只允许每个层级确实需要的流量通过。
应用微分段，使单个工作负载只能与其所需的特定对等方通信，并由基于身份感知的策略而非宽泛的子网规则来强制执行。
默认拒绝东西向流量，要求显式的放行规则。
将敏感数据存储置于私有子网中，不直接暴露于互联网，只能通过受控路径访问。
尽可能使用到托管服务的私有连接，而不是通过公共互联网路由。

正确地加密数据并管理密钥

加密的强度取决于背后的密钥管理是否到位。

在传输过程中全程使用当前版本的 TLS（传输层安全协议）进行加密，包括内部服务间的流量。
默认对所有存储、数据库和备份进行静态加密。
使用密钥管理服务（KMS）管理密钥，对于最高保证级别的密钥及监管要求，使用硬件安全模块（HSM）。
按计划轮换密钥，并支持在怀疑密钥泄露时快速轮换。
将谁可以使用和管理密钥，与谁可以访问数据，分开控制和审计，让密钥托管本身强制实现职责分离。
在监管或合同信任要求组织自行持有密钥（而非由云服务商持有）的场景中，考虑使用客户自管密钥。

保护容器、Kubernetes 和无服务器工作负载

每种计算模型都带来各自的风险。

容器： 从最小化、可信的基础镜像构建；在部署前扫描镜像中的漏洞；以非 root 用户运行；尽可能将文件系统设为只读；切勿将密钥硬编码进镜像。
Kubernetes： 启用 RBAC，并严格限定服务账户的作用范围；应用网络策略实现微分段；使用准入控制器和策略引擎强制执行标准；限制特权容器；隔离敏感工作负载；保持控制平面和节点的补丁更新。
无服务器： 对每个函数的执行角色应用最小权限原则（这是过度授权的常见来源）；校验所有事件输入；通过平台的密钥存储管理密钥；监控异常的调用模式。

无论采用哪种模型，都要保持运行时的补丁更新和镜像的新鲜度。容器的安全性取决于其内部软件的安全性。

持续管理云安全态势

云环境变化的速度远远超出定期人工审计所能跟上的范围。

采用云安全态势管理（CSPM）工具，持续检测跨账户的错误配置、公开暴露和策略违规。
将安全策略定义为代码，并在部署阶段强制执行，从而在错误配置落地之前将其拦截。
优先选择预防（阻止错误配置发生的防护栏）而非检测（事后告警），并将两者结合使用。
维护一份准确的资源和身份清单；看不见的东西是无法保护的。
跟踪并修复已声明的基础设施即代码与实际运行状态之间的漂移。

权衡取舍：优缺点

决策	优点	缺点
RBAC	简单、易于理解、易于审计	粒度较粗，规模扩大后角色数量会激增
ABAC	细粒度、具备上下文感知能力，随标签扩展	设计和推理较为复杂
云服务商托管密钥（KMS）	简单、集成度高、运维负担低	密钥由云服务商持有；掌控力较弱
客户自管密钥/HSM	完全掌控，满足严格的合规要求	运维开销大，存在丢失密钥的风险
预防性防护栏	在错误配置发生之前就加以阻止	可能阻碍正常工作，需要持续调优
仅依赖检测型 CSPM	灵活、不阻塞流程	损害可能在被发现之前就已发生
微分段	对横向移动的遏制能力强	运维复杂度高，策略易于蔓延

主要的权衡在于掌控力与运维负担之间的取舍。更严格的控制（客户自管密钥、严格的微分段、ABAC）能降低风险，但也需要小型团队难以长期维持的专业能力和维护投入。合适的严格程度取决于数据的敏感程度以及所适用的法规。一种务实的做法是：为所有人提供强有力的安全默认设置，再为风险最高的系统保留额外的严格措施，并倾向于使用自动化防护栏，让安全的选择成为默认选项，而不是依赖人工自律。

与团队讨论的问题

你们将在哪里划出硬性的账户或项目边界，每个边界内应包含哪些内容？ 专用账户和项目提供了云环境所能提供的最强遏制能力，使开发环境中的入侵无法波及生产环境，一个业务单元也无法触及另一个业务单元的数据。在你们的资产规模扩张到数千个账户之前，就应确定好边界方案，因为事后在一个扁平结构上补加隔离既缓慢又危险。对于企业和政府工作而言，这些边界还能清晰地映射到环境隔离、数据分类，以及审计人员期望看到的爆炸半径限制上。带上一张当前的示意图，标出哪些工作负载目前共享同一个账户，并标记出哪个过宽的角色同时跨越了生产环境和非生产环境。如果敏感数据与实验性工作负载共处同一账户，那就是首先要修复的边界问题。
你们对谁可以管理密钥、谁可以访问加密数据分别有什么标准？ 加密的强度取决于密钥管理，而将密钥托管与数据访问分离，能让你的 KMS 成为职责分离的强制执行点。确定谁可以创建、轮换和使用密钥，并确保这个群体与可以读取这些密钥所保护数据的人员不发生重叠。对于受监管系统和政府系统而言，这通常决定了在云服务商托管密钥与客户自管密钥或 HSM 之间的选择，后者掌控力更强，但丢失密钥的运维风险也更高。带上你们当前的密钥策略，检查是否存在任何单一身份既能管理密钥又能读取密钥背后数据的情况，因为这是一个常见的隐蔽漏洞。如果密钥托管和数据访问没有分离，静态加密所提供的保护就会比仪表盘上显示的要弱。
你们将如何让安全默认设置在着陆区（landing zone）中变得不可绕过，而不仅仅是一项建议？ 错误配置而非高深的漏洞利用，是云上数据泄露的首要原因，而解决办法是使用预防性防护栏，在一个公开的数据库或未加密的存储桶落地之前就将其阻止，而不是事后才发出告警。确定你们将在部署阶段强制执行哪些策略（禁止公开存储、默认开启加密、强制打标签），哪些策略只做检测和报告。对于大型团队而言，把这些规则编码进着陆区和基础设施即代码模板中，意味着每个新账户都会自动继承保护，无需每个团队各自投入，从而把安全从一项反复征收的税变成一次性的平台投入。带上你们上个月的错误配置发现记录，逐一分析哪些原本可以被一道预防性防护栏彻底阻止。如果你们的态势管理仅仅是检测型的，那么在有人看到告警之前，损害可能已经发生，因此应将影响最大的检查项前移到预防阶段。
在不破坏那些悄悄依赖静态凭据的自动化流程的前提下，你们如何消除长期存在的静态凭据？ 永不过期、嵌入在代码中的访问密钥，是云上数据泄露最常见的原因之一，因为脚本、日志或代码仓库中泄露的一个密钥，就能让攻击者获得持久的访问权限。与之相抗衡的是运维层面的现实：遗留的 CI 作业、定时任务和第三方集成往往默认存在一个静态密钥，而把它们切换到短期令牌或工作负载身份联合，需要没有人排期的工程投入。对于大型团队而言，一条共享的迁移路径（自动签发令牌、设定过期标准，并对任何新出现的长期密钥告警）能防止各团队各自发明出更弱的解决方案。带上一份当前使用中的每个静态凭据清单，包括其存在时长、影响范围，以及它所服务的系统今天是否已能接受联合身份。在企业和政府场景中，把这个截止日期与审计和授权周期绑定，因为一个存续时间超过其创建者任期的凭据，正是会拖延持续授权流程的典型问题。
当某项资源被错误配置或某个密钥被泄露时，你们能多快检测、遏制并修复它，是否已经度量过这个速度？ 一个公开的存储桶或一个权限过宽的角色，其危险程度取决于它保持开放的时间窗口，因此平均检测和修复时间才是真正衡量你们暴露程度的数字。这里的张力在于：能在部署阶段阻止错误的预防性防护栏，与能捕获漏网之鱼的检测型态势管理之间，你需要对两者都有真实的数据，而不是想当然地认为防护栏已经覆盖了一切。带上你们上一季度的错误配置和漂移发现记录（附带时间戳）、从引入到修复的中位时间，以及一次密钥泄露轮换演练的记录。对于跨越数千个账户的企业和政府资产而言，要就一个没有明显归属团队的发现由谁负责修复达成一致，因为一个没有明确负责人响应的告警，最终会演变成一次事件。
在不让所有人陷入停滞的前提下，你们如何在多个云、多个账户和多个团队之间保持一致的安全态势？ 多云、多账户的资产很容易碎片化：每个云服务商都有自己的 IAM 模型、自己的默认设置和自己的态势管理工具，因此在一处强制执行的策略，会在另一处悄然失效。这里的权衡在于能保证一致性的集中管控，与能让团队快速行动的本地自主权之间，任何一端倾斜过度，都会要么阻塞交付，要么导致标准逐渐松动。带上你们当前的覆盖地图：哪些账户继承了着陆区防护栏，哪些未被纳管，同一项控制在不同云服务商之间是以三种不同方式表达的。对于大型或公共组织而言，还要加上审计视角，因为审计人员期望看到一套在所有地方都站得住脚的标准，而一项存在于主云但不存在于备用云中的控制，正是一个有心的攻击者或评估人员会第一个发现的漏洞。

行业视角

初创企业。 速度和生存最重要，因此要完全依靠那些免费自带的安全默认设置：默认开启静态加密、存储默认私有（除非有人手动打开）、根账户启用 MFA，使用云服务商内置的工作负载身份而非粘贴访问密钥。不要搭建 CSPM 平台，也不要手工实现你无力维护的微分段；一条能阻止数据库被开放到互联网的防护栏，只需一个下午的工作就能换来大部分的保护。从一开始就把一切都放进基础设施即代码中，这样加固能力会随你一起扩展，而不会变成日后的重写。

小型企业。 没有专职的安全工程师，预算也紧张，因此应优先选用默认设置已经过加固、密钥管理已由对方代为处理的托管服务，而不是自建一套密钥管理纪律。把云安全视为一个配置卫生问题：清楚知道存在哪些存储桶和数据库、保持它们私有、要求 MFA，并开启云服务商免费提供的原生态势检查。购买工具时，优先选择那些能开箱即用地标记公开暴露和未加密存储的工具，因为这两类错误导致了大多数本可避免的数据泄露。

企业。 真正的问题在于如何在数千个账户和众多团队之间保持一致性，因此这是一项平台层面的工作：着陆区确保每个新账户在配置时就已加固，防护栏以策略即代码的形式强制执行，CSPM 持续扫描漂移。统一 IAM 模型、密钥托管规则和分段基线，让各团队不再各自重复发明更弱的方案，并对整个资产的安全态势进行度量，而不是仅凭各团队自己的说法。为持续的工程投入编列预算，以便随着云服务商新增服务和资产规模扩大，策略能持续保持最新。

政府。 采购规则、数据驻留要求和授权制度塑造着每一项选择，因此安全控制同时也是审计证据。优先选用符合 FIPS 认证、且密钥托管与数据访问分离的密钥管理方案，选用能将数据保留在国境之内的隔离区域，并对容器镜像进行签名、扫描，配合严格的准入控制。尽可能公开你们的防护措施，将持续态势管理直接接入正在进行的授权流程，并要求供应商披露其配置默认值，并支持你们的密级边界所要求的分段和密钥托管控制。

示例

初创企业。 一家小型初创公司把所有业务都运行在一个云账户中，无力配备一个平台团队，因此它依靠那些默认就是安全的设置：默认开启静态加密、存储桶默认私有（除非有人明确打开），并且根账户强制要求 MFA。它没有把长期有效的访问密钥粘贴进 CI，而是使用云服务商内置的工作负载身份，让流水线自动获得短期凭据。一条免费的防护栏，只需自动标记任何被开放到互联网的数据库，就能让它避免最常见、代价也最高的云安全错误，而设置成本只是一个下午的时间。

企业。 一家在两个云服务商上运营数千个账户的媒体公司，实施了一套着陆区模式：每个账户都从一个模板中配置生成，默认开启静态加密、禁止存储公开访问、强制打标签，并预置了一整套基线防护栏策略。CSPM 持续扫描漂移，工作负载身份联合已经消除了 CI 系统中长期存在的密钥。当某位开发者不小心尝试将一个数据库开放到互联网时，一条预防性策略会自动阻止该变更，并自动提交一张工单。

政府。 一家与国防相关的机构在一个隔离的云区域中运营，通过策略强制执行数据驻留要求，确保数据不离开国境。最敏感的密钥保存在符合 FIPS（联邦信息处理标准）认证的 HSM 中，密钥托管与数据访问分离，以强制实现职责分离。Kubernetes 集群采用严格的网络策略和准入控制；每个容器镜像在运行前都要经过扫描和签名。持续态势管理直接为该机构持续进行中的授权证据提供数据。

商业案例：动机、投资回报率与总体拥有成本

云基础设施安全，正是一笔小投入就能避免灾难性、登上头条新闻级别损失的地方。总体拥有成本包括 CSPM 工具、密钥管理服务、设计最小权限 IAM 和分段所需的工程时间，以及持续维护策略最新所需的投入。这些成本是真实存在的，但相对适中。而省去这些投入的代价，则是一个错误配置的资源就可能暴露整个客户数据库，随之而来的还有监管罚款、通知成本，以及持久的品牌损害。云错误配置引发的数据泄露，是业内最常见、也是最可预防的事件类型之一。

自动化和复用能放大投资回报率。把安全默认设置编码进着陆区和基础设施即代码模板中，每个新账户和新工作负载都会自动继承保护，无需每个团队各自投入，从而把安全从一项反复征收的人工税变成一次性的平台投入。对于政府机构和受监管企业而言，强有力的态势管理还能通过自动生成证据，降低审计和持续授权的成本。在向管理层论证时，要强调身份和配置层如今已是首要的数据泄露入口，错误配置是可以预防的，而防护栏既能降低风险，又能减少人工评审带来的摩擦。

反模式与陷阱

通配符权限。 为了”先让功能跑起来”而授予宽泛的 * 访问权限，此后再也没有收紧。
长期存在的静态密钥。 嵌入在脚本和 CI 中、永不过期、最终泄露的访问密钥。
扁平网络。 没有分段，导致一台被攻破的主机能够触及一切。
意外公开。 由于默认设置或疏忽，存储和数据库被暴露到互联网上。
加密却缺乏密钥纪律。 启用了加密，却让密钥访问完全敞开，或从未轮换。
密钥硬编码进镜像。 凭据被嵌入容器镜像，随着镜像运行而扩散到各处。
权限过度的无服务器角色。 由于跳过了作用范围限定，函数被授予了远超其所需的权限。
仅靠审计的态势管理。 事后检测错误配置，而不是在部署阶段就加以预防。
忽视漂移。 任由实际运行环境与基础设施即代码逐渐偏离，直到没有人清楚真实状态。

成熟度模型

第 1 级：启动。 由谁需要资源就由谁手动配置。存在宽泛的通配符权限和长期存在的静态密钥。网络扁平，没有分段。加密应用不一致，甚至完全没有。没有态势管理；错误配置只有在一次事件迫使人们正视问题之后才会浮现。

第 2 级：发展。 出现了一些 IAM 角色和 MFA，主要存储也开启了静态加密，但各团队的做法参差不齐。存在基本的网络层级，但没有默认拒绝机制。配置评审是周期性的、人工进行的。基础设施部分以代码形式定义，因此加固程度取决于哪个团队配置了该账户。

第 3 级：标准化。 具备短期凭据的最小权限 RBAC 和 ABAC 已在全组织范围内形成文档并得到落实。分段采用东西向默认拒绝。传输和静态加密默认开启，密钥保存在 KMS 中并按计划轮换，托管与数据访问分离。容器和 Kubernetes 的加固已成为标准做法，CSPM 依据既定策略，在所有账户上保持一致地运行。

第 4 级：管理。 安全态势是被度量的，而不是被想当然认为的。你们会对照基线和目标跟踪具名指标：处于最小权限基线之内的身份占比、错误配置和漂移的平均检测和修复时间、跨账户的防护栏和 CSPM 覆盖率、密钥轮换合规率，以及仍然存活的长期凭据数量。发现问题按爆炸半径分级处理，修复工作有明确的负责人和服务水平目标，这些数字的趋势数据决定了下一步加固工作的重点。

第 5 级：编排。 安全默认设置已内置于着陆区和基础设施即代码之中，使每一项资源在诞生时就已加固，而控制措施会随着资产和威胁态势的变化而自适应调整。微分段采用身份感知策略；客户自管密钥和 HSM 以分离的托管方式保护最高保证级别的系统。预防性防护栏在部署阶段就阻止错误配置，漂移被自动检测和修复，态势证据自动接入持续授权流程。安全已与交付和风险规划深度融合，组织会随着云服务商、服务和法规的变化，常态化地淘汰和重新界定控制措施的范围。

讨论思路

在你们的环境中，ABAC 在哪些场景下值得其复杂性，哪些场景下坚持使用 RBAC 更合适？
你们如何在不破坏遗留自动化流程的前提下，消除长期存在的凭据？
预防性防护栏与检测型态势管理之间，正确的分配比例是什么？
考虑到运维成本，哪些系统值得使用客户自管密钥或 HSM？
你们如何防止最小权限的权限设置悄悄地重新累积回过度授权？
多云复杂性应该如何改变你们对一致态势和策略的处理方式？

关键要点

身份是新的边界；投资于具备短期凭据的最小权限 IAM。
对网络进行分段，对工作负载进行微分段，以遏制入侵。
默认对传输中和静态存储中的数据加密，并通过 KMS/HSM 管理密钥，实现托管分离。
加固容器、Kubernetes 和无服务器工作负载；保持运行时和镜像的补丁更新。
优先选择预防性防护栏而非事后检测，并持续管理安全态势。
将安全默认设置内置于着陆区和基础设施即代码中，使保护能力自动扩展。
错误配置而非高深的漏洞利用，是云上数据泄露的首要原因，而且是可以预防的。

参考文献与延伸阅读

National Institute of Standards and Technology，SP 800-207: Zero Trust Architecture
Center for Internet Security，CIS Benchmarks（云服务商、Kubernetes、Docker）
Cloud Security Alliance，Cloud Controls Matrix 与 Security Guidance for Cloud Computing
NIST，SP 800-190: Application Container Security Guide
Liz Rice，Container Security
Marco Lancini 等，Cloud security posture and detection 工程文献
各云服务商的 Well-Architected 安全支柱（作为与供应商无关的架构指导）