既知の問題

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

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 タイムスタンプであることを確認してください。 ただし、機密データの保護が最近ストリーミングされたデータから読み取ることはないため、行がスキップされないという保証はありません。

列のコミット タイムスタンプを自動生成し、以前のストリーミング 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 のスキャン

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

Strict XLSX ファイルの検査はサポートされていません

.xlsx 拡張子のファイルには、次の 2 種類があります。1 つは Strict Office Open XML スプレッドシートで、Sensitive Data Protection ではサポートされていません。もう 1 つのタイプは、サポートされているデフォルトの Microsoft Excel ワークブックです。

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

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

区切りファイルの匿名化

検査ジョブで区切り文字で区切られたファイル（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 標準の補助多言語面の文字を含む辞書の単語は、予期しない結果になる可能性があります。そのような文字の例には、絵文字、科学記号、歴史的な文字などがあります。

除外ルール

除外ルールはオブジェクトの infoType には適用できません。