Role Based Access Control for Applications を使用すると、Microsoft Graph のアプリケーションのアクセス許可を使用して Exchange Online のメールボックスに接続するアプリに対して、どのメールボックスの何のデータに対してのアクセスを許可するかを Exchange Online の管理者側から制御することができます。従来はアプリケーションのアクセス許可が Azure AD で与えられ、そのアプリはすべてのメールボックスに接続が可能となり、そのようなアプリが特定のメールボックスにしか接続できないようにするには追加で Exchange Online の Application Access Policy を構成する必要がありました。Role Based Access Control for Applications ではそれ単体でアプリに対してどのメールボックスの何のデータにアクセスすることを許可するか制御できます。また、名前の通り Exchange Online の Role Based Access Control (RBAC) として設定ができます。
この記事では実際に Role Based Access Control for Applications を構成する手順を紹介します。詳しい手順は Role Based Access Control for Applications in Exchange Online を参照してください。
エンタープライズ アプリケーションの用意
まずアクセス許可を与える対象となるアプリの情報を用意する必要があります。アプリも接続先も同じテナントに存在するシナリオを想定している場合はアプリの登録の手順を行ってください。他テナントでマルチテナント アプリとして既に登録されているアプリを使用するシナリオを想定している場合はエンタープライズ アプリケーションの登録の手順を行ってください。
アプリの登録
あとでアプリケーションのアクセス許可が使用できるような内容であれば、お好きな内容でアプリの登録をすれば問題ありません。本来、アプリの開発者が登録を行います。参考として登録手順の例を記載しておきます。
- Azure Portal にサインインします。
- [Azure Active Directory] – [管理] – [アプリの登録] – [新規登録] をクリックします。
- [名前] に任意のアプリの名前を入力します。(例 : RbacTest01)
- [サポートされているアカウントの種類] から [任意の組織ディレクトリ内のアカウント (任意の Azure AD ディレクトリ – マルチテナント)] を選択します。
- [リダイレクト URI] で [Web] を選択し、任意の URI を入力します。(例 : https://localhost/RbacTest01)
- [登録] をクリックします。
- 表示された [アプリケーション (クライアント) ID] の値を控えておきます。
- [管理] – [証明書とシークレット] – [クライアント シークレット] をクリックします。
- [新しいクライアント シークレット] をクリックします。
- [説明] に任意の説明を入力します。(例 : Key1)
- [有効期限] から任意の有効期限を選択します。(例 : 推奨: 180 日 (6 か月))
- [追加] をクリックします。
- 表示されたクライアント シークレットの値を控えておきます。
- Azure Active Directory ブレードのトップに移動します。
- [管理] – [エンタープライズ アプリケーション] をクリックします。
- 一覧から先ほど登録したアプリを探して [オブジェクト ID] の値を控えておきます。
エンタープライズ アプリケーションの登録
すでにアプリが他テナントでマルチテナント アプリとして登録されている場合、そのアプリのアプリケーション (クライアント) ID を自テナントにエンタープライズ アプリケーションとして登録します。手順は Create an enterprise application from a multi-tenant application in Azure Active Directory に記載されています。
登録したら Azure Portal の [管理] – [エンタープライズ アプリケーション] から登録したアプリを探して [オブジェクト ID] の値を控えておきます。
スコープの定義
アプリが接続可能なメールボックスを、Exchange Online の Management Scope もしくは Azure AD の Administrative Unit として定義します。すでに定義済みであればそれを使用できます。参考としてそれぞれの作成方法を記載しておきます。
Exchange Online の Management Scope の作成
例として Department が HR であるメールボックスだけにアクセスを許可したい場合は、Exchange Online に接続した PowerShell で以下のようにコマンドを実行して Management Scope を作成します。
実行例)
New-ManagementScope -Name "HrManagementScope" -RecipientRestrictionFilter "Department -eq 'HR'"
Azure AD の Administrative Unit の作成
Create or delete administrative units と Add users, groups, or devices to an administrative unit を参考に、アクセスを許可したいメールボックスだけが含まれる Administrative Unit を作成してください。
作成後、Exchange Online に接続した PowerShell で Get-AdministrativeUnit コマンドを実行して Administrative Unit が取得できることを確認してください。取得出来たら Name の値を控えておきます。
Service Principal の作成
Exchange Online にアプリの情報を Service Principal として登録します。Exchange Online に接続した PowerShell で以下のようにコマンドを実行してます。
New-ServicePrincipal -AppId <アプリのアプリケーション (クライアント) ID> -ObjectId <エンタープライズ アプリケーションの画面で確認した、アプリのオブジェクト ID> -DisplayName <任意のアプリの名前>
実行例)
New-ServicePrincipal -AppId b2361178-2067-444b-82d7-e8c57e6bac67 -ObjectId 0392f3d6-ad56-4381-bab8-57b585524856 -DisplayName RbacTest01
アクセス許可の設定
Application Management Role として、アプリにアクセスを許可する内容を設定します。Management Scope を使用する場合と Administrative Unit を使用する場合で、それぞれ以下のようにコマンドを実行します。サポートされるアクセス許可の内容は Supported Application Roles に記載があります。
New-ManagementRoleAssignment -Role <アクセス許可の内容> -App <アプリのアプリケーション (クライアント) ID> -CustomResourceScope <作成した Management Scope>
New-ManagementRoleAssignment -Role <アクセス許可の内容> -App <アプリのアプリケーション (クライアント) ID> -RecipientAdministrativeUnitScope <作成した Administrative Unit の Exchange Online での Name>
実行例)
New-ManagementRoleAssignment -Role "Application Mail.Read" -App b2361178-2067-444b-82d7-e8c57e6bac67 -CustomResourceScope "HrManagementScope"
New-ManagementRoleAssignment -Role "Application Mail.Read" -App b2361178-2067-444b-82d7-e8c57e6bac67 -RecipientAdministrativeUnitScope 5af01861-ca3f-481d-844e-4e8ea07877d9
テスト コマンドでのテスト
Test-ServicePrincipalAuthorization コマンドを使用することで、アプリに与えられたアクセス許可の確認をすることができます。
以下のように Resource にテスト対象のメールボックスを指定して実行した場合、そのアプリが与えられているアクセス許可でそのメールボックスに対して接続可能かどうかをテストできます。実行結果の InScope の値が True であれば接続可能で、False であれば接続不可です。
Test-ServicePrincipalAuthorization -Identity <アプリのアプリケーション (クライアント) ID> -Resource <テスト対象のメールボックス>
実行例)
Test-ServicePrincipalAuthorization -Identity b2361178-2067-444b-82d7-e8c57e6bac67 -Resource User01
以下のように Resource を指定せずに実行した場合、そのアプリに与えられているアクセス許可の情報が表示されます。InScope は Not Run と表示されます。
Test-ServicePrincipalAuthorization -Identity <アプリのアプリケーション (クライアント) ID>
実行例)
Test-ServicePrincipalAuthorization -Identity b2361178-2067-444b-82d7-e8c57e6bac67
実際の Microsoft Graph でのアクセスのテスト
設定は以上で完了です。実際の Microsoft Graph でのアクセスをテストします。アプリを自テナントで登録している場合は Microsoft Graph の試し方の「[アプリケーションの許可] を Office365APIEditor で試す」を参考に、動作を確認できます。アプリが他テナントでマルチテナント アプリとして登録されている場合は、アクセス トークンの取得に必要な情報が分からないはずなので、開発者が用意したアプリで実際の動作を確認する必要があります。
アクセスが許可されていないメールボックスに接続すると 403 のステータス コードと以下の body が返されます。
{
"error": {
"code": "ErrorAccessDenied",
"message": "Access is denied. Check credentials and try again."
}
}参考
Role Based Access Control for Applications の GA 直後の情報です。今後の改善で動作が変わる可能性があります。
- 一通り設定し、実際にアクセス トークンを取得した後であっても、Azure Portal で当該エンタープライズ アプリケーションの [セキュリティ] – [アクセス許可] を見ても Role Based Access Control for Applications で設定したアクセス許可の情報は見ることはできません。
- Azure AD 側でアクセス許可の設定を追加で行っていなければ、role が含まれていないアクセス トークンが発行されて、それを使用することになります。つまりアクセス トークンからはどのようなアクセス許可が Role Based Access Control for Applications で設定されているか分かりません。