sql >> データベース >  >> RDS >> Database

どのデータマスキング機能を使用する必要がありますか?

    NIST情報アクセス部門の情報技術研究所のSimsonL.Garfinkelによると、

    匿名化は単一の手法ではなく、さまざまなレベルの有効性でさまざまな種類のデータに適用できるアプローチ、アルゴリズム、およびツールのコレクションです。一般に、プライバシー保護は、より積極的な匿名化手法が採用されるにつれて向上しますが、結果のデータセットに残る有用性は少なくなります。

    -個人情報の匿名化、NISTIR 8053

    静的データマスキング(SDM)は、休止中のデータ要素を匿名化するこれらのさまざまな手段の業界で認められた用語です。要素は通常、機密性が高いと見なされるデータベース列またはフラットファイルフィールドの値です。ヘルスケア業界では、これらはキー識別子と呼ばれます。特に危険にさらされているのは、個人を特定できる情報(PII)、保護された健康情報(PHI)、プライマリアカウント番号(PAN)、企業秘密、またはその他の機密情報です。

    「スタートポイント」のデータ中心のセキュリティ製品であるIRIFieldShield(または、同じ機能を含むIRICoSort製品とIRIVoracityプラットフォーム)は、複数のデータソースに複数のデータ検出とSDM機能を提供します。使用可能なフィールド/列ごとのマスキング機能は次のとおりです。

    1. 複数のNSA Suite BおよびFIPS準拠の暗号化(および復号化)アルゴリズム(形式の保持を含む) 暗号化
    2. SHA-1およびSHA-2ハッシュ
    3. ASCII de-ID(ビットスクランブリング)
    4. バイナリのエンコードとデコード
    5. データのぼかしまたはバケット化(匿名化)
    6. ランダムな生成または選択
    7. 編集(文字の難読化)
    8. 可逆的および不可逆的な仮名化
    9. カスタム式(計算/シャッフル)ロジック
    10. 条件付き/部分的な値のフィルタリングまたは削除(省略)
    11. カスタム値の置換
    12. バイトシフトおよび文字列関数
    13. トークン化(PCIの場合)

    「独自の」外部データマスキング機能をロールすることもできます。これにより、組み込みではなく、実行時にカスタム作成のフィールドレベルのルーチンを呼び出すことができます。

    (各アイテムで)どのマスキング機能を使用すればよいかという疑問が残ります。これは、ビジネスニーズとルール、および適用されるデータプライバシー法によって異なります。技術レベルでは、これは通常、結果の暗号文(マスクされたデータ)をどのように表示する必要があるか、可逆的または一意である必要があるかどうか、安全性、そして場合によってはプロセスに使用できる計算リソースと時間を決定することを意味します。これらの一般的な決定基準を詳しく見てみましょう:

    外観(リアリズム)

    新しくマスクされたデータは、元のデータとほぼ同じように見える必要がありますか?そのサイズとフォーマットはどうですか?仮名化とフォーマット保存暗号化は、最も一般的な2つの方法です。

    適切な名詞と1桁のアカウントまたは電話番号のルックアンドフィールをそれぞれ保持します。ただし、サブストリングマスキング(a / k /部分的なフィールドの編集、たとえばXXX-XX-1234)は、SSNのようなものには問題ない場合があります。分析などのためのデータの永続性と表示について考えてください。

    これに関連して、暗号文の外観とリアリズムも結果の有用性を決定する可能性があります。アプリケーションおよびデータベーステーブル(ロードユーティリティ)のターゲットでは、データの形式が事前定義された構造に準拠するだけでなく、クエリやその他のダウンストリームの運用コンテキストで引き続き機能する必要がある場合があります。

    つまり、きれいなデータや機能的なデータ、あるいはその両方が必要な場合は、完全な編集、ランダム化、ハッシュ、または直接暗号化(結果を広げて曖昧にする)を行わないでください。エージングやサブストリング操作などの小さな調整で回避できる場合がありますが、これらの選択が他の決定基準に与える影響を考慮してください…

    可逆性(再識別)

    元のデータを復元する必要がありますか?その答えは、動的データマスキングの場合のように、ソースデータをそのままにしておくか、マスクされたデータを新しいターゲットに書き出すかによって異なります。そのような場合、答えはノーです。

    答えが「いいえ」の場合でも、リアリズムが必要な場合があります。その場合、不可逆的な仮名化が最善の策となる可能性があります。それがなく、外観が重要でない場合は、キャラクターの編集を行ってください。また、どちらも当てはまらない場合は、ターゲットからソース列を完全に削除することを検討してください。

    答えが「はい」の場合、暗号化、可逆的仮名化またはトークン化、エンコード、またはASCII re-ID(ビットスクランブリング)などのIRIデータマスキング機能が示されます。より高度なユースケースでは、差分反転も必要になる場合があります。つまり、同じターゲットの異なる受信者が同じデータセット内の異なるものを表示することを許可されている場合。このような場合、秘密暗号化キー、ユーザー固有の啓示ジョブスクリプト、またはカスタムアプリケーションを展開できます。

    一意性(一貫性)

    同じ元の値を常に同じであるが異なる置換値に置き換える必要がありますか?データは置換値に結合されますか、それともグループ化されますか?その場合、選択された置換アルゴリズムは、発生したマスキングにもかかわらず参照整合性を維持するために、一意で再現可能な結果を​​生成する必要があります。

    これは、同じ平文に対して同じアルゴリズムとパスフレーズ(キー)が使用されている場合の暗号化によって実現できます。 FieldShield、VoracityなどのIRI Workbench IDEのデータ分類およびクロステーブル保護ウィザードは、一致したマスキングルールのクロステーブル(またはよりグローバルな)アプリケーションを通じてこれを容易にします。このように、同じ平文の値は、その場所に関係なく、常に同じ暗号文の結果を取得します。

    ただし、一意の置換名が不足し、元の名前が重複し、変更されているため、ここでは疑似化が難しくなります(ソーステーブルまたはファイルの元の値に挿入、更新、または削除します。 IRIは、このVoracityワークフローの例で一貫したクロステーブルの仮名化の問題に対処しました。

    強度(セキュリティ)

    各関数内のアルゴリズムを見ると、それらの相対的な「クラック可能性」を判断し、外観や速度などの他の暗号文の考慮事項と照らし合わせて評価するのに役立ちます。たとえば、IRIのAES256関数はAES128オプションよりも強力であり、SHA2はSHA1よりも強力であり、すべてがbase64エンコード/デコードおよびASCIIデコード/再ID関数よりも強力です。

    定義上、リバーシブル関数は通常、リバースできない関数よりも弱いです。たとえば、IRIの不可逆的な(外部ルックアップセット)仮名化方法は、その可逆的な(スクランブルされた元のセット)仮名化方法よりも安全です。とは言うものの、AES-256暗号化アルゴリズムは、キーが失われた場合にも解読するのが非常に難しい場合があります。

    もちろん、より強力なセキュリティは省略され、その後に不可逆的な文字の難読化(編集)が続きます。しかし、欠点は使いやすさの欠如です。 HIPAAセーフハーバーのコンテキストでは、キー識別子の削除が準拠しています。ただし、分析、調査、マーケティング、またはデモンストレーションのためにソースデータの一部を使用する必要がある場合は、代わりにマスキング機能と、技術の統計が低いことを判断(および証明)する専門家が必要になります。再識別の可能性。

    HIPAAの匿名化について説明しますが、いわゆる準識別子(郵便番号や年齢など)に関連するリスクもある可能性があることを忘れないでください。これらの値は、他のデータセットと組み合わせて再識別トレイルを確立するために使用できるため、多くの場合、マスキングする価値もあります。これらの同じ考慮事項の対象となるかどうか、およびその方法。

    計算(パフォーマンス)

    データマスキングアプローチの優れた点の1つは、計算集約型の暗号化アルゴリズムが含まれている場合でも、(ネットワーク全体、データベース、ファイル/システム、ディスクドライブの)大まかな暗号化に比べてオーバーヘッドがはるかに低いことです。保護のために指定したデータ要素(列の値)のみが、マスキング関数に取り込まれ、処理され、マスキング関数から返される必要があります。

    一般に、アルゴリズムが複雑である(そして強力である)ほど、適用に時間がかかります。データマスキングの速度は、適用される関数の数、DB列と行の数、プロセスで尊重するルックアップ制約の数(参照整合性のため)、ネットワーク帯域幅、RAM、I / O、同時プロセス、およびすぐ。

    次の非科学的なチャートは、便利な参照のために、サポートされているIRIデータマスキング機能カテゴリの一部(すべてではありません!)について、一般的に相対的な用語でのみ、上記の属性のほとんどを分類しています。言うまでもなく、IRIは、このチャートの適合性または責任の保証を否認します!

    IRIデータマスキング関数(FieldShieldおよびVoracity内)


    組み込みのIRIデータマスキング関数を使用する場合でも、定義するカスタム関数を使用する場合でも、ビジネスルールに基づいて特定の行や列に適用したり、テーブル全体に適用したりすることができます。また、定義、保存、および再利用できるデータマスキングルールを使用してこれを実行します。利便性と一貫性のために、ルールとして自動分類されたデータに対してこれらのデータマスキング機能を適用することも可能です(そして望ましいです)。また、API呼び出しを介して、動的データマスキングアプリケーションでそれらのいくつかを活用できます。

    FieldShield(またはVoracity)ユーザーは、Eclipse上に構築された無料の最先端のGUIでデータマスキングジョブを作成、実行、および管理できます。または、互換性のある自己文書化4GLスクリプトを編集および実行して、ソース/ターゲットデータとマスキング関数、およびコマンドラインでそれらのスクリプトを実行します。

    詳細については、https://www.iri.com/solutions/data-maskingを参照するか、IRI担当者にお問い合わせください。


    1. Oracle PL / SQL:DBMS_SCHEDULER.CREATE_JOBの例

    2. 巨大なテーブルデータをSQLServerの別のテーブルにコピーする方法

    3. Oracleの互換性レベルを確認する2つの方法(SQLclおよびSQL * Plus)

    4. Ansibleを使用したPostgreSQLのデプロイとメンテナンス