AI开发牧安 · 第2期 做着做着，一个后台装不下了

回答第1期的一个问题，为什么叫牧安，什么含义。

牧安：就是牧羊犬的意思，帮客户放羊。没有什么高大上的含义。

第1期结尾我说，一个后台想把客户管理、资产、检查、监测、上报全塞进去，臃肿是迟早的事。不是迟早，是很快就来了。

混在一个库里的代价

WN101 能跑起来之后，我往里塞客户、塞资产、塞扫描结果、塞探针上报。隔离靠 RBAC——不同用户看见不同数据。短期没问题。

但很快不对劲：所有客户的数据都躺在同一台机器的同一个 SQLite 里。一个客户，把资产清单、日志、甚至敏感扫描结果全交到我这台机器上，他心里应该不踏实吧。而我这边，如果几十家客户的数据搅在一起，真出了岔子，隔离边界我自己都未必说得清。

更麻烦的是部署位置。WN101 那套，要从运营方机器去连客户的主机做检查——旧版甚至用过 paramiko 拿 root SSH 直连，Windows 靠本机 win32evtlog。这路子既危险又不现实：不可能每家客户都给开 root，人家网络也未必通，更有甚者，客户不见得知道root是啥。

数据不出场的底线

卡在这儿，我想明白一件事：要兜底"正在出事的小客户"，最低信任门槛是数据不出客户现场。客户的东西，得留在客户自己地盘上，运营方不能全捞回来。

那客户本地就得有一个自己的平台——能看自己资产、自己事件、自己报告。这就是二级。

而真正去客户主机上"看"东西的，不能是从云端派人去 SSH，得是下沉到客户主机里、或者旁路接在交换机上的轻量探针，自己跑、自己采、自己上报。这就是三级。

至于我这边（运营方），要在云端统一盯着多家客户，7×24 看谁出事了、谁该兜底了。这就是一级。

三个位置，三种角色

想清楚之后，就不是"做一个更大的后台"，而是"三个待在不同位置的角色"：

三级（Agent / 流量探针）：扎在客户服务器里或旁路，本机带个 Web 界面管服务、探资产，采集完主动上报。端口 8802。

二级（客户服务平台）：装在客户本地，客户自己管资产、管事件、给子公司开账户，往一级报数据。端口 8801。

一级（MSS 运营平台）：放云端，我这边统一收二级的上报、监控、响应，还能把数据外发给第三方 SIEM 或监管平台。端口 8800。

数据顺着 三级 → 二级 → 一级 往上走。但小客户没二级的时候，三级也能绕过二级直报一级——这条旁路得留着。

图片

隔离是红线

三个层级一定，多租户隔离就成了硬红线。一级上每家二级客户是独立租户，数据强隔离；二级给子公司、分公司开子账号，按组织树隔资产、隔事件；任何跨级跨租户的访问，没权限直接回 403。

还有断网。二级、三级得能断网自愈——客户现场网络抖一下，不能整个瘫了，得自己接着跑、缓过来再续传。一级才是中心和聚合。

顺手清了个旧账

之前文档里这产品有点人格分裂：一会儿写"单机兜底工作台"，一会儿写"分布式平台"，两套说法互相打架。这次我把话挑明——只留三级架构，单机兜底那套假设作废。旧版说的"V2.0 不做 7×24 SOC"，也被三级架构自然解决了：一级云端中心天生就是 7×24。

上面这张就是定下来的样子。一个采集端、一个本地平台、一个云端中心，数据从下往上走。

下一篇说点拧巴事

分层想清楚了，落到技术选型上我做了个当时挺反潮流的决定：不用任何 Web 框架，纯 Python 标准库硬写。

下篇聊聊为什么宁肯麻烦点，也不上 Flask。

本系列记录牧安平台从 0 到 1 的开发过程，一个待业在家的网安老兵边做边想。

上期：《从 WN101 说起》；下期：《在家折腾的技术选型》。