14個(gè)文本轉(zhuǎn)圖像AI API
為了有效解決 API 安全問題，需要通過多個(gè)組件的組合來提供保護(hù)：
第一步是部署 API。假設(shè)我們有一個(gè)開放的銀行 API，并將其暴露出來。此時(shí)，它是“裸露的”，完全暴露在外界。當(dāng)前的保護(hù)措施僅集成在應(yīng)用程序中，或者依賴底層框架（例如 Java Spring）。因此，API 面臨諸如 DoS 攻擊、有效負(fù)載中毒和其他內(nèi)容級攻擊等威脅。
接下來，我們來介紹一下 API 網(wǎng)關(guān)，例如 Broadcom Layer7 API Gateway。網(wǎng)關(guān)提供了一種可擴(kuò)展、高性能的方式，通過 API 將跨云、容器或本地環(huán)境的任意組合連接到最關(guān)鍵的數(shù)據(jù)和應(yīng)用程序。
不受保護(hù)的API：
在API前邊插入API網(wǎng)關(guān)
為了有效保護(hù) API，應(yīng)在 API 前面插入 API 網(wǎng)關(guān)。API 網(wǎng)關(guān)能解決 API 面臨的核心安全挑戰(zhàn)，并能夠處理基本的身份驗(yàn)證和某些級別的授權(quán)。隨著 IETF 在 OAuth 方面取得的進(jìn)展，以及一套成熟的 OAuth 工具（例如授權(quán)服務(wù)器），身份驗(yàn)證問題也能得到更加完善的解決方案。
在身份驗(yàn)證方面，有幾個(gè)標(biāo)準(zhǔn)可以提供幫助。其中，最流行和現(xiàn)代的標(biāo)準(zhǔn)是 OAuth 2.0 和基于身份驗(yàn)證的配置文件 OpenID Connect。OAuth 2.0 支持用戶身份驗(yàn)證、委派、模擬等多種用例。OAuth 提供了不同的身份驗(yàn)證流程，每個(gè)流程都針對特定的用例進(jìn)行定制：
在涉及 API 的情況下，API 客戶端（可能是應(yīng)用程序的后端）需要發(fā)送用戶的令牌（無論是透明的訪問令牌還是可能是 JWT 令牌）。該令牌來自授權(quán)服務(wù)器，是最終用戶完成身份驗(yàn)證過程后的結(jié)果（例如 OAuth 2.0 中的授權(quán)碼流）。身份驗(yàn)證的處理方式有多種。例如，使用的令牌可以是用戶的實(shí)際令牌（訪問令牌、JWT 令牌，甚至 ID 令牌），或者 API 調(diào)用可以使用系統(tǒng)到系統(tǒng)的令牌（例如客戶端憑證）。具體方式將取決于架構(gòu)團(tuán)隊(duì)的決策。
配置授權(quán)層時(shí)，確保了解如何訪問最終用戶的身份信息，以便授權(quán)層能夠利用這些信息進(jìn)行授權(quán)。
需要注意的是，身份驗(yàn)證流程在 OAuth 2.0 中有時(shí)被稱為 RS/AS 模式（資源服務(wù)器/授權(quán)服務(wù)器模式）。該模式允許通過使用范圍和聲明來進(jìn)行某種程度的粗粒度授權(quán)。IETF 內(nèi)部正在開展進(jìn)一步的工作，以推出一種名為交易令牌的新型令牌，這將有助于進(jìn)一步增強(qiáng)授權(quán)功能。
完成身份驗(yàn)證步驟后，我們就知道了正在進(jìn)行操作的主體——即最終用戶的身份。這個(gè)步驟的結(jié)果是，接下來至關(guān)重要的一步——授權(quán)。
現(xiàn)在我們已經(jīng)知道了用戶的身份，接下來需要確認(rèn)的是他們可以執(zhí)行哪些操作。這就是授權(quán)步驟的目標(biāo)。
幸運(yùn)的是，OASIS XACML 和 NIST 發(fā)布了一種架構(gòu)，現(xiàn)在已成為外部化和細(xì)粒度授權(quán)的標(biāo)準(zhǔn)模式。這個(gè)架構(gòu)的主要組成部分包括：
那么，回到本文的核心問題，如何修復(fù)與 OWASP API 威脅相關(guān)的訪問控制問題呢？我們可以通過以下步驟來緩解與訪問控制損壞相關(guān)的特定風(fēng)險(xiǎn)：
一旦您建立了 P*P 架構(gòu)并且了解了請求者的身份，修復(fù)就相對簡單了：編寫策略并將其部署到 PDP。編寫策略的語言有多種選擇，例如 OPA 的 Rego、Oso 或 ALFA。下面是使用 ALFA 編寫并部署到 PDP 的一個(gè)示例。
假設(shè)我們的 API 暴露了以下端點(diǎn)。請注意，這只是一個(gè)簡單的示例，實(shí)際情況中不要直接使用此設(shè)計(jì)：
/accountsGET /accounts：列出用戶的賬戶。GET /accounts/{accountId}：列出指定 accountId 的特定賬戶。POST /accounts：創(chuàng)建新賬戶。/accounts/{accountId}/transactionsGET /accounts/{accountId}/transactions：列出指定賬戶的最近交易。GET /accounts/{accountId}/transactions/{txId}：列出指定交易的詳細(xì)信息。POST /accounts/{accountId}/transactions/：創(chuàng)建從指定賬戶到目標(biāo)賬戶的轉(zhuǎn)賬。針對每個(gè)端點(diǎn)和方法，我們可以定義具體的授權(quán)策略。例如，以下是開放銀行用例中的 ALFA 策略代碼：
namespace openbanking{
policyset main{
apply firstApplicable
/**
* 控制對銀行賬戶的訪問
**/
policyset accounts{
target clause object=="account"
apply firstApplicable
/**
* 確定誰可以查看賬戶
**/
policy viewAccount{
target clause action=="view"
apply firstApplicable
/**
* 任何用戶都可以查看他們擁有的賬戶
*/
rule owner{
permit
condition account.owner == user.username
}
/**
* 分行職員可以查看同一分行客戶的賬戶
*/
rule branch{
target clause user.role == "teller"
permit
condition user.branch == account.branch
}
}
}
}
}一旦我們編寫了策略，就可以開始編寫示例授權(quán)請求。以下是 XACML/JSON 格式的授權(quán)請求示例：
{
"Request": {
"ReturnPolicyIdList": true,
"AccessSubject": {
"Attribute": [
{
"AttributeId": "openbanking.user.username",
"Value": "Alice"
}
]
},
"Resource": {
"Attribute": [
{
"AttributeId": "openbanking.object",
"Value": "account"
},
{
"AttributeId": "openbanking.account.accountId",
"Value": "AL47 2121 1009 0000 0002 3569 87411"
}
]
},
"Action": {
"Attribute": [
{
"AttributeId": "openbanking.action",
"Value": "view"
}
]
}
}
}請注意，此請求不包含元數(shù)據(jù)，例如賬戶所有權(quán)或分行信息。這些信息將通過 PIP 獲取并由 PDP 計(jì)算。
截至 2023 年 6 月，一些從業(yè)者和供應(yīng)商在 OpenID 基金會的領(lǐng)導(dǎo)下聚集，推動創(chuàng)建一種新的 PEP-PDP 標(biāo)準(zhǔn)，以提高不同框架之間的互操作性。這個(gè)新標(biāo)準(zhǔn)現(xiàn)被稱為 AuthZEN，并且在本文撰寫時(shí)，已經(jīng)處于實(shí)施者草案階段，已有 12 個(gè)實(shí)現(xiàn)符合該標(biāo)準(zhǔn)。具體示例可以參見此 Postman 集合。
在上面的示例中，我們檢查用戶是否可以查看整個(gè)銀行賬戶信息?？赡芪覀兿Ｍ跈?quán)用戶查看賬戶的部分內(nèi)容，例如賬戶 ID、余額或交易列表。為此，我們可以在內(nèi)部 API 向網(wǎng)關(guān)返回調(diào)用時(shí)，在出站通道上應(yīng)用授權(quán)檢查。網(wǎng)關(guān)可以攔截流量并觸發(fā)一系列新的授權(quán)檢查。這些檢查可以以批處理模式進(jìn)行。例如，可以提出這樣的查詢：“Alice 是否可以查看賬戶 #123 的 ID、余額和交易列表？”查詢返回的結(jié)果可能是“允許”、“拒絕”或“拒絕”等。
恭喜！外部化和基于策略的授權(quán)能夠有效解決 OWASP 前十名中的安全風(fēng)險(xiǎn)。例如，針對 API1:2023 – 對象級授權(quán)損壞（BOLA），上述 ALFA 策略能夠直接解決這一問題，因?yàn)樗谑谟柙L問權(quán)限之前會驗(yàn)證用戶是否為賬戶的所有者。隨著時(shí)間推移，策略可以不斷豐富和加強(qiáng)，而無需重新部署應(yīng)用程序或 API。
為了實(shí)現(xiàn)這一愿景，您可以將 Layer7 API 網(wǎng)關(guān)與 Axiomatics 的細(xì)粒度授權(quán)服務(wù)結(jié)合使用，身份驗(yàn)證部分則可以委托給 Curity 的 Identity Server。如果您想看到實(shí)際效果，我們非常樂意為您展示。
原文鏈接：A Guide to Fixing Broken Access Control in Your APIs
