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