潘柱廷
启明星辰信息技术有限公司CSO。 曾任信息产业部太极联合实验室副总工程师、中国人民银行总行信息网络安全资深顾问、安氏互联网安全系统（中国）有限公司首席技术官等职。曾承担了全国银行系统计算机安全检查、培训和设计工作，并参与了银行系统信息安全指导纲要的制订。

在从理论深度去理解ID Federation之前，先从最朴素的需求和实现思想上的一些思考。

我要分享帐号

我们大家都知道安全的一个基本原则性建议：不要共享系统帐号，这样非常不安全。这是每一个安全从业人员的基本知识，在作风险评估的时候，如果发现这样的问题我们从来都是给出负面的评价并建议用户改进。

可是，在实际的业务工作中，这样一个简单的要求，其实会消耗不少的管理成本。因为，在这个认证和授权的行为中，由几个方面的因素都是多变的，是的管理 起来有困难。比如，人是一个多变的因素，人的新进和离开，都会导致系统帐号的变化。而每配置一个帐号，都要不少的管理活动不得不配套，这样复杂的管理活动 必然容易引起错误，或者引起管理者的投机取巧。再比如，系统本身也是一个多变的因素，随着企业竞争环境的剧烈化和多变化，新的业务会不断出现，新的管理应 用也会不断配套出现。这些都带来应用系统的频繁变化，而一个新业务系统都要进行帐号的配置。那么每个系统都要为其所有相关的Stakeholder配置帐 号，这又是一个比较繁琐的管理过程。在上述两种变化中，如果我们每次遇到变化都要对从人、角色、权力、具体的帐号配置等等全都进行配套调整，那将是一个非 常复杂的工作，特别是对于一个大型的机构来说，甚至可以说是一个不可能完成的任务。在这样的背景下，多人共享一个系统中的帐号，就变成了一个自然的结果。

怎么平衡这种帐号分享要求与基本帐号安全要求的矛盾呢？

围绕ＩＤ拆解认证过程

解决上述矛盾，其实就是要认清楚，＂要求不要多人共享帐号＂的目的是什么。简单来说，其目的就是为了防止责任不清。而不是控制粒度问题。因为，既然让 多人共享一个帐号，就是认可多人具有同样的一个角色，也就是这个觉得的访问控制规则是可以适用多人的。而剩下的就是如何确定每个人的 accountability了。所以，这个要求非常类似于RBAC的需求。

　　这个时候，我们就可以将整个认证过程拆解开了：

拆解为三步：

1. 为每个人（个体）分配ＩＤ，并对其进行认证。这个认证可以是用户名口令、动态口令、证书、生物识别等等。总之，这个步骤解决的是人的ＩＤ问题。
2. 为每个必要的系统角色分配ＩＤ。每个ＩＤ所对应的权限分配等等已经就绪。这些ＩＤ常常就是各个机器和系统上的帐号。
3. 第三步就是将上面两个ＩＤ关联起来。最简单的理解就是做一个mapping。

当然，拆解和mapping还不完全，所有和ID相关的活动和操作，都要跨越/穿越这个mapping关系。最最典型的要求，就是accountability功能要得到继承，也就是审计功能应当能够将ID4R的活动对应到ID4P上去。

如果能够很好地实现拆解和关联，那么前面提到的挑战就得到了一个很好的解决办法。而且，你也会感觉到，这个解决方案在将事情向简化的方式推进，完全符合“安全从简单开始”的理念。