1 背景

近年來，國家采取了多項重要舉措來加強個人數據保護，包括實施《中華人民共和國網絡安全法》和《個人信息保護法》等法律法規。這些舉措旨在確保用戶隱私的安全，同時確保企業合規運營。在處理敏感數據時，企業有責任采取適當的措施來保護用戶信息。

在數據保護方面，日志記錄成為一個需要特別關注的敏感信息領域。因此，本文將重點介紹轉轉在日志脫敏方面的應用與實踐。

2 目標與措施

目標：對日志內的手機號、身份證號、銀行卡號等敏感信息脫敏，建立一個可持續的日志敏感信息管控機制。

措施：

1. 檢測和定位存在敏感日志的服務與CASE；
2. 開發低接入成本的日志脫敏工具；
3. 推動相關業務進行迭代修改；
4. 長期監控和持續治理，確保日志安全。

圖片

我們的第一步是利用大數據離線掃描服務日志，并使用正則表達式匹配敏感信息。

然而，第二和第三步是挑戰的關鍵，即如何在不干擾業務正常迭代排期的情況下，推動大量服務的日志做脫敏。我們希望使用技術手段盡量降低業務日志脫敏的人力成本。

3 實施

參考《轉轉日志規范》查看標準日志輸出要求，在此基礎之上，提供一些工具輔助業務對日志脫敏。

【推薦】JavaBean類需實現toString()方法，日志直接打印對象，慎用JSON工具將對象轉換成String。

3.1 脫敏工具類

我們開發了脫敏工具類，期望業務同學在實現JavaBean toString()方法的同時，使用脫敏工具對敏感字段使用脫敏。

圖片

• desensitize(String input)：通用脫敏函數，支持對任意字符脫敏，將提取字符串中4位以上數字(如手機號、銀行卡號、身份證號、數字驗證碼等)做脫敏；
• desensitizeByInputLength(String input)：據字符串長度匹配不同的脫敏規則，如：11位則使用手機號脫敏規則，18位則使用身份證號脫敏規則；
• desensitizePhoneNumber(String phoneNumber)：脫敏手機號，前3位和后4位，中間的數字用*代替；
• desensitizeIDCard(String idCard)：脫敏身份證號, 保留前6位和后4位，脫敏7~15位生日信息, 用*代替；
• desensitizeBankCardNumber(String bankCardNumber)：脫敏銀行卡號, 前6位和后4位，中間的數字用*代替。

public final class DesensitizeUtil {    
    
    /**
     * 根據字符串長度匹配不同的脫敏函數, 強制脫敏
     */
    public static String desensitizeByInputLength(String input) {
        int length = input.length();
        // 手機號
        if (length == 11) {
            return desensitizePhoneNumber(input);
        }
        // ,,,
    }

    /**
     * 脫敏手機號, 前3位和后4位，中間的數字用*代替
     */
    public static String desensitizePhoneNumber(String phoneNumber) {
        // 11位手機號
        if (phoneNumber.length() == 11) {
            return phoneNumber.substring(0, phoneNumber.length() - 8) + "****" + phoneNumber.substring(phoneNumber.length() - 4);
        }
        return phoneNumber;
    }
    
    // 省略其他脫敏函數...

}

3.2 JSON脫敏

在某些日志記錄的場景中，會打印包含敏感字段的JSON格式的數據，需要對其中的敏感信息進行脫敏處理。

在常見的JSON工具中，比如Jackson，可以使用自定義的序列化器/反序列化器來實現脫敏。下面以Jackson為例進行說明：

首先，我們可以定義一個注解來標注哪些字段需要脫敏處理：

/**
 * 脫敏注解
 */
@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Desensitize {
 
}

然后，我們可以創建一個自定義的Jackson模塊，通過繼承BeanSerializerModifier類來修改字段的序列化行為。在這個類中，我們可以根據字段上的Desensitize注解來判斷是否需要進行脫敏處理：

/**
 * Jackson脫敏序列化修改器
 */
public class JacksonDesensitizeSerializerModifier extends BeanSerializerModifier {

    @Override
    public List<BeanPropertyWriter> changeProperties(SerializationConfig config, BeanDescription beanDesc,
                                                     List<BeanPropertyWriter> beanProperties) {
        for (BeanPropertyWriter beanProperty : beanProperties) {
            // 只針對使用了@Desensitize的字段做脫敏
            Desensitize desensitize = beanProperty.getAnnotation(Desensitize.class);
            if(desensitize != null) {
                // 指定自定義的序列化器
                beanProperty.assignSerializer(new Desensitization());
            }
        }
        return beanProperties;
    }


    /**
     * Jackson序列化器
     */
    public class Desensitization extends StdSerializer<Object> {

        @Override
        public final void serialize(Object value, JsonGenerator gen, SerializerProvider provider) throws IOException {
            // 根據長度對字段做脫敏
            String desensitize = DesensitizeUtil.desensitizeByInputLength(String.valueOf(value));
            gen.writeString(desensitize);
        }

    }
}

最后，我們需要注冊這個自定義的模塊到Jackson中

/**
 * JSON工具
 */
public class JsonUtil {

    private static final ObjectMapper DESENSITIZE_OBJECT_MAPPER = newObjectMapper();

    private static ObjectMapper newObjectMapper() {
        ObjectMapper mapper = new ObjectMapper();
        //增加脫敏序列化器
        SimpleModule simpleModule = new SimpleModule("SimpleModuleDesensitize");
        simpleModule.setSerializerModifier(new JacksonDesensitizeSerializerModifier());
        mapper.registerModule(simpleModule);
        return mapper;
    }
    
   /**
    * 對象轉JSON的自動脫敏工具
    */
    public static <T> String object2DesensitizeString(T object) throws JsonProcessingException {
        return DESENSITIZE_OBJECT_MAPPER.writeValueAsString(object);
    }
    
    //...
}

對于業務同學而言，只需在需要脫敏的對象上添加脫敏注解，然后使用我們提供的JsonUtil進行脫敏操作，實現簡單高效。

/**
 * 需要脫敏的對象
 */
public class User {
      
    /**
     * 標記此字段需要脫敏
     */
    @Desensitize
    private String mobile;

    private String username;
    
    //getter setter...
}

User user = new User();
user.setAge(18);
user.username = "zhangsan";
user.password = "123456";

JsonUtil.object2DesensitizeString(user);
//輸出結果: {"mobile":"135****5555","username":"張三"}

注意：以上代碼只是一個示例，并不完整。在實際使用中，還需要根據具體的需求來靈活實現脫敏處理。

3.3 APT自動脫敏

在實際實施過程中，以上兩個方案遇到了很多阻礙。主要問題在于業務同學手動維護Bean的toString()方法過于繁瑣、重復工作多、容易遺漏對象并導致增加或刪除字段時需要不斷修改toString()函數。此外，業務服務所依賴的Bean來源復雜，有可能是其他業務提供的第二方Jar包或第三方Jar包。

因此，在實際應用中，業務同學更傾向于將Bean序列化為JSON并輸出到日志中，如下所示：

log.info("data={}", JsonUtil.object2DesensitizeString(bean));

然而，這種方法不符合《轉轉日志規范》要求，而且忽略了JSON序列化性能的問題。此外，這種方案也需要耗費大量的人力資源：需要評估每一行日志，以確定是否需要添加JSON脫敏功能。

因此，業務同學提出了以下需求：是否可以實現類似Lombok一樣的功能，只需在Bean的字段上添加脫敏注解，就能在編譯期自動實現脫敏后的toString()函數？這樣的話，在打印日志時直接打印對象即可自動脫敏。

經過調研發現，Lombok在編譯時利用APT（Annotation Processing Tools）生成代碼，實現了自動化的代碼生成過程，從而簡化了開發工作。

APT（Annotation Processing Tool）是Java的編譯期注解處理器。它允許開發人員在編譯期間處理注解，并根據注解和相關對象的信息生成Java代碼模板或配置文件等。

APT的使用可以提高程序性能，因為它在代碼編譯時完成注解處理，而不是在運行時使用反射方式處理注解。

著名的開源框架，如Lombok、MapStruct和AutoService等，也使用了類似的技術來優化代碼的生成和處理過程。

圖片

我們利用APT技術實現了這樣的功能：如果一個類沒有重寫Object.toString()方法，在編譯時會自動為該類生成一個脫敏后的toString()方法。這個自動生成的toString()方法能夠識別脫敏注解，并在生成的toString()方法內對敏感信息進行脫敏處理。

在Java編譯后的Class文件中，toString()方法可能來自三個來源：源代碼、轉轉APT處理、Lombok等。優先級為：源代碼 > 轉轉APT處理 > Lombok等其他APT。簡言之，我們的APT處理不會覆蓋源代碼中定義的toString()方法，但會覆蓋由Lombok生成的toString()方法。

比如，我們有以下源碼：

class User {

    private String username;
    /**
     * 密碼，增加了脫敏注解
     */
    @Desensitize
    private String password;
}

在接入轉轉APT后，反編譯的Class文件如下：

class User {
    private String username;
    @Desensitize
    private String password;

    public String toString() {
        StringJoiner sj = new StringJoiner(", ", "User[", "]");
        
        if (this.username != null) {
            sj.add("username=" + this.username);
        }
 
        if (this.password != null) {
            sj.add("password=" + DesensitizeUtil.desensitizeByInputLength(value));
        }
 
        return sj.toString();
    }
}

測試如下：

User user = new User();
user.username = "zhangsan";
user.password = "123456";

System.out.println(user);  
//輸出結果: User[username=張三, password=1****6]

這個功能的上線大大降低了業務同學實現日志脫敏的工作量，只需為字段添加脫敏注解即可。同時，也解決了線上對象未重寫Object.toString()時打印日志的尷尬問題。

不過，在落地APT過程中，我們也遇到了一些問題，希望能給讀者提供一些有收益的參考。

3.3.1 本地緩存問題

在某個服務的Spring Bean上，有一個包含大量本地緩存的List字段，這個服務會打印Spring Bean對象到日志中。在引入轉轉APT之前，一切正常；但引入后，出現了頻繁的OOM問題。通過內存分析后發現，問題出在轉轉APT為Spring Bean自動生成的toString()函數內產生了大量的字符串上。

@Service
public class AppService {
    /**
     * 本地緩存
     */
    private List<Object> cache = new ArrayList<>();
    
}

@Autowired
private AppService service;

log.info("service={}", service);

我們觀察到大部分帶有本地緩存（或者高內存占用字段）的對象都是Spring的Bean，因此，我們對轉轉APT進行了修改：即不再為Spring Bean生成toString()函數。

3.3.2 JDK序列化問題

某個服務的JavaBean使用了原生JDK的序列化/反序列化工具，但是這個JavaBean卻沒有添加serialVersionUID。

class Person implements Serializable {

    // 沒有定義serialVersionUID
    // private static final long serialVersionUID = -55721300387280236L;

}

Java序列化機制使用long型的serialVersionUID字段來標志類的版本號；序列化對象時，JVM會將serialVersionUID的值寫入序列化數據中；反序列化時，JVM會將序列化數據中的serialVersionUID與對應類中的serialVersionUID進行比較，若不同，則拋出InvalidCastException；若版本號相同，則能夠進行反序列化。

當一個類沒有顯式定義serialVersionUID時，JVM會自動根據類的信息計算生成一個默認的serialVersionUID。這樣，在類發生變化時，自動生成的serialVersionUID可能會改變，導致無法正確反序列化之前的數據。

引入轉轉APT后，由于自動生成了toString函數，類信息發生變化，導致serialVersionUID也發生了改變，進而導致反序列化失敗。

解決方式是將之前默認生成的serialVersionUID找到，并將其添加到類的源碼中。

3.4 棄用方案

還有一種快速落地的方法是，通過在應用程序內部統一攔截日志輸出，正則匹配敏感信息，并利用脫敏工具進行脫敏處理。

我們沒有使用這種方式的原因是因為：脫敏應盡量避免正則匹配，容易誤傷且性能低下。

4 規劃

上文提過，服務內依賴的Java Bean來源十分復雜，我們目前只解決了對象本身的脫敏問題。而對于服務依賴的Jar包版本控制，仍需要業務團隊梳理依賴關系，并手動修改脫敏后的Jar包版本，這一過程仍需要耗費較多的時間和人力。

考慮到這個問題，是否可以為每個服務提供一個依賴關系管控系統？該系統可以對Jar包的版本實現自動更新、自動化測試、灰度發布、自動發布和回滾等一系列功能。對于轉轉目前的情況來說，我相信這不是一個技術問題，而是一個需要更多時間來完善的TODO List。

圖片

5 總結

一個小小的功能日志脫敏，卻經歷了多個階段與挑戰，從敏感日志的發現到開發脫敏工具類，再到Json脫敏，再到APT脫敏，最終推動業務應用。核心的挑戰在于如何做好推動相關的工作？

我認為，推動相關工作的核心在于有效應對內在和外在的因素。然而，外部因素對推動的阻力常常更大，要成功推動工作，轉變外部阻力為內部動力至關重要。而對于推動者而言，換位思考、勇于挑戰未知、深入追根究底的打磨產品會使產品更容易被接受和推廣。