権限管理設計を完全に理解した 1 

自己紹介 フリーランスエンジニア7年目 r-sugi 2 

今回のアジェンダ マルチテナント SaaS の権限管理、なぜ難しいのか 試しに1つ提示するので、みんなであれこれ議論したい 3 

今回のスライド 詳細はこの記事 4 

権限管理ってなんだっけ？ 認証（Authentication） 「あなたは誰ですか？」 本人確認のプロセス。Googleアカウントでログインするのが認証。 認可（Authorization）← 本日のテーマ 「あなたは何をしてよいですか？」 何ができるかの制御。ログイン後にどの画面を見られるか・どの操作ができ るかを制御する。 5 

権限管理、なぜ難しいのか 最初は if user.role === "admin" から始まる… 気づいたころには「この条件、正しいんだっけ？」と誰も答えられないコードになっ ている toC → toBシングルテナント → toBマルチテナント マルチテナント 複数テナントが同一DBに共存 テナント間のデータ分離が必須 ロール以外にも、プランなど組み合わせが加わり、複数軸が絡み合う 6 

RBAC とその限界 RBAC＝ロールに権限を紐づけるシンプルなモデル。認知率は高いが、すぐ限界が来 る。 shop_owner_pro のような謎ロールが増殖 (role x plan) if admin? && manager? || shop_leader? と連鎖 7 

やらかしパターン 3選 バックエンド：Policy クラスにビジネスロジックが混入 フロントエンド：role を直参照、バックと二重管理に テーブル設計：admin_leader_users テーブルが爆誕 8 

バックエンド Policy クラスにビジネスロ ジックが増えていく 9 

フロントエンド role直書き 10 

テーブルに切り出す 権限判定用ではなさそうな テーブルを作成。 毎回参照したり、フラグにして 使い回したりする 11 

権限管理の概念 PBAC + ReBAC PBAC： 「何ができるか」をポリシーに集約する ロール、プラン→権限の最小単位をポリシーとして定義する イメージ: AWS IAM role: policies ReBAC： 「誰のリソースか」をリレーションで守る PBACだけでは他テナントのリソースへの横断アクセスを防げない 「顧客一覧を取得できる権限がある」→他テナントの顧客も取得できてしま う 12 

サンプル:コンビニチェーン向けマルチテナントSaaS 13 

PBAC： 「何ができるか」をポリシーとして定義する 14 

PBAC 店舗作成できるかの判定 宣言的にpolicyを指定できる 15 

ReBAC： 「誰のリソースか」をリレーションで守る 16 

ReBAC: 店舗の情報を閲覧しようとした 17 

ReBAC: 店舗の情報を閲覧し ようとした リポジトリ全体にフィルター済 みのscopeを注入しておく 個別処理を実装する際にscopeを 参照して一覧を取得する(一括処 理系も同様) すごくしんどい 18 

19 

まとめ 権限管理はPBAC x ReBACがベース PBACは導入しやすい。ReBACはつらい（RLSを入れてもつらそう） 20