Azure Managed Identity入門｜パスワードレスでAzureリソースを安全に連携するマネージドID実践ガイド

クラウドに移行したのに、接続文字列やAPIキーをアプリのコードに直書きしている——そういうケースは、まだ現場に根強く残っている。オンプレ時代のサービスアカウントをそのままクラウドに持ち込む感覚で運用してしまうと、キーのローテーション漏れや誤ってGitにコミットしてしまう事故が起きる。

Azure Managed Identity（マネージドID）は、この問題を設計レベルで解決してくれる機能だ。Azureのリソース（App ServiceやVMなど）に対してIDを自動付与し、そのIDがMicrosoft Entra IDの認証基盤を使ってほかのAzureリソースにアクセスできるようになる。パスワードやシークレットをアプリ側が一切持たなくていい。

この記事では、Managed Identityの仕組みと2種類のID、そしてApp ServiceからKey Vaultへシークレットをパスワードレスで取得する実践手順を順を追って解説する。Azure VMやAKSにも同じ考え方が使えるので、まずApp Serviceで基礎を固めてほしい。

なぜManaged Identityが必要なのか

オンプレのサービスアカウントと何が違うのか

オンプレでは、アプリがDBや他システムに接続する際、専用のサービスアカウント（例: svc_myapp）を作ってパスワードを発行し、configファイルや環境変数に書いておくのが一般的だった。これ自体は正攻法だが、次のような運用リスクを常に抱えている。

・パスワードのローテーション忘れ: 「1年ごとに変えるルール」が形骸化し、何年も同じパスワードを使い続けるケースが多い
・秘密情報の拡散: 本番のconfigを開発環境にコピーした結果、意図せず機密情報が広がる
・Gitへの誤コミット: .envファイルを誤ってリポジトリにプッシュしてしまうインシデントは絶えない

Azureクラウドでも同じ手法をそのまま使おうとすると、同じリスクを持ち込むことになる。Managed Identityはこれを「そもそもパスワードを持たせない」という発想で解決する。

Managed Identityの仕組み

仕組みを大まかに説明すると、次の流れになる。

①AzureリソースにManaged IDを有効化する（例: App Service）
②そのリソースはMicrosoft Entra IDにサービスプリンシパルとして自動登録される
③アクセス先のリソース（例: Key Vault）に「このManaged IDにシークレットの読み取りを許可する」というロール割り当てを設定する
④アプリコードがシークレットにアクセスしたい時、AzureのIMDSエンドポイントからトークンを自動取得する
⑤そのトークンでKey VaultのAPIを呼び出し、シークレットを取得する

この流れのなかで、アプリコードが「パスワード」「クライアントシークレット」を直接保持する場面はゼロだ。トークンの取得・更新はAzureプラットフォームが自動的に処理してくれる。

2種類のManaged Identityを理解する

Managed Identityには「システム割り当て」と「ユーザー割り当て」の2種類がある。用途に応じて使い分けることが重要だ。

使い分けの基本方針: まず「このアプリ専用のIDでいい」という場合はシステム割り当てが手軽だ。一方、複数のApp Serviceインスタンスや複数のAzure FunctionsがKey Vaultに同じ権限でアクセスする場合は、ユーザー割り当てでIDを共通化するとロール設定の管理が楽になる。

基本的な使い方 — App ServiceからKey Vaultへの接続

最も典型的なユースケースとして「App ServiceのWebアプリからKey Vaultのシークレットをパスワードレスで取得する」手順を具体的に示す。

1. App ServiceのManaged Identityを有効化する

Azureポータルで対象のApp Serviceを開き、「設定」→「ID」に移動する。「システム割り当て済み」タブの「状態」を「オン」に切り替えて「保存」を押すだけだ。

# Azure CLIで有効化する場合（APP_SERVICE_NAMEとRESOURCE_GROUP_NAMEを置き換えて実行）
az webapp identity assign \
  --name  \
  --resource-group 

# 出力例（principalIdがEntra IDのサービスプリンシパルID）
{
  "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "tenantId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy",
  "type": "SystemAssigned"
}

出力された principalId を控えておく。次のステップで使用する。

2. Key VaultへのRBAC（ロール割り当て）を設定する

対象のKey Vaultを開き、「アクセス制御 (IAM)」→「ロールの割り当て」で「追加」をクリックする。「キー コンテナー シークレット ユーザー」ロールを選択し、メンバーとして手順1で作成したManaged ID（App Serviceと同名）を指定する。

# Azure CLIで設定する場合
KEY_VAULT_NAME="mykeyvault"
PRINCIPAL_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"  # 手順1のprincipalId

az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee-object-id $PRINCIPAL_ID \
  --assignee-principal-type ServicePrincipal \
  --scope $(az keyvault show --name $KEY_VAULT_NAME --query id -o tsv)

Key Vaultのアクセスモデルには「アクセスポリシー（旧方式）」と「Azure RBAC（推奨）」の2種類がある。新規環境では必ずRBAC方式を選ぶこと。ポータルのKey Vault設定で「アクセスポリシー」ではなく「Azure ロールベースのアクセス制御」が選択されているかを確認しておこう。

Azure Key Vaultの詳細な設定についてはAzure Key Vault入門｜シークレット・キー・証明書を一元管理する実践ガイドも参考にしてほしい。

3. アプリコードでシークレットを取得する

Python（azure-identity + azure-keyvault-secrets）を例に示す。コード内に認証情報は一切出てこない点が重要だ。

# pip install azure-identity azure-keyvault-secrets
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

# DefaultAzureCredentialはManaged Identity → Azure CLI → 環境変数の順で自動選択
credential = DefaultAzureCredential()

key_vault_url = "https://mykeyvault.vault.azure.net/"
client = SecretClient(vault_url=key_vault_url, credential=credential)

# シークレット名を指定して値を取得（パスワード不要）
secret = client.get_secret("db-connection-string")
print(secret.value)

DefaultAzureCredential が優秀で、App Service上ではManaged Identityを自動的に使い、ローカル開発環境ではAzure CLIのログイン情報を自動的に使ってくれる。コードを環境ごとに切り替える必要がなく、CI/CDパイプラインや他の環境でもそのまま動く。

App ServiceのKey Vault参照機能を使う（コード変更なし）

実はコードを一行も書かずにKey Vaultのシークレットを環境変数として利用できる方法がある。App Serviceのアプリケーション設定（環境変数）で、値を次の書式で指定するだけだ。

# アプリケーション設定の「値」欄に以下の書式で指定する
@Microsoft.KeyVault(VaultName=mykeyvault;SecretName=db-connection-string)

# または SecretUri を直接指定する方法
@Microsoft.KeyVault(SecretUri=https://mykeyvault.vault.azure.net/secrets/db-connection-string/)

App Serviceの起動時にKey Vaultから値が自動解決され、通常の環境変数としてアプリに渡される。既存アプリへの適用に特に有効で、コードに一切手を加えずにパスワードレスを実現できる。ポータルのアプリケーション設定画面でこの書式で値を入力し、保存してアプリを再起動するだけで動作する。

その他のユースケース

Managed IdentityはApp Service専用の機能ではない。Azure上のほぼあらゆるコンピューティングリソースに適用できる。

・Azure VM: VMからAzure Blob StorageやSQL Databaseにパスワードレスでアクセスする。VM上で動くスクリプトやデーモンに有効だ
・Azure Functions: イベントトリガーで動く関数からKey Vaultや他のAPIに安全に接続する
・Azure Kubernetes Service（AKS）: Workload Identityという仕組みでPodレベルのManaged Identityが使える。Podごとに異なる権限を付与できる
・Azure Data Factory: データパイプラインのリンクサービス設定でManaged Identityを指定できる
・Azure Logic Apps: ワークフローからストレージやDBに接続する際の認証に利用できる

料金の仕組み

Managed Identity自体の利用料金はかからない。無料で使える機能だ。

ただし間接的なコストには注意が必要だ。Managed Identityを活用することで、Key VaultへのAPIコール数が増加する場合がある。Key VaultはAPIコール数に応じて課金される（2026年7月時点、スタンダードティアで10,000回あたり約$0.03 USD）。シークレットを毎リクエストで取得するような実装にすると、コールが積み重なる。

実務的な対処法は、アプリケーション起動時に一度シークレットを取得してメモリにキャッシュするか、前述のApp ServiceのKey Vault参照機能を使うことだ。後者はプラットフォームがキャッシュを自動管理するため、コールが最小限に抑えられる。

応用・実務Tips

① Azure Policyで有効化を強制する
セキュリティ基準として「全App ServiceはManaged Identityを有効化すること」をポリシーで強制できる。Azure Policy入門の「audit」または「deny」効果を使ってリソース作成時に自動チェックが走るようにしておくと、設定漏れを防げる。

② ローカル開発環境での動作確認
DefaultAzureCredentialはローカルでは az login したAzure CLIセッションを自動で使う。開発者が自分のAzureアカウントでログインしていれば、同じコードでローカル実行が可能だ。ただし、本番環境と同じKey Vaultを使うと誤操作のリスクがあるため、開発用Key Vaultを別途用意することを推奨する。

③ ユーザー割り当てIDの共有管理
複数のApp ServiceやAzure FunctionsがKey Vaultに同じ権限でアクセスする場合、ユーザー割り当てManaged IDを1つ作り、各サービスに割り当てると管理が集約できる。ロールの追加・削除もManaged ID側の操作1回で完結する。

④ Managed IDのアクセスログを確認する
Key VaultのAzure Monitor診断ログを有効化しておくと、どのManaged IDがいつシークレットにアクセスしたかをLog Analyticsで追跡できる。セキュリティ監査の証跡として有効だ。

よくあるトラブルと対処法

Q. DefaultAzureCredentialでトークン取得に失敗する（認証エラー）
まずApp Serviceの「ID」設定でManaged Identityが「オン」になっているか確認する。次にKey VaultのIAMでロール割り当てが正しく設定されているかを確認する。ロール割り当てが反映されるまで最大で数分かかるため、設定直後のエラーは数分待ってから再試行するとよい。

Q. アクセスポリシーで設定したのにアクセスできない
Key VaultのアクセスモデルがRBACになっているのにアクセスポリシーを設定しようとした場合、設定が反映されない。ポータルのKey Vault「設定」→「アクセス構成」でアクセスモデルを確認し、モデルに合った方法で権限を付与すること。

Q. App ServiceのKey Vault参照が「Invalid」と表示される
原因として多いのは①書式ミス（スペースや余分な文字の混入）、②Managed Identityが無効、③Key Vault側のロール設定が不足の3点だ。App Serviceの「構成」→「アプリケーション設定」でステータスアイコンをクリックすると、エラーの詳細が確認できる。

Q. ユーザー割り当てIDを削除したら他のサービスへの接続が切れた
ユーザー割り当てManaged IDを複数サービスで共有していた場合、そのIDを削除するとすべてのサービスが認証エラーになる。削除前に、そのIDがどのリソースに割り当てられているかをポータルの「使用中のリソース」タブで確認してから作業すること。

本記事のまとめ

Azure Managed Identityは、クラウドでのサービス間認証を「パスワードを持たせない」設計に変えるための重要な機能だ。

オンプレのサービスアカウント管理では当たり前だった「パスワード管理の手間とリスク」を、Managed Identityはプラットフォームレベルで消し去ってくれる。Microsoft Entra IDの認証基盤についてはMicrosoft Entra ID（旧Azure AD）入門も合わせて読んでほしい。

まずは手元のApp ServiceひとつにManaged Identityを有効化し、Key Vault参照の動作確認から始めてみよう。設定にかかる時間はポータル操作で5分もあれば十分だ。