マネージドIDとKeyVaultの違い
マネージド ID と IMDS
マネージド ID とは「(ユーザーの操作ではなく) 稼働中の Azure サービスが Azure AD に保護されたリソースへアクセスするときの認証主体 ID」のことです。
認証主体は仮想マシン (Azure VM) だったり App Service のような Azure Managed Service だったりします。
例えば App Service で稼働しているアプリケーションが Blob Storage と連携したいが Blob Storage には匿名アクセスは許可されておらず Azure AD による認証が必要な場合、やり方の 1 つとして「App Service に記述するソースコード自体に認証情報を埋め込む」というものがあります。
ですがこれはセキュリティリスクが高い行為であり、また、パスワード等の認証情報を変更する際はソースコードも修正しなければならず、非推奨な方法です。
そこでマネージド ID の出番です。
マネージド ID を App Service に割り当てることにより、Azure VM のアプリケーションは Blob Storage への認証をマネージド ID で行います。
マネージド ID は Azure AD のユーザーアカウントのような位置付けで作られ、App Service は Azure AD から OAuth2 のアクセストークンを払い出してもらいます。app1 からのリクエストには「Blob Storage を使いたいよ」という主旨の情報が載っており、Azure AD はそれに対して「Blob Storage はこの範囲内で使っていいよ。このアクセストークンを使うんだよ。」と返してくれます。
ですがあなたはふと思うでしょう。
「Azure AD へのアクセスもその掟 (アクセス制御) の範疇だったら？」
そう、制約と誓約です。
Azure AD は様々な外部連携機能があり、Azure 以外からもアクセスすることが前提の仕組みであり、Azure AD に直接アクセスし、アクセストークンなんて重要な情報を取得できてしまったら大変です。
そこで、実際には前段に Azure IMDS (Instance MetaData Service) という仕組みが使われます。また、この IMDS へのマネージド ID の登録以外にも「Azure AD へのサービスプリンシパル (エンタープライズアプリケーション) の登録」や「RBAC の権限設定」が為されます。シーケンスは以下の通りです。
Azure AD と Azure IMDS はお互いを信頼し合います。では「app1 と IMDS はどうか」というと、そもそも IMDS 自体が Azure リソースからの全てのリクエストを受け付け処理するものなので、正確では無いと思いますが、敢えて表現するなら「 Azure IMDS が相手を一方的に信頼」するものでしょう。前提として相手が Azure リソースだと確信しています。
Azure IMDS は http://169.254.169.254 という特殊な IP アドレスを持つ Azure のマネージドサービスです。IMDS へのアクセス自体には認証がありませんが、アドレス自体が特殊であり、これでセキュリティを担保しているものと考えられます。
169.254.0.0/16 のアドレス帯は IPv4 の「リンクローカルアドレス」と呼ばれており、通常の Windows だと ping 169.254.169.254 を打つと一般エラーになります。
C:\> ping 169.254.169.254 169.254.169.254 に ping を送信しています 32 バイトのデータ: ping: 転送に失敗しました。一般エラーです。 ping: 転送に失敗しました。一般エラーです。 ...
ところが Azure VM のルート Table には 169.254.169.254/32 へのルート情報が載っており、この IP だけ通信できるように細工がされております。以下は route print コマンドで確認した結果です。
MS のサイトでもこのアドレスを「既知のルーティング不可能な IP アドレス」と表現しています。おそらく Azure ネットワーク内でも特別なルーティング処理でセキュリティを確保しているのでしょう。
KeyVault とは
ところで、Managed ID と似た仕組みで KeyVault というものがあります。
KeyVault は「Azure AD 認証による保護がされていない」ローカル認証を行う方式のサービス・アプリケーションに対応した仕組みです。目的はマネージド ID と同じく、「ソースコード自体に認証情報を含めないため」ですが、対象が違うのです。
例えば App Service がオンプレミスのデータベースサーバへアクセスするときなど、「対象サービスのローカルでの認証」を行うケースにおいては KeyVault で保護することができます。
つまり、Azure AD での認証が可能なサービスはマネージド ID により認証を行い、それが出来ないようなローカル認証のサービスは KeyVault を使う、という使い分けが良いでしょう。
あなたはまたふと思うでしょう (省略) が、KeyVault のアクセスにはマネージド ID を使うことができます。
マネージドIDとサービスプリンシパルの違い
サービスプリンシパルとは、Azure AD 上に作られる「アプリケーションに人格を持たせたもの」です。「エンタープライズアプリケーションの登録」を行うと作られます。
マネージド ID は認証元が Azure リソースの場合限定で使えるものであり、そのために Azure AD に作るものがサービスプリンシパルでした。つまり、マネージド ID の仕組みにはサービスプリンシパルが含まれます。
一方、サービスプリンシパルは Azure リソース外にも適用できますので、自作したアプリケーションを Azure AD に登録することで、Azure AD にサービスプリンシパルが作られます。
このリンク先には以下の記述があります。
マネージド ID は、本質的にサービス プリンシパルのラッパーであり、管理がより簡単になります。
なので当然、使い分けとしては「Azure リソースのサービスならマネージド ID」「Azure 外のアプリケーションならサービスプリンシパル」が良いでしょう。
まとめ
それぞれの推奨される守備範囲の例としては以下の通りになります。
| 認証元のアプリ・サービス | 認証対象のアプリ・サービス | |
|---|---|---|
| Managed ID | Azure リソース (例. AppService) | Azure リソース (例. Blobストレージ) |
| KeyVault | Azure リソース (例. AppService) | オンプレリソース (例. オンプレDB) |
| サービスプリンシパル | オンプレリソース (例. オンプレアプリ) | Azure リソース (例. Blobストレージ) |
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント