今天談下對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網關是否轉發該請求？

這個就涉及到了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統一認證中心進行集成即可。