← エピソード一覧に戻る Episode 164 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 管理者は一種類で足りるのか
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発で受注にも運用にも直結するテーマ、権限モデルを扱います。SSO を入れたのに大型案件が止まる、そんな場面の裏には、かなりの確率で権限設計の甘さがあります。
ミカ
ミカです。えっ、ログインが安全なら十分じゃないんですか。SSO が入っていれば、企業向けの要件はだいたい満たせるのかと思っていました。
タカシ
そこが大きな誤解です。認証は『あなたが誰か』を確認する仕組みですが、権限モデルは『どの組織で、何を、どこまでできるか』を決める設計です。B2B SaaS では、この後半が弱いと導入審査で止まります。
ミカ
なるほど。同じ人でも、会社 A では管理者、会社 B では閲覧だけ、みたいなことが普通にありますもんね。単純なユーザー管理とは別物だ。
Chapter 2 基本 ― RBACだけでは粗すぎる理由
タカシ
Auth0 の説明でも、RBAC はユーザーに直接権限をばらまかず、役割に権限を束ねるので管理しやすいとされています。ここまでは基本です。ただ SaaS では、主語を user ではなく organization membership に置かないと、顧客ごとの違いを表現しにくいんです。
ミカ
organization membership って、その会社に属している時のその人の立場、みたいなイメージですか。たしかに、それなら同じ個人でも会社ごとに権限を変えられますね。
タカシ
その通りです。さらに AWS のガイドは、RBAC に加えて account lockout や MFA 利用状況のような属性条件も組み合わせる例を示しています。つまり役割名だけでは足りず、条件付きで絞る設計が必要になるわけです。
ミカ
へえ。じゃあ admin というラベルを付けた瞬間に全部できる、みたいな雑な設計は危ないんですね。情シスから嫌われそうです。
タカシ
危ないです。経営的には、管理者権限が広すぎると事故半径が大きくなり、狭すぎると運用が回らなくなります。権限モデルはセキュリティ機能というより、導入コストと継続率を左右する商品設計なんです。
Chapter 3 具体例 ― AtlassianとSlackは何を分けているか
ミカ
実際の SaaS がどう切っているのか知りたいです。優秀なプロダクトほど、管理者を細かく分けている印象はあります。
タカシ
分かりやすいのが Atlassian です。organization admin だけが user provisioning や SAML、SSO を管理でき、audit log も見られる一方、app admin は製品ごとの設定担当に留まります。組織統制と日常運用を最初から分けているんです。
ミカ
同じ管理者でも、会社全体を扱う人と、アプリの運用だけ触る人を分けているんですね。全部 owner に寄せないのは、たしかに健全そうです。
タカシ
しかも Atlassian は、SCIM で同期された外部グループを read-only とし、default group には使えないと明記しています。つまり IdP 側の同期と、実際の製品アクセスやライセンス割当を混ぜない。これは地味ですがかなり重要な設計です。
ミカ
ライセンスまで絡むと、権限モデルはセキュリティだけじゃなく収益管理にも入ってきますね。雑に同期すると、請求まで事故りそうです。
タカシ
Slack も面白いです。SCIM ではメンバーの作成や無効化、ユーザーグループ管理まで扱えますが、Enterprise では Audit Logs Admin、Roles Admin、Security Admin などの system role を分離しています。入れる人、監査する人、役割を設計する人を同一視していません。
ミカ
なるほど。人を追加できる権限と、証跡を見る権限と、セキュリティ設定を触る権限は別なんだ。これは enterprise 顧客が好きそうな整理です。
Chapter 4 具体例 ― NotionとWorkOSが示す運用の完成形
タカシ
Notion の SCIM API も示唆的です。Enterprise Plan でユーザーとグループを作成・削除でき、workspace role として owner、membership_admin、member、restricted_member を扱います。つまり管理者にも段差を付け、閲覧制限の強い利用者も標準で持っているわけです。
ミカ
restricted member まで標準にあるのはいいですね。現場に全部を見せたくないけど、完全に外部扱いにもしたくない、みたいな運用って結構あります。
タカシ
加えて Notion の audit log は、ログイン、ログアウト、support access、Workspace SAML 認証などを追跡し、365 日分を CSV export できます。ここが大事で、権限は付与した瞬間より、後から説明できるかどうかで enterprise の信頼性が決まります。
ミカ
つまり『誰が見られるか』だけじゃなくて、『誰が変えたか』『いつ入ったか』まで残せないと弱いんですね。監査ログが主役に見えてきました。
タカシ
そうなんです。さらに WorkOS は、組織ごとの custom role、複数ロール付与、SCIM や SSO グループからの role assignment を前提にしています。これは SaaS が顧客ごとの統制差分を、特注開発ではなく設定で吸収する方向へ進んでいることを示しています。
Chapter 5 クロージング ― 明日から見直すチェックポイント
ミカ
今日の話を聞くと、まず自社で identity、organization membership、role、permission、audit event が分かれているか確認したくなります。全部 user テーブルに押し込んでいたら、かなり危険そうです。
タカシ
その確認は有効です。その上で、請求や SSO を触る人、ユーザー管理をする人、監査を見る人、日常運用を回す人、一般利用者を最低限分けること。そして権限変更やデータ出力を必ず記録に残すこと。この二つでかなり事故が減ります。
ミカ
あと SCIM ですね。手動招待と手動削除のままだと、入退社のたびに権限がずれそうですし、情シスレビューでも不安を与えます。
タカシ
まさにそこです。SSO は入口、SCIM は人事異動への追随、監査ログは説明責任、そして権限モデル本体は日々の統制です。この四つがつながって初めて enterprise-ready に近づきます。ぜひ自社の管理者ロールが広すぎないか、今週中に棚卸ししてみてください。
ミカ
今日は『ログインできる』と『安全に運用できる』は全然違うとよく分かりました。次に管理画面を見る時、ロール一覧の見え方がかなり変わりそうです。それではまた次回お会いしましょう。