Azure のマネージド ID は、Azure リソースで実行されているアプリケーションの資格情報を安全かつ便利に管理する方法を提供します。 この記事では、ユーザー割り当てマネージド ID とシステム割り当てマネージド ID の選択に関するベスト プラクティスの推奨事項について説明します。これにより、ID 管理を最適化し、管理オーバーヘッドを削減できます。
システムまたはユーザー割り当てのマネージド ID を選択する
ユーザー割り当てマネージド ID のほうが、システム割り当てマネージド ID より広範なシナリオにおいて効率的です。 一部のシナリオと、ユーザー割り当てまたはシステム割り当てに関する推奨事項については、次の表を参照してください。
ユーザー割り当て ID は複数のリソースで使用できます。そのライフ サイクルは、関連しているリソースのライフ サイクルと切り離されています。 どのリソースがマネージド ID をサポートしているかについてお読みください。
このライフ サイクルによって、リソースの作成と ID 管理の責任を分離することができます。 ユーザー割り当て ID とそのロールの割り当てを、それらを必要とするリソースより先に構成できます。 リソースを作成するユーザーが必要とするのは、ユーザー割り当て ID を割り当てるアクセス権だけです。新しい ID やロールの割り当てを作成する必要はありません。
システム割り当て ID はリソースと共に作成および削除されるので、ロールの割り当てを前もって作成することはできません。 このシーケンスによって、リソースを作成しているユーザーがロールの割り当てを作成するアクセス権も持っていない場合、インフラストラクチャのデプロイ中にエラーが発生する可能性があります。
インフラストラクチャで複数のリソースが同じリソースへのアクセスを必要とする場合は、1 つのユーザー割り当て ID をそれらに割り当てることができます。 管理する個別の ID とロールの割り当てが少なくなるため、管理オーバーヘッドが削減されます。
各リソースがそれぞれの ID を持つことが必要な場合、あるいは一意のアクセス許可セットを必要とするリソースがあり、リソースが削除されたときに ID も削除したい場合は、システム割り当て ID を使用する必要があります。
| シナリオ | 推奨 | 注記 |
|---|---|---|
| マネージド ID を使用したリソースの迅速な作成 (エフェメラル コンピューティングなど) | ユーザー割り当て ID | 複数のマネージド ID を短時間で作成しようとした場合 (たとえば、独自のシステム割り当て ID を持つ複数の仮想マシンをそれぞれデプロイする場合) は、Microsoft Entra オブジェクトの作成のレート制限を超える可能性があり、要求は HTTP 429 エラーで失敗します。 リソースを迅速に作成または削除している場合、システム割り当て ID を使用していると Microsoft Entra ID 内のリソース数の上限を超える可能性もあります。 削除されたシステム割り当て ID はリソースからアクセスできなくなりますが、30 日後に完全に消去されるまで制限にカウントされます。 1 つのユーザー割り当て ID に関連付けられているリソースをデプロイするには、Microsoft Entra ID でサービス プリンシパルを 1 つだけ作成する必要があります。この場合、レート制限は回避されます。 事前に作成された 1 つの ID を使用すると、複数のリソースがそれぞれ独自の ID で作成された場合に発生する可能性のあるレプリケーション遅延のリスクが軽減されます。 詳細については、Azure サブスクリプション サービスの制限に関するページを参照してください。 |
| レプリケートされたリソースおよびアプリケーション | ユーザー割り当て ID | 同じタスクを実行するリソース (重複した Web サーバーや、アプリ サービスと仮想マシン上のアプリケーションで実行されている同一の機能など) には、通常、同じアクセス許可が必要です。 同じユーザー割り当て ID を使用することで、必要なロールの割り当てが少なくなり、管理オーバーヘッドが減ります。 リソースは、種類が同じである必要はありません。 |
| コンプライアンス | ユーザー割り当て ID | 組織で、すべての ID の作成が承認プロセスを通過する必要がある場合、複数のリソースで 1 つのユーザー割り当て ID を使用すると、新しいリソースが作成されると作成されるシステム割り当て ID よりも承認が少なくなります。 |
| リソースがデプロイされる前に必要なアクセス権 | ユーザー割り当て ID | リソースによっては、デプロイの一環として特定の Azure リソースへのアクセスが必要になる場合があります。 この場合、システム割り当て ID は時間内に作成されない可能性があるため、既存のユーザー割り当て ID を使用する必要があります。 |
| 監査ログ | システム割り当て ID | どのリソース (ID でない) がアクションを実行したのかをログ記録する必要がある場合は、システム割り当て ID を使用します。 |
| アクセス許可のライフサイクル管理 | システム割り当て ID | リソースのアクセス許可がリソースと共に削除されるようにしたい場合は、システム割り当て ID を使用します。 |
ユーザー割り当て ID を使用した管理の削減
図は、システム割り当て ID とユーザー割り当て ID を、複数の仮想マシンが 2 つのストレージ アカウントにアクセスするために使用したときの違いを示しています。
この図は、システム割り当て ID を持つ 4 つの仮想マシンを示しています。 それぞれの仮想マシンには、2 つのストレージ アカウントへのアクセスを許可する同じロールの割り当てがあります。
ユーザー割り当て ID が 4 つの仮想マシンに関連付けられている場合、必要となるロールの割り当ては 2 つだけなのに対して、システム割り当て ID では 8 つが必要です。 仮想マシンの ID により多くのロールの割り当てが必要な場合は、この ID に関連付けられているすべてのリソースに付与されます。
セキュリティ グループを使用して、必要となるロールの割り当ての数を減らすることもできます。 この図は、システム割り当て ID を持つ 4 つの仮想マシンを示しています。この仮想マシンはセキュリティ グループに追加され、ロールの割り当てはシステム割り当て ID ではなくグループに追加されています。 結果は似ていますが、この構成では、ユーザー割り当て ID と同じ Resource Manager テンプレート機能が提供されません。
複数のマネージド ID
マネージド ID をサポートするリソースは、システム割り当て ID と、1 つ以上のユーザー割り当て ID の両方を使用できます。
このモデルには、共有のユーザー割り当て ID を使用し、しかもきめ細かいアクセス許可を必要に応じて適用できる柔軟性があります。
次の例では、"Virtual Machine 3" と "Virtual Machine 4" は、認証時に使用するユーザー割り当て ID に応じて、ストレージ アカウントとキー コンテナーの両方にアクセスできます。
次の例では、"Virtual Machine 4" にはユーザー割り当て ID の両方があり、認証時に使用される ID に応じて、ストレージ アカウントとキー コンテナーの両方にアクセスできます。 システム割り当て ID のロールの割り当ては、その仮想マシンに固有です。
制限
マネージド ID の制限と、カスタム ロールとロールの割り当ての制限をご覧ください。
アクセス権を付与する場合は最小特権の原則に従う
マネージド ID を含む任意の ID にサービスへのアクセス許可を付与する際は、常に目的のアクションを実行するために必要な最小限の権限を付与するようにします。 たとえば、マネージド ID を使用してストレージ アカウントからデータを読み取る場合、その ID アクセス許可がストレージ アカウントにデータを書き込むのを許可する必要はありません。 追加のアクセス許可を付与する (たとえば、不必要であるに、も関わらず、マネージド ID を Azure サブスクリプションの共同作成者にするなど) と、その ID に関連するセキュリティの影響範囲が大きくなります。 その ID が侵害された場合の被害が最小限になるように、セキュリティの影響範囲は常に最小にする必要があります。
Azure リソースにマネージド ID を割り当てる、またはユーザーに割り当てアクセス許可を付与することによる影響を考慮する
Azure ロジック アプリや仮想マシンなどの Azure リソースにマネージド ID が割り当てられると、マネージド ID に付与されたすべてのアクセス許可が Azure リソースで使用できるようになることに注意してください。 もし、あるユーザーがこのリソースにコードをインストールまたは実行するアクセス権を持っている場合、そのユーザーはその Azure リソースに割り当てられている、または関連付けられているすべての ID へのアクセス許可を持っていることになるため、これは重要なことです。 マネージド ID の目的は、開発者がアクセスを得るために資格情報の処理を行ったり、これをコードに直接挿入したりすることなく、Azure リソース上で実行されるコードに他のリソースへのアクセス許可を与えることです。
たとえば、マネージド ID (ClientId = 1234) に StorageAccount7755 への読み取り/書き込みアクセス権が付与され、 LogicApp3388 に割り当てられている場合、ストレージ アカウントへの直接アクセス権を持たないが、 LogicApp3388 内でコードを実行するアクセス許可を持つ Alice は、マネージド ID を使用するコードを実行することで 、StorageAccount7755 との間でデータの読み取り/書き込みを行うこともできます。
同様に、Alice が自分でマネージド ID を割り当てるアクセス許可を持っている場合は、それを別の Azure リソースに割り当て、マネージド ID で使用できるすべてのアクセス許可にアクセスできます。
一般的に、コードを実行でき (Logic App など)、マネージド ID を持つリソースに対する管理者権限をユーザーに付与する際には、そのユーザーに割り当てられるロールを使ってリソース上でコードをインストールまたは実行できるかどうかを考慮し、そうである場合は必要な場合にのみ、そのロールを割り当てるようにします。
メンテナンス
システム割り当て ID は、リソースが削除されると自動的に削除されます。一方、ユーザー割り当て ID のライフサイクルは、それが関連付けられているリソースとは無関係です。
リソースが関連付けられていない場合でも、ユーザー割り当て ID が不要になったら、手動で削除する必要があります。
ロールの割り当ては、システム割り当てまたはユーザー割り当てのマネージド ID のいずれかが削除されたときに、自動的には削除されません。 これらのロール割り当ては手動で削除して、サブスクリプションごとのロール割り当ての制限を超えないようにする必要があります。
削除されたマネージド ID に関連付けられているロールの割り当ては、ポータルで表示されると "ID が見つかりません" と表示されます。 詳細については、こちらを参照してください。
ユーザーまたはサービス プリンシパルに関連付けられていないロールの割り当ては、ObjectType の値が Unknown として表示されます。 それらを削除するために、パイプを使用していくつかの Azure PowerShell コマンドを結合できます。最初に、すべてのロールの割り当てを取得し、ObjectType という Unknown 値が付いたものにのみフィルターを適用した後で、Azure からそれらのロールの割り当てを削除します。
Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment
認可にマネージド ID を使用する場合の制限
サービスへのアクセスを許可するために Microsoft Entra ID グループを使用するのは、認可プロセスを簡素化するための優れた方法です。 発想はシンプルです。アクセス許可をグループに付与し、ID をグループに ID を追加して、それらの ID が同じアクセス許可を継承するようにします。 これは、さまざまなオンプレミス システムで採用されている十分に確立されたパターンであり、ID がユーザーを表す場合は適切に機能します。 Microsoft Entra ID で認可を制御するためのもう 1 つのオプションは、アプリ ロールを使用することです。これにより、(ディレクトリ内のグローバル概念であるグループではなく) アプリに固有のロールを宣言できます。 その後、(ユーザーやグループだけではなく) マネージド ID にアプリ ロールを割り当てることができます。
どちらの場合も、Microsoft Entra アプリケーションやマネージド ID などの人間以外の ID の場合、この認証情報をアプリケーションに提示する方法の正確なメカニズムは、現在理想的には適していません。 Microsoft Entra ID や Azure ロールベースのアクセス制御 (Azure RBAC) を使用する現在の実装では、Microsoft Entra ID によって発行されるアクセス トークンを各 ID の認証に使用します。 グループまたはロールに追加された ID は、Microsoft Entra ID によって発行されたアクセス トークン内のクレームとして表されます。 Azure RBAC ではこのクレームを使用して、アクセスを許可または拒否するための認可ルールをさらに評価します。
ID のグループとロールがアクセス トークン内の要求であるため、承認の変更はトークンが更新されるまで有効になりません。 通常は問題とならない人間のユーザーの場合、ログアウトして再度ログインすれば (または、トークンの有効期間が切れるのを待つ (既定では 1 時間) と)、新しいアクセス トークンを取得できるためです。 一方、マネージド ID のトークンは、パフォーマンスと回復性を確保するために、基盤の Azure インフラストラクチャによってキャッシュされます。マネージド ID のバックエンド サービスでは、リソース URI ごとのキャッシュを約 24 時間保持します。 これは、マネージド ID のグループまたはロール メンバーシップの変更が有効になるまでに数時間かかる可能性があることを意味します。 現時点では、有効期限が切れる前にマネージド ID のトークンを強制的に更新することはできません。 そのため、マネージド ID のグループまたはロールのメンバーシップを変更してアクセス許可を追加または削除する場合には、ID を使用する Azure リソースに適切なアクセス権が付与されるまでに、数時間の待ち時間が発生することがあります。
この遅延が要件に対して許容できない場合は、トークンでグループまたはロールを使用する代わりの方法を検討してください。 アクセス許可を持つマネージド ID の追加または削除を Microsoft Entra ID グループに対して行う代わりに、マネージド ID のアクセス許可の変更が速やかに有効になるよう、アクセス許可が ID に直接適用されるユーザー割り当てマネージド ID を使用して Azure リソースをグループ化することをお勧めします。 ユーザー割り当てマネージド ID は、1 つ以上の Azure リソースに割り当てて使用できるため、グループのように使用できます。 割り当て操作は、マネージド ID 共同作成者およびマネージド ID オペレーターのロールを使用して制御できます。