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