授人以魚(yú)不如授人以漁，與其直接把設(shè)計(jì)好的權(quán)限體系拿出來(lái)展示，不如把權(quán)限體系的設(shè)計(jì)思路和方法提煉出來(lái)與大家分享。

本文首先介紹PaaS產(chǎn)品和權(quán)限體系的定義，其次講解針對(duì)PaaS產(chǎn)品的權(quán)限體系設(shè)計(jì)原則和思路，再次與大家分析如何根據(jù)方法實(shí)現(xiàn)一套權(quán)限體系，最后再分享一些在權(quán)限體系建設(shè)中的心得。

1. 概念定義

1.1 什么是PaaS產(chǎn)品

PaaS是（Platform as a Service）的縮寫(xiě)，是指平臺(tái)即服務(wù)。把服務(wù)器平臺(tái)作為一種服務(wù)提供的商業(yè)模式，通過(guò)網(wǎng)絡(luò)進(jìn)行程序提供的服務(wù)稱之為SaaS(Software as a Service)，而云計(jì)算時(shí)代相應(yīng)的服務(wù)器平臺(tái)或者開(kāi)發(fā)環(huán)境作為服務(wù)進(jìn)行提供就成為了PaaS（Platform as a Service）。

——來(lái)自百度百科

PaaS產(chǎn)品對(duì)外提供服務(wù)通常是以API或SDK兩種形態(tài)，API是可以直接云調(diào)用的接口，SDK是需要集成部署的軟件開(kāi)發(fā)工具包。

1.2 什么是權(quán)限體系

權(quán)限，是指某個(gè)特定的用戶具有特定的系統(tǒng)資源使用權(quán)力。在權(quán)限的定義中我們可以知道，“用戶”是權(quán)限的主體，“使用權(quán)力”是權(quán)限的客體。

權(quán)限體系，是指對(duì)所有的權(quán)限主體和客體進(jìn)行限制和約束的完整方案。

1.3 PaaS產(chǎn)品的權(quán)限體系

在上述的文字中我們知道了PaaS產(chǎn)品的主要服務(wù)形態(tài)以及權(quán)限體系的定義，那么PaaS產(chǎn)品的權(quán)限體系實(shí)際上就是對(duì)用戶具有的API和SDK這兩種服務(wù)的使用權(quán)力的限制和約束方案。

2. 權(quán)限體系的設(shè)計(jì)原則

安全。穩(wěn)定。易用。

2.1 安全

所謂安全，就是要讓權(quán)限體系的功能完整實(shí)現(xiàn)，從而達(dá)到對(duì)主體客體進(jìn)行有效控制的目的。毋庸置疑，安全是權(quán)限體系最重要的設(shè)計(jì)原則。

1）設(shè)計(jì)上的安全，全面考慮各場(chǎng)景狀態(tài)，保證權(quán)限體系在設(shè)計(jì)上沒(méi)有漏洞。

2）技術(shù)上的安全，防止權(quán)限體系遭到外界的技術(shù)破解。

2.2 穩(wěn)定

1）系統(tǒng)穩(wěn)定，減少不必要的聯(lián)網(wǎng)措施，優(yōu)化并減少單位內(nèi)授權(quán)鑒權(quán)的系統(tǒng)并發(fā)量，降低權(quán)限系統(tǒng)壓力。使用服務(wù)器資源彈性伸縮方案，支撐系統(tǒng)并發(fā)峰值。

2）操作穩(wěn)定，結(jié)合業(yè)務(wù)場(chǎng)景提高授權(quán)鑒權(quán)的靈活度以適應(yīng)用戶各種業(yè)務(wù)需求，減少權(quán)限系統(tǒng)為適應(yīng)業(yè)務(wù)而變更的頻率。權(quán)限體系一經(jīng)確定，一般不會(huì)輕易變更，即使變更也需要做到向下兼容。

2.3 易用

統(tǒng)一各場(chǎng)景的授權(quán)鑒權(quán)方式，減少系統(tǒng)間交互，降低用戶學(xué)習(xí)和接入成本。

3. 權(quán)限體系的設(shè)計(jì)思路

3.1 權(quán)限體系的執(zhí)行任務(wù)和方式

3.1.1.權(quán)限體系的執(zhí)行任務(wù)

執(zhí)行任務(wù)是指權(quán)限操作的業(yè)務(wù)流程，一般可劃分為授權(quán)和鑒權(quán)兩個(gè)階段。在用戶使用PaaS產(chǎn)品的過(guò)程中，我們需要先授權(quán)，再鑒權(quán)，只有鑒權(quán)通過(guò)后，用戶才能使用產(chǎn)品功能。

• 授權(quán)，是指授予用戶PaaS產(chǎn)品使用權(quán)力的過(guò)程。
• 鑒權(quán)，是指鑒別用戶合法性及PaaS產(chǎn)品使用權(quán)力的過(guò)程。

3.1.2.權(quán)限體系的執(zhí)行方式

執(zhí)行方式是指權(quán)限任務(wù)通過(guò)什么形式來(lái)完成，一般可劃分為在線和離線兩種方式。

在用戶的業(yè)務(wù)場(chǎng)景中，網(wǎng)絡(luò)環(huán)境是影響權(quán)限任務(wù)執(zhí)行的最主要因素，某些場(chǎng)景下用戶系統(tǒng)可以連接互聯(lián)網(wǎng)，而某些場(chǎng)景下用戶系統(tǒng)不可以連接互聯(lián)網(wǎng)，所以我們?cè)谠O(shè)計(jì)權(quán)限體系時(shí)，需要充分考慮權(quán)限的執(zhí)行方式。

• 在線，是指用戶系統(tǒng)可以連接互聯(lián)網(wǎng)，權(quán)限任務(wù)可以通過(guò)互聯(lián)網(wǎng)通信完成。
• 離線，是指用戶系統(tǒng)不可以連接互聯(lián)網(wǎng)，權(quán)限任務(wù)需要通過(guò)本地校驗(yàn)完成。

3.1.3.執(zhí)行任務(wù)和執(zhí)行方式的組合

綜上，我們可以得出執(zhí)行任務(wù)和執(zhí)行方式的組合如下——

1）在線授權(quán)-在線鑒權(quán)

圖1

2）在線授權(quán)-離線鑒權(quán)

圖2

3）離線授權(quán)-離線鑒權(quán)

圖3

備注：在實(shí)際業(yè)務(wù)中，極少會(huì)出現(xiàn)“離線授權(quán)-在線鑒權(quán)”的情況，這里暫時(shí)不做敘述。

3.2 權(quán)限體系的管控內(nèi)容

從權(quán)限體系的定義中我們知道，權(quán)限體系管控的內(nèi)容包括主體和客體，主體是用戶，客體是使用權(quán)力。說(shuō)直白些，權(quán)限體系要控制的內(nèi)容就是“給誰(shuí)用”“用什么”“用多少”“用多久”“用多好”。

3.2.1.權(quán)限體系的主體

主體是用戶/客戶/租戶/應(yīng)用（whatever什么稱號(hào)），要管控的是“給誰(shuí)用”。

3.2.2.權(quán)限體系的客體

客體是使用權(quán)力，要管控的是“用什么”“用多少”“用多久”“用多好”。

• “用什么”控制的是用戶可以使用哪些產(chǎn)品；
• “用多少”，控制的是產(chǎn)品的使用數(shù)量，一般包括API的調(diào)用次數(shù)、SDK的裝機(jī)量等；
• “用多久”，控制的是產(chǎn)品使用有效期；
• “用多好”，控制的是產(chǎn)品性能，一般體現(xiàn)為API的性能QPS。

*QPS是指一個(gè)特定接口在每秒內(nèi)所處理的流量，一般來(lái)說(shuō)服務(wù)器數(shù)量越多算力就越大，特定接口的QPS也會(huì)越大，因此QPS和服務(wù)器成本是強(qiáng)相關(guān)的。

3.3 權(quán)限體系的使用場(chǎng)景

權(quán)限體系的使用場(chǎng)景其實(shí)就是PaaS產(chǎn)品的使用場(chǎng)景，筆者做了如下的劃分（圖4）：云調(diào)用、移動(dòng)端、邊緣終端、服務(wù)器端。這四個(gè)場(chǎng)景基本已經(jīng)涵蓋PaaS產(chǎn)品的所有使用場(chǎng)景，權(quán)限體系需要面向場(chǎng)景而設(shè)計(jì)。

圖4 場(chǎng)景象限

3.3.1.云調(diào)用

云調(diào)用是指用戶系統(tǒng)通過(guò)互聯(lián)網(wǎng)調(diào)用PaaS產(chǎn)品的開(kāi)放API接口，以實(shí)現(xiàn)對(duì)產(chǎn)品功能的使用。

3.3.2.移動(dòng)端

移動(dòng)端是指用戶通過(guò)將PaaS產(chǎn)品的SDK集成到自己的移動(dòng)應(yīng)用程序中，以實(shí)現(xiàn)對(duì)產(chǎn)品功能的使用。移動(dòng)端的應(yīng)用程序是安裝在C端用戶的手機(jī)中。

3.3.3.邊緣終端

邊緣終端在對(duì)PaaS產(chǎn)品的使用方式上和移動(dòng)端是一樣的，即集成SDK到應(yīng)用程序中，差別在于邊緣終端的應(yīng)用程序是安裝在例如門(mén)禁、閘機(jī)、攝像頭這類邊緣設(shè)備中。

后面3.4.2和3.4.3小節(jié)會(huì)提到為什么要這樣區(qū)分的原因。

3.3.4.服務(wù)器端

服務(wù)器端是指通過(guò)把PaaS產(chǎn)品打包成部署包（可以理解為是SDK），并將該包私有化部署到用戶系統(tǒng)的本地服務(wù)器中，以實(shí)現(xiàn)對(duì)產(chǎn)品功能的使用。

再說(shuō)透一點(diǎn)，服務(wù)器端和云調(diào)用是同一個(gè)產(chǎn)品的兩種服務(wù)方式，服務(wù)器端是離線使用，云調(diào)用是在線使用。例如在某某云上的人臉比對(duì)產(chǎn)品，用戶可以直接通過(guò)調(diào)用API來(lái)使用人臉比對(duì)，此時(shí)算法是部署在某某云服務(wù)器中的；用戶也可以在平臺(tái)申請(qǐng)人臉比對(duì)的私有化部署，將人臉比對(duì)算法部署到自己本地的服務(wù)器中來(lái)使用。銀行類、政府類客戶因?yàn)閿?shù)據(jù)合規(guī)要求，會(huì)使用這種私有化部署的方式。

3.4 權(quán)限體系管控內(nèi)容的場(chǎng)景化

我們已知權(quán)限體系要管控的內(nèi)容以及使用場(chǎng)景，接下來(lái)就要細(xì)化在每個(gè)場(chǎng)景中實(shí)際要控制哪些具體項(xiàng)目，以達(dá)成管控內(nèi)容的場(chǎng)景化實(shí)現(xiàn)。

3.4.1.云調(diào)用場(chǎng)景的控制項(xiàng)

表1

3.4.2.移動(dòng)端場(chǎng)景的控制項(xiàng)

表2

備注：在移動(dòng)端場(chǎng)景中，設(shè)備指紋不可提前預(yù)知，需要C端用戶安裝APP后我們才能獲取到設(shè)備指紋，所以在該場(chǎng)景下如果要控制裝機(jī)量，就必須聯(lián)網(wǎng)，在線實(shí)時(shí)將設(shè)備指紋回傳給權(quán)限系統(tǒng)后臺(tái)計(jì)算裝機(jī)量是否已達(dá)上限。

3.4.3.邊緣終端場(chǎng)景的控制項(xiàng)

表3

備注：在邊緣終端場(chǎng)景中，設(shè)備指紋是可以提前獲得的，而且該場(chǎng)景下大多是不可聯(lián)網(wǎng)，所以我們需要將獲得的設(shè)備指紋提前寫(xiě)入到授權(quán)文件中，以便本地校驗(yàn)控制裝機(jī)量。結(jié)合3.4.2來(lái)看，這就是為什么要區(qū)分移動(dòng)端和邊緣終端的原因。

3.4.4.服務(wù)器端場(chǎng)景的控制項(xiàng)

表4

備注：在服務(wù)器端的場(chǎng)景下，一般會(huì)直接控制部署的具體機(jī)器，所以“使用主體”會(huì)采用設(shè)備指紋來(lái)進(jìn)行管控，而采用設(shè)備指紋的管控，同時(shí)會(huì)把裝機(jī)量也一并控制起來(lái)。

3.5 其他權(quán)限策略

除了上述常規(guī)的權(quán)限內(nèi)容，根據(jù)實(shí)際業(yè)務(wù)我們還可以制定一些特殊的權(quán)限策略，例如“周期性權(quán)限驗(yàn)證”策略。這個(gè)策略在“在線授權(quán)-離線鑒權(quán)”的場(chǎng)景中會(huì)經(jīng)常被用到，所以筆者特意拎出來(lái)和大家詳細(xì)分享。

所謂周期性權(quán)限驗(yàn)證，顧名思義就是按照一定的時(shí)間周期重新執(zhí)行授權(quán)和鑒權(quán)。這個(gè)策略的意義在于在離線鑒權(quán)的情形下，我們也可以在一定周期內(nèi)對(duì)客戶的權(quán)限進(jìn)行有效的主動(dòng)管控。

舉個(gè)例子：

某客戶和我們簽訂了一年的SDK產(chǎn)品合作合同，我們給該客戶開(kāi)通了一年期的SDK產(chǎn)品使用權(quán)限，客戶在使用SDK時(shí)，鑒權(quán)模塊會(huì)自動(dòng)把生成好的一年有效期的License文件拉取到本地進(jìn)行校驗(yàn)。過(guò)了幾天時(shí)間，該客戶沒(méi)有按照合同履約向我們付款，此時(shí)我們需要停止對(duì)該客戶的產(chǎn)品使用授權(quán)。

在沒(méi)有“周期性權(quán)限驗(yàn)證”策略的情況下，此時(shí)我們是沒(méi)有辦法主動(dòng)控制那些已經(jīng)正在使用的SDK權(quán)限，因?yàn)榇藭r(shí)有效的License文件已經(jīng)在本地存在，本地校驗(yàn)是可以通過(guò)的；

而如果有“周期性權(quán)限驗(yàn)證”策略，此時(shí)我們只需要在后臺(tái)關(guān)閉該客戶的授權(quán)，License文件會(huì)自動(dòng)更新為“無(wú)授權(quán)”狀態(tài)，那么當(dāng)達(dá)到一個(gè)驗(yàn)證周期時(shí)，SDK會(huì)重新在后臺(tái)拉取新License文件，此時(shí)拉取的是“無(wú)授權(quán)”狀態(tài)的文件，所以本地校驗(yàn)就不會(huì)通過(guò)，從而實(shí)現(xiàn)對(duì)權(quán)限的主動(dòng)管控。

這個(gè)策略需要和有效期的概念區(qū)分開(kāi)來(lái)。當(dāng)權(quán)限體系中存在這個(gè)“周期性權(quán)限驗(yàn)證”策略時(shí)，控制項(xiàng)中需要增加一個(gè)字段“下次更新日期”，即達(dá)到這個(gè)日期，就需要對(duì)License文件進(jìn)行一次拉取更新。下次更新日期（UDD）的生成規(guī)則和有效期有著如下的關(guān)系——

*我們假設(shè)將周期設(shè)定為30天和7天

表5

4. PaaS產(chǎn)品的權(quán)限體系實(shí)現(xiàn)

在明確了權(quán)限體系的設(shè)計(jì)原則和設(shè)計(jì)思路后，我們一起來(lái)看看根據(jù)設(shè)計(jì)原則和思路而實(shí)現(xiàn)的權(quán)限體系。

前文提到，PaaS產(chǎn)品有API和SDK兩種服務(wù)形態(tài)，有云調(diào)用、移動(dòng)端、邊緣終端、服務(wù)器端四種使用場(chǎng)景。結(jié)合服務(wù)形態(tài)和使用場(chǎng)景，我們可以得出以下象限分類（圖5）。

圖5

對(duì)權(quán)限體系的設(shè)計(jì)，我們可以從服務(wù)形態(tài)維度進(jìn)行分類設(shè)計(jì)，也可以從使用場(chǎng)景維度進(jìn)行分類設(shè)計(jì)?；凇耙子谩痹瓌t，我們需要盡可能的把各場(chǎng)景授權(quán)鑒權(quán)方式統(tǒng)一，所以這里建議以服務(wù)形態(tài)的維度進(jìn)行分類設(shè)計(jì)。

同時(shí)，再跟大家回顧一下權(quán)限體系任務(wù)和方式的組合，包括“在線授權(quán)-在線鑒權(quán)”、“在線授權(quán)-離線鑒權(quán)”、“離線授權(quán)-離線鑒權(quán)”。

4.1 API服務(wù)形態(tài)

針對(duì)API服務(wù)形態(tài)，我們只會(huì)采用“在線授權(quán)-在線鑒權(quán)”的任務(wù)方式組合。

4.1.1.核心設(shè)計(jì)

API權(quán)限體系的核心設(shè)計(jì)是通過(guò)APPID+KEY、AK+SK等密鑰的在線分配和加解密校驗(yàn)以實(shí)現(xiàn)授權(quán)和鑒權(quán)。

4.1.2.權(quán)限體系實(shí)現(xiàn)

1）控制項(xiàng)

前文已經(jīng)描述過(guò)云調(diào)用場(chǎng)景的控制項(xiàng)（表1）。

2）權(quán)限體系載體

一個(gè)完整的API權(quán)限體系需要權(quán)限后臺(tái)系統(tǒng)作為載體。

權(quán)限后臺(tái)系統(tǒng)，承擔(dān)的是控制內(nèi)容設(shè)置、密鑰生成和下發(fā)、配置文件生成、在線密鑰和配置校驗(yàn)的功能。

3）系統(tǒng)間交互時(shí)序圖

圖6

備注：對(duì)于API的使用，我們建議業(yè)務(wù)方與PaaS平臺(tái)的交互采用服務(wù)器到服務(wù)器加密通信的方式，不要采用業(yè)務(wù)方移動(dòng)端、邊緣終端直接與PaaS平臺(tái)服務(wù)器通信的方式，后者的通信方式會(huì)存在抓包劫持導(dǎo)致密鑰泄露的風(fēng)險(xiǎn)。密鑰一旦泄露，權(quán)限就會(huì)被盜用。

4.2 SDK服務(wù)形態(tài)（難點(diǎn)）

針對(duì)SDK服務(wù)形態(tài)，我們會(huì)采用”在線授權(quán)-在線鑒權(quán)“、“在線授權(quán)-離線鑒權(quán)“、”離線授權(quán)-離線鑒權(quán)“三種任務(wù)方式組合進(jìn)行歸一化設(shè)計(jì)。這正是權(quán)限體系設(shè)計(jì)最復(fù)雜的地方。

4.2.1.核心設(shè)計(jì)

SDK權(quán)限體系的核心設(shè)計(jì)是通過(guò)License文件的分配和校驗(yàn)以實(shí)現(xiàn)授權(quán)和鑒權(quán)。

4.2.2.權(quán)限體系實(shí)現(xiàn)

1）權(quán)限Key-Value標(biāo)準(zhǔn)協(xié)議

通過(guò)核心設(shè)計(jì)我們知道，SDK權(quán)限體系的關(guān)鍵是License文件的分配和校驗(yàn)，而License文件能夠被有效校驗(yàn)的關(guān)鍵就是《權(quán)限Key-Value標(biāo)準(zhǔn)協(xié)議》。

所謂《權(quán)限Key-Value標(biāo)準(zhǔn)協(xié)議》，是指License文件與SDK之間相互共識(shí)的控制項(xiàng)和內(nèi)容值的標(biāo)準(zhǔn)集合。Key是控制項(xiàng)，正是前文管控內(nèi)容場(chǎng)景化中表2、表3、表4所列舉的控制項(xiàng)；Value是內(nèi)容值。我們需要將表2、表3、表4進(jìn)行歸一化處理，會(huì)得出如下標(biāo)準(zhǔn)協(xié)議——

表6

備注：

• “互斥”表示不會(huì)同時(shí)錄入Value。
• “SDK編號(hào)”和“算法/服務(wù)編號(hào)”需要協(xié)定編號(hào)與具體SDK或算法服務(wù)的對(duì)應(yīng)關(guān)系，例如SDK編號(hào)為K12345對(duì)應(yīng)的是活體檢測(cè)SDK，那么在活體檢測(cè)SDK中會(huì)打上K12345這個(gè)編號(hào)。在授權(quán)過(guò)程中，權(quán)限系統(tǒng)會(huì)根據(jù)工作人員的設(shè)置把SDK編號(hào)寫(xiě)入License文件，鑒權(quán)過(guò)程中會(huì)校驗(yàn)License文件中的SDK編號(hào)Value是否與SDK中打上的編號(hào)一致，以實(shí)現(xiàn)對(duì)“用什么”進(jìn)行控制。
• “設(shè)備指紋”可以是MAC地址、IMEI碼、序列號(hào)等能夠辯識(shí)具體設(shè)備的唯一標(biāo)識(shí)，同一類設(shè)備的標(biāo)識(shí)一經(jīng)確定后不可輕易修改，如必須修改則需要通知業(yè)務(wù)方緊密配合一同完成修改，否則很容易造成鑒權(quán)失敗導(dǎo)致生產(chǎn)事故發(fā)生。
• “有效期日期”需要注意一個(gè)風(fēng)險(xiǎn)，在設(shè)備本地進(jìn)行日期或時(shí)間校驗(yàn)，業(yè)務(wù)方可通過(guò)手動(dòng)調(diào)整本地時(shí)間，以達(dá)到永遠(yuǎn)都不會(huì)過(guò)期的目的。不過(guò)對(duì)本地時(shí)間進(jìn)行手動(dòng)調(diào)整是以犧牲一定的設(shè)備功能為前提的，一般業(yè)務(wù)方不會(huì)為了一點(diǎn)授權(quán)費(fèi)用而鉆這種空子。
• “有效期倒計(jì)時(shí)”是另外一種控制有效期限的方式，這種方式可以規(guī)避上面“有效期日期”中篡改本地時(shí)間的風(fēng)險(xiǎn)，但這種方式也會(huì)存在另一種風(fēng)險(xiǎn)——如果設(shè)備關(guān)機(jī)，倒計(jì)時(shí)則會(huì)停止。所以對(duì)于有效期限的控制，大家可以根據(jù)實(shí)際情況，采取其中一種方式，當(dāng)然也可以兩種方式綜合校驗(yàn)考量。
• “是否聯(lián)網(wǎng)校驗(yàn)數(shù)量”主要是針對(duì)移動(dòng)端場(chǎng)景，前文我們已經(jīng)提到過(guò)，移動(dòng)端場(chǎng)景無(wú)法提前獲取設(shè)備指紋，如果要控制裝機(jī)量，就必須聯(lián)網(wǎng)，在線實(shí)時(shí)將設(shè)備指紋回傳給權(quán)限系統(tǒng)后臺(tái)計(jì)算裝機(jī)量是否已達(dá)上限。

2）權(quán)限體系載體

一個(gè)完整的SDK權(quán)限體系需要權(quán)限后臺(tái)系統(tǒng)和鑒權(quán)SDK兩個(gè)載體。

權(quán)限后臺(tái)系統(tǒng)，承擔(dān)的是控制內(nèi)容設(shè)置、License文件生成和下發(fā)、在線配置校驗(yàn)的功能。

鑒權(quán)SDK，承擔(dān)的是License文件獲取和本地校驗(yàn)的功能。之所以要把鑒權(quán)獨(dú)立封裝為一個(gè)SDK，是為了讓鑒權(quán)和業(yè)務(wù)功能解耦。

圖7 SDK包簡(jiǎn)易架構(gòu)圖

3）系統(tǒng)間交互時(shí)序圖

圖8

備注：

• 第3步“下發(fā)License文件”可以通過(guò)“在線”下發(fā)和“離線”下發(fā)兩種方式，以實(shí)現(xiàn)“在線授權(quán)”和“離線授權(quán)”。
• 第7步“在線配置校驗(yàn)”是“在線鑒權(quán)”的情況下所需要執(zhí)行的任務(wù)，“離線鑒權(quán)”中是不需要執(zhí)行這個(gè)任務(wù)的。
• 圖8的時(shí)序圖描述的是不含異常流的主流程。

4）離線鑒權(quán)流程圖

圖9

后記

最后再分享一些在設(shè)計(jì)API和SDK權(quán)限體系時(shí)的小心得吧。

1. 關(guān)于API的密鑰和調(diào)用量對(duì)賬

密鑰的生成和下發(fā)，目前主流平臺(tái)的方式是由平臺(tái)獨(dú)立完成并存在數(shù)據(jù)庫(kù)中，這就埋下了泄露的隱患。雖然平臺(tái)對(duì)數(shù)據(jù)庫(kù)有著很嚴(yán)密的保護(hù)，對(duì)密鑰的明文查看也有著很嚴(yán)格的權(quán)限策略，但是這些措施都無(wú)法完全杜絕平臺(tái)方密鑰泄露及被破解的風(fēng)險(xiǎn)。一旦業(yè)務(wù)方的權(quán)限發(fā)生盜用，密鑰的泄露責(zé)任無(wú)法扯清，即使是業(yè)務(wù)方自己不小心泄露的，平臺(tái)方也很難舉證。

同時(shí)，在平臺(tái)方與業(yè)務(wù)方進(jìn)行調(diào)用量對(duì)賬時(shí)，往往都會(huì)存在雙方日志的差異，在這種情況下以誰(shuí)的日志數(shù)據(jù)為準(zhǔn)也是很難扯清的問(wèn)題。通常面對(duì)這種情況，平臺(tái)方為了留住業(yè)務(wù)方往往會(huì)選擇妥協(xié)，以業(yè)務(wù)方的日志數(shù)據(jù)或者說(shuō)以相對(duì)較少的日志數(shù)據(jù)為準(zhǔn)進(jìn)行對(duì)賬計(jì)費(fèi)。

針對(duì)上述的情況，筆者有思考過(guò)一種可以讓平臺(tái)方證明無(wú)泄露責(zé)任且可以對(duì)清楚日志數(shù)據(jù)的新鑒權(quán)方式。核心思想就是讓業(yè)務(wù)方來(lái)生成密鑰——一對(duì)非對(duì)稱的公私鑰。具體操作如下：

• 業(yè)務(wù)方自行使用非對(duì)稱加密算法生成一對(duì)公鑰和私鑰，私鑰可以用于加密，公鑰僅可以用于解密不可用于加密；
• 公鑰交由平臺(tái)方保管，私鑰由業(yè)務(wù)方自行保管；
• 業(yè)務(wù)方對(duì)平臺(tái)API接口發(fā)起請(qǐng)求時(shí)，需要傳入一個(gè)加密字符串 N ，加密字符串 N 是由業(yè)務(wù)方私鑰加密生成；
• 平臺(tái)方接到接口請(qǐng)求時(shí)，首先會(huì)使用業(yè)務(wù)方提供的公鑰對(duì)加密字符串 N 進(jìn)行解密；
• 若解密成功，則鑒權(quán)通過(guò)，進(jìn)入后續(xù)的配置校驗(yàn)和功能處理并返回結(jié)果；若解密失敗，則鑒權(quán)不通過(guò)，接口請(qǐng)求報(bào)錯(cuò)并返回結(jié)果；
• 業(yè)務(wù)方調(diào)用API接口的每條日志中都會(huì)留存字符串 N 這個(gè)字段。

2. 關(guān)于SDK數(shù)量的控制

對(duì)于離線場(chǎng)景中，數(shù)量只能通過(guò)設(shè)備指紋來(lái)控制，這意味著在我們給出授權(quán)前，客戶的機(jī)器都是已經(jīng)生產(chǎn)好或者是準(zhǔn)備好的。

認(rèn)知淺薄，歡迎討論。

本文由 @ 山雞Samson 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議