JAvaログ脱敏フレームsensitive、優雅な印刷脱敏ログ
4346 ワード
に質問
ユーザの情報セキュリティを保証するために、機密情報は脱敏する必要がある.プロジェクト開発の過程で、敏感な情報のログ問題を処理するたびに面倒な感じがして、大部分はツール類で単独で処理して、後で統一管理に不利で、とても優雅ではありません.そこでjava注釈に基づくログ脱敏ツールを書きました.
github sensitive
プロジェクト紹介
ログの脱敏は、一般的なセキュリティ要件です.一般的なツールクラスメソッドに基づく方法では,コードへの侵入性が強すぎる.書くのが面倒だ.
本プロジェクトは注釈ベースの方式を提供し、一般的な脱敏方式を内蔵し、開発が容易である.
ユーザーは、実際のニーズに基づいて注釈をカスタマイズすることもできます.
変更ログ
ログの非アクティブ化
金融取引の安全性のために、国は以下の情報に対してログを脱敏することを強制している.ユーザ名 携帯番号 メールボックス 銀行カード番号 パスワード 永続化された暗号化
保存するときは上の情報を暗号化する必要があります.パスワードは不可逆暗号化で、その他は可逆暗号化です.
似たような機能がたくさんあります.本システムの解決範囲外です.
とくせい注釈ベースのログ脱感 カスタムポリシー実装、ポリシー有効条件 一般的な脱敏内蔵案 jdk 1.7+ をサポート
クイックスタート
mavenインポート
オブジェクトの定義 User.java
我々はpasswordに対して脱敏を使用し,StrategyPasswordとして脱敏ポリシーを指定した.(nullを直接返す)テスト 出力情報は以下の通り
カスタム脱敏ポリシーが有効なシーン
デフォルトでは、指定したシーンはすべて有効です.
しかし、一部のユーザーのパスワードが123456であるなど、脱敏しない場合があります.このようなユーザーは脱敏しないと思います. UserPasswordCondition.java
その他は変わらず、conditionを指定し、以下のように実現しました. ConditionFooPassword.java
すなわち、パスワードが123456でない場合にのみ、パスワードの脱敏ポリシーが有効になります.
単一フィールド
上記の例は、単一のフィールドであれば、注釈式に基づくプログラミングです.たとえば singleSensitiveTest ログ情報
最適化される場所
新しいオブジェクトの作成
この方法では、元のオブジェクトを修正しないように、新しいオブジェクトを作成し、少し無駄にして最適化することができます.
その他の方法
log 4 j 2/logbackなどの変換器に基づいて機密情報の脱敏を行うことができるが、異なるlogフレームワークの移植性を有しない.
ユーザの情報セキュリティを保証するために、機密情報は脱敏する必要がある.プロジェクト開発の過程で、敏感な情報のログ問題を処理するたびに面倒な感じがして、大部分はツール類で単独で処理して、後で統一管理に不利で、とても優雅ではありません.そこでjava注釈に基づくログ脱敏ツールを書きました.
github sensitive
プロジェクト紹介
ログの脱敏は、一般的なセキュリティ要件です.一般的なツールクラスメソッドに基づく方法では,コードへの侵入性が強すぎる.書くのが面倒だ.
本プロジェクトは注釈ベースの方式を提供し、一般的な脱敏方式を内蔵し、開発が容易である.
ユーザーは、実際のニーズに基づいて注釈をカスタマイズすることもできます.
変更ログ
ログの非アクティブ化
金融取引の安全性のために、国は以下の情報に対してログを脱敏することを強制している.
保存するときは上の情報を暗号化する必要があります.パスワードは不可逆暗号化で、その他は可逆暗号化です.
似たような機能がたくさんあります.本システムの解決範囲外です.
とくせい
クイックスタート
mavenインポート
com.github.houbb
sensitive-core
0.0.1
オブジェクトの定義
我々はpasswordに対して脱敏を使用し,StrategyPasswordとして脱敏ポリシーを指定した.(nullを直接返す)
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
public void UserSensitiveTest() {
User user = buildUser();
System.out.println(" : " + user);
User sensitiveUser = SensitiveUtil.desCopy(user);
System.out.println(" : " + sensitiveUser);
System.out.println(" : " + user);
}
private User buildUser() {
User user = new User();
user.setUsername(" ");
user.setPassword("123456");
user.setEmail("[email protected]");
user.setIdCard("123456190001011234");
user.setPhone("18888888888");
return user;
}
: User{username=' ', idCard='123456190001011234', password='1234567', email='[email protected]', phone='18888888888'}
: User{username=' * ', idCard='123456**********34', password='null', email='123**@qq.com', phone='188****8888'}
: User{username=' ', idCard='123456190001011234', password='1234567', email='[email protected]', phone='18888888888'}
sensitiveUser
を直接利用してログ情報を印刷することができますが、このオブジェクトはコードの他のプロセスに影響を与えず、元のuser
オブジェクトを使用することができます.カスタム脱敏ポリシーが有効なシーン
デフォルトでは、指定したシーンはすべて有効です.
しかし、一部のユーザーのパスワードが123456であるなど、脱敏しない場合があります.このようなユーザーは脱敏しないと思います.
@Sensitive(condition = ConditionFooPassword.class, strategy = StrategyPassword.class)
private String password;
その他は変わらず、conditionを指定し、以下のように実現しました.
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);
}
}
}
すなわち、パスワードが123456でない場合にのみ、パスワードの脱敏ポリシーが有効になります.
単一フィールド
上記の例は、単一のフィールドであれば、注釈式に基づくプログラミングです.たとえば
@Test
public void singleSensitiveTest() {
final String email = "[email protected]";
IStrategy strategy = new StrategyEmail();
final String emailSensitive = (String) strategy.des(email, null);
System.out.println(" :" + emailSensitive);
}
:123***@qq.com
最適化される場所
新しいオブジェクトの作成
この方法では、元のオブジェクトを修正しないように、新しいオブジェクトを作成し、少し無駄にして最適化することができます.
その他の方法
log 4 j 2/logbackなどの変換器に基づいて機密情報の脱敏を行うことができるが、異なるlogフレームワークの移植性を有しない.