如何使用 .NET Azure SDK 向 Azure 服務驗證 .NET 應用程式
當應用程式必須存取儲存體、金鑰保存庫或認知服務等 Azure 資源時，則須向 Azure 進行驗證。 無論是部署至 Azure、內部部署或在本機開發人員工作站上進行開發，皆須進行此動作。 本文說明使用 Azure SDK for .NET 時，向 Azure 驗證應用程式的建議方法。
建議的應用程式驗證方法
向 Azure 資源進行驗證時，建議應用程式使用權杖型驗證，而不是連接字串。 Azure SDK for .NET 提供支援權杖型驗證的類別，無論是本機開發、部署至 Azure，還是部署至內部部署伺服器，都能讓應用程式向 Azure 資源流暢進行驗證。
向 Azure 資源驗證時，應用程式應使用的特定權杖型驗證類型取決於其執行位置，如下圖所示。
- 當開發人員在本機開發期間執行應用程式時 - 應用程式可針對本機開發使用應用程式服務主體，或使用開發人員的 Azure 認證向 Azure 進行驗證。 在本機開發期間驗證一節中，將詳細分別討論這些選項。
- 當應用程式裝載於 Azure 時 - 應用程式應使用受控識別向 Azure 資源進行驗證。 在伺服器環境中驗證一節中，將詳細討論這個選項。
- 當應用程式裝載並部署於內部部署時 - 應用程式應使用應用程式服務主體向 Azure 資源進行驗證。 在伺服器環境中驗證一節中，將詳細討論這個選項。
DefaultAzureCredential
Azure SDK 提供的 DefaultAzureCredential 類別可讓應用程式根據執行環境使用不同的驗證方法。 這可讓應用程式從本機開發升階至實際執行環境，以便測試環境且無須變更程式碼。 您可為每個環境設定適當的驗證方法，DefaultAzureCredential 會自動偵測及使用該驗證方法。 使用 DefaultAzureCredential 時應優先選擇手動編碼條件式邏輯或功能旗標，以便在不同環境中使用不同驗證方法。
本文稍後將討論如何使用 DefaultAzureCredential 類別的詳細資料，請參閱在應用程式中使用 DefaultAzureCredential一節。
權杖型驗證的優點
建置適用於 Azure 的應用程式時，強烈建議使用權杖型驗證，而不是連接字串。 相較於使用連接字串的驗證方式，權杖型驗證可提供下列優點。
- 下述的權杖型驗證方法可讓您在 Azure 資源上建立應用程式所需的特定權限。 遵循最低權限原則。 反之，連接字串會授與完整權限給 Azure 資源。
- 使用連接字串的任何人員或應用程式皆可連線至 Azure 資源，權杖型驗證方法則會將資源的存取範圍限定為預定存取資源的應用程式。
- 在受控識別的情況下，沒有應用程式秘密可供儲存。 由於沒有可遭入侵的連接字串或應用程式密碼，應用程式便更加安全。
- Azure SDK 中的 Azure.Identity 套件會在幕後為您管理權杖。 如此，使用權杖型驗證便會像連接字串一樣易於使用。
連接字串的使用情境，應限制為不存取實際執行或敏感性資料的初始概念證明應用程式或開發原型。 否則，在對 Azure 資源進行驗證時，應一律優先使用 Azure SDK 中所提供的權杖型驗證類別。
伺服器環境中的驗證
裝載於伺服器環境中時，應針對應用程式執行的環境，將唯一的應用程式身分識別指派給各應用程式。 在 Azure 中，服務主體即代表應用程式身分識別，這是一種特殊類型的安全性主體，用於識別和驗證 Azure 的應用程式。 應用程式要使用的服務主體類型，取決於應用程式的執行位置。
| 驗證方法 | 描述 |
|---|---|
| Azure 裝載的應用程式 | Azure 裝載的應用程式應使用受控識別服務主體。 受控識別的設計目的是代表 Azure 裝載的應用程式身分識別，且只能用於 Azure 裝載的應用程式。 例如，系統會將 Azure App Service 所裝載的 .NET Web 應用程式會指派受控識別。 指派給該應用程式的受控識別便會用於向其他 Azure 服務驗證應用程式。 |
| Azure 外部裝載的應用程式 (例如內部部署應用程式) |
必須連線至 Azure 服務的 Azure 外部裝載應用程式 (例如內部部署應用程式)，應使用應用程式服務主體。 應用程式服務主體代表該應用程式在 Azure 中的身分識別，且會透過應用程式註冊流程建立。 例如，假設內部部署裝載的 .NET Web 應用程式使用 Azure Blob 儲存體。 您會使用應用程式註冊流程，為應用程式建立應用程式服務主體。 AZURE_CLIENT_ID、AZURE_TENANT_ID 和 AZURE_CLIENT_SECRET 皆會儲存為環境變數，供應用程式在執行階段進行讀取，並可讓應用程式使用應用程式服務主體向 Azure 進行驗證。 |
本機開發期間的驗證
當應用程式在本機開發期間於開發人員的工作站上執行時，仍必須向應用程式使用的任何 Azure 服務進行驗證。 在本機開發期間，向 Azure 驗證應用程式的兩項主要策略如下：
| 驗證方法 | 描述 |
|---|---|
| 建立本機開發期間專用的應用程式服務主體物件 | 在此方法中，專用的應用程式服務主體物件會透過應用程式註冊流程進行設定，以便用於本機開發期間。 接著，服務主體的身分識別會儲存為環境變數，在本機開發中執行該應用程式時可供存取。 透過此方法，您可將應用程式所需的特定資源權限指派給開發人員在本機開發期間使用的服務主體物件。 這可確保應用程式只能存取所需的特定資源，並複寫應用程式在實際執行環境具備的權限。 此方法的缺點，則是必須為使用應用程式的每位開發人員建立個別的服務主體物件。 |
| 在本機開發期間，使用開發人員認證向 Azure 驗證應用程式 | 在此方法中，開發人員必須從本機工作站上的 Visual Studio、適用於 VS Code 的 Azure Tools 擴充功能、Azure CLI 或 Azure PowerShell 登入 Azure。 該應用程式便可從認證存放區存取開發人員的認證，並使用這些認證存取 Azure 資源。 此方法的優點是更方便設定，因為開發人員只需要從 Visual Studio、VS Code 或 Azure CLI 登入其 Azure 帳戶。 此方法的缺點是，開發人員帳戶具備的權限可能比應用程式所需的更多。 因此，這個方法無法準確複寫應用程式在實際執行環境中執行時會用到的權限。 |
使用應用程式中的 DefaultAzureCredential
DefaultAzureCredential 支援多種驗證方法，並會決定執行階段期間使用的驗證方法。 因此，您的應用程式可在相異的環境中使用不同的驗證方法，無須實作環境特定程式碼。
DefaultAzureCredential 尋找認證的順序和位置，可在 DefaultAzureCredential中找到。
為實作 DefaultAzureCredential，請先將 Azure.Identity 與選擇性的 Microsoft.Extensions.Azure 套件新增至您的應用程式。 您可透過命令列或 NuGet 套件管理員執行此動作。
在應用程式專案目錄中開啟您想要的終端環境，然後輸入下列命令。
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Azure 服務通常使用 SDK 的對應用戶端類別來存取。 這些類別和您自訂的服務都應在 Program.cs 檔案中註冊，使其可在應用程式中透過相依性插入來存取。 請依照下列步驟，在 Program.cs 內正確設定您的服務和 DefaultAzureCredential。
- 用 Using 陳述式納入
Azure.Identity和Microsoft.Extensions.Azure命名空間。 - 用相關的協助程式方法註冊 Azure 服務。
- 將
DefaultAzureCredential物件的執行個體傳遞至UseCredential方法。
下列程式碼區段示範其中一種範例。
using Microsoft.Extensions.Azure;
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
x.UseCredential(new DefaultAzureCredential());
});
或者，您也可以更直接地在服務中使用 DefaultAzureCredential，而不求助於其他 Azure 註冊方法，如下所示。
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
上述程式碼在本機開發期間於本機工作站上執行時，會尋找環境變數中的應用程式服務主體，或在 Visual Studio、VS Code、Azure CLI 或 Azure PowerShell 中尋找一組開發人員認證；任意者皆可於本機開發期間用來向 Azure 資源驗證應用程式。
部署至 Azure 時，這同一組程式碼也可向其他 Azure 資源驗證您的應用程式。 DefaultAzureCredential 可擷取環境設定與受控識別設定，以便自動向其他服務進行驗證。
探索 DefaultAzureCredential 驗證方法的順序
在內部，DefaultAzureCredential 會實作認證提供者鏈結，向 Azure 資源驗證應用程式。 每個認證提供者皆可偵測應用程式是否已設定該認證類型。 DefaultAzureCredential 會依序檢查各提供者，從第一個設定認證的提供者開始使用認證。
DefaultAzureCredential 尋找認證的順序和位置，可在 DefaultAzureCredential (英文) 中找到。
| 認證類型 | 描述 |
|---|---|
| 應用程式服務主體 | DefaultAzureCredential 會讀取一系列環境變數，以判斷該應用程式是否已設定應用程式服務主體 (應用程式使用者)。 如是，DefaultAzureCredential 則會使用這些值向 Azure 驗證應用程式。此方法最常用於伺服器環境，但也可在本機開發時使用。 |
| 受控識別 | 若應用程式所部署的 Azure 主機已啟用受控識別，DefaultAzureCredential 將會使用該受控識別來驗證該應用程式。 本文件伺服器環境中的驗證一節會討論使用受控識別的驗證。只有當應用程式裝載於 Azure 時使用 Azure App Service、Azure Functions 或 Azure 虛擬機器等服務，才能使用此方法。 |
| Visual Studio | 若開發人員已透過登入 Visual Studio 向 Azure 進行驗證，DefaultAzureCredential 將會使用該相同帳戶向 Azure 驗證應用程式。 |
| Visual Studio Code | 若開發人員已使用 Visual Studio Code Azure 帳戶外掛程式向 Azure 進行驗證，DefaultAzureCredential 將會使用該相同帳戶向 Azure 驗證應用程式。 |
| Azure CLI | 若開發人員已使用 Azure CLI 中的 az login 命令向 Azure 進行驗證，DefaultAzureCredential 將會使用該相同帳戶向 Azure 驗證應用程式。 |
| Azure PowerShell | 若開發人員已使用 Azure PowerShell 的 Connect-AzAccount Cmdlet 向 Azure 進行驗證，DefaultAzureCredential 將會使用該相同帳戶向 Azure 驗證應用程式。 |
| 互動式 | 若啟用，DefaultAzureCredential 將會透過目前系統的預設瀏覽器，以互動方式來驗證開發人員。 預設會停用這個選項。 |
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應