前回の記事では、CSP事業者の2種類の代理管理権限であるDAPとAOBOについて紹介しましたが、今回は、それらに関してもう少し具体的な実装方式について書いていきたいと思います。

前回も一部紹介しましたが、これらの代理権限はCSPパートナーのAzure ADテナントと顧客のAzure ADテナントの間で今の図のようなイメージで構成されます。

まず、CSPパートナーでは、Partner Centerから各ユーザーに対して役割を付与すると、裏でAzure AD上にCSPプログラムのOn-Board時に作成されたそれぞれに対応したセキュリティグループに所属されます。その後、顧客側テナントでは以下の流れで実装されます。

1. 顧客とのCSP事業者の関係づけをすると、顧客テナントに対して、パートナーテナントの特定のセキュリティグループ（AdminAgentsならびにHelpdeskAgents）が顧客側テナントの外部プリンシパル(Foreign Principal)として追加されます。
2. DAPを有効化するとこれらに顧客のAzure ADテナントの全体管理者、ヘルプデスク管理者の役割が割り当てられます。
3. Azureサブスクリプションを作成すると、AOBOの権限としてAdminAgentsが所有者として設定されます。

参考までに、パートナーテナントには基本的にAzure AD Premium P2のライセンスが付いていてリスクベースの認証が有効化されてます。また、多要素認証なしでの認証だと代理管理権限が行使できないようにも設計されているので、パートナーテナント側のユーザーはシステム的にきちんと守られていますので、その点は安心できる要素かなと思います。

この辺りの実装が分かっていると事象の説明がしやすいFAQがあるので、いくつか紹介します。

Q1.CSPのパートナーです。Partner Centerからヘルプデスクエージェントの役割を与えたユーザーが、M365のサポートリクエストは上げられるのですがAzureのサポートリクエストが上げられません、それどころかAzureサブスクリプションすら見えません。
A1.ヘルプデスクエージェントはAzureADに対してのヘルプデスク管理者の権限は有していますが、Azureサブスクリプションに関する権限は持っていません。Azureを管理する必要がある場合は管理エージェントグループに所属させて下さい。

Q3.お客様要望で、現在他のCSPパートナーで利用しているM365とAzureのサブスクリプションを自社のCSPに譲渡（リセーラー変更）しました。移行完了の連絡が来たのですが、M365は見えますがAzureは何も見えません。また、Microsoftからの請求額が少し高いように見えます。
A3.Azureの代理管理のAOBOの権限はAzureのRBACとして実装されておりますが、サブスクリプションを別の事業者に移譲した場合でも変更されず、従来のCSPパートナーのみが権限を持っている状態となります。
適切に移行するには、移行を実施する前に、旧パートナーあるいはお客様によって新パートナーに対するAOBOの権限を設定し、移行完了後に不要となった旧パートナーの権限を削除する必要がございます。
なお、このAOBOの設定を行わない場合、新パートナーにはクレジット（PEC）が支払われませんので、その意味からも移行前に正しく設定を行っておくことを推奨します。

Q4.お客様はM365をMicrosoftのEnterprise Agreementを通じて調達されており、自身で管理をしています。CSP事業者としてAzureサブスクリプションを提供することになったのですが、Azureのみを管理するのでAzure ADの管理権限は不要と判断し、AOBOを残してDAPを削除したらお客様のAzureにアクセスできなくなりました。
A4.Azureへのアクセスは、Azureサブスクリプションの権限の他に適切なAzure ADに帯する権限（最低限Directory Reader）も必要となります。DAPを削除した場合、お客様Azure ADテナントに対しての権限が無くなってしまうので、AOBOの他にDAPも継続して割り当てが必要となります。

Q5.Azure AD Premiumの条件付きアクセスの機能で自テナントの管理者の役割に対して各種アクセス制限を実装しています。CSPパートナーが外部ネットワークからのアクセスとなるので、条件付きアクセスでCSPの代理権限の時のみ外部ネットワークのアクセスが可能なようにポリシーを記載したいのですが。
A5.パートナーのアカウントはForeign Principalとして実装されており、これはAzure ADのアクセス制御で対象を特定するために利用できる「ユーザーまたはグループ」「ワークロードID（プレビュー）」ではないため、利用できません。パートナーアクセスはIPアドレスなど別の情報を識別情報として利用し、そのアクセスに対しては条件付きアクセスでブロックされない（[MFAを要求する]のアクションは可能）よう設計する必要があります。