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\--flattenbindings[].members\--formattable(bindings.role)\--filterbindings.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-actionv1.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视界——从资讯看技术》的第十二期。我们继续。如果这篇文章让你有所思考欢迎在评论区聊聊你检查过自己负责的云上资源吗有没有发现过“忘了关”的公开访问权限— Compiled and Authored by Whisky — July 18 th, 2026
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\--flattenbindings[].members\--formattable(bindings.role)\--filterbindings.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-actionv1.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视界——从资讯看技术》的第十二期。我们继续。如果这篇文章让你有所思考欢迎在评论区聊聊你检查过自己负责的云上资源吗有没有发现过“忘了关”的公开访问权限— Compiled and Authored by Whisky — July 18 th, 2026
