.NET 用 Azure ID ライブラリを使用した認証のベスト プラクティス

この記事では、Azure サービスに対する認証時に .NET アプリのパフォーマンスと信頼性を最大限に高めるのに役立つガイドラインを提供します。 .NET 用の Azure Identity ライブラリを最大限に活用するには、潜在的な問題と軽減手法を理解することが重要です。

運用環境で確定的な資格情報を使用する

DefaultAzureCredential は Azure Identity ライブラリを使い始めるのに最も近い方法ですが、その便利さにも特定のトレードオフが生じます。 最も顕著なのは、チェーン内で成功し、要求認証に使用される特定の資格情報を事前に保証することはできません。 運用環境では、この予測不能性により、重大で、時には微妙な問題が発生する可能性があります。

たとえば、次の架空の一連のイベントについて考えてみます。

1. 組織のセキュリティ チームは、すべてのアプリでマネージド ID を使用して Azure リソースに対する認証を行う必要があります。
2. 数か月間、Azure 仮想マシン (VM) でホストされている .NET アプリは、マネージド ID を介して認証するために DefaultAzureCredential を正常に使用します。
3. サポート チームに指示することなく、開発者はその VM に Azure CLI をインストールし、az login コマンドを実行して Azure に対して認証します。
4. Azure 環境での個別の構成変更により、元のマネージド ID を介した認証が予期せずサイレントモードで失敗し始めます。
5. DefaultAzureCredential 失敗した ManagedIdentityCredential をスキップし、次に使用可能な資格情報 (AzureCliCredential) を検索します。
6. アプリケーションでは、マネージド ID ではなく Azure CLI 資格情報の使用が開始され、失敗したり、予期しない昇格や特権の削減が発生したりする可能性があります。

運用環境のアプリでこのような種類の微妙な問題やサイレント エラーが発生するのを防ぐには、DefaultAzureCredential から次のいずれかの決定論的な解決策に移行することを強くお勧めします。

• ManagedIdentityCredential など、特定の TokenCredential 実装。 オプションについては、派生 の一覧 を参照してください。
• アプリが動作する Azure 環境向けに最適化された、簡素化された ChainedTokenCredential の実装。 ChainedTokenCredential 基本的に、運用環境用の ManagedIdentity や開発用の VisualStudioCredential など、受け入れ可能な資格情報オプションの特定の許可リストを作成します。

たとえば、ASP.NET Core プロジェクトで次の DefaultAzureCredential 構成を考えてみましょう。

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));

    DefaultAzureCredential credential = new();
    clientBuilder.UseCredential(credential);
});

上記のコードを、必要な資格情報のみを指定する ChainedTokenCredential 実装に置き換えます。

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));

    clientBuilder.UseCredential(new ChainedTokenCredential(
        new ManagedIdentityCredential(clientId: userAssignedClientId),
        new VisualStudioCredential()));
});

この例では、ManagedIdentityCredential は運用環境で自動的に検出されますが、VisualStudioCredential はローカル開発環境で動作します。

資格情報インスタンスを再利用する

可能な限り資格情報インスタンスを再利用して、アプリの回復性を向上させ、Microsoft Entra ID に発行されるアクセス トークン要求の数を減らします。 資格情報が再利用されると、基になる MSAL 依存関係によって管理されるアプリ トークン キャッシュからトークンをフェッチしようとします。 詳細については、「Azure Identity クライアント ライブラリの トークン キャッシュ」を参照してください。

重要

資格情報を再利用しない大量のアプリでは、Microsoft Entra ID からの HTTP 429 調整応答が発生し、アプリが停止する可能性があります。

推奨される資格情報の再利用戦略は、.NET アプリケーションの種類によって異なります。

ASP.NET Core

Microsoft.Extensions.Azureの UseCredential メソッドを使用して資格情報の再利用を実装します。 たとえば、UserAssignedClientId 環境変数が設定された Azure App Service でホストされている ASP.NET Core アプリを想像してみてください。 .NET 構成プロバイダーは環境変数が存在することを判断し、ManagedIdentityCredential を使用して Key Vault シークレットと Blob Storage クライアントを認証します。 それ以外の場合は、開発時の資格情報のチェーン シーケンスが使用されます。

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddSecretClient(new Uri("<key-vault-url>"));
    clientBuilder.AddBlobServiceClient(new Uri("<blob-storage-url>"));

    string? clientId = builder.Configuration["UserAssignedClientId"];

    TokenCredential credential = clientId is not null
        ? new ManagedIdentityCredential(
            ManagedIdentityId.FromUserAssignedClientId(clientId))
        : new ChainedTokenCredential(
            new VisualStudioCredential(),
            new AzureCliCredential(),
            new AzurePowerShellCredential());

    clientBuilder.UseCredential(credential);
});

この方法の詳細については、「Microsoft Entra IDを使用した認証」を参照してください。

その他

non-ASP.NET Core アプリでは、資格情報の再利用は、各クライアント コンストラクターに同じ資格情報インスタンスを渡すことによって実現されます。 たとえば、Windows で認証ブローカーを使用する WPF アプリを想像してみてください。

private void testBrokeredAuth_Click(object sender, RoutedEventArgs e)
{
    IntPtr windowHandle = new WindowInteropHelper(this).Handle;
    InteractiveBrowserCredential credential = new(
        new InteractiveBrowserCredentialBrokerOptions(windowHandle)
        {
            UseDefaultBrokerAccount = true,
        });

    BlobServiceClient blobServiceClient = new(
        new Uri("<blob-storage-url>"),
        credential);

    SecretClient secretClient = new(
        new Uri("<key-vault-url>"),
        credential);
}

トークンの有効期間とキャッシュ ロジックが必要なタイミングを理解する

Azure Core に依存する Azure SDK クライアント ライブラリコンテキスト外で Azure ID ライブラリの資格情報を使用する場合は、トークンの有効期間の とキャッシュ動作をアプリで管理する必要があります。

AccessTokenの RefreshOn プロパティは、トークンの更新を試みることができるタイミングに関するヒントをコンシューマーに提供します。これは、トークンを更新するために Azure Core ライブラリに依存する Azure SDK クライアント ライブラリによって自動的に使用されます。 トークン キャッシュ をサポートする資格情報Azure ID ライブラリを直接使用する場合、基になる MSAL キャッシュは、RefreshOn 時間が発生したときに自動的に事前に更新されます。 この設計により、クライアント コードはトークンが必要なたびに GetToken を呼び出し、ライブラリに更新を委任できます。

必要な場合にのみ GetToken を呼び出すには、RefreshOn の日付を確認し、その後に事前にトークンの更新を試みます。 具体的な実装はお客様が行います。

マネージド ID の再試行戦略を理解する

.NET 用 Azure Identity ライブラリを使用すると、ManagedIdentityCredentialを使用してマネージド ID を使用して認証できます。 ManagedIdentityCredential を使用する方法は、適用された再試行戦略に影響します。 次の方法で使用する場合:

• DefaultAzureCredential、最初のトークン取得の試行が失敗した場合や、短い期間が経過した後にタイムアウトになった場合、再試行は試行されません。 これは、効率的な開発内部ループのために "高速に失敗" するように最適化されているため、最も回復力の低いオプションです。
• ChainedTokenCredentialや ManagedIdentityCredential のような他の方法としては、直接的なものがあります。

  • 再試行の間隔は 0.8 秒から始まり、既定では最大 5 回の再試行が試行されます。 このオプションは回復性のために最適化されていますが、開発内部ループで望ましくない可能性のある遅延が発生します。

  • 既定の再試行設定を変更するには、ManagedIdentityCredentialOptionsの Retry プロパティを使用します。 たとえば、最大 3 回再試行し、開始間隔は 0.5 秒です。

    ManagedIdentityCredentialOptions miCredentialOptions = new(
            ManagedIdentityId.FromUserAssignedClientId(clientId)
        )
        {
            Retry =
            {
                MaxRetries = 3,
                Delay = TimeSpan.FromSeconds(0.5),
            }
        };
        ChainedTokenCredential tokenChain = new(
            new ManagedIdentityCredential(miCredentialOptions),
            new VisualStudioCredential()
        );
    

再試行ポリシーのカスタマイズの詳細については、「カスタム再試行ポリシーの設定」を参照してください。