云安全运营中心：产品、数据、权限三重闭环防护

文章配图，仅供参考

　　数据闭环更搞笑。安全组说“所有流量都经过数据湖分析”，结果演练时发现，某条业务线的API流量被标记为“内部信任流量”，直接跳过了数据湖的检测规则——问就是“业务方说影响性能，要求白名单放行”。后来查监控，这条白名单是三年前加的，当时负责的工程师早离职了，现在连谁批的流程都查不到。最绝的是，数据湖的日志保留周期只有三十天，演练时想复盘攻击路径，发现关键日志已经被自动清理了，安全总监在群里骂“这闭环闭了个寂寞”。

　　权限闭环反而没想象中烂。我们用的IAM系统是自研的，虽然界面丑得像九十年代网页，但权限审计功能确实硬核——演练时有个测试账号用管理员权限删了生产库的备份，系统十五秒内就触发了告警，自动冻结账号并通知了安全组。但问题在于，权限闭环太依赖人工复核了。安全组每天要处理三百多条权限变更申请，其中八十条是“紧急需求”，最后实际审核的只有五十条，剩下的全靠“信任审批”——结果演练时，测试账号就是用“紧急需求”绕过了审核，权限闭环成了“形式闭环”。

　　机房的冷风和低频噪音让我脑子发胀。那天下午，安全组和运维组在会议室吵了两个小时，运维说“产品闭环是你们安全组的事，我们只管机器不宕机”，安全组说“数据闭环是你们运维没配好规则，白名单是你们加的”。我在旁边翻演练报告，发现一个细节：攻击者用的漏洞是CVE-2021-XXXX，这个漏洞的POC去年就公开了，但我们的产品漏洞库里标记的是“低危”，因为“未发现实际利用案例”——结果现在被锤得满头包，安全总监拍桌子说“以后高危漏洞的定义不能只看公开案例，得看实际攻击趋势”。

　　食堂的剩饭凉了，我端着盘子去微波炉加热，听见两个运维在吐槽：“安全组就知道定规则，自己连Linux命令都敲不利索。”另一个说：“他们定的那些权限策略，连业务方都看不懂，更别说执行了。”我原以为他们只是发牢骚，结果回工位一看，告警群里又炸了——某个业务线的开发偷偷把生产环境的权限提到了root，说是“调试方便”，安全组发现时，人家已经用root权限删了三张表，数据恢复用了四个小时，MTTR直接超标。

　　后来复盘时，安全总监提了个“优胜劣汰”的理论：三重闭环里，产品闭环是基础，数据闭环是核心，权限闭环是保障，但实际运行中，产品闭环最容易被“优化”——因为产品更新快，规则同步延迟、配置错误这些“小问题”容易被忽略；数据闭环最容易被“妥协”——因为业务方总说“影响性能”，安全组为了不挡路，只能放行；权限闭环最容易被“形式化”——因为审核流程太繁琐，大家为了效率，最后都靠“信任”。他说“优胜劣汰”的意思是，三重闭环里，只有真正能落地、能扛住攻击的，才会被保留；那些虚的、形式化的，早晚会被淘汰。

　　但我觉得这理论有点扯。演练结束后，安全组连夜改了规则，产品闭环加了同步校验，数据闭环关了所有白名单，权限闭环上了自动化审计——结果第二天业务方就炸了，说“安全策略太严，影响开发效率”，要求“松绑”。安全总监妥协了，说“先保证业务不中断，安全慢慢优化”。现在三重闭环还在，但我知道，下次攻防演练时，该破的地方还是会破——因为“优胜劣汰”的前提是，有人愿意为安全买单，但现实是，业务方只关心“能不能按时上线”，安全组只关心“别出事故”，至于闭环不闭环，谁在乎呢？

　　UPS的嗡鸣声里，我翻了翻手里的演练报告，发现一个更讽刺的事：攻击者用的漏洞，我们其实在三个月前就收到过预警，但因为“优先级低”，没及时修复——现在想想，所谓“三重闭环”，可能连“预警-修复”这个最基础的环节都没闭环。下次再有人吹“三重闭环”，我大概只会笑笑，然后继续改我的规则——毕竟，能扛住攻击的，从来不是理论，是代码。

（编辑：汽车网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!