前回までの記事（CSP事業者の代理管理を読み解く① 、CSP事業者の代理管理を読み解く② ）ではCSP事業者の持つ代理管理権限について紹介させて頂きました。とても強い権限ですので、きちんとCSP事業者側としてもしっかり管理していくべき事項であることがご理解頂けたかと思います。
事業者側、ならびにユーザー側から守るべきポリシーなどは、公式から クラウド ソリューション プロバイダーのセキュリティに関するベスト プラクティス – Partner Center | Microsoft Docs 上げられていますので、俯瞰的な情報はそちらを参照して頂くとして、この記事では、より具体的にこの機能をこう使うと便利に実装できるよということをいくつか紹介していきたいと思います。
1.特権管理者のメンバーを管理する
当たり前といえば当たり前なのですが、CSPパートナー側のAzure ADのテナントの最上位の権限であるグローバル管理者のメンバー管理は厳密に実施する必要があります。
Partner Centerでの表示 Partner Centerから見た場合は上位の様な物になりますが、グローバル管理者はAzure AD全体で2名以上、4名以下にすることがベストプラクティス とされています。現実問題としては、グローバル管理者の権限でないとできないことも実際には少ないとは思うのですが、管理をサービス毎に分担している場合など、運用上複数人を割り当てる必要があるケースも有ると思います。
こうした場合に便利なのが、Azure ADの Privileged Identity Management (AADPIM)の機能になります。この機能を有効化すると、主に2つの点で有利な点があります。
権限を必要な時だけ有効化でき、更に理由などのエビデンスを残せる 役割を持つユーザーを監視できる（AADPIM外で割り当てられた場合に警告メールを出せる） AADPIMのロール毎の設定 常時では全体管理者を割り当てず、必要な作業の単位でそのアカウントが必要な理由、チケット番号などをエビデンスとして残しつつ、必要に応じて権限の承認などのプロセスを経て有効化、有効化期間（例えば1時間）が過ぎれば特権が削除されるという運用になります。Excelのリストで管理して定期的な棚卸しをするより楽ですし、何より安全です。
今すぐに運用を変えるのは難しいという場合でも、PIMの機能だけでも有効化するというのは有用です。この場合、既存のロールを持つユーザーは全て、AADPIM的には永続的なアクティブの割り当てとなり、ユーザビリティは変わりませんが、メンバーシップの監視は行えるようになります。週次のレポートも飛んでくるようになります。その後、必要に応じてJust-In-Timeでのロールの割り当てを実施するのが良いです。
有効化後にロールを割り当てると飛んでくるメール 2.ログを長期保存する
Partner CenterやAzure ADからは、標準で過去30日分のサインインなどの各種代理管理を含むログを閲覧/検索が可能です。
平常時は30日分あれば十分トラブルシュートなどの運用は可能かと思いますが、問題はインシデント発生時です。アカウントの漏洩などが疑われる状態となった場合に、ユーザー企業に対して説明上、現状だけでなく過去においても問題が無かったことを確認するという悪魔の証明のプロセスが走ります。
サイバー攻撃に関する各種調査で、攻撃されてから発見までの日数として半年～1年など、かなりの長さがかかることが分かっています。従って、最低でもその期間は遡って確認ができるように各種のログは保存しておくと有事の際の対応がかなり楽になります（というより、取っていないと絶望的です）。
一番簡単なのは、AzureのLog Analyticsを利用してAzure Active Directoryの AuditLogs や SigninLogs を最長である2年間保存しておくという手法です。このために、PartnerのAzure ADテナントに対して自身で持っているEAやWeb Directのサブスクリプションを作成します。MPNの特典のAzure Sponsorshipのクレジットを利用しても良いですね。
エクスポートの設定はAzure Active Directoryの [診断設定] メニューから保存するログを選択。Log Analyticsでワークスペースを選択し、[使用量と推定コスト]から[データ保有期間]でログ保持期間の設定です。（事前にLog Analyticsワークスペースは作成して、価格レベルは従量課金制に設定しておきます）
エクスポートするログの設定 ログ保持期間の設定 PartnerテナントのAzure ADを通常のMicrosoft 365の利用などと分離しているケースが多いと思いますが、その場合は記録されるログもCSPパートナーとして実施する作業に関するログのみとなりますので、せいぜい数百から多くて数千円/月の課金で済む場合がほとんどだと思います。
3.条件付きアクセスを活用してリスクを低減する
Partnerテナントのアカウントは、基本的に全ての認証に多要素認証を利用することが求められます。確かに、これでかなりの部分のリスクは低減することできますが、人がオペレーションをしている以上100%ではありません。
Azure Active Directoryの条件付きアクセスを活用すると、実際にあり得ないパターンの認証についてブロックするという自動処理を書くことができます。
例えば、24時間365日の運用管理を担っている監視センターの輪番のオペレータの方が、監視センター以外のIP（例えば自宅などから）からアクセスするケースというのは考えられません。こういったアクセスを明示的に排除するルールを作成することができます。
監視センター以外のIPからアクセスさせない条件付きアクセス これは、一見システム管理側の利点にも見えますが、個人的にこれはどちらかというと社員側を守る為の設定だと思ってます。例えば、監視センターの人間も、全顧客テナントに管理者としてアクセスできるような強すぎる権限なんて欲しくて付与されてるわけでは無いです。多要素認証があるとはいえ、ID、パスワードとスマートフォンがあったらアクセスできてしまうと考えると、業務外の環境からはアクセスされないという環境を実装することにより、心理的安全性を確保することができると思います。
4.AdminAgentsグループにJust-in-Timeで参加する
本機能はプレビュー機能となりますので、GA時に仕様が変わる、移行が必要になる、そもそも機能実装されないなどのリスクがあります。
前の項でも説明をしましたが、AdminAgentsグループは非常に強い権限を持つグループであり、常時参加していたいと思う、あるいは参加している必要がある人というのは、パートナーの中でも非常に少数であると考えられます。
現在プレビュー中ではありますが、特権アクセスグループを利用するとグループへの所属をJust-in-Timeで実施することができます。アクティブ化に理由・チケット番号の記載を要求したり、指定したメンバーの承認を必要とすることも設定できます。
特権アクセスグループの設定 特権アクセスグループの有効化には、[グループに Azure AD ロールを割り当てることができる] という設定を [はい] に設定しないといけないのですが、この設定はグループ作成時にのみ設定できる仕様になりますので、CSPのオンボード時に自動作成されるAdminAgentsグループには有効化できません。
ただ、仕様上特に明示されていないのですが、AdminAgentsはメンバーにグループを入れ子にして利用しても動作しますので、これを利用して以下のイメージで実装します。
特権アクセスグループの実装 特権アクセスグループの設定（承認の要否、チケット番号記載の有無、承認者）が異なるケースなどは、複数これらのグループを作成し、それぞれのグループをAdminAgentsグループのメンバーとして追加します。
5.低い権限でAOBOに接続する
本構成はMicrosoftサポート対象外の構成です。検証する限り、現時点で動きますが、将来的に動かなくなる、あるいはクレジットを獲得できなくなるなどのリスクが内在していることをご承知おきください。
CSP事業者の代理管理を読み解く② で記載した通り、Azureサブスクリプションを代理管理する場合は、そのユーザーは全体管理者（Azure AD）＋所有者（Azure）という最上位の権限を持つか、あるいはユーザーが明示的に削除して何も持たないかのいずれか一方という 1 か 0 かという権限所持に関する選択肢しか与えられておりません。
CSP事業者を通じたMicrosoft Azureの導入にあたり、CSP事業者に対して以下のようなリクエストが来るケースが存在しています。
Azureの管理権限だけが必要なのにAzure ADの全体管理者の権限を与えなければいけないのは大きすぎる システムの構築運用の主体は自分たちなので事業者にAzureの所有者の権限を与えるのは大きすぎる これに対して非サポートではありますが、構成可能なのが以下の通りになります。
Azure ADに対するより弱い [ヘルプデスク管理者] の権限を持っているヘルプデスクエージェントに対してAOBOを割り当てる AOBOで付与されている権限を [所有権] ではなくより弱い管理権限にする 1.に関しては、AdminAgentsへのAOBOの復活と同じ手順で、対象をPartnerのAzure ADテナントのHelpdeskAgentsに変更します。
2.に関しては、所有者権限はユーザー側に渡して、CSP事業者にはより低い権限（例えばサポートリクエスト共同作成者）を付与する形になります。クレジットの獲得できる権限 が望ましいと思いますが、技術的にはマストな要件ではないです。
両方同時にやろうとする場合は以下のコマンドとなり、PowerShellのコマンドレットでRBACを付与します。
New-AzRoleAssignment -Scope /subscriptions/[サブスクリプションID] -RoleDefinitionName "Support Request Contributor" -ObjectId [HelpdeskAgentsのオブジェクトID]
PowerShellコマンドレット これにより、Azure Portalからの見た目は以下の感じになります。
Azure PortalのIAM その後、所有者をお客様ユーザー（例えばadmin@～など）に割り振り、既存のAOBOの所有者権限を削除頂ければ作業は完了となります。
注意点ですが、AOBOの所有者権限がなくなった場合、CSP事業者側からのAzure契約の削除（Azureサブスクリプションの上位にあるAzureプランの削除の前提条件が配下のサブスクリプションが全て非アクティブであるという物があるので）ができないので、廃止の処理もできません。
正確には、AzureサポートにSRを上げて強制削除することもできるのですが、数日リードタイムが掛かってしまいます。こちらはきちんとエンドユーザーと意識を合わせておいた方が良いと思います。
6.重要なセキュリティグループのメンバーシップを監視する
AdminAgents、HelpdeskAgentsなど、ParterのAzure ADテナント内の特定のセキュリティグループのメンバーに対しては、顧客テナントに対しての強力な代理管理者権限が付与されます。
このメンバーシップ自体は単なるセキュリティグループのメンバーであるという形で実装されています。誰かがグループメンバーを変更して代理管理者権限で顧客テナントに入って何か操作をし、その後グループメンバーシップから外したとしても、単純な定期的なメンバーシップの棚卸だと気がつくことがきません。
前の2項でAzure ADのログをLog Analyticsにエクスポートすることを紹介しましたが、これをやっておけばそのログを監視することによりメンバーシップの変更を検知することができます。
グループメンバーシップを管理するAlertRule 名前 AdminAgentsグループの情報が変更されました
スコープ Azure ADの監査ログを保存しているLog Analyticsのワークスペース
検索クエリ
AuditLogs
| where Category == "GroupManagement"
| where TargetResources contains '(監視するAdminAgentsグループのObjectID)'
| where Result == "success"
アラートロジック 結果の数が 次の値より大きい 0
評価基準 期間5分 頻度5分（※より長い値でも可能）入れ子しているグループのメンバーなどを含めた完全なメンバーシップを監視することはできませんが、これで大部分の 追加/削除 に関する変更は監視することができるようになると思います。
以上、今回は実装に当たってのTIPSをいくつか紹介しました。
CSPパートナーのテナントには昨年からセキュリティ強化に向けてAzure AD Premium P2の無償ライセンスが提供中になります。折角タダで使えるのであれば、是非この機会に使い倒して頂き、便利だと思ったらエンドユーザーにも紹介・提供していけるようになれば良い流れかなと考えております。
