Web應(yīng)用程序和API安全的新規(guī)則
實現(xiàn)訪問控制的常用方法是基于范圍。任意數(shù)量的范圍都可以與 OAuth 令牌相關(guān)聯(lián)。例如，如果我們考慮一個倉庫管理系統(tǒng)，相關(guān)范圍可能是list_items和order_item。然后我們可以擁有一個具有以下兩種方法的倉庫 API：
現(xiàn)在，token_1只能具有list_items作用域，token_2則同時具有list_items和order_item作用域。因此，應(yīng)用程序只能使用token_1調(diào)用 hmart.com/warehouse/items 方法。但是，使用token_2的應(yīng)用程序可以調(diào)用這兩個 API 方法。
現(xiàn)在我們可以關(guān)注應(yīng)用程序如何獲取令牌。此過程在 OAuth 2.0 規(guī)范的授權(quán)類型下提到。兩種有用的授權(quán)類型是授權(quán)碼授權(quán)類型和客戶端憑據(jù)授權(quán)類型。當(dāng)使用授權(quán)碼授權(quán)時，應(yīng)用程序必須提供應(yīng)用程序憑據(jù)以及用戶憑據(jù)才能獲取令牌。當(dāng)使用客戶端憑據(jù)授權(quán)時，僅提供應(yīng)用程序憑據(jù)即可獲取令牌。在這兩種情況下，都可以使用請求指定所需的范圍。
了解了令牌、范圍和授權(quán)類型后，我們現(xiàn)在可以考慮如何使用令牌進(jìn)行 API 訪問控制。基于令牌的訪問控制可以在以下兩個階段實施：(1) 令牌頒發(fā)和 (2) API 調(diào)用。
在基本情況下，我們可以通過僅限制某些角色的范圍來實現(xiàn)基于角色的訪問控制。例如，我們可以制定一個訪問控制策略，規(guī)定對于warehouse_admin角色， list_items和order_item范圍都是允許的。但是，對于warehouse_staff角色，只允許list_items范圍。我們還可以制定更高級的訪問控制策略。例如，我們可以強(qiáng)制執(zhí)行以下三個條件來頒發(fā)具有order_item范圍的令牌：(1) 具有 warehouse_admin 角色的用戶，(2) 用戶在 HMart 總部工作，(3) 源 IP 地址屬于澳大利亞。XACML 可用于實施此類高級授權(quán)策略。
由于可以擴(kuò)展標(biāo)準(zhǔn)授權(quán)或引入新授權(quán)，因此在獲取令牌的步驟中可以支持許多訪問控制方案。例如，我們可以引入用于頒發(fā)令牌的批準(zhǔn)工作流，以便在 IDP 將令牌發(fā)送到應(yīng)用程序之前，令牌請求必須得到某些用戶的批準(zhǔn)。在這種情況下，由于工作流的長期運行特性，通常必須通過單獨的通道將令牌發(fā)送到應(yīng)用程序。圖 2 顯示了使用訪問控制策略和批準(zhǔn)工作流來頒發(fā)令牌。
另一種可能性是，API 使用者可以在發(fā)送實際令牌請求之前提前請求范圍。在這種情況下，范圍請求可以由 IDP 根據(jù)某些授權(quán)策略或批準(zhǔn)工作流程進(jìn)行處理。無論哪種情況，如果范圍請求被批準(zhǔn)，IDP 都可以維護(hù)一個映射，表明給定的范圍是允許相應(yīng)用戶的。然后，當(dāng)應(yīng)用程序代表用戶請求具有該范圍的令牌時，IDP 可以查找映射并決定是否發(fā)出具有請求范圍的令牌。
如前所述，通常必須提供應(yīng)用程序憑據(jù)和用戶憑據(jù)（如適用）才能獲取令牌。因此，每個令牌可以與一個應(yīng)用程序和一個用戶帳戶相關(guān)聯(lián)。當(dāng)在 API 調(diào)用期間將令牌發(fā)送到 API 網(wǎng)關(guān)時，API 網(wǎng)關(guān)可以在 IDP 和其他相關(guān)組件的幫助下授權(quán)請求。此授權(quán)步驟可以強(qiáng)制執(zhí)行許多在令牌頒發(fā)階段無法實現(xiàn)的訪問控制策略。
在最簡單的情況下，網(wǎng)關(guān)可以檢查令牌是否有效（例如基于簽名）、令牌是否已過期以及令牌是否具有調(diào)用 API 方法所需的范圍。但是，也可以實施更復(fù)雜的策略，這些策略取決于運行時數(shù)據(jù)。例如，可以有一個策略規(guī)定某個 API 方法只允許在 IP 范圍 xy 和辦公時間內(nèi)使用。與令牌發(fā)行階段類似，此類策略通常在 XACML 中實現(xiàn)，API 網(wǎng)關(guān)必須聯(lián)系 XACML 引擎，為每個 API 請求提供相關(guān)詳細(xì)信息，以執(zhí)行授權(quán)。
此外，還可以組合限制功能來實施更高級的策略。例如，可以規(guī)定 HMart 地區(qū)辦事處的用戶每小時只能調(diào)用 10 次倉庫/訂單方法。API 網(wǎng)關(guān)、IDP 和限制組件必須協(xié)同工作才能實施此類策略。如果限制組件提供限制流量突發(fā)的功能（例如，每天允許 2000 個請求，但突發(fā)限制為每秒 100 個請求），那么 API 限制策略還可用于實施某種程度的保護(hù)以防止應(yīng)用程序?qū)泳芙^服務(wù) (DOS) 攻擊。圖 3 顯示了在 API 調(diào)用階段使用限制策略和訪問控制策略來保護(hù) API 安全。請注意，在這種情況下，使用單獨的限制組件，而策略評估引擎內(nèi)置于 API 控制面板中。
另一個安全要求是防止基于使用 API 的 Web 應(yīng)用程序的可能攻擊。當(dāng)單頁應(yīng)用程序使用 API 時，它可能會將 API 令牌存儲在瀏覽器的本地存儲或會話存儲中。然后，如果用戶打開惡意網(wǎng)頁（來自另一個站點），它可以訪問 API 令牌并調(diào)用 API。此外，如果 API 網(wǎng)關(guān)需要在 HTTP cookie 中發(fā)送 API 令牌，則在同一瀏覽器會話中打開的惡意網(wǎng)頁可以簡單地向目標(biāo) API 發(fā)送請求。另一種可能性是，在同一瀏覽器會話中打開的惡意網(wǎng)頁與 IDP 執(zhí)行 OAuth 令牌授予流程以獲取有效令牌。防止上述攻擊的最佳方法是強(qiáng)制實施 API 的跨源資源共享 (CORS) 策略。CORS 策略允許 API 開發(fā)人員聲明允許哪些域名、HTTP 方法、HTTP 標(biāo)頭等進(jìn)行 API 調(diào)用。例如，HMart API 可能有一個 CORS 策略，規(guī)定只有 hmart.com 和 abcstore.com 才允許進(jìn)行 API 調(diào)用，因此，如果攻擊者.com 站點試圖對 HMart API 進(jìn)行 API 調(diào)用，Web 瀏覽器將阻止。
API 安全的另一個關(guān)鍵方面是保護(hù)流經(jīng) API 層的消息。由于與組織的所有交互都是通過 API 層進(jìn)行的，因此我們可以通過執(zhí)行消息級別策略來確保非預(yù)期方不會收到敏感信息，而預(yù)期方會收到正確的信息。
TLS 是在傳輸層實現(xiàn)機(jī)密性和完整性的主要方法。通過在客戶端應(yīng)用程序和 API 層之間以及 API 層和后端服務(wù)之間啟用 TLS，我們可以保證消息內(nèi)容在傳輸過程中不會被修改，也不會暴露給非預(yù)期方。
但是，在某些情況下，我們需要更細(xì)粒度的內(nèi)容保護(hù)。例如，患者的病史詳情應(yīng)僅供指定醫(yī)生查看，而全名、電子郵件等信息則可供醫(yī)院的一般工作人員查看。在這種情況下，應(yīng)該可以在 API 層實施策略，以便如果 API 調(diào)用不是由相關(guān)醫(yī)生發(fā)出的，則患者的病史詳情將從響應(yīng)負(fù)載中刪除。這種從消息負(fù)載中選擇性刪除信息的方式在遵守 GDPR 等法規(guī)時也有助于保護(hù)個人身份信息 (PII)。還可以通過加密消息的某些部分來支持選擇性地公開信息，以便只有授權(quán)的應(yīng)用程序才能讀取這些詳細(xì)信息。
與有效載荷保護(hù)相關(guān)的另一個關(guān)鍵點是根據(jù)定義的策略驗證有效載荷。一個這樣的用例是確保有效載荷包含特定格式的所有相關(guān)字段。例如，倉庫物品列表響應(yīng)必須包含每件物品的物品 ID、單位數(shù)量和單價。這種類型的消息格式驗證通常由 XML 模式或 JSON 模式驗證執(zhí)行。除了模式驗證之外，API 層還可以通過阻止任何有害內(nèi)容（例如 SQL 注入、PHP 注入、Javascript 注入等）來保護(hù)有效載荷。此類保護(hù)可以在 API 網(wǎng)關(guān)上作為一組正則表達(dá)式驗證來實現(xiàn)。圖 4 說明了在 API 網(wǎng)關(guān)上實施的示例消息級別保護(hù)。
此外，API 層還可以通過使用 API 網(wǎng)關(guān)的私鑰對有效負(fù)載進(jìn)行簽名來確保消息內(nèi)容在傳輸過程中不會被修改。由于 API 使用應(yīng)用程序以及后端服務(wù)都信任 API 網(wǎng)關(guān)的證書，因此 API 網(wǎng)關(guān)的簽名在大多數(shù)情況下足以確認(rèn)消息的完整性。如果使用 TLS，傳輸層將確保整個有效負(fù)載的消息完整性。但是，如果只需要對有效負(fù)載的某些部分進(jìn)行完整性驗證，API 層可以使用 XPath 或 JSON 路徑表達(dá)式對選擇性有效負(fù)載部分進(jìn)行簽名。
前面幾節(jié)討論了在 API 層實施的安全策略。但是，API 層公開的后端服務(wù)也可能具有各種安全機(jī)制。例如，后端服務(wù)本身可以是受 OAuth 保護(hù)的 API。在這種情況下，API 層應(yīng)充當(dāng) OAuth 客戶端，并在每次后端調(diào)用時提供有效令牌。一種方法是在 API 層中嵌入永久令牌。但是，如果令牌有到期時間，API 層必須使用相關(guān) IDP 執(zhí)行令牌刷新流程并在必要時更新令牌（見圖 5）。在 API 網(wǎng)關(guān)的集群部署中，必須通過共享存儲等機(jī)制向集群中的所有網(wǎng)關(guān)節(jié)點提供此類后端令牌。
API 層只能根據(jù)從請求中得出的信息（例如 API 方法、用戶詳細(xì)信息、源 IP、時間戳等）執(zhí)行訪問控制。如果需要基于后端數(shù)據(jù)執(zhí)行任何其他訪問控制活動，則必須在后端服務(wù)中實現(xiàn)這些策略。
API 層是組織所有功能公開的中心點。因此，在 API 層執(zhí)行各種 API 操作期間可以捕獲大量信息。這些信息可用于獲取安全見解并預(yù)測可能的威脅。
首先，我們可以考慮審計方面。API 層用于由各種用戶組執(zhí)行多項操作。API 創(chuàng)建者使用 API 層來創(chuàng)建 API 并發(fā)布它們。管理用戶可以創(chuàng)建不同的策略應(yīng)用于 API。應(yīng)用程序開發(fā)人員可以訂閱 API 并生成密鑰。管理級用戶可以批準(zhǔn)某些與 API 相關(guān)的操作。API 層可以記錄所有這些操作以及涉及的用戶、時間戳和其他相關(guān)詳細(xì)信息以創(chuàng)建審計日志。每當(dāng)發(fā)生安全漏洞時，都可以根據(jù)這些審計日志跟蹤詳細(xì)信息，例如誰創(chuàng)建了 API、誰批準(zhǔn)了它以及哪些應(yīng)用程序正在使用它。此類審計日志可以寫入文件或數(shù)據(jù)庫，稍后可以由內(nèi)置審計組件進(jìn)行處理。此外，還可以將這些審計日志泵送到 ELK 或 Splunk 等分析系統(tǒng)。
除了上面提到的 API 操作之外，我們可以在 API 層捕獲的另一個重要信息是 API 調(diào)用詳細(xì)信息。API 調(diào)用操作的數(shù)量比其他 API 操作高得多，這通常需要單獨且更具可擴(kuò)展性的分析組件來捕獲和處理這些事件。由于 API 調(diào)用的數(shù)量可能達(dá)到每月數(shù)百萬或數(shù)十億，我們通常對基于這些事件的總結(jié)和預(yù)測感興趣。例如，我們可能會觀察到一個應(yīng)用程序在過去 3 個月內(nèi)一直在使用 IP 范圍 X，并且它突然從 IP 地址 y（不在 X 范圍內(nèi)）發(fā)送請求。在這種情況下，安全分析組件可以檢測到常規(guī)模式的變化并阻止請求或向管理員發(fā)送通知。同樣，如果 API 在過去 6 個月內(nèi)每分鐘收到 20 個請求，并且如果它突然開始每分鐘收到 1500 個請求，則分析組件可以通知管理員常規(guī)模式的變化。這種基于模式的安全場景可以在分析組件中預(yù)先定義（例如，如果 API 上的請求數(shù)與過去 6 個月的平均請求數(shù)相比增加了 200%，則通知）。還可以將 ML 模塊與 API 分析集成，以便它可以學(xué)習(xí) API 調(diào)用模式，并在調(diào)用發(fā)生在學(xué)習(xí)模式之外時采取行動。
組織可能在兩個方面涉及 API。首先，作為 API 提供者，組織可能將其功能作為 API 公開給內(nèi)部和外部消費者。然后，作為消費者，組織內(nèi)使用的各種應(yīng)用程序可能使用內(nèi)部和外部 API。在考慮 API 和應(yīng)用程序的安全性時，跟蹤所有已發(fā)布的 API 以及所有應(yīng)用程序的 API 依賴關(guān)系至關(guān)重要。
讓我們考慮兩個例子，一個是 API 提供者，另一個是 API 消費者。假設(shè)某個組織的銷售部門維護(hù)一個 API，供其合作伙伴下批量訂單。該部門隨著時間的推移改進(jìn)了此 API，并創(chuàng)建了具有各種附加功能的多個版本。由于該組織有許多合作伙伴，并且并非所有合作伙伴都準(zhǔn)備好立即使用最新版本，因此它必須維護(hù)多個處于活動狀態(tài)的 API 版本。現(xiàn)在讓我們假設(shè)該組織的中央 IT 部門引入了一項新政策，規(guī)定所有合作伙伴 API 應(yīng)僅允許相應(yīng)合作伙伴使用的 IP 地址范圍。如果沒有一個中心位置來跟蹤提供給合作伙伴的所有 API 及其活動版本，則很難對所有相關(guān) API 實施此安全策略。這可能會遺漏一些 API 并暴露安全漏洞。
現(xiàn)在考慮 API 消費者場景，我們可以以應(yīng)用程序開發(fā)人員為保險公司實施健康保險索賠處理應(yīng)用程序為例。在開發(fā)期間，開發(fā)人員使用沙盒版本的多個 API，例如 CRM API 和支付百分比計算 API。現(xiàn)在，當(dāng)索賠處理應(yīng)用程序移至生產(chǎn)環(huán)境時，開發(fā)人員可能會忘記將某些依賴 API 更改為生產(chǎn)版本。由于沙盒 API 中未實施生產(chǎn)級安全策略，這可能導(dǎo)致泄露公司客戶的敏感健康相關(guān)信息。
處理這些問題的主要方法是通過 API 治理。API 治理政策可能規(guī)定，所有內(nèi)部發(fā)布的 API 必須由相應(yīng)部門的經(jīng)理批準(zhǔn)，外部發(fā)布的 API 必須由經(jīng)理和中央 IT 團(tuán)隊批準(zhǔn)。它還可能規(guī)定所有 API 必須遵守特定的安全準(zhǔn)則列表。此外，根據(jù)該政策，所有 API 可能都必須發(fā)布到中央門戶，這有助于標(biāo)記、搜索和分類 API。因此，當(dāng)需要引入新的安全策略時，可以通過中央 API 門戶輕松發(fā)現(xiàn)所有活動 API。為了管理應(yīng)用程序?qū)?API 的消耗，組織可能會要求所有依賴 API 都需要在中央 API 門戶中注冊。因此，應(yīng)用程序必須在中央 API 門戶中訂閱 API 并獲取令牌才能使用這些 API。這使管理員和 IT 團(tuán)隊能夠輕松跟蹤哪些應(yīng)用程序使用哪些 API 并根據(jù)依賴關(guān)系實施策略（例如，如果應(yīng)用程序依賴于任何 API 的非生產(chǎn)版本，則不允許將其部署在生產(chǎn)環(huán)境中）。
圖 7 突出顯示了與 API 治理相關(guān)的 APIM 平臺的主要組件。API 治理的一個關(guān)鍵功能是支持可擴(kuò)展的 API 生命周期管理。API 生命周期管理功能允許管理員定義 API 的各個生命周期階段（例如創(chuàng)建、審核、發(fā)布、棄用、退役等）及其轉(zhuǎn)換。此外，還可以關(guān)聯(lián)狀態(tài)轉(zhuǎn)換的工作流，例如，可以指定兩個經(jīng)理級用戶必須批準(zhǔn) API，然后才能將其移至已發(fā)布狀態(tài)。此外，還可以在狀態(tài)轉(zhuǎn)換工作流中調(diào)用外部系統(tǒng)，這使我們能夠在使用多個 API 管理部署的情況下將 API 發(fā)布到中央 API 門戶（或中央注冊表）。
除了 API 生命周期管理功能外，復(fù)雜的 API 門戶在 API 治理中也發(fā)揮著重要作用。面向應(yīng)用程序開發(fā)人員的門戶可以跟蹤應(yīng)用程序的 API 依賴關(guān)系，還可以強(qiáng)制應(yīng)用程序?qū)?API 訂閱實施基于策略或工作流的授權(quán)。API 開發(fā)人員使用的門戶可以控制誰可以創(chuàng)建、審查或發(fā)布 API，誰可以查看和編輯 API，根據(jù)創(chuàng)建者的角色將 API 發(fā)布到哪些 API 網(wǎng)關(guān)等。如果 API 管理平臺不支持足夠的治理功能，則可能需要利用外部注冊表進(jìn)行治理。但是，在這種情況下，API 管理平臺和注冊表之間可能必須進(jìn)行大量集成。
僅使用 API 管理平臺或 API 網(wǎng)關(guān)無法保證 API 的安全。根據(jù)安全架構(gòu)部署 API 平臺模塊、后端服務(wù)和其他組件也是 API 安全的關(guān)鍵任務(wù)。圖 8 顯示了 API 部署的示例。
圖中所示的每個節(jié)點通常都是兩個或多個實例的集群。API 層由以下組件組成：API 網(wǎng)關(guān)、API 控制面板、密鑰管理器、API 分析模塊和集成模塊。
API 網(wǎng)關(guān)充當(dāng)后端服務(wù)和客戶端應(yīng)用程序之間的代理。因此，API 調(diào)用級別的安全實施在網(wǎng)關(guān)處執(zhí)行。API 控制面板具有發(fā)布 API、定義策略和訂閱 API 的功能。密鑰管理器用于頒發(fā)和驗證 API 令牌。因此，令牌頒發(fā)級別的安全實施由密鑰管理器處理。分析模塊從網(wǎng)關(guān)收集 API 調(diào)用數(shù)據(jù)，可用于評估速率限制策略。集成模塊可以連接多個后端和云服務(wù)，并可以執(zhí)行必要的消息轉(zhuǎn)換、協(xié)議匹配、消息驗證和服務(wù)編排。
上述 API 層的組件及其職責(zé)只是部署的一個示例，供應(yīng)商可以采用不同的方式實現(xiàn)這些組件。例如，可以將密鑰管理器組合到控制面板中，并將分析模塊實現(xiàn)為現(xiàn)有分析平臺（如 ELK）的一組擴(kuò)展。此外，還可以在 API 網(wǎng)關(guān)本身中實現(xiàn)集成功能，而無需單獨的模塊。但是，擁有單獨的模塊可以增加部署的靈活性，并允許我們根據(jù)需要擴(kuò)展單個組件。
現(xiàn)在，如果我們回到部署方面，所有 API 層組件都可以部署在組織的內(nèi)部網(wǎng)絡(luò)內(nèi)，這樣任何組件都不允許直接通過外部流量。然后，我們可以在 DMZ 中放置一個負(fù)載均衡器，并允許負(fù)載均衡器通過防火墻到 API 網(wǎng)關(guān)的流量。
但是，一個組織可能有多種類型的 API 消費者。首先，可能是公共消費者（例如，在線購物門戶的客戶），他們將通過互聯(lián)網(wǎng)訪問 API。然后，可能是合作伙伴組織，他們也通過互聯(lián)網(wǎng)訪問 API。但是，由于合作伙伴組織的數(shù)量有限，因此可以獲取這些組織使用的 IP 地址范圍。此外，可能存在位于不同地區(qū)或國家的分支機(jī)構(gòu)。可以與這些分支機(jī)構(gòu)建立 VPN 連接。現(xiàn)在我們可能希望向這些消費者公開不同的 API 集。因此，可以為每種消費者類型使用單獨的網(wǎng)關(guān)集群，并僅將該消費者所需的 API 部署到相應(yīng)的網(wǎng)關(guān)集群中，如圖 8 所示。然后，我們可以制定防火墻規(guī)則，規(guī)定僅允許網(wǎng)關(guān) 1 的公共流量，而網(wǎng)關(guān) 2 僅限于合作伙伴的源 IP 范圍。此外，網(wǎng)關(guān) 3 僅限于來自分支機(jī)構(gòu)的 VPN 連接。
密鑰管理器組件負(fù)責(zé)頒發(fā)令牌并評估高級運行時策略。例如，可以制定一項策略，規(guī)定只有屬于warehouse_admin角色的用戶才可以在下午 6:00 之后調(diào)用“warehouse/add_item”方法。為了評估此類策略并執(zhí)行基于用戶屬性的令牌頒發(fā)，必須將用戶存儲與密鑰管理器關(guān)聯(lián)起來。這可以是 LDAP 存儲或數(shù)據(jù)庫支持的自定義用戶存儲。此外，組織可能已經(jīng)部署了中央身份和訪問管理 (IAM) 系統(tǒng)來管理所有用戶詳細(xì)信息。在這種情況下，API 密鑰管理器組件應(yīng)該能夠與中央 IAM 系統(tǒng)聯(lián)合，以便在 IAM 系統(tǒng)內(nèi)配置的用戶可以無縫訪問 API。此外，組織可能還希望其用戶使用他們的 Google 或 Facebook 憑據(jù)訪問 API。為了滿足這些要求，密鑰管理器必須使用 OpenID Connect、SAML 或這些提供商使用的自定義協(xié)議等協(xié)議與這些云身份提供商聯(lián)合。
現(xiàn)在我們可以考慮后端服務(wù)。這些服務(wù)可以部署在組織的內(nèi)部網(wǎng)絡(luò)或單獨的網(wǎng)絡(luò)中。顯然，無論哪種情況，此類服務(wù)都不應(yīng)在未經(jīng)過 API 網(wǎng)關(guān)或其他保護(hù)機(jī)制的情況下暴露給外部各方。如果服務(wù)部署在單獨的網(wǎng)絡(luò)中，則 API 層和第二個網(wǎng)絡(luò)之間必須有某種類型的安全連接（例如 VPN），如圖 8 所示。此外，其中一些服務(wù)可能是基于云的服務(wù)或合作伙伴公司提供的服務(wù)。在這種情況下，這些服務(wù)具有某種保護(hù)機(jī)制（例如 OAuth），因此 API 層應(yīng)該充當(dāng) API 客戶端，如保護(hù)后端服務(wù)中所述。
正如本文所討論的，為了妥善保護(hù) API，需要考慮多個方面。其中一些安全功能由 API 管理平臺開箱即用地支持，而另一些則必須作為擴(kuò)展插入到這些平臺中。此外，可能還需要將 API 管理平臺與外部工具集成以符合組織的安全策略，同時還可能存在與產(chǎn)品部署而非產(chǎn)品本身相關(guān)的安全策略。因此，為了有效地保護(hù) API，必須考慮所有這些方面。
文章來源：An Overview on API Security
