您正在查看 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info
總覽
API 生態系統會遭受來自外部和內部用戶端的各種攻擊。提供和使用 API 可為服務供應商帶來大量商機，但也帶來一些安全性風險。開發人員必須瞭解這些挑戰，並在建立及使用 API 時解決這些問題。
OWASP 是一個開放社群，專門協助機構開發、購買及維護可信任的應用程式和 API。透過 OWASP API 安全性專案，OWASP 會發布網頁應用程式和 REST API 最嚴重的安全性風險，並提供相關建議，協助您解決這些風險。
在 Apigee 中，API Proxy 層會在後端系統處理要求前，偵測、封鎖及回報用戶端傳送的格式錯誤 API 要求，藉此降低風險並保護您的服務。格式不正確的要求可能包含任何組成 HTTP 應用程式層級通訊協定的元件：
- 網址
- 標頭
- 路徑
- 酬載
格式不正確的 API 要求可能來自外部開發人員、內部開發人員或惡意機器人開發的已知或不明用戶端。這類要求構成了大多數 OWASP 威脅，但基礎 API Proxy 層還有其他元件可降低風險，例如資料遮罩、記錄、管理等。
只要採用以使用者為導向的設計方式，並將 API 連結至後端系統，Apigee 的智慧型 API 管理平台就能協助您解決 OWASP API 安全性漏洞，讓您能順利解決這些問題。以下列出 Apigee 針對主要的 REST OWASP 威脅建議的政策/設定。
Apigee 解決方案可防範 2017 年 OWASP 十大資安風險
建構及保護網頁應用程式時，會涉及許多安全性問題。OWASP 發布了網頁應用程式的2017 年 OWASP 十大安全威脅清單。雖然網路應用程式包含許多部分，但大多數的現代網路應用程式都嚴重依賴 REST API。Apigee 並非用於處理網頁應用程式的所有安全性需求，但可在保護 REST API 方面發揮關鍵作用。以下是 OWASP 的主要安全威脅，並說明如何使用 Apigee 解決這些威脅。
A1:2017 - Injection
為防範 SQL、NoSQL、LDAP 和 JavaScript 等不受信任的資料注入，避免執行不當指令或未經授權存取資料，Apigee 提供多項輸入驗證政策，可驗證用戶端提供的值是否符合預期，再允許進一步處理。Apigee Edge 會充當傳入 API 要求的伺服器，檢查酬載結構是否落在可接受的範圍內，這也稱為限制檢查。您可以設定 API proxy，讓輸入驗證例行程轉換輸入內容，移除危險字元序列，並以安全值取代。
您可以透過下列幾種方式，透過 Apigee 平台驗證輸入內容：
- JSONThreatProtection 會檢查 JSON 酬載是否有威脅。
- XMLThreatProtection 會檢查 XML 酬載是否有威脅。
- 您可以使用 JavaScript 執行參數驗證。
- 您可以使用 JavaScript 執行標頭驗證。
- 您可以使用 RegularExpressionProtection 政策處理 SQLCodeInjection。
驗證內容類型：
- 要求 - 在 Proxy 流程中使用條件邏輯來檢查 Content-Type。請使用 AssignMessage 政策或 RaiseFault 政策，傳回自訂錯誤訊息。
- 回應：在 Proxy 流程中使用條件邏輯來驗證 Content-Type。使用 AssignMessage 政策設定 Content-Type 標頭，或使用 AssignMessage 或 RaiseFault 政策傳回自訂錯誤訊息。
A2:2017 - 驗證和工作階段管理機制有誤
攻擊者可利用應用程式中的實作缺陷，存取密碼、工作階段權杖和金鑰，進而模擬其他使用者。這主要是實作問題，而非產品問題。Apigee 提供 VerifyApiKey、OAuth 和 JSON Web Token (JWT) 政策，有助於防範此漏洞。
API 金鑰驗證
API 金鑰驗證是可為 API 設定的應用程式安全性最簡單的形式。用戶端應用程式只需在要求中提供 API 金鑰，然後 Apigee Edge 會透過附加至 API Proxy 的政策，檢查 API 金鑰是否處於所要求資源的核准狀態。
Apigee 提供 API 金鑰產生和驗證功能。當開發人員建立並核准與一或多個 API 產品相關聯的應用程式時，Apigee 就會產生 API 金鑰和密碼。
「API 金鑰」一詞有時可能有不同的涵義。在 Apigee 中，當應用程式與產品建立關係時，Apigee 會產生用戶端 ID 和用戶端密碼。有些人會將 ID 和密鑰都稱為 API 金鑰。有些人只將用戶端 ID 稱為 API 金鑰。在 Edge UI 中，您會看到「consumer key」和「consumer secret」。
在「VerifyAPIKey」政策中，系統只會驗證用戶端 ID 或「消費者金鑰」。開發人員向 Apigee 註冊應用程式，並將應用程式與 API 產品建立關聯時，就會收到消費者金鑰。開發人員會在應用程式對 API 產品中內含的 API 代理程式發出的呼叫中，加入消費者金鑰。
Apigee 也支援從外部來源匯入現有的 API 金鑰。
對於 OAuth 授權類型，系統會同時使用用戶端 ID 和密碼。
OAuth 2.0
OAuth 2.0 授權架構可讓第三方應用程式取得 HTTP 服務的有限存取權，方法是代表資源擁有者在資源擁有者與 HTTP 服務之間協調核准互動，或是允許第三方應用程式自行取得存取權。
Apigee 的 OAuth 2.0 政策可讓您實作及自訂四種 OAuth 2.0 授權類型。您可以使用 OAuthv2 政策強制執行 OAuth 存取權杖。消費者必須註冊，並擁有已核准的應用程式，才能存取 API。並會收到 API 用戶端 ID 和用戶端密碼。消費者必須透過其中一個 OAuth 授權進行驗證，才能取得不透明的存取權杖。這個權杖可用於控管 API 存取權。
JWT
JSON Web Token (JWT) 通常用於在已連結的應用程式之間共用宣告或斷言。Apigee 提供 JWT 支援，使用三種政策。
- GenerateJWT 權杖 (支援 HS256 和 RS256 簽名)
- ValidateJWT 符記
- 在不驗證的情況下解碼 JWT 權杖
A3:2017 - Sensitive Data Exposure
攻擊者會鎖定信用卡詳細資料、身分證字號、登入憑證、個人識別資訊 (PII) 和稅務身分證號等機密資料，用於盜用身分、竊取金錢、詐欺和其他犯罪行為。Web 應用程式需要實作靜態資料和傳輸中資料的加密機制，以及其他策略，確保機密資料的安全。
TLS (傳輸層安全標準，前身為 SSL) 是標準安全技術，可在網頁伺服器和網頁用戶端 (例如瀏覽器或應用程式) 之間建立加密連結。Apigee 支援單向和雙向 TLS。
透過使用虛擬主機設定，系統可支援北向 TLS (用戶端連線至充當伺服器的 API)。虛擬主機可設定為單向或雙向 TLS。
透過使用目標伺服器設定，可支援南向 TLS (Apigee 做為連線至後端服務的用戶端)。您可以為目標伺服器設定單向或雙向 TLS。
Apigee 支援許多 TLS 設定選項。
雙向 TLS 強制執行可確保用戶端使用已在 Apigee 上完成註冊的憑證。OWASP 也提供 TLS 最佳做法。
在 Apigee hybrid 中，TLS 可透過主機別名在輸入端使用，這與虛擬主機的概念類似。
以下是保護機密資料的規範：
- 使用支援單向和雙向 TLS 的平台，可在通訊協定層級提供防護。
- 請使用AssignMessage 政策和 JavaScript 政策等政策，在機密資料傳回用戶端前將其移除。
- 請使用標準 OAuth 技術，並考慮加入 HMAC、雜湊、狀態、Nonce、PKCE 或其他技術，提升每個要求的驗證層級。
- 使用資料遮蓋設定，在 Edge Trace 工具中遮蓋機密資料。
- 請小心在快取中儲存任何機密資料 (或加密儲存在快取中的機密資料)。在 Edge 中，您可以加密鍵/值對應中的靜態機密資料。
A4:2017 - XML 外部實體
處理 XML 的系統或應用程式需要處理 XML 中的「外部實體參照」(external entity references)，也就是在 XML 處理期間，會以實際資料取代檔案或資料的參照。如果應用程式或 XML 處理工具過舊，或是實作不佳，攻擊者就能駭入資料，並利用這些資料竊取資訊，或是對系統發動各種攻擊，例如拒絕服務攻擊。
Apigee 的ExtractVariables 政策可讓您從要求或回應中擷取內容，並將該內容指派給變數。您可以擷取訊息的任何部分，包括標頭、URI 路徑、JSON/XML 酬載、表單參數和查詢參數。這項政策會將文字模式套用至郵件內容，並在找到相符項目時，將變數設為指定的郵件內容。
Apigee 平台內建 XML 剖析器，可使用 XPath 擷取資料。此外，它還有 XMLThreatProtection 政策，可防範惡意 XML 酬載。
A5:2017 - 存取權控管機制有誤
使用者登入並取得系統存取權後，就必須設立適當的授權控管機制，讓使用者只能查看及執行允許的作業。如果沒有嚴格的存取控制機制，攻擊者可能會查看未經授權的資料 (通常是敏感資料)，或惡意操控資料和系統行為。
Apigee 支援分層導入存取權控管機制的做法，可防止不肖人士未經授權變更或存取系統。
Edge UI 的存取權控管
- 請使用貴公司的識別資訊提供者設定單一登入機制。
- 設定角色式存取權控管 (RBAC)，只允許使用者存取所需的功能和設定。
- 小組功能提供額外功能，可限制對 Proxy、產品和應用程式的存取權。
- 設定資料遮蓋功能，隱藏使用者不應看見的機密資料。
- 建立加密的鍵/值對應，用於儲存敏感的鍵/值組合，這些組合會在 Edge UI 和管理 API 呼叫中顯示為遮罩。
Apigee 開發人員入口網站的存取權控管
- 請使用貴公司的識別資訊提供者設定單一登入機制。
- 設定角色型存取權控管 (RBAC)，只允許使用者存取 Drupal 開發人員入口網站中所需的功能和設定。
- 設定開發人員入口網站，根據使用者角色顯示特定 API 產品。
- 設定入口網站，根據使用者角色顯示或隱藏內容。
Apigee 執行階段 API 存取權的存取權控管
- 您可以透過 API 金鑰、OAuth 權杖、OAuth 範圍、憑證和其他技術，強制執行 API 存取權。
- API 供應商會定義 API 產品，藉此設定可用的資源。您可以透過使用者介面、管理 API 或開發人員入口網站手動授予存取權。開發人員的應用程式獲得 API 產品存取權後，就會收到用於驗證程序的用戶端 ID 和密鑰。
- Apigee 可與任何身分提供者整合，執行 OAuth。
- Apigee 可產生 JWT 權杖或其他技術，將使用者身分傳送至目標服務。目標服務可使用該身分，視需要限制服務和資料的存取權。
A6:2017-安全性設定錯誤
安全性設定錯誤很容易被忽略，因為管理員和開發人員常常會誤以為自己使用的系統天生安全。安全性設定錯誤可能會發生在許多不同的情況下，例如信任預設設定或部分設定可能不安全、錯誤訊息包含敏感詳細資料、未使用適當的安全性控管機制在雲端儲存資料、HTTP 標頭設定錯誤等等。Apigee 平台提供多種機制，可讓您控制、管理及監控安全性設定，包括 可重複使用的共用流程。
共用流程可讓 API 開發人員將政策和資源組合成可重複使用的群組。共用流程可擷取可重複使用的功能，有助於確保一致性、縮短開發時間，並更輕鬆地管理程式碼。您可以在個別 API Proxy 中加入共用流程，也可以更進一步將共用流程放入流程掛鉤，為在相同環境中部署的每個 API Proxy 自動執行共用流程邏輯。
Apigee 產品版本可確保防範含有安全漏洞的程式庫。如果發現新的安全漏洞，Apigee 可能會發布其他修補程式或更新。Edge 公有雲會自動修補。Edge for Private Cloud (內部部署) 客戶必須自行套用產品修補程式。
A7：2017-跨網站指令碼攻擊 (XSS)
跨網站指令碼攻擊 (XSS) 會讓攻擊者在使用者的網頁瀏覽器中執行指令碼，藉此控制使用者工作階段、操控網站，或以其他方式惡意影響使用者。XSS 問題不一定與 API 相關，但 Apigee 提供的威脅防護政策可用於防範 API 中的 XSS。使用規則運算式，搭配 RegularExpressionProtection 政策或 JavaScript 政策，檢查 JavaScript 和其他注入類型攻擊的酬載和參數值。
CORS 是針對所有瀏覽器強制執行的同源政策所實作的常見解決方案之一，您可以使用AssignMessage 政策實作。
A8:2017 - 不安全的反序列化
攻擊者可以利用序列化缺陷進行不同類型的攻擊，例如重播、權限提升和注入。不安全的反序列化功能也可能會啟用遠端程式碼執行功能。
Apigee 不建議您進行反序列化。不過，JSONThreatProtection 政策和 RegularExpressionProtection 政策可協助防範惡意 JSON 酬載。JavaScript 政策也可用於掃描酬載是否含有惡意內容。快取和其他政策可用於防範重播攻擊。在基礎架構層級，Apigee 平台也內建了防護機制，可保護執行中的程序。
A9:2017 - 使用已知安全漏洞的元件
由於架構、程式庫和模組會以完整執行權限和 CRUD 存取權執行，攻擊者可以利用元件漏洞來攻擊系統。
Apigee 定期發布產品，確保能防範元件漏洞，尤其是在發現特定漏洞時。Apigee 公有雲會自動套用修補程式，而 Apigee 會在內部部署環境可安裝修補程式時通知 Edge for Private Cloud 客戶。
A10:2017 - 記錄與監控功能不足
如果您未在系統中妥善執行記錄、監控和事件管理作業，攻擊者就能對資料和軟體進行更深入、更持久的攻擊。
Apigee 提供多種方式執行記錄、監控、錯誤處理和稽核記錄。
記錄
- 您可以使用訊息記錄政策，將記錄訊息傳送至 Splunk 或其他 syslog 端點。
- 您可以透過 Analytics API 擷取 API 分析資料，然後匯入或匯出至其他系統。
- 在 Private Cloud 專用 Edge 中，您可以使用「MessageLogging」政策寫入本機記錄檔。您也可以查看每個執行中元件的記錄檔案。
- JavaScript 政策可用於同步或非同步傳送記錄訊息至 REST 記錄端點。
監控
- 請使用 API 監控 UI 或 API，定期監控 API 和後端，並觸發 alet。
- 使用健康監測功能定期監控目標伺服器後端。
- Apigee 提供監控 Edge for Private Cloud 的建議。
- Apigee 也提供 最佳做法，可供團隊用於監控 API 計畫。
處理錯誤
Apigee 為 API Proxy 提供強大且多功能的錯誤處理機制。與 Java 程式擷取例外狀況的方式類似，API Proxy 可以擷取錯誤，並決定如何向用戶端傳回適當的回應。Apigee 的自訂錯誤處理機制可讓您新增功能，例如在發生錯誤時記錄訊息。
稽核記錄
Apigee 平台會保留稽核記錄，追蹤 API Proxy、產品和機構記錄的變更。您可以透過使用者介面或Audits API取得這份記錄。
Apigee 解決方案可因應 2013 年 OWASP 安全漏洞
OWASP 更新 2017 年清單時，2013 年清單中的部分漏洞並未列入。這些漏洞仍是有效的威脅。以下各節將說明如何使用 Apigee 處理這些威脅。
A8:2013 - 跨網站偽造要求 (CSRF)
跨網站偽造要求可讓攻擊者透過 HTTP 將使用者的驗證詳細資料、工作階段 Cookie 和其他資料轉送至有安全漏洞的網路應用程式，讓網路應用程式誤以為這些要求是來自使用者的合法要求。
指南：
- 這比較像是瀏覽器問題，而非 API 產品問題。您可以使用 OpenID Connect、OAuth 和其他技術來解決這個安全漏洞。
- 建議您使用 HMAC、狀態、雜湊、Nonce 或 PKCE 技術，以防偽造和重播攻擊。
A10:2013 - 未經驗證的重新導向和轉送
如果網頁應用程式執行重新導向，但未驗證重新導向是否會將使用者導向至信任的網站，攻擊者就能將使用者導向至惡意目的地，執行網路釣魚、惡意軟體執行和其他攻擊。
指南：
- 使用 OAuth，並在每次要求時強制執行驗證。
- 在 API 代理邏輯中檢查回應代碼並適當處理重新導向，以防發生非預期的 302 重新導向。