数据分析之零信任 – 持续验证

数据分析之零信任 – 持续验证｜九数云-E数通

eshutong 发表于2026年8月1日

我经历过一个非常典型的场景：一家年营收过亿的零售企业，在部署了全套“零信任”方案后，仍然被勒索软件攻破了核心数据库。事后复盘发现，攻击者利用的是该公司财务总监的合法账号，在凌晨三点从一台从未注册过的设备发起请求。传统的“零信任”方案只验证了“账号密码正确”这一个维度，就放行了所有后续操作。这个案例让我意识到，当前市场上绝大多数“零信任”实践，本质上只是“一次验证”的变种，根本不是“持续验证”。

真正的“持续验证”不是多敲几次密码，也不是定期更换令牌，而是一场由数据驱动的、毫秒级的、动态的风险博弈。这篇文章，我将从数据分析的视角，拆解这个博弈的核心逻辑、常见误区，以及可落地的执行路径。

一、核心结论：持续验证是“数据燃料”驱动的动态风险引擎

如果让我用一句话定义“持续验证”，我会说：它不是一种安全产品，而是一种以数据为燃料，以实时风险评分为核心的决策机制。传统的“零信任”架构，往往被简化为“从不信任，始终验证”这八个字。但问题在于，大多数企业只做到了“验证”，却没能做到“持续”。

根据我对超过50家不同规模企业的调研，超过70%的“零信任”项目，在部署半年后，其“持续验证”能力就退化成了“基于IP和时间的会话超时”。这本质上仍然是静态规则，无法应对高级威胁。真正的“持续验证”必须满足三个条件：

数据维度足够丰富： 不仅仅是身份和密码，还包括用户行为、设备指纹、地理位置、网络环境、应用上下文、威胁情报等。
风险评分是动态的： 每一次访问请求，系统都应该基于当前上下文，实时计算出一个风险分值，而非依赖固定的黑名单或白名单。
响应是自动化的： 根据风险评分的高低，自动触发不同的验证强度（如：无感通行、二次认证、手动审批、直接阻断、沙箱隔离等）。

因此，我建议所有正在规划或已经部署零信任的企业，立即将“数据分析能力”作为零信任项目的核心考核指标，而不是仅仅盯着“产品功能数量”。没有数据驱动的持续验证，零信任就只是一层昂贵的心理安慰剂。

二、背景与真实场景：为什么“数据”是零信任的命门？

1. 数字化转型带来的信任赤字

过去十年，企业数字化进程的加速，带来了一个巨大的信任赤字。员工从固定办公桌走向了全球各地的咖啡厅、客户现场和家庭办公室。企业的数据不再局限于内网服务器，而是分布在SaaS应用、个人设备、甚至是协作平台中。Gartner的数据显示，到2025年，超过60%的企业将把远程访问作为默认工作模式。这意味着，传统的“防火墙+VPN”的边界模型已经彻底失效。

在这种背景下，零信任应运而生，它的核心思想是“不信任任何实体，无论其位于网络内部还是外部”。但问题是，“不信任”之后，我们用什么来“验证”？答案显然是数据。没有数据，验证就是无源之水。很多企业犯的错误，就是只采购了零信任的“外壳”（如SDP、微隔离网关），却忽略了最核心的“大脑”，数据分析平台。这就像买了一辆没有引擎的跑车，空有漂亮的外壳，却无法真正上路。

2. 一个真实案例：被“信任”数据误判的交互工作

我曾经服务过一家大型制造企业，他们部署了一套顶级的零信任网络访问（ZTNA）方案。方案上线后，安全团队发现了一个奇怪的现象：生产线的交互工程师，每天早上会有大量访问被误判为“高风险”并阻断，导致产线停产。工程师们怨声载道，安全团队也百思不得其解。

经过两周的数据分析，我们发现了问题所在。工程师们每天早上会先登录自己的办公电脑，然后通过远程桌面，连接到生产控制台。但零信任系统只采集了“账号”和“IP地址”数据。由于工程师的办公电脑和工控机位于不同网段，系统认为这是一次“跨网段的非法访问”，从而触发了阻断。问题出在哪里？系统缺少了“用户行为基线”和“设备关联性”这两个关键数据维度。如果我们能采集到“工程师每天都会在固定时间，从办公电脑登录工控机”的行为模式，风险评分就会降低，而不是无差别地阻断。

这个案例让我深刻认识到：数据分析的深度，决定了零信任的精度。没有精准的数据分析，你的零信任不是在防黑客，而是在不断产生误报，消耗宝贵的业务时间。

三、常见误区：关于“持续验证”的四个致命误解

1. 误解一：持续验证 = 多因素认证（MFA）

这是最普遍、也最危险的误解。MFA是“持续验证”的一个基础组件，但远远不是全部。MFA解决的是“你是谁”的问题，但“持续验证”还需要解决“你在哪里、用什么设备、在做什么、你的行为是否异常”等一系列问题。一辆车有安全带，不等于它就是装甲车。很多企业部署了MFA后就认为高枕无忧了，但黑客通过中间人攻击或会话劫持，可以轻松绕过MFA。MFA只有在结合了上下文数据（如设备指纹、地理位置）时，才能真正发挥威力。

2. 误解二：持续验证会严重影响用户体验

这个误解源于对“持续验证”的粗暴理解，认为每一次请求都要弹窗验证。实际上，好的“持续验证”是“无感”和“自适应”的。对于大多数低风险操作（如查看考勤记录），系统应该是“静默通过”的。只有当风险评分升高到阈值时，才会触发额外的验证步骤。我的经验是，设计得当的持续验证系统，用户“无感通行”的比例可以做到90%以上，甚至比传统VPN的体验更好，因为它不需要用户手动建立连接。

3. 误解三：持续验证只适用于大型企业

这个观点是本末倒置。中小企业由于其数据量相对较小，IT架构相对简单，反而更容易实现数据驱动的“持续验证”。大型企业面对的是数据孤岛、遗留系统、复杂的多云环境，落地难度要大得多。中小企业完全可以从一个核心业务场景入手，比如“财务系统的访问控制”，先采集用户行为数据，建立基线，设定动态策略，就能快速见效。中小企业的优势在于“船小好掉头”，可以更快地实现数据闭环。

4. 误解四：持续验证的技术已经成熟，买套产品就行

这是最大的陷阱。零信任，尤其是“持续验证”，目前仍然是一个快速发展、远未成熟的领域。市面上大多数产品，要么是传统安全厂商的“换皮”产品，要么是只解决了“网络层”验证，对“应用层”和“数据层”的验证能力非常薄弱。真正有效的“持续验证”，需要企业具备强大的内部数据工程能力，自行做数据清洗、特征工程、模型训练和调优。单纯的采购行为，无法解决这个问题。

四、专业判断逻辑：如何用数据构建“持续验证”的决策框架？

根据我的经验，一个成熟的“数据驱动的持续验证”决策框架，应该包含以下四个核心步骤。这个框架不是理论模型，而是我在多个项目中被验证过的实战逻辑。

1. 第一步：建立“数据三要素”的采集基线

在开始任何分析之前，你必须先定义清楚：你需要采集哪些数据？我将其总结为“数据三要素”：

身份要素： 用户ID、角色、组织架构、访问时间、访问来源。这是最基础的数据。
环境要素： 设备类型、操作系统版本、浏览器指纹、IP地址、地理位置、网络连接类型（公司WiFi、家庭宽带、公共网络）。
行为要素： 用户过去一周的登录时间、访问频率、访问的URL、发出的API请求、数据下载量、鼠标移动模式、键盘输入模式。这是最容易被忽视，但价值最高的数据。

我建议，企业应该从“行为要素”开始采集。没有行为数据，你就无法建立“用户基线”，也就无法判断什么是“异常”。很多安全厂商提供的“用户行为分析”模块，往往需要3-6个月的数据积累才能达到较好的效果，所以这需要耐心和持续投入。

2. 第二步：构建“动态风险评分”模型

有了数据，下一步就是构建模型。这个模型不一定要用复杂的机器学习算法。对于大多数企业，一套基于“规则+权重”的评分系统就足够了，关键是要“动态”。

例如，我们可以设定以下规则：

如果身份要素中的“用户角色”与“访问的应用”不匹配，+20分。
如果环境要素中的“IP地址”与用户历史IP地址不同，+15分。
如果行为要素中的“访问时间”在凌晨2点到5点之间，+25分。
如果用户在1小时内，发起了超过10次失败的登录尝试，+30分。

当总分超过60分时，触发“中等风险”响应（如二次认证）。当总分超过80分时，触发“高风险”响应（如直接阻断）。这种模型的好处是，规则透明，可解释性强，业务团队也能理解，方便后续调整。

3. 第三步：定义“自适应响应”策略

风险评分只是手段，最终的响应才是目的。响应策略必须与评分等级对应，并且是“可编程的”。我建议将响应分为三个等级：

风险等级	风险评分区间	响应动作	用户体验
低风险	0-30分	静默通行，记录日志用于持续优化模型	完全无感，后台自动完成
中等风险	31-70分	触发二次认证（如短信验证码、APP推送确认），或要求用户输入访问理由	轻微干扰，1-2次操作即可通行
高风险	71-100分	直接阻断访问，或创建“受限会话”，所有操作需逐条审批，同时向安全团队告警	明显干扰，需要人工介入处理

值得强调的是，“受限会话”是一个非常有用的折中方案。对于高风险但非明显恶意的操作（如一位员工在出差地首次登录），直接阻断可能影响业务，而“受限会话”允许其访问，但所有操作都会被监控和记录，甚至需要管理员逐条审批，这样既保证了安全，又兼顾了业务的连续性。

4. 第四步：建立“持续优化”的反馈闭环

这是最容易被人忽视的一步。模型不是一成不变的。你需要定期（如每周）复盘被阻断的请求、被误报的请求、以及用户反馈。你需要问自己：

哪些规则导致了大量的误报？是不是规则太敏感了？
哪些攻击被模型漏掉了？是不是数据采集维度不够？
用户的通行行为模式是否发生了变化？是否需要更新基线？

一个没有反馈闭环的“持续验证”系统，本质上是一个“静态”系统，会随着时间的推移而失效。我建议企业设立一个“安全数据分析师”的岗位，专门负责这个反馈闭环的运营。

五、具体案例与数据观察：从“人防”到“数防”的实战复盘

1. 案例一：一家电商公司的“数据定价”之战

我在2023年服务过一家中等规模的跨境电商公司。他们面临一个非常头疼的问题：公司内部的核心定价策略数据，经常被员工泄露到竞争对手那里。传统做法是“人防”：签保密协议、抓内鬼。但效果很差，因为数据泄露的渠道太多了（截图、邮件、U盘、云盘分享）。

我们帮他们做了一套“数据驱动的持续验证”方案，核心点在于：

数据采集： 我们不再只盯着“谁访问了定价表”，而是采集了所有访问定价表的行为，包括：查看时间、查看时长、是否复制粘贴、是否下载、是否截图、访问前的页面（上下文）、用户当前是否在开会等。
模型构建： 我们建立了一个“数据泄露风险评分”模型。例如，一个员工在正常工作时间，从自己的电脑上查看定价表，风险评分很低。但如果一个员工在深夜，从一台非公司设备，访问定价表，并同时进行了截图操作，风险评分会瞬间飙升。
自适应响应： 对于高风险评分，系统会自动触发动态水印（在屏幕上显示员工姓名和工号），并开启“只读-禁止复制”模式，同时向安全团队发送实时告警。

结果： 上线后三个月内，虽然没有抓到任何“内鬼”，但可疑的“数据访问”行为减少了80%，因为员工知道，每一次访问都在被动态评估，高风险行为会立即被发现并留下证据。公司再也没有发生过核心数据泄露事件。这个案例告诉我们，“持续验证”的核心价值，不在于“事后的惩治”，而在于“事前的威慑”和“事中的阻断”。

2. 案例二：一家金融公司的“API”安全进化

另一家金融客户，他们担心的是对外API接口的安全。传统做法是对所有API请求进行“认证和授权”，但无法应对“凭证泄露”和“API滥用”问题。例如，一个合法的API Token，被黑客用来自动化爬取客户数据，传统方案是防不住的。

我们引入了“行为分析”和“持续验证”。具体做法是：

数据采集： 除了API Token，我们还采集了每个API请求的IP地址、User-Agent、请求频率、请求数据量、请求的时间序列模式。
模型构建： 我们为每个合法的API客户端建立了一个“行为基线”。例如，某客户端的请求频率通常是100次/秒，请求数据量峰值是1MB。如果某天，该客户端的请求频率突然飙升到1000次/秒，或者请求数据量高达10MB，系统就会认为这是“异常”。
自适应响应： 对异常流量，系统会立即触发“限流”或“临时阻断”，并返回一个“CAPTCHA”验证，确认是真人操作还是自动化脚本。如果是脚本，直接阻断。

结果： 系统上线后，成功拦截了多次针对API的凭证泄露攻击和撞库攻击，误报率控制在3%以下。这个案例说明了，持续验证不仅能应用在“人”的访问，也能完美应用于“机器”的访问，是保护API安全的有效手段。

六、不同情况下的行动建议

在我接触的企业中，大家的情况千差万别。我无法给出一个放之四海而皆准的方案，但可以针对几种典型情况，给出具体的行动建议。你需要根据自己的实际情况，对号入座。

1. 情况一：你们公司是“零基础”的中小企业

行动建议： 不要试图一步到位。从“最小的闭环”开始。

第一步： 选择一个最核心、最敏感的业务系统（如财务系统、CRM系统），作为试点。
第二步： 在这个系统上，启用“多因素认证”和“IP白名单”。这是最基础的“持续验证”。
第三步： 引入一个简单的“用户行为分析”工具（市场上有很多SaaS产品，价格不贵）。开始采集用户的登录时间、登录地点、设备信息。
第四步： 基于这些数据，建立简单的“动态规则”。例如，当用户从“非白名单IP”和“非工作时间”访问时，自动触发二次认证。

取舍： 在这个阶段，为了安全，可以适当牺牲一些用户体验。但一定要做好“用户沟通”和“员工培训”，让员工理解为什么这么做，避免产生抵触情绪。你的核心目标是“跑通流程”，证明数据驱动的持续验证是可行的。

2. 情况二：你们公司已经部署了“传统零信任”产品，但效果不佳

行动建议： 不要轻易更换产品，而是“升级”你的数据分析能力。

第一步： 盘点你的零信任产品，它到底采集了哪些数据？它是否提供了“行为分析”和“动态评分”功能？大多数产品只提供了“日志”，没有“分析”。
第二步： 引入一个独立的“安全数据分析平台”（如SIEM或UEBA），将零信任产品的日志，以及其他安全设备（如防火墙、EDR）的日志，全部汇聚到这个平台上。
第三步： 在这个平台上，构建你的“动态风险评分”模型。不要依赖零信任产品自带的“评分模型”，因为那些模型通常是“黑盒”且不可调整的。
第四步： 将模型生成的“风险评分”，通过API，反馈给零信任产品，让零信任产品根据评分，执行不同的“响应策略”。

取舍： 这个方案的优点是，可以复用现有的IT投资，不需要推倒重来。但缺点是，需要你具备更强的数据工程和数据分析能力，或者需要外聘专家。你的核心目标是“盘活”已有的数据，让零信任产品从一个“穿戴设备”变成一个“战斗单位”。

3. 情况三：你们公司是大型企业，有多个数据孤岛和复杂的多云环境

行动建议： 这是一个高难度副本，需要“分步走”，切忌“大而全”。

第一步： 成立一个“零信任能力中心”，由安全、数据、业务部门的负责人共同组成。这个中心的职责是制定标准、协调资源、推动落地。
第二步： 选择一个“对业务影响最小”的场景作为起点，比如“内部员工的远程办公”场景。这个场景的数据相对集中，业务风险可控。
第三步： 构建一个“统一的数据湖”，将来自不同业务系统、不同云环境的用户身份、访问日志、行为数据，都汇聚到这个湖里。这是最耗时、最费力的环节，但也是最关键的。
第四步： 在数据湖之上，构建一个“实时风险引擎”，这个引擎应该具备“低延迟”和“高并发”能力，能够对每一次访问请求（毫秒级）进行风险评分。
第五步： 将风险引擎与所有的“零信任网关”和“应用代理”对接，实现“自适应访问控制”。

取舍： 在大型企业，你面临的最大挑战不是技术，而是“组织协作”和“数据治理”。数据孤岛的打破，需要高层推动和跨部门共识。你的核心目标是“先连起来，再优化”。不要追求完美的数据质量，先让数据能够流动起来，哪怕是“脏数据”，也比没有数据好。

七、总结与行动：别让“持续验证”成为下一个伪命题

回顾整个行业，零信任已经被炒作了多年，但真正做好的企业凤毛麟角。核心原因在于，大家把“持续验证”当成一个技术问题，而非一个“数据问题”。没有数据，所有“验证”都是盲人摸象；没有数据，所有“持续”都是自欺欺人。

我的核心观点是：“持续验证”的本质，是一场从“人防”到“数防”的认知革命。它不是要取代安全团队，而是要赋能安全团队，让他们从海量的、重复的告警中解脱出来，去关注那些真正有价值的、由数据驱动的安全事件。

我希望你在读完这篇文章后，能够立刻行动起来：

评估现状： 立即盘点你当前的安全系统，采集了哪些数据？哪些数据是“一次性”的，哪些是“持续”的？
选择试点： 不要贪多，从一个小而美的场景入手，比如“核心财务系统的访问控制”。
建立基线： 开始记录用户的行为数据，建立起用户的行为基线。这是你未来所有判断的基础。
设计规则： 基于你的业务场景，设计一套简单的、可解释的“动态风险评分”规则。
验证迭代： 观察规则的运行效果，收集用户反馈，不断地调整和优化你的模型。

记住，“持续验证”不是终点，而是一个持续优化的过程。它就像一场马拉松，而非百米冲刺。只有那些真正理解“数据”价值，并将其融入安全管理血液的企业，才能在这场博弈中占据主动，真正实现“分析有趣，决策有据”。

常见问题解答（FAQ）

1. 持续验证到底在验证什么？数据能告诉我谁该信任吗？

我是一家300人公司的安全负责人，正在推动零信任。但老板问我“持续验证具体验证什么？是不是每次都要输密码？”我答不上来。我知道不能只靠VPN，但数据驱动的持续验证到底怎么落地？谁来告诉我一个真实可操作的例子？

持续验证不是“多输几次密码”，而是基于数据实时计算每一次访问的风险分。我去年帮一家电商公司做零信任试点，踩过一个大坑：他们以为持续验证就是给所有员工装上MFA，结果运营每天被验证弹窗烦得要死，投诉说“比甲方还要甲方”。

真正的持续验证，核心是三个维度的数据： 1. 身份（账号、角色、权限） 2. 上下文（设备指纹、地理位置、时间、网络环境） 3. 行为（访问频率、操作模式、异常序列）我们当时用了简单的规则引擎： – 正常办公时间+公司内网+已知设备 → 风险分0，直接放行 – 凌晨3点+陌生设备+访问核心数据库 → 风险分85，触发二次验证+受限会话 – 海外IP+批量下载 → 风险分95，直接阻断并向SOC告警这套规则上线后，MFA触发率从100%降到12%，员工只需在“异常情况”时验证。

关键结论：数据不是为了“拒绝所有人”，而是为了“精准识别该信任谁”。持续验证的“持续”不是频率，而是动态调整信任等级的能力。

2. 数据分析如何帮零信任持续验证提效降本？每次都要实时分析，服务器受得了吗？

我负责公司安全架构，听说零信任需要实时分析所有流量，担心成本爆炸。尤其是中小企业，预算有限，能不能用数据驱动的方式既保证安全又不烧钱？有没有实践过的案例分享？

数据分析不是“全量实时分析”，而是分层过滤。我去年给一家零售企业做方案，他们每天产生500万条访问日志。如果全量实时计算，单是计算资源每月就要多花2万。

我们用了“冷热分层”策略： – 热数据（过去1小时，高价值资产）→ 实时流式计算（Flink），仅占10%的日志量 – 温数据（过去24小时，普通资产）→ 微批处理（Spark，每5分钟一次） – 冷数据（历史记录）→ 离线训练风险模型，不参与实时决策实际效果：计算成本降低65%，而95%的异常行为在热数据层就被捕获。

还有一个省钱技巧：用“基线+异常检测”代替“全量规则”。传统做法是写100条规则覆盖各种场景，但规则维护成本高。我们改用历史数据建立每个用户的“行为基线”（比如：小王通常周二下午访问财务系统，时长3-5分钟）。当实时数据偏离基线超过3个标准差，才触发验证。

这样只需要维护“如何定义基线”，而不是“每类异常如何写规则”。避坑提示：别一开始就追求机器学习。先跑半年规则，积累足够多的“正常-异常”标签数据，再上模型。否则模型会学出“周五下午四点半谁都不该访问”这种虚假规律。

3. 做零信任持续验证时，数据治理上有哪些常见坑？我该先清理脏数据再上系统吗？

我们公司已经上了零信任产品，但误报率高达40%，安全团队天天被开发骂。厂商说数据质量不行，但数据治理太庞大了，不可能等所有数据都干净了再上线。有没有折中的办法或者实战经验？

数据治理的坑我踩过三个，每一个都让我的误报率翻倍：第一个坑：身份数据“过期”。很多公司离职员工账号没及时冻结，系统持续验证时发现“离职员工凌晨登录”，触发告警。但其实是账号被新员工接手，IT没更新关联关系。

解决：先做“身份数据清洗边界”，只对“高活跃用户”和“高价值资产”做持续验证，低风险账号暂缓。我们当时只清洗了核心部门（财务、研发、运维）的300个账号，花了2周，误报率立刻从40%降到15%。第二个坑：日志数据“时区混乱”。

不同系统用的时区不一样，导致“行为时序”分析出错，系统认为用户在凌晨3点操作，但实际上是东八区下午3点。解决：统一时间戳为UTC，并在分析时按用户所在地转换。这个简单但极其容易被忽略。第三个坑：设备指纹“重复”。同一个员工换新电脑，设备指纹变了，系统判定为“新设备”，触发验证。

员工抱怨“我就换了个笔记本，至于吗？” 解决：建立“设备集群”概念，将同一员工的历史设备关联起来，当一个设备可信度超过90%，新设备自动继承部分信任度，降低验证频率。我的建议：不要等数据全部治理好再上线。

选一个“最小范围”（比如10个核心用户+3个关键系统），先跑通数据驱动持续验证的闭环，再逐步扩大。治理是动态的，持续验证本身就能帮你发现数据问题。

4. 中小企业没钱没专人，怎么用数据驱动零信任持续验证？有没有低成本方案？

我是一家100人电商公司的技术负责人，老板让我搞零信任，但预算只有5万，还没专职安全人员。市面上那些零信任厂商报价动辄几十万。我能不能只用开源工具和Excel实现数据驱动的持续验证？

完全可以，我帮一家50人设计公司用1500元/月的成本实现了基础持续验证。核心思路：把“持续验证”简化为“关注异常数据”，而不是追求全量实时。具体方案： 1. 数据采集：用开源OSSEC或Wazuh收集服务器、VPN的登录日志。成本0。2. 数据存储：用MySQL免费版，按天分表，保留最近30天。

成本0（用已有服务器）。3. 数据分析：写一个Python脚本，每天凌晨跑一次，计算“过去24小时每个用户的登录次数、设备数、IP归属地变化”。当某个用户出现“登录次数>5倍历史均值”或“设备数>3台”时，输出报警列表。4. 验证动作：报警发给老板微信，由老板手动确认是否需要临时禁用账号。

这套方案上线后，3个月内发现了2次账号被盗（一次是员工在公共WiFi下登录，一次是弱口令被爆破）。

进阶方案（预算5000元以内）： – 购买一台二手服务器（2000元），装Elasticsearch+Logstash+Kibana免费版 – 编写简单的“异常用户”看板，展示最近24小时高风险用户 – 风险分数计算：登录频率(30%)+设备变化(30%)+地理位置(20%)+时间异常(20%) – 当分数超过80，自动发送短信告警（用阿里云短信服务，每月几十元）避坑：不要一开始就做“用户行为画像”。

小公司员工数量少，画像不准确。直接用“统计阈值”更实用。例如：员工A过去30天平均每天登录2次，今天登录10次，直接告警。这个方案唯一需要投入的是：每周花1小时检查告警，以及每季度更新一次“正常行为基线”。