Azure上でアプリケーションを構築する際、アプリケーションが別のAzureリソースへアクセスするケースは多くあります。
例えば以下のようなケースです。
- Azure App Service → Azure Key Vault
- Azure App Service → Azure Blob Storage
- 仮想マシン → Azure SQL Database など。
このときに問題になるのが、 認証情報（ID、パスワード、シークレットなど）をどう管理するか です。
認証情報を利用した認証方式ですと、認証情報をどこかで能動的に管理する必要がありました。
プログラムに埋め込む、プログラムから読み込める場所にファイルとして置いておく、環境変数に書いておく、などが考えられます。
しかしそれらは、操作ミスによる情報漏洩、期限切れなどの問題を引き起こすリスクを抱えていました。
そこで生まれたのが マネージドID による認証方式です。
認証情報を利用した認証方式
例えば、仮想マシンからAzure Blob Storageへアクセスする際は、アクセスキーやSASキーなどのシークレット情報を用いてアクセスしていました。
マネージドIDを使用した認証方式
一方、マネージドIDを使用した認証方式では、シークレット情報の入力は必要ありません。
仮想マシンが、自身のマネージドIDを使用して認証を行います。
マネージドIDの概念
マネージドIDを作成すると、内部的にサービスプリンシパルが作成されます。
※詳細は割愛しますが、サービスプリンシパルとは、RBAC（ロールベースアクセス制御）による、「誰がリソースにアクセスしてよいか」を識別するためのIDです。
Microsoft Entra ID上にサービスプリンシパルが自動生成され、そのサービスプリンシパルをAzureリソースに紐づけて利用しています。
マネージドIDは 「サービスプリンシパル」を自動管理してくれる仕組み 、と言えるかと思います。
また、中身がサービスプリンシパルということは、アクセス制御（IAM）におけるロールの割り当て対象として選択することもできます。
例えば、冒頭で例に挙げたAzure App Service → Azure Key Vaultへのアクセスにおいては、認証元であるAzure App ServiceのマネージドIDを有効化しておき、有効化したマネージドIDに対して、Azure Key Vaultを管理するロールを付与することで、Azure App ServiceからAzure Key Vaultの操作が可能になります。
このように 「Azureリソース」をユーザーのごとく扱える 、という点もメリットと言えると思います。
マネージドIDを利用できるAzureリソースは、すでに挙げた仮想マシンやAzure App Serviceの他にも、Azure AutomationやAzure Event Hubsなど、多岐にわたるサービスやリソースで利用可能です。
マネージドIDを使用した認証フロー
ではこのマネージドIDを使用して、実際にどのような順番で認証が行われているか、上で示した、仮想マシンからAzure Blob Storageへのアクセスを例に記載します。
出典：ここで、「Azure Instance Metadata Service（IMDS）」が登場していますが、仮想マシンのメタデータを管理してくれているAzureの内部コンポーネントと捉えてください。
IMDSは、仮想マシンの内部からのみアクセス可能なコンポーネントとなっており、「どの仮想マシンから来た通信か」をネットワークレベルで識別できます。
そのため、「信頼できる仮想マシンからのトークン要求」と判断し、Microsoft Entra IDにトークンの要求を行います。
このような流れで取得したトークンを用いて、最終的に仮想マシンからAzure Blob Storageへのアクセスを行います。
このようにして、シークレットを用いずに、「Azure内部で抱えている識別情報のみで完結する」認証方式が、マネージドID認証となります。
今回はAzureのマネージドIDを利用した認証について解説しました。
シークレット情報の管理が不要になるため、アプリケーション実装時におけるAzureリソースの認証方法は、できる限りマネージドID認証で行うのがセキュアでメンテナンス性の高い設計に繋がると考えています。
