OpenFGAで拓く次世代認可基盤 〜予告編〜

Transcript

1. OpenFGAで拓く次世代認可基盤 〜予告編〜 NALYSYS開発部 桐生直輝 2025/02/05
2. 自己紹介 桐生直輝 (25歳) • 入社：2023年3月 • 所属：NALYSYS開発部 ◦ リードエンジニアやらせていただいてます ◦ 主にバックエンド〜インフラ担当 • 趣味：コンピュータいじり、自宅サーバー構築 ◦ おうちKubernetes運用中です ◦ 最近は少し手が回らないがち・・
3. サービス紹介 • 社員のエンゲージメントを計測できる SaaS • パルスサーベイ(NALYアンケート) • 適性検査PIONALY • 性格診断NALYGRAM
4. 今回のテーマ 認証と認可の「認可」のほう • 認証: アクセスしてきたユーザーが「誰であるか」を判断すること • 認可: アクセスしてきたユーザーが「何をして良いか」判断すること ◦ 基本的に認証ができている前提 • 今回は認証は扱いません
5. 今回のテーマ 認可制御の新たな道を切り開きたい！ • 従来の認可制御では、RBACと呼ばれるモデルが多く用いられてきた ◦ NALYSYSもRBACをベースとした認可方式を利用中 • 一方、複雑なシナリオではRBACだけでは不十分な場合も・・・ → 今回は、ReBACと呼ばれる新たな制御方式をご紹介
6. 今回のテーマ 今回は予告編なので・・・ • まだ机上で検討中の内容がほとんどです • もしかしたら実装できない内容を含んでいるかも ◦ 変なところがあればこっそり教えてください
7. 今回のテーマ アジェンダ 1. NALYSYSにおける認可制御の課題 2. 新たな認可制御ReBACとは何か 3. OpenFGAによるReBACの実装 4. 今後検証していきたい事項について
8. NALYSYSにおける認可制御の課題
9. NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • RBAC: 権限をひとまとめにしたロールを作り、それをユーザーに割り当てる ロール モチベーション管理 管理者 read:全員の従業員情報 権限 read:全員のNALYサーベイ 権限 write:全員のNALYサーベイ 権限 ロール モチベーション管理 メンバー read:自分の従業員情報 権限 read:自分の性格診断結果 権限 write:自分のNALYサーベイ 権限
10. NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • APIがアクセスを検証するときは、要求された権限があるかを判断する ロール モチベーション管理 管理者 read:全員の従業員情報 権限 read:全員のNALYサーベイ 権限 write:全員のNALYサーベイ 権限 NALYサーベイ 一覧API • read:全員のNALYサーベイがあるかチェック 付与
11. NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • 操作を行う側では、必要なpermissionがあるかどうかだけを確認すれば良い ◦ 例えば、従業員情報の取得 APIで、従業員情報の読み取り権限が「モチベーション管理 管理 者」と「年末調整 管理者」のどちらからやってきたかなどは気にする必要がない • これだけでも結構制御が可能だが、全てのケースをカバーできるわけではない
12. NALYSYSの認可制御 NALYSYSではRBACを利用 • 権限は、リソース + 動詞(verb)で構成される ◦ 例: 全員の従業員情報+ read -> 全ての従業員情報を読み取れる • 操作を行う側では、必要なpermissionがあるかどうかだけを確認すれば良い ◦ 例えば、従業員情報の取得 APIで、従業員情報の読み取り権限が「モチベーション管理 管理 者」と「年末調整 管理者」のどちらからやってきたかなどは気にする必要がない • これだけでも結構制御が可能だが、全てのケースをカバーできるわけではない
13. NALYSYSの認可制御 RBACだけだと完結できない例 • NALYSYSには組織階層がある 会社1 部署A 子部署1 子部署2 チーム1 チーム2 子部署3 部署B
14. NALYSYSの認可制御 RBACだけだと完結できない例 • 「モチ管 リーダー」だと、自分が管理者の部署内の NALYスコアだけが見られる 会社1 部署A 子部署1 子部署2 チーム1 チーム2 子部署3 部署B 子部署1の管理者 NALYスコアの閲覧可能範囲
15. NALYSYSの認可制御 RBACだけだと完結できない例 • 単純なRBACだと、範囲の制限はアプリケーションのロジックでやる必要がある • 例: 特定の従業員のNALYスコアを取得するAPI ◦ 権限「read:全員のNALYスコア」or「read:同じ会社の人のNALYスコア」or「read:配下部署の人の NALYスコア」があれば実行は可能 ◦ 「read:同じ会社の人のNALYスコア」以下の権限なら、会社 IDも追加でチェック ◦ 「read:配下部署の人のNALYスコア」以下の権限なら、部署 IDも追加でチェック
16. NALYSYSの認可制御 部署配下制御は特に地獄！ • 配下部署かを判断するには、「間接的な配下部署」も考慮する必要がある • つまり、部署の再帰的な解決を毎回行う必要がある • さらに、会社レベルでのチェックも別で存在する → 会社・部署の両方に対するクエリを毎回書く必要がある 😢
17. NALYSYSの認可制御 よりシンプルな認可制御を求めて • アプリケーション側では、「ユーザー」「対象オブジェクト」「操作」を渡したら「できる」 or「でき ない」が返ってくるのが理想的 ◦ 例：「ユーザー(id=1)」は、「従業員(id=123)」の「NALYスコア読み取り」をできるか • ReBACを使うことでこのような認可クエリを実現できる
18. 新たな認可制御 ReBAC
19. 新たな認可制御 ReBAC ReBACとは • ReBAC = Relation Based Access Control • オブジェクト間の持つ関係に基づいて認可判断を行う • Zanzibar(Googleの各種サービスの認可基盤)で用いられている手法
20. 新たな認可制御 ReBAC ReBACの構成要素 • ReBACでは、typeに対してrelationを定義する • type: リソースを表す型。例: corporation, department, employee, user ◦ 全てのリソースはIDを持つ。corporation:123は、typeがcorporationでidが123 • relation: あるリソースが他のリソースに対してとりうる関係 ◦ 例: departmentは、corporationまたはdepartmentに対してparentというrelationを持ちうる ◦ 例: employeeは、corporationまたはdepartmentに対してbelongsというrelationを持ちうる
21. 新たな認可制御 ReBAC typeとrelationの例 corporation:100 department:201 department:202 parent employee:301 parent belongs employee:302 belongs これらの関係はrelation tupleで表現される 例えば、赤い線の関係の場合、 (employee:301, belongs, department:201) department:203 parent belongs
22. 新たな認可制御 ReBAC ReBACにおける権限の扱い • ReBACでは、リソース間の関係だけではなく、権限も relationで表す • 例えば、部署情報を編集できることを表す場合 : ◦ departmentがuserに対してcanEditというrelationを持てるようにする department:202 user:302 canEdit • ただ、権限のrelation tupleを直接追加することは通常しない department:202を編集可能なリソースの1つはuser:302
23. 新たな認可制御 ReBAC 間接的なrelationの定義 • ReBACでは、既存のrelationに基づいて新しいrelationを作ることができる • 例えば、departmentに対してviewerとeditorという2つのrelationを定義し、 ◦ departmentのcanView = viewer or editor ◦ departmentのcanEdit = editor • このように定義することで、権限とその判断ロジックを分離する
24. 新たな認可制御 ReBAC 間接的なrelationの例 department:202 editor user:302 canView canEdit viewer user:303 canView 実線は明示的に(relation tupleによって)付与されたrelation 点線は暗黙のうちに付与された relation
25. 新たな認可制御 ReBAC typeを跨いだrelationの自動付与 • 間接的なrelationの付与において、自身以外のrelationも参照することが可能 • 例えば、corporationのeditorが配下departmentのeditorにもなって欲しい場合: ◦ departmentのeditor = 直接付与 or editor from parent • parentには親会社・親部署が含まれるので、これだけで再帰的に editorが付与される
26. 新たな認可制御 ReBAC typeを跨いだrelationの自動付与の例 corporation:100 user:302 department:201 editor • department#editor = editor from parentの場合 parent editor department:202 parent editor
27. 新たな認可制御 ReBAC NALYSYSの認可制御を ReBACで表現してみる • ここまで登場した概念を用いると、配下部署制御を簡単に実装できる • 部署管理者をdepartment#managerとして表現 ◦ さらに、manager from parentをこれに含める • さらに、user#managerをmanager from belongsによって定義 ◦ 所属部署のmanagerはuserのmanagerにもなる • 最後に、user#managerがあればuser#canViewNalyScoreを付与するようにする
28. 新たな認可制御 ReBAC NALYSYSの認可制御を ReBACで表現してみる corporation:1 department:A department:C department:D department:B user:301 employee:501 manager シンプルに(employee:501, canViewNalyScore, user:301)などを問い合わせれば、配 下部署に基づいた権限判断が行われる manager manager canViewNalyScore belongs manager relationのあるobject
29. OpenFGAによるReBACの実装
30. OpenFGAによるReBACの実装 OpenFGAとは • ReBACのオープンソース実装 • Zanzibarの論文に登場する概念を実装している • 高速で一貫性のある認可クエリを実行可能 • CNCF Sandbox Projectsにも採択されている
31. OpenFGAによるReBACの実装 OpenFGAの実行形態 • OpenFGAは認可クエリを受け付けるHTTPサーバーとして動作する • データはMySQLやPostgreSQLなどのRDB上にストア • 認可クエリに対するインメモリキャッシュも構成可能
32. OpenFGAによるReBACの実装 OpenFGAにおけるtypeとrelationの定義 • OpenFGAでは、一連のtypeとrelationの定義をAuthorization Modelと呼んでいる • サーバーにAuthorization Modelを登録する • さらにRelation Tupleも登録することで認可クエリを実行できるようになる
33. OpenFGAによるReBACの実装 OpenFGAにおけるtypeとrelationの定義 • Authorization Modelには専用のDSLがあり、直観的な記述が可能 type corporation type user type department relations define parent: [corporation, department] define manager: [user] or manager from parent type employee relations define belongs: [corporation, department] ...
34. OpenFGAによるReBACの実装 NALYSYSでのOpenFGAの実装構想 • NALYSYSでは、主に以下の用途でOpenFGAの権限制御を利用予定 • 各APIの実行可否判断 • 一覧系APIでのフィルタリング • フィールドの閲覧可否判断
35. OpenFGAによるReBACの実装 NALYSYSのオブジェクトツリー概要 • テナントを頂点として、リソース階層をそのまま表現する • アプリケーション全体での権限はテナントの relationとして表現 tenant corporation department department corporation employee canAddCorporation canAddIpRestriction ... canListEmployees canAddEmployee ...
36. OpenFGAによるReBACの実装 各APIの実行可否判断 • 各リソースのcanXXXを用いて判断 ◦ 例: findEmployeById($id)の場合、(employee:$id, canView, user:$userId)をcheck • リソースの追加などは親コンテナの relationとして定義 ◦ 例: 会社への従業員の追加は corporation#canAddEmployeeとして定義
37. OpenFGAによるReBACの実装 一覧系APIでのフィルタリング • 一覧系のAPIでは、結果のうち閲覧可能なものを返さなければならない • これを実現するには以下の2つのパターンがある • パターン1: 権限関係なく取得してから絞り込む • パターン2: 閲覧可能なオブジェクトのIDを列挙して絞り込み検索
38. OpenFGAによるReBACの実装 パターン1: 権限関係なく取得してから絞り込む • 権限関係なく取得してから、全てのオブジェクトの閲覧可否を batch checkで判定 • 既存のcanView relationなどをそのまま利用でき、直感的でわかりやすい • 一方、検索結果の大部分が表示できない場合は非効率 • また、取得件数が多い場合もOpenFGAへの負荷が高まってしまう ◦ ページネーションの実装が前提
39. OpenFGAによるReBACの実装 パターン2: 閲覧可能なオブジェクトの IDを列挙して絞り込み検索 • 例えば、特定の会社配下しか見られない場合に予め会社 IDで絞り込むなど • 合致するrelationを持つオブジェクトはListObjectという操作で列挙可能 • 列挙されるオブジェクトIDが少ない時に適している • デメリットとしては、employeeに対する権限をcorporationなどの親にリフトアップする必要が ある上、アプリケーション側の認可ロジックに対する結合が増えてしまう • 場合に応じて適切に使い分けていく必要がある
40. OpenFGAによるReBACの実装 フィールドの閲覧可否判断 • 例えば、従業員の生年月日は強い権限を持っている場合しか見られない • GraphQLのfieldMiddleware機能を使って、フィールドごとの認可判断を行う ◦ 認可クエリはdataloaderなどを使って適宜バッチ化
41. OpenFGAによるReBACの実装 (余談) RBACとのインピーダンスミスマッチについて • RBACではロールから権限を参照していたが、 ReBACでRBACを再現する場合、権限から ロールを参照する必要がある ◦ 例えば、permissionAがroleAとroleBの両方にある場合、 permissionA: roleA or roleBと定義す る必要がある • 既存のロールを移行しようと思うとこれが分かりにくいため、トランスパイラなどによりこの逆 変換を行うことを検討している
42. 今後検証していきたい事項について
43. 今後検証していきたい事項について 認可クエリのパフォーマンス特性 • OpenFGAは既存のRDB(PostgreSQLなど)の上にグラフを構築する • グラフ演算がどのようなクエリに跳ねるのかは未知数 ◦ 一応、andはorに比べて重たいという記述はあるが、情報が少ない • 複雑なクエリがどのようなSQLを呼ぶのかを検証していきたい
44. 今後検証していきたい事項について 認可モデルの進化性 • typeやrelationの追加・削除を無停止でうまいことロールアウトできるか • typeやrelationの定義(authorization model)は、具体的なrelationの内容(relation tuples)とは完全に独立に更新可能となっている ◦ 無効なtupleは単純に無視されるため • authroziation modelを無理ない方法で複数保持できるかを検証したい ◦ 使う側で必ずauthorization modelのIDを指定する必要があるので、毎回手動で更新するのは 大変そう
45. まとめ
46. まとめ • OpenFGAとReBACを用いることでよりきめ細かい認可制御が可能となる • 一方、RBACと同じような体験も得たい場合は工夫が必要 • 新しい技術で障壁もあるが、複雑な認可モデルの実現方法としてはかなり有力な選択肢に なりうる 本日のポイント
47. ご清聴ありがとうございました！