处理敏感数据
在实现 OpenTelemetry 时,必须高度关注敏感数据的处理。 遥测数据的采集始终存在无意中捕获敏感或个人信息的风险,而这些信息可能受到各种隐私法规和合规性要求的约束。
你的责任
OpenTelemetry 会收集遥测数据,但无法自行判断在你的具体上下文中哪些数据是敏感的。 作为实现者,你需要承担以下责任:
- 确保遵守适用的隐私法律和法规。
- 保护遥测数据中的敏感信息。
- 获取数据采集所需的必要同意。
- 实施适当的数据处理和存储实践。
此外,你还需要理解并审查你所使用的任何自动插桩库所生成的遥测数据,因为这些库同样可能会收集并暴露敏感信息。
敏感数据的考量
哪些数据属于敏感数据会因场景不同而有所差异,例如:
- 个人可识别信息(PII)
- 认证凭据
- 会话令牌
- 财务信息
- 与健康相关的数据
- 用户行为数据
数据最小化
在通过遥测收集可能包含敏感信息的数据时, 应遵循数据最小化原则。这意味着:
- 只收集对可观测性有明确用途的数据。
- 除非绝对必要,否则避免收集个人信息。
- 考虑是否可以通过聚合或匿名化的数据来达到相同目的。
- 定期审查已收集的属性,确保它们仍然是必要的。
保护敏感数据
如前一节所述,防止收集敏感数据的最佳方式是不去收集任何可能是敏感的数据。然而, 在某些情况下你可能确实需要收集这些数据,或者你并不能完全控制所收集的数据, 因此需要在后处理阶段对数据进行清洗。以下建议可以帮助你实现这一点。
OpenTelemetry Collector 提供了多种处理器,可用于管理敏感数据:
attribute处理器: 删除或修改特定属性。filter处理器: 过滤掉包含敏感数据的整个 span 或指标。redaction处理器: 删除 span、日志和指标数据点中不在允许属性列表内的属性。transform处理器: 使用正则表达式对数据进行转换。
删除和哈希化用户信息
下面是一个 attribute 处理器的配置示例,用于对 user.email 进行哈希处理,并从敏感的
user 信息中删除 user.full_name:
processors:
attributes/example:
actions:
- key: user.email
action: hash
- key: user.full_name
action: delete
使用 user.hash 替换 user.id
下面是一个 transform 处理器的配置示例,用于移除 user.id,并将其替换为 user.hash:
transform:
trace_statements:
- context: span
statements:
- set(attributes["user.hash"], SHA256(attributes["user.id"]))
- delete_key(attributes, "user.id")
对用户的 ID 或姓名进行哈希处理,可能无法提供你所需要的匿名化程度。因为在实践中, 如果输入空间较小且可预测(例如纯数字的用户 ID),哈希是可以被反向推断的。
截断 IP 地址
作为哈希处理的替代方案,你也可以对数据进行截断,或按共同的前缀或后缀进行分组。例如:
- 日期:只保留年份,或年份和月份,丢弃具体的日期。
- 电子邮件地址:去掉本地部分,仅保留域名。
- IP 地址:去掉 IPv4 的最后一个八位组,或 IPv6 的最后 80 位。
下面是一个 transform 处理器的配置示例,用于删除 client.address 属性中 IPv4 地址的最后一个八位组:
transform:
trace_statements:
- context: span
statements:
- replace_pattern(attributes["client.address"], "\\.\\d+$", ".0")
使用 redaction 处理器删除属性
最后,关于使用 redaction 处理器删除特定属性的示例,可以参考 Collector 配置安全最佳实践页面中的
“清洗敏感数据”章节。
意见反馈
这个页面对您有帮助吗?
Thank you. Your feedback is appreciated!
Please let us know how we can improve this page. Your feedback is appreciated!