您正在查看 Apigee Edge 說明文件。
參閱 Apigee X 說明文件。 資訊
總覽
API 生態系統會有來自外部和內部用戶端的各種攻擊。 提供及使用 API 可為服務供應商帶來巨大的機會，但也構成部分安全性風險。開發人員在建立及使用 API 時，必須瞭解這些挑戰，並設法解決。
OWASP 是一個開放式社群，旨在協助機構開發、購買及維護可信任的應用程式和 API。OWASP 透過 OWASP API Security 專案會將最嚴重的安全性風險發布到網頁應用程式和 REST API，並提供解決這些風險的建議。
有了 Apigee，API Proxy 層就能在後端系統處理要求前，偵測、封鎖及回報來自用戶端的格式錯誤 API 要求，進而降低風險並保護您的服務。格式錯誤的要求可包含構成 HTTP 應用程式層級通訊協定的任何元件：
- 網址
- 標頭
- 路徑
- 酬載
格式錯誤的 API 要求可能來自外部開發人員、內部開發人員或惡意機器人開發的已知或未知的用戶端。這類要求佔大部分 OWASP 威脅，但基礎 API Proxy 層還有其他元件，可降低資料遮蓋、記錄、管理等風險。
透過 Apigee 的智慧型 API 管理平台，您可以順暢處理最主要的 OWASP API 安全漏洞，藉此在設計 API 並連結後端系統時順利處理最主要的 OWASP API 安全漏洞。以下列出 Apigee 針對前 REST OWASP 威脅的建議政策/設定。
2017 年 OWASP 前 10 大企業適用的 Apigee 解決方案
在建構及保護網頁應用程式時，有很多安全疑慮。OWASP 發布了網頁應用程式的 2017 大 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 驗證標頭。
- 您可以使用 RegularExpressionProtection 政策處理 SQLCodeInjection。
驗證內容類型：
- 要求 - 使用 Proxy 流程中的條件邏輯檢查 Content-Type。使用 AssignMessage 政策或 engageFault 政策傳回自訂錯誤訊息。
- 回應：使用 Proxy 流程中的條件邏輯驗證 Content-Type。請使用 AssignMessage 政策設定 Content-Type 標頭，或是使用 AssignMessage 或 GoFault 政策傳回自訂錯誤訊息。
A2:2017 - 驗證和工作階段管理損壞
攻擊者可以存取密碼、工作階段符記和金鑰，利用應用程式中的實作瑕疵來冒用其他使用者。這不僅僅是實作問題，而非產品問題。Apigee 提供 VerificationApiKey、OAuth 和 JSON Web Token (JWT) 政策，有助於防範這個安全漏洞。
API 金鑰驗證
API 金鑰驗證是最簡單的應用程式型安全性方式，可針對 API 進行設定。用戶端應用程式只要根據其要求顯示 API 金鑰，然後透過附加至 API Proxy 的政策顯示 Apigee Edge，就能檢查該 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)。
系統會透過使用目標伺服器設定，支援南界 TLS (做為連線至後端服務的用戶端)。目標伺服器可為單向或雙向傳輸層安全標準 (TLS)。
Apigee 支援許多傳輸層安全標準 (TLS) 設定選項。
強制執行雙向傳輸層安全標準，可確保用戶端使用已在 Apigee 上加入的憑證。OWASP 也提供 TLS 最佳做法。
在 Apigee Hybrid 中，您可以透過主機別名使用 TLS，這與虛擬主機的概念類似。
以下為保護機密資料的準則：
- 使用支援單向與雙向傳輸層安全標準 (TLS) 的平台，該平台在通訊協定層級受到保護。
- 您可以使用 AssignMessage 政策和 JavaScript 政策等政策，在機密資料傳回用戶端前移除。
- 請使用標準 OAuth 技巧，並考慮加入 HMAC、雜湊、狀態、 Nonce、PKCE 或其他技術，改善各項要求的驗證層級。
- 使用資料遮罩設定來遮蓋 Edge Trace 工具中的機密資料。
- 在快取中儲存任何機密資料 (或為儲存在快取中的機密資料加密)，請特別留意。在 Edge 中，您可以使用鍵/值對應中的靜態機密資料加密。
A4:2017 - XML 外部實體
處理 XML 的系統或應用程式需要處理 XML 中的「外部實體參照」，也就是在 XML 處理期間以實際資料取代的檔案或資料參照。如果應用程式或 XML 處理器過舊或實作不當，攻擊者可能會入侵資料，藉此竊取資訊或在系統中發動各種攻擊，例如阻斷服務。
Apigee 的擷取變數政策可讓您擷取要求或回應中的內容，並將該項內容指派給變數。您可以擷取訊息的任何部分，包括標頭、URI 路徑、JSON/XML 酬載、表單參數和查詢參數。這項政策的運作方式是將文字模式套用至訊息內容，並在尋找相符項目時，為指定的訊息內容設定變數。
Apigee 平台中的內建 XML 剖析器會使用 XPath 擷取資料。這項政策也具有 XMLThreatProtection 政策，可防範惡意的 XML 酬載。
A5:2017 - 存取控制損壞
在使用者登入並取得系統存取權後，您需要設置適當的授權控管機制，讓使用者只能查看自己能夠執行的操作，並執行這些操作。如果沒有高強度的存取權控管，攻擊者可以查看未經授權和經常存在機密資料，或惡意操縱資料和系統行為。
Apigee 支援以分層方式實施存取權控管，防範惡意行為人在未經授權的情況下變更或存取系統。
Edge UI 的存取權控管
- 透過貴公司的識別資訊提供者設定單一登入。
- 設定角色型存取權控管 (RBAC) 功能，僅允許使用者存取所需的功能和設定。
- Teams 功能提供額外功能，可限制 Proxy、產品和應用程式的存取權。
- 設定資料遮蓋功能，隱藏使用者的機密資料。
- 建立加密的鍵/值組合以儲存敏感的鍵/值組合，這些鍵/值組合會顯示在 Edge UI 和 Management API 呼叫中。
Apigee 開發人員入口網站的存取權控管
- 透過貴公司的識別資訊提供者設定單一登入。
- 設定角色型存取權控管 (RBAC)，規定使用者只能透過 Drupal 開發人員入口網站存取所需的功能和設定。
- 設定開發人員入口網站，根據使用者角色顯示特定 API 產品。
- 設定入口網站，根據使用者角色顯示或隱藏內容。
Apigee 執行階段 API 存取權的存取權控管
- 您可以透過 API 金鑰、OAuth 權杖、OAuth 範圍、憑證和其他技術，強制執行 API 存取權。
- API 供應商會定義 API 產品來設定可用資源。系統會在 UI 中、透過 Management API 或開發人員入口網站手動授予存取權。當開發人員的應用程式獲得 API 產品的存取權時，就會收到驗證程序中使用的用戶端 ID 和密鑰。
- Apigee 可與任何識別資訊提供者整合，以便執行 OAuth。
- Apigee 可產生 JWT 權杖或其他技術，將使用者身分傳送至目標服務。目標服務可以視需要使用該身分限制服務和資料的存取權。
A6:2017- 安全性設定錯誤
安全性設定錯誤很容易遭到忽略，因為管理員和開發人員誤會認為自己使用的系統本來就安全無虞。安全性設定可能有多種不同情況，例如信任預設設定或做出不安全的部分設定、導致錯誤訊息含有機密詳細資料、在沒有適當安全控管機制的情況下將資料儲存在雲端、缺少設定 HTTP 標頭等。Apigee 平台提供多種機制，可讓您控管、管理及監控安全性設定，包括 可重複使用的共用流程。
API 開發人員可透過共用流程，將政策和資源合併到可重複使用的群組。 共用流程會集中擷取可重複使用的功能，協助您確保一致性、縮短開發時間，以及更輕鬆地管理程式碼。您可以在個別 API Proxy 中加入共用流程，也可以進一步將共用流程放入流程掛鉤，針對部署於相同環境且做為共用流程中的每個 API Proxy，自動執行共用流程邏輯。
Apigee 產品發布版本可確保資料庫受到安全漏洞的保護。在發現新的安全漏洞時，Apigee 可能會發布其他修補程式或更新。邊緣公用雲端會自動修補。適用於私有雲 (地端部署) 客戶的邊緣必須自行套用產品修補程式。
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 也會向 Private Cloud 客戶通知 Edge。
A10:2017 - 記錄與監控不足
如果沒有在系統中適當執行記錄、監控及事件管理，攻擊者就能對資料與軟體執行更深入且長時間的攻擊。
Apigee 提供多種執行記錄、監控、錯誤處理和稽核記錄的方式。
記錄
- 你可以使用 MessageLogging 政策將記錄訊息傳送至 Splunk 或其他 Syslog 端點。
- API 數據分析資料可透過 Analytics (分析) API 提取，並匯入或匯出至其他系統。
- 在 Edge for Private Cloud 中，您可以使用 MessageLogging 政策寫入本機記錄檔。 系統也提供每個執行中元件的記錄檔。
- JavaScript 政策能以同步或非同步的方式，將記錄訊息傳送到 REST 記錄端點。
Monitoring
- 使用 API Monitoring UI 或 API 定期監控 API 與後端，並觸發小程式。
- 使用健康狀態監控功能定期監控目標伺服器後端。
- Apigee 會提供監控 Private Cloud Edge 的建議。
- Apigee 也提供 最佳做法，讓您的團隊用於監控您的 API 計畫。
處理錯誤
Apigee 為 API Proxy 提供功能強大且用途廣泛的錯誤處理機制。與 Java 程式擷取例外狀況的方式類似，API Proxy 可以擷取錯誤，並判斷如何向用戶端傳回適當的回應。Apigee 的自訂錯誤處理功能可讓您新增功能，例如在發生錯誤時記錄訊息記錄。
稽核記錄
Apigee 平台會保留稽核記錄，追蹤 API Proxy、產品和機構記錄的變更。如要取得這項記錄，請透過 UI 或 Audits API 取得。
2013 年 OWASP 安全漏洞的 Apigee 解決方案
OWASP 在 2017 年更新清單時，遺漏 2013 年清單中的某些漏洞，它們仍然有效。以下各節說明如何使用 Apigee 處理這些威脅。
A8:2013 - 跨網站偽造要求 (CSRF)
跨網站偽造要求可讓攻擊者將使用者的驗證詳細資料、工作階段 Cookie 和其他資料，透過 HTTP 轉送至易受攻擊的網頁應用程式，讓網頁應用程式誤信這些要求都是使用者提出的合法要求。
規範：
- 而是瀏覽器問題，而非 API 產品問題。您可以善用 OpenID Connect、OAuth 和其他技術來解決這個安全漏洞。
- 考慮使用 HMAC、狀態、雜湊、Nonce 或 PKCE 技術，防範偽造和重播攻擊。
A10:2013 - 未驗證的重新導向與轉寄
如果網頁應用程式執行重新導向，但並未確認重新導向會將使用者帶往受信任的網站，攻擊者可能會將使用者帶往惡意目的地，藉此進行網路釣魚、惡意軟體執行和其他攻擊。
規範：
- 請使用 OAuth 並在每次要求時強制執行驗證。
- 檢查 API Proxy 邏輯中的回應代碼，並適當處理重新導向，預防非預期的 302 重新導向。