マルチAzureAD環境の検討（SSO編）
はじめに
AWSでは、システム全体を構成するのに複数アカウントを作成し、各アカウントに「ログ管理」「セキュリティ対策」「ユーザー管理」「サブシステムA」「サブシステムB」…と使い分けることが普通になっています。
一方Azureでは、マルチサブスクリプションはまるちAzureADと言うのは基本的に推奨されていませんでした※
そこで「AzureADのマネージドな機能を利用して、マルチAAD環境を作ってみよう」という想定で、必要な機能とその実現方式をまとめてみたいと思います。
考える機能はいくつかあると思いますが、今回は「SSO」ということでユーザープリンシパルの管理についてまとめます。
SSO
SSOとは…をググると、以下のような機能を指すようです。
「1度のユーザー認証によって、複数のシステム（アプリケーションやクラウドサービス）を利用できる仕組み」
ですので、今回は『「1つのユーザープリンシパル（≒1回のユーザー認証）」を使って、複数のAAD環境にアクセスでき、それに紐づけられたAzureサブスクリプションを操作できること』というのを要件に必要なことを考えてみます。
AAD環境構成
以下のような構成を考えます。一番左に「ユーザー管理AAD」を配置し、ここでユーザー作成・削除やグループの管理を行います。すなわち、企業における「人事情報が反映されるAAD」といった想定です。
ココで行われた構成変更が、都度作業することなく右側のAADに反映され、さらにはリソース（サブスクリプション）を操作できるようにする…というのがゴールです。
設定ポイント
番号は図中の★と一致させてます。
1:ユーザー同期
先日プレビューとなった「AADテナント間ユーザー同期」を使います。私も下記にて検証しましたが、
同期対象となるユーザーは「グループ」で制御するのが簡単そうです。
（詳細はリンク先を参照ください）
どういうユーザーをどこ環境にアクセス可能にするか？というのがSSOを考える上での最初の設計要素ですので、ここでのグループ設計がキモになります。
例えば、『Adminグループは本番環境と本番環境両方に同期し、Devグループは開発環境にのみ同期する』といった設計が考えられます。
2:動的グループ
同期されてきたユーザーを自動的にグループに所属させます。
ポイントとなるのは「動的グループ」に所属させるクエリの条件ですが、「テナント間ユーザー同期」では特定のプロパティに特定の値を設定することが可能です。
以下の記事で検討した通り、「extensionAttributeN」という属性は基本的には使われておらず、こういった用途に使えるプロパティですので、ここに「どういった種類のユーザーか」すなわち「admin/dev」「systemA用/systemB用」などを入れて同期するのが良いと考えます。
（詳細はリンク先を参照ください）
3:リソースへのアクセス権
2で作成した動的グループに対して、Azureリソースへのアクセス権を付与します。
図ではサブスクリプションを対象としていますが、場合によりリソースグループや管理グループを対象とする場合もあると思いますが、いずれにせよここで重要なのは「どのグループ」に「どういった権限を付与するか」という検討です。
少なくとも、同じ環境に対してグループAは「所有者」、グループBは「共同作成者」、グループCは「閲覧者」の使い分けだったり、システム別に権限を分離しるためにグループXはSystemX用リソースグループ、グループYはSystemY用のリソースグループ…といった権限構成を考えることになります。
4:AzureADへの権限
かなり前ですが、AzureとAzure ADに対する権限の違いについてまとめたことがあります。
全く別の設定でそれぞれ権限を割り当てることになるのですが、残念ながら2の「動的グループ」にはAzureADロール（AADに対する権限）を付与することができません。つまり、AzureADに対する権限付与は、1の同期構成を作成するユーザーなど各AADの管理者が個別に実施する必要があるということです。（ぜひアップデートによる対応を期待したいところです）
まとめ
以上の通り、マルチAAD環境で「SSO」らしきものを実現する方法をまとめてみました。
個別にユーザーを作ったり、都度ゲストユーザーを招待・作成する必要があった時代からすると、かなり管理が楽になると思います。
キモとなる「テナント間ユーザー同期」機能はまだプレビューですが、ぜひ早期GAを実現してもらいたいところです。（よろしくお願いします）。
他の「マルチAAD環境で必要な機能」も順次考えていきたいと思います！
Discussion