Skip to content

MS_AzureManagedID

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 2 revisions

Azure Managed ID

概要

補足（「何が簡単になるのか？」への答え）: 原文が自問しているこの点が、
マネージド ID の存在意義そのものである。

【サービス プリンシパル（SPN）】
  ① Azure AD にアプリを登録する
  ② シークレット（または証明書）を発行する
  ③ それをアプリの設定ファイル / Key Vault に置く   ← 秘密が生まれる
  ④ 有効期限が来たら更新する                        ← 忘れると止まる

【マネージド ID】
  ① リソースで「マネージド ID を有効にする」
  ② そのプリンシパル ID に RBAC ロールを付ける
  （以上。秘密が存在しない）

つまり**「秘密を持たない」ことが本質**である。
漏洩・ローテーション・失効という 3 つの問題が構造的に消える。
AKSクラスタ作成・操作に必要な権限 で
「SPN 方式は 1 年後に突然壊れる」と述べたのは、まさにこの ④ の話。

補足（最新化）: 現在の呼称は
Microsoft Entra マネージド ID である。

補足（「仮想アカウント的」という喩えについて）: この喩えは的確である。
どちらも「パスワードを管理しなくてよい、リソースに紐づいた ID」であり、
資格情報のライフサイクルをプラットフォームが面倒を見る。

  • 仮想アカウント — マシン アカウントの資格情報を使う
  • マネージド ID — Azure プラットフォームが証明書を管理・ローテーションする

gMSA がドメイン環境で解いた問題を、
Azure で解いたものと考えるとよい。

詳細

用語

紐付け ≒ 関連エンティティの ID 的な。

クライアント ID

Azure AD によって生成される ID

プリンシパル ID

補足（2 つの ID の使い分け）: 混同しやすいので整理する。

ID 何に使うか
クライアント ID（アプリケーション ID） コード側でトークン取得時に「どの ID か」を指定する（ユーザー割り当ての場合に必須）
プリンシパル ID（オブジェクト ID） Azure 側で RBAC のロール割り当て先として指定する

「ロールを付けたはずなのに 403 になる」場合、
プリンシパル ID を間違えているか、
ユーザー割り当てなのにクライアント ID を指定していないのが典型。

Azure Instance Metadata Service (IMDS)

  • クライアント ID に対する証明書が登録される。

  • クライアントに、access_token を返す。

    • クライアントを識別し、
    • Azure AD に問い合わせ、
    • access_token を返す。

補足（IMDS の実体）: IMDS は
169.254.169.254 というリンクローカル アドレスで待ち受ける
ローカル エンドポイントで、そのマシンからしかアクセスできない。

アプリ ──HTTP──▶ http://169.254.169.254/metadata/identity/oauth2/token
                      │ （プラットフォームが本人確認）
                      ▼
                  access_token
                      │
                      ▼
             Key Vault / Storage / SQL Database

「秘密を持たずに認証できる」のは、
VM の外からは絶対に到達できない経路でトークンを配るためである。
逆に言えば、SSRF 脆弱性でこの URL を叩かれると危険なので、
Web アプリでは外部入力による URL アクセスに注意が要る
（IMDS 側も Metadata: true ヘッダーを必須にして対策している）。

SSRF への対策としては、次の 3 点を押さえる。

  • IMDS 側の保護として、Metadata: true ヘッダーの付与が
    必須になっている（リダイレクトも不可）
  • アプリ側で外部から与えられた URL を取得しない設計にする
  • マネージド ID に与える RBAC は最小限にする
    （盗まれた場合の被害範囲がそのまま権限範囲になる）

なお、実装ではこの URL を直接叩く必要はない。
Azure Identity ライブラリ（DefaultAzureCredential）が
環境に応じて自動的に処理する。

// ローカル開発では Visual Studio / Azure CLI の資格情報、
// Azure 上ではマネージド ID を自動で使い分ける
var client = new SecretClient(
    new Uri("https://<名前>.vault.azure.net/"),
    new DefaultAzureCredential());

種類

システム割り当てマネージド ID

Azure サービス インスタンス上で直接有効にされる。

  • この ID を有効にすると、Azure によって、

    • そのインスタンスのサブスクリプションの
      Azure AD テナントに対し、対応するインスタンスの
      「システム割り当てマネージド ID」が作成される。

    • 「システム割り当てマネージド ID」が作成されると、
      その資格情報がインスタンスにプロビジョニングされる。

  • 「システム割り当てマネージド ID」のライフ サイクルは、

    • 「システム割り当てマネージド ID」が有効にされた
      Azure サービス インスタンスに直接関連付けられる。

    • インスタンスが削除された場合、Azure は

      • Azure AD の資格情報
      • 「システム割り当てマネージド ID」

      を、自動的にクリーンアップする。

ユーザー割り当てマネージド ID

スタンドアロン Azure リソースとして作成される。

  • 作成プロセスで、
    使用されているサブスクリプションの Azure AD テナントに、
    Azure が「ユーザー割り当てマネージド ID」を作成する。

  • 作成された「ユーザー割り当てマネージド ID」は、
    1 つまたは複数の Azure サービス インスタンスに割り当てることができる。

  • 「ユーザー割り当てマネージド ID」のライフ サイクルは、
    Azure サービス インスタンスのライフサイクルとは個別に管理される。

補足（どちらを選ぶか）: ライフサイクルの違いが選択基準になる。

システム割り当て ユーザー割り当て
ライフサイクル リソースと一蓮托生（消すと消える） 独立（リソースを作り直しても残る）
共有 1 リソース 1 ID 複数リソースで共有可能
ロール割り当て リソース作成のたびに必要 一度付ければ使い回せる
向く場面 単発・小規模 IaC で作り直す構成、スケールアウトする構成

ARM テンプレート や Bicep で環境を作り直す運用では、
システム割り当てだと作り直すたびにロール割り当てが失われる
（新しい ID が生成されるため）。
したがって、エンタープライズでは
ユーザー割り当てを先に作り、そこにロールを付けておく方が扱いやすい。

一方、VMSS のようにインスタンスが増減する場合も、
ユーザー割り当てなら 1 つの ID を共有できる。

用例

コチラに併記

参考

本 Wiki 内

Microsoft Learn

移行メモ（重複ページの統合）: 本ページは、同一の元ページが
MS_AzureManagedIdentity と MS_AzureManagedID の
2 つのファイル名で二重に移行されていたものを統合した結果である。
元ページ名（Azure Managed ID）に合わせて
MS_AzureManagedID を残し、
MS_AzureManagedIdentity 側の固有記述
（仮想アカウント / gMSA との対比、
SSRF 対策の具体策）を取り込んだうえで当該ファイルを削除し、
参照元のリンクを本ページへ張り替えた。

Tags: 移行, セキュリティ, アカウント, クラウド, 認証基盤, Azure, Active Directory

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally