Microsoftは先頃の声明で、Azure Active Directory(AD)ベースのService Busアクセス制御の一般供用を開始すると発表した。これにより、ユーザIDとRBAC(Role Based Access Control)を組み合わせて、サービスのエンドポイントを認証するオプションが利用可能になる。この目的で使用するRBACロールも同時に導入しており、付与するアクセス許可をきめ細かく制御することができる。
従来のAzure Service Busにおける認証の優先オプションは、トークン発行者とService Bus双方に既知の対称キーである共有アクセス署名を使用して、キュー、トピック、サブスクリプションへのアクセスを提供する方法だった。結果として、開発者がこれらをアプリケーション内に直接実装することになるため、多くの場合において、ソースコードや構成ファイルにトークンがハードコーディングされていた。もうひとつのオプションは、トークンを発行するセキュリティトークンサービス(STS)を用意して、Active Directory認証を使ってSTSに対してアプリケーションを認証する方法だった。しかし、この方法では、アプリケーションの構造が複雑になると同時に、そのためのコンポーネントを開発し、メンテナンスする必要があった。それらに代わってAzure AD機能を導入することで、Active Directoryのユーザやグループだけでなく、サービスプリンシパルあるいはManaged Service Identity(MSI)もIDとして使用可能になる。MSIを実装することで、ADがアプリケーションまたはサービスのIDを生成して、Key VaultやAzure Storage、そして今回のService Busなど、サポート対象のサービスに対する認証に使用するようになる。特筆すべきは、これら機能の追加によって、認証の実装に資格情報やトークンが不要になったことだ。これについては、Azure MVPのJoonas Westlin氏が、いくつかのメリットがあることを説明している。
来年になれば、これらの機能を有効にするサービスがさらに増えることは間違いありません。それによって、アプリ内のどこにも資格情報が保存されない状態に、さらに近づくことになります。資格情報を管理したり、保護したりする必要はありません。
さらに、Active Directory機能を組み込むことによって、クライアントは、認証の実行に使用するデバイスや場所などでIDを制限する条件付きアクセスの使用など、サービスが提供する特別な機能を使用できるようになる。認証を求めるクライアントがAzure ADに対してアクセストークンを要求し、それがService Busエンティティに送信される要求に含めて渡される。より明確には、これがIDのRBACロールに応じて、データ送受信などの特定の権限を決定する。この方法により、Azureサブスクリプション全体から特定のService Busエンティティに至るまで、さまざまなスコープでこれらの特権を付与することができる。詳細はドキュメントに説明されている。
- キュー、トピック、あるいはサブスクリプション — ロールの割り当ては、特定のService Busエンティティに適用される。現時点でのAzureポータルは、ユーザー/グループ/管理対象IDのService Bus RBACロールへの割り当てを、サブスクリプションレベルではサポートしていない。
- Service Bus名前空間 — ロールの割り当ては、名前空間の下のService Busのトポロジ全体と、それに関連付けられたコンシューマグループに及ぶ。
- リソースグループ — ロールの割り当ては、リソースグループ下のすべてのService Busリソースに適用される。
- サブスクリプション — ロールの割り当ては、サブスクリプション内のすべてのリソースグループ下の、すべてのService Busリソースに適用される。
リソースへのロールの割り当ては、Azure PowerShell、Azure CLI、Azure Resource Managerテンプレートのいずれかを使用すれば可能である。アタッチ後から設定が反映されるまでは、最大で5分かかる場合がある。それば終われば、クライアントアプリケーションは、そのIDを使用してリソースに対する認証を行うことが可能になる。
出典： https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-managed-service-identity