Azure Identity ライブラリを使用して .NET アプリを Azure サービスに認証する方法の概要
アプリから Azure リソースにアクセスする必要がある場合は、アプリを Azure に対して認証する必要があります。 これは、Azure にデプロイされているか、オンプレミスにデプロイされているか、ローカル開発者のワークステーションで開発中であるかに関係なく、すべてのアプリに当てはまります。 この記事では、Azure SDK クライアント ライブラリを使用するときに Azure に対してアプリを認証するための推奨される方法について説明します。
推奨されるアプリの認証方法
アプリでは、Azure リソースへの認証時に、接続文字列ではなくトークンベースの認証を使用することをお勧めします。 Azure Identity ライブラリは、トークンベースの認証をサポートするクラスを提供します。これを使用することで、アプリがローカル開発中の場合、Azure にデプロイされている場合、オンプレミス サーバーにデプロイされている場合を問わず、アプリが Azure リソースに対してシームレスに認証できるようになります。
アプリが Azure リソースに対する認証に使用するトークンベースの認証の特定の種類は、次の図に示すように、アプリが実行される場所によって異なります。
アプリの使用環境によってお勧めの認証方法が異なります。
- 開発中にローカルで実行する場合、アプリはローカル開発用のアプリケーション サービス プリンシパルまたは開発者の Azure 資格情報を使用して Azure に対して認証できます。 各オプションについて詳しくは、ローカル開発時の認証に関するセクションをご覧ください。
- Azure でホストされている場合、アプリはマネージドIDを使用してAzureリソースに対して認証する必要があります。 このオプションについて詳しくは、サーバー環境での認証に関するセクションをご覧ください。
- オンプレミスでホストおよびデプロイされた場合、アプリケーション サービス プリンシパルを使用して Azure リソースに対してアプリを認証する必要があります。 このオプションについて詳しくは、サーバー環境での認証に関するセクションをご覧ください。
DefaultAzureCredential
Azure Identity ライブラリで提供されている DefaultAzureCredential クラスを使用すると、アプリが実行されている環境に応じて異なる認証方法を使用できます。 これにより、コードを変更せずに、ローカル開発からテスト環境、運用環境へアプリを昇格できます。 環境ごとに適切な認証方法を構成すると、DefaultAzureCredential によりその認証方法が自動的に検出されて使用されます。 さまざまな環境で異なる認証方法を使用するには、条件付きロジックや機能フラグを手動でコーディングするよりも、DefaultAzureCredential を使用することをお勧めします。
DefaultAzureCredential の使用方法の詳細については、アプリケーションでの DefaultAzureCredential の使用に関するセクションを参照してください。
トークンベースの認証の利点
トークンベースの認証には、接続文字列を使用した認証に比べて次のような利点があります。
- 以下で説明するトークンベースの認証方法を使用すると、Azure リソースでアプリに必要な特定のアクセス許可を確立できます。 これは、最小限の特権の原則に従います。 これに対し、接続文字列では Azure リソースに対する完全な権限が付与されます。
- 接続文字列を持つすべてのユーザーまたはアプリが Azure リソースに接続できるのに対し、トークンベースの認証方法では、リソースへのアクセスのスコープを、リソースへのアクセスを意図したアプリのみに設定します。
- マネージド ID の場合、保存するアプリケーション シークレットはありません。 これにより、侵害される可能性のある接続文字列やアプリケーション シークレットがなくなるため、アプリの安全性が高くなります。
- Azure.Identity パッケージでは、Microsoft Entra トークンの取得と管理が行われます。 これにより、トークンベースの認証を接続文字列として簡単に使用できます。
接続文字列の使用は、運用環境や機密データにアクセスしない概念実証アプリまたは開発プロトタイプに限定する必要があります。 それ以外の場合は、Azure リソースに対する認証時に、Azure Identity ライブラリで使用できるトークンベースの認証クラスを常に優先する必要があります。
サーバー環境での認証
サーバー環境でホストする場合、各アプリには、アプリが実行される環境ごとに一意の アプリケーション ID を割り当てる必要があります。 Azure では、アプリケーション ID は、Azure に対するアプリの識別と認証を目的とした特殊な種類のセキュリティ プリンシパルであるサービス プリンシパルによって表されます。 アプリに使用するサービス プリンシパルの種類は、アプリが実行されている場所によって異なります。
| 認証方法 | 説明 |
|---|---|
| Azure でホストされているアプリ | Azure でホストされているアプリでは、マネージド ID サービス プリンシパルを使用する必要があります。 マネージド ID は、Azure でホストされているアプリの ID を表すように設計されており、Azure でホストされているアプリでのみ使用できます。 たとえば、Azure App Service でホストされている .NET Web アプリにはマネージド ID が割り当てられます。 アプリに割り当てられたマネージド ID は、他の Azure サービスに対するアプリの認証に使用されます。 |
| Azure の外部でホストされているアプリ (オンプレミス アプリなど) |
Azure サービスに接続する必要がある Azure の外部でホストされているアプリ (オンプレミス アプリなど) では、アプリケーション サービス プリンシパルを使用する必要があります。 アプリケーション サービス プリンシパルは Azure のアプリの ID を表し、アプリケーション登録プロセスを通じて作成されます。 たとえば、Azure Blob Storage を利用するオンプレミスでホストされている .NET Web アプリがあるとします。 アプリの登録プロセスを使用して、アプリのアプリケーション サービス プリンシパルを作成します。 AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_CLIENT_SECRET はすべて環境変数として格納され、実行時にアプリケーションによって読み取られ、アプリケーション サービス プリンシパルを使用してアプリが Azure に対して認証できるようにします。 |
ローカル開発時の認証
ローカル開発時に開発者のワークステーションでアプリを実行する場合でも、アプリで使用されるすべての Azure サービスに対して認証する必要があります。 ローカル開発時に Azure に対してアプリを認証するための主な戦略は次の 2 つです。
| 認証方法 | 説明 |
|---|---|
| ローカル開発時に使用する専用のアプリケーション サービス プリンシパル オブジェクトを作成する | この方法では、専用のアプリケーション サービス プリンシパル オブジェクトが、ローカル開発時に使用するアプリ登録プロセスを使用して設定されます。 その後、サービス プリンシパルの ID は、アプリがローカル開発で実行されるときにアクセスする環境変数として格納されます。 この方法では、ローカル開発時に開発者が使用するサービス プリンシパル オブジェクトに、アプリで必要な特定のリソース アクセス許可を割り当てることができます。 これにより、アプリケーションでは必要な特定のリソースにのみアクセスでき、運用環境でアプリに割り当てられるアクセス許可がレプリケートされます。 この方法の欠点は、アプリケーションで作業する開発者ごとに個別のサービス プリンシパル オブジェクトを作成する必要があることです。 |
| ローカル開発時に開発者の資格情報を使用して Azure に対してアプリを認証する | この方法では、開発者は、Visual Studio、VS Code 用の Azure Tools 拡張機能、Azure CLI、またはローカル ワークステーション上の Azure PowerShell から Azure にサインインする必要があります。 その後アプリケーションは、資格情報ストアから開発者の資格情報にアクセスし、それらの資格情報を使用してアプリから Azure リソースにアクセスできます。 この方法には、開発者が Visual Studio、VS Code、または Azure CLI から自分の Azure アカウントにのみログインするだけで済むため、セットアップが簡単になるという利点があります。 この方法の欠点は、開発者のアカウントにアプリケーションで必要とされるよりも多くのアクセス許可が与えられることです。 したがって、このアプローチでは、アプリが実稼働環境で使用するアクセス許可を正確に再現することはできません。 |
アプリケーションで DefaultAzureCredential を使用する
DefaultAzureCredential は、Microsoft Entra ID に対する認証のための、堅牢な順序付けられた一連のメカニズムです。 各認証メカニズムは、TokenCredential クラスから派生したクラスであり、資格情報と呼ばれます。 実行時に、DefaultAzureCredential は最初の資格情報を使用して認証を試みます。 その資格情報がアクセス トークンの取得に失敗した場合は、シーケンス内の次の資格情報が試みられ、正常にアクセス トークンが取得されるまでそれを続けます。 これにより、アプリは環境固有のコードを記述せずに、さまざまな環境でさまざまな資格情報を使用できます。
DefaultAzureCredentialを使用するには、Azure.Identity パッケージを (必要に応じて Microsoft.Extensions.Azure パッケージも) アプリケーションに追加します。
任意のターミナルで、アプリケーション プロジェクト ディレクトリに移動し、以下のコマンドを実行します。
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Azure サービスには、さまざまな Azure SDK クライアント ライブラリの特殊なクライアント クラスを使用してアクセスします。 これらのクラスと独自のカスタム サービスは、アプリ全体で依存関係の挿入を介してアクセスできるように登録する必要があります。 Program.cs で、以下の手順を実行して、クライアント クラスと DefaultAzureCredential を登録します:
usingディレクティブを使用して、Azure.IdentityおよびMicrosoft.Extensions.Azure名前空間を含めます。Addプレフィックス付きの対応する拡張メソッドを使用して、Azure サービス クライアントを登録します。DefaultAzureCredentialのインスタンスをUseCredentialメソッドに渡します。
次に例を示します。
using Microsoft.Extensions.Azure;
using Azure.Identity;
builder.Services.AddAzureClients(clientBuilder =>
{
clientBuilder.AddBlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"));
clientBuilder.UseCredential(new DefaultAzureCredential());
});
UseCredential を使用する代わりに、DefaultAzureCredential を直接インスタンス化することもできます。
using Azure.Identity;
builder.Services.AddSingleton<BlobServiceClient>(_ =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
上記のコードをローカル開発ワークステーションで実行すると、環境変数でアプリケーション サービス プリンシパルが検索されるか、ローカルにインストールされた開発者ツール (Visual Studio など) で開発者の資格情報のセットが検索されます。 どちらのアプローチも、ローカル開発中に Azure リソースに対してアプリを認証するために使用できます。
Azure にデプロイすると、この同じコードでアプリを他の Azure リソースに対して認証することもできます。 DefaultAzureCredential では、環境設定とマネージド ID 構成を取得し、他のサービスに対して自動的に認証することができます。
.NET