关于敏感数据脱敏的一个方案

没有看代码，你这个是日志脱敏吗？我们基本不脱敏日志，只脱业务数据（ java -> jackson 方式脱敏）

这种需要手动侵入式调用的，可能还不如遍历拿敏感字段，毕竟大多数开发不会 care 自己打印的日志到底有没有敏感信息

一般来说，已知敏感值位置，研发不应该打印敏感值，这种在 CR 阶段就要被打回去的

想脱敏就别胡弄。要不然就别脱。

看了下你的方案，思路是好的，但有个根本矛盾：既然代码里都能明确标出哪块是敏感数据了，那最佳实践本来就不该记日志，CR 阶段就该拦截掉。这也是楼上几位意思——业务数据脱敏比日志脱敏更常用也更可控。

而且这种侵入式的改写太依赖开发者自觉，多数人写日志时根本不会想那么多，落地会很痛苦。如果真想抽一个日志脱敏的基础能力，不如学学 Jackson 方式搞个注解统一拦截，或者像最后那位老哥说的，做得彻底一点，别夹生。

我们以前数据包案例都要脱敏 忘记咋做的了

@ezwangsong 这个方案的好处是 在最源头标记一次敏感数据,后续再调用其他 mq,dubbo,线程池的时候会传递 traceid,将后续整个调用链路的地方都实现日志脱敏
相当于在一些出现敏感数据的源头做一次标记,后面就不用管了

@nealHuang 手动调用和遍历敏感数据是一样的吧,可以是注解或者是支持配置字段的方式自动遍历

@BreadPrince 如果等级严格的话那可能确实不合适
如果业务一定会有敏感数据又要求日志不出现敏感数据,但是没有非常严格的要求的话,我这种我觉得是在业务影响和代码改动都比较小的情况下的一种可以考虑的实现方案.

@meshell 其实还有一套配合的数据库脱敏加密方案配套用
我感觉我一开始没有说清楚,这个方案我觉得有趣的地方是将脱敏实现以 TraceID 的方式传递了下去,可以在当前整个调用链路去自动脱敏

@kneo 确实没有那么严谨,会有遗漏的风险