譯自：An Overview on API Security。
本文概括了API防護有關的方方面面，從上層視角介紹了API防護中主要注意的點，并給出了相應的建議。本文可以作為一個API防護架構的啟發文檔。
APIs是通路一個組織功能和資料的入口，但無意間暴露的API可能會對組織的數字資産造成相當大的破環，同時有可能洩露敏感資訊。是以，在實作數字化轉型項目時，需要重點考慮APIs的安全性。
在上一篇文章中已經讨論了與API認證有關的問題，本文關注與API安全有關的其他重要因素，以及對應的解決方案。
目錄
API安全綜述
API調用中的通路控制
token頒發過程中的通路控制
API調用過程中的通路控制
消息防護
後端服務的安全性
基于分析的安全性
APIs治理
API部署防護
首先考慮一下APIs的通路控制，它確定隻有預定方才能通路API。API通路控制的行業标準是OAuth2.0。圖1展示了基于OAuth API調用的兩個活動，一個應用需要從一個有效的身份提供程式擷取token，然後在每次API調用中發送将其發送到API網關。是以很多通路控制場景都會圍繞該token。注意，可以在API控制面實作IDP功能，也可以在API部署中使用獨立的IDP。
Figure 1: 基于token的API通路控制簡介
通常會基于作用域來實作通路控制。一個OAuth token可以關聯任意多個作用域。例如一個倉庫管理系統，相關的作用域可能是list_items 和order_item，可以使用如下兩個倉庫API方法：
GET hmart.com/warehouse/items — required scope: list_items
POST hmart.com/warehouse/orders — required scope: order_item
現在，可以在list_items 作用域中使用token_1 ，而在list_items 和order_item 作用域中同時使用token_2 。是以，一個應用可以使用token_1調用 hmart.com/warehouse/items 方法，使用token_2 調用兩個API方法。
下面關注一個應用如何擷取一個token。OAuth 2.0規範在授予類型中提到了該過程。兩種有用的授予類型為：授權代碼授予類型和客戶憑證授予類型。當使用授權代碼授予時，應用必須提供應用憑證以及使用者憑證來擷取token。當使用客戶憑證授予時，隻需要提供應用憑證即可擷取token。這兩種場景下，都需要在請求中指定需要的作用域。
在了解了token，作用域和授予類型後，現在看下，API通路控制如何使用token。基于token的通路控制的使用可以分為兩個階段：(1)token的頒發和(2)API調用。
在一個基本場景中，我們會使用基于角色的通路控制來表明特定角色的作用域。例如，我們可以使用一個通路控制政策，給warehouse_admin 角色授予list_items 和order_item作用域，但僅給warehouse_staff 角色授予list_items 作用域。為了頒發一個order_item 作用域的token，需要考慮如下三個條件：(1)該使用者是否是warehouse_admin 角色，(2)使用者是否在HMart總公司工作，(3)源IP是否屬于Australia. XACML(可以使用IP實作進階授權政策)。可以使用XACML(可擴充通路控制标記語言) 來實作這類進階授權政策。
可以擴充标準的授予方式或引入新的授予方式，擷取token的過程支援很多通路控制場景。例如，可以在釋出token時加入審批流程，這樣可以在IDP将token發往應用之前，由特定使用者進行token請求的審批。這種情況下，由于審批流程時間比較長，通常需要一個獨立的通道将token發往應用。圖2展示了通路控制政策和token審批流。
Figure 2: token頒發期間基于屬性和基于工作流程的授權
在API控制面存儲了使用者角色以及針對不同角色指定的政策。
API使用者可能會在發送實際的token請求前請求作用域，這種情況下，可以使用基于授權政策或審批流程的IDP進行處理。但無論哪種場景，隻要授予了作用域請求，IDP就會維護一個使用者和授予的作用域之間的映射狀态。後續當一個應用代表一個使用者請求該作用域的token時，IDP會查找映射，然後決定是否給該請求作用域頒發token。
正如前面提到的，通常需要提供應用憑證和使用者憑證來擷取token。是以，可以将應用程式和使用者帳戶與令牌進行關聯。當在API調用過程中發送一個token到API網關時，API網關可以在IDP以及相關元件的幫助下授權請求。該授權步驟可能會執行很多無法在token頒發階段使用的通路控制政策。
在最簡單的場景下，網關可以檢查token是否有效(如基于簽名)，是否過期以及token的作用域是否正确。但同時也可以基于運作時的資料執行很多複雜的政策。例如，可以使用一個政策來規定在上班期間，隻有IP段為x-y的用戶端能夠發起特定的API方法。與token頒發階段類似，可以使用XACML實作這類政策。API網關需要使用API請求的相關資訊來聯系XACML引擎，并以此執行授權功能。
而且可以結合限流功能實作更進階的政策。例如，可以規定在HMart區域辦事處工作的員工每小時可以有10次機會調用warehouse/orders方法。API網關、IDP和限流元件必須通力合作來實作這些政策。如果限流元件提供了限制流量突發的功能，API限流政策(如每天允許2000個請求，每秒的請求數限制為100。)也可以用于防護某些級别的應用層DOS攻擊。圖3展示了使用限流政策和通路控制政策在API調用階段對API進行防護。注意這種情景下使用了一個獨立的限流元件，并将政策評估引擎放到了API控制面。
另一個安全需求是防護來自使用這些APIs的web應用的攻擊。當一個單頁應用使用APIs時，它可能在浏覽器本地存儲或會話存儲中儲存API token。如果一個使用者打開了一個惡意網頁(從另外一個站點)，則該網頁就可以通路API token并調用API。而且，當一個API網關要求在HTTP cookies中發送API token時，在相同的浏覽器會話中打開的惡意網頁就可以向目标API發送請求。還有一種可能性，即在同一浏覽器會話中打開的惡意網頁會與IDP一起執行OAuth令牌授予流程，以擷取有效令牌。防護上述攻擊的最佳方式是對API強制使用跨域資源共享(CORS)政策。CORS政策允許API開發者說明API調用可以使用的域名、HTTP方法、HTTP首部等。例如，HMart API可能使用一個CORS政策來說明僅允許hmart.com 和 abcstore.com站點調用API，是以web浏覽器會阻止attacker.com向HMart發起API調用。
API安全性的另一個關鍵點是對API層的消息流進行防護。由于一個組織會通過API層進行互動，是以需要通過消息層面的政策保證不會意外洩露敏感資訊，并讓正确的接收方接收到正确的資訊。
TLS是在傳輸層實作機密性和完整性的主要方法。通過在用戶端應用和API層，以及API層和後端服務之間啟用TLS，就可以保證在消息傳遞過程中不會被篡改或洩露。
但在某些情況下需要更細粒度的内容保護。例如，病人的曆史資訊隻能被配置設定的醫生檢視，而名字、電子郵箱等可以被普通的醫院員工檢視。這種場景下，需要在API層實作政策，這樣如果不相關的醫生發起API調用時，就可以将病人的曆史資訊從響應載荷中移除。這種可以從消息載荷中選擇性進行移除的處理方式也可以用于在遵守如GDPR之類的法規時，保護個人身份資訊(PII)。可以通過對部分内容進行加密來選擇性地暴露資訊，這樣隻有授權的應用可以閱讀這些資訊。
載體防護的另一個關鍵點是使用定義的政策對其進行校驗。一種使用場景是保證載體包含特定格式的所有相關字段。例如，倉庫條目清單響應必須包含條目ID，每個條目數目和單價。通常采用XML模式或JSON模式校驗消息格式。除了模式校驗，API層也應該提供阻止如SQL注入、PHP注入、Javascript注入的有害内容。可以在API網關側以一組正規表達式的方式實作這類防護。圖4描述了在API網關實作了消息級别的防護。
Figure 4: API網關上基于JSON模式、内容移除政策和TLS的載體防護
上圖中使用了兩組證書，API網關會解除安裝用戶端證書，并使用後端證書加密通信。
API層可以通過使用API網關的私鑰簽名載體的方式，確定消息内容不會在傳輸過程中被修改。由于調用API的應用和後端服務都信任API網關的證書，是以API網關的簽名可以在大多數場景下確定消息的完整性、如果使用了TLS，則會由傳輸層保證整個消息載體的完整性。但如果隻需要確定載體中特定部分的完整性，則API層可以使用XPath或JSON表達式對選擇的載體部分進行簽名。
前面章節主要關注API層的安全政策。但由API層暴露的後端服務也可能有各種安全機制。例如，一個後端服務可能是一個使用OAuth防護的API。這種情況下，API層可能作為一個OAuth用戶端，并在每個後端調用中提供有效的token。一種方式是在API層中嵌入一個永久的token，但如果token有有效期的話，API層必須使用相關的IDP執行token重新整理流程，并在需要時更新token(見圖5)。在以叢集方式部署API網關時，這類後端token需要使用如共享存儲的方式，使之在所有的網關節點上生效。
Figure 5: API層通路使用OAuth 2.0防護的後端服務
API層僅可以基于請求的資訊(如API方法，使用者資訊，源IP，時間戳等)執行通路控制。如果需要根據後端資料執行額外的通路控制，則需要在後端服務中實作這些政策。
API 層是暴露一個組織所有功能的核心。是以，可以在API層的API操作中捕獲大量資訊，這些資訊可以用來洞察安全性并推測可能存在的威脅。
首先，考慮稽核方面。多個使用者組可以使用API層來執行多種操作。API的建立者會使用API層建立并釋出APIs，系統管理者可能為APIs建立不同的政策，應用開發者可能會訂閱API并生成密鑰，部門管理級使用者可能會允許相關APIs的某些操作。API層可以通過記錄操作涉及的所有使用者、時間戳以及其他細節來建立審計日志。當發生安全問題時，就可以在審計日志中追溯誰建立了API，誰允許該API以及那個應用使用了API。這些審計日志可以寫入檔案或資料庫，後續可以由内置的審計元件處理，也可以将這些審計日志導入分析系統，如ELK或Splunk。
Figure 6: 使用API調用資料來彙總與安全性有關的資訊，并觸發與安全性有關的事件通知
除了上面提到的API操作，在API層可以捕獲到的另外一個重要資訊是API調用細節。API調用操作的次數要遠遠大于API本身的操作次數，通常需要使用單獨的、可擴充性更高的分析元件來捕獲和處理這些事件。由于每月的API調用次數可以達到百萬甚至上億，通常我們更關注基于這些事件的彙總以及預測。例如，一個應用在過去的3個月内使用IP段X，但突然從IP段Y發出了一個請求(不在X範圍内)。這種情況下，安全分析元件會在常用的模式中探測到這種變更，并阻止該請求或給系統管理者發送一條提醒資訊。類似地，如果一個API在過去的6個月内每分鐘接收20個請求，但突然增加到每分鐘1500個請求，分析元件可以根據常用的模式來通知到系統管理者此次變更。這種基于安全場景的模式可以在分析元件中進行定義(如，當一個API的請求數是過去6個月平均請求數的兩倍時發出通知)。也可以內建API分析的機器學習模型，這樣可以學習API的調用模式，并在調用出現異常時采取對應的動作。
一個組織可能會在兩方面涉及對APIs的治理。首先，作為一個API提供者，必須通過APIs将功能暴露給内部和外部消費者，其次作為一個消費者，各種組織内使用的應用可能會使用内部和外部的APIs。當考慮APIs和應用的安全性時，需要關注所有釋出的APIs以及所有應用依賴的API。
舉兩個API提供者和API消費者的例子。假設一個組織的銷售部門為它的合作夥伴維護一個用于批量下單的API。後續部門為了提升該API的功能建立了多個版本，并添加了很多特性。由于部門有很多合作夥伴，且不是所有的合作夥伴都會立即使用最新版本的API，是以需要同時維護多個版本的API。現在假設組織的中央IT部門引入了一個新的政策，該政策要求合作夥伴的APIs僅能使用特定的IP段。如果無法集中跟蹤提供給所有合作夥伴的APIs及其版本，那麼就很難為所有APIs執行該安全政策，可能會錯過一部分API，造成安全隐患。
看下API消費者的場景，假設一個應用開發者為一個保險公司實作了一個醫療保險索賠處理程式。在開發過程中，開發者使用了沙盒版本中的多個API，如CRM API和付款百分比計算API。現在将索賠處理程式轉移到生産環境，有可能因為開發者忘記将依賴的APIs轉變為生産版本，導緻無法執行生産級别的安全政策，這樣可能會洩露公司客戶的敏感健康資訊。
處理這些問題的主要方式是API治理。API治理政策可能會要求所有對内釋出的API必須經過對應部門的管理者的同意，對外釋出的APIs必須經過管理者和中央IT團隊的同意。還可能要求所有的APIs必須遵守特定的安全準則。而且，這些政策可能要求所有的APIs必須釋出到一個中央門戶中，友善對API進行标記，搜尋和分類。是以，當需要引入一個新的安全政策時，通過中央API門戶能夠發現所有活動的APIs。為了治理應用消費的API，組織可能會強制要求将所有依賴的APIs注冊到中央API門戶中。這樣應用必須向中央API門戶訂閱API，有助于管理者和IT團隊跟蹤哪些應用使用APIs，并基于依賴配置政策(如，如果一個應用基于非生産版本的API，則不允許将其部署到生成環境中)。
Figure 7: 使用API管理平台和中央系統資料庫來治理API
上圖給出了一個API管理平台架構，包括開發門戶、API生命管理、API流程引擎(稽核、釋出等)以及資料分析等元件。
圖7展示了與API治理有關的APIM平台的主要元件。API治理的一個主要特性是支援擴充API生命周期管理。API生命周期管理特性允許管理者定義APIs的各種生命周期階段(如，建立，稽核，釋出，廢除，重試等)和它們之間的過渡，以及為狀态過度關聯相應的流程。例如，在将一個API轉變到釋出狀态之前，必須經兩個管理級别的使用者的同意。此外，在狀态過度流程中可以調用外部系統，這樣可以在使用多個API管理部署的情況下，允許将APIs釋出到一個中央API門戶(或一個中央系統資料庫)。
除了API生命周期管理特性外，複雜的API門戶在API治理中扮演着一個重要角色。應用開發者可以使用門戶來跟蹤應用的API依賴，并為應用的API訂閱添加基于政策或基于流程的授權。API開發者使用的門戶也可以用于控制誰建立、稽核或釋出了APIs，允許誰檢視和編輯APIs，以及基于建立者的角色将API釋出到哪個API網關等。如果一個API管理平台沒有足夠的治理功能，則可能需要使用外部系統資料庫進行治理。但這種情況下，需要考慮API管理平台和系統資料庫之間的內建的數量。
僅使用API管理平台或API網關是無法防護APIs的。對API安全性來說，根據安全架構來部署API平台子產品、後端服務和其他元件也是一個重要任務。
Figure 8: 部署API管理元件、後端服務、多身份提供方，并連接配接到雲服務
上圖中的每個節點通常是兩個或更多執行個體組成的叢集。API層考慮如下元件：API網關，API控制面，密鑰管理器，API分析子產品和內建子產品。
API網關作為後端服務和用戶端應用之間的代理，會在網關上執行API調用層面的安全功能。API控制面具有釋出APIs、定義政策和訂閱APIs的功能。密鑰管理器用于頒發和校驗API tokens。是以由密鑰管理器執行token頒發層面的安全功能。分析子產品會從網關收集API調用資料，用于評估限速政策。內建子產品可以連接配接多個後端和雲服務，執行必要的消息轉換、協定比對、消息校驗和服務編排等。
上面給出了一個API層的元件及其職責的部署案例，實際可以采用多種實作方式。例如，可以将密鑰管理其也納入控制面，将分析子產品作為現有分析平台（如ELK）的擴充。這樣就可以在API網關上實作內建功能，無需使用單獨的子產品。但使用單獨的子產品可以增加部署的靈活性，并在需要時擴充獨立的元件。
現在，如果回到部署方面，所有的API層元件都可以部署到組織的内網中，這樣任何元件都不能直接通路外部服務。此時在DMZ中安裝一個負載均衡器，并允許負載均衡器通過防火牆接通API網關流量。
然而，一個組織可能有多種類型的API消費者。首先會有公共消費者(如線上購物門戶的客戶)，會從網際網路絡上通路APIs。此外還會有合作夥伴所在的組織從網際網路通路APIs。但可以限制合作夥伴的組織數目，并為這些組織配置設定它們可以使用的IP位址段。此外，不同的地區和國家可能會存在分支機構，可以使用VPN連接配接這些分支機構。為了給這些消費者暴露一組API是，可以為每個消費類型采用獨立的網關叢集，僅将該使用者所需的API部署到相應的網關群集中(如圖8所示)。然後使用防火牆規則指出僅允許網關1的公網流量，網關2僅限于合作夥伴的IP段。更近一步，可以将網關3限制為分支機構的VPN通路。
密鑰管理器元件負責頒發tokens并評估進階運作時政策。例如，可以使用政策配置僅允許warehouse_admin角色的使用者才能在6.00 PM之後調用“warehouse/add_item”方法。為了評估這些政策并基于頒發的token執行使用者功能，需要将使用者存儲和密鑰管理器關聯起來。使用者存儲可以是一個LDAP存儲或自定義的使用者存儲資料庫。一個組織可能會部署一個中央身份中心和通路管理(IAM)系統來管理所有的使用者細節。這種情況下API密鑰管理元件需要聯合IAM系統，這樣IAM系統中的使用者就可以無縫通路APIs。此外，組織可能期望它的使用者使用他們的Google或FaceBook憑證來通路APIs，這類雲身份供應商使用了如OpenID Connect、SAML、或自定義的協定。
現在考慮一下後端服務，這些服務可以部署在組織的内部網絡或一個獨立的網絡中。不管那種場景，這類服務都不能不經過API網關或其他防護機制暴露到外部。如果服務部署在一個獨立的網絡中，需要在API層和第二個網絡中使用安全連接配接(如VPN)。有些服務可能是基于雲的服務或由合作夥伴公司提供的服務，這種情況下，這些服務可以使用如OAuth這樣的機制進行防護，此時，API層應該作為一個API用戶端(正如在對後端服務防護中提到的)。
為了适當地保護API，應該考慮多個領域。有些安全特性是(API管理平台)開箱即用的，而有些需要作為擴充嵌入這些平台。為了與組織的安全政策保持一緻，可以将API管理平台和外部工具進行內建，也可以使用與産品部署(而非産品本身)有關的安全政策。是以為了有效防護APIs，需要考慮到方方面面。