M365Con 2027 – 無料オンラインカンファレンス · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Azure マネージド ID の比較: システム割り当てとユーザー割り当て、どちらを選ぶべきか?

By ·

Azure のシステム割り当てマネージド ID とユーザー割り当てマネージド ID を比較します。管理作業の負担を減らし、安全にスケールさせるためにどちらの ID の種類を選ぶべきかを解説します。

Automatically translated with AI from the original post. Read the English original

Cover: Azure Managed Identities - Simply Explained

Azure でシステム割り当てとユーザー割り当てのマネージド ID のどちらを選ぶかは、クラウドのセキュリティと管理作業の負担の観点で、最も重要なアーキテクチャ上の判断の 1 つです。システム割り当て ID は単一の Azure リソースのライフサイクルに直接紐づく一方、ユーザー割り当て ID はスタンドアロンのエンティティとして複数のリソースで共有できます。そのため、重複するロール割り当てを大幅に減らし、自動化された環境でトークン上限がボトルネックになるのを防ぐことができます。

重要なポイント

主な違いを理解する

シークレットや接続文字列をハードコーディングしないセキュアなクラウド アプリケーションを設計し始めるとき、ワークロードが Microsoft Entra ID に対してどのように認証するかを決める必要があります。Azure には、システム割り当てとユーザー割り当ての 2 種類のマネージド ID があります。それぞれの仕組みを理解しておくと、エンジニアリング チームが多くの時間をトラブルシューティングや管理作業に費やさずに済みます。

システム割り当て ID の仕組み

システム割り当てマネージド ID は、Azure 仮想マシン、App Service、関数アプリなど、特定の Azure リソース内で直接有効にします。リソースとともに生まれ、リソースとともに消えるものと考えるとよいでしょう。仮想マシンでシステム割り当て ID を有効にすると、Azure は Microsoft Entra ID に、そのリソースと同じ名前の ID を作成します。

この方式の主な利点は、シンプルさとライフサイクルの連動です。ID はリソースに結び付いているため、仮想マシンの廃止後にディレクトリに孤立した ID が残る心配がありません。リソースを削除すると、Azure が ID を自動的に削除します。ただし、この強い結び付きは、同じアクセス許可を必要とする複数のリソースがある場合に、アーキテクチャ上の制約となります。

ユーザー割り当て ID の仕組み

一方、ユーザー割り当てマネージド ID は、まずスタンドアロンの Azure リソースとして作成します。任意の名前を付けてリソース グループ内で独立して管理し、アクセスを必要とする 1 つ以上の Azure サービスに明示的に割り当てます。特定の仮想マシンや App Service のライフサイクルに縛られないため、割り当てられたすべてのリソースを削除しても残ります。

このスタンドアロンという性質によって、クラウド アーキテクトによる大規模なアクセス管理の進め方が変わります。サーバーとデータベースの間の 1 対 1 の認証関係として扱う代わりに、ユーザー割り当て ID を使えば、複数のマイクロサービスのクラスターが 1 つの管理しやすいセキュリティ コンテキストを共有する、多対 1 の認証モデルを構築できます。

管理の負荷とロールの割り当て

2 種類の ID の実務上の違いは、大規模な環境でロールベースのアクセス制御 (RBAC) を管理するときに明確になります。ストレージ アカウント、キー コンテナー、データベースへのアクセスを ID に付与するたびに、Azure のロールの割り当てを作成する必要があります。

たとえば、企業でよくある次のような場面を考えてください。4 台の仮想マシンが、2 つの異なる Azure Storage アカウントからデータを読み取る必要があるとします。システム割り当てマネージド ID だけを使う場合、仮想マシンごとに専用の ID が必要になります。アクセスを付与するには、マシンとストレージ アカウントの組み合わせごとに、合計 8 件のロールの割り当てを設定しなければなりません。仮想マシンが 20 台に増えると、ロールの割り当ての数は指数関数的に膨れ上がり、管理が極めて煩雑になります。

一方、同じ 4 台の仮想マシンが 1 つのユーザー割り当てマネージド ID を共有すれば、必要なロールの割り当ては合計 2 件だけです。きめ細かなアクセス制御は同じまま、管理の手間はごくわずかで済みます。メンバーが退職したり、インフラを作り直したりした場合も、ディレクトリをすっきりと保つことがずっと容易になります。

アーキテクチャ上の落とし穴とエッジケース

ユーザー割り当て ID は一般に効率的ですが、種類の選択を誤ると、目に見えにくい運用上の摩擦が生じることがあります。大きな危険のひとつは、短命のコンピューティング リソースや自動スケーリング環境です。

1 日のうちに開発、テスト、コンテナー化された環境を頻繁にプロビジョニングと削除を繰り返し、システム割り当て ID を使っている場合、クリーンアップ処理が実行されるまでに、それらの ID が Microsoft Entra ID に蓄積されていきます。やがて組織は Azure のディレクトリのレート制限に達し、プラットフォームが新しいリソースの作成要求をすべて拒否するようになる可能性があります。これらの一時的なワークロードでユーザー割り当て ID を共有すれば、この落とし穴を完全に回避できます。

逆に、システム割り当て ID が力を発揮する場面は、次の 2 つの特定のシナリオです。

また、絶対的な二者択一を迫られるわけではないことも覚えておいてください。1 つの Azure リソースに、機密性の高い専用の処理向けのシステム割り当て ID と、共有の業務ワークフロー向けの 1 つ以上のユーザー割り当て ID を同時に持たせることができます。

結論

Microsoft クラウドで ID を管理するには、運用効率と厳格なセキュリティ境界のバランスを取ることが欠かせません。システム割り当て ID とユーザー割り当て ID の運用上の違いを理解すれば、管理の肥大化を招くことなく、ハードコードされた機密情報を排除し、堅牢でスケーラブルなアーキテクチャを設計できます。

トークンの発行方法、Azure Key Vault がパスワードなしで連携する仕組み、避けるべき一般的なセキュリティの落とし穴について深く知りたい場合は、専門家による知見と実践的な戦略を得るために、ポッドキャストのエピソードの完全版を聴いてください。

よくある質問

1 つの Azure リソースで、システム割り当てマネージド ID とユーザー割り当てマネージド ID の両方を使用できますか。

はい。仮想マシンや App Service などの Azure リソースは、1 つのシステム割り当て ID と 1 つ以上のユーザー割り当て ID を同時に有効にできます。これにより、専用の認証方式と共有の認証方式を組み合わせられます。

ユーザー割り当て ID を接続した Azure リソースが削除された場合、その ID はどうなりますか。

システム割り当て ID は、親リソースが削除されると自動的に削除されます。これに対し、ユーザー割り当て ID は独立したスタンドアロンのオブジェクトとして Azure に残り、管理者が明示的に削除するまで存在し続けます。

複数のリソースにまたがるほとんどのシナリオで、Microsoft がユーザー割り当て ID を推奨するのはなぜですか。

Microsoft がユーザー割り当て ID を推奨する主な理由は、管理の負荷とロールの割り当ての乱立を減らすためです。複数のコンピューティング リソースで 1 つの ID を共有すると、作成と管理が必要な RBAC の割り当ての数を大幅に減らせます。

Azure でマネージド ID を実行するのに費用はかかりますか。

いいえ、システム割り当てのマネージド ID とユーザー割り当てのマネージド ID は、どちらも Azure リソース向け Microsoft Entra ID に含まれる無料の機能です。ただし、アクセスする基盤のコンピューティングやストレージのサービスには、通常の料金が発生する場合があります。

Azure App Service Microsoft Entra ID Azure Functions

Related articles

RSS