去年一份安全智库报告里有一句挺扎心的话：超过一半的 IT 管理者把「团队缺技能」列成安全事件的首因，而不是预算不够。我挑了三个公开复盘里几乎每年都重演的场景，把它们地名、厂商名全隐掉，只看技术根因。

场景 A｜一个忘了关的 ES 端口

某家给物流做系统托管的科技公司，把 Elasticsearch 的 9200 端口直接朝公网敞开。里面跑的不只是运单号，还混着一批联系人字段。攻击者没用任何高级手法，就是扫端口、拉数据。事后复盘单上写着两条：没做网络隔离、没对敏感索引加访问控制。技术成本很低，疏忽成本很高。

场景 B｜匿名 FTP 的十年便利

另一家做文件共享的企业，为了让业务部门跨地打印，把 FTP 设成了匿名可读。云防火墙规则长期处于「不生效」状态。直到外部流量告警突增，才回溯发现涉事目录已经被分批拉走很久。便利性和隔离性在这里打了十年默契牌，最后由运维背锅。

场景 C｜数据库空密码

汽车租赁 SaaS 的一台 MySQL 把 3306 直接对外，root 没设口令。审计日志后来数出来，同一批数据被不同来源取走了上百次。这种案例在技术圈有个共识：弱口令不是低级错误，是攻击面入口。

三个案子串起来，你会发现共同点根本不是「黑客多厉害」，而是同一组老毛病——未授权访问、弱口令、日志没留、端口裸奔。DSMM 在「数据处理安全」这一章里的说法很实在：任何有数据权限的人，都是潜在的泄露向量；脱敏之前必须先有分类分级表，不是所有字段都值得脱。

EEC工信教考中心，数据安全工程师，聚鑫汇

马老师13521730416

丁老师13522094648

落到普通读者能做的 5 件事，不玄乎：

1. 业务系统对外开放端口做一次盘点，默认全关、按需开；

2. 数据库账号强制复杂口令+IP 白名单，禁用匿名共享；

3. 敏感字段在测试/分析环境走脱敏，不要拷真表；

4. 所有对敏感表的查询留审计日志，至少保留半年；

5. 每季度跑一次最小权限复核，把「顺手给的权限」收回来。

你们公司最近一次权限复核是什么时候？评论区说说，我挑几个典型场景下期拆。