.NET Azure SDK を使用して Azure サービスに対して .NET アプリを認証する方法
ストレージ、キー コンテナー、コグニティブ サービスなどの Azure リソースにアプリケーションがアクセスする必要がある場合は、Azure に対してアプリケーションを認証する必要があります。 これは、Azure にデプロイされているか、オンプレミスにデプロイされているか、ローカル開発者のワークステーションで開発中であるかに関係なく、すべてのアプリケーションに当てはまります。 この記事では、Azure SDK for .NET を使用するときに Azure に対してアプリを認証するための推奨される方法について説明します。
推奨されるアプリの認証方法
アプリでは、Azure リソースに対して認証するときに、接続文字列ではなくトークンベースの認証を使用することをお勧めします。 Azure SDK for .NET には、トークンベースの認証がサポートされているクラスが用意されており、アプリがローカル開発中か、Azure にデプロイされているか、オンプレミス サーバーにデプロイされているかに関係なく、アプリが Azure リソースに対してシームレスに認証できるようにします。
アプリが Azure リソースに対する認証に使用するトークンベースの認証の特定の種類は、次の図に示すように、アプリが実行される場所によって異なります。
- 開発者がローカル開発時にアプリを実行している場合 - アプリは、ローカル開発用のアプリケーション サービス プリンシパルを使用するか、開発者の Azure 資格情報を使用して Azure に対して認証できます。 これらの各オプションについては、「ローカル開発時の認証」のセクションで詳しく説明します。
- アプリが Azure でホストされている場合 - アプリは、マネージド ID を使用して Azure リソースに対して認証する必要があります。 このオプションについては、以下の「サーバー環境での認証」のセクションで詳しく説明します。
- アプリがオンプレミスでホストされデプロイされている場合 - アプリは、サービス プリンシパルを使用して Azure リソースに対して認証する必要があります。 このオプションについては、以下の「サーバー環境での認証」のセクションで詳しく説明します。
DefaultAzureCredential
Azure SDK によって提供される DefaultAzureCredential クラスを使用すると、アプリでは実行環境に応じて異なる認証方法を使用できます。 これにより、コードを変更せずに、ローカル開発からテスト環境、運用環境へアプリを昇格できます。 環境ごとに適切な認証方法を構成すると、DefaultAzureCredential によりその認証方法が自動的に検出されて使用されます。 さまざまな環境で異なる認証方法を使用するには、条件付きロジックや機能フラグを手動でコーディングするよりも、DefaultAzureCredential を使用することをお勧めします。
DefaultAzureCredential クラスの使用の詳細については、この記事の後半の「アプリケーションで DefaultAzureCredential を使用する」で説明します。
トークンベースの認証の利点
Azure 用のアプリを構築するときには、接続文字列を使用するよりもトークンベースの認証を強くお勧めします。 トークンベースの認証には、接続文字列を使用した認証に比べて次のような利点があります。
- 以下で説明するトークンベースの認証方法を使用すると、Azure リソースでアプリに必要な特定のアクセス許可を確立できます。 これは、最小限の特権の原則に従います。 これに対し、接続文字列では Azure リソースに対する完全な権限が付与されます。
- 接続文字列を持つすべてのユーザーまたはアプリが Azure リソースに接続できるのに対し、トークンベースの認証方法では、リソースへのアクセスのスコープを、リソースへのアクセスを意図したアプリのみに設定します。
- マネージド ID の場合、格納するアプリケーション シークレットはありません。 これにより、侵害される可能性がある接続文字列やアプリケーション シークレットがないため、アプリの安全性が高くなります。
- Azure SDK の Azure.Identity パッケージでは、バックグラウンドでトークンを管理します。 これにより、トークンベースの認証を接続文字列として簡単に使用できます。
接続文字列の使用は、運用環境や機密データにアクセスしない概念実証アプリまたは開発プロトタイプに限定する必要があります。 それ以外の場合は、Azure リソースに対する認証時に、Azure SDK で使用できるトークンベースの認証クラスを常に優先する必要があります。
サーバー環境での認証
サーバー環境でホストする場合、各アプリケーションには、アプリケーションが実行されている環境ごとに一意のアプリケーション 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 では複数の認証方法がサポートされており、実行時に使われる認証方法が決定されます。 このようにして、アプリでは環境固有のコードを実装することなく、さまざまな環境でさまざまな認証方法を使用できます。
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());
});
または、次に示すように、追加の Azure 登録メソッドを使わず、サービスでより直接的に DefaultAzureCredential を利用することもできます。
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 では、環境設定とマネージド ID 構成を取得し、他のサービスに対して自動的に認証することができます。
DefaultAzureCredential 認証方法のシーケンスについて
内部的には、DefaultAzureCredential で Azure リソースに対してアプリケーションを認証するための資格情報プロバイダーのチェーンが実装されます。 各資格情報プロバイダーでは、その種類の資格情報がアプリ用に構成されているかどうかを検出できます。 DefaultAzureCredential では各プロバイダーを順番にチェックし、資格情報が構成されている最初のプロバイダーの資格情報が使用されます。
DefaultAzureCredential によって資格情報が検索される順序と場所は、DefaultAzureCredential にあります。
| 資格情報の種類 | 説明 |
|---|---|
| アプリケーション サービス プリンシパル | DefaultAzureCredential では、一連の環境変数を読み取り、アプリケーション サービス プリンシパル (アプリケーション ユーザー) がアプリに設定されているかどうかを判断します。 そうであれば、DefaultAzureCredential はこれらの値を使用し、Azure に対してアプリを認証します。この方法は、サーバー環境で最もよく使用されますが、ローカルで開発する場合も使用できます。 |
| マネージド ID | マネージド ID が有効な Azure ホストにアプリケーションがデプロイされている場合、DefaultAzureCredential ではそのアカウントを使用して、Azure に対してアプリを認証します。 マネージド ID を使用した認証については、このドキュメントの「サーバー環境での認証」セクションで説明します。この方法は、Azure App Service、Azure Functions、Azure Virtual Machines などのサービスを使用してアプリケーションが 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 コマンドレットを使用して Azure に対して認証を行った場合、DefaultAzureCredential ではその同じアカウントを使用してアプリを Azure に認証します。 |
| Interactive | 有効にした場合、DefaultAzureCredential では、現在のシステムの既定のブラウザーを介して開発者を対話形式で認証します。 既定では、このオプションは無効になっています。 |
.NET
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示