Shulou(Shulou.com)06/01 Report--

problem

In order to ensure the information security of users, sensitive information needs to be desensitized.

In the process of project development, it is very troublesome to deal with the log of sensitive information every time, and most of them are handled separately by tool classes, which is not conducive to unified management in the future and is not elegant.

Therefore, a log desensitization tool based on java annotations is written.

Github sensitive

Project introduction

Log desensitization is a common security requirement. The common method based on the tool class method is too strong for the code. It is very troublesome to write.

This project provides an annotation-based approach and has built-in common desensitization methods to facilitate development.

Users can also customize annotations based on their actual needs.

Change log

Log desensitization

For the sake of the security of financial transactions, it is mandatory for the state to desensitize the following information:

User name

Cell-phone number

Mailbox

Bank card number

Password persistent encryption

The above information needs to be encrypted when it is stored, the password is irreversible encryption, and the rest is reversible encryption.

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

Characteristics

Log desensitization based on annotations

You can customize the policy implementation and the conditions for the policy to take effect.

Common desensitization built-in solutions quickly start maven import com.github.houbb sensitive-core 0.0.1 define object User.java

We desensitize password and specify the desensitization strategy as StrategyPassword. (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 ("original before desensitization:" + user); User sensitiveUser = SensitiveUtil.desCopy (user); System.out.println ("desensitized object:" + sensitiveUser); System.out.println ("original after desensitization:" + user);} private User buildUser () {User user = new User (); user.setUsername ("desensitized monarch") User.setPassword ("123456"); user.setEmail ("12345@qq.com"); user.setIdCard ("123456190001011234"); user.setPhone ("18888888888"); return user } the output information is as follows: original before desensitization: User {username=' desensitized monarch', idCard='123456190001011234', password='1234567', email='12345@qq.com', phone='18888888888'} desensitized object: User {username=' desensitized * monarch', idCard='123456*34', password='null', email='123**@qq.com', phone='188****8888'} desensitized original: User {desensitized monarch', idCard='123456190001011234', password='1234567' Email='12345@qq.com', phone='18888888888'}

We can directly use sensitiveUser to print log information, and this object does not affect the rest of the code, we can still use the original user object.

The scenario in which the custom desensitization policy takes effect

By default, all the scenarios we specify are valid.

But you may need to do not desensitize in some cases, for example, some users' password is 123456, so it doesn't matter if you think this kind of user is not desensitized.

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

Everything else remains the same, we specify a condition, which is implemented as follows:

ConditionFooPassword.javapublic 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 policy takes effect only if the password is not 123456.

For a single field

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

SingleSensitiveTest@Testpublic void singleSensitiveTest () {final String email = "123456@qq.com"; IStrategy strategy = new StrategyEmail (); final String emailSensitive = (String) strategy.des (email, null); System.out.println ("desensitized mailbox:" + emailSensitive);} mailbox after desensitization: 123***@qq.com new object creation where to be optimized

In order to avoid modifying the original object, this approach creates a brand new object, which is a little wasteful and can be optimized.

Other methods

It can desensitize sensitive information based on log4j2/logback and other converters, but it does not have the portability of different log frameworks.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.