既知の問題

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

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 を 使用して入力テーブルに入力している場合、Sensitive Data Protection が一部の行のスキャンをスキップする可能性があります。

この問題を軽減するには、検査ジョブで、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 では、リソースの可視性は resourceVisibility の TableDataProfileフィールドに示されます。

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 の検出

Sensitive Data Protection が 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 標準の補助 多言語面の文字を含む辞書の単語は、予期しない検出結果になる可能性があります。このような文字の例には、絵文字、科学記号、歴史的なスクリプトがあります。