データマスキング

データ マスキングまたはデータ難読化とは、機密データを変更するプロセスであり、不正侵入者にとって価値がないかほとんどない一方で、ソフトウェアまたは権限のある担当者は引き続き使用できます。データ マスキングは、コンテキストに応じて 匿名化またはトークン化と呼ばれることもあります。

データをマスクする主な理由は、個人を特定できる情報、またはミッションクリティカルなデータとして分類される情報を保護することです。ただし、データは有効なテスト サイクルを実行する目的で使用可能である必要があります。また、本物に見え、一貫性があるように見える必要があります。企業の運用システムの外部で表されるデータにマスクを適用する方が一般的です。言い換えると、アプリケーション開発、プログラム拡張の構築、およびさまざまなテスト サイクルの実施の目的でデータが必要な場合です。エンタープライズ コンピューティングでは、運用システムからデータを取得して、これらの非運用環境に必要なデータ コンポーネントを埋めるのが一般的です。ただし、この方法は必ずしも非運用環境に限定されるわけではありません。組織によっては、コール センター オペレータの端末画面に表示されるデータに、ユーザーのセキュリティ権限に基づいて動的にマスクを適用する場合があります (例: コール センター オペレータが課金システムでクレジットカード番号を表示できないようにする)。

コーポレートガバナンスの観点からの主な懸念^[1]は、これらの非本番環境で作業を行う人員が、本番データに含まれる情報を扱うためのセキュリティ許可を必ずしも得ていないことです。この慣行は、権限のない人員がデータをコピーできるセキュリティホールとなり、標準的な本番レベルの制御に関連するセキュリティ対策が簡単に回避される可能性があります。これは、データセキュリティ侵害のアクセスポイントとなります。

データのマスキングや難読化に関係するデータは、いくつかのレベルで意味を保たなければなりません。

1. データは、アプリケーション ロジックにとって意味のあるままでなければなりません。たとえば、住所の要素を難読化し、都市と郊外を別の都市または郊外に置き換える場合、アプリケーション内に郵便番号または郵便番号検索を検証する機能があれば、その機能がエラーなく、期待どおりに動作できるようにする必要があります。クレジットカード アルゴリズム検証チェックや社会保障番号検証についても同様です。
2. マスクされたデータが実稼働データ ソースからのものであることが明らかにならないように、データに十分な変更を加える必要があります。たとえば、組織内では、30 万ドルを超える収入を得ている上級管理職が 10 人いることが周知の事実であるとします。組織の HR システムのテスト環境にも、同じ収入階層の ID が 10 人含まれている場合、他の情報を組み合わせて実際の ID をリバース エンジニアリングできます。理論的には、データが明らかにマスクまたは難読化されている場合、データ侵害を企む人物が実稼働データセット内の ID についてある程度の知識を持っていれば、ID データをリバース エンジニアリングできると考えるのは妥当です。したがって、データセットのデータの難読化またはマスクは、個別のフィールドやテーブル内の個々のデータ要素だけでなく、ID および機密データ レコードが保護されるように適用されます。
3. 組織内の複数のデータベースにそれぞれマスク対象の特定のデータ要素が含まれている場合、マスクされた値はデータベース間で一貫している必要があります。アプリケーションは最初に 1 つのデータベースにアクセスし、その後、外部キーがマスクされている関連情報を取得するために別のデータベースにアクセスすることがあります (たとえば、コール センター アプリケーションは最初に顧客マスター データベースからデータを取り出し、状況に応じて、その後、非常に異なる金融商品を含む他のいくつかのデータベースの 1 つにアクセスします)。これには、適用されるマスキングが繰り返し可能であること (マスキング アルゴリズムへの同じ入力値は常に同じ出力値を生成する) が必要ですが、リバース エンジニアリングして元の値に戻すことはできません。関係するデータ要素によっては、上記 (1) で述べた追加の制約も適用される場合があります。このシナリオで接続する必要があるデータベース間で異なる文字セットが使用されている場合、マスキング アルゴリズム自体によって、またはこのアルゴリズムを呼び出す前に、元の値を共通の表現に変換するスキームを適用する必要があります。

置換は、データ マスキングを適用し、データ レコードの実際の外観と操作性を維持できる最も効果的な方法の 1 つです。

この手法では、既存の値を別の本物らしい値に置き換えることができるような方法でマスキングを実行できます。^[2]この手法が、データ サブセット全体をマスキングされたデータ セットであるかどうかに関して偽装する上で最適なメリットを提供するデータ フィールド タイプがいくつかあります。たとえば、顧客レコードを含むソース データを処理する場合、実際の姓または名を、提供されたまたはカスタマイズされたルックアップ ファイルからランダムに置き換えることができます。置換の最初のパスですべての名に男性名を適用できる場合、2 番目のパスでは、性別が「F」であるすべての名に女性名を適用できるようにする必要があります。この手法を使用すると、データ構造内の性別の組み合わせを簡単に維持し、データ レコードに匿名性を適用できますが、同時に、マスキングされたデータで構成されるデータベースとして簡単に識別できない、本物らしい外観のデータベースを維持できます。

この置換方法は、電話番号、郵便番号、ポストコード、クレジットカード番号、社会保障番号やメディケア番号などの他のカードタイプの番号など、世界中のデータベース構造にある多くのフィールドに適用する必要があります。これらの番号は、実際にLuhn アルゴリズムのチェックサム テストに準拠する必要があります。

ほとんどの場合、置換ファイルはかなり大規模になる必要があるため、大規模な置換データセットとカスタマイズされたデータ置換セットを適用する機能が、データ マスキング ソリューションの評価基準の重要な要素になります。

シャッフル法は、データ難読化の非常に一般的な形式です。置換法に似ていますが、マスクされている同じデータ列から置換セットを導き出します。非常に簡単に言えば、データは列内でランダムにシャッフルされます。^[3]ただし、単独で使用した場合、元のデータに関する知識を持つ人なら誰でも、データセットに「what if」シナリオを適用して、実際の ID を再構築できます。シャッフル法は、シャッフル アルゴリズムが解読されれば、元に戻すこともできます。^[要出典]

データシャッフルは、データの有用性と漏洩リスクの両方において他のマスキング技術よりも優れた性能を発揮しながら、撹乱の望ましい特性をすべて保持するため、撹乱または変更された機密データを使用することに対する懸念を克服します。^[3]

ただし、シャッフルには、特定の領域では実際に強みがあります。たとえば、テスト データベースの財務情報の年末の数字の場合、仕入先の名前をマスクし、マスクされたデータベース全体でアカウントの値をシャッフルできます。元のデータについて詳しい知識のある人でも、真のデータ レコードを元の値に戻すことはほとんど不可能です。

数値差異法は、財務および日付駆動の情報フィールドに適用するのに非常に便利です。事実上、このマスキング方法を利用する方法では、給与などの財務データ セットに意味のある範囲を残すことができます。適用される差異が +/- 10% 程度であれば、受取人に支払われる給与の範囲に関して、それは依然として非常に意味のあるデータ セットです。

同じことが日付情報にも当てはまります。データ セット全体で人口統計および保険数理データの整合性を維持する必要がある場合、日付フィールドに +/- 120 日のランダムな数値分散を適用すると日付分布は保持されますが、マスクされているレコードの既知の実際の日付または生年月日、または既知の日付値に基づいて、既知のエンティティまで追跡することは依然としてできなくなります。

暗号化は、多くの場合、データ マスキングの問題を解決する最も複雑な方法です。暗号化アルゴリズムでは、ユーザー権限に基づいてデータを表示するために「キー」を適用する必要があります。これは多くの場合、最善の解決策のように思われますが、実際には、データを表示する適切な権限を持たない担当者にキーが渡される可能性があります。これでは、マスキングの目的が達成されません。古いデータベースは、提供されたキーの元の認証情報を使用してコピーされ、同じ制御不能な問題が継続する可能性があります。

最近、エンティティのプロパティを保持しながらデータを暗号化するという問題が認識され、ベンダーや学界の間で新たな関心が寄せられています。新しい課題により、フォーマットを保持する暗号化を実行するアルゴリズムが生まれました。これらは、NIST が承認した Advanced Encryption Standard (AES) アルゴリズム モードに基づいています。^[4]

特定のフィールドに null 値を適用するという非常に単純なマスキング手法が採用されることもあります。null 値アプローチは、実際にはデータ要素の可視性を防止する場合にのみ役立ちます。

ほとんどの場合、マスクされたデータ セットで維持されるデータ整合性の度合いが低下します。これは現実的な値ではなく、テスト対象のシステムにあるフロントエンド ソフトウェアに適用されている可能性のあるアプリケーション ロジック検証に失敗することになります。また、アイデンティティ データをリバース エンジニアリングしようとする人には、データ セットにある程度データ マスクが適用されていることが強調されます。

特定のフィールドの文字をスクランブルまたはマスクすることも、機密情報の表示を防ぐための単純でありながら非常に効果的な方法です。これは実際には、以前のヌル化方法の拡張ですが、データを実際の状態に保ち、完全にマスクしないことに重点が置かれています。

これは、実稼働システムのクレジットカード データによく適用されます。たとえば、コール センターのオペレーターが顧客のクレジットカードにアイテムを請求するとします。次に、最後の 4 桁が XXXX XXXX xxxx 6789 であるカードの請求参照を引用します。オペレーターはカード番号の最後の 4 桁しか見ることができませんが、請求システムが顧客の詳細を請求のために渡すと、完全な番号が支払いゲートウェイ システムに公開されます。

このシステムはテストシステムにはあまり効果的ではありませんが、上で説明した課金シナリオには非常に役立ちます。これは動的データマスキング法としても知られています。^{[5] [6]}

マスキング方法の構築方法に関係なく、追加のルールを任意のマスキングソリューションに組み込むこともできます。製品に依存しないホワイトペーパー^{[7]は、行内部同期ルール、テーブル内部同期ルール、テーブル[8]}からテーブル同期ルールなど、エンタープライズマスキングソリューションのより一般的な複雑な要件のいくつかを調べるための優れた情報源です。

データ マスキングは、テスト データの構築と密接に結びついています。データ マスキングには、静的データ マスキングとオンザフライ データ マスキングの 2 つの主要な種類があります。

静的データ マスキングは通常、データベースのゴールデン コピーに対して実行されますが、ファイルを含む他のソースの値にも適用できます。DB 環境では、運用データベース管理者は通常、テーブルのバックアップを別の環境にロードし、データセットを特定のテスト ラウンドに必要なデータを保持するサブセットに縮小し (「サブセット化」と呼ばれる手法)、データが静止している間にデータ マスキング ルールを適用し、ソース管理から必要なコード変更を適用し、データを目的の環境にプッシュします。^[9]

決定論的マスキングとは、同じ行、同じテーブル、同じデータベース/スキーマ、インスタンス/サーバー/データベースタイプ間で、列の値を同じ値に置き換えるプロセスです。例: データベースには複数のテーブルがあり、各テーブルにはファーストネームの列があります。決定論的マスキングでは、ファーストネームは常に同じ値に置き換えられます。つまり、「Lynne」がデータベースのどこにあっても、「Lynne」は常に「Denise」になります。^[10]

静的データマスキングの代替として、データの確率的変動を利用して元のデータの統計的特性の一部を保持する方法もあります。統計データ難読化方法の例としては、差分プライバシー^[11] やDataSifter法^[12]などがあります。

オンザフライ データ マスキング^[13]は、データが途中でディスクに触れることなく、環境から環境へデータを転送するプロセスで行われます。同じ手法が「動的データ マスキング」にも適用されますが、一度に 1 つのレコードです。このタイプのデータ マスキングは、継続的なデプロイメントを行う環境や、高度に統合されたアプリケーションに最も役立ちます。継続的なデプロイメントまたは継続的な配信のプラクティスを採用している組織には、バックアップを作成してデータベースのゴールデン コピーにロードする時間がありません。したがって、マスクされたテスト データの小さなサブセット (デルタ) を本番環境から継続的に送信することが重要です。高度に統合されたアプリケーションでは、開発者は開発の最初から他の本番システムからフィードを受け取りますが、これらのフィードのマスキングは見落とされたり、後になって予算が組まれたりするため、組織は準拠していません。オンザフライ データ マスキングを導入することが不可欠になります。

動的データ マスキングはオンザフライ データ マスキングに似ていますが、オンザフライ データ マスキングでは、あるソースから別のソースにデータをコピーして、後者を共有できるようにするという点で異なります。動的データ マスキングは実行時に動的にオンデマンドで行われるため、マスクされたデータを動的に保存する 2 番目のデータ ソースは必要ありません。

動的データ マスキングにより、シンガポール金融管理局やヨーロッパのプライバシー規制など、厳格なプライバシー規制を中心としたさまざまなシナリオが可能になります。

動的データ マスキングは属性ベースでポリシー主導です。ポリシーには次のものが含まれます。

• 医師は担当患者の医療記録を閲覧できる（データフィルタリング）
• 医師は医療記録内の SSN フィールドを表示できません (データ マスキング)。

動的データ マスキングは、特にフォーマット保持暗号化を使用する場合に、値をオンザフライで暗号化または復号化するためにも使用できます。

近年、動的なデータ フィルタリングとマスキングを実装するための標準がいくつか登場しています。たとえば、XACMLポリシーを使用して、データベース内のデータをマスキングできます。

動的データ マスキングを適用できるテクノロジは 6 つあります。

1. データベース内: データベースは SQL を受信し、返されたマスクされた結果セットに書き換えを適用します。開発者とデータベース管理者には適用できますが、アプリケーションには適用できません (接続プール、アプリケーション キャッシュ、およびデータ バスによってアプリケーション ユーザー ID がデータベースから隠され、アプリケーション データの破損を引き起こす可能性があるため)。
2. アプリケーションとデータベース間のネットワーク プロキシ: SQL をキャプチャし、選択要求に書き換えを適用します。単純な「選択」要求を持つ開発者およびデータベース管理者には適用できますが、ストアド プロシージャ (プロキシは実行のみを識別します) およびアプリケーション (接続プール、アプリケーション キャッシュ、およびデータ バスによってアプリケーション ユーザー ID がデータベースから隠され、アプリケーション データの破損を引き起こす可能性があるため) には適用できません。
3. データベース プロキシ: ネットワーク プロキシのバリエーションです。データベース プロキシは通常、アプリケーション/ユーザーとデータベースの間に配置されます。アプリケーションとユーザーは、データベース セキュリティ プロキシを介してデータベースに接続します。アプリケーションとユーザーがデータベースに接続する方法に変更はありません。また、データベース サーバーにエージェントをインストールする必要もありません。SQL クエリは書き換えられますが、実装されると、このタイプの動的データ マスキングはストアド プロシージャとデータベース関数内でもサポートされます。
4. エンドユーザーとアプリケーション間のネットワーク プロキシ: テキスト文字列を識別して置換します。この方法は、リアルタイムの文字列置換が意図せず適用されると破損が起こりやすいため、複雑なアプリケーションには適用できません。
5. アプリケーションと XACML でのコード変更: コード変更は通常、実行が難しく、保守が不可能であり、パッケージ化されたアプリケーションには適用できません。
6. アプリケーション ランタイム内: アプリケーション ランタイムをインストルメント化することで、データ ソースから返される結果セットを書き換えるポリシーが定義され、アプリケーション ユーザーに完全な可視性を提供します。この方法は、データ要求、データ結果、およびユーザー結果を制御できるため、複雑なアプリケーションを動的にマスクする唯一の適用可能な方法です。
7. ブラウザ プラグインによるサポート: SaaS またはローカル Web アプリケーションの場合、ブラウザ アドオンを設定して、正確なCSS セレクターに対応するデータ フィールドをマスクできます。これは、アプリケーション内の機密フィールドをHTML クラスなどでマークするか、難読化またはマスクするフィールドを識別する適切なセレクターを見つけることで実現できます。

近年、最終的なアプリケーションがクラウドでホストされるかオンプレミスでホストされるかに関係なく、組織は新しいアプリケーションをクラウドで開発することがますます増えています。現在、クラウド ソリューションにより、組織はインフラストラクチャをサービスとして、プラットフォームをサービスとして、ソフトウェアをサービスとして使用できます。テスト データを作成し、それをオンプレミスのデータベースからクラウドに、またはクラウド内の異なる環境間で移動するには、さまざまなモードがあります。顧客がデータベースの管理をクラウド プロバイダーに依存しながら PII データを保護する必要がある場合、動的データ マスキングはクラウドでさらに重要になります。アプリケーションがクラウドでホストされるかオンプレミスでホストされるかに関係なく、開発環境のサービス レベル契約(SLA) は通常、運用環境の SLA ほど厳格ではないため、データ マスキングはシステム開発ライフ サイクル(SDLC) のこれらのプロセスの一部になります。

• 諜報機関によるマスキングと暴露