中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

授人以魚不如授人以漁，與其直接把設計好的權限體系拿出來展示，不如把權限體系的設計思路和方法提煉出來與大家分享。

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

1. 概念定義

1.1 什么是PaaS產品

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

——來自百度百科

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

1.2 什么是權限體系

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

權限體系，是指對所有的權限主體和客體進行限制和約束的完整方案。

1.3 PaaS產品的權限體系

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

2. 權限體系的設計原則

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

2.1 安全

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

1）設計上的安全，全面考慮各場景狀態(tài)，保證權限體系在設計上沒有漏洞。

2）技術上的安全，防止權限體系遭到外界的技術破解。

2.2 穩(wěn)定

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

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

2.3 易用

統(tǒng)一各場景的授權鑒權方式，減少系統(tǒng)間交互，降低用戶學習和接入成本。

3. 權限體系的設計思路

3.1 權限體系的執(zhí)行任務和方式

3.1.1.權限體系的執(zhí)行任務

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

• 授權，是指授予用戶PaaS產品使用權力的過程。
• 鑒權，是指鑒別用戶合法性及PaaS產品使用權力的過程。

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

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

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

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

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

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

1）在線授權-在線鑒權

圖1

2）在線授權-離線鑒權

圖2

3）離線授權-離線鑒權

圖3

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

3.2 權限體系的管控內容

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

3.2.1.權限體系的主體

主體是用戶/客戶/租戶/應用（whatever什么稱號），要管控的是“給誰用”。

3.2.2.權限體系的客體

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

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

*QPS是指一個特定接口在每秒內所處理的流量，一般來說服務器數(shù)量越多算力就越大，特定接口的QPS也會越大，因此QPS和服務器成本是強相關的。

3.3 權限體系的使用場景

權限體系的使用場景其實就是PaaS產品的使用場景，筆者做了如下的劃分（圖4）：云調用、移動端、邊緣終端、服務器端。這四個場景基本已經涵蓋PaaS產品的所有使用場景，權限體系需要面向場景而設計。

圖4 場景象限

3.3.1.云調用

云調用是指用戶系統(tǒng)通過互聯(lián)網(wǎng)調用PaaS產品的開放API接口，以實現(xiàn)對產品功能的使用。

3.3.2.移動端

移動端是指用戶通過將PaaS產品的SDK集成到自己的移動應用程序中，以實現(xiàn)對產品功能的使用。移動端的應用程序是安裝在C端用戶的手機中。

3.3.3.邊緣終端

邊緣終端在對PaaS產品的使用方式上和移動端是一樣的，即集成SDK到應用程序中，差別在于邊緣終端的應用程序是安裝在例如門禁、閘機、攝像頭這類邊緣設備中。

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

3.3.4.服務器端

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

再說透一點，服務器端和云調用是同一個產品的兩種服務方式，服務器端是離線使用，云調用是在線使用。例如在某某云上的人臉比對產品，用戶可以直接通過調用API來使用人臉比對，此時算法是部署在某某云服務器中的；用戶也可以在平臺申請人臉比對的私有化部署，將人臉比對算法部署到自己本地的服務器中來使用。銀行類、政府類客戶因為數(shù)據(jù)合規(guī)要求，會使用這種私有化部署的方式。

3.4 權限體系管控內容的場景化

我們已知權限體系要管控的內容以及使用場景，接下來就要細化在每個場景中實際要控制哪些具體項目，以達成管控內容的場景化實現(xiàn)。

3.4.1.云調用場景的控制項

表1

3.4.2.移動端場景的控制項

表2

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

3.4.3.邊緣終端場景的控制項

表3

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

3.4.4.服務器端場景的控制項

表4

備注：在服務器端的場景下，一般會直接控制部署的具體機器，所以“使用主體”會采用設備指紋來進行管控，而采用設備指紋的管控，同時會把裝機量也一并控制起來。

3.5 其他權限策略

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

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

舉個例子：

某客戶和我們簽訂了一年的SDK產品合作合同，我們給該客戶開通了一年期的SDK產品使用權限，客戶在使用SDK時，鑒權模塊會自動把生成好的一年有效期的License文件拉取到本地進行校驗。過了幾天時間，該客戶沒有按照合同履約向我們付款，此時我們需要停止對該客戶的產品使用授權。

在沒有“周期性權限驗證”策略的情況下，此時我們是沒有辦法主動控制那些已經正在使用的SDK權限，因為此時有效的License文件已經在本地存在，本地校驗是可以通過的；

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

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

*我們假設將周期設定為30天和7天

表5

4. PaaS產品的權限體系實現(xiàn)

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

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

圖5

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

同時，再跟大家回顧一下權限體系任務和方式的組合，包括“在線授權-在線鑒權”、“在線授權-離線鑒權”、“離線授權-離線鑒權”。

4.1 API服務形態(tài)

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

4.1.1.核心設計

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

4.1.2.權限體系實現(xiàn)

1）控制項

前文已經描述過云調用場景的控制項（表1）。

2）權限體系載體

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

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

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

圖6

備注：對于API的使用，我們建議業(yè)務方與PaaS平臺的交互采用服務器到服務器加密通信的方式，不要采用業(yè)務方移動端、邊緣終端直接與PaaS平臺服務器通信的方式，后者的通信方式會存在抓包劫持導致密鑰泄露的風險。密鑰一旦泄露，權限就會被盜用。

4.2 SDK服務形態(tài)（難點）

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

4.2.1.核心設計

SDK權限體系的核心設計是通過License文件的分配和校驗以實現(xiàn)授權和鑒權。

4.2.2.權限體系實現(xiàn)

1）權限Key-Value標準協(xié)議

通過核心設計我們知道，SDK權限體系的關鍵是License文件的分配和校驗，而License文件能夠被有效校驗的關鍵就是《權限Key-Value標準協(xié)議》。

所謂《權限Key-Value標準協(xié)議》，是指License文件與SDK之間相互共識的控制項和內容值的標準集合。Key是控制項，正是前文管控內容場景化中表2、表3、表4所列舉的控制項；Value是內容值。我們需要將表2、表3、表4進行歸一化處理，會得出如下標準協(xié)議——

表6

備注：

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

2）權限體系載體

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

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

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

圖7 SDK包簡易架構圖

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

圖8

備注：

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

4）離線鑒權流程圖

圖9

后記

最后再分享一些在設計API和SDK權限體系時的小心得吧。

1. 關于API的密鑰和調用量對賬

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

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

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

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

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

對于離線場景中，數(shù)量只能通過設備指紋來控制，這意味著在我們給出授權前，客戶的機器都是已經生產好或者是準備好的。

認知淺薄，歡迎討論。

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

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