第16章：深蓝的涟漪
第16章：深蓝的涟漪 (第2/2页)现有文档描述，payload字段解密后应该是标准JSON格式，包含固定的几个嵌套字段。但路容知道，在实际传输过程中，可能因为加密算法、网络编码、第三方接口等各种原因，产生一些非标准但依然可解析的变体。
比如，JSON字符串的开头或结尾多了一个空格。
比如，某个字段的值是空数组[]，但被编码成了空字符串““。
比如，时间戳字段的值是整数，但被错误地传成了字符串。
这些变体，在严格的JSON解析器里会报错，但在一些宽松的解析器里可以正常处理。
路容设计的规则是：只要payload解密后不能通过严格JSON解析验证，就标记为“格式异常”，暂时搁置，触发人工审核。
这听起来很合理。
但她在规则里加了一个细节：对于AES-256-GCM加密的数据包，解密过程会生成一个“认证标签”，用于验证数据完整性。如果认证标签验证失败，解密工具会直接报错，不会输出任何内容。
而她的规则，在处理“认证标签验证失败”的情况时，设计了一个特殊的逻辑分支。
这个分支会检查数据包的元数据——device_id、timestamp、来源IP——然后与最近一小时内的其他数据包进行模糊匹配。如果找到相似的数据包，就假设这个解密失败的数据包是重复发送的版本，直接丢弃，不触发告警。
但如果找不到相似数据包呢？
规则会将其标记为“加密负载格式错误”，进入异常队列。
然后——关键在这里——路容在代码里设置了一个阈值：同一来源IP在五分钟内，如果出现超过三个“加密负载格式错误”的数据包，就触发系统级告警。
为什么？
因为正常的数据传输，不会在短时间内产生大量解密失败的数据包。如果出现，要么是源头数据有问题，要么是加密密钥错误，要么是——有人故意发送了无法解密的测试数据。
而“深蓝计划”的数据来源，周哲说涉密。
路容不知道具体是什么来源。
但她知道，李剑三年前构陷她时，用的就是伪造的数据包，伪装成她从公司服务器泄露出去的加密文件。那些文件，表面上是AES加密，实际上内部结构被篡改过，解密后会得到错误的内容。
当时的加密方式，也是AES-256。
当时的错误模式，也是认证标签验证失败。
当时的处理逻辑——天启科技的安全团队写的——也是将这类数据包标记为异常，触发告警。
然后告警记录，成了“证据”的一部分。
路容的手指停在键盘上。
屏幕上的代码已经写了三百多行。她从头到尾检查一遍，确认逻辑正确，确认漏洞隐蔽，确认这个规则在技术评审时能通过——因为它确实能有效过滤重复数据，也确实能检测格式异常。
只是，它会对某种特定的错误模式，产生“过度敏感”的反应。
而这种错误模式，与三年前她见过的，太像了。
下午两点，权限批下来了。
路容登录密钥管理平台，看到状态变成“已授权”。她下载了解密密钥，导入工具，重新尝试打开那个加密文件。
进度条缓慢移动。
百分之十，百分之三十，百分之七十。
解密完成。
文件展开，里面是数万行JSON格式的数据。路容快速浏览，确认文档描述的结构准确：timestamp是13位毫秒时间戳，device_id是32位哈希字符串，event_type包括“page_view”、“button_click”、“scroll”等，payload字段是加密内容。
她随机选择几条数据，用密钥解密payload。
解密后的内容显示出来：用户访问了某个电商网站的商品页面，点击了“加入购物车”按钮，页面停留时间47秒，滚动深度65%……
很标准的用户行为数据。
路容连续解密了十几条，内容都正常。
她关掉文件，打开另一个。
同样正常。
第三个，正常。
第四个——
路容的目光停住了。
这条数据的device_id，她见过。
就在刚才解密的第一个文件里，有相同的device_id，但timestamp相差三分钟。她翻回去对比，两个数据包的device_id完全一致，event_type都是“page_view”，但payload解密后的内容……
第一个：用户访问了网站A的首页。
第四个：用户访问了网站B的商品页。
同一个设备，三分钟内，访问了两个不同的网站。
这本身不奇怪，用户可能切换应用。
但路容注意到一个细节：两个数据包的来源IP不同。
第一个来源IP：203.112.89.76（深港市电信）
第四个来源IP：103.215.44.128（境外，新加坡）
同一个设备，三分钟内，IP地址从深港市跳到了新加坡。
不可能。
除非……
路容盯着屏幕，心跳微微加速。
除非这个device_id不是真实的设备标识，而是经过某种映射或伪造的ID。或者，数据来源本身就有问题——可能混合了多个渠道的数据，没有做好去重和归一化。
又或者，这些数据根本不是实时采集的，而是从某个数据仓库里批量导出，重新打包加密后，伪装成实时数据流。
她继续查看。
又发现了几个类似的案例：相同的device_id出现在不同的来源IP，时间间隔很短，访问行为不连贯。
还有一批数据，timestamp的时间顺序是乱的——晚发生的事件，时间戳反而比早发生的事件更早。
以及一些payload解密后，JSON结构虽然正确，但某些字段的值明显异常：页面停留时间999999秒，滚动深度-1，按钮点击坐标(9999,9999)……
路容把这些异常案例记录下来。
然后，她开始修改过滤规则代码。
针对device_id异常跳变的情况，她加入了一个检查：如果同一个device_id在十分钟内出现在地理距离不可能达到的IP地址（比如深港市和新加坡），就将这两个数据包都标记为“设备标识可疑”，进入人工审核队列。
针对timestamp乱序的情况，她加入时间戳合理性校验：如果数据包的时间戳比系统当前时间还晚，或者比同来源的前一个数据包早太多，就标记为“时间戳异常”。
针对字段值异常的情况，她加入数值范围检查。
每一条规则，都有合理的技术理由。
每一条规则，也都可能误伤正常数据。
但路容把误判的概率，控制在了一个“可接受”的范围——根据她写的测试用例，误判率大约在0.3%到0.5%之间。对于TB级别的数据流，这意味着每天会有数万个数据包被错误地标记为异常。
而系统告警的阈值，她设置为：同一数据源，异常率超过1%，持续五分钟，触发告警。
如果她的规则误判率是0.5%，正常数据流的异常率可能只有0.1%或更低，那么整体异常率不会超过0.6%，达不到告警阈值。
除非——
数据源本身的异常率就很高。
或者，有人故意往数据流里注入异常数据包。
路容写完最后一段代码，保存。
时间已经是下午六点。
窗外天色渐暗，城市的灯光再次亮起。她站起来，活动了一下僵硬的肩膀。颈椎发出轻微的咔哒声。她走到窗边，拉开窗帘。
深港市的夜晚，繁华而冷漠。
远处星耀集团的写字楼，依然灯火通明。不知道周哲还在不在办公室，不知道李剑此刻在做什么，不知道那些加密数据包，此刻正从世界的哪个角落，流向星耀的服务器。
路容回到书桌前，将代码提交到测试环境。
系统提示：代码审核中，预计两小时内完成。
她关掉电脑。
煮了碗泡面，加了鸡蛋和几片青菜。面条在沸水里翻滚，热气蒸腾，带着浓郁的调味料气味。她端着碗坐在床边，慢慢吃。
手机安静地躺在桌上。
晚上八点，代码审核通过。
测试环境开始部署新的过滤规则。路容重新打开电脑，登录监控面板。数据流曲线平稳，清洗流程各环节正常。她的规则模块显示“运行中”，处理计数开始累积。
晚上十点，处理数据量超过500GB。
异常标记数量：1274个。
异常率：0.25%。
低于告警阈值。
路容泡了第二杯茶，坐在电脑前等待。茶香在房间里弥漫，混合着泡面残留的气味。她戴上耳机，播放轻音乐，音量调得很低。
时间一分一秒过去。
晚上十一点。
异常率：0.31%。
晚上十一点半。
异常率：0.29%。
午夜十二点。
数据流进入低谷期，流入速度减缓。异常率波动，最高到0.35%，最低到0.22%。
路容的眼睛开始发涩。
她摘下眼镜，揉了揉眉心。然后重新戴上眼镜，盯着屏幕。
凌晨一点。
数据流突然出现一个小高峰——监控面板显示，有新的数据源接入，流量在五分钟内增加了30%。路容坐直身体，手指放在触摸板上，放大那个时间段的统计图。
新数据源的IP段：198.51.100.0/24。
地理位置：显示为“未知”。
异常率，开始上升。
0.41%。
0.53%。
0.67%。
路容屏住呼吸。
屏幕上的数字跳动。
0.72%。
0.85%。
0.91%。
然后——
1.02%。
红色警示标志，在监控面板上亮起。
系统告警触发。
几乎同时，路容的手机震动起来。
她拿起手机，屏幕上显示来电：周哲。
路容盯着那个名字，看了三秒钟。然后她深吸一口气，按下接听键，同时打开变声器。
“喂？”
“若溪，抱歉这么晚打扰。”周哲的声音从听筒里传来，背景里有键盘敲击声和轻微的警报声，“测试环境出问题了，你设计的过滤规则，标记了一大批‘深蓝’外围数据为异常，现在数据流堵塞，清洗流程停滞。我需要你立刻远程登录，一起排查。”
路容的声音平静：“异常率多少？”
“刚才峰值1.02%，现在降到0.98%，但还是高于阈值。”周哲说，“数据源是198.51.100开头的那个段，今晚刚接入的新渠道。你方便现在上线吗？”
“方便，给我五分钟。”
“好，我发你紧急访问链接。”
电话挂断。
路容放下手机，看向电脑屏幕。
红色警示标志依然亮着。
监控面板上，异常数据包的数量还在缓慢增加。
她端起已经凉透的茶，喝了一口。
茶很苦。
但她的嘴角，微微扬起。
鱼饵，已经放下。