機械学習データセット内の機密データに関する考慮事項

機械学習(ML)プログラムを開発する際には、社内のデータアクセスとそのアクセスのセキュリティの関係を釣り合わせることが重要です。機密データへのアクセスが制限されている場合でも、生データセットに含まれている分析情報を ML トレーニングに活用する必要があります。両方の目標を達成するには、任意の数の集計または難読化手法を部分的に適用した後で、生データのサブセットまたはデータセット全体で ML システムをトレーニングすると便利です。

たとえば、製品に関する顧客のフィードバックを評価するよう、ML モデルをトレーニングする必要がありますが、データエンジニアがそのフィードバックの送信者を特定することは望ましくありません。ただし、配送先住所や購入履歴などの情報は、ML モデルのトレーニングにとって非常に重要です。データがデータ エンジニアに提供された後、データ エンジニアはデータ探索の目的でデータをクエリする必要があるため、機密データ フィールドを保護してからデータを使用可能にすることが重要です。この種のジレンマは、レコメンデーション エンジンを含む ML モデルでも一般的です。ユーザー固有の結果を返すモデルを作成するには、通常、ユーザー固有のデータにアクセスする必要があります。

このような場合のために、データセットから一部の機密データを削除してもなお有効な ML モデルをトレーニングするための手法があります。この記事では、機密情報を特定して保護するための戦略と、ML データに関するセキュリティ上の懸念に対処するプロセスについて説明します。

機密情報の取り扱い

機密情報とは、該当する責任者の意思と法律的観点から、アクセスの制限や暗号化などのセキュリティ手段を追加して保護する必要があると考えるすべてのデータのことです。たとえば、名前、メールアドレス、お支払い情報などのフィールドは、多くの場合、機密とみなされます。データ エンジニアや悪意のある者が機密情報を間接的に推論できるような情報も、機密情報とみなされます。

HIPAA や PCI-DSS などの標準によって、機密データを保護するための一連のベスト プラクティスが指定されると同時に、機密データが処理される方法が顧客に通知されます。これらの認定基基準により、顧客は十分な情報に基づいて、個人情報のセキュリティに関する意思決定ができます。

機械学習データセットにおける機密データの処理が困難になる理由は、次のとおりです。

  • ほとんどのロールベースのセキュリティは所有権のコンセプトに基づいています。つまり、ユーザーは自分のデータを表示または編集できますが、自分に属していないデータにはアクセスできません。多くのユーザーからのデータの集合である ML データセットでは、所有権のコンセプトは機能しなくなります。基本的に、データ エンジニアは、データセットを効果的に使用するために、データセット全体に対する表示アクセス権を付与される必要があります。
  • 予防措置として頻繁に使用される、機密フィールドの暗号化や解像度の削減は、ML データセットでは必ずしも十分ではありません。集計データセット自体が頻度分析攻撃によって暗号化を破る手段を提供することがよくあります。
  • データセットから機密フィールドをランダムにトークン化、抑制、または削除することは必要なデータを不明瞭にするため、ML モデルのトレーニングの効果が減少し、予測のパフォーマンスが低下する可能性があります。

組織は、通常、セキュリティと利便性の適切なバランスをとるために、ツールと一連のベスト プラクティスを開発します。ML データセットの機密データを保護するために、以降で説明する次の 3 つの目標に留意してください。

  • 高い信頼度でデータセット内の機密データを識別すること。
  • プロジェクトへの悪影響なく機密データを保護すること。これは、機密扱いと判断したデータの削除やマスキング、あいまい化によって実現できます。
  • ガバナンス プランとベスト プロパティのドキュメントを作成すること。これにより、データ エンジニアとユーザーは、機密データ、特に機密データを確実に識別、マスク、削除できないシナリオに関して、適切に意思決定できます。

これらの 3 つの目標については、以降のセクションで詳しく説明します。これらのセクションでは、データセットを社内でのみ公開するシナリオを中心に説明します。この記事では、データセットを一般公開で共有するシナリオについては説明しません。

機密データの識別

社内環境に機密データが存在するシナリオはいくつか考えられます。以降のセクションでは、最も一般的な 5 つのシナリオと、その機密データを識別するために使用できる方法について説明します。

列の機密データ

機密データは、構造化データセットの特定の列に限定されている場合があります。たとえば、ユーザーの姓名および住所を含む列のセットがあるとします。この場合、機密データを含む列を識別し、それらを保護する方法を決定して、決定事項を文書化します。

テキストベースの非構造化データセットの機密データ

機密データは、テキストベースの非構造化データセットの一部である場合、通常、既知のパターンを使用して検出できます。たとえば、チャットの記録のクレジット カード番号は、クレジット カード番号の共通の正規表現パターンを使用して確実に検出できます。誤った分類につながる正規表現の検出エラーは、Cloud Data Loss Prevention API(DLP API)などのより高度なツールを使用して最小限に抑えることができます。

自由形式の非構造化データの機密データ

機密データは、テキスト レポート、録音、写真、スキャンされた領収書など、自由形式の非構造化データとして存在することがあります。これらのデータセットでは、機密データを識別するのがかなり難しくなりますが、役立つツールが数多くあります。

  • フリーテキスト ドキュメントの場合は、自然言語処理システム(Cloud Natural Language API など)を使用して、エンティティ、メールアドレス、およびその他の機密データを識別できます。
  • 録音の場合は、音声入力サービス(Cloud Speech API など)を使用し、その後、自然言語プロセッサを適用できます。
  • 画像の場合、テキスト検出サービス(Cloud Vision API など)を使用して、画像から生のテキストを取得し、画像内のテキストの位置を切り出すことができます。Vision API は、画像内の一部のターゲット アイテムの位置座標を提供できます。たとえば、この情報を使用して、レジの行列の画像のすべての顔をマスクしてから、機械学習モデルをトレーニングして平均顧客待ち時間を見積もることができます。
  • 動画の場合、各動画を個々の画像フレームに解析して画像ファイルとして扱うことができます。また、Cloud Video Intelligence API などの動画処理ツールを Cloud Speech API とともに使用して、音声を処理することもできます。

ただし、これらの手法は、顧問弁護士の審査と承認を受ける必要があり、また該当するシステムがどの程度までフリーテキストの処理、音声の変換、画像の理解、動画の分割を行うことで、潜在的な機密データを識別できるかによって異なります。上に示した Google API と Cloud DLP は、前処理パイプラインに組み込むことができる強力なツールです。ただし、これらの自動化された方法は完全ではなく、除去後に残っている機密情報を処理するためのガバナンス ポリシーの整備を検討することが必要になります。

複数のフィールドを組み合わせた機密データ

機密データは、フィールドの組み合わせとして存在することや、保護されたフィールドの時間の経過に伴う傾向から明らかになることがあります。たとえば、ユーザーを識別する可能性を減らすための標準的な方法は、郵便番号の最後の 2 桁をぼかして、5 桁から 3 桁に減らすことです(zip3)。ただし、勤務先に関連付けられた zip3 と自宅住所に関連付けられた zip3 の組み合わせは、自宅と勤務先の組み合わせが一般的でないユーザーの識別には十分である可能性があります。同様に、時間の経過に伴う zip3 の自宅住所の傾向は、複数回転居した個人の識別に十分である場合があります。

頻度分析攻撃に対してデータセットが本当に保護されているかどうかを特定するには、統計に関する専門知識が必要です。人間の専門家に依存するシナリオには、スケーラビリティの課題があります。逆説的ですが、生データの潜在的な問題を調査するために、同じデータ エンジニアがデータを除去する必要がある場合があります。理想的には、このリスクを識別し、数値化するための自動化された方法を作成します(この記事ではこのタスクについて説明しません)。

いずれにしても、弁護士およびデータ エンジニアと協力して、これらのシナリオでのリスクの可能性を評価する必要があります。

非構造化コンテンツの機密データ

コンテキスト情報が埋め込まれているため、非構造化コンテンツに機密データが存在することがあります。たとえば、チャットの記録に「昨日、私のオフィスから電話しました。4 階は携帯電話の電波が弱いので、18 階の Cafe Deluxe Espresso の横のロビーに行ったのです」というフレーズがあるとします。

トレーニング データのコンテキストと範囲、および弁護士のアドバイスに基づいて、このコンテンツの一部をフィルタリングする必要がある場合があります。非構造化という特性と、フレーズの組み合せが大量で複雑になることから、類似した推定が可能になるため、これはプログラマティックなツールによる対処が難しいシナリオですが、非構造化データセット全体へのアクセスに関するガバナンスの強化を検討する価値はあります。

モデル開発の場合、通常、信頼できる個人が除去および確認したデータのサブサンプルを取得し、モデル開発に利用できるようにすると効果的です。その後、セキュリティ制限とソフトウェア自動化を使用して、本番環境モデル トレーニング プロセスを通じて完全なデータセットを処理できます。

機密データの保護

機密データを識別したら、そのデータを保護する方法を決定する必要があります。

機密データの削除

プロジェクトでユーザー固有の情報を必要としない場合は、それらの情報をすべてデータセットから削除してから、ML モデルを構築するデータ エンジニアにデータセットを提供することを検討してください。ただし、前述のように、機密データを削除するとデータセットの価値が大幅に低下する場合があります。このような場合、「機密データのマスキング」セクションで説明した手法を 1 つ以上使用して機密データをマスクする必要があります。

機密データを削除するには、データセットの構造によって異なるアプローチが必要です。

  • データが構造化データセットの特定の列に限定されている場合、該当する列へのアクセスを提供しないビューを作成できます。データ エンジニアがデータを表示することはできませんが、同時に、データは「ライブ」であり、継続的なトレーニングのために人間が介入してデータを非特定化する必要がありません。
  • 機密データが非構造化コンテンツの一部であるが、既知のパターンを使用して識別可能な場合、自動的に削除して汎用文字列に置き換えることができます。Cloud DLP がこの方法で課題に対応します。
  • 画像、動画、音声、または非構造化自由形式データ内に機密データが存在する場合は、デプロイしたツールを拡張して機密データを識別し、マスクしたり削除したりできます。
  • フィールドの組み合わせのために機密データが存在し、自動ツールまたは手動データ分析ステップを組み込んで各列のリスクを数値化している場合、データ エンジニアは関連する列の保持または削除に関して、情報に基づいた意思決定を行うことができます。

機密データのマスキング

機密データ フィールドを削除できない場合でも、データ エンジニアがマスクされた形式のデータを使用して効果的なモデルをトレーニングできる可能性があります。データ エンジニアが、ML トレーニングに影響を与えることなく、機密データ フィールドの一部またはすべてをマスクできると判断した場合、いくつかの手法を使用してデータをマスクできます。

  • 最も一般的なアプローチは、書式なしテキスト識別子のすべての出現をそのハッシュ値または暗号化された値、あるいはその両方に置き換える代入暗号を使用することです。一般的には、強力な暗号化ハッシュ(たとえば SHA-256)または強力な暗号化アルゴリズム(たとえば AES-256)を使用してすべての機密フィールドを格納することがベスト プラクティスとして受け入れられています。暗号化にソルトを使用すると繰り返し可能な値が作成されず、ML トレーニングにとって弊害となることに注意が必要です。

  • トークン化は、各機密フィールドに格納されている実際の値を無関係のダミー値で置き換えるマスキング手法です。ダミー値と実際の値とのマッピングは、より安全な完全に異なるデータベースで暗号化 / ハッシュされます。この方法が ML データセットに対して機能するのは、同じトークン値が同じ値に対して再利用される場合のみであるので注意してください。この場合、これは代入暗号に類似しており、頻度分析攻撃に対して脆弱です。主な違いは、トークン化では、暗号化された値を別のデータベースに push することにより、保護が強化されることです。

  • 複数列のデータを保護する別の方法は、主成分分析(PCA)または他の次元削減手法を使用して複数の特徴を結合してから、結果の PCA ベクトルに対してのみ ML トレーニングを実施するというものです。たとえば、3 つの異なるフィールド age、smoker(1 または 0 で表されます)、body-weight がある場合に、データを 1 つの PCA 列にまとめて計算式 1.5age+30smoker+0.2*body-weight. を使用することが考えられます。20 歳で喫煙し、体重が 140 ポンド(63.5 kg)の個人の場合、値 88 が生成されます。これは、30 歳で喫煙せず、体重が 215 ポンド(97.5 kg)の個人の場合に生成される値と同じ値です。

    なんらかの形でユニークな個人を識別した場合でも、PCA ベクトル式の説明なしにその個人をユニークにしている要素を特定することが困難であるため、この方法は非常に堅牢となります。ただし、すべての PCA 処理によってデータの分布が削減され、精度と引き換えにセキュリティが確保されます。

前述のように、異なる識別子が出現する一般的な頻度を事前に把握して、さまざまな暗号化された識別子の実際の出現状況から推定を導出することで、代入暗号を解読することが可能になる場合があります。たとえば、赤ちゃんの名前の一般公開データセットにおける名前の分布を使用して、特定の暗号化された識別子に対する、可能性の高い一連の名前を推定することができます。悪意のある者が完全なデータセットにアクセスする可能性があることを考えると、暗号化、ハッシング、トークン化は頻度分析攻撃に対して脆弱です。一般化と数値化は、代入において多対 1 のマッピングを使用し、対応する推定はわずかに弱くなりますが、依然として頻度分析攻撃に対して脆弱です。機械学習データセットには多数の対応する変数があるため、頻度分析攻撃は発生の同時確率を使用でき、潜在的に暗号解読が容易になります。

したがって、機密データを含む可能性のあるすべての機械学習データセットへのアクセスを制限するために、すべてのマスキング方法を、効果的な監査およびガバナンス メカニズムと組み合わせる必要があります。これには、すべての機密フィールドが抑制、暗号化、数値化、または一般化されたデータセットが含まれます。

機密データのあいまい化

あいまい化は、データの精度や粒度を低下させることでデータセット内の機密データの特定を困難にする一方で、あいまい化する前のデータを使用したモデルのトレーニングと比較しても、同等の利点がある手法です。次のフィールドは、このアプローチに特に適しています。

  • 場所。人口密度は世界中で異なるため、位置座標をどの程度丸めるべきかについての簡単な答えはありません。たとえば、1 桁精度(-90.3、およそ 10 km 以内など)に丸められた小数点ベースの緯度と経度は、大規模な農場がある農村部の居住者の特定には十分である可能性があります。座標の丸めでは十分でない場合は、市区町村、州、郵便番号などのロケーション識別子を使用できます。これらは、はるかに広い地域をカバーするため、1 名の個人を区別することはより困難になります。1 つの行に固有の特性を適切に難読化するのに十分な大きさのバケットサイズを選択します。
  • 郵便番号。5+4 形式の米国の郵便番号は世帯を特定できますが、最初の 3 桁(zip3)のみが含まれるようにあいまい化できます。これにより、多くのユーザーを同じバケットに入れることによって、特定のユーザーを識別する機能が制限されます。ただし、非常に大規模なデータセットでは、より巧妙な攻撃が可能になるため、このリスクを定量化することが有益である場合があります。
  • 数量。数字は、個人を特定する可能性を低くするためにビニングできます。たとえば、通常、正確な生年月日ではなく、誕生年を含む 10 年または誕生月のみを必須とします。したがって、年齢、生年月日などの数値フィールドは、範囲を代入することであいまい化できます。
  • IP アドレス。IP アドレスは、アプリケーション ログを含む機械学習ワークフローの一部であることが多く、機密性の点で物理的住所と同様に扱われることがよくあります。あいまい化の手法としては、IPv4 アドレスの最後のオクテット(IPv6 を使用する場合は最後の 80 ビット)をゼロで埋めることをおすすめします。これには、緯度や経度を丸める、住所を郵便番号のみにする、などの処理を行い、地理的な精度と引き換えに保護を強化することと同じ効果があります。IP アドレスのあいまい化は、パイプラインのできるだけ早い段階に組み込みます。ディスクに IP アドレスを書き込む以前に、IP アドレスをマスクするか非表示にするよう、ロギング ソフトウェアを変更できる可能性もあります。

ガバナンス ポリシーの確立

データセットに機密データが含まれている場合は、弁護士に相談して、ガバナンス ポリシーとベスト プラクティスのドキュメントを作成することをおすすめします。ポリシーの詳細は、制定者が決定します。PCI Security Standards Council の Best Practices for Maintaining PCI DSS Complianceここで参照できる ISO/IEC 27001:2013 のセキュリティ手法要件など、数多くのリソースを利用できます。次のリストも、ポリシー フレームワークを確立する際に考慮できるいくつかの共通のコンセプトを示しています。

  • ガバナンス ドキュメントのための安全な場所を確保します。
  • 暗号化キー、ハッシュ関数、またはその他のツールをドキュメントから除外します。
  • 機密データが受信される、すべての既知のソースを文書化します。
  • 格納されている機密データのすべての既知の所在地、および存在するデータの種類を文書化します。データを保護するために行われたすべての改善手順を含めます。
  • 改善手順が困難、整合性がない、または不可能な機密データの既知の所在地を文書化します。これにより、頻度分析攻撃が使用される可能性があると思われる状況に対応します。
  • 機密データの新しいソースを継続的にスキャンおよび識別するプロセスを確立します。
  • 機密データへの一時的または永続的なアクセス権を付与された役割と(場合によっては)個々の従業員の名前を文書化します。そのアクセスが必要になった理由を含めます。
  • 従業員が機密データへのアクセスをリクエストするプロセスを文書化します。機密データにアクセスできる場所、機密データをコピーできるかどうか、コピー方法、コピー場所、アクセスに関連するその他の制限事項を指定します。
  • 誰がどの機密データにアクセスできるかを定期的に見直して、アクセスが必要かどうかを判断するプロセスを確立します。脱退プロセスの一環として、従業員が退職したり役割が変化したりした場合の対処方法の概要を示します。
  • ポリシーを伝達し、実施して、定期的にレビューするプロセスを確立します。

次のステップ