技术方案讨论，移除实时日志中的敏感数据

[beryl]

最近遇到一个需求，看起来不复杂，但是也研究了一两天，感觉还是挺有意思的，拿出来一起讨论下

需求：准实时移除实时日志中的敏感数据

几个要求：
1. 每 5 分钟将线上日志中的敏感数据脱敏，例如手机号替换成 *
2. 不改现有的代码逻辑
3. 尽可能的轻量化方案，因此限定系统自带脚本(shell 、perl 、python)
4. 日志文件较大 最大 3G, 每天归档，处理过程不能占用过多机器资源
5. 允许丢掉小批量日志, 尽可能少
6. 系统晚上九点之后，不会有用户使用

中间断断续续研究了四五种方案，结合 chatGPT 写的代码。 最终准备采取的方案：

1. 使用 perl 脚本
2. 每五分钟剪切日志文件的前 20M ，到新文件。 循环切分，数据量不会太大，切分过程丢数据少
3. 用 perl 处理新文件，20M 处理起来还是比较快。过程丢数据少
4. 晚上十一点把今天的日志再进行合并成一个

一起讨论下还有哪些更加优雅方案

再描述下重点前提约束，这个约束是业务和环境导致的，相当于命题作文：

不改动生成日志的服务的代码，或者配置
相当于旁路方式

再补充：
手机号格式或者需要脱敏的东西，不考虑细节，简单说就是 11 位数字。

技术问题，从技术角度沟通。

各位请当做一个纯技术爱好者去讨论和沟通

[whoosy]

最大才 3G ，rsyslog 完全就能处理

[luckyrayyy]

你咋知道是手机号，如果别的 ID 正好跟手机号长得差不多呢。切文件为啥还会丢日志？

[liuzhaowei55]

如果是做等保，这个方案怕是不太行，因为数据已经落地了
考虑下根据日志识别出来敏感数据，然后进行告警，从源头上修改

[povsister]

老生常谈的问题了，没什么太多讨论的。
google：hidding sensitive data in log

我认为下策：在采集时直接替换
因为究其原因，它属于 sensitive 的原因是，有人的权限不够看而已。你直接采集时干掉就会影响后续一整条路的分析。而且分布式的采集，你更新屏蔽规则又要搓轮子。

举个例子：
我是做账号系统认证的，所有业务都集成我的认证中间件，这个中间件产生的 log 里含有用户 token ，业务研发看到之后可以拿用户的 token 去伪装用户身份。所以 token 不能给业务研发看。
但我是做账号系统的，这个 token 对我是有 debug 价值的（通过私钥解开后，可以看签发时间，是向哪个端签发的，对抗黑产很有用）

中策：采集后在日志网关统一替换
优点：规则集中管理
缺点：同上，没有原始数据。而且集中式处理在海量日志时 cpu 成本太高。依旧存在日志敏感内容泄露问题。

上策：zero trust 生产网络，禁止研发直连，日志原样采集存储，提供 clickhouse/es 平台的查询前端，前端展示时依据用户权限系统在查询网关吐出时做敏感信息遮盖。有查看需求的走审批流程。
优点：懒得分析了
缺点：没一个团队这个方案你怕是不好做

总之，这只是个道高一尺魔高一丈的对抗过程。服务都在研发手里，想要什么信息不是随便拿捏。
你需要做的是好好想想自己的威胁模型，你要控制/缩小哪些攻击面，可能遭遇什么类型的攻击。

通常来说，我遇到的提这个要求的，一般都是合规，不合规 toB 不好卖啊。

[aw2350]

1 、日志内容特征？诸如有一定的模板格式
2 、PY 包处理大文本的多了去了，只有日志模板能确定，直接正则解析开整

[xueling]

对于这种处理方式，并不是特别认同，此类问题更应该从源头进行修正，而不是采取这种“补救”措施。

[matrix1010]

@povsister 我认为在源头处理才是上策，保护用户敏感数据是企业/开发者的责任。Google 和 AWS 都有专门的服务，比如 Google 这个 https://cloud.google.com/application-integration/docs/mask-sensitive-data-logs 。开头就很明确说了为什么要这么做

Masking sensitive data in logs provides the following benefits:

Improve customer security and privacy
Comply with data privacy regulations

敏感信息处理的重点不在程序员好不好开发，而是合规并且尽可能防止数据泄漏造成的风险。

[povsister]

@matrix1010
进一步倒推，最源头的方式：你不要把敏感信息打到日志里，为此你要重新审计每一行代码并提交证明
再进一步，所有敏感信息操作都必须 trust computing ，不允许在内存里直接存放敏感数据

现实总是妥协的，我不反对关键的敏感信息在源头处理，但敏感信息是分级的，大多数业务并接触不到也不需要接触非常机密的信息，那何必因噎废食呢。
This is an eternal chasing game of cat and mouse.

[matrix1010]

@povsister 钻牛角尖就没意思了。讨论这个问题时不应该考虑程序/代码/架构。原则就是能做到尽量做到，或者 GDPR 之类的强制你做到。做不到用户的信息就存在泄漏风险。你的系统必须要在 log 里记录真实手机/邮箱才能防止灰产，那是公司内部问题，用户不应该为此承担风险。

[zmxnv123]

让我想起了当时备考 AWS 的日子，里面有个服务专门就是做这个，但我已经一点都想不起来名字了。

[yigecook]

3g 的话，用 python 操作流式处理，也不用每五分钟处理，设置 chunk 为 200M ，就好。

```python
import re

# 定义敏感数据的正则表达式模式
sensitive_data_pattern = re.compile(r'\b\d{16}\b')

def process_chunk(chunk):
# 使用正则表达式替换敏感数据
return sensitive_data_pattern.sub('****', chunk)

def process_log_file(input_file_path, output_file_path, chunk_size=200*1024*1024):
with open(input_file_path, 'rb') as input_file, open(output_file_path, 'wb') as output_file:
while True:
chunk = input_file.read(chunk_size)
if not chunk:
break
# 将字节数据转换为字符串进行处理
chunk_str = chunk.decode('utf-8', errors='ignore')
processed_chunk_str = process_chunk(chunk_str)
# 将处理后的字符串转换回字节数据
processed_chunk = processed_chunk_str.encode('utf-8')
output_file.write(processed_chunk)

# 使用示例
input_file_path = 'path/to/your/large_log_file.log'
output_file_path = 'path/to/your/processed_log_file.log'

process_log_file(input_file_path, output_file_path)
```

以上脚本的工作流程如下：

定义敏感数据的正则表达式模式，用于匹配和替换敏感数据。
process_chunk 函数会对读取的块进行处理，移除敏感数据。
process_log_file 函数会逐块读取输入日志文件，每次读取 200M 的数据，处理后写入到输出文件。
通过这种方式，处理过程不会占用超过 200M 的内存，同时也能够有效地移除日志中的敏感数据。请根据您的具体需求调整正则表达式模式和其他处理逻辑。

[caryqy]

sed 正则匹配手机号/11 位数字 原地替换为指定内容。内存不够就按行匹配

[Yuan2One]

2B 应该都是有自己的日志 SDK 的，直接通过配置脱敏，也比较灵活

[jones2000]

直接改原始文件，找到要修改的文件地址，通过 WriteFile ， 把这段需要脱敏的数据覆盖掉，这样就不会修改原始文件大小，日志写入和脱敏可以同时运行