秒懂Springboot之如何使用logback做日志脱敏和截取

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

文章目录

前言
日志
- logback
- 原理
- 实现原理
- 方案
技术总结
总结
源码

前言

日志的重要性无需多言，而数据的安全性亦不用赘述，但不幸的是它两常常产生矛盾。要便利就会牺牲安全，要安全就会牺牲便利，所以需要找到一个折中的方案：既满足日志方便审计以及查找问题的需求又兼顾安全。这就是我们今天要谈论的日志脱敏的问题。

日志

现在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, PolicyEnum.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这种方案。

当敏感信息长度大于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...}

上文是我通过application.yaml读取了相应的值传到logback里的

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

技术总结

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

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

总结

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

源码

一如既往，你可以从个人博客首发获取源码