Google最新报告：云上85%的安全漏洞，不是被黑客攻破的，是自己配错的
Google最新报告：云上85%的安全漏洞，不是被黑客攻破的，是自己配错的
《AI视界——从资讯看技术》专栏 · 第十二期
数据会说话。这一次，它说出了运维最不愿面对、但也最能证明自身价值的真相。
本系列专栏其他文章欢迎访问：AI视界——从资讯看技术
我的主页：AOwhisky，这里有更多运维系统性知识整理和其他有趣内容，欢迎与我一起探讨学习~
一、一份报告，一个扎心的数字
2026年7月，Google Cloud 发布了年度云安全报告。
报告里有各种图表、趋势分析和行业对比，各大科技媒体都做了摘要报道。但真正让我把咖啡放下来反复看了三遍的，是报告开头一个数字：
85%的云上安全事件，根本原因不是零日漏洞，不是高级APT攻击，而是配置错误。
85%。
这个数字意味着什么？意味着大部分云安全事故，不是因为攻击者太强，而是因为防御者自己没把门关好。
上一期我们聊了 eBPF 安全工作组，聊的是“谁来监控监控者”。那是一个技术细节很深的话题。这一期我们把视角拉高，用数据回答一个更普遍的问题：运维在整个安全体系里，到底站在什么位置？
Google 这份报告给出了一个不太中听但绝对真实的答案：站在第一排，而且是背锅的第一排。
二、都是些什么配置错误？
报告把“配置错误”拆成了几个细分类别。排名前三的分别是：
第一名：存储桶公开访问
S3 存储桶、Cloud Storage 存储桶被设置为“公开读取”，而且当事人完全不知情。排名第一，遥遥领先。
这不仅是AWS刚兴起时的老毛病。十年过去了，它依然是云安全事件的头号杀手。因为很多企业为了方便测试，临时开了一个公开存储桶，然后忘了关。
第二名：IAM 权限过度授权
给服务账号配了远超出实际需求的权限。一个只需要读日志的服务，被赋予了管理员权限；一个只在内网跑的脚本，拿着可以操作生产数据库的Token。
最要命的是，这些过度授权往往不是一次性失误，而是日积月累的“权限膨胀”。今天加一个权限，明天再加一个，没人记得最初的权限范围是什么。
第三名：数据库密码硬编码
AK/SK 写在代码里、数据库密码写在配置文件里、API密钥提交到了公开仓库。每一个都是老生常谈，每一个都在持续发生。
这些配置错误有一个共同特点：它们都不涉及复杂的技术对抗。
攻击者不需要写一个高级的0day利用链。他只需要在公网上扫描一遍，找到公开的 S3 存储桶，然后把里面的数据拖走。甚至不需要“攻击”，直接下载就行。
打个比喻：
- 高级APT攻击，像是职业大盗，需要策划、踩点、破解安防系统。
- 云上配置错误，像是你没锁门，然后路人顺手就把东西拿走了。
Google 这份报告想说的其实是：你不需要防住所有职业大盗，你只需要先把门锁好。但很多人连这一步都没做。
三、为什么配置错误这么普遍？
如果只是个别团队的失误，这不值得写一期专栏。但85%这个数字，说明它是一个系统性问题。
原因一：云上配置复杂度爆炸
一个典型的云上应用，涉及到的配置项有多少？
VPC 网络配置、安全组规则、IAM 策略、存储桶权限、数据库访问白名单、负载均衡器配置、日志投递策略、密钥轮换规则、CDN 缓存策略……
每一个配置项都有多个可选值，而且它们之间互相影响。安全组规则设得太紧，服务之间调不通；设得太松，攻击面扩大。这是典型的“越复杂，越容易出错”。
原因二：IaC 不是银弹
基础设施即代码，比如 Terraform、CloudFormation，让配置管理更规范了。但它没有消灭配置错误，只是把错误从“手误”变成了“批量手误”。
写错一行 Terraform 配置，影响的不是一个实例，是整个环境。而且 IaC 的配置本身也可能出安全漏洞——比如 State 文件里包含明文密钥，或者代码仓库里的 Terraform 配置没有经过安全审查。
原因三：安全是“别人的事”的心态
在很多团队里，安全被认为是“安全团队”的职责，和开发、运维没关系。开发只管功能，运维只管稳定性，安全团队最后扫一遍漏洞就算完事。
但配置是谁写的？大部分情况下，是运维和开发写的。安全团队可以定规则，但规则落地要由写配置的人执行。只要这种“安全是别人的事”的心态存在，配置错误就不会消失。
四、运维视角：把安全从“别人的事”变成“自己的事”
聊到这里，你可能会想：这些不是安全团队该操心的事吗？
Google 这份报告最有价值的地方，恰恰是它重新划分了责任边界。
安全团队负责发现漏洞、制定策略、响应攻击。但配置是运维和开发写下去的。你写的安全组规则，就是你的防线的宽度。你设的 IAM 策略，就是攻击者能拿到的最大权限。
运维不可能取代安全团队，但运维可以把安全从“事后检查”变成“事前防线”。
三个可以立刻动手做的事：
第一，给 IAM 做一次“减脂手术”
# 查看某个服务账号的所有权限gcloud projects get-iam-policy PROJECT_ID\--flatten="bindings[].members"\--format="table(bindings.role)"\--filter="bindings.members:YOUR_SERVICE_ACCOUNT"# 或者用 AWS CLIaws iam list-attached-role-policies --role-name YOUR_ROLE aws iam list-role-policies --role-name YOUR_ROLE把结果拉出来，逐条问自己：这个权限还在用吗？这个角色真的需要管理员权限吗？如果答案不确定，先关掉再说。权限可以再加，但泄露的数据回不来。
第二，扫描公开存储桶
AWS Trusted Advisor 和 GCP Security Command Center 都有内置的公开存储桶检测功能。免费的，你不需要装任何东西。但很多团队从来没打开看过。
用 CLI 也可以手动检查：
# AWS S3 检查某个桶是否公开aws s3api get-bucket-acl--bucketYOUR_BUCKET_NAME# 检查是否有公开访问的 Block Public Access 设置aws s3api get-public-access-block--bucketYOUR_BUCKET_NAME如果输出里有AllUsers或AuthenticatedUsers——你的数据可能已经在公网上裸奔了。
第三，把配置检查嵌入 CI/CD
不要把安全审查留到上线前最后一刻。那时候发现问题，要么延迟发布，要么带病上线。
# GitHub Actions 示例：每次PR自动检查 IaC 安全问题-name:Terraform Security Scanuses:aquasecurity/tfsec-action@v1.0.0with:tfsec_args:--minimum-severity MEDIUM如果 Terraform 配置里定义了一个公开 S3 存储桶，这个扫描会在 PR 阶段就直接拦截。安全审查不需要人的介入，它可以是一道自动门。
五、十二期了，我们回到了原点
第十二期。
从第一期聊 AI 写代码的隐患，到这一期聊云上配置错误的85%，十二期文章，话题从 AI 到内核，从法规到网络，横跨了技术栈的每一层。
但今天这期，像是一次回归。
我们第一期说过，运维正在从“操作员”变成“守门人”。这句话当时更多是一个判断。现在，Google 用85%这个数字，给它做了一个数据注释。
守门人的工作，不是自己下场打攻击者。是确保每次关门都关紧了，每次权限都设对了，每次配置变更都经过审查了。
这些事不酷，不新，不激动人心。但当事故发生时，你会发现这些基本功的缺失，比任何高级攻击都致命。
对于正在入行的你来说，这是一个好消息。
因为这意味着，你不需要先成为安全专家才能做出安全贡献。你把 IAM 策略理清楚、把存储桶权限检查一遍、把 Terraform 扫描接入 CI/CD——这些事不难，但大部分团队还没做。
谁先做，谁就先把门锁好了。
一期一会 · 本期核心笔记
- Google 年度报告显示，85% 的云上安全事件源于配置错误，不是高级攻击。三大重灾区是公开存储桶、IAM 过度授权、密钥硬编码。
- 配置错误泛滥的原因：云上配置复杂度爆炸、IaC 不能消灭错误、安全被认为是“别人的事”。
- 运维可以立刻做三件事：IAM 权限减脂、公开存储桶扫描、IaC 安全扫描嵌入 CI/CD。安全不是安全团队的专属，是你写的每一条配置。
这一期我们用数据验证了十二期以来一直在说的事：技术越自动化，基础配置的扎实程度越重要。下一期，我们回归 AI 话题线——Cursor 2.0 把 Agent 模式变成了正式功能。当 AI 写代码从“试用”变成“标配”，我们的讨论也该更新了。
这是《AI视界——从资讯看技术》的第十二期。我们继续。
如果这篇文章让你有所思考，欢迎在评论区聊聊：你检查过自己负责的云上资源吗？有没有发现过“忘了关”的公开访问权限？