文档PII积累问题
内部知识库——Confluence、Notion、SharePoint、GitBook——积累了一种特定类型的PII问题，这种问题几乎对标准合规工具是不可见的：用于流程文档的截图中嵌入的客户个人数据。
这种情况在成千上万的支持和运营团队中上演：
一名支持代理发现了一个不寻常的账户配置。他们截图了客户的账户页面，以记录正在编写的知识库文章中的问题。截图中包含了客户姓名在用户界面头部、他们的电子邮件地址在账户设置中，以及他们的订阅详情。
知识库文章被发布到内部维基。150名支持代理现在可以访问它。12名在外部帮助台工作的承包商可以访问它。该文章是处理边缘案例的有用文档。
三年后，知识库中有847篇这样的文章。每篇文章都包含客户账户的截图。出现在截图中的客户账户数据没有得到这些客户的同意。大多数人不知道他们的数据出现在内部维基中。
GDPR暴露：为什么这不是一个小问题
内部文档截图的GDPR分析：
数据最小化（第5条第1款（c））： 个人数据必须是“适当的、相关的，并限于必要的范围。”关于账户配置边缘案例的知识库文章并不需要真实客户的姓名和电子邮件地址。一个经过处理的截图（客户姓名模糊）同样可以满足文档目的。包含真实客户数据并不是必要的。
目的限制（第5条第1款（b））： 为一个目的（客户服务互动）收集的个人数据不能在没有法律依据的情况下重新用于另一个目的（内部流程文档）。客户的账户数据是为了提供服务而收集的，而不是为了记录内部边缘案例。
访问控制（第5条第1款（f）和第32条）： 必须采取适当的技术措施来保护个人数据。可供所有150名代理和承包商访问的维基中的客户账户截图——包括那些可能无法访问基础客户账户系统的人——代表了对个人数据的不当广泛访问。
删除权（第17条）： 请求删除其个人数据的数据主体有权在“没有不当延误”的情况下被删除。如果他们的数据出现在23篇知识库文章中作为嵌入的截图，则删除请求需要找到并处理所有23篇文章——在没有系统检测的情况下，这是一项操作上困难的任务。
访问控制绕过
维基截图最显著的合规问题是它们创建的访问控制绕过。
支持组织通常使用RBAC来控制谁可以访问客户账户系统。一级代理访问基本账户信息。二级代理访问账单和技术细节。经理和管理员访问完整的账户资料。
当二级代理创建一篇包含完整客户账户资料截图的知识库文章时，该截图对所有维基用户可访问——包括不应访问账单详情的一级代理、根本没有系统访问权限的承包商，以及在入职期间的新员工。
该截图绕过了客户账户系统上的RBAC控制。RBAC旨在保护的个人数据现在对所有有维基访问权限的人可访问。
实际补救：追溯性和前瞻性
对于在GDPR审计中发现此问题的组织：
追溯性补救：
- 识别所有包含图像附件的内部维基页面
- 对所有图像附件运行图像PII检测
- 处理结果：对高置信度PII检测的图像进行标记以供审查
- 对于标记的图像：要么用经过处理的版本替换，要么为维基页面添加适当的访问控制
- 记录补救措施以备GDPR问责记录
追溯性补救的规模取决于知识库的大小。对于一个有50人支持团队的三年知识库，图像数量可能达到数千。批量图像处理使其可行；关键瓶颈是对标记图像的人为审查。
前瞻性控制：
- 流程文档：所有支持团队成员接受培训，以在维基使用前处理截图
- 技术支持：截图注释工具（在粘贴前模糊客户姓名）
- 审查步骤：指定审查员在发布前批准维基文章，特别检查图像中的客户PII
- 定期审计：每季度对所有维基附件进行批量图像PII扫描
最低可行控制（对于资源有限的团队）： 一个维基发布检查清单，包括“在发布前删除或模糊所有客户姓名、电子邮件和账户ID”。低技术、非自动化，但创建了控制的文档。
为什么问题随着时间的推移而恶化
在没有系统控制的情况下，内部维基PII问题随着时间的推移而加剧：
数量： 每个新知识库文章中包含客户截图都会增加总PII暴露。随着支持团队的增长和知识库的扩展，积累的PII成比例增长。
被遗忘的文章： 记录不再发生的旧边缘案例的文章可能在维基中被遗忘，但仍然可访问——包含了已经提交删除请求的客户的PII。
跨团队传播： 知识库经常变得跨职能。一篇包含客户截图的支持文章可能会与产品团队、工程团队或外部承包商共享，作为功能请求或错误报告的背景。
删除权积压： 随着更多客户数据在维基中积累，响应删除请求变得更加复杂。在没有系统检测的情况下，没有可靠的方法来确认所有数据主体的信息实例都已被识别和删除。
对于GDPR合规性，一致的发现是，知识库PII更容易预防而不是补救。前瞻性控制——现在实施——可以避免指数增长的补救问题。
来源：