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

LT: https://easy2.connpass.com/event/392459/
記事: https://zenn.dev/rsugi/articles/19e0014a7040b3

Transcript

1. 権限管理設計を完全に理解した 1
2. 自己紹介 フリーランスエンジニア7年目 r-sugi 2
3. 今回のアジェンダ マルチテナント SaaS の権限管理、なぜ難しいのか 試しに1つ提示するので、みんなであれこれ議論したい 3
4. 今回のスライド 詳細はこの記事 4
5. 権限管理ってなんだっけ？ 認証（Authentication） 「あなたは誰ですか？」 本人確認のプロセス。Googleアカウントでログインするのが認証。 認可（Authorization）← 本日のテーマ 「あなたは何をしてよいですか？」 何ができるかの制御。ログイン後にどの画面を見られるか・どの操作ができ るかを制御する。 5
6. 権限管理、なぜ難しいのか 最初は if user.role === "admin" から始まる… 気づいたころには「この条件、正しいんだっけ？」と誰も答えられないコードになっ ている toC → toBシングルテナント → toBマルチテナント マルチテナント 複数テナントが同一DBに共存 テナント間のデータ分離が必須 ロール以外にも、プランなど組み合わせが加わり、複数軸が絡み合う 6
7. RBAC とその限界 RBAC＝ロールに権限を紐づけるシンプルなモデル。認知率は高いが、すぐ限界が来 る。 shop_owner_pro のような謎ロールが増殖 (role x plan) if admin? && manager? || shop_leader? と連鎖 7
8. やらかしパターン 3選 バックエンド：Policy クラスにビジネスロジックが混入 フロントエンド：role を直参照、バックと二重管理に テーブル設計：admin_leader_users テーブルが爆誕 8
9. バックエンド Policy クラスにビジネスロ ジックが増えていく 9
10. フロントエンド role直書き 10
11. テーブルに切り出す 権限判定用ではなさそうな テーブルを作成。 毎回参照したり、フラグにして 使い回したりする 11
12. 権限管理の概念 PBAC + ReBAC PBAC： 「何ができるか」をポリシーに集約する ロール、プラン→権限の最小単位をポリシーとして定義する イメージ: AWS IAM role: policies ReBAC： 「誰のリソースか」をリレーションで守る PBACだけでは他テナントのリソースへの横断アクセスを防げない 「顧客一覧を取得できる権限がある」→他テナントの顧客も取得できてしま う 12
13. サンプル:コンビニチェーン向けマルチテナントSaaS 13
14. PBAC： 「何ができるか」をポリシーとして定義する 14
15. PBAC 店舗作成できるかの判定 宣言的にpolicyを指定できる 15
16. ReBAC： 「誰のリソースか」をリレーションで守る 16
17. ReBAC: 店舗の情報を閲覧しようとした 17
18. ReBAC: 店舗の情報を閲覧し ようとした リポジトリ全体にフィルター済 みのscopeを注入しておく 個別処理を実装する際にscopeを 参照して一覧を取得する(一括処 理系も同様) すごくしんどい 18
20. まとめ 権限管理はPBAC x ReBACがベース PBACは導入しやすい。ReBACはつらい（RLSを入れてもつらそう） 20