今天談下對API閘道器接入的介面服務進行安全管理方面的內容。

在原來談Kong閘道器的時候，曾經談到Kong閘道器和安全相關的外掛能力，其中包括了身份認證外掛：Kong提供了Basic Authentication、Key authentication、OAuth2.0 authentication、HMAC authentication、JWT、LDAP authentication認證實現。安全控制外掛：ACL（訪問控制）、CORS（跨域資源共享）、動態SSL、IP限制、爬蟲檢測實現。

這些內容相對還是比較抽象，因此準備重新再整理下對介面的安全管理。

介面安全實際上本身分為了傳輸安全，資料安全，訪問控制安全。對於常說的Oauth2.0，JWT，Basic Authentication實際都屬於訪問控制安全範疇。對於訪問控制安全本身又拆分為了認證和鑑權，但是很多時候兩者又在混用，後面再展開。

傳輸安全

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

HTTPS 全稱Hyper Text Transfer Protocol over SecureSocket Layer），是以安全為目標的 HTTP 通道，在HTTP的基礎上透過傳輸加密和身份認證保證了傳輸過程的安全性 。

HTTPS 在HTTP 的基礎下加入SSL 層，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL。對於SSL簡單說明如下：

SSL(Secure Sockets Layer 安全套接字協議),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網路通訊提供安全及資料完整性的一種安全協議。TLS與SSL在傳輸層與應用層之間對網路連線進行加密。

HTTPS 存在不同於 HTTP 的預設埠及一個加密/身份驗證層（在 HTTP與 TCP 之間）。這個系統提供了身份驗證與加密通訊方法。

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

資料安全

資料安全即常說的對資料進行加密處理。在前面談傳輸安全的時候可以看到對於傳輸的資料已經進行了加密處理。即如果傳輸的內容被監聽或攔截，獲取到的資訊是加密後的訊息報文。

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

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

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

由於傳輸安全本身已經進行了加密處理，那麼在API閘道器接入API介面服務的時候，實際上不涉及到資料安全的相關操作。

如果存在某些場景，即介面的呼叫方輸入的資料，本身也不希望API閘道器能夠看到詳細的明文，那麼這個時候就可以考慮對訊息報文進行資料加密，或者說個別介面如涉及到工資薪酬等資訊，那麼也需要對個別欄位資訊進行加密處理。

這類資料加密介面消費方和介面提供方自己協商演算法並進行處理即可，對於API閘道器來說並不需要接入到詳細的資料加密過程。

對於API閘道器，即使企業資料安全也可以看到，對於消費方將訊息報文傳送到API閘道器的這段實際是沒有進行資料加密的，而只能在API閘道器和後端Server進行資料加密。只有消費端在呼叫介面的時候就加密才能夠做到端到端資料加密。

因此簡單總結就是：就API閘道器來說一般不用參與具體的訊息報文的資料加密，直接其餘Https傳輸安全控制即可。

介面訪問安全

如上圖，先舉一個場景來進行說明：

即當前ERP介面服務註冊和接入到API閘道器，API閘道器暴露介面服務給CRM，SRM等業務系統使用，同時ERP系統本身也有一個前端的微服務模組，需要呼叫ERP後端微服務的API介面，而這些介面不用註冊到API閘道器，直接走註冊中心方式呼叫。

兩層的安全控制

首先要指出的是在引入了API閘道器接入和釋出服務後，實際整體架構下面對的是兩層的安全控制。即首先要控制CRM系統對API閘道器暴露服務的安全，同時還需要控制API閘道器和前端模組對後端ERP系統API介面服務的安全。

ERP提供的API介面的安全

在這裡假設ERP系統後端微服務模組一共暴露了50個API介面，但是僅只有10個API介面註冊和接入到了API閘道器，其他的40個API介面是ERP前端微服務模組訪問使用。

對於ERP前端模組來說，更多是認證操作，只要認證透過即可以訪問所有API介面服務。但是對於API閘道器來說，則是認證+鑑權，在認證通過後還需要確定具體那些API介面資源可以供API閘道器來進行呼叫。

API封裝後暴露的API介面安全

對於API閘道器封裝暴露的介面安全，同樣包括了兩個層面，一個是認證，一個是鑑權。由於API介面服務本身無狀態，在這種無狀態情況下實際認證和鑑權是繫結在一起來完成的。

比如對於CRM系統當前對API閘道器的介面服務發起呼叫，實際上需要處理兩個事情。其一是該呼叫請求確實是CRM系統發起的，其二是確定CRM系統是否有呼叫這個介面的許可權。

基於IP地址的安全控制

由於API閘道器暴露的介面最終使用的是業務系統而不是使用者，比如CRM系統，SRM系統。因此可以增加IP地址來進行安全控制。

可以提前對每個呼叫端系統的IP地址進行配置，一個系統可以配置多個地址。

那麼當某個sysid的系統發起呼叫請求後，我們首先校驗過來的IP地址是否是我們已經配置並允許的IP地址，如果校驗透過才放行，否則拒絕。

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

其一是IP地址本身可以偽造，其二是在業務系統容器化改造後，實際業務系統的IP地址是在動態變化的，這兩點都增加了IP地址控制的難度。

已經基本的使用者名稱密碼來控制

我們給每個系統都分配一個獨立的使用者名稱和密碼，業務系統在呼叫API閘道器上的介面服務的時候，在http header裡面帶上使用者名稱和密碼資訊。這個資訊傳遞到API閘道器後，API閘道器對使用者名稱和密碼進行校驗，只要驗證通過後才放行。

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

即使用者名稱和密碼洩露，但是在實施了Https安全傳輸後，透過Http攔截的方式來獲取到使用者密碼資訊已經不可能，那麼密碼往往是業務系統以其它方式出現了洩露。

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

前端微服務對後端微服務API訪問

在這種場景下一般不適合用傳統的Session會話保持方式來進行認證和鑑權，因此引入了JWT來實現認證和鑑權。

對於JWT具體介紹參考網上詳細文章。

簡單解釋下就是對於服務端認證透過的客戶端，服務端返回一個包含了數字簽名的Token給客戶端，這個token本事包括了客戶端資訊，有效期資訊等。以後每次客戶端對服務端的請求只需要附帶這個Token即可。既只要客戶端認證通過了，在Token的有效期裡面都可以附帶這個資訊來訪問服務端提供的介面服務。

JWT Token = Header+Payload+Signature

簡單來說你發起請求呼叫的時候附加我當時頒發給你的Token，裡面是含了簽名信息，當前我接到請求後，我透過金鑰對簽名信息進行驗證，通過後則放行。

這種方法實際和前面談的使用者名稱密碼感覺並沒有本質區別，因為Token本身也是類似密碼的一種展現方式。那麼走JWT方式認證鑑權的好處在哪裡？

其一是隻需要在認證的時候透過使用者名稱密碼，後續介面呼叫都不用再傳遞密碼，減少了密碼洩露的可能性。其次Token本身有時效性的要求，即使Token資訊洩露，往往不會造成太大的影響。

在前面已經談到啟用了API閘道器後實際存在兩層的安全控制。一個是CRM系統到API閘道器的安全，一個是API閘道器到ERP系統的安全。

在啟用了JWT後可以看到，如果ERP系統認證通過了CRM頒發了一個Token給CRM系統，CRM系統每次在呼叫API閘道器介面的時候都附帶了這個Token，API閘道器本身會將資訊透傳給後端的ERP系統。告訴ERP這個請求呼叫實際是你經過認證的CRM發起的，可以放行。

因此在這種情況下，我們不用再特意去處理API閘道器和ERP系統間的訪問安全性。API閘道器在這裡只起到了一個代理透傳的作用。

這個就涉及到了CRM和API閘道器之間的安全控制。

消費端系統和API閘道器間的訪問安全

如何控制消費端到API閘道器的訪問安全，實際道理是一樣的，既可以採用簡單的為每個消費端分配一個使用者名稱和密碼，進行基礎的安全驗證。也可以啟用JWT，透過JWT來進行驗證授權。

如果在API閘道器上也啟用JWT，實際是另外一個思路，即變化為兩級的安全控制。

消費方只要通過了API閘道器的鑑權就預設可以訪問後端服務

後端服務本身只對API閘道器進行認證和鑑權

這個本身也是一種常用的方式，即對於ERP系統來說實際只需要考慮API閘道器的認證鑑權介面，這種情況下完全可以簡化化雙方約定一個key即搞定。

從靜態Token到動態Token

在前面談到，即使在採用JWT方式下，如果Token洩露，那麼實際上是可以訪問透過的，除非Token本身已經失效。因此更加好的方式是動態Token。

一種動態Token的生成方法是，每一次的介面呼叫消費端都需要從認證伺服器獲取到一個僅單次有效的Token，然後將Token傳遞到後端，後端基於Token進行驗證。但是這種方式本身會帶來不小的效能損耗。

另外一種動態Token生成方法可以是消費端和API閘道器間約定了一個基於時間作為金鑰的來動態生成簽名或加密資訊的方法。

即：靜態Token+和時間相關的Key => 動態Token

因此消費方在消費介面服務的時候，會基於當前的時間，然後基於雙方約定的規則來生成一個動態的Token作為簽名。而資訊傳送到API閘道器後，API閘道器基於同樣的規則來計算簽名，只有雙方計算出來的結果一樣的時候，才算驗證透過。

這本身是一種更加嚴格的安全控制，即介面的呼叫中Token隨時都在不斷的變化。

Token的重新整理

對於Token一般會設定有效時間，比如採用JWT方式的時候，Token裡面本身就包含了Token本身的有效期資訊。如果Token過了有效期，那麼即使附帶了Token資訊呼叫，也會因為Token失效而呼叫失敗。

因此需要一種Token的重新整理機制。

比如消費端可以在Token過期前主動的呼叫介面來獲取一個新的Token值，要獲取新的Token值實際有兩種方式可以選擇。

其一是用初始化的使用者名稱，密碼來認證，認證通過後給新Token其二是基於sysid+oldToken值進行呼叫，驗證通過後發放新的Token

在新Token發放，同時舊的Token本身還沒有過期的時候，實際上兩個Token都應該可以呼叫成功。這個時候對於Token的驗證應該支援這種情況。

介面訪問授權

前面主要談認證，比如CRM系統認證通過了可以訪問API閘道器上的介面服務。但是並不是說所有的介面服務都可以訪問。

介面服務本身是一種資源，滿足基於資源的授權模型。

因此可以進行細粒度的介面服務授權，比如ERP提供提供了A到D四個介面服務。但是在API閘道器上可以控制或授權CRM系統只能夠訪問A和B兩個介面。

如果CRM系統發起多D服務的訪問，即在API閘道器層級就鑑權不透過而拒絕。

前面談到在API閘道器的訪問安全管理裡面，往往認證和授權兩個事情是同步完成的，即首先驗證過來的請求是CRM系統的，沒有仿冒。其次再進一步驗證CRM系統對某個介面是否有訪問許可權。當前也可以參考RBAC模型方式，對一類業務系統或一組介面服務統一進行授權。

OAuth2.0安全控制

OAuth是Open Authorization的簡寫。

OAuth協議為使用者資源的授權提供了一個安全的、開放而又簡易的標準。與以往的授權方式不同之處是OAuth的授權不會使第三方觸及到使用者的帳號資訊（如使用者名稱與密碼），即第三方無需使用使用者的使用者名稱與密碼就可以申請獲得該使用者資源的。

在前面已經談到了API閘道器和後端系統間是一套獨立的安全機制，API閘道器對後端系統服務的訪問並不是說需要前端CRM系統授權透過才可以。同時對於API閘道器在整個微服務架構下仍然是和內部IT系統在一個大的部署域內。

因此大部分場景下，API閘道器並不涉及到OAuth2.0的安全認證和控制，也沒必要啟用。如果考慮到不應該在API閘道器儲存過重的業務系統使用者名稱，密碼等資訊，那麼直接和啟用內部的LDAP統一認證中心進行整合即可。