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

项目
2025-04-21

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

注意

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

个人数据处理策略

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

筛选、模糊处理、匿名化或调整收集的数据，以通过数据收集转换将其避免视作“个人数据”。这是目前为止的首选方法，这样就无需创建非常昂贵且影响很大的数据处理策略。
规范化数据以减轻对数据平台和性能造成的负面影响。例如，不记录显式用户 ID，而是创建查找，将用户名及其详细信息关联到可随后在其他位置记录的内部 ID。这样，如果某个用户要求删除其个人信息，则你只需删除查找表中对应于该用户的行即可。
如果需要收集个人数据：
- 使用 “删除数据 API ”或 “清除 API ”和 “查询 API ”导出和删除与用户关联的任何个人数据。
- 使用摘要规则删除或模糊处理新表中的个人数据，以便更广泛地共享，并通过管理表级读取访问权限来限制对包含个人数据的表的访问。

在 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' //RegEx originally provided on https://stackoverflow.com/questions/5284147/validating-ipv4-addresses-with-regexp
| 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 使用一个对象来指定要删除的数据的参数，并返回一个引用 GUID。

获取清除状态 POST API 返回一个“x-ms-status-___location”标头，你可以调用其中包含的 URL 来确定清除操作的状态。例如：

x-ms-status-___location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/Microsoft.OperationalInsights/workspaces/[WorkspaceName]/operations/purge-[PurgeOperationId]?api-version=2015-03-20

注意

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

后续步骤

详细了解 Azure Monitor 中的安全性。
详细了解 Application Insights 如何收集、处理和保护数据。

通过