您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info
總覽
API 生態系統會遭受來自外部和內部用戶端的各種攻擊。 提供及使用 API 為服務供應商帶來龐大商機，但也造成一些安全風險。開發人員必須瞭解這些挑戰，並在建立及使用 API 時解決這些問題。
OWASP 是一個開放社群，致力於協助機構開發、購買及維護可信賴的應用程式和 API。OWASP 透過 OWASP API Security 計畫，發布網頁應用程式和 REST API 最嚴重的安全風險，並提供解決這些風險的建議。
透過 Apigee，API Proxy 層可以在後端系統處理要求之前，偵測、封鎖及回報來自用戶端的格式錯誤 API 要求，進而降低風險並保護服務。要求格式錯誤可能包括組成 HTTP 應用程式層級通訊協定的任何元件：
- 網址
- 標頭
- 路徑
- 酬載
格式錯誤的 API 要求可能來自外部開發人員、內部開發人員或惡意機器人開發的已知或未知用戶端。這類要求占 OWASP 威脅的大宗，但基礎 API Proxy 層還有其他元件可降低風險，例如資料遮蓋、記錄、管理等。
Apigee 的智慧 API 管理平台可讓您在設計 API 並將其連線至後端系統時，以消費為導向，輕鬆解決 OWASP API 安全性重大漏洞。以下列出 Apigee 建議的政策/設定，可防範 REST OWASP 威脅。
適用於 2017 年 OWASP 前 10 大風險的 Apigee 解決方案
建構及保護網頁應用程式時，會遇到許多安全疑慮。 OWASP 發布了網頁應用程式的 2017 年前 10 大 OWASP 安全威脅清單。雖然網頁應用程式包含許多部分，但大多數現代網頁應用程式都非常依賴 REST API。Apigee 並非用來處理網頁應用程式的所有安全需求，但可協助保護 REST API，扮演關鍵角色。以下是 OWASP 前幾名的安全威脅，以及如何使用 Apigee 解決這些威脅的說明。
A1:2017 - 注入
為防範 SQL、NoSQL、LDAP 和 JavaScript 等不受信任的資料注入，避免執行非預期指令或未經授權存取資料，Apigee 提供多項輸入驗證政策，可驗證用戶端提供的值是否符合預期，再允許後續處理。Apigee Edge 會做為傳入 API 要求的伺服器，檢查酬載結構是否在可接受的範圍內，這也稱為限制檢查。您可以設定 API Proxy，讓輸入驗證常式轉換輸入內容，移除有風險的字元序列，並替換為安全值。
您可以使用 Apigee 平台，透過下列幾種方式驗證輸入內容：
- JSONThreatProtection 檢查 JSON 酬載是否有威脅。
- XMLThreatProtection 檢查 XML 酬載是否有威脅。
- 您可以使用 JavaScript 驗證參數。
- 您可以使用 JavaScript 執行標頭驗證。
- 您可以使用規則運算式防護政策處理 SQLCodeInjection。
驗證內容類型：
- 要求 - 在 Proxy 流程中使用條件式邏輯檢查 Content-Type。使用 AssignMessage 政策或 RaiseFault 政策傳回自訂錯誤訊息。
- 回應 - 在 Proxy 流程中使用條件邏輯驗證 Content-Type。使用 AssignMessage 政策設定 Content-Type 標頭，或使用 AssignMessage 或 RaiseFault 政策傳回自訂錯誤訊息。
A2:2017 - Broken Authentication and Session Management
攻擊者可利用應用程式中的實作缺陷，存取密碼、工作階段權杖和金鑰，藉此模擬其他使用者。這是實作問題，而非產品問題。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 中，您會看到「用戶端金鑰」和「用戶端密鑰」。
在 VerifyAPIKey 政策中，系統只會驗證用戶端 ID 或「消費者金鑰」。開發人員向 Apigee 註冊應用程式，並將應用程式與 API 產品建立關聯時，會收到用戶端金鑰。開發人員會在應用程式對 API 產品中綁定的 API Proxy 發出的呼叫中，加入用戶端金鑰。
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 支援。
- 產生 JWT 權杖 (支援 HS256 和 RS256 簽章)
- 驗證 JWT 權杖
- 解碼 JWT 權杖，但不驗證
A3:2017 - 敏感資料暴露
攻擊者會鎖定信用卡詳細資料、身分證字號、登入憑證、個人識別資訊 (PII) 和稅號等敏感資料，以進行身分盜用、竊取金錢、詐欺和其他犯罪行為。網頁應用程式必須實作靜態和傳輸中資料的加密機制，以及其他策略，確保機密資料受到保護。
TLS (傳輸層安全標準，前身為 SSL) 是標準安全技術，用於在網路伺服器和網頁用戶端 (例如瀏覽器或應用程式) 之間建立已加密連結。Apigee 支援單向和雙向 TLS。
透過使用虛擬主機設定，即可支援北向 TLS (用戶端連線至做為伺服器的 API)。虛擬主機可設定為單向或雙向 TLS。
透過使用 Target Server 設定，即可支援南向 TLS (Apigee 做為連線至後端服務的用戶端)。目標伺服器可設定為單向或雙向 TLS。
Apigee 支援多種 TLS 設定選項。
強制執行雙向 TLS 可確保用戶端使用已加入 Apigee 的憑證。OWASP 也提供 TLS 最佳做法。
在 Apigee Hybrid 中，TLS 可透過主機別名在 Ingress 中使用，這與虛擬主機的概念類似。
以下是保護機密資料的指南：
- 使用支援單向和雙向 TLS 的平台，在通訊協定層級提供防護。
- 使用 AssignMessage 政策和 JavaScript 政策等政策，在將機密資料傳回用戶端前移除這些資料。
- 使用標準 OAuth 技術，並考慮加入 HMAC、雜湊、狀態、隨機數、PKCE 或其他技術，提高每個要求的驗證等級。
- 使用資料遮蓋設定，遮蓋 Edge Trace 工具中的機密資料。
- 請小心不要將任何機密資料儲存在快取中 (或加密儲存在快取中的機密資料)。在 Edge 中，您可以加密鍵/值對應中的靜態機密資料。
A4:2017 - XML 外部實體
處理 XML 的系統或應用程式必須處理 XML 中的「外部實體參照」，也就是在 XML 處理期間，參照會替換為實際資料的檔案或資料。如果應用程式或 XML 處理器老舊或實作不當，攻擊者就能駭入資料，並用來竊取資訊或對系統發動各種攻擊，例如阻斷攻擊。
Apigee 的 ExtractVariables 政策可讓您從要求或回應中擷取內容，並將該內容指派給變數。您可以擷取訊息的任何部分，包括標頭、URI 路徑、JSON/XML 酬載、表單參數和查詢參數。這項政策會將文字模式套用至郵件內容，並在找到相符內容時，設定含有指定郵件內容的變數。
Apigee 平台內建 XML 剖析器，可使用 XPath 擷取資料。此外，Apigee 也提供 XMLThreatProtection 政策，可防範惡意 XML 酬載。
A5:2017 - Broken Access Control
使用者登入並存取系統後，您必須適當控管授權，確保使用者只能查看及執行允許的操作。如果存取控制措施不夠嚴密，攻擊者就能查看未經授權的資料 (通常是機密資料)，或惡意操縱資料和系統行為。
Apigee 支援分層方法，可實作存取權控管機制，防止惡意人士未經授權變更或存取系統。
Edge UI 的存取權控管
- 使用貴公司的識別資訊提供者設定單一登入。
- 設定角色式存取控管 (RBAC)，只允許使用者存取所需的功能和設定。
- 團隊功能提供額外功能，可限制存取 Proxy、產品和應用程式的權限。
- 設定資料遮蓋，向使用者隱藏私密/機密資料。
- 建立加密的鍵/值對應，儲存敏感的鍵/值組合，這些組合會在 Edge 使用者介面和管理 API 呼叫中顯示為遮蓋。
Apigee 開發人員入口網站的存取權控管
- 使用貴公司的識別資訊提供者設定單一登入。
- 設定角色型存取權控管 (RBAC)，只允許使用者在以 Drupal 為基礎的開發人員入口網站上，存取所需的功能和設定。
- 設定開發人員入口網站，根據使用者角色顯示特定 API 產品。
- 設定入口網站，根據使用者角色顯示或隱藏內容。
Apigee 執行階段 API 存取權控管
- 您可以透過 API 金鑰、OAuth 權杖、OAuth 範圍、憑證和其他技術，強制執行 API 存取權。
- API 供應商會定義 API 產品，藉此設定可用的資源。您可以透過使用者介面手動授予存取權、透過管理 API 授予存取權，或透過開發人員入口網站授予存取權。開發人員的應用程式獲得 API 產品的存取權後，會收到用於驗證程序的用戶端 ID 和密鑰。
- Apigee 可與任何身分識別提供者整合，執行 OAuth。
- Apigee 可以產生 JWT 權杖或其他技術，將使用者身分傳送至目標服務。 目標服務可視需要使用該身分，限制服務和資料的存取權。
A6:2017-Security Misconfiguration
安全設定錯誤很容易遭到忽略，通常是因為管理員和開發人員誤以為自己使用的系統本質上就是安全的。安全設定錯誤可能以多種方式發生，例如信任預設設定或進行可能不安全的局部設定、讓錯誤訊息包含敏感詳細資料、在雲端儲存資料時未採取適當的安全控管措施，以及錯誤設定 HTTP 標頭等。Apigee 平台提供多種機制，可供您控管、管理及監控安全設定，包括 可重複使用的共用流程。
API 開發人員可透過共用流程，將政策和資源組合成可重複使用的群組。 共用流程可將可重複使用的功能集中在一處，有助於確保一致性、縮短開發時間，以及更輕鬆地管理程式碼。您可以在個別 API Proxy 中加入共用流程，也可以進一步將共用流程放在流程掛鉤中，針對部署在與共用流程相同環境中的每個 API Proxy，自動執行共用流程邏輯。
Apigee 產品發布版本可確保防範含有安全漏洞的程式庫。如果發現新的安全漏洞，Apigee 可能會發布額外的修補程式或更新。 邊緣公有雲會自動修補。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 提供多種方式來執行記錄、監控、錯誤處理和稽核記錄。
記錄
- 您可以使用 MessageLogging 政策，將記錄訊息傳送至 Splunk 或其他系統記錄端點。
- 您可以透過Analytics API 擷取 API 數據分析資料，並匯入或匯出至其他系統。
- 在 Edge for Private Cloud 中，您可以使用 MessageLogging 政策寫入本機記錄檔。 您也可以查看各執行中元件的記錄檔。
- JavaScript 政策可用於以同步或非同步方式，將記錄訊息傳送至 REST 記錄端點。
監控
- 使用 API Monitoring 使用者介面或 API 定期監控 API 和後端，並觸發警報。
- 使用健康狀態監控功能，定期監控目標伺服器後端。
- 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、狀態、雜湊、隨機數或 PKCE 技術，防止偽造和重送攻擊。
A10:2013 - 未經驗證的重新導向和轉送
如果網頁應用程式會執行重新導向，但不會驗證重新導向是否將使用者傳送至可信任的預期網站，攻擊者就能將使用者傳送至惡意目的地，以執行網路釣魚、惡意軟體執行和其他攻擊。
使用原則：
- 使用 OAuth，並在每個要求中強制執行驗證。
- 在 API Proxy 邏輯中檢查回應代碼，並適當處理重新導向，避免發生非預期的 302 重新導向。