情シスはSaaSのアカウント管理をどうおこなうのがいいのか。一例としてAdminaのロール機能を使ったアカウント管理運用フローを共有します
マネーフォワード Admina にロール機能がリリースされました。
本機能は23年7月にSaaS管理SaaSを比較検討している中で「ロール機能を作ってください。この機能がないと私がやりたいSaaS管理はできないんです。」とマネーフォワードiさんにお願いして作ってもらった機能です。 私の所属する STORES 株式会社 ではβテスターとしてロール機能を先行実装した環境を開発初期から利用していました。当初はバグだらけでした（笑）が、5ヶ月間のフィードバックを重ねてバグ修正と機能改修を繰り返して全環境にリリースされたようです。
リリース記念（？）として本記事では、私が考えるアカウント管理の理想や、理想に近づけるために実際に STORES で行っているAdminaのロール機能を使ったアカウント管理運用フローを共有していこうかなと思います。
そもそも私の目指したいSaaSアカウント管理の理想
2年半前に「なぜ情シスがすべてのSaaSの管理をするとうまくいかないのか？」というnoteを書きました。
note内に書いた下記の部分に対する思いは当時も今も全く変わっていません。SaaSは使いたい部署が調査して、予算を取って、稟議をあげて、導入して、アカウント管理もする。そして情シスは支援に徹するのスタンスです。そのほうがうまくいくと信じています。
部門でSaaS管理している人を支援しましょう。部門向けSaaSを管理してあげるのではなく管理に役立つデータを提供したり、管理方法を一緒に考えてあげたり、SSOの設定を手伝ってあげたりの支援です。あくまで管理の主体は部門の方で、情シスは支援にとどめます。
アカウント管理だけみれば、理想はSCIMやアカウント管理用のAPIを使ってIdPと連携された世界になるでしょう。
入社時の組織や雇用形態に応じてだったり申請ベースで自動でアカウントが発行される世界、そして退職と同時に自動で連携SaaSのアカウントも消える世界、最高ですね。
でもこの世界にたどり着くのはまだまだ先の話です。
実際はSCIMどころかSSOすら実装されていないSaaSも多く、SCIMが用意されていても、プランアップを強制されてそこまでお金はだせない・・・というのが現実です。そんな中で各社の情シスはできるところから自動化していってる、というのが現状かなと思います。
ではアカウント管理において情シスが支援する方法はまったくないのでしょうか？
いえ、あります。その一つの解決方法がAdmina、Bundle、ジョーシスを始めとしたSaaS管理SaaSを導入し、アカウント発行や削除やアカウントの棚卸しをラクにできるようにすることです。
なぜロール機能が必要だったのか
冒頭で「ロール機能を作ってください」と書きましたが元々Admina上のユーザーは連携されたすべてのSaaS管理ができるようになっていました。
これは情シスがすべてのSaaSを管理する分には問題ないのですが、私がやりたいのは部門ごと、など狭めた範囲でSaaS管理をしたいのです。
下記がAdminaのロール機能をつかったときのイメージです。
ロールを作ってそのロールの中でSaaSアカウントを管理する形です。
ロールが違えば他のロールで連携されたSaaSはみえません、またユーザーには複数ロールをつけることも可能です。
これは他チームのSaaSのアカウント一覧を見せたくないとかではなくて、見えてしまうことでノイズになるからです。
例えば上記の図で言うならば、デザイナーロールの方がSlackのアカウント削除漏れがわかったとてやれることはありません。
ロールがないと大量の連携されたSaaS一覧の中から自分たちが管理しているSaaSを探す、という作業が必要になりますし、（本当は自分のチームで消さないといけないのに）〇〇チームが消してくれるはず、みたいな勘違いからのアカウント削除漏れが発生する可能性が高くなります。
そのため適切な範囲のロールを切らないと運用が綺麗に回らないと判断し、ロール機能は絶対に必要だったのです。
Admina利用にあたっての前提について
Admina自身のログイン/アカウント発行削除/ロールについて
AdminaはIdPと連携してSSOやSCIMを組むことができます。
弊社の場合はOktaと連動させているので、Okta上のAdminaグループに入れると自動でAdminaのアカウントが発行されます。
ただしロールの割当までは連動しないのでそこは情シス側で手動で当てる必要があります。
SaaSの接続方法について
Adminaでは大きく分けて、下記3つの インテグレーション方式 と アカウントCSVアップロード方式 の2種類の接続方法があります。
OAuthを利用した接続
APIを利用した接続
ID/Passwordを利用した接続
インテグレーション方式のうち ID/Passwordを利用した接続は禁止としました。（システム上では禁止にできないためルールによる禁止）
これはAdmina側にID/Passwordを渡すのは高リスクと判断したためです。
※ Adminaを信用してないわけではないですが、アカウントを取得できる権限になると管理者権限になるため、パスワードをそのまま渡すのは高リスクと判断しました
そうなると結構な数のSaaSが連携できなくなるため、カスタムアプリを作って アカウントCSVアップロード方式 で行うパターンが多くなります。
上記のアカウントCSVアップロードは元々機能としてはありましたが、アップロードしてもCSVに記載されていないアカウントが削除されずCSVにあるアカウントが追加されるだけでした。そのため一度全てのアカウントを消してアップロードし直さないといけなかったのです。
この仕様では運用がかなり大変だったので「CSVに記載されていないアカウントを削除する」という機能を追加してもらいました。
（おそらくですが）多くの会社ではID/Passwordを利用したSaaS接続も普通にOKにしていて、CSVアップロードの需要がなかったのだと思います。
セキュリティに一定厳しい会社ではリスク許容できない連携方法があったりすると思います。本機能のリリースによりCSVアップロードを使ったアカウント登録がだいぶ使いやすくなったのでセキュリティが厳しくてAPI連携等ができない会社さんでも十分実用に耐えうるようになったと思います。
アカウント棚卸しの運用手順について
棚卸し依頼は毎月月初に行うことにしています。
棚卸しの手順はインテグレーション方式 と アカウントCSVアップロード方式で違うのでそれぞれ解説します。
インテグレーション方式の棚卸し手順
下記のように月初に情シスから棚卸し依頼をSlackで飛ばします。
Admina利用者はSaaS同期処理を実行します。
※ インテグレーション方式であれば定期的に同期処理が走るのですが、情シスによる従業員マスターからのアカウント削除タイミングが棚卸しタイミングと近いと退職者扱いにならないため念のため同期処理を行ってもらっています
Admina利用者は同期処理が終了した際に、退職者があぶり出されるので必要であればアカウント削除を行い、再度同期処理を行って退職者が0件になることを確認してもらい、棚卸し終了です。
アカウントCSVアップロード方式の棚卸し手順
インテグレーション方式の棚卸し手順と同じ用にSlackで依頼を飛ばします。
Admina利用者はSaaSの管理画面にいってアカウント一覧をCSV等でダウンロードします。（大体のSaaSには用意されています）
Admina用にCSVを整形しアップロードし、あとはインテグレーション方式と同じように退職者アカウントが0件になることを確認してもらい、棚卸し終了です。
アカウントの即時削除について
棚卸しは月初に依頼していますが、アカウントは不要になった時点で即時削除するのが正しいです。
Adminaではアカウント画面からメールアドレス検索を行いそのアカウントがもっているSaaSの一覧が表示できます。
この機能を使うことで、アカウント削除タイミングになったらAdmina上の画面をみて当該アカウントが使っているサービスを特定し、アカウントを削除する、というフローを作れます。
それぞれのSaaSの管理画面にはいってユーザー検索して、存在していたら削除、という流れSaaSごとにしなくていいのはとても便利です。
もちろんこの仕組みで即時削除するフローを構築する場合は管理しているSaaSをすべてAdminaに連携する必要があります。
その他 Admina利用時のガイドラインに記載していること
ワークスペース名について
Adminaでは同一のSaaSを連携したときに区別できるようにするためにワークスペース名という項目があります。
ワークスペース名は自分で設定できない（自動で設定される）SaaSと自分で設定できるSaaSがあります。
たとえばGoogle Workspaceのワークスペース名はAdminaが自動でGoogle Workspaceのプライマリードメインを引っ張って設定します。
カスタムアプリ（CSVアップロード方式）の場合は連携者がワークスペース名を入れる必要があります。
そのため、ワークスペース名はロール名と揃えたり、SaaSを管理しているチーム名や用途なんかにするといいかと思います。
ユーザータイプについて
Admina上の従業員マスターのユーザータイプは条件によって変化します。
これが少しややこしいので解説しておきます。
Google Workspace を従業員マスターにしている場合は下記のようにユーザータイプが設定されます。（サスペンド状態は休職になりますが弊社の場合サスペンド状態はつくらないため図には記載されていません）
Adminaの特徴としてGoogleグループをシステムユーザータイプとして扱う、というのがあります。
これはAdminaの気に入ってる仕組みのひとつなのですが、現実問題Googleグループを使ったアカウントというのがいろんなSaaS上に存在します。
ライセンス違反になる形での共有アカウント利用はもちろんNGですが、システムアカウントというのは必要なことはあるので、これが退職者として扱われずシステムとしてでてくるのは使い勝手がいいと思います。
おわりに
本記事はあくまで私がやりたいアカウント管理の話をAdminaで実現しているよ、という話です。
自社のアカウント管理をどうしたいかによって選定するSaaS管理SaaSも変わってくるかと思いますし、Adminaを使っていてもまた違う運用だったりもすると思います。他のSaaS管理SaaSの話やAdminaを使った別の運用方法の記事もぜひ見てみたいので導入している方はブログを書いてくれたら一報くれるとうれしいです笑
この記事が気に入ったらサポートをしてみませんか？