墨菲定律并不是说会有坏事发生，而是说只要有可能，就一定会发生。 ——《星际穿越》

0x00 前言

最近经历了一些比较潦草的设计和运营。虽然说世界就是一个巨大的草台班子，也经历了好友的鼓励，同事的开导，见怪不怪之后，除了无奈😮‍💨，倒也学了些别样的心得。不总结一下，反倒错失了一次成长。所以决定从架构的角度再聊一聊对安全运营的理解。（注：下文所指的安全运营并非仅指 SOC，而是指整个信息安全团队的日常运营工作。）

0x01 面向失败设计

正常来说，稍具规模的正经企业中所经历的安全运营，从外到内必有三道防线，自顶向下则上有策略->规范->流程，中有告警->事件->工单, 下有响应->溯源->复盘。前有系统后有平台，左有数据右有脚本， 安全团队也自以为是相当全面，马力全开。但为什么还是出现大量问题，大部分情况缺乏验证所致，以及缺乏专业人员去进行验证。当然，这么说和安全验证类产品并没有半毛钱关系，企业内的业务复杂度，暂时也不足以支撑有效的商业安全验证产品能够完全落地。而是希望从 面向失败设计的思维来简单讨论一下（这并不是一个新鲜的概念，而是一直用在系统工程设计中的，今天挪过来聊聊运营）。面向失败设计的核心其实并不在于设计，而是在最初之时接受并理解失败是不可避免的。就像墨菲定律中所言，只要有可能发生就一定会发生。而安全显然是不存在绝对安全的系统，那就意味着一定会有问题出现：

• • 你以为有了专线就一劳永逸，实际上两端系统都有高危漏洞；你以为需要的安全产品部署妥当了，结果发现不仅 HA 是摆设，甚至安全系统本身就留有 Knock 后门；你以为引入了“新鲜”的产品，实际也可能就是中国特供；你以为有做 IP 白名单限制便是固若金汤，心中暗想也不过就是日常运营复杂了点，却不知道实际上后台系统都是弱口令，完全经不起猜解；你以为集成了 SSO 便可万事大吉，谁料想哪能连个 MFA 都没有；你以为有了 MFA 就能高枕无忧，实际上 MFA 居然没有时效；你以为的木桶短板已经足够高的时候，一次钓鱼邮件就前功尽弃；更别提员工在单纯点钓鱼之外还能离开不锁屏。

• • 你以为密钥经过多个 KSO 安全产生并传输，殊不知接收方直接放在了配置文件里，（还谈什么密钥和机密数据同样重要）；你以为 EAAS 提供稳定的加解密服务，殊不知接收方直接本地进行计算；你以为数据分类分级做的很完善，未料想日志里打出了很多 PII 信息，已经持久化的数据也没有处理；你以为有了人机验证就能阻挡机器流量，实际配置可能还在观察模式；

• • 你以为终端很安全，却未料想哪次工单忘记回收管理员权限；你以为控制策略很完善，却不知道有特权账户的人早已安装了许多白名单外的软件；你以为 DLP 策略精准，上网行为控制完善，却不知道真正的数据外泄只需要一次，从不需要多次。

• • 你以为的扫描器规则充分，却不知道三方库被遗漏了；你以为的架构设计 review 中增加的安全部分方案合理，却不知道实际上根本没人按这个做；你以为打了一个补丁没事了，谁知道又引入了一个新的补丁；你以为的培训有效了，谁知道别人都快睡着了；你以为 SIT/UAT/PROD 隔离的很好，却不知道哪里早已被打通了；你以为的 TLS 证书用来做客户端认证很美好，实际上却不知道服务端根本不验证 CA 和有效期；

• • 你以为供应商专业，经验充足，实际上策略为空，却告诉你已经打完收工；你以为一条策略即可生效，实际上却常年累月不见告警；你以为覆盖了很多指标，数据看板一做一个，但对于事件而言却显得纬度单一，不足以分析。你以为面试上写的精通溯源分析是做过大型事件处理，没曾想刚看完 splunk 的入门培训。你以为五年的资深运营，原来更多只是看看告警。

• • 你以为的演练声势浩大准备充足，实际上却不知道是因为阴差阳错的情况下负负得正； 你以为审计能够帮你发现问题，实际是牛来弹琴比对牛弹琴还难。你以为自己足够专业，理论熟练，经验充足，实则也可能一叶障目（骂一下自己）。

往往在运营的过程中，更多的人是只见树木，不见森林，以为看好了自己那一摊子，却高估了专业性，并有着皇帝新衣式的自信。而实际情况要么缺乏设计（以为自己设计了），要么过渡设计（嘿！真够专业的）。前者不做讨论，后者则往往给出繁杂的指标衡量，多个流程制度。也恰恰是因为存在这些流程制度及指标（先不讨论合理不合理），给了设计者和所有人一个错觉：“我们/系统是安全的！” 一种新的灯下黑产生了。我曾切实的遇到一个审批流有 6 个节点，通过之后有半年有效期。但仅在能使用的时候联系对应的 IT 人员把你加到对应的组里。（看，这是多么安全！）

再回到面向失败的设计上，在架构上来说不仅是从资源层面做到冗余容错以及数据备份，还要使应用模块化，能够降级或自愈，在运营（架构设计中的运营模块）中还要去做好变更管理，测试验证，灾难演练，备份恢复等等吧。那从 BAU 本身来看，以面向失败的设计思路看甲方日常运营的话，主要分两块（其实是老生常谈）：

有效性检测：

• • 定期风险评估（你不能相信任何既定的白名单，也不能相信任何已有系统的稳定性，一方面定期评估，一方面持续性监控）

• • 确保尽可能对既定场景做预案（你不能确保某个可以搞定某件事的人在事情触发时就在那！要让每个人能够依靠 SOP 进行处置）

• • 检查冗余和备份是否生效（备份数据是空的？UPS 电池没有电？密钥备份导不进去了？）

• • 确保监控系统是否实时生效（告警没有通知出来？日志不吐了？监控系统不能登陆了？排查的时候发现某个组件开关没开过？）

• • 培训后的考试（你在培训，线上的在睡觉，线下的在唠嗑）

连续性检测：

• • 做好季度性演练（避免为了暴露问题而造问题，安全意识是要持续的）

• • 写好安全部门的 BCP（没了张屠夫，也不能吃带毛的猪）

• • 做好自动化（机器比人做重复的运营更可靠，人去确保自动化有没有运转起来即可）

• • 模块化流程但反模块化运营（架构设计中面向失败讲究模块化，但对于运营则需要确保每个人的模块都有 backup，横向支撑团队，不是“我只会 xx，我只干 xx”，但需要加钱）

当然即便如此，意外还是会发生。有时来自合作商意外操作（世界就是个巨大的草台班子，Again），有时因为缺乏记录需要自证清白。但回到前面所说，面向失败设计的要点就在于接受失败。意外是不可预期的，尤其在应急响应的过程中，如何冷静的给出方案并协调相关部门参与进来，快速落地补救才是最重要的。至于追责此时反倒没那么高优先级（也许有人不愿意做，可能是已经提前考虑到事后定责）。

0x02 安全即服务

安全工作本身是不对等的。想保证机密，就很难保持信息透明；想做好安全默认，就会对架构有侵入；想做好 SDLC，就要切入业务流程； 有一边需要业务无感，另一边就需要对基础设施做改造。对业务提安全即服务，对内就要做好安全平台。而对于提供安全服务出去，就是要把 BAU 变成流程变成平台变成 API 接口的过程。这和 SAAS 类的服务还是稍有不同的，一个是把产品对客户提供，一个是把服务做成产品提供给客户。但甲方安全又何尝不是企业内的乙方？

对于企业而言，无论是研发团队承担这个工作还是安全团队自己实现相应安全平台，在维护安全服务连续性的过程其实就是企业本身为失败买单的过程。设计规划的成本、开发和实现的成本、运维成本、培训成本等等。当然对于企业方向的调整过程，本身就不得不为新的目标买单。 之所以讨论安全即服务这个话题，是最近看了下安全运营即服务的 PPT，基本上都是从生命周期管理和 SOC 两个方向去做介绍的，中间也穿插一些新兴的技术和产品。比如 AI 的应用，SOAR 的优化之类。但实际通篇看来并没有能够体现出安全运营即服务中的运营部分。一边看着像是能够包圆了整个 SOC 的运营过程，但品来品去总觉得缺少了什么。虽然 XX 即服务并不是一个新鲜的话题，但我不禁揣测，是否是市场寒冷，人力资源成本上升，通过人力资源池的方式既能为客户降低成本又能中间商压榨一波安全运营人员的最大价值。不禁让我想起了三体中的人列计算机。对于大型企业，能养得起 SOC 团队不在乎这点降本，而小规模的企业又不在乎安全。似乎安全服务即运营逐渐的使安全运营工作变成了人力密集型工作了。值得一提是云厂商提供的安全产品，Pay As You Go 的模式。反倒更像安全即服务一些。当然考虑成本的话，虽然乙方厂商似乎都在大放异彩，但甲方却瘦的骨感。屁股决定脑袋的年代，还是要保持点客观的思考。

0x03 总结

当我准备写一篇关于安全运营的文章时，才猛然意识到。当年有多讨厌 BAU，今日就需要多么慎重的审视它。但想要做到既见树木，又见森林，何其难哉。一方面 BAU 的工作是无法逃避的，另一方面又要放弃自己对技术的固有认知。因为并不是所有在逻辑上成立的东西都能够在具体的运营场景中按照预期运行。尤其在金融行业，越是基础的东西，似乎就越可能脱离常识。存在着大量独特的场景。就像你知道完善鉴权的公网域名 API 访问是优于专线的 IP 访问，但是依旧是只会做白名单，专线，硬编码。久而久之这里的人都会认为，运维研发分离的模式，专线 IP 白名单的模式非常安全。嘴里提着纵深防御，却实际还是老一套，也会挂点新鲜名词，什么混沌工程之类的，但是实际怎么样就不得而知了。相对于传统金融架构和互联网金融架构而言，两者之间的 GAP 还是很大的。几乎完全不能相信设计，要先看看落地落的什么样子。因为在传统的金融架构中，甚至在交易的相关系统中都不需要 DNS，因为 DNS 可能存在缓存（也许这并不是一个合适的理由）。

如今大模型的发展，对于安全运营工作从业人员其实还是比较悲观的。以 GPT4 为例，写胶水语言（豆包，通义在写代码方面甚至不如 GPT3.5），做代码审计，效率介于 Junior 和 Senior 之间。慢慢三道防线会被演化成一个 senior 的写好 prompt，由 Junior 的工程师配合上 GPT 就可以了，成本缩减的同时又可以看向真正的安全运营即服务。

我曾一度犹豫、一度思考。-1 到 0 和 0 到 1 的区别。对于架构设计而言，从-1 到 0 和 0 到 1 实际没有太大的差别，你没有架构，就从 0 设计（V1 版本架构）。你没有正常的架构（T-1 版本），就设计出正常的架构（V1 版本架构），作出 N 个 Phase 实现。但是对于运营-1 到 0 和 0-1 简直天壤之别。因为运营是不能一步到位的，不谈优化，单单拨“乱”反“正”是一个无法逾越的鸿沟。人力资源成本，相当于先勒住背道而驰的马，才能策马向前。从 T-1 版本下做运营的 0-1，痛苦不言而喻。