你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
在 Azure Monitor Logs 和 Application Insights 中管理个人数据
Log Analytics 是一种可能存有个人数据的数据存储。 Application Insights 将其数据存储在 Log Analytics 分区中。 本文解释 Log Analytics 和 Application Insights 存储个人数据的位置，以及如何管理这些数据。
在本文中，日志数据指的是发送到 Log Analytics 工作区的数据，而应用程序数据指的是 Application Insights 收集的数据。 如果你使用的是基于工作区的 Application Insights 资源，请参阅有关日志数据的信息。 如果你使用的是经典 Application Insights 资源，请参阅有关应用程序数据的信息。
注意
若要了解如何查看或删除个人数据，请参阅 GDPR 的常规数据主体请求、GDPR 的 Azure 数据主体请求或 GDPR 的 Windows 数据主体请求，具体取决于实际领域和需求。 有关 GDPR 的详细信息，请参阅 Microsoft 信任中心的 GDPR 部分和服务信任门户的 GDPR 部分。
所需的权限
| 操作 | 所需的权限 |
|---|---|
| 从 Log Analytics 工作区中清除数据 | 对 Log Analytics 工作区具有 Microsoft.OperationalInsights/workspaces/purge/action 权限，例如，Log Analytics 参与者内置角色所提供的权限 |
个人数据处理策略
下面从技术角度，按优先程度从高到低的顺序列出了几种方法，不过，处理个人数据的策略最终需要将由你和你的公司决定：
- 停止收集个人数据，或模糊处理、匿名处理或调整收集的数据，以避免将其视为“个人”数据。 这是目前为止的首选方法，这样就无需创建非常昂贵且影响很大的数据处理策略。
- 规范化数据以减轻对数据平台和性能造成的负面影响。 例如，不记录显式用户 ID，而是创建查找以将用户名及其详细信息关联到可随后在其他位置记录的内部 ID。 这样，如果某个用户要求删除其个人信息，则你只需删除查找表中对应于该用户的行即可。
- 如果需要收集个人数据，请使用清除 API 路径和现有查询 API 路径制定一个流程，以履行有关导出和删除任何与用户关联的个人数据的任何义务。
在 Log Analytics 中的何处查找个人数据
Log Analytics 规定了数据的架构，但允许使用自定义值替代每个字段。 你也可以引入自定义架构。 因此，无法确切知道可在特定工作区的哪些位置找到个人数据。 但是，不妨从清单中的以下位置着手。
注意
以下某些查询使用 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 查找方法来识别包含个人数据的表。
自定义数据：Log Analytics 允许通过自定义日志、自定义字段、HTTP 数据收集器 API 收集自定义数据并将其收集为系统事件日志的一部分。 检查所有自定义数据是否包含个人数据。
解决方案捕获的数据：由于解决方案机制是开放式的，因此建议查看解决方案生成的所有表以确保合规。
应用程序数据
IP 地址：虽然 Application Insights 在默认情况下会将所有 IP 地址字段模糊处理成
0.0.0.0，但为了保留会话信息，它通常会将此值替代为实际的用户 IP。 使用以下查询查找“IP 地址”列在过去 24 小时内包含的值不是0.0.0.0的任何表：search client_IP != "0.0.0.0" | where timestamp > ago(1d) | summarize numNonObfuscatedIPs_24h = count() by $table用户 ID：默认情况下，Application Insights 在 session_Id、user_Id、user_AuthenticatedId、user_AccountId 和 customDimensions 等字段中使用随机生成的 ID 进行用户和会话跟踪。 但是，这些字段通常会替代为与应用程序更相关的 ID，例如用户名或 Microsoft Entra GUID。 这些 ID 通常被视为个人数据。 我们建议对这些 ID 进行模糊处理或匿名处理。
自定义数据：Application Insights 允许向任何数据类型追加一组自定义维度。 使用以下查询来识别过去 24 小时内收集的自定义维度：
search * | where isnotempty(customDimensions) | where timestamp > ago(1d) | project $table, timestamp, name, customDimensions内存中和传输中数据：Application Insights 跟踪异常、请求、依赖项调用和跟踪。 你通常会在代码和 HTTP 调用级别找到个人数据。 查看异常、请求、依赖项和跟踪表中是否存在任何此类数据。 尽可能使用遥测初始值设定项来混淆该数据。
Snapshot Debugger 捕获：当 Application Insights 在应用程序的生产实例上检测到异常时，你可以使用 Application Insights 中的 Snapshot Debugger 功能收集调试快照。 快照会公开导致异常的完整堆栈跟踪，以及堆栈中每一步的本地变量的值。 遗憾的是，此功能不允许选择性地删除贴靠点，也不允许以编程方式访问快照中的数据。 因此，如果默认的快照保留率不满足合规性要求，我们建议关闭此功能。
导出和删除个人数据
我们强烈建议重新构建数据收集策略以停止收集个人数据、模糊处理或匿名处理个人数据，或以其他方式修改此类数据，直到它不再被视为个人数据。 在处理个人数据时，定义和自动化策略、构建可供客户用来与其数据交互和持续进行维护的界面会产生成本。 此外，Log Analytics 和 Application Insights 的计算成本很高，大量并发查询或清除 API 调用可能会对与 Log Analytics 功能的所有其他交互产生负面影响。 但是，如果必须收集个人数据，请遵循本部分所述的准则。
重要
虽然大多数清除操作的完成速度要快得多，但由于其对所用数据平台造成的严重影响，在完成清除操作方面的正式 SLA 设置为 30 天。 此 SLA 可满足 GDPR 要求。 这是一个自动化过程，因此无法加快操作速度。
查看和导出
对于查看和导出数据请求，请使用 Log Analytics 查询 API 或 Application Insights 查询 API。
注意
不能使用具有基本和辅助表计划的 Log Analytics 查询 API。 请改用 Log Analytics /search API。
需要实现一个逻辑用于将数据转换为适合提供给用户的格式。 Azure Functions 是托管此类逻辑的好地方。
删除
警告
Log Analytics 中的删除操作具有破坏性且不可逆！ 执行时请特别小心。
Azure Monitor 的清除 API 让你可以删除个人数据。 请慎用清除操作，以避免出现潜在的风险和性能影响，以及 Log Analytics 数据的整个聚合、度量和其他方面发生偏差的可能性。 有关处理私人数据的替代方法，请参阅个人数据处理策略部分。
清除是一项高特权操作。 出于数据丢失的可能性，请在 Azure 资源管理器中谨慎授予数据清除器角色。
为了管理系统资源，我们将清除请求数限制为每小时 50 个。 可以通过发送一条命令并在其谓词中包含所有需要清除的用户标识，来批量执行清除请求。 使用 in 运算符来指定多个标识。 在执行清除请求之前运行查询，以验证预期结果。
重要
使用 Log Analytics 或 Application Insights 清除 API 不会影响保留成本。 为了降低保留成本，必须缩短数据保留期。
日志数据
工作区清除 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
注意
不能从具有基本和辅助表计划的表中清除数据。
应用程序数据
组件 - 清除 POST API 使用一个对象来指定要删除的数据的参数，并返回一个引用 GUID。
组件 - 获取清除状态 GET API 返回一个“x-ms-status-location”标头，你可以调用其中包含的 URL 来确定清除操作的状态。 例如：
x-ms-status-location: https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/providers/microsoft.insights/components/[ComponentName]/operations/purge-[PurgeOperationId]?api-version=2015-05-01