既知の問題

このページには、機密データの保護の既知の問題とともに、以下の問題を回避する方法や問題から復旧する方法が記載されています。

一般的な問題

BigQuery に結果を保存する

ジョブまたは検出スキャンの結果が BigQuery に保存されているときに、Already exists エラーがログに記録されます。このエラーは、問題があることを示すものではありません。結果は予期したとおりに保存されます。

BigQuery のスキャン

このセクションでは、BigQuery データを検査またはプロファイリングを実施する際に発生する可能性のある問題について説明します。

検査とプロファイリングのオペレーションに共通の問題

次の問題は、BigQuery 検査オペレーションとプロファイリング オペレーションの両方に適用されます。

行レベルのセキュリティが適用される行はスキャン不能

行レベルのセキュリティ ポリシーを使用すると、機密データの保護が、保護されている BigQuery テーブルを検査してプロファイリングするのを回避できます。 行レベルのセキュリティ ポリシーを BigQuery テーブルに適用している場合は、TRUE フィルタを設定し、譲受人リストにサービス エージェントを含めることをおすすめします。

重複する行

BigQuery テーブルにデータを書き込む場合、機密データの保護によって重複する行が書き込まれることがあります。

最近ストリーミングされたデータ

機密データの保護は、最近ストリーミングされたデータ（旧称ストリーミング バッファ）をスキャンしません。詳細については、BigQuery ドキュメントのストリーミング データの可用性をご覧ください。

BigQuery 検査に関する問題

次の問題は、BigQuery データに対する検査オペレーションにのみ適用されます。データ プロファイルには影響しません。

エクスポートされた検出結果に row_number フィールドの値がない

検出結果を BigQuery に保存するように機密データの保護を構成すると、入力テーブルのスキャン時に、生成された BigQuery テーブルの location.content_locations.record_location.record_key.big_query_key.row_number フィールドが推定されます。この値は非決定的であり、クエリされません。また、検査ジョブの場合は null になる場合があります。

結果が存在する特定の行を識別する必要がある場合は、ジョブの作成時に inspectJob.storageConfig.bigQueryOptions.identifyingFields を指定します。

識別するフィールドは、生成された BigQuery テーブルの location.content_locations.record_location.record_key.id_values フィールドで確認できます。

スキャンを新しい BigQuery コンテンツに制限する

スキャンを新しいコンテンツのみに制限し、BigQuery Storage Write API を使用して入力テーブルに入力している場合、機密データの保護が一部の行のスキャンをスキップする可能性があります。

この問題を軽減するには、検査ジョブで、TimespanConfig オブジェクトの timestampField が、BigQuery が自動生成する commit タイムスタンプであることを確認してください。 ただし、機密データの保護が最近ストリーミングされたデータから読み取ることはないため、行がスキップされないという保証はありません。

列の commit タイムスタンプを自動生成し、従来のストリーミング API を使用して入力テーブルにデータを入力する場合は、次の操作を行います。

  1. 入力テーブルのスキーマで、タイムスタンプ列の型が TIMESTAMP であることを確認します。

    サンプル スキーマ

    次の例では、commit_time_stamp フィールドを定義し、そのタイプを TIMESTAMP に設定しています。

    ...
{
 "name": "commit_time_stamp",
 "type": "TIMESTAMP"
}
...

  2. tabledata.insertAll メソッドの rows[].json フィールドで、タイムスタンプ列の値が AUTO に設定されていることを確認します。

    JSON の例

    次の例では、commit_time_stamp フィールドの値を AUTO に設定しています。

    {
  ...
  "commit_time_stamp": "AUTO",
  ...
}

最大割合または最大行数を設定してスキャンを制限する

テーブル行の合計数（rowsLimitPercent）に対する割合に基づいてサンプリング制限を設定すると、機密データの保護によって予想よりも多くの行を検査できます。スキャンする行数にハードリミットが必要な場合は、代わりに最大行数（rowsLimit）を設定することをおすすめします。

BigQuery プロファイリングに関する問題

次の問題は、BigQuery データに対するプロファイリング オペレーションにのみ適用されます。詳細については、BigQuery データのデータ プロファイルをご覧ください。

5 億テーブルを超える組織またはプロジェクト

5 億を超えるテーブルがある組織またはプロジェクトをプロファイリングしようとすると、Sensitive Data Protection はエラーを返します。このエラーが発生した場合は、エラー メッセージに記載されている手順に沿って操作します。

組織のテーブル数が 5 億を超え、テーブル数が少ないプロジェクトがある場合は、プロジェクト レベルのスキャンを実行します。

テーブルと列の上限については、データ プロファイリングの上限をご覧ください。

検査テンプレート

検査テンプレートは、プロファイリングするデータと同じリージョンに存在する必要があります。複数のリージョンにデータがある場合は、複数の検査テンプレート（データがあるリージョンごとに 1 つ）を使用します。global リージョンに保存されている検査テンプレートを使用することもできます。global リージョンにテンプレートを含めると、機密データの保護はリージョン固有のテンプレートのないデータにそれを使用します。詳細については、データ所在地に関する検討事項をご覧ください。

格納される infoType

検査テンプレートで参照される格納される infoType（格納されるカスタム辞書検出器とも呼ばれる）は、次のいずれかに格納する必要があります。

  • global リージョン。
  • 検査テンプレートと同じリージョン。

そうしないと、プロファイリング オペレーションはエラーResource not foundで失敗します。

リソースの可視性

テーブルデータ プロファイルでは、BigQuery テーブルに適用されるリソースの公開設定の分類は、テーブルの公開設定ではなく、テーブルを含むデータセットの公開設定によって異なります。したがって、テーブルの IAM 権限がデータセットの IAM 権限と異なる場合、データプロファイルに示されるテーブルのリソースの公開設定が正しくない場合もあります。この問題は、BigQuery の検出と Vertex AI の検出に影響します。

Google Cloud コンソールで、リソースの公開設定はテーブルデータ プロファイルの [公開] フィールドに表示されます。Cloud Data Loss Prevention API では、リソースの公開設定は TableDataProfile の resourceVisibility フィールドに示されます。

Cloud Storage のスキャン

このセクションでは、データを検査または匿名化する際に発生する可能性のある問題について説明します。

大規模なカスタム辞書検出器を使用した XLSX ファイルの検査

大規模なカスタム辞書検出器（格納されるカスタム辞書検出器とも呼ばれる）を使用して Microsoft Excel .xlsx ファイルを検査する場合は、検査ジョブの実行速度が遅くなり、停止しているように見え、大量の Cloud Storage クラス B オペレーションが発生する可能性があります。これは、機密データの保護によって .xlsx ファイル内のセルごとに大規模なカスタム辞書のソース用語リストが読み取られる可能性があるためです。読み取りオペレーションの量によって、機密データの保護の検査ジョブの進行状況がほとんどなくなり、停止しているように見えることがあります。

関連する Cloud Storage 請求料金の詳細については、オペレーション料金のクラス B オペレーションの料金をご覧ください。

バイナリモードでスキャンされる構造化ファイル

一般的に構造化解析モードでスキャンされるファイルがバイナリモードでスキャンされる場合がありますが、これには構造化解析モードの拡張機能は含まれてません。詳細については、構造化解析モードで構造化ファイルをスキャンするをご覧ください。

区切りファイルの匿名化

検査ジョブで区切り文字で区切られたファイル（CSV ファイルなど）を匿名化すると、出力の一部の行に空のセルが増えることがあります。これらの余分なセルを回避する回避策として、代わりに content.deidentify メソッドを使用してデータを匿名化します。

Cloud SQL の検出

Security Command Center の重複する検出結果

Cloud SQL データ プロファイリングは、検出結果を Security Command Center に公開することをサポートしています。

2024 年 4 月 25 日より前は、バグにより、Sensitive Data Protection が Security Command Center で Cloud SQL インスタンスの重複する検出結果を生成することがあります。これらの検出結果は、一意の検出 ID で生成されていますが、同じ Cloud SQL インスタンスに関連しています。この問題は解決されましたが、重複する検出結果が引き続き存在します。重複する検出結果はミュートして、Security Command Center の [検出結果] ページに表示されないようにすることができます。

Amazon S3 の検出

機密データ保護が Security Command Center に送信する Amazon S3 の検出結果には、影響を受けるリソースの AWS アカウント ID または表示名に関する情報が含まれていない場合があります。これは通常、次の場合に発生します。

  • 検出結果が Security Command Center に送信された時点で、AWS コネクタは有効になってから約 24 時間しか経過していませんでした。
  • 検出結果が Security Command Center に送信された時点で、AWS アカウントは AWS コネクタに約 24 時間しか含まれていませんでした。

この問題を解決するには、約 24 時間後に、データ プロファイルを削除するか、プロファイリング スケジュールを設定して、データ プロファイルを再生成します。検出結果の詳細がすべて Security Command Center に送信されます。

インテリジェントなドキュメント解析

このセクションでは、ドキュメントの解析に関連する既知の問題について説明します。

DocumentLocation オブジェクトにデータが入力されていない

インテリジェント ドキュメント解析スキャンモードでは、location.content_locations.document_location.file_offset フィールドに値が入力されません。

検出

Unicode 標準の補助多言語面の文字を含む辞書の単語は、予期しない結果になる可能性があります。そのような文字の例には、絵文字、科学記号、歴史的な文字があります。