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