近期在公司推廣實施安全開發(fā)生命周期流程(SDL)，基于目前業(yè)務(wù)的發(fā)展，有很多以API形式提供的數(shù)據(jù)訪問接口，為此專門對所有系統(tǒng)的API接口進(jìn)行了一次梳理，在梳理過程中發(fā)現(xiàn)了部分接口存在的安全隱患，包括未授權(quán)訪問、數(shù)據(jù)校驗不完整、訪問敏感數(shù)據(jù)等問題。因此在這里針對API可能帶來的安全問題聽過一些安全解決措施，大家一起交流學(xué)習(xí)。

隨著業(yè)務(wù)開放性的發(fā)展趨勢，為了應(yīng)對快速發(fā)展的業(yè)務(wù)及靈活多變的程序需求，API(Application Programming Interface)在程序中的應(yīng)用顯得愈發(fā)重要，API為外部業(yè)務(wù)對接、系統(tǒng)間的調(diào)用提供了靈活性和創(chuàng)新性。然而與此同時，隨之而來的則是API應(yīng)用帶來的一系列安全問題，任意訪問、數(shù)據(jù)泄露、竊取用戶信息等，API的使用不當(dāng)都可能破壞數(shù)據(jù)的保密性、完整性和可用性。

一個安全的API僅可對其用戶、應(yīng)用程序、以及消費它的服務(wù)可見，以此確保信息的保密性;除此之外，同時要保證客戶端和服務(wù)端間交互的信息沒有被第三方篡改，以此保證信息的完整性。要滿足信息的保密性和完整性，對調(diào)用方和終端用戶進(jìn)行身份認(rèn)證是前提條件。

身份驗證可以說是安全界的核心。API創(chuàng)建者需要有能力識別消費API的用戶、應(yīng)用以及調(diào)用API的服務(wù)，那么就需要有一個身份存儲庫來識別并確認(rèn)用戶和應(yīng)用的身份有效性。身份存儲庫目前最常用的解決方案就是LDAP 服務(wù)，而活動目錄(AD)是目前對LDAP***的一種實現(xiàn)。LDAP服務(wù)主要存儲用戶名、密碼、數(shù)字證書以及其他用戶相關(guān)的身份信息和用戶所屬機(jī)構(gòu)組織信息，應(yīng)用的身份信息同樣可以存儲在這里。身份提供者(IP)是專用于管理與身份存儲庫的交互以用于身份驗證和授權(quán)的軟件，APP可以將身份驗證及授權(quán)的工作交由身份提供者處理，這是一種更加安全和可取的方法。

當(dāng)調(diào)用者使用應(yīng)用ID和用戶名調(diào)用你的API時，API需要有能力識別調(diào)用者提供的信息的有效性，這種有效性驗證主要是通過驗證共享的秘密信息來完成的。當(dāng)你的API作為身份提供者時，通常會傳遞同樣的身份認(rèn)證信息到LDAP服務(wù)進(jìn)行驗證。下面介紹幾種常用的API身份驗證的方法。

***種就是用戶名密碼方式，這也是最簡單的一種認(rèn)證方式。系統(tǒng)間身份認(rèn)證使用這種方式實現(xiàn)時，身份認(rèn)證使用的密碼可能會在多個API間進(jìn)行共享。用戶名密碼身份認(rèn)證方式并不推薦使用，主要是基于兩方面的考慮：首先是由于密碼的可猜測性，密碼是人為生成，安全性較低;其次是密碼的維護(hù)工作也存在困難，例如修改某個API進(jìn)行身份認(rèn)證的密碼，那么所有相關(guān)聯(lián)的應(yīng)用都會受到影響。

第二種是多因素認(rèn)證方式(MFA)，即在用戶知道什么的前提下，進(jìn)一步通過用戶有什么進(jìn)行身份驗證，通過用戶獲取到的一次性token來進(jìn)一步驗證用戶身份憑證。這個token可以是MFA服務(wù)提供者發(fā)送的短信，也可以是數(shù)字key，目前已經(jīng)有成熟的第三方數(shù)字key服務(wù)提供商，開源的有Google Authenticator、FreeOTP，商用的則有RSASecurID。

第三種方式是基于Token的身份認(rèn)證憑證，是對用戶名密碼安全性的補(bǔ)充，為用戶名密碼的認(rèn)證和授權(quán)提供了一種更加安全的方式。身份提供者基于用戶名密碼的身份憑證生成一個獨立的token，后續(xù)與應(yīng)用的交互，只需要將該token傳遞給應(yīng)用，因此通過網(wǎng)絡(luò)來回切換的用戶名/密碼憑證大幅減少。同時，token被設(shè)置了過期時間并且可以被撤銷，從而保證了token使用上的安全性。更重要的是，針對每個應(yīng)用都生成對應(yīng)的獨立token，當(dāng)撤銷或者失效某一個token時，其他應(yīng)用仍可以正常使用自己的token，無需再次進(jìn)行用戶名密碼認(rèn)證。

如下圖所示，用戶Gary登錄應(yīng)用，應(yīng)用驗證其用戶名密碼身份信息，并向身份提供者申請token，身份提供者在身份存儲庫中驗證Gary的身份有效性，驗證通過后，身份提供者向應(yīng)用返回token，接下來應(yīng)用就可以使用這個token作為調(diào)用API的身份憑證。這也是目前網(wǎng)絡(luò)認(rèn)證協(xié)議Kerberos的實現(xiàn)基本原理。

接下來要介紹的是聯(lián)合身份認(rèn)證機(jī)制?；诹钆频纳矸菡J(rèn)證方式允許將令牌的發(fā)布與其驗證分開，從而促進(jìn)身份管理的集中化。API的開發(fā)者只需要關(guān)心用戶在調(diào)用API時的驗證邏輯，不需要關(guān)心具體的身份認(rèn)證邏輯，這部分是由集中式身份提供者完成的，API只需要在請求中帶上token，然后由集中式身份提供者完成對token有效性的驗證，如果生成的token有權(quán)限發(fā)起這次請求，則API將被允許調(diào)用。身份提供者能夠?qū)τ脩?、?yīng)用及APP的身份進(jìn)行識別和認(rèn)證，是基于它們的身份信息和共享密碼都存儲在身份存儲庫中。但是，你的API不會始終暴露給身份提供者能識別的應(yīng)用和用戶，如果你希望將你的API暴露給外部用戶控制的應(yīng)用，外部用戶可能來自于其他公司或者公司內(nèi)部的其他業(yè)務(wù)部門，這時候該如何控制API的安全性呢?尤其是對于大公司而言，他們有很多的安全上下文，每個安全上下文都包含有獨立的身份存儲庫和身份提供者，此時，聯(lián)合身份機(jī)制應(yīng)運而生，聯(lián)合身份提供者能夠?qū)碜圆煌踩舷挛牡挠脩暨M(jìn)行認(rèn)證和授權(quán)。

聯(lián)合身份認(rèn)證機(jī)制的流程如下圖所示，與普通的基于token的身份認(rèn)證流程類似，但流程中增加了物流API和物流系統(tǒng)身份提供者兩個角色，應(yīng)用利用訂單系統(tǒng)身份提供者返回的有效token申請訪問物流API，物流API向物流系統(tǒng)身份提供者申請驗證token有效性，但它并不知道此token是否有效，必須向訂單系統(tǒng)身份提供者申請驗證此token，而不是在物流身份存儲庫中檢索此token的信息，這里的訂單系統(tǒng)身份提供者和物流系統(tǒng)身份提供者就是聯(lián)合身份提供者。

身份認(rèn)證完成之后，就需要根據(jù)用戶的身份對其進(jìn)行授權(quán)，其權(quán)限的大小由其身份決定。下面就介紹幾種在API安全中使用的授權(quán)模式。

***種是最常用的基于角色的訪問控制模型。每個企業(yè)或組織的員工都會根據(jù)其業(yè)務(wù)職責(zé)劃分成不同的部門或組。那么這些組織內(nèi)的員工就根據(jù)其分組界定其權(quán)限。分組信息就可以應(yīng)用在于應(yīng)用交互中，根據(jù)應(yīng)用的授權(quán)及在應(yīng)用中設(shè)置不同分組的訪問規(guī)則來限制用戶的訪問，用戶所在分組決定其在應(yīng)用中的角色權(quán)限。輕量級目錄訪問協(xié)議(LDAP)服務(wù)正是利用了分組的概念。身份提供者負(fù)責(zé)從身份存儲庫中檢索分組信息，角色則是應(yīng)用對訪問控制權(quán)限的具體定義，用戶則可以采用應(yīng)用定義的多個角色。

基于角色的訪問控制是一種非常簡單的訪問控制機(jī)制。應(yīng)用不需要維護(hù)每個用戶能訪問的數(shù)據(jù)和功能，只需要通過角色將數(shù)據(jù)和功能訪問權(quán)限抽象化，而只需要根據(jù)用戶的角色分配不同的訪問權(quán)限。

第二種授權(quán)方式是基于屬性的訪問控制模型(ABAC)。不同于基于靜態(tài)角色訪問控制方式，基于屬性的訪問控制旨在調(diào)用API時根據(jù)用戶的環(huán)境信息動態(tài)分配其訪問控制權(quán)限，環(huán)境信息包括如訪問時間、角色、API的地理位置、應(yīng)用的地理位置以及其他決定訪問程度的條件的組合信息。可擴(kuò)展的訪問控制標(biāo)識語言(XACML)是一種基于XML的開放標(biāo)準(zhǔn)語言，是一種用于決定請求/響應(yīng)的通用訪問控制策略語言和執(zhí)行授權(quán)策略的框架，可定義API調(diào)用時訪問控制規(guī)則，這種規(guī)則可以在不同API調(diào)用時進(jìn)行動態(tài)變換，是一種典型的ABAC環(huán)境下的策略描述語言。

第三種是基于Oauth 2.0的代理訪問控制方式。基于HTTP的OAuth 2.0框架允許應(yīng)用程序代表自己或代表用戶獲取對API資源的訪問權(quán)限。 因此，它允許用戶將訪問控制委派給第三方應(yīng)用程序。 為此，你的API接口必須與OAuth 2.0授權(quán)服務(wù)器協(xié)作，檢查每次請求訪問token時，都經(jīng)過授權(quán)服務(wù)器的校驗。授權(quán)服務(wù)器則向請求方返回響應(yīng)，指明訪問token是否有效，是否是由OAuth提供者生成并且未過期的，同時校驗該token能訪問的范圍。

提到聯(lián)合身份認(rèn)證機(jī)制，就不得不提到安全斷言標(biāo)記語言(SAML)。安全斷言標(biāo)記語言(SAML)是一種行業(yè)標(biāo)準(zhǔn)，已成為企業(yè)級身份聯(lián)合的事實標(biāo)準(zhǔn)。它允許身份提供者以標(biāo)準(zhǔn)方式將有關(guān)用戶的身份驗證和授權(quán)信息傳遞給服務(wù)提供者。SAML斷言可以由一個安全上下文中的身份提供者發(fā)布，并被另一個安全上下文中的身份提供者所理解。SAML斷言通常傳達(dá)有關(guān)用戶的信息給另一個身份提供者，包括用戶所屬組織，以及斷言的到期時間，無需提供密碼信息，驗證斷言有效性的身份提供者必須與發(fā)布斷言的身份提供者建立信任關(guān)系。在企業(yè)內(nèi)使用SAML的主要場景就是單點登錄(SSO)，用戶無需為每個需要登陸的應(yīng)用單獨維護(hù)一套身份信息，僅僅需要在服務(wù)提供者處注冊登陸一次即可暢通無阻的訪問其他應(yīng)用。

這里介紹一種實現(xiàn)SSO身份認(rèn)證常用的協(xié)議—OpenID Connect。OpenID Connect構(gòu)建于OAuth 2.0之上，提供聯(lián)合身份機(jī)制來保護(hù)你的API。它不但能支持原生和移動應(yīng)用程序，同樣適用于企業(yè)級應(yīng)用，它基于JSON/REST的協(xié)議使其應(yīng)用更加簡便快捷，是一種在企業(yè)內(nèi)部實現(xiàn)單點登錄更加輕量級的解決方案。不同于Oauth 2.0的訪問token，OpenIDConnect使用JWT ID token，token中包含已經(jīng)身份驗證通過的用戶的標(biāo)準(zhǔn)格式信息。API可以通過調(diào)用身份提供者上的用戶信息端點來確定訪問控制策略，以驗證用戶是否屬于某個角色。 與SAML斷言一樣，JWT ID令牌經(jīng)過數(shù)字簽名，因此聯(lián)合身份提供者可以根據(jù)與發(fā)布它們的身份提供者的信任關(guān)系來決定是否接受此token。

認(rèn)證和授權(quán)是API安全的前提，一個安全的API應(yīng)該有能力識別調(diào)用它的系統(tǒng)和終端用戶的身份，本文介紹了幾種認(rèn)證和授權(quán)機(jī)制，來加強(qiáng)API的安全性，在實際應(yīng)用場景中，可以根據(jù)具體情況采用不同的實現(xiàn)方式，也希望大家能夠更多交流API安全這方面的經(jīng)驗和問題。