建站
咨詢
售后
建站咨詢
新聞中心
近期在公司推廣實(shí)施安全開(kāi)發(fā)生命周期流程(SDL)，基于目前業(yè)務(wù)的發(fā)展，有很多以API形式提供的數(shù)據(jù)訪問(wèn)接口，為此專門(mén)對(duì)所有系統(tǒng)的API接口進(jìn)行了一次梳理，在梳理過(guò)程中發(fā)現(xiàn)了部分接口存在的安全隱患，包括未授權(quán)訪問(wèn)、數(shù)據(jù)校驗(yàn)不完整、訪問(wèn)敏感數(shù)據(jù)等問(wèn)題。因此在這里針對(duì)API可能帶來(lái)的安全問(wèn)題聽(tīng)過(guò)一些安全解決措施，大家一起交流學(xué)習(xí)。
成都創(chuàng)新互聯(lián)主要從事成都網(wǎng)站制作、網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)洛川,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):13518219792
隨著業(yè)務(wù)開(kāi)放性的發(fā)展趨勢(shì)，為了應(yīng)對(duì)快速發(fā)展的業(yè)務(wù)及靈活多變的程序需求，API(Application Programming Interface)在程序中的應(yīng)用顯得愈發(fā)重要，API為外部業(yè)務(wù)對(duì)接、系統(tǒng)間的調(diào)用提供了靈活性和創(chuàng)新性。然而與此同時(shí)，隨之而來(lái)的則是API應(yīng)用帶來(lái)的一系列安全問(wèn)題，任意訪問(wèn)、數(shù)據(jù)泄露、竊取用戶信息等，API的使用不當(dāng)都可能破壞數(shù)據(jù)的保密性、完整性和可用性。
一個(gè)安全的API僅可對(duì)其用戶、應(yīng)用程序、以及消費(fèi)它的服務(wù)可見(jiàn)，以此確保信息的保密性;除此之外，同時(shí)要保證客戶端和服務(wù)端間交互的信息沒(méi)有被第三方篡改，以此保證信息的完整性。要滿足信息的保密性和完整性，對(duì)調(diào)用方和終端用戶進(jìn)行身份認(rèn)證是前提條件。
身份驗(yàn)證可以說(shuō)是安全界的核心。API創(chuàng)建者需要有能力識(shí)別消費(fèi)API的用戶、應(yīng)用以及調(diào)用API的服務(wù)，那么就需要有一個(gè)身份存儲(chǔ)庫(kù)來(lái)識(shí)別并確認(rèn)用戶和應(yīng)用的身份有效性。身份存儲(chǔ)庫(kù)目前最常用的解決方案就是LDAP 服務(wù)，而活動(dòng)目錄(AD)是目前對(duì)LDAP***的一種實(shí)現(xiàn)。LDAP服務(wù)主要存儲(chǔ)用戶名、密碼、數(shù)字證書(shū)以及其他用戶相關(guān)的身份信息和用戶所屬機(jī)構(gòu)組織信息，應(yīng)用的身份信息同樣可以存儲(chǔ)在這里。身份提供者(IP)是專用于管理與身份存儲(chǔ)庫(kù)的交互以用于身份驗(yàn)證和授權(quán)的軟件，APP可以將身份驗(yàn)證及授權(quán)的工作交由身份提供者處理，這是一種更加安全和可取的方法。
當(dāng)調(diào)用者使用應(yīng)用ID和用戶名調(diào)用你的API時(shí)，API需要有能力識(shí)別調(diào)用者提供的信息的有效性，這種有效性驗(yàn)證主要是通過(guò)驗(yàn)證共享的秘密信息來(lái)完成的。當(dāng)你的API作為身份提供者時(shí)，通常會(huì)傳遞同樣的身份認(rèn)證信息到LDAP服務(wù)進(jìn)行驗(yàn)證。下面介紹幾種常用的API身份驗(yàn)證的方法。
***種就是用戶名密碼方式，這也是最簡(jiǎn)單的一種認(rèn)證方式。系統(tǒng)間身份認(rèn)證使用這種方式實(shí)現(xiàn)時(shí)，身份認(rèn)證使用的密碼可能會(huì)在多個(gè)API間進(jìn)行共享。用戶名密碼身份認(rèn)證方式并不推薦使用，主要是基于兩方面的考慮：首先是由于密碼的可猜測(cè)性，密碼是人為生成，安全性較低;其次是密碼的維護(hù)工作也存在困難，例如修改某個(gè)API進(jìn)行身份認(rèn)證的密碼，那么所有相關(guān)聯(lián)的應(yīng)用都會(huì)受到影響。
第二種是多因素認(rèn)證方式(MFA)，即在用戶知道什么的前提下，進(jìn)一步通過(guò)用戶有什么進(jìn)行身份驗(yàn)證，通過(guò)用戶獲取到的一次性token來(lái)進(jìn)一步驗(yàn)證用戶身份憑證。這個(gè)token可以是MFA服務(wù)提供者發(fā)送的短信，也可以是數(shù)字key，目前已經(jīng)有成熟的第三方數(shù)字key服務(wù)提供商，開(kāi)源的有Google Authenticator、FreeOTP，商用的則有RSASecurID。
第三種方式是基于Token的身份認(rèn)證憑證，是對(duì)用戶名密碼安全性的補(bǔ)充，為用戶名密碼的認(rèn)證和授權(quán)提供了一種更加安全的方式。身份提供者基于用戶名密碼的身份憑證生成一個(gè)獨(dú)立的token，后續(xù)與應(yīng)用的交互，只需要將該token傳遞給應(yīng)用，因此通過(guò)網(wǎng)絡(luò)來(lái)回切換的用戶名/密碼憑證大幅減少。同時(shí)，token被設(shè)置了過(guò)期時(shí)間并且可以被撤銷，從而保證了token使用上的安全性。更重要的是，針對(duì)每個(gè)應(yīng)用都生成對(duì)應(yīng)的獨(dú)立token，當(dāng)撤銷或者失效某一個(gè)token時(shí)，其他應(yīng)用仍可以正常使用自己的token，無(wú)需再次進(jìn)行用戶名密碼認(rèn)證。
如下圖所示，用戶Gary登錄應(yīng)用，應(yīng)用驗(yàn)證其用戶名密碼身份信息，并向身份提供者申請(qǐng)token，身份提供者在身份存儲(chǔ)庫(kù)中驗(yàn)證Gary的身份有效性，驗(yàn)證通過(guò)后，身份提供者向應(yīng)用返回token，接下來(lái)應(yīng)用就可以使用這個(gè)token作為調(diào)用API的身份憑證。這也是目前網(wǎng)絡(luò)認(rèn)證協(xié)議Kerberos的實(shí)現(xiàn)基本原理。
接下來(lái)要介紹的是聯(lián)合身份認(rèn)證機(jī)制?；诹钆频纳矸菡J(rèn)證方式允許將令牌的發(fā)布與其驗(yàn)證分開(kāi)，從而促進(jìn)身份管理的集中化。API的開(kāi)發(fā)者只需要關(guān)心用戶在調(diào)用API時(shí)的驗(yàn)證邏輯，不需要關(guān)心具體的身份認(rèn)證邏輯，這部分是由集中式身份提供者完成的，API只需要在請(qǐng)求中帶上token，然后由集中式身份提供者完成對(duì)token有效性的驗(yàn)證，如果生成的token有權(quán)限發(fā)起這次請(qǐng)求，則API將被允許調(diào)用。身份提供者能夠?qū)τ脩?、?yīng)用及APP的身份進(jìn)行識(shí)別和認(rèn)證，是基于它們的身份信息和共享密碼都存儲(chǔ)在身份存儲(chǔ)庫(kù)中。但是，你的API不會(huì)始終暴露給身份提供者能識(shí)別的應(yīng)用和用戶，如果你希望將你的API暴露給外部用戶控制的應(yīng)用，外部用戶可能來(lái)自于其他公司或者公司內(nèi)部的其他業(yè)務(wù)部門(mén)，這時(shí)候該如何控制API的安全性呢?尤其是對(duì)于大公司而言，他們有很多的安全上下文，每個(gè)安全上下文都包含有獨(dú)立的身份存儲(chǔ)庫(kù)和身份提供者，此時(shí)，聯(lián)合身份機(jī)制應(yīng)運(yùn)而生，聯(lián)合身份提供者能夠?qū)?lái)自不同安全上下文的用戶進(jìn)行認(rèn)證和授權(quán)。
聯(lián)合身份認(rèn)證機(jī)制的流程如下圖所示，與普通的基于token的身份認(rèn)證流程類似，但流程中增加了物流API和物流系統(tǒng)身份提供者兩個(gè)角色，應(yīng)用利用訂單系統(tǒng)身份提供者返回的有效token申請(qǐng)?jiān)L問(wèn)物流API，物流API向物流系統(tǒng)身份提供者申請(qǐng)驗(yàn)證token有效性，但它并不知道此token是否有效，必須向訂單系統(tǒng)身份提供者申請(qǐng)驗(yàn)證此token，而不是在物流身份存儲(chǔ)庫(kù)中檢索此token的信息，這里的訂單系統(tǒng)身份提供者和物流系統(tǒng)身份提供者就是聯(lián)合身份提供者。
身份認(rèn)證完成之后，就需要根據(jù)用戶的身份對(duì)其進(jìn)行授權(quán)，其權(quán)限的大小由其身份決定。下面就介紹幾種在API安全中使用的授權(quán)模式。
***種是最常用的基于角色的訪問(wèn)控制模型。每個(gè)企業(yè)或組織的員工都會(huì)根據(jù)其業(yè)務(wù)職責(zé)劃分成不同的部門(mén)或組。那么這些組織內(nèi)的員工就根據(jù)其分組界定其權(quán)限。分組信息就可以應(yīng)用在于應(yīng)用交互中，根據(jù)應(yīng)用的授權(quán)及在應(yīng)用中設(shè)置不同分組的訪問(wèn)規(guī)則來(lái)限制用戶的訪問(wèn)，用戶所在分組決定其在應(yīng)用中的角色權(quán)限。輕量級(jí)目錄訪問(wèn)協(xié)議(LDAP)服務(wù)正是利用了分組的概念。身份提供者負(fù)責(zé)從身份存儲(chǔ)庫(kù)中檢索分組信息，角色則是應(yīng)用對(duì)訪問(wèn)控制權(quán)限的具體定義，用戶則可以采用應(yīng)用定義的多個(gè)角色。
基于角色的訪問(wèn)控制是一種非常簡(jiǎn)單的訪問(wèn)控制機(jī)制。應(yīng)用不需要維護(hù)每個(gè)用戶能訪問(wèn)的數(shù)據(jù)和功能，只需要通過(guò)角色將數(shù)據(jù)和功能訪問(wèn)權(quán)限抽象化，而只需要根據(jù)用戶的角色分配不同的訪問(wèn)權(quán)限。
第二種授權(quán)方式是基于屬性的訪問(wèn)控制模型(ABAC)。不同于基于靜態(tài)角色訪問(wèn)控制方式，基于屬性的訪問(wèn)控制旨在調(diào)用API時(shí)根據(jù)用戶的環(huán)境信息動(dòng)態(tài)分配其訪問(wèn)控制權(quán)限，環(huán)境信息包括如訪問(wèn)時(shí)間、角色、API的地理位置、應(yīng)用的地理位置以及其他決定訪問(wèn)程度的條件的組合信息?？蓴U(kuò)展的訪問(wèn)控制標(biāo)識(shí)語(yǔ)言(XACML)是一種基于XML的開(kāi)放標(biāo)準(zhǔn)語(yǔ)言，是一種用于決定請(qǐng)求/響應(yīng)的通用訪問(wèn)控制策略語(yǔ)言和執(zhí)行授權(quán)策略的框架，可定義API調(diào)用時(shí)訪問(wèn)控制規(guī)則，這種規(guī)則可以在不同API調(diào)用時(shí)進(jìn)行動(dòng)態(tài)變換，是一種典型的ABAC環(huán)境下的策略描述語(yǔ)言。
第三種是基于Oauth 2.0的代理訪問(wèn)控制方式。基于HTTP的OAuth 2.0框架允許應(yīng)用程序代表自己或代表用戶獲取對(duì)API資源的訪問(wèn)權(quán)限。 因此，它允許用戶將訪問(wèn)控制委派給第三方應(yīng)用程序。 為此，你的API接口必須與OAuth 2.0授權(quán)服務(wù)器協(xié)作，檢查每次請(qǐng)求訪問(wèn)token時(shí)，都經(jīng)過(guò)授權(quán)服務(wù)器的校驗(yàn)。授權(quán)服務(wù)器則向請(qǐng)求方返回響應(yīng)，指明訪問(wèn)token是否有效，是否是由OAuth提供者生成并且未過(guò)期的，同時(shí)校驗(yàn)該token能訪問(wèn)的范圍。
提到聯(lián)合身份認(rèn)證機(jī)制，就不得不提到安全斷言標(biāo)記語(yǔ)言(SAML)。安全斷言標(biāo)記語(yǔ)言(SAML)是一種行業(yè)標(biāo)準(zhǔn)，已成為企業(yè)級(jí)身份聯(lián)合的事實(shí)標(biāo)準(zhǔn)。它允許身份提供者以標(biāo)準(zhǔn)方式將有關(guān)用戶的身份驗(yàn)證和授權(quán)信息傳遞給服務(wù)提供者。SAML斷言可以由一個(gè)安全上下文中的身份提供者發(fā)布，并被另一個(gè)安全上下文中的身份提供者所理解。SAML斷言通常傳達(dá)有關(guān)用戶的信息給另一個(gè)身份提供者，包括用戶所屬組織，以及斷言的到期時(shí)間，無(wú)需提供密碼信息，驗(yàn)證斷言有效性的身份提供者必須與發(fā)布斷言的身份提供者建立信任關(guān)系。在企業(yè)內(nèi)使用SAML的主要場(chǎng)景就是單點(diǎn)登錄(SSO)，用戶無(wú)需為每個(gè)需要登陸的應(yīng)用單獨(dú)維護(hù)一套身份信息，僅僅需要在服務(wù)提供者處注冊(cè)登陸一次即可暢通無(wú)阻的訪問(wèn)其他應(yīng)用。
這里介紹一種實(shí)現(xiàn)SSO身份認(rèn)證常用的協(xié)議—OpenID Connect。OpenID Connect構(gòu)建于OAuth 2.0之上，提供聯(lián)合身份機(jī)制來(lái)保護(hù)你的API。它不但能支持原生和移動(dòng)應(yīng)用程序，同樣適用于企業(yè)級(jí)應(yīng)用，它基于JSON/REST的協(xié)議使其應(yīng)用更加簡(jiǎn)便快捷，是一種在企業(yè)內(nèi)部實(shí)現(xiàn)單點(diǎn)登錄更加輕量級(jí)的解決方案。不同于Oauth 2.0的訪問(wèn)token，OpenIDConnect使用JWT ID token，token中包含已經(jīng)身份驗(yàn)證通過(guò)的用戶的標(biāo)準(zhǔn)格式信息。API可以通過(guò)調(diào)用身份提供者上的用戶信息端點(diǎn)來(lái)確定訪問(wèn)控制策略，以驗(yàn)證用戶是否屬于某個(gè)角色。 與SAML斷言一樣，JWT ID令牌經(jīng)過(guò)數(shù)字簽名，因此聯(lián)合身份提供者可以根據(jù)與發(fā)布它們的身份提供者的信任關(guān)系來(lái)決定是否接受此token。
認(rèn)證和授權(quán)是API安全的前提，一個(gè)安全的API應(yīng)該有能力識(shí)別調(diào)用它的系統(tǒng)和終端用戶的身份，本文介紹了幾種認(rèn)證和授權(quán)機(jī)制，來(lái)加強(qiáng)API的安全性，在實(shí)際應(yīng)用場(chǎng)景中，可以根據(jù)具體情況采用不同的實(shí)現(xiàn)方式，也希望大家能夠更多交流API安全這方面的經(jīng)驗(yàn)和問(wèn)題。
當(dāng)前標(biāo)題：簡(jiǎn)析認(rèn)證加授權(quán)如何使API更安全
瀏覽路徑：http://www.dlmjj.cn/article/djeddps.html
