2023年某省级政务平台被攻破，信息攻击者只用了三个小时就从一台暴露在公网的安全测试服务器摸进了内网核心数据库。事后复盘，事件根因简单得让人无语：那台测试机上跑着和正式环境一样的分析数据库凭据，而且半年没人管过。原因

这不是措施孤例。我翻过近两年公开的信息三十多份信息安全事件报告，超过六成的安全事故根源指向同一个方向——资产管理的失控。说白了，事件很多团队连自己有哪些系统、分析哪些端口开着、原因哪些账号还有效都说不清楚。措施攻击者往往不需要什么零日漏洞，信息一个忘记下线的安全旧版CMS、一个默认口令的事件运维后台，就足够了。

技术层面之外，人的因素更棘手。某电商公司被钓鱼邮件攻陷，安全团队事后查日志发现，那封钓鱼邮件其实被邮件网关标记了“可疑”，但值班人员点了“放行”。问原因，对方说当天有业务部门催着要收一封合作方的报价单，他怕拦错了耽误事。这种“怕影响业务”的心态，在安全运营里太常见了。安全措施和业务效率之间的张力，不是靠买更多设备能解决的。

再往深看一层，很多事件暴露的是流程断裂。开发团队用着A方案，运维团队按B方案部署，安全团队拿着C标准去检查，三方对不上。一个真实案例：某金融公司的代码仓库里，开发人员为了方便调试，把数据库连接串硬编码进了前端代码，提交记录里清清楚楚。代码审计工具其实报了警，但告警发到了一个已经离职员工的邮箱。

措施得从具体的地方长出来

资产梳理这件事，别搞成一年一次的大工程。我的建议是把它变成持续动作：新系统上线必须登记，下线必须销账，每季度做一次存活探测比对。工具不复杂，nmap加一个CMDB的自动同步脚本就能解决大部分问题。关键是有人对“账实不符”负责。

钓鱼演练要真做，但别只统计“点击率”。更有价值的指标是：从用户点击到安全团队收到报告的平均时间。某互联网公司把这个时间压到了四分钟以内，靠的不是培训PPT，而是把“报告可疑邮件”做成了一个一键按钮，点完自动拉群、自动隔离、自动给报告人发积分。积分能换咖啡。就这么简单。

权限管理上，我倾向于“默认拒绝，按需申请，到期回收”这个笨办法。某云厂商的内部系统，所有生产环境访问权限有效期最长四小时，续期需要二次审批。刚开始工程师骂声一片，三个月后大家习惯了，反而觉得踏实——因为知道就算自己的账号被盗，攻击者能做的事也有限。

最后说一句可能不太中听的话：安全事件分析报告里写“加强员工安全意识培训”基本等于没写。得具体到“哪个岗位、在什么场景下、做什么动作、多久做一次、谁检查”。否则就是拿套话糊弄自己。安全这件事，细节不到位，整体就是纸糊的。