今天最大的攻击面， 是您的云。
针对 AWS、Azure 与 GCP 的配置、身份与网络隔离所做的审查。多数云上事故并非始于云厂商故障，而是始于一项过宽的权限、一个无意间暴露的资源，或一个被遗忘的密钥。
在云上，出错的很少是云厂商
责任共担模型划清了分工：厂商负责基础设施的安全，配置归您。事故发生在您这一半——为了方便测试而打开的存储桶、赶工时顺手给了管理员权限的角色、因为工期吃紧而没做隔离的网络。这些在扫描里都不会显示为漏洞，它们显示为一个没人再回头看过的配置决定。
- 作为临时措施授予的权限，事后几乎不会被收回。
- 绕开标准流程创建的资源，不会继承该流程附带的防护。
- 环境变量与代码仓库里的密钥，依然是进入系统最短的路。
- 没有隔离，一个立足点就能触达本该彼此分开的账号与环境。
服务包含内容
以下范围是常规项目的默认配置。在范围沟通阶段均可调整，不另收费。
- 宽泛策略，以及动作与资源中的通配符
- 可被扮演的角色与权限提升链
- 长期有效的访问密钥与轮换机制
- 联合身份、身份提供方与会话
- 服务账号与工作负载权限
- 管理操作与日常运维的分离
- 对象与容器的公开暴露
- 静态加密与密钥管理
- 访问策略与跨账号共享
- 版本管理、保留期与防误删
- 备份与恢复演练
- 存放在预期之外位置的敏感数据
- 对整个互联网开放的入站规则
- 环境之间与账号之间的隔离
- 负载均衡、网关与流量终结
- 可从外部访问的管理类服务
- 私有连接与网络对等互联
- 容器与编排层的攻击面
- 所有区域均启用审计追踪
- 日志本身的保留与保护
- 控制平面事件的覆盖情况
- 敏感权限变更的告警
- 集中归集到独立账号
- 与既有监控体系的对接
- IAM、角色、策略与身份联合
- VPC、安全组、NACL、对等互联与公网暴露
- S3、RDS、DynamoDB、Blob Storage 与 Cloud Storage
- EC2、Lambda、ECS、EKS、AKS 与 GKE
- CloudTrail、AWS Config、Microsoft Sentinel 与 Security Command Center
- 身份提供方与联合单点登录
实施方式
按范围调整配置审查
以只读审计角色系统性通读整个环境：身份、网络、存储、日志与数据保护，并与云厂商自家文档及公开基线逐项比对。
路径验证
不是罗列配置，而是从一个合理的起点出发——一份应用凭据、一个被攻陷的容器、一名普通用户——测定它在环境内部究竟能走多远。
持续审查与基础设施即代码
分析构建环境的模板与模块，并建立周期性复核。在源头修复，才能避免同一处偏差随着每个新账号、新项目、新一次部署再次出现。
什么时候该审查云环境
云上配置每天都在变，且经手的人很多。有些时刻的风险明显比其他时候集中。
匆忙搬过去的环境，往往带着为打通切换而放开的大权限，并附带一句“之后再收紧”——而那个“之后”很少到来。
每个团队开一个，每个项目再开一个。没有统一标准，防护就会各走各的，也没人看得到全局。
异常开销有时是浪费，有时是某个本不该有创建权限的人建出来的资源。弄清是哪一种，是值得的。
云上控制措施的证据，如今已是多数问卷的固定项。与其让评审员先发现缺口，不如自己先找出来。
我们如何推进
[流程]环境梳理
我们从“到底有什么”开始：账号、订阅、项目、启用的区域与在用资源。云上资产几乎总是比文档所写的更多，而清单里缺的那个资源，往往正是没有防护的那个。
身份与权限分析
我们梳理谁能做什么，包括通过继承和角色扮演可以做到的事。重点不是写在纸面上的策略，而是实际生效的权限——它通常比授权者所设想的宽得多。
配置审查
存储、网络、加密、日志、备份与托管服务逐项对照厂商文档与公开的安全配置基线，记录每一处偏差，并说明它在这个具体环境里为什么要紧。
可达范围验证
我们模拟贴近现实的起始位置，衡量各自能走多远：一份应用凭据能读到什么，一个被攻陷的容器能碰到什么，能否从一个环境跨进另一个。正是这一步，把一份偏差清单变成可证明的风险。
日志与告警评估
我们核对所执行的动作是否留下了痕迹、这些痕迹是否防删除，以及敏感权限变更是否触发告警。缺少可信痕迹的环境，事故之后是查不下去的。
报告与整改计划
偏差按成因归类，而不是按资源罗列：源自同一条策略的十个条目，是一次修复，不是十次。每一组都配有可落地的指引，以及从源头防止复发的建议。
工作背后的公开依据
审查以云厂商自身文档与公开配置基线为准，因此每一条结论都可以被独立核验。
- CIS Benchmarks
- 面向 AWS、Azure 与 GCP 的配置基线，提供了一份逐条可比对的客观参照，用来衡量环境的实际状态。
- Well-Architected（安全支柱）
- 各家云厂商的架构指南写明了他们自己推荐的做法，也就免去了关于“这条建议出处何在”的争论。
- 责任共担模型
- 它精确界定了厂商责任在哪里终止、您的责任从哪里开始——而多数事故恰恰发生在这条界线上。
- MITRE ATT&CK for Cloud
- 面向云的矩阵为身份滥用、驻留与数据收集等手法提供统一命名，可用来评估检测覆盖面。
- NIST SP 800-53
- 这份控制项目录，是技术发现与治理、审计部门既有语言之间的桥梁。
- 最小权限
- 它不是标准，而是指导权限分析的准绳：每个身份只应触及其所需，任何偏离都需要给出明确理由。
- Azure Security Benchmark
- 微软针对 Azure 的自有基线。当环境以 Azure 为主、审计方也期待这一参照时使用。
- CSA 云控制矩阵
- 云安全联盟的矩阵梳理了云安全各领域，并与其他标准做了交叉引用，客户问卷冗长时尤其好用。
- ISO/IEC 27017 与 27018
- 分别针对云安全与云上个人数据的标准，常出现在企业合同条款中。
- 与数据保护法规、PCI-DSS 的对应
- 若环境涉及个人数据或持卡人数据，每条发现还会对应到相应条款，便于直接作为证据使用。
交付物
双视角 · 保密协议现有资产清单
账号、项目、区域与在用资源的真实清单。对不少团队来说，这是第一份真正有用的交付物，因为它会翻出谁都不记得还归自己管的环境。
实际权限图谱
实践中谁能触达什么，包括经由继承与角色扮演形成的间接路径。它带来的意外，通常比配置清单还多。
按成因归类的偏差
按共同来源整理的发现，每条附上公开依据。修好成因就能一次关掉多个条目，也能防止复发。
已验证的路径
对最值得关注的风险给出具体路线：从哪里起步、能到达什么、为什么这要紧。这让一处配置偏差变成非技术人员也能掂量的风险。
痕迹与检测评估
我们执行的动作有哪些被记录下来、哪些日志被关掉，以及今天有哪些敏感变更会悄无声息地过去。
按优先级排列的整改计划
一份兼顾风险与投入的工作顺序，并区分哪些可在配置层改掉、哪些必须改在基础设施代码里才不会卷土重来。
常见问题
不需要。审查通过只读审计角色进行，三家云厂商都原生提供。可达范围验证所需的凭据另行约定，范围有限，权限范围与有效期以书面形式写明。
是补充，不是替代。态势工具负责覆盖量、持续跟踪配置漂移，这很有价值。它做不到的是把权限串起来，证明一份应用凭据能够读到本该隔离的数据——而恰恰是这种证明会改变优先级。
支持。混合云才是常态，而跨厂商对比往往会暴露防护不均：同一类资源在这边锁得很死，在那边却敞着，只因为是不同团队搭的。
编排层在范围内：角色与绑定、容器安全上下文、服务之间的网络策略、控制平面的暴露、密钥管理，以及集群身份与云身份之间的关联——这是一条常见的提权路径。
至少要覆盖支撑生产的那部分。开发与预发布账号一旦在网络或身份上通向生产，就值得纳入，而这种情况比想象中常见——偏偏那里的防护往往最松。
在源头修。如果环境由基础设施代码构建，修复就写进模块，往后每次部署都生效。报告会针对每一组偏差说明：该在资源上处理，还是在生成它的模板里处理。
可以。每一条都附有公开依据与所观察到的配置证据，形式上便于审计人员独立核验，不必重做一遍分析。