[版权申明] 非商业目的注明出处可自由转载出自：shusheng007

前言

日志的重要性无需多言，而数据的安全性亦不用赘述，但不幸的是二者常常以相生相克的姿势出现在程序员面前。要便利就会牺牲安全，要安全就会牺牲便利，所以需要找到一个折中的方案：既满足日志方便审计以及查找问题的需求又兼顾安全。这就是我们今天要谈论的日志脱敏的话题。

日志

现在java生态最常使用的几个用来记录日志的技术有：log4j，logback，log4j2 , tinyLog，不过现在我们一般会通过SLF4J来集成日志。SLF4J的意思是Simple Logging Facade for Java，可见其是一个面板，一个日志的抽象层。我们通过SLF4J接入日志后，以后想要更换其他的实现了SLF4J的日志库就比较方便了，无需改动代码。

如下图所示：

图片出至 logback官方文档

logback

2001年瑞士程序员Ceki Gülcü创建了Log4j，多年后的一天早上起来他决定不玩了，于是 2015又发起了SLF4J和Logback新项目，目标是成为前辈log4j的继任者。但是对于大型互联网系统，选择Log4J2的比较多，因为其性能更加优秀，据说每秒可以写入1千8百万条日志，而logback最多每秒写入200万条日志，其还有非常强大的插件系统。可能就是因为复杂而强大，2021年阿里云发现了零日漏洞，被称为近10年最严重的软件漏洞...。阿里第一时间向Apache基金会报告了此漏洞，却没有向中国信息相关部门报告，最后收获处罚也在情理之中了。

闲话聊的差不多了，该入正题了。现在由于Springboot 默认集成logback，所以logback越来越流行，所以今天就聊一下如何使用logback进行日志的脱敏和截取。

Logback 被分成三个不同的模块：logback-core，logback-classic，logback-access。我们一般会使用logback-core和logback-classic，logback-access 用来与 Servlet 容器（Tomcat、Jetty）进行整合提供http访问日志的功能。

原理

logback的学习曲线还是比较陡峭的，我第一次接触的时候就被那个配置搞的相当懵逼，相信工作了几年的同学如果没有专门研究过还是感觉无从下手。由于我们这篇文章主要着眼于脱敏和截取，而不是如何使用logback，所以对其如何使用不会说的太详细，有相关需求的可以看官方文档。如果需求特别强烈可以抽时间在写一篇相关文章。

logback里面有几个非常关键的概念：

Logger
日志对象的抽象，负责日志等级，Mark的设置等
Appender
负责将日志输出到不同的目的地，控制台、文件、数据库、网络...
Encoder
顾名思义，它是编码用的。那编什么码呢？Encoder将日志事件转换为字节数组，同时将字节数组写入到一个 OutputStream 中。
Layouts
负责将日志事件转化为格式化的字符串

当输出一个日志LogEvent时，其处理流程如下：

Appender ->Encoder->Layout-> Converter

如下图所示。

日志最后都会经过各种Converter，所以我们可以在这一步来做文章。

实现原理

在SpringBoot中使用logback的时候，通常会在resource文件下创建一个名为logback-spring.xml的文件。logback配置文件本来的命名为logback.xml，当加上spring后缀后就可以在logback配置文件中使用spring相关的配置了，这块一会再说。

这里我们做一个最低配置。一个 ConsoleAppender，一个PatternLayoutEncoder，一个PatternLayout。如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{40} - %msg%n</pattern>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
    </root>

</configuration>

我们的日志内容的转换是由PatternLayout里的%msg负责的，它其实是配置了一个MessageConverter ，源码非常简单，如下所示。

public class MessageConverter extends ClassicConverter {
    public String convert(ILoggingEvent event) {
        return event.getFormattedMessage();
    }
}

可见MessageConverter 没有做任何日志的转化，将获取到的格式化日志直接返回了。要想对输出的日志做一些脱敏等工作我们就需要实现自己的MessageConverter 。

方案

我们准备实现如下功能

消息超长截取。例如设置最大长度为1024个字符，超过则截取并在末尾加上一个截断符<<<。
敏感信息处理。例如我们可以将敏感信息使用*替换。
匹配深度。其为提升性能而设计，一般用不上。例如手机号是敏感信息，很不辛一段日志里面包含了1000个手机号，如果深度设置为200，200以后的手机号就不再按敏感信息处理了。

具体实现

继承ClassicConverter，重写其start() 方法。从前文介绍可知这个类也是MessageConverter的基类。

 @Override
 public void start() {
     List<String> options = getOptionList();
     //从参数选项中提取配置
     if (options != null) {
         try {
             final Integer targetMaxLength = Integer.valueOf(options.get(0));
             ...
         } catch (Exception e) {
             e.printStackTrace();
         }
     }
 }

在此方法内，我们可以通过父类DynamicConverter的getOptionList()获取从外界传入的参数。这些参数包括：最大长度、匹配敏感信息的正则表达式、敏感信息的处理方式...

重写DynamicConverter的convert(ILoggingEvent event)方法

 @Override
 public String convert(ILoggingEvent event) {
     String source = event.getFormattedMessage();
     ...

     int length = source.length();
     boolean isOutLengthLimit = length > maxLength;
     if (isOutLengthLimit || replaceMatcher != null) {
         StringBuilder sb = new StringBuilder(isOutLengthLimit ? maxLength + 6 : length + 6);
         //超长截取
         if (isOutLengthLimit) {
             sb.append(source, 0, maxLength)
                     .append("<<<");
         } else {
             sb.append(source);
         }
         if (replaceMatcher != null) {
             return replaceMatcher.execute(sb, HandlePolicy.fromName(policy));
         }
         return sb.toString();
     }
     return source;
 }

当获取到日志消息后，对其长度进行判断，超长则截取。然后构建一个ReplaceMatcher进行正则匹配，脱敏。

创建一个静态内部类ReplaceMatcher ，这个类是真正干活的类

    public static class ReplaceMatcher {
        private final Pattern pattern;
        private final int depth;
        ...

        public String execute(StringBuilder source, PolicyEnum policy) {
            Matcher matcher = pattern.matcher(source.toString());

            int depthCounter = 0;
            while (matcher.find() && (depthCounter < depth)) {
                depthCounter++;
                int start = matcher.start();
                int end = matcher.end();
                if (start < 0 || end < 0) {
                    break;
                }
                //匹配到的数据
                source.replace(start, end, facade(matcher.group(), policy));
            }
            return source.toString();
        }

        private String facade(String source, PolicyEnum policy) {
            final int length = source.length();
            StringBuilder sb = new StringBuilder(source);

            if (policy == REPLACE) {
                if (length > 128) {
                    return sb.replace(3, length - 3, String.format("[%s]", length - 6)).toString();
                }
                if (length > 10) {
                    return sb.replace(3, length - 3, repeat('*', length - 6)).toString();
                }
            }
            ...
            return sb.replace(0, length, repeat('*', length)).toString();
        }
    }

其逻辑也很简单：使用正则表达式去匹配，如果匹配到了就处理。处理的方式可以自定义，文中展示了REPLACE这种方案，也可以DROP。

当敏感信息长度大于128个字符时，保留前后3个字符，中间字符使用[省略的长度]来代替。例如字符串： abc这里省略了200个敏感字符cba 会被替换为abc[200]cba。
当长度大于10小于128时，保留前后各三个字符，中间用*替换。例如： 13512341234替换为：135*****234
当小于10，则全部替换为*。例如password替换为********

如何使用

当完成以上步骤后我们的DesensitizedMessageConverter 就大功告成了，接下来就是怎么让它生效的问题了。

再来看一眼我们的logback的配置文件，其中%msg是在配置其原生的MessageConverter，我们的目标是要用我们自己的DesensitizedMessageConverter来替换掉MessageConverter ，那怎么弄呢？

...
   <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{40} - %msg%n</pattern>
...

logback提供了一个叫<coconversionRule>的标签，通过这个标签我们可以使用自定义的Converter了

<configuration>

    <springProperty scope="context" name="LOG_CON_MAX_LIMIT" source="cus-log.properties.max-limit"/>
    <springProperty scope="context" name="LOG_CON_POLICY" source="cus-log.properties.policy"/>
    <springProperty scope="context" name="LOG_CON_REGEX" source="cus-log.properties.regex"/>
    <property name="LOG_CON_DEPTH" value="100"/>

    <property name="LOG_CON_SUM" value="'${LOG_CON_MAX_LIMIT}','${LOG_CON_REGEX}','${LOG_CON_POLICY}','${LOG_CON_DEPTH}'"/>

    <conversionRule conversionWord="dmsg" converterClass="top.ss007.log.cuslog.DesensitizedMessageConverter"/>

        ...
           <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{40} - %dmsg{${LOG_CON_SUM}}%n</pattern>
        ...    

</configuration>

首先我们定义DesensitizedMessageConverter的conversionWord为dmsg，名称随便叫，只要不和logback自己已经使用的重复了就行。然后我们就可以使用dmsg来替换msg了。正常情况下已经OK了，但是我们的Conveter需要传入参数：最大截取长度，正则表达式等，这怎么办呢？

如下所示，只要在dmsg后面使用{}依次传入即可，顺序以及数目要与我们在DesensitizedMessageConverter解析一一对应的，不能瞎传。

%dmsg{p1,p2,p3...}

由于我们使用了logback-spring.xml 作为logback的配置文件名，所以我就可以在其内部使用application.yaml的配置了

cus-log:
  properties:
    max-limit: 1024
    policy: REPLACE
    regex: (?<="password":").*?(?=") #匹配  {"password":"123456"} 中的123456

技术总结

这一套方案看起来不难，但其实要求对Logback有比较全面的认识了理解才能做到，下面我总结几个关键点：

清楚logback的日志处理流程，确定要对MessageConverter 下手
清楚如何给Converter传参和如何解析参数
清楚如何应用自定义的Converter
会写各种正则表达式

总结

总体来说logback的学习曲线还是比较陡峭的，由于很多同学参与项目时，日志已经被前辈配置好了，平时也不会去改动它，导致很多人工作了多年对其都不是很了解。不过不了解也不要紧，日志虽然非常非常非常重要，但其具有一旦设定就几乎不变的特性，所以放轻松看待即可。但是，技多不压身...

源码

一如既往，你可以从Github上获取 本文源码，点亮小星星是一个IT人的优秀品质

Menu

Share

秒懂SpringBoot之如何使用logback实现日志的脱敏和截取

前言

日志

logback

原理

实现原理

方案

具体实现

技术总结

总结

源码

Comment

永不磨灭的设计模式

秒懂SpringBoot之全网最易懂的Spring Security教程

秒懂设计模式之工厂方法模式（Factory Method Pattern）

面向对象设计之魂(六大原则)

秒懂设计模式之抽象工厂模式（Abstract Factory Pattern）

秒懂设计模式之桥接模式（Bridge Pattern）

秒懂设计模式之装饰者模式（Decorator Pattern）

秒懂设计模式之建造者模式（Builder pattern）

秒懂设计模式之组合模式（Composite Pattern）

秒懂设计模式之适配器模式（Adapter Pattern）