身份和访问管理

身份和访问管理（Identity and Access Management，IAM）通过对客体的鉴别（authentication）与授权（authorization），实现对信息资源访问的控制。几乎在所有的安全标准中，IAM都作为重要的安全域，应用程序接口（Application Programming Interface，API）是开放银行的基础之一，商业银行借助其实现内部和外部互联的金融服务模式，因此IAM在其中显得尤为重要。

鉴别，是指确认一个实体所声称身份的过程。授权，是指在属性管理系统中，将主体与角色绑定的过程。鉴别和授权是两件不同的事，鉴别指的是证明声称方确实是声称者本体。在实践中，身份鉴别/实体鉴别的实现称为身份管理，而授权的实现则被称为访问管理，身份管理和访问管理两者经常被合在一起称为身份与访问管理。鉴别、授权、身份管理系统和访问管理系统等上述概念的关系，大致如图1所示。

图1鉴别与授权及其支持关系

JR/T 0185-2020《商业银行应用程序接口安全管理规范》（下文中简称“本标准”）中，将上述过程合称为认证鉴权，在商业银行应用程序接口服务层中体现为一项功能，在整个生命周期管理中，身份和访问管理，或者鉴别与授权，则体现在每一个具体的阶段中。

API是一系列封装好的函数，有时候也被翻译为“应用程序编程接口”，如其名称所述，属于软件开发的范畴，因此在本标准中，其生命周期阶段，分别划分为安全设计（第7章）、安全部署（第8章）、安全集成（第9章）、安全运维（第10章）、服务终止与系统下线（第11章）。身份与访问管理的要求在生命周期中的每个阶段虽然都有所体现，但是在安全设计和安全集成阶段体现的尤为集中。

安全设计阶段的要求

本标准中安全设计阶段，IAM分为两种角色描述：接口身份认证安全要求和用户身份认证安全要求。这与六章一节“接口类型”的要求是相对应的。

应用方身份认证使用的验证要素提供了三种方式或其组合，如图2所示。

图2应用方身份认证使用的验证要素

安全级别分A2和A1，其中A2为高等级，主要针对资金交易和账户信息查询应用类，A1为低等级，用于金融产品和信息查询应用类。标准中明确规定，A2级别接口，应使用数字证书或公私钥对的方式进行双向身份认证。

数字证书或公私钥对存在一定的差异。在公钥密码算法的设计中，发送者用公钥加密，接收者用私钥解密。公钥是公开的，不必担心窃听，私钥又不存在传输的问题。这解决了对称密码中难以解决的密钥配送问题。对于持有私钥方而言，这本身就确认了身份。这就是公私钥对的方式。但是，在非对称密码算法中，接收者依然无法判断收到的公钥是否是合法的，因为有可能是中间人假冒的。事实上，仅靠公钥密码本身，无法防御中间人攻击。于是，需要（认证机构）对公钥进行签名，从而确认公钥没有被篡改。加了数字签名的公钥称为证书（公钥证书，一般简称为证书）。因此，数字证书比公私钥对要求更高一些。

用户身份认证安全要求中，提了较为通用的要求，同时要求用户身份认证应该商业银行执行，明确了责任主体。对于A2级别接口中的资金交易类服务，要求双因子认证。

安全集成阶段的要求

首先，需要注意的是，九章三节的“运行安全”部分，是安全集成的子阶段，也就是说，在本标准中，“运行”和“运维”的概念作了严格的区分。

安全集成中集成阶段中，鉴别，即身份认证，在九章二节“接入安全控制”和9三节“运行安全”中，各有章节，在该节的“权限控制”中，还讨论了授权，即权限控制。

接入安全控制的身份认证章节，还包括了身份声明的要求，商业银行配置唯一标识的APPID及与之匹配的鉴别凭证（Credential），即下图2中所示的应用鉴别密文、数字证书或公私钥对。认证过程中的要求，与设计阶段是一一对应的。

运行安全中身份认证，不再涉及接口，只需要对用户身份进行鉴别。有几个需要注意的点，首先，与设计阶段保持了一致，强调用户身份认证应该在商业银行完成，确实需要从应用方输入的，不能在本地留存；其次，商业银行需要对应用方提供的用户相关信息进行核验，而不是直接信任应用方；最后，提出了会话有效期应该遵循最小时间设计，关于会话有效期，在ISO/IEC 27002：2013/GB/T 22081-2016“安全登录规程”中，其九章四节“系统和应用访问控制”即属于授权相关的内容。

如上文所述，九章三节的“权限控制”，虽然同属于IAM的范畴，但已经另一个方面的要求了。其中的主要要求包括，最小授权原则，用户明示同意的授权有效期，以及授权有效期的控制。最小授权原则，在七章三节“授权管理”中亦有明确要求。

此外，还提出了应为用户提供关闭商业银行应用程序接口相关服务的渠道，如电子银行和营业网点等。开通和关闭的渠道的要求在信息安全相关标准中，并不常见，本质上，这是用户权力的范畴。在隐私相关标准中比较常见，例如，ISO/IEC 27701：2019《ISO/IEC 27001与ISO/IEC 27002在隐私信息管理的扩展要求与指南》，七章三节“提供修改或撤回同意的机制”，其中描述为：组织宜随时通知个人可识别信息（Personally Identifiable Information，PII）主体其有关撤回同意的权利，并提供这样的机制。退出机制取决于系统；在可能的情况下，宜与获得同意的机制保持一致。例如，如果通过电子邮件或网站收集同意书，撤回同意书的机制宜是相同的，而不是电话或传真等替代方案。跟ISO/IEC27701：2019对比，本标准的要求还是比较低的。

上述章节从设计阶段到集成阶段，其中内容对应关系如下图3所示。

图3设计阶段与集成阶段IAM要求的对应关系

密钥管理相关的要求

密码算法、密码协议和密钥管理是密码系统（Cryptosystems）安全三个不可或缺的基础。算法的强度是密码系统安全的基础，但并不是全部。密钥在所有的依赖于密码技术的安全系统中都是最为关键的部分之一，这导致密码机制的安全性和可靠性直接取决于密钥这一安全参数的管理。如果密钥管理存在薄弱环节，那么再强的密码算法和再完备的密码协议都会失效。

由于在验证要素中，用到了应用鉴别密文、数字证书和公私钥对，因此在七章三节章节“密钥管理”有专门的要求，主要包括加密和签名的密钥应该不同且分离，无论是私钥明文或密文，都不能以编码方式置于代码中，应用鉴别密文和私钥不能存储于本地的配置文件中，密码有效期的设置应根据API的等级。这几项要求，与主流的密钥管理标准基本都保持了一致，例如，ISO11568系列标准和ISO11770系列标准。

（本文作者就职于中国金融认证中心）