AzureのマネージドIDは「権限」ではない｜2種類のIDとアクセス許可の違い

Azureのアプリから、ストレージに保存したファイルを読みたい。マネージドIDを有効にしたのに、アクセスできない。

このとき混ざりやすいのが、アプリがどのIDで名乗るかと、そのIDに何を許可したかです。マネージドIDを持つことだけで、すべてのAzureリソースにアクセスできるわけではありません。

マネージドIDは、アプリが使うIDの管理を助ける

マネージドIDを利用すると、対応する実行環境のアプリは、開発者が資格情報を手動で管理することなくMicrosoft Entraのトークンを取得できます。コードにアクセスキーやパスワードを直接持たせる代わりに、実行環境に関連付けたIDを使う考え方です。Microsoft Learn・概要

ただし、IDの管理が楽になることと、権限の設計が不要になることは別です。利用元のサービスがマネージドIDに対応しているか、接続先が必要な認証方法を受け付けるかも確認します。

IDの寿命は、2種類で違う

まずは、どのリソースに結び付くかを見ます。

ユーザー割り当ての「ユーザー」は、利用する人間のサインインアカウントを意味しているわけではありません。独立して用意するマネージドIDの種類の名前です。Microsoft Learn・種類と比較

図は仕組みを整理するための概念図です。

ストレージを読む例では、「名乗る」と「許可」を分ける

架空の例として、VM上のアプリがBlobデータを読む場合を考えます。

1. どのIDを使うか：アプリの実行環境に関連付けたマネージドIDを選ぶ
2. 何にアクセスするか：必要なストレージのデータと操作を決める
3. その操作が許可されているか：対象と範囲に合ったアクセス許可を確認する

MicrosoftのBlob向け説明では、IDを認証してトークンを得る段階と、要求先でアクセスを認可する段階が分かれています。Microsoft Entra IDを使ったBlobデータへのアクセスには、Azure RBACによる適切なロール割り当てが必要です。Blobの認証と認可

「IDがある」「トークンが取れた」だけでは、読みたいデータへの許可まで確認できたとは限りません。ロールと適用範囲の基本は、Azure RBACとMicrosoft Entraロールの違いで整理できます。

共有できるIDでも、何でもまとめない

同じアクセス許可が必要な複数のリソースでは、ユーザー割り当てIDを共有すると管理を整理できる場合があります。反対に、リソースごとに異なる権限や識別が必要なら、その違いを残す設計が必要です。名前が似ているから、同じ部署だから、というだけでは共有する理由になりません。Microsoft Learn・種類の選択

Microsoftは、必要な操作に絞った最小限の権限を勧めています。読み取りだけでよい例に、不必要な書き込みやサブスクリプション全体の広い権限を加えるのは避けます。

もう一つ見るのは、利用元で誰がコードを実行・変更できるかです。そのリソース上で実行するコードは、関連付けられたIDの権限を使えるため、IDへの許可と利用元の管理を切り離して考えないようにします。権限を付与する際の注意

設定する前に、三行で用途を書こう

最初のメモは、次の三つで十分です。

• どこで動くアプリが使うIDか
• どのデータに、どんな操作が必要か
• 利用元を作り直すとき、IDも一緒に変わってよいか

この三行が決まると、IDの種類とアクセス許可を別々に確認しやすくなります。実行環境の違いから整理したい場合は、VM・App Service・Functionsの違いへ。IDを作る操作や権限の付与へ進む前に、対象サービスの対応条件と組織の管理方針を確認してください。