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

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

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

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

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

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

一起讨论下还有哪些更加优雅方案
2313 次点击
所在节点    程序员
14 条回复
whoosy
76 天前
最大才 3G ,rsyslog 完全就能处理
luckyrayyy
76 天前
你咋知道是手机号,如果别的 ID 正好跟手机号长得差不多呢。切文件为啥还会丢日志?
liuzhaowei55
76 天前
如果是做等保,这个方案怕是不太行,因为数据已经落地了
考虑下根据日志识别出来敏感数据,然后进行告警,从源头上修改
povsister
76 天前
老生常谈的问题了,没什么太多讨论的。
google:hidding sensitive data in log

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

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

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

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

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

通常来说,我遇到的提这个要求的,一般都是合规,不合规 toB 不好卖啊。
aw2350
76 天前
1 、日志内容特征?诸如有一定的模板格式
2 、PY 包处理大文本的多了去了,只有日志模板能确定,直接正则解析开整
xueling
76 天前
对于这种处理方式,并不是特别认同,此类问题更应该从源头进行修正,而不是采取这种“补救”措施。
matrix1010
76 天前
@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
76 天前
@matrix1010
进一步倒推,最源头的方式:你不要把敏感信息打到日志里,为此你要重新审计每一行代码并提交证明
再进一步,所有敏感信息操作都必须 trust computing ,不允许在内存里直接存放敏感数据

现实总是妥协的,我不反对关键的敏感信息在源头处理,但敏感信息是分级的,大多数业务并接触不到也不需要接触非常机密的信息,那何必因噎废食呢。
This is an eternal chasing game of cat and mouse.
matrix1010
76 天前
@povsister 钻牛角尖就没意思了。讨论这个问题时不应该考虑程序/代码/架构。原则就是能做到尽量做到,或者 GDPR 之类的强制你做到。做不到用户的信息就存在泄漏风险。你的系统必须要在 log 里记录真实手机/邮箱才能防止灰产,那是公司内部问题,用户不应该为此承担风险。
zmxnv123
76 天前
让我想起了当时备考 AWS 的日子,里面有个服务专门就是做这个,但我已经一点都想不起来名字了。
yigecook
76 天前
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
76 天前
sed 正则匹配手机号/11 位数字 原地替换为指定内容。内存不够就按行匹配
Yuan2One
76 天前
2B 应该都是有自己的日志 SDK 的,直接通过配置脱敏,也比较灵活
jones2000
75 天前
直接改原始文件,找到要修改的文件地址,通过 WriteFile , 把这段需要脱敏的数据覆盖掉,这样就不会修改原始文件大小,日志写入和脱敏可以同时运行

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1055173

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX