在 Azure Monitor 日志中管理个人数据

Azure Monitor 日志是一种数据存储，可在其中找到个人数据。 本文介绍 Azure Monitor 日志存储个人数据的位置以及如何管理此数据。

注意

若要了解如何查看或删除个人数据，请参阅 GDPR 的常规数据主体请求、GDPR 的 Azure 数据主体请求或 GDPR 的 Windows 数据主体请求，具体取决于实际领域和需求。 有关 GDPR 的详细信息，请参阅 Microsoft 信任中心的 GDPR 部分和服务信任门户的 GDPR 部分。

个人数据处理策略

下面从技术角度，按优先程度从高到低的顺序列出了几种方法，不过，处理个人数据的策略最终需要将由你和你的公司决定：

  • 通过使用 数据收集转换，对收集的数据进行过滤、模糊处理、匿名化或调整，使其不被视为“个人”数据。 这种方法 是迄今为止 最好的选择，可节省创建成本高昂且有影响力的数据处理策略的需求。
  • 规范化数据以减少对数据平台和性能的负面影响。 例如，不要直接记录明确的用户 ID，而应创建一个映射关系，将用户名及其详细信息与内部 ID 关联起来，并在其他位置记录该内部 ID。 如果用户要求删除其个人信息，则只能删除与用户相对应的查阅表格中的行。
  • 如果需要收集个人数据：

在 Azure Monitor 日志中查找个人数据的位置

Azure Monitor 日志为数据指定架构，但允许使用自定义值替代每个字段。 你也可以引入自定义架构。 因此，无法准确说明特定工作区中是否存在个人数据。 但是，不妨从清单中的以下位置着手。

注意

本文中的某些查询使用search *来查询工作区中的所有表。 一般情况下，强烈建议您尽量避免使用search *，因为这会导致极低效的查询。 请改为查询特定的表。

  • IP 地址：Log Analytics 收集多个表中的各种 IP 信息。 例如，以下查询显示收集了过去 24 小时内的 IPv4 地址的所有表：

    search *
| where * matches regex @'\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}\b' // Match IPv4 addresses
| summarize count() by $table

  • 用户 ID：可以在各种解决方案和表中查找用户用户名和用户 ID。 使用搜索命令在整个数据集中查找特定的用户名或用户 ID：

    search "<username or user ID>"

    请记住，不仅要查找用户可读的用户名，还要查找可追溯到特定用户的 GUID。

  • 设备 ID：与用户 ID 一样，设备 ID 有时被视为个人数据。 使用用户 ID 所述的方法来标识保存个人数据的表。

  • 自定义数据：Azure Monitor 日志允许通过自定义日志、自定义字段、 日志引入 API 以及作为系统事件日志的一部分收集自定义数据。 检查所有自定义数据中是否包含个人数据。

  • 解决方案捕获的数据：由于解决方案机制是开放式的，因此建议查看解决方案生成的所有表以确保合规。

导出、删除或清除个人数据

在收集个人数据之前，请查看 “个人数据处理策略 ”部分。 使用数据收集转换筛选、模糊处理或匿名化数据是首选方法，并避免了此处所述的成本。 在处理个人数据时，在定义和自动化策略、构建客户与其数据交互的接口以及持续维护方面会产生成本。 Log Analytics 和 Application Insights 的计算成本也很高，并发查询、删除数据或清除 API 调用大量会对与 Log Analytics 功能的其他所有交互产生负面影响。 但是，如果必须收集个人数据，请遵循本部分所述的准则。

注意

删除或清除数据不会影响计费。 若要控制数据保留成本，请配置 数据保留设置。

查看和导出个人数据

使用Log Analytics 查询 API发送视图请求和数据导出请求。 Log Analytics 查询 API 不支持使用基本和辅助表计划的表。 对于这些表，请改用 搜索 API 。

需要实现一个逻辑用于将数据转换为适合提供给用户的格式。 Azure Functions 是托管此类逻辑的好地方。

删除个人数据

使用 Azure Monitor 日志删除数据 API，可以发出异步请求，以删除 Log Analytics 工作区中特定表的数据。 请谨慎使用“删除数据”操作，以避免潜在的风险、性能影响，以及可能导致 Log Analytics 数据中整体聚合、度量和其他方面失衡的情况。 有关处理私人数据的替代方法，请参阅个人数据处理策略部分。

如果需要符合一般数据保护条例（GDPR）要求，请使用 清除 API，该 API 性能较低，仅支持符合 GDPR 所需的作。

警告

删除和彻底清除操作是破坏性的且不可逆！ 在执行时要格外小心。

清除个人数据

Azure Monitor 的 清除 API 允许根据 GDPR 的要求清除个人数据。 清除 API 的性能低于 删除数据 API。 Azure Monitor 建议使用“删除数据 API”，并仅授权执行 GDPR 合规性所需的清除请求。

为了管理系统资源，服务将清除请求限制为每小时 50 个请求。 可以通过发送一条命令并在其谓词中包含所有需要清除的用户标识，来批量执行清除请求。 使用 in 运算符来指定多个标识。 在执行清除请求之前运行查询，以验证预期结果。

重要

虽然大多数清除操作的完成速度要快得多，但由于其对所用数据平台造成的严重影响，在完成清除操作方面的正式 SLA 设置为 30 天。 此 SLA 可满足 GDPR 要求。 这是一个自动化过程，因此无法加快操作速度。

所需的权限

行动 所需的权限
从 Log Analytics 工作区中清除数据 对 Log Analytics 工作区的 Microsoft.OperationalInsights/workspaces/purge/action 权限，由 Log Analytics 参与者和数据清除者内置角色提供

清除日志数据

  • 工作区清除 POST API 接受表名称和筛选器，用于标识要清除的数据。 它返回响应 202 Accepted 。 x-ms-status-location响应标头包含用于检查操作状态的 URL。
  • 向 GET 标头中的 x-ms-status-location URL 发送请求。 获取清除状态 API 返回清除操作的状态。

注意

不能从具有基本和辅助表计划的表中清除数据。

后续步骤

  • Last updated on