企业身份管理的架构思考与实践

有意识地进行身份管理

最近我有机会参加一个关于企业身份管理的研讨会，并希望分享一些意外有用的思考。

身份是一个难以捉摸的概念，它既有现实世界的锚点，在数字世界中又可能是多面且复杂的。无论是现实世界还是数字身份都高度依赖于上下文环境，在这两个领域中，为了管理便利和跨上下文重用，人们往往倾向于简化身份，却没有考虑到这对身份主体以及组织使用该身份进行交易的影响。

如果在创建身份时没有充分考虑身份特性，最终将导致更大的不确定性、更高的复杂性，并最终给整个组织带来更大的风险。

创建身份时需要考虑多个上下文特性，在重用为不同产品或服务创建的身份时，必须考虑这些特性，否则可能会陷入困境。

这描述了身份预期使用的位置，可能转化为哪些产品或服务将依赖此身份。我们还需要思考：- 我们需要创建它吗？- 我们可以让其他组织创建它吗？- 我们可以让其他组织使用它吗？

身份的不同用途会有不同要求。了解某人在队列中的位置是临时的，不需要个人数据属性，而在法庭上定罪某人则需要不同强度的身份确认。

身份所需的强度（丰富性、置信度、有效性或验证）将取决于其预期服务的用途。创建过于强大的身份可能会吓跑潜在客户，而创建弱验证身份可能会限制身份的未来重用，需要在用户旅程中提升验证级别以进行更高风险的交易（如支付）。

创建身份的法律基础很重要；既包括身份可以合法使用的用途，也包括身份的下游共享以及依赖你创建或传输身份的其他组织可能带来的潜在责任。

某些身份比其他身份更敏感。没有人希望自己的个人数据属性被泄露，但对于躲避施虐者的家庭暴力受害者，或对于有家庭的外勤卧底警察来说，这些身份特性一旦添加到身份中，就会变得极其敏感。这不仅会影响组织在身份存储方面应实施的安全约束级别，还会限制这些身份可以共享的程度。

虽然不建议创建具有当前不需要特性的身份，同时也强调可能没有法律依据这样做，但值得考虑身份在整个企业产品和服务套件中的生命周期。应尽早寻找机会在客户旅程中尽量减少重用的风险，并减少客户必须经历的身份变更次数。

强烈建议将上表中的特性映射到每个产品和服务，然后将每个特性映射到它们在客户旅程中的位置，以明确依赖关系和风险，从而对创建和重用管理的客户身份做出有意识的决策。