API安全綜述
API安全綜述
譯自：An Overview on API Security。
本文概括了API防護有關的方方面面，從上層視角介紹了API防護中主要注意的點，並給出了相應的建議。本文可以作為一個API防護架構的啟發文檔。
APIs是訪問一個組織功能和數據的入口，但無意間暴露的API可能會對組織的數字資產造成相當大的破環，同時有可能泄露敏感資訊。因此，在實現數字化轉型項目時，需要重點考慮APIs的安全性。
在上一篇文章中已經討論了與API認證有關的問題，本文關注與API安全有關的其他重要因素，以及對應的解決方案。
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調用。
token頒發過程中的訪問控制
在一個基本場景中，我們會使用基於角色的訪問控制來表明特定角色的作用域。例如，我們可以使用一個訪問控制策略，給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。
API調用過程中的訪問控制
正如前面提到的，通常需要提供應用憑證和用戶憑證來獲取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治理
一個組織可能會在兩方面涉及對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管理平台或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，需要考慮到方方面面。
