機密データの保護では、情報タイプ(infoType)を使用してスキャンする対象を定義します。infoType は、名前、メールアドレス、電話番号、識別番号、クレジット カード番号などの機密データのタイプを表します。infoType 検出器は、infoType の一致条件で照合する検出メカニズムです。
infoType を選択する際のベスト プラクティス
データを保護するうえで、まず重要なのはデータを把握することです。ベスト プラクティスとして、ビジネスニーズがある情報のみを収集、保存、処理する必要があります。処理しているデータを特定することで、ビジネス、ユーザー、データ セキュリティとプライバシーの対策について、情報に基づいた意思決定を行うことができます。
ビジネスのユースケースによっては、特定の機密情報が必要な場合もあれば、そうでない場合もあります。すべてのユースケースをサポートする単一のソリューションは存在しません。このため、Sensitive Data Protection では、スキャンするデータの種類を柔軟に制御できます。匿名化またはマスキングに infoType を使用している場合は、データの変換のタイミングと方法も制御できます。
一般的なガイドライン
infoType を選択する際は、次の一般的なガイドラインを考慮してください。
収集する必要のない機密情報
ビジネス内の各サービスは、そのサービスに必要なデータのみを収集する必要があります。たとえば、ビジネスの特定のサービスでは、財務情報を収集する必要はありません。このようなサービスでは、CREDIT_CARD_NUMBER
、FINANCIAL_ACCOUNT_NUMBER
などの infoType 検出器や、業界カテゴリ FINANCE
の他の infoType を有効にすることを検討してください。
収集する必要はあるものの、チーム全体で共有したくない情報
個人情報の収集には有効なユースケースがあるかもしれませんが、チーム全体で共有すべきではありません。たとえば、サポート チケットを送信したお客様から連絡先情報を提供された場合、問題を解決するためにお客様に連絡できます。チケットを表示するチームの全員に個人情報(PII)を表示したくない。タイプ カテゴリ PII
の PHONE_NUMBER
、EMAIL_ADDRESS
などの infoType 検出機能を有効にすることを検討してください。
業界、データ プライバシー、または地域の規制の対象となるセンシティブ データのカテゴリ
特定の情報の種類は、発行方法や使用目的が原因で機密情報と見なされます。その他のケースでは、コンテキスト情報とユーザー属性情報は保護対象カテゴリと見なされます。このような情報の収集、使用、管理には、追加の制限が適用される場合があります。次のカテゴリで infoType 検出器を有効にすることを検討してください。
類似する infoType の選択
類似の infoType 検出器を選択する際は、次の点を考慮してください。
パスポート
特定の国のパスポートの識別子をスキャンする必要がない場合は、汎用検出機能 PASSPORT
を選択します。
UK_PASSPORT
などの特定の国固有のパスポート検出機能が使用できます。ただし、国固有のパスポートの検出機能によっては、特定の形式のパスポートで、コンテキストに応じた手がかりが存在する場合にのみ、パスポートを識別できる場合があります。
個人名
人名をスキャンする場合は、ほとんどのユースケースで FIRST_NAME
または LAST_NAME
ではなく PERSON_NAME
を使用します。
PERSON_NAME
は人名の検出機能です。単語の名前やフルネームを含めることができます。この検出機能は、自然言語理解などのさまざまなテクノロジーを使用して、Jane、Jane Smith、Jane Marie Smith などの名前を検出しようとします。FIRST_NAME
と LAST_NAME
は、名前の一部を識別しようとするこの検出機能のサブセットです。これらの検出機能の検出結果は、常に PERSON_NAME
の検出結果のサブセットです。
日付と時刻
すべての日付をスキャンする必要がない場合は、DATE_OF_BIRTH
などのターゲット日付検出機能の使用を検討してください。この検出機能は、日付が個人の生まれた日付に関連していることを示すコンテキストを特定しようとします。
DATE
検出機能は、コンテキストに関係なくすべての日付を検出しようとします。また、今日や昨日などの相対日付もフラグが立てられます。同様に、TIME
はすべてのタイムスタンプを検索しようとします。
場所
すべてのロケーションをスキャンする必要がない場合は、LOCATION
検出機能の代わりに STREET_ADDRESS
の使用を検討してください。STREET_ADDRESS
検出機能は、完全修飾された住所を検出しようとします。通常、完全修飾された住所は一般的な場所よりも正確で、より機密性が高いと見なされます。
LOCATION
infoType 検出機能は、コンテキストに関係なく、任意の場所(パリやカナダなど)を検出しようとします。
コンテキストを必要とする InfoType 検出器
多くの infoType 検出機能では、一致を特定する前にコンテキスト上の手がかりが必要です。組み込みの infoType 検出器が、フラグが立てられると想定される項目にフラグを立てない場合は、その項目の近くにコンテキスト上の手がかりがないためです。代わりに GENERIC_ID
またはカスタム infoType 検出器の使用を検討してください。
業界共通の定義がない情報タイプ
一部の情報の種類には、業界共通の定義がありません。たとえば、カルテ番号、口座番号、PIN、セキュリティ コードなどです。これらのタイプの場合は、GENERIC_ID
、FINANCIAL_ACCOUNT_NUMBER
、MEDICAL_RECORD_NUMBER
などの infoType の使用を検討してください。これらの検出機能は、エンティティ検出とコンテキストを組み合わせて、機密性の高い可能性のある要素を見つけます。
レイテンシの高い infoType 検出器
不要な infoType 検出器は有効にしないでください。以下は特定のシナリオで有用ですが、これらの infoType により、リクエストの実行速度がこれらを含まないリクエストよりもはるかに遅くなる可能性があります。
PERSON_NAME
FEMALE_NAME
MALE_NAME
FIRST_NAME
LAST_NAME
DATE_OF_BIRTH
LOCATION
STREET_ADDRESS
ORGANIZATION_NAME
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 リストを使用します。デフォルトのリストは、ユースケースに適していない場合があります。
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 は、英語と各国の言語に対応しています。ほとんどのグローバル対応の 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 検出器の一覧表示をご覧ください。