パスワードレス認証のためのマネージド ID

従来、アプリケーションは、構成ファイルや環境変数に保存された接続文字列またはAPIキーを使用して、StorageやKey VaultなどのAzureサービスに接続していました。これらの認証情報は、誤ってソース管理にコミットされたり、ログに露出したり、侵害の際に盗まれたりする可能性があります。Managed Identityを使用すると、アプリケーションが認証情報を保存する必要が完全になくなります。代わりにAzure自体がリソースに代わってトークンを発行・更新し、アプリケーションは実行時にAzureへ現在のトークンを要求するだけです。

Managed Identityは、Azureリソース（VM、App Service、Function Appなど）に関連付けられた、Microsoft Entra IDで自動的に管理されるサービス プリンシパルです。AzureプラットフォームがIDの認証情報を作成・維持し、定期的にローテーションするため、コードがパスワードやシークレットを扱うことはありません。リソース上で実行されるアプリケーションは、Azure Instance Metadata Service（IMDS）のエンドポイント（http://169.254.169.254）を呼び出して短期間有効なOAuthトークンを取得し、そのトークンをAzureサービスに提示します。

マネージド IDには2種類あります。システム割り当ては単一のAzureリソースに紐付けられます。リソースで有効にすると作成され、リソースを削除すると自動的に削除されます。ユーザー割り当ては、個別に作成してから1つ以上のAzureリソースに関連付ける、独立したEntra IDのIDです。ユーザー割り当てIDは、複数のサービス（例：複数のFunction App）で同じIDとRBAC権限を共有する必要がある場合に便利で、ロール割り当ての重複を避けられます。

マネージド IDを有効にした後は、対象のAzureリソースに対するRBAC権限を付与する必要があります。たとえば、App ServiceからBLOBを読み取れるようにするには、ストレージアカウント上で、App Serviceのマネージド IDにStorage Blob Data Readerロールを割り当てます。RBACの割り当ては最小権限の原則に従い、必要最小限の権限だけを付与してください。絶対に必要な場合を除き、マネージド IDにOwnerまたはContributorを割り当てないでください。

Azure SDKには、複数の認証方式を決められた順序で自動的に試すDefaultAzureCredentialクラスが用意されています。認証方式には、環境変数、ワークロード ID、マネージド ID、Azure CLI、Visual Studioなどがあります。アプリケーションがAzure（App Service、VM、Function App）上で実行されると、DefaultAzureCredentialはコードを変更しなくても自動的にマネージド IDを使用します。ローカルでは、開発者はAzure CLIのセッションを使用して認証します。この1つの認証情報クラスで、条件分岐なしにあらゆる環境に対応できます。

一般的なパターンとして、マネージド IDを使用して実行時にAzure Key Vaultのシークレットへアクセスします。データベースのパスワードをアプリケーション設定に保存する代わりに、Key Vaultに保存し、アプリのマネージド IDにそのVault上のKey Vault Secrets Userロールを付与します。アプリケーションは起動時に、DefaultAzureCredentialを使用してKey Vaultからシークレットを取得します。このパターンにより、シークレットがコード、構成ファイル、環境変数に保存されることはなく、Key Vaultにのみ存在し、必要なときだけ一時的に取得されます。

Azure SQL DatabaseはEntra ID認証をサポートしているため、マネージド IDでユーザー名とパスワードを使わずにSQLへ認証できます。有効にするには、まずSQLサーバーにEntra ID管理者を設定し、次に対象データベースでマネージド IDの表示名に対するCREATE USERステートメントを実行して、適切なデータベースロールを付与します。アプリケーションはAzure SDKのDefaultAzureCredentialと、https://database.windows.net/をスコープとするアクセストークンを使用して、完全なパスワードレスで接続します。

Azure Kubernetes Serviceでは、個々のPodがWorkload Identity（AAD Pod Identityの後継）を使用してマネージド IDトークンを取得できます。ユーザー割り当てマネージド IDを作成し、それをAKSのOIDC発行者とフェデレーションして、Kubernetesサービスアカウントにアノテーションを付けます。するとAzure Workload Identity webhookが必要な環境変数を注入し、PodのDefaultAzureCredentialがトークンを取得できるようになります。これにより、Kubernetes Secretsオブジェクトにシークレットを保存せずに、コンテナ化されたマイクロサービスでもパスワードレス認証を利用できます。

マネージド IDの認証情報は開発者から見えませんが、すべてのトークン発行イベントとリソースアクセスイベントは記録されます。Entra IDサインインログには、マネージド IDによるすべてのトークン要求について、アクセス対象のリソース、時刻、要求の成否などが記録されます。Azure StorageのアクティビティログとKey Vaultの監査ログには、トークンを使用して実行された具体的な操作が記録されます。これらのログは、マネージド IDに関するセキュリティ監査やインシデント調査に不可欠です。

現在アプリケーションで接続文字列またはAPIキーを使用している場合は、次の3つの手順でマネージド IDへ移行します。手順1 — コンピューティングリソースでマネージド IDを有効にします。手順2 — 各対象サービス上で、そのIDに適切なRBACロールを割り当てます。手順3 — 接続文字列の代わりにDefaultAzureCredentialを使用するよう、アプリケーションコードを更新します。移行を確認したら、App Serviceの構成とKey Vaultから接続文字列を削除します。この移行は、最新のAzure SDKを使用するアプリケーションであれば、通常、コードを最小限変更するだけで完了できます。

Managed Identityには、認証情報ベースの認証と比べて、4つの主要なセキュリティ上のメリットがあります。認証情報を保存しない — 盗まれたり、誤ってコミットされたりするものがありません。自動ローテーション — Azureが基盤となる証明書を、ダウンタイムなしでローテーションします。スコープを限定した権限 — 最小権限の原則に従い、必要なRBACロールだけをIDに付与します。完全な監査証跡 — すべてのアクセス試行がEntra IDとアクセス先サービスの監査ログに記録されます。新しいAzureサービス統合では、マネージド IDを標準の認証方式にする必要があります。

このレッスンでは、マネージド IDによって Azure リソースに自動管理される Entra ID の ID が付与され、保存された認証情報が不要になること、Azure SDK の DefaultAzureCredential が Azure 上ではマネージド ID を、開発環境では開発者の認証情報を透過的に使用すること、そして対象サービスに対する RBAC ロールの割り当てによって、その ID がアクセスできる対象を制御することを学びました。次は、アプリケーションコンポーネント間の疎結合なメッセージングを実現する Azure Service Bus について学びます。