如何設(shè)計B端SDK和API的激活與安全機制?

1 評論 10495 瀏覽 110 收藏 14 分鐘

在C端流量紅利逐漸消失的今天,很多企業(yè)開始轉(zhuǎn)向 to B的生意。

而B端的生意就離不開SDK和API。這是公司對外輸出技術(shù)方案必不可少的兩種不同的形式。

因此,本文將結(jié)合SDK和API進行介紹,分析它們的區(qū)別以及如何設(shè)置激活與安全機制。

1. SDK和API的區(qū)別

首先我們簡單來講一下SDK和API的區(qū)別。

1.1 什么是API?

API,全稱Application Programming Interface,即應(yīng)用程序編程接口。

API其實就是把做好的功能,封裝成各種預(yù)先定義好的函數(shù),其他人想使用這些已有的功能,只需要調(diào)用這些函數(shù),并傳遞必要的參數(shù)即可。

API的主要作用是,程序員不需要深究API背后功能實現(xiàn)的具體邏輯,程序員只需要直接調(diào)用API就可以使用其背后的功能邏輯,這節(jié)省了程序員一大部分的工作,大大提升了效率。

舉個例子:

銀行的窗口就類似一個個的API,他們分別有不同的功能,比如取款、存款、對公等業(yè)務(wù)。

而我們預(yù)先填好的表格信息,交給窗口的工作人員,就是傳遞必要的“參數(shù)”信息給這個窗口API,然后使用它的存款功能。

我們不需要理解工作人員具體需要哪些操作,其中涉及多少復(fù)雜邏輯。

只需要來到窗口(調(diào)用API),上交表格(傳遞必要信息)就能使用該功能服務(wù)。

1.2 什么是SDK?

SDK 就是 Software Development Kit 的縮寫,翻譯過來——軟件開發(fā)工具包。

這是一個覆蓋面相當廣泛的名詞,可以這么說:輔助開發(fā)某一類軟件的相關(guān)文檔、范例和工具的集合都可以叫做SDK。

SDK可以簡單的認為是一系列API的程序包集合。在這個程序包中是一個完整的軟件功能,這份程序包幾乎是全封閉的,只有一個小小接口(API)可以聯(lián)通外界。

還是剛剛銀行的例子:

可以把銀行看做是一整個SDK,銀行SDK程序包能幫你完成存款、取款等業(yè)務(wù)。

銀行SDK唯一聯(lián)通外界的就是它的大門,或者說是取號機(API),只有進入銀行然后取號,才能在不同的窗口辦理服務(wù)。

而這些不同的窗口,就可以看成一個個不同功能的API接口。

2. API的接入安全機制

安全機制,其實是為了保護我方后臺,主要有兩點:

  1. 不被不明身份者訪問
  2. 不被惡意大量的請求攻擊

先來簡單說一下API的接入安全機制。

API的安全機制設(shè)計主要考慮兩個方面:

  1. API接入方案如何避免接口盜用(防止不明身份者訪問)
  2. Http接口請求如何避免攻擊(防止被惡意大量請求攻擊)

第一個方面,需要客戶對自家的后臺做一層封裝,然后我們后臺僅接受客戶后臺接口傳遞的請求。

第二個方面,需要在我方后臺建立IP白名單,提供給客戶后臺,方便雙方進行加密驗證。識別哪些是客戶的請求,哪些是惡意請求。

3. SDK的接入安全機制

為了防止客戶拿到我們的SDK以后白嫖,或者為所欲為,我們需要在客戶接入SDK,請求我方服務(wù)的時候進行激活校驗。

就像是我們買票進站乘車一樣,需要出示身份證和車票進行校驗方可通過。

SDK最終都是會被集成到硬件設(shè)備中提供服務(wù),尤其是AI公司的技術(shù)方案,不管是視覺還是語音,最后交付的都是硬件產(chǎn)品。

通常激活的時機,都是在硬件設(shè)備進行第一次啟動的時候進行。

SDK的激活涉及到我方對客戶的計費,所以激活邏輯的設(shè)計要非常的仔細和嚴謹(畢竟都是錢哪。。)

一般來說,SDK的激活方案可以分為三種(以下說法參考思必馳的產(chǎn)品授權(quán)方案):

  1. 預(yù)燒錄
  2. 預(yù)登記
  3. 動態(tài)注冊

預(yù)燒錄,指的是,我們后臺預(yù)先生成授權(quán)的license文件,然后預(yù)先寫入硬件設(shè)備的存儲文件中。在設(shè)備首次啟動的時候,就直接調(diào)取license文件進行激活。這種方式適用于需要不聯(lián)網(wǎng)提供服務(wù)的場景。

預(yù)登記,指的是,預(yù)先登記設(shè)備白名單,以用戶設(shè)備注冊激活的一種授權(quán)方式。這種方式適用于客戶提前知道所需授權(quán)設(shè)備的設(shè)備標識的場景

動態(tài)注冊,指的是,每次設(shè)備激活,后臺動態(tài)給這些設(shè)備進行激活并注冊的一種形式。這種方式適用于客戶可以提供設(shè)備的唯一標識,但是提前不知道哪些設(shè)備需要授權(quán),不知道有多少設(shè)備需要授權(quán)的場景。

下面想主要講一下,我在設(shè)計預(yù)登記和動態(tài)注冊時遇到的一些坑。

3.1 預(yù)登記對我方友好,但是對客戶不太靈活

預(yù)登記方式其實對我方來說是比較友好的,因為客戶提前提供準確的設(shè)備唯一標識的時候,我們可以很方面的進行激活和統(tǒng)計,說直白點,就是方便收錢。

所以,客戶為了省錢,有可能采取作弊策略:將一個設(shè)備的唯一標識給多臺設(shè)備進行使用

因為設(shè)備標識,一般是設(shè)備序列號(SN),對于硬件廠商來說是可以自己按照一定的規(guī)則隨便刷的。

那為了防止被客戶白嫖,我們自然要設(shè)計一套防作弊策略:不僅僅采集客戶提供的設(shè)備序列號,還要采集一些設(shè)備的其他信息進行輔助判斷,該序列號只綁定了一臺設(shè)備。

當客戶想白嫖我們,將設(shè)備A的序列號給設(shè)備B使用,那么在激活校驗的時候,就會發(fā)現(xiàn)設(shè)備B的序列號關(guān)聯(lián)的信息和我們記錄的信息(設(shè)備A)不同,如此就可以認定客戶是想白嫖,激活失敗。

上述方式看起來比較完美的解決了客戶作弊的問題。但是對于部分客戶來說就會造成不便。

有些客戶在對接SDK后,會進行測試。在測試的過程中,客戶會不斷的對硬件設(shè)備進行刷機、恢復(fù)出廠設(shè)置等騷操作。

而刷機、恢復(fù)出廠設(shè)置會改變設(shè)備的信息(例如AndroidID),那么就會造成同樣的序列號在同一臺設(shè)備上不能激活了。

因為刷機改變了它的設(shè)備信息,我們會認為這不是同一臺設(shè)備。

你可能會說,那客戶再寫一個序列號不就行了,反正客戶可以自己刷序列號。

客戶是上帝,你不能指望客戶去干這樣的累活。當然是我們來優(yōu)化了。

為了解決這個問題,我們想到一個方案:超級序列號。這個序列號必須是我們來生成(可控),擁有無限次激活,可以在多臺設(shè)備上使用的超能力。

但是為了防止客戶拿這個超級序列號白嫖我們,我們需要給這個超級序列號設(shè)置時間限制。在有效時間內(nèi)可以隨意使用,一旦過了有效期就會失效。

3.2 動態(tài)注冊雖然靈活,但是對于統(tǒng)計來說麻煩

動態(tài)注冊就是在設(shè)備第一次啟動激活的時候,上傳設(shè)備的信息,包括:序列號、MAC(藍牙+WiFi)、IMEI和AndroidID。

但是這些信息不一定能獲取到。

IMEI,國際移動設(shè)備識別碼(International Mobile Equipment Identity,IMEI)

IMEI本該最理想的設(shè)備ID,具備唯一性,恢復(fù)出廠設(shè)置不會變化(真正的設(shè)備相關(guān))。

但是Android6.0以后,就需要用戶授權(quán)才能使用,而且在Android10.0以后,就會徹底拒絕獲取IMEI。

并且,IMEI其實只有通訊的設(shè)備才會有,如果沒有通訊(簡單理解,就是電話卡)模塊的話,也不一定有IMEI號。

序列號(SN)

設(shè)備序列號由廠商提供,如果廠商比較規(guī)范的話,序列號應(yīng)該是唯一的,也不會隨刷機或恢復(fù)出廠設(shè)置等改變。

但是你不能把利益建立在人性的基礎(chǔ)上,那太不靠譜。所以序列號,其實更多只能作為輔助信息來進行判斷。

MAC地址

MAC地址一般指藍牙MAC、WiFi Mac或者是兩者的拼接。但是獲取同樣需要權(quán)限,而且如果設(shè)備沒有藍牙模塊,沒有WiFi模塊的話,也不一定有MAC地址。

Android ID

Android ID 是獲取門檻最低的,不需要任何權(quán)限,64bit 的取值范圍,唯一性算是很好的了。但是不足之處也很明顯:刷機、root、恢復(fù)出廠設(shè)置等會使得 Android ID 改變

所以,我們在設(shè)計動態(tài)注冊激活邏輯的時候,就需要考慮到這些情況。

動態(tài)注冊的激活邏輯,就是每次激活的時候,后臺記錄設(shè)備上傳的四個設(shè)備信息(有的不一定有)。

然后每次其他設(shè)備激活的時候,就把該要激活的設(shè)備信息在已激活的設(shè)備信息記錄中進行比對,比對的規(guī)則有兩方面:

  1. 所上報的設(shè)備信息種類是否一致,種類指的是四種設(shè)備信息
  2. 所上報的設(shè)備信息是否一致

這樣的激活邏輯,雖然能保證最大程度的識別出不同的設(shè)備,但是會給統(tǒng)計激活設(shè)備上(統(tǒng)計是為了收錢)造成麻煩。

例如,AndroidID,會隨著刷機、恢復(fù)出廠設(shè)置而改變。這就會成為客戶扯皮的點。

客戶會說:“我并沒有更換設(shè)備,只是因為設(shè)備故障需要刷機或者恢復(fù)出廠設(shè)置,你就多收我一臺設(shè)備的錢,當我是冤大頭嗎?”

雖然這可以通過商務(wù)的手段去解決,但是還是那句話,客戶是霸霸嘛。

其實,從上面我們描述四大設(shè)備信息的特征來看,AndroidID具有如下優(yōu)秀屬性:

  1. 一定能獲取到;
  2. 只有刷機操作才會改變,無法人為指定。

所以,完全可以以AndroidID作為主要依據(jù),只要AndroidID一致,不管其他參數(shù)種類和參數(shù)值是否相同,都可以認為是一臺設(shè)備。

我們只需要找出那些,因為刷機或恢復(fù)出廠設(shè)置導(dǎo)致AndroidID改變的設(shè)備,而這些是客戶扯皮的主要部分。

因此,在我們給設(shè)備動態(tài)注冊的時候,要采用嚴格的規(guī)則,只要有一點不一樣,就重新注冊設(shè)備信息。

但是在統(tǒng)計激活的設(shè)備信息上,可以根據(jù)一定的規(guī)則,將具有爭議的注冊設(shè)備信息給統(tǒng)計出來,做到扯皮也是要有準備和技術(shù)含量的。

SDK 和 API 是公司輸出技術(shù)的主要手段,而如何設(shè)計激活邏輯和安全機制,是保證公司不被白嫖的手段,需要認真和謹慎的考慮。

以上內(nèi)容是在工作中的一些總結(jié),僅供大家參考。

 

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

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 看到這篇文章真的是深有同感,其實就是考慮在線激活和離線激活且兩種形式并存,并且需要考慮客戶頻繁刷機導(dǎo)致的激活碼失效問題,補充一下,超級序列號的話可以寫個程序,監(jiān)控同一個設(shè)備序列號激活的次數(shù),如果發(fā)現(xiàn)這臺設(shè)備序列號在一天內(nèi)或者幾天內(nèi)激活了很多次,超過了設(shè)置的閾值,就可以視為異常,讓商務(wù)上門吧

    來自廣東 回復(fù)