OneNym代理 ID 与令牌
引用订单与会员。
减少直接存储个人信息。
ONENYM PLATFORM / 技术设计
完成必要操作，
减少个人信息共享。
不再在企业之间复制个人信息，
而是在受限访问下执行获准操作。
OneNym Platform 结合代理 ID、令牌、授权与独立保险库，将个人信息与业务系统分离，并将使用限制在必要用途内。
01 / 架构
分离身份、权限与数据。
业务系统处理代理 ID 和令牌。读取与处理须经过独立授权。个人信息保存在独立保险库中，减少跨系统副本。
请求操作
↓
↓
仅允许获准操作
验证请求方、用途、记录与有效期。
拒绝超出授权范围的请求。
限制为必要信息
↓
↓
数据保险库
管理个人信息及映射关系。
返回结果或有限字段。
此图为概念示意。代理 ID 与个人信息的映射同样属于需要保护的敏感信息。
02 / 四个组成部分
通过设计减少暴露。
01 / PROXY IDENTITY
代理 ID
使用各服务专属标识符引用个人，而非传递个人信息。不同服务使用独立 ID，可减少关联分析与追踪的机会。
考量：租户及服务隔离、不可预测的 ID、轮换、删除与映射访问限制。
02 / TOKENIZATION
令牌化
以用途限定的引用令牌替代地址或邮箱，管理获准操作、有效期及使用次数。
考量：被盗令牌的滥用、重复使用限制、撤销及谁可解析令牌。简单哈希并不能使数据匿名化。
03 / PERMISSIONS
访问权限
逐操作检查条件，例如允许 A 公司为配送使用该订单地址一次。不仅检查登录状态，还要确认谁可处理哪些数据、用于何种目的。
考量：租户隔离、用途、范围、有效期、撤销、管理与审计。技术权限不同于用户同意或合同依据。
04 / DATA VAULT
数据保险库
将个人信息与业务记录分离，仅经受限路径提供。共同设计加密、密钥管理、管理权限、备份与删除，并根据部署环境使用 Azure Key Vault、AWS KMS 等云密钥服务。
考量：密钥与数据分离、租户边界、恢复、可用性、审计及留存。集中式保险库本身可能成为高价值攻击目标。
03 / 集成示例
无需保存地址，即可请求配送。
这是零售商与配送服务商的设计示例。服务商集成、数据保管及使用依据需另行设计与约定。
在保险库登记必要数据
登记收货地址，向零售商返回与订单关联的代理 ID。设计绕过零售商服务器和日志的输入路径。
签发用途限定令牌
按订单、承运商与有效期限制令牌。零售商传递令牌，而非地址。
授权配送服务商
验证服务商身份及令牌范围，仅返回获准的配送数据。
执行到期与撤销
授权到期或被撤销后停止后续访问。已读取地址的删除取决于服务商的操作及约定。
零售商留存记录示例
订单 ID、代理 ID、配送令牌与配送状态。
减少直接留存的数据示例姓名、邮编及地址。账单与客服所需留存内容应另行确定。
TECHNICAL DEEP DIVE
了解具体实施设计。
阅读标识符映射、授权、加密密钥与删除的具体示例。
04 / 局限与考量
减少留存只是解决方案的一部分。
代理 ID 也需要保护
可识别或关联个人的 ID 和令牌不会自动匿名化。需妥善管理存储与访问。
已读取的数据可能留存
撤销访问不会删除已经生成的副本或日志。合作方需要留存与删除政策。
可用性与职责
部署时约定故障影响、恢复、职责、数据位置及留存期限。
实施前的设计决策
明确身份验证、授权、密钥、审计日志、留存、删除、故障行为及迁移。API 与集成范围取决于系统和业务流程。
FROM EXPOSURE TO ARCHITECTURE
从了解数据流开始。
Exposure Test 可评估当前访问个人信息的路径。
联系我们，讨论如何减少个人信息留存。