こんにちは。イオンスマートテクノロジー株式会社（AST）でSREチームの林 aka もりはやです。
本記事ではSREチームで推進中のMicrosoft Entra ID(以後はEntra ID)を利用した各種サービスへのSSO/SCIM連携を行なっていく上で、ユーザの制御をどう行うか検討した4パターンを紹介します。自分なりに考えたものを紹介しますが、より良い考え方や違った切り口などのご意見は大歓迎です。
もしかしたら「Entra IDで各サービスの認証をするだけなのにそんなパターンある？」と思われた方もいらっしゃるかもしれません。分かりやすくするために以下の図を作成しました。ユーザおよびグループを制御するポイントが複数あることが伝わるでしょうか。
＊なお本記事で"サービス"と記載した箇所は"SaaS"や"ツール"や"プロダクト"と呼ぶ方が適切かもしれませんが記事内では"サービス"で統一します。
TL;DR
はじめに要点を説明します。
4つのユーザを制御するパターンがある
Entra IDを利用した各種サービスへのSSO/SCIM連携でユーザ認証を行う場合、ユーザを制御する方法は大きく以下の3+1パターンがあると考えました。
- "Enterprise applications"でユーザを直接コントロールする
- "Enterprise applications"の"Users & groups"に直接ユーザ追加/削除を行う
- 後述すると2と3もこの対応をグループに対して行う点は同じだが、1はユーザを直接Enterprise applicationsに紐付ける点が異なる
- Entra ID上の既存グループを利用する
- 既存のEntra IDのグループを利用し、"Enterprise applications"の"Users & groups"に既存のグループを追加し、各グループへユーザ追加/削除を行う
- 初期設定としてグループを追加した後は、基本的にはグループに対するユーザ管理のみとなる
- 新しくEntra ID上に認証先サービス用のグループを作成する
- 新規にサービス用のグループを作成し、"Enterprise applications"の"Users & groups"に新規グループを追加し、そのグループへユーザ追加/削除を行う
- 初期設定としてグループを追加した後は、基本的にはグループに対するユーザ管理のみとなる
Entra IDを使わない選択も用途によってありえるかもしれないため比較のために以下も加える。
4. Entra IDを利用せずに、サービスが備えたユーザ認証機能を利用する
認証先のサービスに応じて使い分ける
これらを検討した結果、サービスの課金体系によって2,3を使い分けるのが良いと判断しました。
具体的には
- "2. Entra ID上の既存グループを利用する"パターンは、New Relicなどの”ユーザ数によって課金が発生しないサービス”で採用
- ＊補足としてNew RelicはBasicタイプと呼ばれる参照系ユーザに対して課金は発生しない
- "3. 新しくEntra ID上にサービス用のグループを作成する"パターンは、PagerDutyなどの"ユーザ数によって明確に課金が発生するサービス"で採用
背景
当社ではシステム開発・運用を加速するためにNew RelicやPagerDutyやGitHubなど複数のサービスを導入しています。現状これらのサービスへのログインはEntra IDを利用したものや、各サービス自身が備えたユーザ認証を行なっているものもあります。
SREチームではユーザ管理の煩雑さの軽減や、統合管理によるセキュリティ向上を目的としてEntra IDによるSSO/SCIMの展開を進めています。
なおSSO(Sigle Sign-On)とSCIM(System for Cross-domain Identity Management)の違いについては以下のドキュメントがわかりやすいので興味がある方は参照してください。ざっくり表現するなら”SCIMは各サービスに対しIdentityをプロビジョンするプロトコルで、SSOの一元的なユーザ認証機能も内包するもの”です。
Entra IDのEnterprise applictaionの設定はできた
Entra IDでSSO/SCIMを行う場合、Enterprise Applicationの機能を利用します。
SAMLなどの設定を一通り終えてテストログインが終われば、後はユーザやグループをそのアプリケーションに紐づけていくだけです。
アプリケーションへユーザとグループを紐づける操作は極めて簡単です。左ペインから"Users and groups"を選択し、表示された上部のタブから"+Add user/group"を選択し、後は対象のサービスへログインを許可するユーザまたはグループを追加していきます。
例として以下の図は"morihayatest"というアプリケーションに対してユーザの私（林）が追加されています。
ユーザ制御のパターンがいくつかあることに気づく
いざEntra IDで各サービスの認証を行なっていくにあたり、そのサービスへログイン可能なユーザを制御する方法がいくつかあることに気づきました。それらは以下の通りです。
- "Enterprise applications"でユーザを直接コントロールする
- Entra ID上の既存グループを利用する
- 新しくEntra ID上に認証先サービス用のグループを作成する
比較のため、"Entra ID"を使わない従来の方法も加えます。
4. Entra IDを利用せずに、サービスが備えたユーザ認証機能を利用する
それぞれ解説していきます。
1. "Enterprise applications"でユーザを直接コントロールする
ユーザを直接Enterprise Applicationに追加する方法です。
私にとってはSSOの初期設定時にテストを目的として自分のユーザのみを追加して行うのがこちらの方法です。
メリット
この方法のメリットは以下です。
- Enterpise applicationの画面で、どのユーザが利用可能かが簡単にわかる
- ユーザ単位の細やかな制御が可能
デメリット
デメリットとしては各アプリケーションごとにユーザを登録するため、ユーザの管理が煩雑になる点です。
方法1の総評
当社のような規模になると関係者は数百を超え、協力会社の方なども含めると毎月のようにユーザの変動が発生します。そのためデメリットである煩雑さを感じる可能性が高いと判断し、この方法は早々に見送りました。
2. Entra ID上の既存グループを利用する
当社ではAzure Reposを多くのプロジェクトで活用しており、それらへのアクセス制御のために以下のようなグループがすでに存在していました。2はこれらの既存グループをEnterprise Applicationに割り当てる方法です。
- プロジェクトごとのグループ
- プロジェクトの中で役割（開発, 運用など）ごとのグループ
- 部門、協力会社など所属ごとのグループ
メリット
メリットは既存のグループを利用することで、既存のグループ運用の仕組みがそのまま利用できる点です。
「Azure DevOpsを使うために申請をしたら、ついでに関連するサービスも使えるようになって便利！」といった状況になるのはユーザも管理者もハッピーですね。
デメリット
既存に適切なグループが存在しないケースがあります。
特にサービスによっては利用人数に応じてライセンス課金が発生するため、利用するユーザを厳選したい場合に既存グループでは必要以上なユーザが含まれる場合があります。
方法2の総評
既存の資産と運用がそのまま使える点で、対象サービスがユーザ数による課金が発生しないケースで優れた方法です。当社のケースではNew RelicのBasicユーザとしてのログインをこの方法で行なっています。
なお、New Relicでもユーザ数に応じたライセンス課金が発生するFull Platformユーザについては申請による手動での対応を行なっていますが、従来のBasicユーザの追加依頼などの対応が方法2によるSCIM導入後は激減したのは良い体験でした。
3. 新しくEntra ID上に認証先サービス用のグループを作成する
2の既存グループが適用できないケースの対策として、認証先サービス用に新しくグループを作成し、そのグループへユーザを追加していく方法です。
メリット
この方法のメリットは以下の通りです。
- そのサービスを利用したいユーザをユーザ単位で制御できる
- ”グループにユーザを追加する”運用はすでに回っているため、それを活用できる
- 具体的にはTerraformでコード化されており、他チームからもPRで申請がくる文化がある
デメリット
1の方法と同様にユーザ単位での煩雑な制御になります。ただしグループへの追加自体はすでに運用が回っているため他チームにも方法を委譲できており、SREチームなどのEntra IDを管理するチームに負荷が集中することは軽減できます。
グループ名も PagerDuty-PaidUsers のようにグループ名がサービス用であることが分かる名前にしておくことも重要です。
方法3の総評
対象サービスへのログインをユーザ単位で厳密に制御しつつ、すでに運用として回っているグループ追加運用に載せることで運用負荷を軽減できる方法です。当社のケースではPagerDutyのようなユーザー数に基づくライセンス課金のサービスについてこの方法を採用しました。
4. Entra IDを利用せずに、サービスが備えたユーザ認証機能を利用する
従来の方法として各ツールの備えた認証機能を利用する方法です。
メリット
この方法のメリットは手軽であることです。大抵の場合はツール自体に招待機能があり、追加したいユーザのメールアドレスを登録するような形です。
そのためEntra IDに存在しないユーザでもサービスの利用が可能になります。
デメリット
ツール毎に管理が発生し煩雑になります。
退職や異動時の処理がツール毎に必要となるため削除やロックすべきアカウントが放置される可能性が高くなります。（定期的な棚卸しが必要なのはEntra IDも同じですが）
ログイン履歴などもEntra IDで一元的に見れず、ツール毎の機能に頼る必要があります。
Entra IDの"アプリケーションギャラリー"にも表示されないことで、ツールのURLを知らないと利用できない不便さも発生し得ます。
方法4の総評
従来の方法だけに運用の煩雑さを除けば、ユーザ管理の柔軟性があります。
ただし、Entra ID一元管理によるさまざまなメリットを考えて今後は減らしていきたいと考えています。
まとめ
以上がMicrosoft Entra IDを利用した各種サービスへのSSO/SCIM制御をどうやるかを悩んだ話です。一旦の方針としてこれらを決めましたが、今後も用途に応じてやり方を変化させていく予定です。
今回検討しなかった方法の一例を挙げると、本記事ではユーザとグループの扱いについてフォーカスしましたが、サービスによってはユーザごとの属性（PropertyとかAttributesとも呼ぶ)を認可に利用することも可能であり、Entra ID側の1つのグループの中でユーザ毎に異なる権限などをサービス側で付与することが可能です。（当社の場合はユーザの属性はシンプルな情報しかなく検討しなかった）
サービスによっては2と3を同じサービスに対して併用するケースもあるでしょうし、Entra IDを利用せずにサービス内の認証機能を直接利用した方が良いケースもあるかもしれません。セキュリティ要件が低いものはTerraformで管理せずにEntra IDの"Self-service"機能を利用してみるのも便利そうです。
こうしてより良いEntra IDの活用・適切な認証認可・運用のバランスなどを考慮しながら日々改善を進めていければと考えています。それでは皆さまEnjoy Azure！
イオングループで、一緒に働きませんか？
イオングループでは、エンジニアを積極採用中です。少しでもご興味もった方は、キャリア登録やカジュアル面談登録などもしていただけると嬉しいです。
皆さまとお話できるのを楽しみにしています！
Discussion