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，需要考慮到方方面面。