java log desensitization framework sensitive, elegant print desensitization log

Posted by Acs on Thu, 09 May 2019 16:56:03 +0200

problem

In order to ensure users'information security, sensitive information needs desensitization.
In the process of project development, it feels very troublesome to deal with the log problem of sensitive information every time. Most of them are handled separately with tool classes, which is not conducive to the unified management in the future and is not elegant.
So a log desensitization tool based on java annotations was written.

github sensitive

Project introduction

Log desensitization is a common security requirement. Common tool-based methods are too intrusive to code. It's particularly troublesome to write.

This project provides annotation-based methods, and built-in common desensitization methods, easy to develop.

Users can also customize annotations based on their actual needs.

Change log

Journal desensitization

For the sake of the security of financial transactions, the state compulsorily stipulates that the following information should be log desensitized:

  1. User name
  2. Cell-phone number
  3. mailbox
  4. Bank card number
  5. Password

Persistent encryption

When stored, the above information needs to be encrypted. The password is irreversible encryption, and the others are reversible encryption.

There are many similar functions. It is not within the scope of the solution of the system.

Characteristic

  1. Annotation-based log desensitization
  2. Policy implementation can be customized and policy entry-into-force conditions can be defined
  3. Common desensitization built-in solutions
  4. Support for jdk1.7+

Quick start

maven import

<dependency>
    <groupId>com.github.houbb</groupId>
    <artifactId>sensitive</artifactId>
    <version>0.0.1</version>
</dependency>

Define objects

  • User.java

We use desensitization for password, specifying the strategy of desensitization as Strategy Password. (Return null directly)

public class User {

    @Sensitive(strategy = StrategyChineseName.class)
    private String username;
    
    @Sensitive(strategy = StrategyCardId.class)
    private String idCard;
    
    @Sensitive(strategy = StrategyPassword.class)
    private String password;
    
    @Sensitive(strategy = StrategyEmail.class)
    private String email;
    
    @Sensitive(strategy = StrategyPhone.class)
    private String phone;
    
    //Getter & Setter
    //toString()
}
  • test
    @Test
    public void UserSensitiveTest() {
        User user = buildUser();
        System.out.println("Primitive before desensitization: " + user);
        User sensitiveUser = SensitiveUtil.desCopy(user);
        System.out.println("Desensitized subjects: " + sensitiveUser);
        System.out.println("Primitive after desensitization: " + user);
    }

    private User buildUser() {
        User user = new User();
        user.setUsername("De Prince");
        user.setPassword("123456");
        user.setEmail("12345@qq.com");
        user.setIdCard("123456190001011234");
        user.setPhone("18888888888");
        return user;
    }
  • The output information is as follows
Primitive before desensitization: User{username='desensitizer', idCard ='1234561900011234', password ='1234567', email ='12345@qq.com', phone ='1888888'}
Desensitized objects: User{username='Tuojun', idCard ='123456************ 34', password ='null', email ='123**@qq.com', phone ='188**** 8888'}
Primitive after desensitization: User{username='desensitizer', idCard ='1234561900011234', password ='1234567', email ='12345@qq.com', phone ='1888888'}

We can use sensitiveUser directly to print log information, and this object has no impact on other processes of the code, we can still use the original user object.

Scenarios where custom desensitization policies take effect

By default, the scenarios we specify are valid.

But you may need to not desensitize in some cases, for example, some user password is 123456, you think this user is not desensitized.

  • UserPasswordCondition.java
@Sensitive(condition = ConditionFooPassword.class, strategy = StrategyPassword.class)
private String password;

Others remain unchanged. We specify a condition, which is implemented as follows:

  • ConditionFooPassword.java
public class ConditionFooPassword implements ICondition {
    @Override
    public boolean valid(IContext context) {
        try {
            Field field = context.getCurrentField();
            final Object currentObj = context.getCurrentObject();
            final String password = (String) field.get(currentObj);
            return !password.equals("123456");
        } catch (IllegalAccessException e) {
            throw new RuntimeException(e);
        }
    }
}

That is, the password desensitization strategy will only take effect if the password is not 123456.

For a single field

The above example is based on annotated programming, if you're just a single field. such as

  • singleSensitiveTest
@Test
public void singleSensitiveTest() {
    final String email = "123456@qq.com";
    IStrategy strategy = new StrategyEmail();
    final String emailSensitive = (String) strategy.des(email, null);
    System.out.println("Desensitization mailbox:" + emailSensitive);
}
  • log information
Desensitization mailbox: 123***@qq.com

Places to be optimized

New Object Creation

This way to avoid modifying the original object, create a new object, a little wasteful, can be optimized.

Other methods

Sensitive information can be desensitized based on log4j2/logback converters, but the portability of different log frameworks is not different.

Topics: Java github Maven Programming