Azure OpenAI 支援的驗證方法
Azure OpenAI 支援數種驗證方法，以確保對其資源的安全和控制存取。 主要方法是：
- API 金鑰：Azure OpenAI 也支援 API 金鑰型驗證。 API 金鑰是在 Azure 入口網站內產生，可用來驗證對 Azure OpenAI 服務的要求。 不建議從安全性觀點使用這個驗證方法，且應該只作為最後手段使用。 如果您必須使用這個驗證方法，請務必安全地處理 API 金鑰，並定期輪替禁藥，以降低未經授權存取的風險。
- Microsoft Entra 識別碼： 此方法會利用 Microsoft Entra 的強固身分識別和存取管理功能。 使用者和應用程式會使用 Microsoft Entra 身分識別進行驗證，這可以是傳統使用者帳戶或受控識別。 此方法可確保只有已驗證和授權的使用者才能存取 Azure OpenAI 資源。
- Entra受控識別： Azure 資源的受控識別會在 Microsoft Entra 中提供自動受控識別，讓應用程式在連線到支援 Microsoft Entra 驗證的資源時使用。 這些身分識別可以是系統指派，表示它們會繫結至特定的 Azure 資源或使用者指派，這可讓單一身分識別跨多個資源共用。 受控識別可簡化認證的管理，並藉由消除應用程式程式碼中硬式編碼認證的需求，以增強安全性。
為什麼受控識別比 API 金鑰更安全
Microsoft Azure 中的受控識別提供更安全的 API 金鑰替代方案，而原因有數個：
- 受控識別不需要開發人員直接處理認證，進而降低意外暴露或濫用的風險。
- 使用 API 金鑰時，開發人員必須在其應用程式程式碼或組態檔中內嵌這些金鑰。
API 金鑰可能會不小心透過原始程式碼存放庫、記錄或其他方式公開。 這種暴露可能會導致未經授權的存取和潛在的安全性缺口。 相較之下，受控識別可針對應用程式提供自動受控識別，以在連線至支援 Microsoft Entra (先前稱為 Azure AD) 驗證的資源時使用。 這表示認證不會儲存在應用程式程式碼中，因而降低洩漏和未經授權存取的風險。
此外，受控識別可讓 Azure 服務安全地向其他 Azure 服務進行驗證，以簡化驗證程序，而不需要明確認證。 這是使用由 Microsoft Entra 所發行的權杖來達成此目的，這些權杖會自動進行管理和輪替，確保認證一律為最新狀態，並降低認證竊取的風險。 另一方面，API 金鑰為靜態且需要手動輪替，這可能會導致容易出錯且經常遭到忽視，因此導致潛在的弱點。 開發人員可以使用受控識別，利用 Azure 的內建安全性功能，例如角色型存取控制 (RBAC)，將精確的權限授與資源，以進一步增強安全性。
Microsoft 建議您在向 Azure OpenAI 或支援受控識別的任何其他 Azure 服務驗證時，透過 API 金鑰使用受控識別。
在 Azure OpenAI 內使用 API 金鑰和受控識別之間的差異
讓我們評估外洩用戶端識別碼與外洩 API 金鑰的影響。
API 金鑰功能類似於一般密碼。 如果遭到入侵，則擁有金鑰的任何人都可以存取資源。 對於 Azure OpenAI，這表示不受限制地使用 GPT-4 等 AI 模型。 如果可公開存取網路，則安全性影響可能更大。
相反地，如果用戶端識別碼外洩，風險會降到最低。 這是因為單憑用戶端識別碼無法建立與 Azure OpenAI 的連線。 若要利用受控識別，服務必須在 Azure 上運作，而即使 Azure OpenAI 是公用的，您也無法從本機環境或使用應用程式透過網路連線。
總而言之，相較於外洩 API 金鑰的後果，惡意探索洩露的用戶端識別碼牽涉到數個步驟，使得惡意執行者更難進行惡意探索。
基於這些原因，與 API 金鑰相比，受控識別提供更安全的方法來管理作業。 在向 Azure OpenAI 進行驗證時，建議您在驗證至 Azure OpenAI 或任何其他支援受控識別的 Azure 服務時，透過 API 金鑰使用受控識別。
系統與使用者指派的身分識別
建置 Azure OpenAI 應用程式時，了解系統指派和使用者指派的身分識別之間的差異對於最佳安全性和資源管理至關重要。
- 系統指派的身分識別 是由 Azure 針對特定資源建立和管理。 刪除資源時，也會刪除其相關聯的系統指派的身分識別，確保身分識別生命週期與其所屬的資源緊密結合。 這種類型的身分識別很適合只需要由單一資源使用身分識別的案例，提供簡單性並減少系統管理額外負荷，因為 Azure 會管理身分識別的認證。
- 使用者指派的身分識別 會獨立於任何特定資源建立，而且可以跨多個資源分享。 這在針對需要在不同資源之間一致身分識別的應用程式具有多功能，以方便管理權限和存取控制。 即使在刪除使用它們的資源之後，使用者指派的身分識別仍會持續存在，以在重新部署和重複使用身分識別方面具有更大的彈性。
選擇系統指派和使用者指派的身分識別，取決於應用程式的特定需求。 對於簡單且最少管理為優先順序的單一資源應用程式，系統指派的身分識別通常是最佳選擇。 相反地，對於需要跨多個資源共用身分識別的應用程式，使用者指派的身分識別可提供更大的彈性和重複使用性。
