Azure Managed Identities

解決する課題

• 接続文字列や API キーをコードや構成ファイルに直書きしたくない（流出・ログ漏えいのリスク）
• シークレットのローテーション・有効期限管理を運用から外したい
• VM や App Service などのアプリが、Key Vault・Storage・SQL Database へ資格情報なしで認証したい
• 「誰が・どのリソースとして」アクセスしたかを Entra ID のサインインログで監査したい

主要概念と用語

• マネージド ID（Managed Identity）: Azure リソースに付与される、自動管理されるサービスプリンシパル。アプリは資格情報を保持せず、ローカルのトークンエンドポイント経由で Entra ID のアクセストークンを取得する
• システム割り当て（System-assigned）: 対象リソース（VM など）と一蓮托生の ID。リソースを作ると生成され、リソースを削除すると一緒に消える。1 リソースにつき 1 つ
• ユーザー割り当て（User-assigned）: リソースから独立した単独のリソースとして作成する ID。複数のリソースに同じ ID を共有でき、リソースを消しても ID は残る
• サービスプリンシパル: テナント内でアプリや ID を表す実体。マネージド ID は Entra ID 側ではサービスプリンシパルとして表現される
• トークンエンドポイント（IMDS / metadata endpoint）: リソース内部からアクセスできる固定アドレス。アプリはここへ問い合わせてアクセストークンを受け取る
• RBAC ロール割り当て: マネージド ID に対して「どのリソースに何ができるか」を与える設定。ID 自体は認証を担い、認可は Azure RBAC が担う

仕様・制限・クォータ

• 対応リソースが限定的: VM / VMSS、App Service / Functions、AKS、Logic Apps、Container Apps など、多くの主要サービスが対応するが、すべてのサービスが対応するわけではない
• システム割り当ては 1 リソースに 1 つ。ユーザー割り当ては 1 リソースに複数アタッチでき、その場合はトークン取得時にどの ID を使うか明示する必要がある
• トークンには有効期限があるため、ライブラリ側でキャッシュと自動更新を行うのが一般的
• テナントをまたいだ利用はできない。マネージド ID はそのリソースが属するテナント内でのみ有効
• 資格情報のローテーションは Azure が自動で実施し、利用者がキーを管理することはない

内部の仕組み

アプリは、リソース内部からアクセスできるローカルのトークンエンドポイントにトークンを要求します。要求を受けた基盤が Entra ID に対して認証を行い、対象リソース向けのアクセストークン（JWT）を返します。アプリはそのトークンを Authorization ヘッダーに載せて Key Vault や Storage などの API を呼びます。

• アプリ自身はシークレットを一切保持しない。資格情報の保管・更新・破棄はプラットフォームが担う
• 取得したトークンは短命で、ライブラリ（Azure Identity SDK の DefaultAzureCredential など）が裏でキャッシュと再取得を行う
• 呼び出し先の API は受け取ったトークンを検証し、Azure RBAC のロール割り当てに基づいて認可する
• Entra ID 側ではマネージド ID はサービスプリンシパルとして現れ、サインインログに利用が記録される

設計パターン / ベストプラクティス

• 接続文字列や API キーはマネージド ID + Key Vault に置き換える。シークレットのハードコードを排除する
• アプリのコードは DefaultAzureCredential 等の標準ライブラリを使い、ローカル開発と本番（マネージド ID）で同じコードを動かす
• 複数リソースで共通の権限を使うならユーザー割り当て ID を 1 つ作り、各リソースへアタッチして運用を集約する
• ロール割り当ては最小権限に絞る。サブスクリプション全体ではなく、対象リソースやリソースグループのスコープに限定する
• ID とロール割り当ては IaC（Bicep / Terraform）で管理し、誰が何にアクセスできるかをコードで追跡可能にする

運用・監視

• Entra ID のサインインログで、マネージド ID（サービスプリンシパル）の認証イベントを監査する
• 呼び出し先（Key Vault など）の診断ログと突き合わせ、想定外のアクセスを検知する
• ロール割り当ての棚卸しを定期的に行い、不要になった権限や孤立した ID を除去する
• ユーザー割り当て ID はリソースを消しても残るため、未使用 ID の放置に注意する
• 403 / 認可エラー時は、ロール割り当て・スコープ・対象リソースの対応を順に確認する

コスト

マネージド ID 自体の利用に追加料金は発生しないのが基本です。費用は、アクセス先サービス（Storage の操作、Key Vault のトランザクションなど）側で通常どおり発生します。資格情報管理を肩代わりさせることで、シークレット管理に伴う運用コストを下げられる点が実質的なメリットです。

セキュリティ

• シークレットを保持・配布しないため、流出・ログ漏えいの面が大きく縮小する
• 資格情報のローテーションが自動で、有効期限切れや古い鍵の放置による事故を防げる
• Entra ID 認証 + Azure RBAC に統一でき、アクセス制御と監査の一元化が進む
• ローカル開発時に本番の ID を流用しない。開発者の ID と本番のマネージド ID を環境ごとに分離する

Well-Architected の観点

• セキュリティ: 資格情報をコードから排除し、Entra ID 認証と RBAC に集約。攻撃面とシークレット管理の負担を同時に減らせる。最小権限のロール割り当てと組み合わせることで、防御の土台になる

試験で問われるポイント

関連サービス・比較

マネージド ID は、AWS で EC2 にロールを割り当てる仕組みに最も近い概念です。

ハンズオン / CLI例

# VM にシステム割り当てマネージド ID を有効化
az vm identity assign \
  --name demo-vm \
  --resource-group demo-rg

# その ID のプリンシパル ID を取得
PRINCIPAL_ID=$(az vm show \
  --name demo-vm \
  --resource-group demo-rg \
  --query identity.principalId -o tsv)

# Key Vault のシークレット読み取りロールを ID に付与（最小権限）
az role assignment create \
  --assignee "$PRINCIPAL_ID" \
  --role "Key Vault Secrets User" \
  --scope "$(az keyvault show --name demo-kv-0614 --query id -o tsv)"

# 共有用のユーザー割り当て ID を作成し、VM にアタッチ
az identity create --name shared-id --resource-group demo-rg

az vm identity assign \
  --name demo-vm \
  --resource-group demo-rg \
  --identities shared-id