https://github.com/lalala8462/log-redact
想问下这个方案有没有什么价值:
在一些可以明确捕获到敏感数据的地方将其格式化(不会保存敏感数据的原文),然后通过重写日志输出的函数,将本来是敏感的数据替换成脱敏/加密的数据.
想问下这个方案有没有什么价值:
在一些可以明确捕获到敏感数据的地方将其格式化(不会保存敏感数据的原文),然后通过重写日志输出的函数,将本来是敏感的数据替换成脱敏/加密的数据.
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Supplement 1 · 4h 49m ago
目前这个脱敏方案的设计考虑是在敏感数据的源头进行标注,然后通过 ThreadLocal+TradeID 传递给后续线程/Dubbo 服务/MQ,实现整个调用链路下的日志脱敏
这样大部分情况下就不用关系日志是否需要脱敏打印
这样大部分情况下就不用关系日志是否需要脱敏打印
 |
1
meshell 16h 0m ago
没有看代码，你这个是日志脱敏吗？我们基本不脱敏日志，只脱业务数据（ java -> jackson 方式脱敏）
|
 |
2
nealHuang 15h 50m ago
这种需要手动侵入式调用的，可能还不如遍历拿敏感字段，毕竟大多数开发不会 care 自己打印的日志到底有没有敏感信息
|
 |
3
BreadPrince 15h 6m ago
一般来说，已知敏感值位置，研发不应该打印敏感值，这种在 CR 阶段就要被打回去的
|
 |
4
kneo 14h 2m ago via Android
想脱敏就别胡弄。要不然就别脱。
|
 |
5
ezwangsong 13h 53m ago  2
看了下你的方案，思路是好的，但有个根本矛盾：既然代码里都能明确标出哪块是敏感数据了，那最佳实践本来就不该记日志，CR 阶段就该拦截掉。这也是楼上几位意思——业务数据脱敏比日志脱敏更常用也更可控。
而且这种侵入式的改写太依赖开发者自觉，多数人写日志时根本不会想那么多，落地会很痛苦。如果真想抽一个日志脱敏的基础能力，不如学学 Jackson 方式搞个注解统一拦截，或者像最后那位老哥说的，做得彻底一点，别夹生。 |
 |
6
Daybyedream 13h 43m ago
我们以前数据包案例都要脱敏 忘记咋做的了
|
 |
7
wish198 OP @ezwangsong 这个方案的好处是 在最源头标记一次敏感数据,后续再调用其他 mq,dubbo,线程池的时候会传递 traceid,将后续整个调用链路的地方都实现日志脱敏
相当于在一些出现敏感数据的源头做一次标记,后面就不用管了 |
|
9
wish198 OP @BreadPrince 如果等级严格的话那可能确实不合适
如果业务一定会有敏感数据又要求日志不出现敏感数据,但是没有非常严格的要求的话,我这种我觉得是在业务影响和代码改动都比较小的情况下的一种可以考虑的实现方案. |
|
10
wish198 OP @meshell 其实还有一套配合的数据库脱敏加密方案配套用
我感觉我一开始没有说清楚,这个方案我觉得有趣的地方是将脱敏实现以 TraceID 的方式传递了下去,可以在当前整个调用链路去自动脱敏 |
Select Language