合规约束下的安全架构：为什么"数据安全/网络安全"需要一个统一数据平面

📌 摘要

当下主流的安全产品体系，是按技术栈层次分科的：网络安全、终端安全、数据安全、应用安全……每个品类对应一个技术层次，各有一批厂商。这种分科方式有其历史必然性，但它与"攻击的连续性"之间存在一个根本性错配——攻击者的路径从不按这个分类行进。

结果是一个长期被忽视的结构性缺失：跨层次的能力关联，在产品体系中找不到承载。 一个真实的数据外泄事件必然同时穿过数据库层、终端层、网络层，而承载跨层关联判定的那一层，在当前的产品结构中缺少落点。

本文不主张任何一个现有品类没有价值，也不主张"分科"是错误的，而是试图回答一个不同的问题：这种"缺少承载"的现象，是厂商能力不足，还是产品交付形态的必然结果？ 我们认为答案偏向后者——并且相信，插件化的数据平面架构可以让"跨层深度关联"与"合规可交付"这两件长期互斥的事同时成立。

0. 前提：攻击的连续性 vs. 防御的分科性

在讨论具体品类之前，需要先明确一个更基础的事实。

安全行业的分科，是按技术栈层次划分的：网络层 → 网络安全；终端层 → 终端安全；数据层 → 数据安全；应用层 → 应用安全。这套分科来自技术演进的历史路径，也对应着厂商的组织架构、产品线与渠道体系，有其充分的合理性。

但攻击者的入侵路径，不是按这个分类行进的。 一次典型入侵大致如下：

钓鱼邮件进入        →  归属"邮件安全"
   ↓
终端被控            →  归属"终端安全 / EDR"
   ↓
内网横向移动        →  归属"网络安全 / NDR"
   ↓
提权、定位数据库    →  归属"主机安全"
   ↓
批量导出数据        →  归属"数据安全 / 数据库审计"
   ↓
数据外发（走网络）  →  归属"网络安全 / DLP"

请注意这条链的最后两步：数据在离开企业的那一刻，是"走网络"离开的。 也就是说：

"网络"与"数据"并不是两个平行的品类，而是同一条攻击链上无法切割的两段。

由此可以更精确地表述问题：

• 网络侧观测到的外发行为，其成因在数据侧（谁导出的、这是不是敏感数据）；
• 数据侧观测到的导出行为，其后果在网络侧（发往何处、是否出境、是否符合合规要求）。

把一个连续的动作切成两段，卖给两个部门，结果必然是两段各自都"正确"，合起来却无效。

一个常见的真实现象可以印证这一点：客户买齐了网络安全与数据安全产品，仍然防不住数据外泄。原因是两层之间没有共享语义——

这不是执行力问题，而是分科方式导致的信息断裂。 而在当前的产业体系中，没有哪个单一产品有能力、也有动力去承载这个断裂处的关联。

因此，本文讨论的起点不是"某个品类做得不好"，而是一个更上游的问题：当攻击是连续的时候，防御是否可以只靠分科的产品堆叠来应对？

1. 一个真实的失效场景

设想一次典型的内网数据外泄。它通常包含三个动作：

1. 数据在库被批量导出 —— 有人执行了一条查询，一次性取走 8 万条客户信息；
2. 数据在终端被落地 —— 某个进程把结果写入 CSV、复制到剪贴板、或接入移动介质；
3. 数据在网络被外发 —— 一个内部主机向境外 IP 传输了 20MB 数据。

现在看三个产品各自的视角：

结果是：三个产品都会产生告警，但没有任何一个系统知道这三条告警描述的是同一件事。 数据库说"有人导出了敏感数据"，终端说"某进程写了文件"，网络说"某主机外传了流量"——三条线索都在，但它们无法自动合并成一条"数据外泄"的判定。

这不是产品缺陷导致的偶发现象，而是分层观测的结构性结果。

2. 这是厂商能力问题吗？—— 一个更公平的解释

一个自然的结论是"厂商看不到这个价值"。但更接近事实的解释是：跨层关联能力，与当前产品的交付形态存在结构性冲突。

具体冲突有三点：

第一，可独立验收的约束。 安全采购的验收对象通常是单一产品。一个产品要能独立部署、独立测评、独立出一份报告、独立签字。而"跨层关联"天然不属于任何单一产品的边界——它需要同时接入另外两个产品的数据，这在一份采购合同里无法界定验收标准。

第二，可独立计价的约束。 每个产品都要能被单独计价进入采购清单。"跨层关联"如果作为附加功能，无法单独定科目；如果做成独立产品，又必须假设客户已经买了另外两层——这会让销售链条变得极其脆弱。

第三，责任边界的约束。 安全产品在出事时需要界定责任。数据库审计产品对"数据库层的审计覆盖"负责，EDR 对"终端行为监测"负责。而"关联判定"一旦出错（漏报或误报），责任无法归属到任何一方。

所以，"在数据库层面纠结"不是视野问题，而是这个品类唯一能独立交付、独立验收、独立签字的落点。 这既是它的优势，也是它的边界。

理解这一点，是理解整个安全产品形态的关键。 技术上的最优解与商业上的可交付物，经常不是同一个东西。

3. 更深一层：客户真正为什么付费

讨论到这里，需要引入一个更根本的约束。

在对安全产品的采购决策中，"是否真的更安全"这件事的实际权重，往往低于"是否可证明我做了该做的事"。原因是一个无法回避的悖论：

安全投入的收益是"没有发生的事"，而"没有发生的事"无法被证明。

于是理性的决策自然转向可证明的替代物：测评报告、合规材料、采购目录、审计记录。这不是客户不重视安全，而是激励结构使得"可证明"成为刚需。

这个约束条件无法被技术消除，只能被正视。因此：

• 任何只谈技术先进性、不谈合规可交付性的方案，在采购环节会直接失效；
• 任何只谈合规、不谈真实检测能力的方案，能卖出去但也确实只解决了 1/3 的问题；
• 真正的机会在于同时满足两者——而这需要一种新的产品形态。

3.5 行业试过了：态势感知为什么没能解决这个问题

到这里，一个自然的反问是：如果跨层关联如此重要，行业难道没有尝试过吗？

尝试过，而且投入巨大——它叫"态势感知"。

3.5.1 它的初衷与本论证完全一致

态势感知（Situational Awareness）的设计诉求，正是"把割裂的安全数据汇总起来，形成全局视角"。它的出发点与本论证第 0 节完全一致：单层产品各自看局部是不够的，必须有一个全局的观察位。

这一点值得充分肯定：行业很早就意识到了层次割裂的问题，并给出了产品化回应。

3.5.2 但它的落点，多数停在了"展示层"

问题出在实现方向。绝大多数态势感知产品的实际形态是：

核心偏差在于：把"数据汇聚"当成了"数据融合"。

这两个概念的区别是本质性的：

• 汇聚是"把 A 的告警和 B 的告警放在同一块屏上"——这是展示问题；
• 融合是"理解 A 的信号与 B 的信号描述的是同一件事"——这是语义问题。

而语义问题的前提，是统一的数据模型。这恰恰是多数态势感知产品所缺少的——它们通常构建在展示层，底层仍然是各家产品各自的数据格式，因此在数据层面并未真正打通。

于是形成一个典型现象：态势感知有"态"（各层的状态都能看到），却难以给出"势"（跨层关联后的趋势判断）。它把 1/3 + 1/3 + 1/3 的信息并列在一起展示了，但没有把它们合并成 1。

3.5.3 这个案例恰好反证了本文的核心论点

态势感知的历史，给出了三个重要结论：

第一，它证明了需求真实存在。 行业愿意为一个"全局视角"投入巨大资源，说明跨层关联不是臆想出来的需求。

第二，它证明了问题不在展示层。 在展示层做集成，无论做得多漂亮，都无法产生跨层判定——因为关联的前提是语义统一，而不是画面统一。

第三，也是最关键的：它说明跨层关联不是一个"功能"，而是一个需要承载的"底座"。 态势感知试图把它做成一个产品，结果只能做成一块屏；因为一个产品无法同时承担"统一数据模型 + 跨层分析 + 多点执行"这三件事——这正是第 2 节所述的三重商业约束在起作用。

结论：行业已经试过了。它试在了正确的问题上，但落在了错误的位置。 需要的不是更好的展示层，而是把承载位置下移一层——从展示层下移到底座层（数据平面）。

3.5.4 一个重要的界定：这不是竞争关系

必须明确，本方案与态势感知不是替代关系：

两者的关系是垂直的、可以叠加的，而不是水平的、互相替代的。 本方案要做的是补上那块一直缺席的底座，让态势感知这类上层应用真正有"势"可言。

4. 插件化数据平面：让两件事同时成立

如果冲突的根源是"产品形态必须可独立交付、可独立计价、可独立担责"，那么解法就不是做一个更好的单体产品，而是改变承载形态。

核心思路是把安全能力拆解为三类原子件：

配套一个统一数据总线作为基座，规定：

• 数据只在 Sensor 处采集一次，可被任意 Analyzer 订阅；
• 每个 Analyzer 是独立插件，可独立交付、独立验收、独立计价；
• 跨层关联由一个专门的 Analyzer 承担，它的产物是一条判定结论，而非一个需要被整体采购的产品。

这样一来，第 2 节里的三个冲突全部被解开：

关键洞察是：真正稀缺的不是那三种采集能力——它们在市面上都有成熟实现；稀缺的是中间那层"跨源关联判定"，以及承载它的统一数据平面。 而这一层之所以长期空白，正是因为旧的产品形态无法承载它。

4.1 更本质的一点：按"功能角色"分，而不是按"技术层次"分

回到第 0 节提出的错配。旧体系按技术层次划分能力（网络 / 终端 / 数据库），而攻击是连续的——层次分科天然会在层次交界处产生盲区。

本方案的分法不同：它不按"数据在哪一层"来组织，而按能力在一条检测链中扮演的角色来组织：

这个分法带来的直接结果是：网络与数据的"不可分割性"第一次有了落点。 以前"跨层关联"因为不属于任何一层，所以没有产品能承载；现在它是一个 Analyzer 插件——有明确归属、明确责任、明确交付物，同时又可以自由地跨层取数。

换言之：分科不是被推翻，而是被补上了一层"横向能力"。 纵向的产品线仍在各自位置上正常运转，横向的关联能力则获得了独立的承载形态。这也是本方案能同时被客户与厂商接受的关键——它不要求任何人放弃现有投资，只要求提供一次数据接入。

5. 这解释了为什么必须全面开源

上述论证要成立，有一个前提必须被解决：如何让既有厂商愿意把自己的能力接入这个数据平面？

这里存在一个天然的不信任：如果基座是闭源的商业产品，厂商接入它等于把自己的能力交给一个潜在的竞争者，同时让出与客户的直接关系与利润空间。在这种预期下，"接入"永远无法规模化。

全面开源是消除这种不信任的唯一可信表达。 它的作用不是营销，而是立场声明：

我不是来替代你的产品，而是来补上你无法承载的那一层。我不打算通过这个基座向你的客户抽成，也不打算让它成为你产品的前置门槛。代码全部可见，你可以验证这一点。

这也解释了为什么宽松许可（如 Apache-2.0）比传染性许更合适：AGPLv3 的设计目标是防止他人免费使用，而本项目的核心诉求恰恰相反——它需要被广泛使用、被集成、被吸收。许可的选择必须服务于目标，而不是服务于防御姿态。

开源在这里不是"分发方式"，而是"商业逻辑的一部分"。 闭源则整个论证不成立。

6. 边界与不做的事

为保持讨论的诚实，必须明确本方案的边界：

• 不主张现有产品无效。 数据库审计、EDR、NDR 各自解决的问题是真实且必要的，本文仅指出跨层关联缺少承载。
• 不主张"按层次分科"是错误的。 分科是技术演进与产业组织的必然结果，有其充分合理性；本文只是指出"层次分科 + 连续性攻击"之间存在需要补充的空间。
• 不主张合规需求是形式主义。 合规是客户在真实激励结构下的理性选择，任何方案都必须尊重这一约束。
• 不自研底层引擎。 采集与分析能力优先集成成熟开源组件（如 Zeek、Suricata、OSSEC 等），本项目的价值在于编排与关联，而非重造引擎。
• 不承诺企业级完整度。 本方案的目标是论证架构的可行性，而非提供一个可立即替代商业产品的完整系统。
• 关联判定不等于自动处置。 高危动作必须保留人工确认环节，自动化仅在低风险动作上启用，且全程可审计、可回滚。

7. 结论

安全产品的形态，长期被三个约束塑造：可独立验收、可独立计价、可独立担责；而行业的分科方式，又长期按技术层次（网络 / 终端 / 数据 / 应用）而非攻击的连续性来组织。

这两个因素叠加，产生了一个结构性结果：跨层关联这一真实需求失去了承载——不是没人看见它，而是没有产品形态能装下它；网络与数据本不可分家，却在采购与责任体系里被切成了两半。

行业并非没有尝试。 态势感知正是对这一问题的产品化回应，它试对了问题，但多数落在了展示层——把"数据汇聚"当成了"数据融合"。这反过来印证了问题的性质：跨层关联不是一个功能，而是一个需要被承载的底座。

插件化的数据平面提供了一条路径：按"能力在检测链中的角色"（采集 / 分析 / 执行）而非"技术层次"来组织能力，让关联判定成为一个可独立交付、独立计价、独立担责的插件，从而使"跨层深度关联"与"合规可交付"不再互斥。

而要让这条路径被行业接受，全面开源不是可选项——它是这个方案能否成立的前提条件。