在此範例案例中，主要應用程式有三個不同的驗證需求：
Azure Key Vault
應用程式必須使用 Azure Key Vault 進行認證，才能取得安全儲存的 API 金鑰，才能呼叫第三方服務。
協力廠商 API
應用程式取得 API 金鑰後，會用該金鑰與外部第三方 API 進行驗證。
Azure 佇列儲存體
處理要求之後，應用程式必須向 Azure 佇列記憶體進行驗證，以將訊息加入佇列，以進行異步或延遲的處理。
這些工作需要應用程式管理三組認證：
Azure 資源有兩組（金鑰保存庫 和 Storage）
一組用於外部服務（第三方 API）
金鑰驗證挑戰
建立安全的雲端應用程式需要謹慎管理憑證，尤其當涉及多個服務時。 此範例案例提供數個重大挑戰：
金鑰保存庫 的迴圈相依性
應用程式會使用 Azure Key Vault 安全地儲存秘密，例如第三方 API 金鑰或 Azure 記憶體認證。 不過，若要擷取這些秘密，應用程式必須先向金鑰保存庫 進行驗證。 這種情況造成一個循環問題：應用程式需要憑證才能存取 金鑰保存庫，但你必須將這些憑證安全儲存。 若無安全解決方案，此問題可能導致開發環境中的憑證硬編碼或不安全設定。
安全處理第三方 API 金鑰
從 金鑰保存庫 擷取 API 金鑰之後，應用程式必須使用它來呼叫外部第三方服務。 請極度小心地使用這把鑰匙：
- 千萬不要硬編碼在原始碼或設定檔裡
- 千萬不要將它記錄於 stdout、stderr 或應用程式日誌中
- 僅將其保留在記憶體中，並在實際使用前於執行階段存取
- 在要求完成後，請立即將其丟棄
無法遵循這些做法會增加認證外洩或未經授權的使用風險。
保護 Azure 佇列儲存體憑證
若要將訊息寫入 Azure 佇列記憶體，應用程式通常需要連接字串或共用存取令牌。 這些認證：
- 必須儲存在安全的位置，例如 金鑰保存庫
- 不得出現在記錄、堆疊追蹤或開發人員工具中
- 只能透過安全執行環境存取
- 如果使用受控識別，則需要適當的 RBAC 設定
環境彈性
應用程式必須使用相同的程式代碼基底和最少的條件邏輯，在本機開發和雲端生產環境中可靠地執行。
此要求意味著：
- 不要在程式碼中嵌入環境特定的秘密
- 不要手動切換憑證或邏輯路徑
- 在各環境間一致使用基於身份的認證
使用 Microsoft Entra ID 的 Azure 優先驗證
隨著雲端應用程式在複雜度中進行調整，並與更多服務整合，安全且簡化的驗證就變得至關重要。 Azure 透過 Microsoft Entra ID 提供 Azure 優先身份模型，實現統一身份管理及與 Azure 服務無縫整合，實現安全且無需憑證的認證。
與其手動管理秘密或將憑證嵌入應用程式碼——這些做法容易帶來安全風險——Microsoft Entra ID 讓應用程式能透過受管理身份安全認證。
Microsoft Entra 受控識別的主要優點包括：
程式代碼中沒有秘密
應用程式不再需要硬式編碼的連接字串、客戶端密碼或密鑰。
應用程式的內建身分識別
Azure 可以自動為你的應用程式指派一個管理身份，因此它能安全地存取像是 金鑰保存庫、Storage 和 SQL 等服務，且不需要額外的憑證。
環境一致性
相同的程式碼與身份模型，無論是在本地開發或 Azure 託管環境中，皆可透過使用 Azure SDK
DefaultAzureCredential運作。
環境特定的身分識別流程
使用Microsoft Entra ID 進行驗證的應用程式，受益於可在 Azure 裝載和本機開發環境中順暢運作的彈性身分識別模型。 Azure SDK 透過DefaultAzureCredential根據環境自動選擇合適的身份方法，來提供這種一致性。
Azure 環境
當你將應用程式部署到 Azure 時：
- 應用程式會自動獲得一個管理身份。
- Azure 內部管理憑證的發行和憑證生命週期，所以你不需要處理任何秘密。
- 應用程式透過使用 Role-Based 存取控制（RBAC）或金鑰保存庫存取政策來存取服務。
本機開發環境
在本機開發期間：
- 服務主體作為應用程式的識別碼。
- 開發者透過使用 Azure CLI（
az login）、環境變數或 Visual Studio/VS Code 整合來進行認證。 - 相同的應用程式程式碼執行時不會做任何修改——只有身份來源會改變。
在這兩種環境中，Azure SDK 都會使用 DefaultAzureCredential，此機制會將身分識別來源抽象化，並自動選取正確的方法。
安全開發的最佳作法
雖然你可以將秘密設定為環境變數（例如透過 Azure App 設定），但這種方法有缺點：
- 您必須在本機環境中手動複製機密資訊。
- 機密資訊有外洩到版本控制系統的風險。
- 你可能需要額外的邏輯來區分不同的環境。
相反地，請採用以下方法：
- 使用 金鑰保存庫 來儲存第三方 API 金鑰和其他秘密。
- 為你部署的應用程式指派一個受管理身份。
- 使用服務主體進行本機開發，併為其指派相同的訪問許可權。
- 在您的程式碼中使用
DefaultAzureCredential來抽象化驗證邏輯。 - 避免儲存或記錄任何認證。
實務上的驗證流程
以下是驗證在執行時的運作方式：
- 您的程式代碼建立
DefaultAzureCredential的實例。 - 你用這個憑證來實例化一個客戶端（例如，
SecretClient，QueueServiceClient）。 - 當應用程式叫用方法時（例如，
get_secret()），用戶端會使用認證來驗證要求。 - Azure 會驗證身分識別，並檢查其是否有執行作業的正確角色或原則。
此流程可確保您的應用程式可以安全地存取 Azure 服務，而不需在程式碼或組態檔中內嵌秘密。 它也可讓您順暢地在本機開發與雲端部署之間切換，而不需要變更您的驗證邏輯。