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.
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.
Journal desensitization
For the sake of the security of financial transactions, the state compulsorily stipulates that the following information should be log desensitized:
- User name
- Cell-phone number
- mailbox
- Bank card number
- 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
- Annotation-based log desensitization
- Policy implementation can be customized and policy entry-into-force conditions can be defined
- Common desensitization built-in solutions
- 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.