從五個方面入手，保障微服務應用安全

隨著計算機、網際網路技術的飛速發展，資訊保安已然是一個全民關心的問題，也是各大企業非常重視的問題。企業一般會從多個層次著手保障資訊保安，如：物理安全、網路安全、系統安全(主機和作業系統)、應用安全等。

對於應用程式安全，需要在應用架構、程式碼、運維、管理等多個角度進行安全性評估，在整個應用程式生命週期中，軟體工程師們則主要負責 身份驗證、訪問授權、程式間通訊安全、程式碼安全、安全的管理與審計這五方面的方案落地。這五個方面中，前三個側重於技術實現，程式碼安全、管理與審計則更需要規範的管理和執行，本文將著重對認證、授權、通訊等技術相關內容重點介紹，管理規範相關內容僅做簡單說明。

文中以採用了微服務架構的應用程式為背景進行描述，但多數的應用程式的安全方案與是否採用微服務架構並沒有強關聯，如有差異的地方，文中會提出來。文中描述過程中會涉及到一些微服務架構中相關的概念名詞，說明如下：

名詞	解釋說明
應用	即應用程式，本文中特指一個微服務應用
業務系統	即傳統意義上的軟體系統，如：OA辦公系統、個貸系統等。微服務架構中，業務系統不是個業務邏輯概念，一個業務系統由一個或多個應用（微服務）組成。
閘道器	即API Gateway 是客戶端訪問應用的入口，後端應用的API門戶。通常負責身份認證、API管理、路由、編排等等
服務	即API，特指程式介面 ，如服務呼叫 即為 API呼叫。需注意在本文中不要與微服務、應用等概念混淆
認證管理系統	認證管理系統（IAM），負責身份識別和訪問管理，其核心業務是應用系統的訪問者的註冊、賬號密碼憑證、訪問者基本資訊的管理和對已註冊的訪問者進行合法性認證和訪問授權。
授權服務	指身份認證授權服務，在微服務架構中，通常是認證管理系統（IAM）的一個應用。認證中心具備讀取"訪問者"身份資訊的許可權。負責核實"訪問者"的身份、為訪問者頒發授權碼、訪問令牌等能力
訪問者	在安全領域統稱" Principal"，指應用程式功能UI或API的使用者，包含兩類：1，基於登入的客戶端    2，API 客戶端
API客戶端	API Client 即客戶端程式型別的訪問者，這類客戶端自身具備部分API的訪問許可權，不需要使用者授予其訪問許可權。
基於登入的客戶端	Login-based Client ，使用者訪問服務提供者的應用程式的功能時，需要通過一個客戶端互動介面來與服務提供者互動，使用者需要先登入，然後由客戶端代表使用者身份去訪問服務提供者應用程式。

微服務架構中安全訪問相關的簡化版的執行檢視如下：

執行檢視

圖中星號 *標註的位置就是服務呼叫過程中安全訪問過程中的一些需要認證鑑權的關鍵位置，如：內外部訪問認證、令牌驗證與授權、內外網通訊協議等。後續章節將對這部分展開分析。

1.身份認證

多數業務功能類的應用的首要任務就是需要做身份認證。對於資料公開或新聞釋出類的入口網站類應用不需要考慮這一點，他們更關注的是資料開放之前的管理和審批。

身份認證或身份驗證(Authentication)，顧名思義就是對應用程式的"訪問者"的身份進行驗證識別。訪問者分兩類。

• 基於使用者登入的客戶端(Login-based Client)：使用者訪問服務提供者的應用程式的功能時，需要通過一個客戶端互動介面來與服務提供者互動，使用者需要先登入，然後由客戶端代表使用者身份去訪問服務提供者應用程式。

• API 客戶端(API Client)：客戶端程式型別的訪問者，這類客戶端自身具備部分API的訪問許可權，不需要使用者授予其訪問許可權。

1. 使用認證管理系統IAM進行訪問者註冊認證

不論是使用者還是API客戶端，在訪問應用之前，均需要先到 認證管理系統IAM進行註冊，以建立其的身份憑證(使用者賬號和密碼、客戶端ID和密碼)。有了身份憑證，才能通過認證服務的驗證。

統一認證管理系統IAM(Identity and Access Management ) 負責身份識別和訪問管理，其核心業務是應用系統的訪問者的註冊、賬號密碼憑證、訪問者基本資訊的管理、對已註冊的訪問者進行合法性認證和訪問的初級授權(獲取訪問者自身資料)等等。

有些企業還會將組織機構、角色甚至業務功能許可權資料也一併歸入IAM系統管理。IAM對許可權管理範圍可大可小，不同企業的管理需求和力度也不一樣，需要集中進行功能授權管理還是下放到業務系統中自治各有優缺點，選擇合適自己的方式就好。

2. IAM認證管理系統使用OAuth2.0進行訪問者授權

傳統WEB應用對於使用者登入訪問，採用會話狀態在服務端儲存的方案，使用者請求通常採用會話粘滯(Sticky session)或會話複製(Replication session)策略，來保持客戶端和服務端的會話。為了會話共享而不得不將會話資訊寫入公共快取或資料庫，導致微服務應用之間產生了耦合性。

微服務架構中不推薦採用服務端儲存會話的方式，如果引入狀態管理不是必要的，那麼應用盡量保持無狀態執行。推薦使用另外一種基於訪問令牌的模式，這種模式下應用中不需要儲存會話狀態，並且API客戶端和基於登入的客戶端均方便使用訪問令牌。微服務架構推薦使用OAuth2.0 授權協議來搭建IAM系統。Spring 體系可以基於Spring Security OAuth實現授權伺服器和客戶端。

在本文的上下文中，面向的是企業基於微服務的總體架構進行方案設計，企業整體架構中，預設認證體系方案為企業統一認證而非業務系統各自認證（此方案的前提條件）。OAuth2.0本身是為三方授權而設計的，而在本方案中討論的是企業內部應用的整體認證和授權，不存在第三方。因此本方案中基於OAuth2.0實現的授權服務可以簡單理解為僅為IAM統一認證管理系統中的“賬號管理應用資源提供者”做授權，並且預設實現為認證通過自動授予已登入賬號資料的讀寫許可權，不在登入通過後與使用者互動確認是否同意授權。其他業務系統作為資源提供者的授權則是系統管理員預置好的授權，也不需要由使用者登入時決定是否授權。這個OAuth2.0的使用場景可能與其他OAuth2.0相關資料或授權框架預設實現有所不同，請大家注意區分。

OAuth協議中定義了四種角色：

• 資源所有者

  能夠許可對受保護資源的訪問許可權的實體。當資源所有者是個人時，它被稱為終端使用者。

• 資源伺服器

  託管受保護資源的伺服器，能夠接收和響應使用訪問令牌對受保護資源的請求。

• 客戶端

  使用資源所有者的授權代表資源所有者發起對受保護資源的請求的應用程式。術語“客戶端”並非特指任何特定的的實現特點(例如：應用程式是否是在伺服器、桌上型電腦或其他裝置上執行)。

• 授權伺服器

  在成功驗證資源所有者且獲得授權後頒發訪問令牌給客戶端的伺服器。

角色分析：

• 對於前面提到的API 客戶端，自身具備API訪問權，不需要使用者授權，因此在OAuth角色對應時，它 既是客戶端又是資源所有者。

• 微服務架構中Web應用一般採用前後端分離的模式，前端為基於瀏覽器訪問的純前端應用，閘道器作為應用程式的入口，此時 閘道器本身可以代表OAuth中的客戶端身份訪問服務提供端應用的功能介面。

• 在微服務架構中，負責頒發訪問令牌的授權服務通常在IAM系統中實現

• 資源伺服器，在微服務架構中，所有的業務系統中的服務功能提供者都是資源伺服器，也包括IAM系統的賬號、組織機構服務、資源許可權管理服務等等

在OAuth2.0授權協議中，主要定義了四種許可型別：授權碼許可、簡單許可、密碼憑據許可和客戶端憑據許可，詳細請參見規範內容： rfc6749 - The OAuth 2.0 Authorization Framework

（https://tools.ietf.org/html/rfc6749）

下面我們根據訪問者型別，分別推薦合適的授權方案。

2.1 API客戶端作為訪問者，使用客戶端憑證許可

典型的API客戶端如批量排程系統、物聯網裝置程式等，通常不需要使用者登入授權就可以自動執行。使用客戶端憑證許可型別比較適合。

客戶端憑證

上圖為OAuth2.0規範標準流程圖，結合此場景中，對應OAuth2.0中的角色，API客戶端作為OAuth2.0的客戶端、IAM則為授權伺服器。

• (A) API客戶端與授權伺服器IAM進行身份驗證並請求訪問令牌。

• (B) 授權伺服器IAM對API客戶端進行身份驗證，如果有效，頒發訪問令牌。客戶端儲存訪問令牌，在後 續的請求過程中使用。如果令牌過期或失效或需要重複此流程再次申請訪問令牌。

其他說明：

1. 此類應用通常不具備與使用者互動的UI，無需使用者授權，具備保證客戶端憑證安全的能力

2. 此類應用後端需要具備通過https訪問授權伺服器的能力

3. 此類應用或裝置需要具備儲存Access Token的能力

2.2 基於登入的客戶端作為訪問者，使用授權碼許可

2.2.1 Web 應用 OAuth2.0 協議中提出前端單頁Web應用可以用簡單許可模式，但簡單許可模式有些侷限性，令牌到期就需要重新登入授權，不支援令牌重新整理，使用者體驗較差。很多使用簡單授權的應用為了改善使用者體驗會頒發一個長期的令牌幾天甚至幾周。

如果有條件使用授權碼模式，支援重新整理令牌則是一個更好的選擇。對訪問令牌時間較短如2分鐘，重新整理令牌為一次性令牌有效期略長如30分，如果存在已作廢的重新整理令牌換取訪問令牌的請求，授權端點也能夠及時發現做出相應入侵處理，如登出該使用者的所有重新整理令牌。在保持良好使用者體驗的同時還兼顧了部分安全性。

本場景以微服務架構中常見的前後端分離Web應用作為示例，前端是單頁應用，閘道器作為Web後臺是服務提供端應用功能入口，也可作為OAuth2.0的客戶端，讓前端Web應用能借助閘道器實現授權碼交換。因此在微服務架構中，即便是純前端單頁應用類的Web應用，仍可以用基於閘道器互動的授權碼模式獲取訪問令牌。其他非前後端分離的混合Web應用自身就是客戶端，不需要藉助閘道器交換訪問令牌。

授權碼

上圖為OAuth2.0規範標準流程圖，結合此場景對應OAuth2.0中的角色，使用者是資源所有者、瀏覽器為使用者代理、閘道器作為被授權的客戶端、IAM則為授權伺服器。

• (A) 閘道器通過引導瀏覽器開始流程授權流程，重定向到統一認證中心的登入頁面。

• (B)使用者輸入密碼登入，授權伺服器驗證使用者身份，並確認使用者是否授權閘道器的訪問請求。

• (C)使用者授權後，認證中心根據之前閘道器注冊時提供的回撥地址，引導瀏覽器重定向回到閘道器。重定向URI包含授權碼

• (D)閘道器通過包含上一步中收到的授權碼和閘道器自身憑證從授權伺服器IAM的請求訪問令牌。

• (E)授權伺服器IAM對閘道器進行身份驗證，驗證授權程式碼，並確保接收的重定向URI與閘道器注冊時的URI相匹配。匹配成功後，授權伺服器IAM響應返回訪問令牌與可選的重新整理令牌給閘道器。

其他說明：

1. 為了前端會話保持，訪問令牌由閘道器在響應時返回到前端，儲存到前端儲存空間，如Cookie、Local Storage、Session Storage等。

2. 訪問令牌失效後，閘道器根據自己的客戶端憑證+重新整理令牌一起傳送授權伺服器，獲取新的訪問令牌和重新整理令牌，並再返回響應中將訪問令牌寫入到使用者瀏覽器的儲存中。

3. 授權碼模式中，使用者的憑證(使用者名稱、密碼)是使用者通過瀏覽器與授權服務互動，並不經過閘道器， 安全性最好。

2.2.2 移動App

個人移動裝置上安裝的原生App本身具備實現授權碼流程的能力，不需要藉助閘道器實現授權碼流程。認證通過後閘道器僅負責校驗訪問令牌即可。

授權碼

移動App實現登入重定向通常可以採用如下方式：

• 模擬web端，使用移動端瀏覽器與WebView

• 使用URI scheme與Intent在應用間跳轉

移動端App的執行環境是不可信的，容易被惡意App入侵的風險，包含如下兩種情況：

1. 重定向過程中的回撥URL引數，容易被惡意App佔用URL Scheme或者監聽localhost埠擷取。

2. 執行環境不可靠，移動App不具備安全儲存客戶端祕鑰的能力，而使用授權碼獲取訪問令牌時需要校驗客戶端祕鑰。

基於上述風險和問題，移動App基於授權碼獲取訪問令牌的流程需要進行優化解決，rfc規範中建議的實現方案是移動App授權流程採用使用帶有PKCE支援的授權碼模式。PKCE, 全稱Proof Key for Code Exchange，即保護授權程式碼授權。這其實是通過一種密碼學手段確保惡意第三方即使截獲Authorization Code或者其他金鑰，也無法向認證伺服器交換Access Token。

經過PKCE改進的授權碼、訪問令牌交換過程示意圖如下：

PKCE

上圖為PKCE模式下授權碼申請和交換訪問令牌的過程，說明如下：

• (A) 移動App客戶端建立並儲存名為code_verifier的隨機祕鑰串，並將祕鑰字串加密轉換的結果t(code_verifier)稱為code_challenge，將轉換後的code_challenge以及轉換方法一併傳送到授權服務中。

• (B) 授權服務返回授權碼並記錄code_challenge和轉換方法t_m。

• (C) 移動App客戶端收到授權碼後，將授權碼和code_verifier祕鑰串傳送到授權伺服器，用以申請訪問令牌。

• (D) 授權伺服器根據轉換方法t_m 轉換code_verifier 並與步驟A中收到的code_challenge比較，如果一致則返回訪問令牌，否則拒絕非法請求。

第三方無法根據code_challenge推匯出code_verifier，因為code_challenge採用了不可逆加密方式。只有移動App客戶端自己才知道這兩個值。因此即使惡意App截獲了code_challenge和授權碼，也無法換取訪問令牌避免了安全問題。要實現這種移動App的PKCE授權碼模式，出移動App自身外，還需要IAM的授權伺服器基於標準的授權碼流程擴充套件配合實現。

關於移動App安全認證的詳細內容請參考官方規範：

• rfc8252 - OAuth 2.0 for Native Apps

  （https://tools.ietf.org/html/rfc825）

• rfc7636 - Proof Key for Code Exchange by OAuth Public Clients

  （https://tools.ietf.org/html/rfc7636）

2.3 高度信任的特權類客戶端，可以使用資源所有者密碼憑據許可

使用者密碼憑據

上圖為OAuth2.0規範標準流程圖，結合此場景中，對應OAuth2.0中的角色，使用者是資源擁有者、特權應用是客戶端、IAM提供授權伺服器

• (A)使用者提供給特權App使用者名稱和密碼。

• (B)特權App將使用者憑據提交給授權伺服器IAM，申請訪問令牌

• (C)授權伺服器IAM 驗證使用者的憑證，如果有效，頒發訪問令牌給特權App。特權App對授權伺服器頒發的訪問令牌、重新整理令牌進行儲存和更新。

其他說明：

• 雖然是特權App，但App中不要持久化儲存使用者密碼，僅登入時使用

• App負責儲存Access Token 、Refresh Token

3. 使用API 閘道器作業務系統訪問入口，負責驗證訪問令牌

訪問者能夠訪問的介面通常是兩類：身份認證API、應用功能類API。

• 身份認證類API：即登入認證相關的API。為了避免使用者、客戶端憑證洩漏第三方(除IAM、訪問者之外為第三方)，身份認證類API或UI建議由IAM系統直接開放給訪問者呼叫進行身份認證。

• 應用功能類API：功能實現來自服務提供者，通過閘道器開放給訪問者。閘道器是訪問應用API的入口。

使用者登入認證由IAM授權伺服器配合使用者資源服務負責。認證成功後，IAM訪問者頒發訪問令牌。後續對應用功能的訪問過程中，均須攜帶訪問令牌以表明訪問者的身份。

3.1 由閘道器負責客戶端身份驗證

閘道器作為業務系統的API入口，當面向外網的訪問者時閘道器還是內外網的分界， 訪問令牌驗證理應由閘道器負責，不應該將令牌驗證的事情交給服務提供者。閘道器負責驗證既能避免未經驗證的請求進入內網，又能夠簡化服務提供端的程式碼，服務提供端無需處理不同型別客戶端的驗證。實際上好處還不只這些，在閘道器可以統一做流控無需應用端重複建設類似功能；系統內部除錯、變更敏捷，減少了跨組織互動。

閘道器驗證訪問令牌有兩種方案：閘道器委託認證服務驗證、閘道器直接驗證，說明如下：

• 方案一：閘道器委託授權服務驗證，每次收到請求後，閘道器均將訪問令牌傳送到IAM認證服務進行認證，認證通過後才允許繼續訪問。

閘道器委託IAM校驗令牌

1. 客戶端成功認證後，使用UUID型別的訪問令牌呼叫閘道器上的服務

2. 由於UUID型別令牌不包含客戶端的資訊，閘道器需要委託IAM認證服務校驗令牌

3. 令牌檢查合法後，將請求路由到服務提供者

4. 應用中也無法解析令牌，需要根據UUID令牌到IAM中獲取使用者資訊

• 方案二(推薦)：閘道器直接驗證，要求閘道器能識別IAM頒發的令牌，這種模式推薦用 JWT令牌，閘道器需要具備解析校驗JWT加密的訪問令牌的能力。

閘道器直接校驗令牌

1. 客戶端成功認證後，使用JWT令牌呼叫閘道器上的服務

2. 閘道器自己直接解密JWT令牌進行校驗

3. 令牌檢查合法後，將請求路由到服務提供者

4. 應用受到請求後，如果需要更多許可權資訊，如果可以根據Token去許可權管理服務獲取許可權資訊(非必須步驟，需要時新增)。

上述兩方案中，方案一的令牌是無業務含義的身份標識字串，每次收到請求閘道器都去IAM認證，對IAM認證服務的效能壓力較大。方案二中IAM頒發的令牌中包含部分客戶端或使用者資訊，使用JWT加密，IAM將驗證方式或SDK提供給了負責認證的閘道器。對於IAM來說，減少了每次請求令牌認證帶來的通訊次數，減輕了IAM的壓力。

推薦採用方案二實現令牌檢查，需要注意的是方案二中的JWT令牌中僅包含必要的資訊即可，不要放太多的角色許可權資訊。後續功能中需要額外的資訊時，可以根據令牌再去IAM中獲取。如果令牌中存放了很多的許可權資料，一旦後臺的授權資料發生變化，令牌中的許可權資料與實際IAM的許可權會存在不一致的問題，只能強制使用者下線重新登入。

JWT令牌是防篡改的，但並不加密，如需要儲存到瀏覽器儲存中，建議採用JWT+JWE方式進行令牌加密。令牌中存放必要少量資料即可，避免濫用。多數伺服器通常會對Http header、cookie長度做限制。

3.2 系統內部應用是否通過閘道器？

我的答案是不需要，否則太麻煩了。通常閘道器是獨立團隊負責，API變更釋出、內部聯調驗證還得跨團隊協調實在不可行。 推薦系統內直通不走閘道器，系統之間訪問必須走閘道器。 要做到這一點，應用也需要實別請求來源進行客戶端認證，這種認證方案沒必要太複雜，應用只應該允許信任的閘道器和系統內部應用程式訪問其服務，不允許系統外部請求繞過閘道器直接呼叫，因此，需要在閘道器和系統內部應用之間這個小範圍內建立信任，常見方案有兩種：

• 方案一，內部令牌：系統內的應用在釋出介面到閘道器時，提供一個系統內部共享的令牌給閘道器和系統內所有應用，接收到請求時檢查請求頭中是否包含系統內信任的令牌， 如果包含可信任令牌，那麼就允許訪問，否則就拒絕

• 方案二，系統內保密令牌+閘道器證書單獨認證：系統內用保密令牌互動就是方案一，只是內部令牌不共享給閘道器，閘道器用公私鑰證書籤名方式與域內系統建立信任，由閘道器生成公私鑰證書，頒發公鑰給各個系統，閘道器呼叫服務提供者時，請求頭中帶上用私鑰簽名的令牌，應用收到請求以後用閘道器釋出的公鑰驗證其令牌。

方案一優點是實現簡單，缺點是安全級別略低，常見的企業架構中，閘道器和業務系統會是不同團隊甚至不同的廠商負責開發維護，內部令牌共享給了其他團隊負責的閘道器，存在一定的風險。方案二相比方案一略複雜一點，安全性更高，系統內互通用內部令牌，系統和閘道器認證使用了閘道器提供的安全令牌檢查方式。兩種方案可根據實際需求選擇。

2.訪問授權

通過認證的API客戶端能夠訪問閘道器開發的所有API嗎？通過認證的使用者能夠呼叫所有API嗎？通過認證的使用者允許呼叫修改訂單的介面，那麼他能修改所有人的訂單嗎？

很顯然絕大多數場景下上述三個問題答案都是"不能"。在絕大多數業務場景中除了對訪問者的身份認證之外，我們還需要再進一步控制許可權。

1. API客戶端訪問閘道器介面時，閘道器需進行API許可權控制

如果訪問者是API客戶端時，API呼叫的許可權需由閘道器進行控制。建議採用先訂閱再訪問的授權模式，閘道器應該僅允許API客戶端訪問其訂閱過的API 。具體實現方法就是絕大多數閘道器都會提供的基於API Key控制API訪問的方式。

需要注意的是，僅使用API key的訪問控制是不夠的。API Key是在閘道器訂閱API時生成的一串唯一編號，並不具備識別客戶端身份的能力。就好比以前買火車票是不實名的，誰拿到火車票，都可以乘坐對應車次。火車票實名制之後，首先需要核驗身份證，核驗通過後才能購票乘車。如果證票不符，則不允許乘車。

將客戶端認證和API Key配合進行訪問認證和許可權校驗才是個更安全的方案。

API許可權控制

上圖為訪問令牌結合API Key的認證鑑權示意圖，說明如下：

• 客戶端1獲取了API Key 但其沒有合法的訪問令牌，如果不允許匿名訪問，則閘道器會拒絕客戶端1訪問，返回錯誤碼401表示客戶端未通過認證；

• 客戶端2擁有了合法的訪問令牌，但其API Key不合法，閘道器在客戶端2認證檢查通過後，檢查API Key，發現其許可權不足，則返回錯誤碼403表示客戶端的許可權不足；

• 客戶端3擁有合法的客戶端訪問令牌和API Key訪問閘道器上的服務，閘道器認證、鑑權通過之後，將請求路由到實際的服務提供端，最終發回正常響應資料。

2. 使用者訪問應用功能時需要進行許可權控制

使用者訪問的功能許可權或資料許可權不要交給閘道器管控，原因是閘道器僅能支援API Path授權，而實際需要控制的使用者許可權有很多，如選單、API、資料等。如果由閘道器控制使用者許可權，管少了不滿足需求，管多了就要耦合太多應用資料。

因此推薦使用者許可權由業務系統自行管理維護和控制。每個業務系統內部如果需要控制使用者許可權，可以建設一個基礎許可權框架，負責管理許可權資料，並提供訪問請求攔截和許可權檢查的SDK給其他應用。

也有部分企業許可權管理要求較高，將系統內部的基礎許可權框架抽取為獨立的許可權管理服務，由獨立團隊維護該服務，採用分散式部署+許可權快取的方式保障效能。這樣做的好處是許可權模型統一、容易對許可權變更進行審批控制和審計。缺點是跨團隊互動，變更流程複雜。

關於許可權管理，是業務系統自治或是集中管控，根據企業自身的需求特點決定即可。

3.通訊安全

通訊安全的方案就是基於傳輸過程加密的方式，常見的選擇就是使用Https協議通訊。

微服務架構體系中，邏輯層面上外部請求接入都是通過閘道器作為入口，閘道器作為內外網的分界，實際部署上，閘道器本身也是多例項分散式的高可用部署形態，前面架設有一個負載均衡F5或nginx，用來對外提供Https協議接入和路由轉發，而閘道器內部就是企業內網，預設是可信任的，內網的系統之間的通訊會採用更輕量級的HTTP協議。 此方案中微服務換成SOA，把閘道器換成ESB，就是傳統的SOA架構中的安全通訊方案，本質上沒有區別。

示意圖如下：

內外網通訊協議

為什麼用了https就能保證通訊安全呢？https是http+ssl，採用密碼學手段對通訊報文做了加密，使得報文無法被篡改，做到了安全傳輸，從而保障了通訊安全。關於https原理和負載均衡器證書配置相關資料網路上有很多，請大家即用即查。

4.程式碼安全

敏感配置加密 ：上述各種服務安全場景和方案聊了那麼多，大家發現儲存好令牌、金鑰、密碼是一切安全的前提。這些東西千萬不能外洩。要保證密碼不洩露的辦法就是做好敏感資料保密，技術手段上則要求儲存密碼、憑證的地方(配置檔案和資料庫表)需要加密儲存。如：配置檔案中的資料庫口令、資料表中存放的密碼資料等

程式碼質量管理 ：建議在開發期對於編碼規範進行制定，還可以通過工具進行輔助檢查和控制，如開源的程式碼質量管理工具Sonar，可以支援多種程式語言，方便的與編譯構建工具整合如Maven，在程式碼進入正式提交對應分支前就將一些安全問題在前期預防，如SQL隱碼攻擊等。

執行時安全掃描 ：測試階段，可以通過安全掃描軟體，如AppScan 等工具對業務系統的前後端功能進行掃描，檢查系統漏洞並即時修復。儘量減小在上線執行後出現安全事故的風險。

5.管理審計

運維管理安全方面，根據安全需求，要有安全相關的管理規範和工具支撐，對系統管理、許可權分配和關鍵資料進行嚴格管控，並做好操作審計日誌記錄。

比如很多安全級別高的行業或企業中如軍工類，對於業務系統的修改、許可權管理審計做了嚴格的流程規範和功能支撐。如典型的三員管理，採用三權分立、互相制約的思路，包含系統管理員、安全管理員、安全審計員三個角色，互相能看到對方的資訊，將業務過程分成不同的段，每段由對應人員負責，不讓任何人掌控全域性。

審計工作是非常重要的一環，沒有任何系統和流程是絕對安全的。關鍵的操作、資料變化等審計日誌需要完整記錄。一旦發生問題，可以通過審計日誌排查分析追蹤。常見內容舉例如下：

• 對於敏感資料項(如：密碼)的訪問

• 客戶端註冊、使用者認證授權過程

• 許可權的授予和廢除

• 關鍵資料的變更、刪除

• 審計功能的啟動和關閉

• 其他關鍵API、命令的訪問

以上這些審計方面的工作中，如果是基於API相關的審計資訊記錄，如邊界互動報文資料，建議基於統一的技術框架進行記錄管理。一些內部實現方法，則可以採用介面、方法上加註解，AOP攔截後記錄的方案。其他情況可根據實際需求設計審計資料儲存的方案。

參考引用 

• rfc6749-The OAuth 2.0 Authorization Framework

  （https://tools.ietf.org/html/rfc6749）

• rfc8252-OAuth 2.0 for Native Apps

  （https://tools.ietf.org/html/rfc8252）

• rfc7636-Proof Key for Code Exchange by OAuth Public Clien

  （https://tools.ietf.org/html/rfc76）

• PKCE授權碼模式 

  （https://tonyxu.io/zh/posts/2018/oauth2-pkce-flow/）
  

• 如何在微服務架構中實現安全性 

  （https://mp.weixin.qq.com/s/zMJknIq2qVCkNMtyBiFtag）
  

• 如何在移動端開發中正確地使用OAuth協議

  （https://www.jianshu.com/p/ca3fc5890b05）

關於作者 ：炎峰，現任普元金融研究院架構師。主要負責普元流程產品的核心架構設計與產品版本發展規劃，先後參與了國家電網BPM、BAM平臺、浦發銀行新一代流程平臺等大型平臺專案建設與實施 。

轉載本文需註明出處：微信公眾號EAWorld，違者必究。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562043/viewspace-2654497/，如需轉載，請註明出處，否則將追究法律責任。