針對大規模服務日志敏感信息的長效治理實踐
1 背景
近年來，國家采取了多項重要舉措來加強個人數據保護，包括實施《中華人民共和國網絡安全法》和《個人信息保護法》等法律法規。這些舉措旨在確保用戶隱私的安全，同時確保企業合規運營。在處理敏感數據時，企業有責任采取適當的措施來保護用戶信息。
在數據保護方面，日志記錄成為一個需要特別關注的敏感信息領域。因此，本文將重點介紹轉轉在日志脫敏方面的應用與實踐。
2 目標與措施
目標：對日志內的手機號、身份證號、銀行卡號等敏感信息脫敏，建立一個可持續的日志敏感信息管控機制。
措施：
- 檢測和定位存在敏感日志的服務與CASE；
- 開發低接入成本的日志脫敏工具；
- 推動相關業務進行迭代修改；
- 長期監控和持續治理，確保日志安全。
圖片
我們的第一步是利用大數據離線掃描服務日志，并使用正則表達式匹配敏感信息。
然而，第二和第三步是挑戰的關鍵，即如何在不干擾業務正常迭代排期的情況下，推動大量服務的日志做脫敏。我們希望使用技術手段盡量降低業務日志脫敏的人力成本。
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脫敏，最終推動業務應用。核心的挑戰在于如何做好推動相關的工作？
我認為，推動相關工作的核心在于有效應對內在和外在的因素。然而，外部因素對推動的阻力常常更大，要成功推動工作，轉變外部阻力為內部動力至關重要。而對于推動者而言，換位思考、勇于挑戰未知、深入追根究底的打磨產品會使產品更容易被接受和推廣。
