今天談下對API網(wǎng)關(guān)接入的接口服務(wù)進(jìn)行安全管理方面的內(nèi)容。

在原來談Kong網(wǎng)關(guān)的時候，曾經(jīng)談到Kong網(wǎng)關(guān)和安全相關(guān)的插件能力，其中包括了身份認(rèn)證插件：Kong提供了Basic Authentication、Key authentication、OAuth2.0 authentication、Hmac authentication、JWT、LDAP authentication認(rèn)證實現(xiàn)。安全控制插件：ACL（訪問控制）、CORS（跨域資源共享）、動態(tài)SSL、IP限制、爬蟲檢測實現(xiàn)。

這些內(nèi)容相對還是比較抽象，因此準(zhǔn)備重新再整理下對接口的安全管理。

接口安全實際上本身分為了傳輸安全，數(shù)據(jù)安全，訪問控制安全。對于常說的Oauth2.0，JWT，Basic Authentication實際都屬于訪問控制安全范疇。對于訪問控制安全本身又拆分為了認(rèn)證和鑒權(quán)，但是很多時候兩者又在混用，后面再展開。

傳輸安全

對于傳輸安全一般會談到Https和SSL，首先看下基本描述。

HTTPS 全稱Hyper Text Transfer Protocol over SecureSocket Layer），是以安全為目標(biāo)的 HTTP 通道，在HTTP的基礎(chǔ)上通過傳輸加密和身份認(rèn)證保證了傳輸過程的安全性 。

HTTPS 在HTTP 的基礎(chǔ)下加入SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL。對于SSL簡單說明如下：

SSL(Secure Sockets Layer 安全套接字協(xié)議),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。TLS與SSL在傳輸層與應(yīng)用層之間對網(wǎng)絡(luò)連接進(jìn)行加密。

HTTPS 存在不同于 HTTP 的默認(rèn)端口及一個加密/身份驗證層（在 HTTP與 TCP 之間）。這個系統(tǒng)提供了身份驗證與加密通訊方法。

當(dāng)實施Https傳輸安全的時候，就需要設(shè)置SSL證書，對于SSL數(shù)字證書有免費的，但是大部分都是商用和收費的，證書本身也有很大類型，不同類型的加密程度也存在不同。同時證書本身又分為了客戶端和服務(wù)端證書，既可以實施單向，也可以實施雙向。在條件允許的情況下，一般是兩端都需要安裝證書。

數(shù)據(jù)安全

數(shù)據(jù)安全即常說的對數(shù)據(jù)進(jìn)行加密處理。在前面談傳輸安全的時候可以看到對于傳輸?shù)臄?shù)據(jù)已經(jīng)進(jìn)行了加密處理。即如果傳輸?shù)膬?nèi)容被監(jiān)聽或攔截，獲取到的信息是加密后的消息報文。

加密就有加密算法，加密算法又存在密鑰。

明文+加密算法（密鑰）=》密文

對于密鑰本身又分為公鑰和私鑰，在對稱加密方式下兩者是一樣的，但是非對稱加密下兩者不同，公鑰是公開的，任何人都可以用公鑰+算法來對文本進(jìn)行加密，但是只有知道私鑰的人才能夠真正解開密文。

由于傳輸安全本身已經(jīng)進(jìn)行了加密處理，那么在API網(wǎng)關(guān)接入API接口服務(wù)的時候，實際上不涉及到數(shù)據(jù)安全的相關(guān)操作。

如果存在某些場景，即接口的調(diào)用方輸入的數(shù)據(jù)，本身也不希望API網(wǎng)關(guān)能夠看到詳細(xì)的明文，那么這個時候就可以考慮對消息報文進(jìn)行數(shù)據(jù)加密，或者說個別接口如涉及到工資薪酬等信息，那么也需要對個別字段信息進(jìn)行加密處理。

這類數(shù)據(jù)加密接口消費方和接口提供方自己協(xié)商算法并進(jìn)行處理即可，對于API網(wǎng)關(guān)來說并不需要接入到詳細(xì)的數(shù)據(jù)加密過程。

對于API網(wǎng)關(guān)，即使企業(yè)數(shù)據(jù)安全也可以看到，對于消費方將消息報文發(fā)送到API網(wǎng)關(guān)的這段實際是沒有進(jìn)行數(shù)據(jù)加密的，而只能在API網(wǎng)關(guān)和后端Server進(jìn)行數(shù)據(jù)加密。只有消費端在調(diào)用接口的時候就加密才能夠做到端到端數(shù)據(jù)加密。

因此簡單總結(jié)就是：就API網(wǎng)關(guān)來說一般不用參與具體的消息報文的數(shù)據(jù)加密，直接其余Https傳輸安全控制即可。

接口訪問安全

如上圖，先舉一個場景來進(jìn)行說明：

即當(dāng)前ERP接口服務(wù)注冊和接入到API網(wǎng)關(guān)，API網(wǎng)關(guān)暴露接口服務(wù)給CRM，SRM等業(yè)務(wù)系統(tǒng)使用，同時ERP系統(tǒng)本身也有一個前端的微服務(wù)模塊，需要調(diào)用ERP后端微服務(wù)的API接口，而這些接口不用注冊到API網(wǎng)關(guān)，直接走注冊中心方式調(diào)用。

兩層的安全控制

首先要指出的是在引入了API網(wǎng)關(guān)接入和發(fā)布服務(wù)后，實際整體架構(gòu)下面對的是兩層的安全控制。即首先要控制CRM系統(tǒng)對API網(wǎng)關(guān)暴露服務(wù)的安全，同時還需要控制API網(wǎng)關(guān)和前端模塊對后端ERP系統(tǒng)API接口服務(wù)的安全。

ERP提供的API接口的安全

在這里假設(shè)ERP系統(tǒng)后端微服務(wù)模塊一共暴露了50個API接口，但是僅只有10個API接口注冊和接入到了API網(wǎng)關(guān)，其他的40個API接口是ERP前端微服務(wù)模塊訪問使用。

對于ERP前端模塊來說，更多是認(rèn)證操作，只要認(rèn)證通過即可以訪問所有API接口服務(wù)。但是對于API網(wǎng)關(guān)來說，則是認(rèn)證+鑒權(quán)，在認(rèn)證通過后還需要確定具體那些API接口資源可以供API網(wǎng)關(guān)來進(jìn)行調(diào)用。

API封裝后暴露的API接口安全

對于API網(wǎng)關(guān)封裝暴露的接口安全，同樣包括了兩個層面，一個是認(rèn)證，一個是鑒權(quán)。由于API接口服務(wù)本身無狀態(tài)，在這種無狀態(tài)情況下實際認(rèn)證和鑒權(quán)是綁定在一起來完成的。

比如對于CRM系統(tǒng)當(dāng)前對API網(wǎng)關(guān)的接口服務(wù)發(fā)起調(diào)用，實際上需要處理兩個事情。其一是該調(diào)用請求確實是CRM系統(tǒng)發(fā)起的，其二是確定CRM系統(tǒng)是否有調(diào)用這個接口的權(quán)限。

基于IP地址的安全控制

由于API網(wǎng)關(guān)暴露的接口最終使用的是業(yè)務(wù)系統(tǒng)而不是用戶，比如CRM系統(tǒng)，SRM系統(tǒng)。因此可以增加IP地址來進(jìn)行安全控制。

可以提前對每個調(diào)用端系統(tǒng)的IP地址進(jìn)行配置，一個系統(tǒng)可以配置多個地址。

那么當(dāng)某個sysid的系統(tǒng)發(fā)起調(diào)用請求后，我們首先校驗過來的IP地址是否是我們已經(jīng)配置并允許的IP地址，如果校驗通過才放行，否則拒絕。

但是基于IP地址控制本次又存在兩個問題。

其一是IP地址本身可以偽造，其二是在業(yè)務(wù)系統(tǒng)容器化改造后，實際業(yè)務(wù)系統(tǒng)的IP地址是在動態(tài)變化的，這兩點都增加了IP地址控制的難度。

已經(jīng)基本的用戶名密碼來控制

我們給每個系統(tǒng)都分配一個獨立的用戶名和密碼，業(yè)務(wù)系統(tǒng)在調(diào)用API網(wǎng)關(guān)上的接口服務(wù)的時候，在http header里面帶上用戶名和密碼信息。這個信息傳遞到API網(wǎng)關(guān)后，API網(wǎng)關(guān)對用戶名和密碼進(jìn)行校驗，只要驗證通過后才放行。

在這種情況下本身也存在問題。

即用戶名和密碼泄露，但是在實施了Https安全傳輸后，通過Http攔截的方式來獲取到用戶密碼信息已經(jīng)不可能，那么密碼往往是業(yè)務(wù)系統(tǒng)以其它方式出現(xiàn)了泄露。

實際上密碼泄露，只要定期修改密碼即可，這樣已經(jīng)滿足大部分的場景要求。

前端微服務(wù)對后端微服務(wù)API訪問

在這種場景下一般不適合用傳統(tǒng)的Session會話保持方式來進(jìn)行認(rèn)證和鑒權(quán)，因此引入了JWT來實現(xiàn)認(rèn)證和鑒權(quán)。

對于JWT具體介紹參考網(wǎng)上詳細(xì)文章。

簡單解釋下就是對于服務(wù)端認(rèn)證通過的客戶端，服務(wù)端返回一個包含了數(shù)字簽名的Token給客戶端，這個token本事包括了客戶端信息，有效期信息等。以后每次客戶端對服務(wù)端的請求只需要附帶這個Token即可。既只要客戶端認(rèn)證通過了，在Token的有效期里面都可以附帶這個信息來訪問服務(wù)端提供的接口服務(wù)。

JWT Token = Header+Payload+Signature

簡單來說你發(fā)起請求調(diào)用的時候附加我當(dāng)時頒發(fā)給你的Token，里面是含了簽名信息，當(dāng)前我接到請求后，我通過密鑰對簽名信息進(jìn)行驗證，通過后則放行。

這種方法實際和前面談的用戶名密碼感覺并沒有本質(zhì)區(qū)別，因為Token本身也是類似密碼的一種展現(xiàn)方式。那么走JWT方式認(rèn)證鑒權(quán)的好處在哪里？

其一是只需要在認(rèn)證的時候通過用戶名密碼，后續(xù)接口調(diào)用都不用再傳遞密碼，減少了密碼泄露的可能性。其次Token本身有時效性的要求，即使Token信息泄露，往往不會造成太大的影響。

在前面已經(jīng)談到啟用了API網(wǎng)關(guān)后實際存在兩層的安全控制。一個是CRM系統(tǒng)到API網(wǎng)關(guān)的安全，一個是API網(wǎng)關(guān)到ERP系統(tǒng)的安全。

在啟用了JWT后可以看到，如果ERP系統(tǒng)認(rèn)證通過了CRM頒發(fā)了一個Token給CRM系統(tǒng)，CRM系統(tǒng)每次在調(diào)用API網(wǎng)關(guān)接口的時候都附帶了這個Token，API網(wǎng)關(guān)本身會將信息透傳給后端的ERP系統(tǒng)。告訴ERP這個請求調(diào)用實際是你經(jīng)過認(rèn)證的CRM發(fā)起的，可以放行。

因此在這種情況下，我們不用再特意去處理API網(wǎng)關(guān)和ERP系統(tǒng)間的訪問安全性。API網(wǎng)關(guān)在這里只起到了一個代理透傳的作用。

那么CRM系統(tǒng)調(diào)用API網(wǎng)關(guān)接口，API網(wǎng)關(guān)是否轉(zhuǎn)發(fā)該請求？

這個就涉及到了CRM和API網(wǎng)關(guān)之間的安全控制。

消費端系統(tǒng)和API網(wǎng)關(guān)間的訪問安全

如何控制消費端到API網(wǎng)關(guān)的訪問安全，實際道理是一樣的，既可以采用簡單的為每個消費端分配一個用戶名和密碼，進(jìn)行基礎(chǔ)的安全驗證。也可以啟用JWT，通過JWT來進(jìn)行驗證授權(quán)。

如果在API網(wǎng)關(guān)上也啟用JWT，實際是另外一個思路，即變化為兩級的安全控制。

消費方只要通過了API網(wǎng)關(guān)的鑒權(quán)就默認(rèn)可以訪問后端服務(wù)

后端服務(wù)本身只對API網(wǎng)關(guān)進(jìn)行認(rèn)證和鑒權(quán)

這個本身也是一種常用的方式，即對于ERP系統(tǒng)來說實際只需要考慮API網(wǎng)關(guān)的認(rèn)證鑒權(quán)接口，這種情況下完全可以簡化化雙方約定一個key即搞定。

從靜態(tài)Token到動態(tài)Token

在前面談到，即使在采用JWT方式下，如果Token泄露，那么實際上是可以訪問通過的，除非Token本身已經(jīng)失效。因此更加好的方式是動態(tài)Token。

一種動態(tài)Token的生成方法是，每一次的接口調(diào)用消費端都需要從認(rèn)證服務(wù)器獲取到一個僅單次有效的Token，然后將Token傳遞到后端，后端基于Token進(jìn)行驗證。但是這種方式本身會帶來不小的性能損耗。

另外一種動態(tài)Token生成方法可以是消費端和API網(wǎng)關(guān)間約定了一個基于時間作為密鑰的來動態(tài)生成簽名或加密信息的方法。

即：靜態(tài)Token+和時間相關(guān)的Key => 動態(tài)Token

因此消費方在消費接口服務(wù)的時候，會基于當(dāng)前的時間，然后基于雙方約定的規(guī)則來生成一個動態(tài)的Token作為簽名。而信息發(fā)送到API網(wǎng)關(guān)后，API網(wǎng)關(guān)基于同樣的規(guī)則來計算簽名，只有雙方計算出來的結(jié)果一樣的時候，才算驗證通過。

這本身是一種更加嚴(yán)格的安全控制，即接口的調(diào)用中Token隨時都在不斷的變化。

Token的刷新

對于Token一般會設(shè)置有效時間，比如采用JWT方式的時候，Token里面本身就包含了Token本身的有效期信息。如果Token過了有效期，那么即使附帶了Token信息調(diào)用，也會因為Token失效而調(diào)用失敗。

因此需要一種Token的刷新機制。

比如消費端可以在Token過期前主動的調(diào)用接口來獲取一個新的Token值，要獲取新的Token值實際有兩種方式可以選擇。

其一是用初始化的用戶名，密碼來認(rèn)證，認(rèn)證通過后給新Token
其二是基于sysid+oldToken值進(jìn)行調(diào)用，驗證通過后發(fā)放新的Token

在新Token發(fā)放，同時舊的Token本身還沒有過期的時候，實際上兩個Token都應(yīng)該可以調(diào)用成功。這個時候?qū)τ赥oken的驗證應(yīng)該支持這種情況。

接口訪問授權(quán)

前面主要談?wù)J證，比如CRM系統(tǒng)認(rèn)證通過了可以訪問API網(wǎng)關(guān)上的接口服務(wù)。但是并不是說所有的接口服務(wù)都可以訪問。

接口服務(wù)本身是一種資源，滿足基于資源的授權(quán)模型。

因此可以進(jìn)行細(xì)粒度的接口服務(wù)授權(quán)，比如ERP提供提供了A到D四個接口服務(wù)。但是在API網(wǎng)關(guān)上可以控制或授權(quán)CRM系統(tǒng)只能夠訪問A和B兩個接口。

如果CRM系統(tǒng)發(fā)起多D服務(wù)的訪問，即在API網(wǎng)關(guān)層級就鑒權(quán)不通過而拒絕。

前面談到在API網(wǎng)關(guān)的訪問安全管理里面，往往認(rèn)證和授權(quán)兩個事情是同步完成的，即首先驗證過來的請求是CRM系統(tǒng)的，沒有仿冒。其次再進(jìn)一步驗證CRM系統(tǒng)對某個接口是否有訪問權(quán)限。當(dāng)前也可以參考RBAC模型方式，對一類業(yè)務(wù)系統(tǒng)或一組接口服務(wù)統(tǒng)一進(jìn)行授權(quán)。

OAuth2.0安全控制

OAuth是Open Authorization的簡寫。

OAuth協(xié)議為用戶資源的授權(quán)提供了一個安全的、開放而又簡易的標(biāo)準(zhǔn)。與以往的授權(quán)方式不同之處是OAuth的授權(quán)不會使第三方觸及到用戶的帳號信息（如用戶名與密碼），即第三方無需使用用戶的用戶名與密碼就可以申請獲得該用戶資源的。

在前面已經(jīng)談到了API網(wǎng)關(guān)和后端系統(tǒng)間是一套獨立的安全機制，API網(wǎng)關(guān)對后端系統(tǒng)服務(wù)的訪問并不是說需要前端CRM系統(tǒng)授權(quán)通過才可以。同時對于API網(wǎng)關(guān)在整個微服務(wù)架構(gòu)下仍然是和內(nèi)部IT系統(tǒng)在一個大的部署域內(nèi)。

因此大部分場景下，API網(wǎng)關(guān)并不涉及到OAuth2.0的安全認(rèn)證和控制，也沒必要啟用。如果考慮到不應(yīng)該在API網(wǎng)關(guān)存儲過重的業(yè)務(wù)系統(tǒng)用戶名，密碼等信息，那么直接和啟用內(nèi)部的LDAP統(tǒng)一認(rèn)證中心進(jìn)行集成即可。