機密データの保護では、情報タイプ(infoType)を使用してスキャンする対象を定義します。infoType は、名前、メールアドレス、電話番号、識別番号、クレジット カード番号などの機密データのタイプを表します。infoType 検出器は、infoType の一致条件で照合する検出メカニズムです。
infoType の使用方法
機密データの保護では、スキャンの構成に含まれる infoType 検出器を使用して、検査の対象と検査結果の変換方法が決定されます。infoType の名前は、スキャン結果の表示や報告時にも使用されます。
たとえば、テキスト ブロックでメールアドレスを検索する場合は、検査構成で EMAIL_ADDRESS
infoType 検出器を指定します。テキスト ブロックのメールアドレスを秘匿化する場合は、検査構成と匿名化構成の両方で EMAIL_ADDRESS
を指定し、そのタイプを秘匿化または変換する方法を示します。
さらに、組み込みの infoType 検出器とカスタム infoType 検出器を組み合わせて、スキャン結果からメールアドレスのサブセットを除外することもできます。まず、INTERNAL_EMAIL_ADDRESS
というカスタム infoType を作成し、内部テスト用メールアドレスを除外するように構成します。次に、EMAIL_ADDRESS
の結果を含めるようにスキャンを設定しますが、INTERNAL_EMAIL_ADDRESS
に一致する結果を除外する除外ルールを含めることができます。カスタム infoType 検出器の除外ルールやその他の機能の詳細については、カスタム infoType 検出器の作成をご覧ください。
機密データの保護には、名前で指定する一連の組み込み infoType 検出器が用意されています。それぞれについては、infoType 検出器リファレンスにリストされています。これらの検出器では、さまざまな手法を使用して各タイプを検出し、分類します。たとえば、パターン一致が必要なタイプ、数学的なチェックサムがあるタイプ、特別な数字制限があるタイプ、検出結果に特定の接頭辞またはコンテキストがあるタイプが存在します。
例
コンテンツをスキャンするように機密データの保護を設定する場合は、スキャンの構成で使用する infoType 検出器を指定します。
たとえば、次の JSON とコードサンプルは、DLP API への単純なスキャン リクエストを示しています。inspectConfig
で PHONE_NUMBER
検出器が指定されています。これは機密データの保護に対して、指定された文字列内で電話番号をスキャンするように指示しています。
C#
機密データの保護用のクライアント ライブラリをインストールして使用する方法については、機密データの保護のクライアント ライブラリをご覧ください。
機密データの保護のために認証するには、アプリケーションのデフォルト認証情報を設定します。 詳細については、ローカル開発環境の認証の設定をご覧ください。
Go
機密データの保護用のクライアント ライブラリをインストールして使用する方法については、機密データの保護のクライアント ライブラリをご覧ください。
機密データの保護のために認証するには、アプリケーションのデフォルト認証情報を設定します。 詳細については、ローカル開発環境の認証の設定をご覧ください。
Java
機密データの保護用のクライアント ライブラリをインストールして使用する方法については、機密データの保護のクライアント ライブラリをご覧ください。
機密データの保護のために認証するには、アプリケーションのデフォルト認証情報を設定します。 詳細については、ローカル開発環境の認証の設定をご覧ください。
Node.js
機密データの保護用のクライアント ライブラリをインストールして使用する方法については、機密データの保護のクライアント ライブラリをご覧ください。
機密データの保護のために認証するには、アプリケーションのデフォルト認証情報を設定します。 詳細については、ローカル開発環境の認証の設定をご覧ください。
PHP
機密データの保護用のクライアント ライブラリをインストールして使用する方法については、機密データの保護のクライアント ライブラリをご覧ください。
機密データの保護のために認証するには、アプリケーションのデフォルト認証情報を設定します。 詳細については、ローカル開発環境の認証の設定をご覧ください。
Python
機密データの保護用のクライアント ライブラリをインストールして使用する方法については、機密データの保護のクライアント ライブラリをご覧ください。
機密データの保護のために認証するには、アプリケーションのデフォルト認証情報を設定します。 詳細については、ローカル開発環境の認証の設定をご覧ください。
REST
JSON 入力:
POST https://dlp.googleapis.com/v2/projects/[PROJECT-ID]/content:inspect?key={YOUR_API_KEY}
{
"item":{
"value":"My phone number is (415) 555-0890"
},
"inspectConfig":{
"includeQuote":true,
"minLikelihood":"POSSIBLE",
"infoTypes":{
"name":"PHONE_NUMBER"
}
}
}
指定されたエンドポイントに上記のリクエストを送信すると、機密データの保護は次を返します。
JSON 出力:
{
"result":{
"findings":[
{
"quote":"(415) 555-0890",
"infoType":{
"name":"PHONE_NUMBER"
},
"likelihood":"VERY_LIKELY",
"location":{
"byteRange":{
"start":"19",
"end":"33"
},
"codepointRange":{
"start":"19",
"end":"33"
}
},
"createTime":"2018-10-29T23:46:34.535Z"
}
]
}
}
実行する検出器を正確に制御し、予測可能にする必要がある場合は、リファレンスに一覧表示された特定の infoType を指定します。指定しない場合、機密データの保護はデフォルトのリストを使用します。これは時間とともに変化する可能性があります。デフォルトの infoType のスキャンは、スキャンするコンテンツの量によって所要時間またはコストが大幅に増大する可能性があります。
infoType 検出器を使用してコンテンツをスキャンする方法の詳細については、入門ガイドの検査、秘匿化、匿名化に関するトピックをご覧ください。
確実性とテスト
検出結果は、可能性と呼ばれる確実性スコアで報告されます。可能性スコアは、検出結果が対応するタイプと一致する可能性を示します。たとえば、タイプがパターンにのみ一致する場合は低い可能性を返します。タイプがパターンに一致し、正のコンテキストがある場合は高い可能性を返します。このため、1 つの検出結果が低い可能性で複数のタイプと一致する場合があります。また、適切に一致しない場合またはコンテキストが負の場合は、結果が表示されない、または確実性が低下する可能性があります。たとえば、指定した infoType の構造と一致するものの、infoType のチェックサムに失敗した場合は、結果が報告されないことが考えられます。ある結果が複数の infoType に一致しても、そのうちの 1 つを優先するコンテキストがあれば、そのタイプについてのみ報告されます。
さまざまな検出器をテストする場合、架空またはサンプルデータは報告に十分なチェックを通過しないため、報告されません。
infoType 検出器の種類
機密データの保護には、いくつかの種類の infoType 検出器があります。ここではすべての種類について概要を説明します。
- 組み込みの infoType 検出器は、機密データの保護に組み込まれています。国またはリージョンに固有の機密データのタイプと、世界中のどこでも適用できるデータタイプに対応する検出器が含まれています。
- カスタム infoType 検出器は、ユーザー自身が作成する検出器です。カスタム infoType 検出器には、次の 3 種類があります。
- 小規模なカスタム辞書検出器は、機密データの保護に対応する単純な単語リストです。含まれる単語やフレーズの数が数万個までのリストでは、小規模なカスタム辞書検出器を使用します。単語リストが大幅に変更される予定がない場合、小規模なカスタム辞書検出器の使用をおすすめします。
- 大規模なカスタム辞書検出器は、Cloud Storage または BigQuery に保存されている単語やフレーズの大規模なリストを使用して、機密データの保護によって生成されます。含まれる単語やフレーズの数が数千万個までの大規模なリストでは、大規模なカスタム辞書検出器を使用します。
- 正規表現(regex)検出器により、機密データの保護を使用して正規表現パターンに基づいて一致を検出できます。
さらに、機密データの保護には、検査ルールのコンセプトも組み込まれており、次の検査ルールを使用してスキャン結果を細かく調整できます。
- 除外ルールを適用すると、組み込みまたはカスタムの infoType 検出器にルールを追加することで、返される結果の数を少なくできます。
- 起動ワードルールを適用すると、組み込みまたはカスタムの infoType 検出器にルールを追加することで、返される結果の数を増やすことや、結果の可能性の値の変更ができます。
組み込みの infoType 検出器
組み込みの infoType 検出器は機密データの保護に組み込まれています。この種類には、国や地域に固有の機密データタイプに対応する検出器が含まれています。機密データタイプとしては、フランスの国民登録番号(NIR)(FRANCE_NIR
)、英国の運転免許証番号(UK_DRIVERS_LICENSE_NUMBER
)、米国の社会保障番号(US_SOCIAL_SECURITY_NUMBER
)などがあります。また、個人名(PERSON_NAME
)、電話番号(PHONE_NUMBER
)、メールアドレス(EMAIL_ADDRESS
)、クレジット カード番号(CREDIT_CARD_NUMBER
)などの、世界のどこにも適用できるデータタイプもあります。infoType に対応する内容を検出するために、機密データの保護ではパターン マッチング、チェックサム、機械学習、コンテキスト解析などのさまざまな手法を活用します。
組み込みの infoType 検出器のリストは常に更新されています。現在サポートされている組み込みの infoType の全リストについては、infoType 検出器リファレンスをご覧ください。
組み込みの infoType 検出器の全リストは、機密データの保護の infoTypes.list
メソッドを呼び出して表示することもできます。
組み込みの infoType 検出器は、100% 正確な検出方法ではありません。たとえば、これらの検出器によって法令要件の遵守を保証することはできません。どのデータが機密であるか、それを保護する最善の方法は何かを決めるのは、お客様の責任です。構成が要件を確実に満たしているかどうか、設定内容を検証することをおすすめします。
言語対応
国固有の infoType は、英語と各国の言語に対応しています。ほとんどのグローバル対応の infoType は複数の言語で動作します。お客様のデータで機密データの保護をテストし、要件を満たしていることを確認します。
カスタムの infoType 検出器
カスタム infoType 検出器には、次の 3 種類があります。
さらに、機密データの保護には検査ルールも含まれています。検査ルールを利用すると、既存の検出器に次のルールを追加することでスキャン結果を細かく調整できます。
小規模なカスタム辞書検出器
小規模なカスタム辞書検出器(「標準のカスタム辞書検出器」とも呼ばれます)を使用して、最大でも数万個の単語またはフレーズを含む小規模のリストを照合します。小規模なカスタム辞書は、この辞書独自の一意の検出器として使用できます。
カスタム辞書検出器は、正規表現や組み込みの検出器で簡単に照合できない単語やフレーズのリストをスキャンする場合に役立ちます。たとえば、会議室をスキャンする場合に、会議室が通常、番号ではなく割り当てられている名前(都道府県名や地域名、ランドマーク、架空の文字など)で呼ばれているとします。こうした会議室名のリストを含めて、小規模なカスタム辞書検出器を作成できます。機密データの保護は、各会議室名の内容をスキャンし、コンテキスト内でいずれかの会議室名が検出されると一致を返します。機密データの保護で辞書の単語とフレーズを照合する方法については、標準のカスタム辞書検出器の作成の「辞書の照合の詳細」セクションをご覧ください。
小規模なカスタム辞書 infoType 検出器の働きと実際の使用例については、標準のカスタム辞書検出器の作成をご覧ください。
大規模なカスタム辞書検出器
大規模なカスタム辞書検出器(「保存済みカスタム辞書検出器」とも呼ばれます)は、スキャンする単語またはフレーズの数が 2~3 個を超える場合、または単語あるいはフレーズのリストが頻繁に変更される場合に使用します。大規模なカスタム辞書検出器では、最大で数千万個もの単語やフレーズに対する照合ができます。
大規模なカスタム辞書検出器は、正規表現のカスタム検出器と小規模なカスタム辞書検出器のどちらとも異なる方法で作成されます。大規模なカスタム辞書には、それぞれ次の 2 つのコンポーネントがあります。
- 作成、定義するフレーズのリスト。このリストは、Cloud Storage 内のテキスト ファイルまたは BigQuery テーブル内の列として保存されます。
- 生成された辞書ファイル。フレーズリストに基づいて機密データの保護によって生成されます。辞書ファイルは Cloud Storage に保存され、ソースフレーズ データのコピーと、検索やマッチングに役立つブルーム フィルタで構成されます。辞書ファイルは直接編集できません。
単語リストを作成し、機密データの保護を使用してカスタム辞書を生成したら、他の infoType 検出器と同様の方法で、大規模なカスタム辞書検出器を使用するスキャンを開始またはスケジュールします。
大規模なカスタム辞書検出器の働きと実際の使用例については、格納されるカスタム辞書検出器の作成をご覧ください。
正規表現
正規表現(regex)カスタム infoType 検出器を使用すると、機密データの保護で正規表現パターンに基づいて一致を検出するための独自の infoType 検出器を作成できます。たとえば、###-#-#####
という形式のカルテ番号があるとします。この場合、次のような正規表現パターンを定義できます。
[1-9]{3}-[1-9]{1}-[1-9]{5}
機密データの保護では、次のような項目が照合されます。
123-4-56789
各カスタム infoType の一致に割り当てる可能性を指定することもできます。つまり、機密データの保護で順序が指定したシーケンスと一致すると、ユーザーが指定した可能性が割り当てられます。これは、カスタム正規表現によって定義されたシーケンスが一般性の度合いが高く、他のランダムなシーケンスと容易に一致する場合に有効です。そのような場合に、機密データの保護によってすべての一致に VERY_LIKELY
のラベルを付けると、スキャン結果の信頼性が損なわれ、誤った情報が一致し、匿名化するおそれがあります。
正規表現のカスタム infoType 検出器の詳細と実際の使用例については、カスタム正規表現検出器の作成をご覧ください。
検査ルール
検査ルールを使用して、既存の infoType 検出器(組み込みまたはカスタム)によって返される結果を細かく調整できます。既存の infoType 検出器でルールを追加および除外することで、機密データの保護から返される結果を適切な内容にする必要がある場合に、検査ルールが有効です。
検査ルールには 2 種類あります。
- 除外ルール
- 起動ワードルール
検査ルールの詳細については、スキャン結果を絞り込むための infoType 検出器の変更をご覧ください。
除外ルール
除外ルールを適用すると、組み込みまたはカスタムの infoType 検出器にルールを追加することで、返される結果の数を少なくしたり精度を低くしたりできます。除外ルールを適用すると、infoType 検出器によって返される結果に含まれるノイズや不要な内容を少なくできます。
たとえば、メールアドレスのデータベースをスキャンする場合、除外ルールをカスタムの正規表現の形式で追加することで、末尾が「@example.com」の結果を除外するように機密データの保護に指示できます。
除外ルールの詳細については、スキャン結果を絞り込むための infoType 検出器の変更をご覧ください。
起動ワードルール
起動ワードルールを適用すると、組み込みまたはカスタムの infoType 検出器にルールを追加することで、返される結果の数を増やしたり精度を高くしたりできます。ホットワード ルールによって、既存の infoType 検出器のルールを効果的に緩和できます。
たとえば、医療データベースで患者名をスキャンするとします。機密データの保護の組み込み PERSON_NAME
infoType 検出器を使用できますが、その場合、機密データの保護では、患者名だけでなくすべての人の名前が一致してしまいます。これを修正するには、起動ワードルールを正規表現のカスタム infoType の形式で組み込んで、一致候補の最初の文字から特定の文字の近接性の範囲内で単語「患者」を探します。このパターンに一致した結果は特殊な基準を満たしているので、可能性として「very likely」を割り当てることができます。
起動ワードルールの詳細については、スキャン結果を絞り込むための infoType 検出器の変更をご覧ください。
例
infoType の結果に対する一致の仕方を理解するには、次の例をご覧ください。一連の数字に対する一致の例を確認して、米国社会保障番号を構成しているか、米国個人納税者番号を構成しているかを判断します。これらの例は、組み込みの infoType 検出器を対象としていることに注意してください。カスタム infoType 検出器を作成する場合は、スキャン一致の可能性を決定する基準を指定します。
例 1
"SSN 222-22-2222"
次の理由により、US_SOCIAL_SECURITY_NUMBER
に対して高い可能性スコア VERY_LIKELY
を報告します。
- 標準的な社会保障番号の形式であるため、確実性が高まります。
- コンテキスト(SSN)が近くにあり、
US_SOCIAL_SECURITY_NUMBER
に対して優先順位が上がります。
例 2
"999-99-9999"
次の理由により、US_SOCIAL_SECURITY_NUMBER
に対して低い可能性スコア VERY_UNLIKELY
を報告します。
- 標準形式であるため、確実性が高まります。
- 社会保障番号が 9 から始まることはないため、確実性が低下します。
- コンテキストが欠けているため、確実性が低下します。
例 3
"999-98-9999"
次の理由により、US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER
に対して POSSIBLE
、US_SOCIAL_SECURITY_NUMBER
に対して VERY_UNLIKELY
の可能性スコアを報告します。
US_SOCIAL_SECURITY_NUMBER
とUS_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER
の両方の標準形式があります。- 9 で始まり、別の数字チェックがあるので
US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER
の確実性が高まります。 - コンテキストが欠けているため、両方の確実性が低下します。
次のステップ
機密データの保護チームは、新しい infoType 検出器とグループを定期的にリリースしています。組み込み infoType の最新の一覧を取得する方法については、組み込みの infoType 検出器の一覧表示をご覧ください。