PaaS产品的权限体系该如何设计
前言
授人以鱼不如授人以渔，与其直接把设计好的权限体系拿出来展示，不如把权限体系的设计思路和方法提炼出来与大家分享。
本文结构：首先介绍PaaS产品和权限体系的定义，其次讲解针对PaaS产品的权限体系设计原则和思路，再次与大家分析如何根据方法实现一套权限体系，最后再分享一些在权限体系建设中的心得。
1.概念定义
1.1.什么是PaaS产品
PaaS是（Platform as a Service）的缩写，是指平台即服务。把服务器平台作为一种服务提供的商业模式，通过网络进行程序提供的服务称之为SaaS(Software as a Service)，而云计算时代相应的服务器平台或者开发环境作为服务进行提供就成为了PaaS（Platform as a Service）。——来自百度百科
PaaS产品对外提供服务通常是以API或SDK两种形态，API是可以直接云调用的接口，SDK是需要集成部署的软件开发工具包。
1.2.什么是权限体系
权限，是指某个特定的用户具有特定的系统资源使用权力。在权限的定义中我们可以知道，“用户”是权限的主体，“使用权力”是权限的客体。
权限体系，是指对所有的权限主体和客体进行限制和约束的完整方案。
1.3.PaaS产品的权限体系
在上述的文字中我们知道了PaaS产品的主要服务形态以及权限体系的定义，那么PaaS产品的权限体系实际上就是对用户具有的API和SDK这两种服务的使用权力的限制和约束方案。
2.权限体系的设计原则
安全、稳定、易用。
2.1.安全
所谓安全，就是要让权限体系的功能完整实现，从而达到对主体客体进行有效控制的目的。毋庸置疑，安全是权限体系最重要的设计原则。
1）设计上的安全，全面考虑各场景状态，保证权限体系在设计上没有漏洞。
2）技术上的安全，防止权限体系遭到外界的技术破解。
2.2.稳定
1）系统稳定，减少不必要的联网措施，优化并减少单位内授权鉴权的系统并发量，降低权限系统压力。使用服务器资源弹性伸缩方案，支撑系统并发峰值。
2）操作稳定，结合业务场景提高授权鉴权的灵活度以适应用户各种业务需求，减少权限系统为适应业务而变更的频率。权限体系一经确定，一般不会轻易变更，即使变更也需要做到向下兼容。
2.3.易用
统一各场景的授权鉴权方式，减少系统间交互，降低用户学习和接入成本。
3.权限体系的设计思路
3.1.权限体系的执行任务和方式
3.1.1.权限体系的执行任务
执行任务是指权限操作的业务流程，一般可划分为授权和鉴权两个阶段。在用户使用PaaS产品的过程中，我们需要先授权，再鉴权，只有鉴权通过后，用户才能使用产品功能。
授权，是指授予用户PaaS产品使用权力的过程。
鉴权，是指鉴别用户合法性及PaaS产品使用权力的过程。
3.1.2.权限体系的执行方式
执行方式是指权限任务通过什么形式来完成，一般可划分为在线和离线两种方式。在用户的业务场景中，网络环境是影响权限任务执行的最主要因素，某些场景下用户系统可以连接互联网，而某些场景下用户系统不可以连接互联网，所以我们在设计权限体系时，需要充分考虑权限的执行方式。
在线，是指用户系统可以连接互联网，权限任务可以通过互联网通信完成。
离线，是指用户系统不可以连接互联网，权限任务需要通过本地校验完成。
3.1.3.执行任务和执行方式的组合
综上，我们可以得出执行任务和执行方式的组合如下——
1）在线授权-在线鉴权
（图1）
2）在线授权-离线鉴权
（图2）
3）离线授权-离线鉴权
（图3）
备注：在实际业务中，极少会出现“离线授权-在线鉴权”的情况，这里暂时不做叙述。
3.2.权限体系的管控内容
从权限体系的定义中我们知道，权限体系管控的内容包括主体和客体，主体是用户，客体是使用权力。说直白些，权限体系要控制的内容就是“给谁用”“用什么”“用多少”“用多久”“用多好”。
3.2.1.权限体系的主体
主体是用户/客户/租户/应用（whatever什么称号），要管控的是“给谁用”。
3.2.2.权限体系的客体
客体是使用权力，要管控的是“用什么”“用多少”“用多久”“用多好”。
“用什么“，控制的是用户可以使用哪些产品；
“用多少“，控制的是产品的使用数量，一般包括API的调用次数、SDK的装机量等；
“用多久“，控制的是产品使用有效期；
“用多好“，控制的是产品性能，一般体现为API的性能QPS。
3.3.权限体系的使用场景
权限体系的使用场景其实就是PaaS产品的使用场景，笔者做了如下的划分（图4）：云调用、移动端、边缘终端、服务器端。这四个场景基本已经涵盖PaaS产品的所有使用场景，权限体系需要面向场景而设计。
（图4）
3.3.1.云调用
云调用是指用户系统通过互联网调用PaaS产品的开放API接口，以实现对产品功能的使用。
3.3.2.移动端
移动端是指用户通过将PaaS产品的SDK集成到自己的移动应用程序中，以实现对产品功能的使用。移动端的应用程序是安装在C端用户的手机中。
3.3.3.边缘终端
边缘终端在对PaaS产品的使用方式上和移动端是一样的，即集成SDK到应用程序中，差别在于边缘终端的应用程序是安装在例如门禁、闸机、摄像头这类边缘设备中。
后面3.4.2和3.4.3小节会提到为什么要这样区分的原因。
3.3.4.服务器端
服务器端是指通过把PaaS产品打包成部署包（可以理解为是SDK），并将该包私有化部署到用户系统的本地服务器中，以实现对产品功能的使用。
再说透一点，服务器端和云调用是同一个产品的两种服务方式，服务器端是离线使用，云调用是在线使用。例如在某某云上的人脸比对产品，用户可以直接通过调用API来使用人脸比对，此时算法是部署在某某云服务器中的；用户也可以在平台申请人脸比对的私有化部署，将人脸比对算法部署到自己本地的服务器中来使用。银行类、政府类客户因为数据合规要求，会使用这种私有化部署的方式。
3.4.权限体系管控内容的场景化
我们已知权限体系要管控的内容以及使用场景，接下来就要细化在每个场景中实际要控制哪些具体项目，以达成管控内容的场景化实现。
3.4.1.云调用场景的控制项
（表1）
3.4.2.移动端场景的控制项
（表2）
备注：在移动端场景中，设备指纹不可提前预知，需要C端用户安装APP后我们才能获取到设备指纹，所以在该场景下如果要控制装机量，就必须联网，在线实时将设备指纹回传给权限系统后台计算装机量是否已达上限。
3.4.3.边缘终端场景的控制项
（表3）
备注：在边缘终端场景中，设备指纹是可以提前获得的，而且该场景下大多是不可联网，所以我们需要将获得的设备指纹提前写入到授权文件中，以便本地校验控制装机量。结合3.4.2来看，这就是为什么要区分移动端和边缘终端的原因。
3.4.4.服务器端场景的控制项
（表4）
备注：在服务器端的场景下，一般会直接控制部署的具体机器，所以“使用主体”会采用设备指纹来进行管控，而采用设备指纹的管控，同时会把装机量也一并控制起来。
3.5.其他权限策略
除了上述常规的权限内容，根据实际业务我们还可以制定一些特殊的权限策略，例如“周期性权限验证”策略。这个策略在“在线授权-离线鉴权”的场景中会经常被用到，所以笔者特意拎出来和大家详细分享。
所谓周期性权限验证，顾名思义就是按照一定的时间周期重新执行授权和鉴权。这个策略的意义在于在离线鉴权的情形下，我们也可以在一定周期内对客户的权限进行有效的主动管控。
举个例子，某客户和我们签订了一年的SDK产品合作合同，我们给该客户开通了一年期的SDK产品使用权限，客户在使用SDK时，鉴权模块会自动把生成好的一年有效期的License文件拉取到本地进行校验。过了几天时间，该客户没有按照合同履约向我们付款，此时我们需要停止对该客户的产品使用授权。在没有“周期性权限验证”策略的情况下，此时我们是没有办法主动控制那些已经正在使用的SDK权限，因为此时有效的License文件已经在本地存在，本地校验是可以通过的；而如果有“周期性权限验证”策略，此时我们只需要在后台关闭该客户的授权，License文件会自动更新为“无授权”状态，那么当达到一个验证周期时，SDK会重新在后台拉取新License文件，此时拉取的是“无授权”状态的文件，所以本地校验就不会通过，从而实现对权限的主动管控。
这个策略需要和有效期的概念区分开来。当权限体系中存在这个“周期性权限验证”策略时，控制项中需要增加一个字段“下次更新日期”，即达到这个日期，就需要对License文件进行一次拉取更新。下次更新日期（UDD）的生成规则和有效期有着如下的关系——
我们假设将周期设定为30天和7天
（表5）
4.PaaS产品的权限体系实现
在明确了权限体系的设计原则和设计思路后，我们一起来看看根据设计原则和思路而实现的权限体系。
前文提到，PaaS产品有API和SDK两种服务形态，有云调用、移动端、边缘终端、服务器端四种使用场景。结合服务形态和使用场景，我们可以得出以下象限分类（图5）。
（图5）
对权限体系的设计，我们可以从服务形态维度进行分类设计，也可以从使用场景维度进行分类设计。基于“易用”原则，我们需要尽可能的把各场景授权鉴权方式统一，所以这里建议以服务形态的维度进行分类设计。
同时，再跟大家回顾一下权限体系任务和方式的组合，包括“在线授权-在线鉴权”、“在线授权-离线鉴权”、“离线授权-离线鉴权”。
4.1.API服务形态
针对API服务形态，我们只会采用“在线授权-在线鉴权”的任务方式组合。
4.1.1.核心设计
API权限体系的核心设计是通过APPID+KEY、AK+SK等密钥的在线分配和加解密校验以实现授权和鉴权。
4.1.2.权限体系实现
1）控制项
前文已经描述过云调用场景的控制项（表1）。
2）权限体系载体
一个完整的API权限体系需要权限后台系统作为载体。
权限后台系统，承担的是控制内容设置、密钥生成和下发、配置文件生成、在线密钥和配置校验的功能。
3）系统间交互时序图
（图6）
备注：对于API的使用，我们建议业务方与PaaS平台的交互采用服务器到服务器加密通信的方式，不要采用业务方移动端、边缘终端直接与PaaS平台服务器通信的方式，后者的通信方式会存在抓包劫持导致密钥泄露的风险。密钥一旦泄露，权限就会被盗用。
4.2.SDK服务形态（难点）
针对SDK服务形态，我们会采用”在线授权-在线鉴权“、“在线授权-离线鉴权“、”离线授权-离线鉴权“三种任务方式组合进行归一化设计。这正是权限体系设计最复杂的地方。
4.2.1.核心设计
SDK权限体系的核心设计是通过License文件的分配和校验以实现授权和鉴权。
4.2.2.权限体系实现
1）权限Key-Value标准协议
通过核心设计我们知道，SDK权限体系的关键是License文件的分配和校验，而License文件能够被有效校验的关键就是《权限Key-Value标准协议》。
所谓《权限Key-Value标准协议》，是指License文件与SDK之间相互共识的控制项和内容值的标准集合。Key是控制项，正是前文管控内容场景化中表2、表3、表4所列举的控制项；Value是内容值。我们需要将表2、表3、表4进行归一化处理，会得出如下标准协议——
（表6）
备注：
“互斥”表示不会同时录入Value。
“SDK编号”和“算法/服务编号”需要协定编号与具体SDK或算法服务的对应关系，例如SDK编号为K12345对应的是活体检测SDK，那么在活体检测SDK中会打上K12345这个编号。在授权过程中，权限系统会根据工作人员的设置把SDK编号写入License文件，鉴权过程中会校验License文件中的SDK编号Value是否与SDK中打上的编号一致，以实现对“用什么”进行控制。
“设备指纹”可以是MAC地址、IMEI码、序列号等能够辩识具体设备的唯一标识，同一类设备的标识一经确定后不可轻易修改，如必须修改则需要通知业务方紧密配合一同完成修改，否则很容易造成鉴权失败导致生产事故发生。
“有效期日期”需要注意一个风险，在设备本地进行日期或时间校验，业务方可通过手动调整本地时间，以达到永远都不会过期的目的。不过对本地时间进行手动调整是以牺牲一定的设备功能为前提的，一般业务方不会为了一点授权费用而钻这种空子。
“有效期倒计时”是另外一种控制有效期限的方式，这种方式可以规避上面“有效期日期”中篡改本地时间的风险，但这种方式也会存在另一种风险——如果设备关机，倒计时则会停止。所以对于有效期限的控制，大家可以根据实际情况，采取其中一种方式，当然也可以两种方式综合校验考量。
“是否联网校验数量”主要是针对移动端场景，前文我们已经提到过，移动端场景无法提前获取设备指纹，如果要控制装机量，就必须联网，在线实时将设备指纹回传给权限系统后台计算装机量是否已达上限。
2）权限体系载体
一个完整的SDK权限体系需要权限后台系统和鉴权SDK两个载体。
权限后台系统，承担的是控制内容设置、License文件生成和下发、在线配置校验的功能。
鉴权SDK，承担的是License文件获取和本地校验的功能。之所以要把鉴权独立封装为一个SDK，是为了让鉴权和业务功能解耦。
（图7）SDK简易架构
3）系统间交互时序图
（图8）
备注：
第3步“下发License文件”可以通过“在线”下发和“离线”下发两种方式，以实现“在线授权”和“离线授权”。
第7步“在线配置校验”是“在线鉴权”的情况下所需要执行的任务，“离线鉴权”中是不需要执行这个任务的。
图8的时序图描述的是不含异常流的主流程。
4）离线鉴权流程图
（图9）
后记
最后再分享一些在设计API和SDK权限体系时的小心得吧。
关于API的密钥和调用量对账
密钥的生成和下发，目前主流平台的方式是由平台独立完成并存在数据库中，这就埋下了泄露的隐患。虽然平台对数据库有着很严密的保护，对密钥的明文查看也有着很严格的权限策略，但是这些措施都无法完全杜绝平台方密钥泄露及被破解的风险。一旦业务方的权限发生盗用，密钥的泄露责任无法扯清，即使是业务方自己不小心泄露的，平台方也很难举证。
同时，在平台方与业务方进行调用量对账时，往往都会存在双方日志的差异，在这种情况下以谁的日志数据为准也是很难扯清的问题。通常面对这种情况，平台方为了留住业务方往往会选择妥协，以业务方的日志数据或者说以相对较少的日志数据为准进行对账计费。
针对上述的情况，笔者有思考过一种可以让平台方证明无泄露责任且可以对清楚日志数据的新鉴权方式。核心思想就是让业务方来生成密钥——一对非对称的公私钥。具体操作如下：
业务方自行使用非对称加密算法生成一对公钥和私钥，私钥可以用于加密，公钥仅可以用于解密不可用于加密；
公钥交由平台方保管，私钥由业务方自行保管；
业务方对平台API接口发起请求时，需要传入一个加密字符串 N ，加密字符串 N 是由业务方私钥加密生成；
平台方接到接口请求时，首先会使用业务方提供的公钥对加密字符串 N 进行解密；
若解密成功，则鉴权通过，进入后续的配置校验和功能处理并返回结果；若解密失败，则鉴权不通过，接口请求报错并返回结果；
业务方调用API接口的每条日志中都会留存字符串 N 这个字段。
以上方案需要重点评估加解密算法对系统性能的影响。
关于SDK数量的控制
对于离线场景中，数量只能通过设备指纹来控制，这意味着在我们给出授权前，客户的机器都是已经生产好或者是准备好的。
认知浅薄，欢迎讨论。