已知问题

本页面列出了敏感数据保护的已知问题，以及可以避免或解决以下问题的方法。

将结果存储到 BigQuery

当作业或发现扫描将结果存储到 BigQuery 时，日志中会显示 Already exists 错误。此错误并不表示存在问题；您的结果将按预期存储。

BigQuery 扫描

本部分介绍了在检查或分析 BigQuery 数据时可能会遇到的问题。

检查和分析操作的常见问题

以下问题同时适用于 BigQuery 检查和分析操作。

无法扫描具有行级安全性的行

行级安全政策可能会阻止敏感数据保护功能检查受保护的 BigQuery 表并对其进行分析。 如果您的 BigQuery 表应用了行级安全政策，建议您设置 TRUE 过滤条件，并将服务代理添加到被授权者列表中：

重复行

将数据写入 BigQuery 表时，敏感数据保护功能可能会写入重复的行。

最近流式传输的数据

Sensitive Data Protection 不会扫描最近流式传输的数据（以前称为流缓冲区）。如需了解详情，请参阅 BigQuery 文档中的流式数据可用性。

BigQuery 检查问题

以下问题仅适用于对 BigQuery 数据执行的检查操作。它们不会影响数据剖析文件。

导出的发现结果中 row_number 字段没有值

当您配置 Sensitive Data Protection 以将发现结果保存到 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 自动生成的提交时间戳。不过，我们仍无法保证不会跳过任何行，因为 Sensitive Data Protection 不会读取最近流式传输的数据。

如果您想为列自动生成提交时间戳，并且使用旧版流式传输 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) 设置抽样限制时，Sensitive Data Protection 可能会检查比预期更多的行。如果您需要对扫描的行数设置硬性限制，建议改为设置最大行数 (rowsLimit)。

BigQuery 剖析问题

以下问题仅适用于对 BigQuery 数据执行的分析操作。如需了解详情，请参阅 BigQuery 数据的数据剖析文件。

拥有超过 5 亿个表的组织或项目

如果您尝试对拥有超过 5 亿个表的组织或项目进行数据分析，敏感数据保护将返回错误。如果您遇到此错误，请按照错误消息中的说明操作。

如果您的组织拥有超过 5 亿个表，但您有些项目的表数量较少，则请尝试执行项目级层扫描。

如需了解表和列的限制，请参阅数据剖析限制。

检查模板

检查模板必须与要剖析的数据位于同一区域。如果您的数据位于多个区域，请使用多个检查模板，每个区域对应一个。您还可以使用存储在 global 区域中的检查模板。如果您在 global 区域中添加了模板，Sensitive Data Protection 会将该模板用于没有区域特定模板的任何数据。如需了解详情，请参阅数据驻留注意事项。

存储的 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 的文件可以是以下两种类型之一。一种是严格的 Office Open XML 电子表格，敏感数据保护功能不支持这种格式。 另一种类型是受支持的默认 Microsoft Excel 工作簿。

以二进制模式扫描的结构化文件

在某些情况下，通常以结构化解析模式扫描的文件可能会以二进制模式扫描，而二进制模式不包含结构化解析模式的增强功能。如需了解详情，请参阅在结构化解析模式下扫描结构化文件。

对分隔文件进行去标识化

使用检查作业对分隔符分隔的文件（例如 CSV 文件）进行去标识化时，输出结果中某些行的单元格可能会额外为空。为了避免出现这些额外的单元格，一种解决方法是改用 content.deidentify 方法来对数据进行去标识化处理。

Cloud SQL 的 Discovery

Security Command Center 重复的发现结果

Cloud SQL 数据分析支持将检测结果发布到 Security Command Center。

在 2024 年 4 月 25 日之前，一个 bug 导致敏感数据保护服务偶尔会在 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。