はじめに
システム本部デベロッパーエクスペリエンス室（以下DevX室）の三谷です*1
DevX室では部門名の通り、開発者体験に関する施策を展開しており、その一環としてシステム本部内で共通して利用するSaaS製品の管理・運用を行なっております。
今回はそのなかでも特に重要なアカウント管理について、
コミュニケーションツールのMicrosoft TeamsをSaaS製品の管理に利用するアプローチで、以下を実現できたという事例をご紹介したいと思います。
| 製品種別 | SaaS用Teamsにメンバー追加 | SaaS用Teamsからメンバー削除 | Teamsアカウント(Azure ADアカウント)が削除/無効化 | 備考 |
|---|---|---|---|---|
| SSO対応製品 | ログイン権限付与 (SaaS側でログイン時にアカウントが自動作成される設定) |
ログイン権限はく奪 | ログイン権限はく奪 | ログイン権限がはく奪された後のSaaS側アカウントの削除/無効化は手動 |
| SSO＆SCIM対応製品 | SaaS側アカウント作成 | SaaS側アカウント削除/無効化 | SaaS側アカウント削除/無効化 |
実際に利用しているTeamsのチームはこんな感じで👇それぞれのチームメンバーがSaaS利用者となっています。
なお、現在契約している製品はシングルサインオン（以下SSO）がサポートされていたため、
認証部分に関しては会社で導入済みのMicrosoft Entra ID(Azure AD)*2との連携を実施している前提となります。
背景
現在、アカウントの払い出しについては以下のような運用フローを採っています。
- 社内のワークフローシステムで利用者が申請を上げる
- SaaS管理部門で申請を確認し、払い出しを行なう （←我々の部門が担当）
DevX室では複数のSaaS製品の管理を行なっており、今後もさまざまなSaaS製品の契約が増え続けることが予想されていました。
それに伴い、アカウントの管理（追加や削除、棚卸し）についても対応する機会が増えていくことがわかっていたため、管理にかかるコストをどうにか削減できないか検討していました。
特に退職者のアカウントがログインできる状態で残り続けると問題になりうるので、そういったセキュリティリスクへの対応も含めて検討を進めました。
課題感
アカウント管理の作業としては製品に依らず、だいたい以下のような対応になるかと思います。
- 各製品の管理画面にログインする
- 管理画面よりアカウントを払い出す/変更する
文章で書くとそこまで大変ではないように見えますが、課題感としては2点ありました。
①製品ごとにアカウントの管理方法が異なる
各製品の画面構成が異なるため、アカウント管理画面へのアクセス方法も異なります。
また、アカウントの払い出し方法についても以下のようにさまざまなパターンがありました
- 管理画面から招待メールを送信
- 管理画面から招待メールを送信し、その後ユーザーが承認
- ユーザーがアカウントを作成後にアカウントと権限を紐づける
これらの差異はそもそも別製品なので致し方ない部分なのですが、
運用側としては毎回異なる製品にログインをしたうえで、さらにアカウントの払い出し方法も異なるのでなかなか煩雑でした。
特に申請があまりない製品については、手順を見つけたり思い出すのに時間がかかることもありました。
②アカウントの払い出しに製品の管理権限が必要
基本的にアカウントの管理は高い権限が要求されるため、どの製品も管理画面へのアクセスを許可する必要があります。
つまり製品管理者がアカウント管理者を兼務するということになりますが、
例えばアカウントの管理だけを切り出して別な方にお願いするといったことはしづらく、不必要に管理画面全般を操作できる権限を与えざるを得ないという課題がありました。
解決策
上記の課題を解決するために、以下の方針で解決策を検討しました。
- できるだけアカウント管理画面へのアクセスを減らす
- 何か特別な運用が増えないようにする
できるだけアカウント管理画面へのアクセスを減らす
すでに連携済みであったSSOに加えて、当時は利用していなかったSystem for Cross-domain Identity Management(SCIM)を利用することでEntra IDアカウントの同期を実現することにしました。
SSOについても当時の設定では社内の人間であれば全員がSSO可能で、SaaS製品側でログインできるユーザーを限定するという運用になっていたため、こちらについても適切に見直しを行ないました。
以下参考までに導入済みのSaaS製品と製品レベルでのSSO/SCIMの対応状況をまとめておきます（2023/8現在）。
| 製品名 | SSO | SCIM | 備考 |
|---|---|---|---|
| Wrike | ⭕ | ⭕ | |
| GitHub | ⭕ | ⭕ | OpenID Connect(OIDC)のSSOもサポートされている |
| Confluence | ⭕ | ⭕ | Atlassian AccessがSSO/SCIMを担う |
| Opsgenie | ⭕ | ⭕ | Atlassian AccessがSSO/SCIMを担う |
| Jira Software | ⭕ | ⭕ | Atlassian AccessがSSO/SCIMを担う |
| mabl | ⭕ | ❌ | メールによる招待が必要 |
| oVice | ⭕ | ❌ |
何か特別な運用が増えないようにする
もともとSaaS製品の利用周知のためTeamsにSaaS単位でチームを作成しており、アカウント払い出し後に手動でメンバー追加する運用を行なっておりました。
・・・ということで「はじめに」で触れたフローだけは実はすでに実現していたのですが、
当時は自身にTeams含むMicrosoft 365製品ファミリーに関する知見がそこまでなく、管理する社内部門も異なっていたため、
Teamsのチーム作ると勝手にSharePointサイトが作成されたりしてConfluenceあるのに邪魔だなー（失礼）というレベル感でした。
現在も所謂 "完全に理解した" レベルですが、Teamsのチームの裏側にはEntra ID上で管理されている「Microsoft 365グループ（旧Office 365グループ）」があり、
グループを作成するための機能やメンバー追加のUIがMicrosoft 365製品（TeamsやSharePoint）の中(※)にあり、
各製品がそのグループに紐づくメンバーに対して製品固有の機能やサービスを提供する（Teamsであればチーム、SharePointであればサイト）関係性であると理解しました。
※もちろん「Microsoft Entra 管理センター」からも作れます
我々の既存運用上、SaaS製品ごとのTeamsにメンバーを追加しており、それが実態としてMicrosoft 365グループにメンバーが追加されるという挙動になっていたため、
実はEntra ID上にSaaS製品の管理用の適切なグループが作成されていたのです。
そのためSSO（エンタープライズアプリケーション）の設定を進める際に、利用対象者をグループで絞り込むことができるため、このグループを利用することにしました。
Teamsにメンバーを追加するためにはチームの管理者権限が必要ですが、それさえできればアカウントの払い出しもできる！製品への管理権限を渡すよりはリスクも少ない！
その結果、選ばれたのはTeamsによるアカウントの管理でした🍵
Teamsによるアカウント管理のメリット・デメリット
メリット
課題感で挙げた問題の解決に加えて、Teamsで管理することによってこれらのメリットも享受できます。
SaaS製品の利用者 ＝ Teamsのメンバーとなるため管理が容易
誰が利用者であるかの確認はTeamsチームのメンバーを見ればすぐにわかりますし、検索機能も付いています。
また、チームの管理者でなくてもメンバーの一覧は確認できるため、利用者側もメンバーを確認できるので管理者に確認する必要もなくなります。
ほかにもチーム内のチャネルを利用して製品に関する周知もできますし、質問チャネルなどを作成すればそちらで利用者とのやり取りも可能です。
特に周知に関してはSaaS製品では稼働状況（ダウンタイム）の情報を共有することが多いため、利用者だけにダイレクトに通知を届けることができます。
Microsoft 365製品間の連携が可能
SharePointでSaaS製品のドキュメントの公開が可能
ドキュメント管理のメインはConfluenceですが、一部アカウントがないケースもあるため、その方々に向けてSaaS利用のドキュメントをSharePointで公開しています。
こちらも標準でドキュメントの公開範囲がTeamsのチームに所属する方へ限定されるので、必要な方々へ適切にドキュメントを公開できます。
Power Automateを活用して連携が可能
Teamsのチームにメンバーが追加されるというイベントをトリガーに、
Power Automateを利用して通知を送ることが可能です。
現在はメンバー追加のお知らせをTeamsへ通知するようにしていますが、
そのメッセージとともにオンボーディング用のドキュメントを合わせて送ることで、追加された方はそれを参照して学習を進めることが可能です。
デメリット
考えうるデメリットですが、現状では以下の2点が挙げられます。
個人的にはそこまで大きくないと思っていますが、ご参考までに。
大量にユーザーを追加しづらい
チームにメンバーを追加するUI上は一度に大量のユーザーを追加はしづらく、CSVでインポートするような機能もありません。
その場合はAzure Active Directory でのグループ メンバーの一括追加を利用する必要があります。
また、Teamsの制約上「チームのメンバー数」は25,000までとなるため、それ以上のアカウント管理は行なえないことにも注意が必要で、これ以外にもTeams側の制約が足かせになる可能性にも留意が必要です。
ユーザー追加・削除時のUIが変わらないので誤追加・誤削除しやすい
「製品ごとにアカウントの管理方法が異なる」の逆になるのですが、
Teamsのメンバー追加画面はどのチームであっても同じ作りなため、アカウント払い出しの際は別製品であってもTeamsにメンバーを追加するという操作になります。
UI上「～にメンバーを追加」という表示はされるため、追加対象の製品名であることを確認しながら追加する必要があります。
実現にあたっての壁
当時の制約として、Microsoft 365グループをエンタープライズアプリケーションに割り当てできないという壁がありました（セキュリティグループのみ割り当て可能）。
現在は公式にサポートされていますが、当時は以下のように使えそうだけど使ってよいのか、という記事があるように使っていいのかわからない状態でした。
Why can some MS 365 groups be added to Enterprise Apps and others can't?
そのため、Microsoft 365グループ → セキュリティグループへの同期を行なったうえでエンタープライズアプリケーションに割り当てをすることにしました。
同期とは言っても、そのために何らかのアプリケーションを作りこむことはしたくなかったので、プレビュー版(※)ではありますが動的グループのグループメンバーシップ機能を活用しました。
※プレビュー版の信用度 >>> ドキュメント非掲載の機能の信用度ということで利用してます
手順は省略しますが、"セキュリティグループ側"に以下のような動的なクエリを追加します。
user.memberof -any (group.objectId -in ['同期元のMicrosoft 365 グループのオブジェクトID'])
この設定を行なうことで、Microsoft 365グループにメンバーが追加されると、セキュリティグループにもメンバーが追加されるようになります。
結果的には直接Microsoft 365グループを割り当てできるようになったためこの手順は不要となりましたが、後述するグループが複数存在する場合においては利用箇所があるため、こちらで紹介させていただきました。
実現方法
SSO
冒頭でも触れましたが、SSOについては構成済みでしたので、SSOできるユーザーを限定する設定を追加しました。
Teamsのチームの裏側にある該当のMicrosoft 365グループをアプリケーションにユーザーとグループを割り当てるの手順に沿って設定します。
上記の手順が完了次第、Azure AD アプリを Azure AD テナントの一連のユーザーに制限するに沿って、割り当ての設定をはいへ変更します。
設定後、グループに入っていない方がログインを行なった場合、エラーコード AADSTS50105が発生します。
注意としてはエンタープライズアプリケーションの作成時ではなく、途中から上記の変更を加える場合、
実はSaaSユーザーだったけど割り当てしたグループに入ってなかったのでログインできなくなった！！というケースが発生する可能性があるため、
設定する際はSaaS側の利用者一覧とMicrosoft 365グループの突合を行なってから設定を入れることを推奨します。
SCIM
SSOの設定が完了したら、次はSCIMの設定を行ないます。
なお、SCIMに対応していない製品に関しては、SSOの設定のみで完了となりますが、
SaaS製品側とアカウントの同期が行なわれないため、アカウントの削除や無効化については別途対応が必要になります。
基本的にはエンタープライズアプリケーションの SCIM プロビジョニングを構成するに沿って設定を行なえば問題ありませんが、
SCIMではSSO同様どのグループで絞って同期させるかという設定が肝なので、プロビジョニング対象のユーザーグループに、SSOの設定で利用したMicrosoft 365グループを指定します。
注意点としては、Entra ID側でアカウントが削除/無効化された際に、SaaS製品側のアカウントがどのような振る舞いになるかを事前に確認しておくことが必要です。
たいていの場合は以下の2ケースの振る舞いになるかと思います。
- アカウントが削除される
- アカウントが無効化される
いずれの場合においてもEntra ID側でログインがはじかれるため認証に成功することはありませんが、
アカウントが削除された際にSaaSデータが消えてしまうなどの振る舞いがないかは確認しておく必要があります。
製品固有の設定方法
上記でご紹介してきた方法は1つのMicrrosoft 365グループに対して1つのSaaS製品のアカウントを払い出す方法ですが、
SaaS製品によっては製品内の権限管理のために複数のグループが必要なものや、どうしてもTeamsのメンバー追加からは対応できないものもあります。
具体的にそれらの製品に対してどのようなアプローチをとっているかをご紹介します。
Atlassian Access
アトラシアン製品は個々の製品をエンタープライズアプリケーションに登録するのではなく、
Atlassian Accessを介して1つのエンタープライズアプリケーションでSSO/SCIMを実現しています。
システム本部では以下のアトラシアン製品を利用しているため、それぞれのMicrosoft 365グループを作成して、
エンタープライズアプリケーションのユーザーグループに割り当てています。
- Jira Software
- Confluence
- Opsgenie
どのグループがどの製品を利用できるかといった権限設定についてはAtlassian Access側の設定になるため、
SCIMで上記のグループを同期したあとで、Atlassian Access側で設定を行なっています。
さらにJiraやConfluenceなどは製品内での権限の管理をグループを利用して細かく設定できるため、
既存の部署などのグループ（セキュリティ・Microsoft 365）についてもSCIMで同期を行なっています。
Opsgenie
Opsgenieではユーザーごとにロールを割り当てることが可能で、アカウントを払い出した直後は「既定のユーザー」ロールが割り当てされます。
システム本部では担当サイトごとにカスタムロールを設定する運用を行なっており、従来はOpsgenieの管理画面で設定変更を行なっていました。
このままでは管理画面に入る必要があるため、何らか別な方法が無いか調査したところ
Update User (Partial) APIを利用してロールを変更できることがわかったため、こちらを叩くPowerShellスクリプトを作成しました。
スクリプトの実行環境としてはGitHub Actionsを利用し、手動トリガー（workflow_dispatch）のUIを利用してロールを変更するようにしました。
GitHub Actionsをフロントとして選んだ理由は、
APIを参照するためのAPIキーといった機微な情報をPowerShell内にべた書きすることは避けたかったので、
GitHub上でシークレットを安全に保持しつつ該当のスクリプトのバージョン管理もしつつ、というバランスがとりやすかったのが最大の理由です。
また、実行結果がログとしても残るので、誰がいつどのようなロール変更を行なったかを確認できるのもメリットでした。
現在は実施していませんが、実行後にTeamsへ通知を飛ばすことも可能ですので発展のさせやすさもメリットかなと思います。
GitHub
システム本部ではGitHub Enterprise Cloudを利用していますが、GitHub内でさらにユーザーごとにロールを分けることが可能で、現在これらのロールを利用しています。
- Enterprise owner
- GitHub Enterpriseの管理者ロール
- Billing manager
- GitHub Enterpriseの支払い情報だけを見るユーザーロール
- Restricted user / Guest collaborator
- Enterprise Managed User(EMU)向けで、リポジトリの権限がinternalの場合でも明示的に権限を付与しないと参照できないロール
- User
- 通常のユーザー向けロール
このロール設定がグループからの同期が必須要件であったため、
エンタープライズアプリケーション側の設定に以下の通り、それぞれのロールごとにグループを割り当てています。
Billing managerやEnterprise ownerはそう変わることもないため、通常の運用上は所属部署や雇用形態に応じてUserとRestricted Userを使い分けて利用しています。
しかしTeamsのチームにメンバーを追加する際に、どちらのグループかを選択して追加することは機能的にはできません。
そのため残念ながらGitHubについてはTeamsを使わずにメンバー追加を行なう必要があるため、Azure Portalや自分のグループ内の「所有しているグループ」からメンバー追加を行なっています。
なお、メンバーの追加/削除はグループの所有者でないと行なえないため、事前にアカウント管理する方を所有者に指定しておく必要があります。
アカウントの追加はTeamsからは行なえませんが、GitHubについては4つのセキュリティグループから1つのMicrosoft 365グループへの同期(※)を行なっています。
※「実現にあたっての壁」で触れた動的グループ機能ですが、先ほどとは同期の方向が逆になります
こちらを行なうことによって、同期先のTeamsチームが以下の機能として利用できます
こちらも手順は省略しますが、"Microsoft 365グループ側"に以下のような動的なクエリを追加します（わかりやすいように改行しています）。
user.memberof -any (group.objectId -in [
'Billing managerグループのオブジェクトID',
'Enterprise ownerグループのオブジェクトID',
'Restricted userグループのオブジェクトID',
'UserグループのオブジェクトID'
])
ちなみにこの設定を入れたあとでTeamsからメンバーを追加しようとすると、以下のような警告が表示されてメンバーの追加ができなくなります。
まとめ
現在の管理方式に行きつくまではだいぶ時間がかかりましたが、割と応用が利く方法だと思っています。
私自身がアプリケーション開発の経験が長く、Microsoft 365を含めた所謂IT周りの知識は現在の部門に異動してから身に付けたため結果的に時間がかかってしまいました。
すでにやってるよ！！という方もたくさんいらっしゃるかもしれませんが、今回の記事を読んで、SaaSのアカウント管理を見直すきっかけになれば幸いです。
一緒にカカクコムのシステム本部の開発者体験を上げてくれる方を募集しています！！
システム本部の開発者体験を上げることをミッションとして、デベロッパーエクスペリエンス室は立ち上がりました。
多様なドメインでサービスを展開していますので、SaaSの管理以外も含めてまだまだ取り組めること・取り組みたいことはたくさんあります。
そのため一緒に壁打ちをして、同じ時間を共有して取り組んでくれる仲間を募集しています。
興味を持っていただけた方はぜひご応募ください！
