透過 Azure 本機服務使用 Azure OpenAI 服務的智慧型應用程式提供無縫的使用者驗證和授權。 但有些場景比較複雜，需要不同的架構設計。 這些方案包括具有未託管在 Azure 上的用戶端應用程式、使用外部身分識別提供者以及部署存取相同 Azure OpenAI 執行個體的多個用戶端的拓撲。 在這些場景中，在 Azure OpenAI 前面引入閘道可以透過新增一個確保對已部署執行個體進行一致身份驗證的層來顯著提高安全性。
本文介紹了向 Azure OpenAI 提供驗證的關鍵場景：
每個場景都描述了它們帶來的挑戰以及合併閘道的好處。
重要
您可以針對任何閘道實作使用下列指引，包括 Azure API 管理。 為了說明這種靈活性，架構圖在大多數場景中使用元件的通用表示。
透過外部身分提供者對用戶端應用程式進行身份驗證
下載此架構的 Visio 檔案。
場景限制
此場景有以下限制：
用戶端應用程式使用支援 OpenID Connect (OIDC) 的外部身分提供者，例如 Okta、Auth0 或社交身分提供者。
用戶端應用程式針對與 Azure OpenAI 資料平面租用戶不同的 Microsoft Entra 租用戶進行身份驗證。
這些約束可以應用於以下範例：
已針對外部 OIDC 提供者或 Microsoft Entra ID 進行驗證並與 Azure OpenAI 執行個體整合的現有用戶端應用程式。
必須一致地驗證來自多個識別提供者之使用者的用戶端應用程式。
直接連接到 Azure OpenAI
如果這些場景中的用戶端應用程式直接連接到 Azure OpenAI 而不使用閘道，則它們必須使用基於金鑰的驗證來向 Azure OpenAI 進行驗證。 基於金鑰的身份驗證引入了額外的安全性問題。 您必須安全地儲存和輪換金鑰，並且不能為各個模型部署提供不同的用戶端基於角色的存取控制 (RBAC) 設定。
引入閘道
下載此架構的 Visio 檔案。
閘道透過以下方式解決了這種情況的挑戰：
閘道使用開放授權 (OAuth) 透過現有的外部身分提供者對使用者進行身份驗證。 閘道驗證身分提供者產生的經過驗證的使用者存取權權杖，例如 JSON Web 權杖 (JWT)。 然後，閘道會向支援的 Azure OpenAI 執行個體授予授權。
您不需要管理用戶端金鑰。 這種方法消除了基於金鑰的身份驗證的安全風險。
閘道使用託管識別碼連接到 Azure OpenAI，透過最低權限的 Azure RBAC 提高安全性。
針對此場景的建議
將更多 OAuth 範圍新增至身分識別提供者中的應用程式註冊中，以便為消費者提供更精細的權限。 這些範圍使用戶端應用程式能夠請求在閘道中執行特定操作的權限，包括存取 Azure OpenAI。
使用入站原則設定此場景以進行 API 管理。 使用
validate-jwt原則強制支援的 JWT 的存在性、有效性和屬性值。
在這種情況下避免使用閘道的原因
如果單一智慧型應用程式存取Azure OpenAI，則在應用程式內設定使用者身份驗證和授權比透過閘道更容易。 使用此方法指派必要的 Azure RBAC，以便使用 Azure OpenAI 對智慧型應用程式進行安全性驗證。
透過憑證對用戶端應用程式進行身份驗證
下載此架構的 Visio 檔案。
場景限制
此場景有以下限制：
您想要使用憑證來驗證用戶端應用程式。
用戶端應用程式不能使用，或者您不想使用 Microsoft Entra ID 或其他 OIDC 提供者進行身份驗證。
用戶端不能使用，或者您不想使用聯合身份進行身份驗證。
這些約束可以應用於以下範例：
對 Azure OpenAI 進行驗證的用戶端是機器或裝置，不會發生使用者互動。
由於安全標準和合規性規定，您的組織要求您使用憑證進行身分驗證。
您希望為多個用戶端應用程式提供基於其環境進行身份驗證的選項，包括使用用戶端憑證。
直接連接到 Azure OpenAI
Azure OpenAI 本身不支援用戶端憑證驗證。 為了在沒有閘道的情況下支援這種場景，智慧應用程式需要使用使用者憑證驗證以及 API 金鑰或託管識別來對 Azure OpenAI 執行個體的請求進行身份驗證。 您必須在每個用戶端中實作憑證身分驗證邏輯。 在這種情況下，如果從用戶端直接連接到 Azure OpenAI，基於金鑰的身份驗證會帶來風險和管理開銷。
引入閘道
下載此架構的 Visio 檔案。
您可以在該架構中引入一個閘道，以減輕用戶端的用戶端認證驗證負擔。 閘道驗證智慧型應用程式提供的用戶端數位證書，並檢查頒發者、到期日期、指紋和吊銷清單。 閘道應使用託管識別碼透過 Azure OpenAI 進行自身身份驗證。 閘道也應使用 Azure Key Vault 來儲存根憑證授權單位 (CA)。 使用此方法可以集中用戶端憑證驗證，從而減少維護開銷。
閘道在此場景中提供了多個優勢：
您使用閘道的託管身分而不是存取金鑰，這消除了金鑰被盜的風險並減輕了金鑰輪換的維護負擔。
您可以集中憑證驗證，這可確保您使用一致的安全原則來評估所有智慧型應用程式的用戶端數位憑證。
您可以將憑證驗證卸載到閘道，從而簡化用戶端程式碼。
針對此場景的建議
驗證憑證時，驗證整個憑證鏈，包括根 CA 和中間憑證。 全面驗證確保證書的真實性並防止未經授權的存取。
定期輪調和更新用戶端證書，以最大限度地降低證書外洩的風險。 使用 Key Vault 自動執行此程序並保持憑證最新。 設定即將到期的憑證警報，以防止閘道的服務中斷。
實施相互傳輸層安全性 (mTLS) 以確保用戶端和伺服器相互驗證。 此原則提供了額外的安全層。 若要設定閘道以強制執行 mTLS，請設定適當的原則和約束。
使用 API 管理中的
validate-client-certificate原則驗證 Azure 金鑰保管庫所引用的用戶端憑證。 此原則驗證用戶端應用程式提供的用戶端憑證並檢查頒發者、到期日、指紋和吊銷清單。
在這種情況下避免使用閘道的原因
在用戶端較少的簡單環境中，在用戶端處理安全性和憑證管理的成本可能超過引入閘道所增加的複雜性。 此外，如果您選擇商業解決方案而不是自訂實現，閘道可能會成為單點故障，由於增加的層而增加延遲，並導致供應商鎖定。
在實施用戶端憑證身分驗證閘道之前，您必須仔細評估您的特定需求、資源可用性和應用程式的重要性。
透過金鑰對多個用戶端應用程式進行驗證以存取共用的 Azure OpenAI 執行個體
下載此架構的 Visio 檔案。
場景限制
此場景有以下限制：
- 多個用戶端應用程式存取共用的 Azure OpenAI 執行個體。
- 用戶端不能使用，或者您不想使用 Microsoft Entra ID 進行身份驗證。
- 用戶端不能使用，或者您不想使用聯合身份進行身份驗證。
- 您希望對用戶端應用程式使用基於金鑰的身份驗證。
這些約束可以應用於以下範例：
您可以跨多個環境部署用戶端應用程序，包括 Azure、本機或其他雲端供應商。
組織需要向不同的團隊提供 Azure OpenAI，並為每個團隊設定獨特的存取和使用限制。
直接連接到 Azure OpenAI
Azure OpenAI 支援透過共用金鑰進行基於金鑰的驗證。 Azure OpenAI 公開主鍵和輔助鍵。 輔助金鑰的目的是支援金鑰輪換。 它不提供用戶端身分隔離。 在這種情況下，當您直接向 Azure OpenAI 驗證多個用戶端時，每個用戶端共用相同的金鑰。 此實施面臨以下挑戰：
您無法撤銷特定用戶端的權限，因為每個用戶端共用相同的金鑰。
您無法為不同的用戶端授予對相同 Azure OpenAI 執行個體部署中的不同模型的不同存取權限。
您無法從記錄觀點區分一個用戶端與另一個用戶端。
引入閘道
下載此架構的 Visio 檔案。
您可以在此體系結構中引入一個閘道，該閘道會向每個用戶端應用程式發出專用金鑰。 API 管理使用訂閱的概念來提供專用的用戶端金鑰。 閘道應使用託管識別碼透過 Azure OpenAI 進行自身身份驗證。
閘道在此場景中提供了多個優勢：
您可以撤銷單一用戶端應用程式的存取權限，而不會影響其他用戶端。
在輪換金鑰之前，您不需要更新所有用戶端的金鑰設定，因此金鑰輪換在邏輯上更容易。 更新用戶端設定後，您可以輪換每個用戶端的專用金鑰。
您可以從記錄的角度唯一地識別每個用戶端。
閘道獨立地對每個用戶端實施速率限制和配額。
針對此場景的建議
加強對與 API 請求相關的指標的監控。 當您使用閘道中的託管識別碼時，Azure OpenAI 記錄中使用者和用戶端應用程式的可追蹤性不會提高。 閘道應提供與請求相關的記錄，例如請求用戶端和使用者 ID。
當您透過閘道將多個用戶端應用程式要求路由到共用 Azure OpenAI 執行個體時，請確保閘道會根據用戶端身分做出適當模型部署的路由決策。 有關詳細資訊，請參閱在多個 Azure OpenAI 部署前面使用閘道。
對存取多個 Azure OpenAI 執行個體的用戶端應用程式進行驗證
下載此架構的 Visio 檔案。
場景限制
此場景有以下限制：
- 用戶端應用程式連線到一個或多個區域中的多個 Azure OpenAI 執行個體。
- 用戶端不能使用，或者您不想使用 Microsoft Entra ID 或其他 OIDC 提供者進行驗證。
- 您希望對用戶端應用程式使用基於金鑰的身份驗證。
這些約束可以應用於以下範例：
用戶端應用程式必須在地理上分佈其工作負載，以減少延遲並提高效能。
用戶端應用程式嘗試透過跨多個區域部署執行個體來最佳化其每分鐘權杖配額。
組織需要無縫故障轉移和災難復原功能以確保持續運作。 因此，他們管理雙重部署原則，例如由預先設定吞吐量部署和即用即付部署組成的原則。
用戶端應用程式必須使用僅在某些 Azure 區域可用的特定模型功能。
直接連線到多個 Azure OpenAI 執行個體
當用戶端應用程式直接連接到多個 Azure OpenAI 執行個體時，每個用戶端必須儲存每個執行個體的金鑰。 除了使用金鑰的安全考慮之外，輪換金鑰的管理負擔也增加了。
引入閘道
下載此架構的 Visio 檔案。
當使用閘道處理存取多個 Azure OpenAI 部署的用戶端應用程式時，您將獲得與透過金鑰處理多個用戶端應用程式以存取共用 Azure OpenAI 執行個體的閘道相同的優勢。 您也可以簡化驗證流程，因為您使用單一使用者定義的託管識別碼來對從閘道到多個 Azure OpenAI 執行個體的請求進行驗證。 實施此方法可以減少整體營運開銷，並最大限度地降低使用多個執行個體時用戶端設定錯誤的風險。
針對此場景的建議
實作負載平衡技術，在 Azure OpenAI 的多個執行個體之間分配 API 請求，以處理高流量並確保高可用性。 有關詳細資訊，請參閱在多個 Azure OpenAI 部署或執行個體前面使用閘道。
當您使用多個 Azure OpenAI 執行個體實作多租用戶方案時，關聯閘道處每個租用戶的代幣使用情況。 此方法可確保您追蹤總權杖使用情況，無論要求轉送至哪個後端 Azure OpenAI 執行個體。
一般建議
透過閘道整合 Azure OpenAI 時，需要考慮一些適用於所有場景的跨領域建議。
使用 API 管理而不是建立自己的解決方案，以實現高效的 API 編排、與其他 Azure 服務的無縫集成，並透過減少開發和維護工作來節省成本。 API 管理透過直接支援身份驗證和授權來確保安全的 API 管理。 它與 Microsoft Entra ID 等身分提供者集成，支援 OAuth 2.0 並提供基於原則的授權。 此外，API 管理使用託管身分來安全、低維護地存取 Azure OpenAI。
結合場景打造綜合閘道解決方案
在實際應用程式中，您的用例可以跨越本文中的多個場景。 例如，您可能擁有透過外部身分提供者進行驗證的用戶端應用程序，並需要存取多個 Azure OpenAI 執行個體。
下載此架構的 Visio 檔案。
要建立支援您的特定要求的閘道，請結合這些場景中的建議以形成全面的方法。
執行閘道原則
在閘道傳送請求至 Azure OpenAI 執行個體之前，請確保強制實施入站身分驗證和授權原則。 為了確保閘道僅轉送經過驗證和授權的請求，請使用來自身分提供者的使用者存取權杖或憑證驗證來實施此方法。
若要啟用精細控制，請透過閘道中用戶端應用程式的角色和權限實施更多授權範圍。 使用這些範圍來允許根據用戶端應用程式的需求進行特定操作。 這種方法增強了安全性和可管理性。
對於存取權杖驗證，請務必驗證所有關鍵註冊聲明 (例如 iss、aud、exp 和 nbf）以及任何相關的特定於工作負載的聲明 (例如群組成員資格或應用程式角色)。
使用 Azure 受控識別
若要簡化所有用戶端應用程式方案的驗證，請使用 Azure 託管識別碼集中身分驗證管理。 此方法降低了與管理用戶端應用程式中的多個 API 金鑰或憑證相關的複雜性和風險。
託管識別碼本質上支援 Azure RBAC，因此它們確保閘道僅具有存取 Azure OpenAI 執行個體所需的最低層級的權限。 為了降低未經授權的存取風險並簡化安全性原則的合規性，請將託管身分與其他停用替代驗證的方法結合。
實現全面的可檢視性
當您使用託管識別實現閘道時，會降低可追溯性，因為託管標識代表閘道本身，而不是發出請求的使用者或應用程式。 因此，提高與 API 請求相關的指標的可檢視性至關重要。 為了保持存取模式和使用情況的可見性，閘道應提供更多追蹤元資料，例如請求用戶端和使用者 ID。
集中記錄通過閘道的所有請求可協助您維護審計追蹤。 集中式稽核追蹤對於故障排除、合規性和偵測未經授權的存取嘗試尤其重要。
閘道實施
Azure 不提供統包解決方案或參考架構來建置本文中的閘道，因此您必須建置和操作閘道。 Azure 提供了社群支援的實作範例，涵蓋了本文中的用例。 當您建立自己的閘道解決方案時，請參考這些範例。 有關詳細資訊，請參閱影片即時學習：Azure OpenAI 應用程式身份和安全性。
參與者
以下貢獻者最初撰寫了本文。
主要作者：
- Lizet Pena De Sola | Azure FastTrack 資深客戶工程師
- Bappaditya Banerjee | Azure FastTrack 資深客戶工程師
- James Croft | ISV & 數位原生卓越中心客戶工程師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。
下一步
- 適用於 Azure OpenAI 的 RBAC
- 在 API 管理中使用託管身份
- API 管理中的原則
- APIM 中 API 的驗證和授權
- 使用 OAuth 2.0 和 Microsoft Entra ID 來保護 API 管理中的 API
- 透過在 API 管理中使用用戶端憑證驗證來保護後端服務