云上数据泄露，大多不是"被黑"，是配置错

一、半个月，方向全错

去年，有家做智能硬件的企业找到我们，起因很蹊跷：

竞品的新品发布会 PPT 里，出现了他们下一代产品的完整参数表——连成本测算页都有。

他们查了半个多月内网，翻遍了员工电脑，什么都没查到。

最后发现问题出在阿里云上：他们有个对象存储 Bucket，为了方便合作方下载固件包，被设成了公共读。

谁都能列目录，谁都能下载。

一份 IDC 安全报告早就说过：云上数据泄露事件里，配置错误占的比例远超黑客攻击。大部分根本不是"被黑"，是数据自己挂在公网上"晒"着。

二、锁是好锁，就是没人关

上云之后，很多企业有一种错觉：服务器在云上，云厂商会替我管安全。

这话只对了一半。

云厂商管的是平台本身不出问题；但 Bucket 开不开公开访问、数据库绑不绑公网 IP、安全组放不放行 3389 端口——这些都是你自己账号里、自己点出来的配置。

点错一下，等于把仓库大门敞开。锁还是好锁，就是没人关。

三、三种"敞门"姿势

姿势一：整柜子钥匙插在门上

为图方便让客户下载文件，把整个 Bucket 设成公共读甚至公共读写。结果客户资料、备份文件、合同扫描件，全都能被匿名列出。

这种事在安全厂商的扫描报告里每周都有新案例——搜索引擎随便搜一个关键字，就能列出一串。

姿势二：把仓库开在马路边

图远程办公方便，MySQL、SQL Server 的 3306、1433 端口直接对公网开放，root 密码还比较弱。

勒索团伙的扫描器 24 小时在公网上扫这些端口，挂上去基本等于举手报到。

很多勒索事件的起点不是钓鱼邮件，就是一台暴露在公网的数据库弱口令。

姿势三：管理端口裸奔

云服务器远程桌面 3389、SSH 22 直接对公网开放，再配一个 "Admin@2024" 式的密码。

攻破只是时间问题。

四、一张能直接用的巡检清单

这类问题防起来不难，难的是没人负责定期看。

建议每月跑一遍这四项：

① 对象存储权限

盘点所有 Bucket 的访问策略，非公共需求的一律改私有 + 签名 URL，有效期控制在 24 小时内。

② 数据库公网地址

能用内网和 VPN 访问的，就把公网地址关掉。

③ 安全组最小开放

按"最小开放"原则过一遍：管理端口只对固定办公出口 IP 放行。

④ 云账号本身

子账号是否滥用主账号密钥？AccessKey 有没有出现在代码仓库里？多因素认证开没开？

AccessKey 泄露是近年上升最快的入口之一——程序员把它写进代码提交到 GitHub，第二天就有人拿去开机器挖矿。

五、靠人点控制台，坚持不过三个月

说实话，这套清单靠人工每月点一遍控制台，十有八九坚持不了三个月。

它可以交给工具：上邦的终端与数据安全体系里，配合资产盘点和异常外联监测，能及时发现终端到陌生云地址的批量上传行为——等于在云上配置之外，又加了一道内部视角的哨兵。

配置没关严的口子，流量会替你说话。

六、云不是不安全，"以为安全"才最危险

数据搬上云的第一天，就该同步把配置基线立起来。

别等竞品发布会那天，才想起来查。