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

by Tech Leverages

Slide 1

Slide 1 text

OpenFGAで拓く次世代認可基盤〜予告編〜 NALYSYS開発部桐生直輝 2025/02/05

Slide 2

Slide 2 text

自己紹介桐生直輝 (25歳) ● 入社：2023年3月 ● 所属：NALYSYS開発部 ○ リードエンジニアやらせていただいてます ○ 主にバックエンド〜インフラ担当 ● 趣味：コンピュータいじり、自宅サーバー構築 ○ おうちKubernetes運用中です ○ 最近は少し手が回らないがち・・

Slide 3

Slide 3 text

サービス紹介 ● 社員のエンゲージメントを計測できる SaaS ● パルスサーベイ(NALYアンケート) ● 適性検査PIONALY ● 性格診断NALYGRAM

Slide 4

Slide 4 text

今回のテーマ認証と認可の「認可」のほう ● 認証: アクセスしてきたユーザーが「誰であるか」を判断すること ● 認可: アクセスしてきたユーザーが「何をして良いか」判断すること ○ 基本的に認証ができている前提 ● 今回は認証は扱いません

Slide 5

Slide 5 text

今回のテーマ認可制御の新たな道を切り開きたい！ ● 従来の認可制御では、RBACと呼ばれるモデルが多く用いられてきた ○ NALYSYSもRBACをベースとした認可方式を利用中 ● 一方、複雑なシナリオではRBACだけでは不十分な場合も・・・ → 今回は、ReBACと呼ばれる新たな制御方式をご紹介

Slide 6

Slide 6 text

今回のテーマ今回は予告編なので・・・ ● まだ机上で検討中の内容がほとんどです ● もしかしたら実装できない内容を含んでいるかも ○ 変なところがあればこっそり教えてください

Slide 7

Slide 7 text

今回のテーマアジェンダ 1. NALYSYSにおける認可制御の課題 2. 新たな認可制御ReBACとは何か 3. OpenFGAによるReBACの実装 4. 今後検証していきたい事項について

Slide 8

Slide 8 text

NALYSYSにおける認可制御の課題

Slide 9

Slide 9 text

NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 ● RBAC: 権限をひとまとめにしたロールを作り、それをユーザーに割り当てるロールモチベーション管理管理者 read:全員の従業員情報権限 read:全員のNALYサーベイ権限 write:全員のNALYサーベイ権限ロールモチベーション管理メンバー read:自分の従業員情報権限 read:自分の性格診断結果権限 write:自分のNALYサーベイ権限

Slide 10

Slide 10 text

NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 ● APIがアクセスを検証するときは、要求された権限があるかを判断するロールモチベーション管理管理者 read:全員の従業員情報権限 read:全員のNALYサーベイ権限 write:全員のNALYサーベイ権限 NALYサーベイ一覧API ● read:全員のNALYサーベイがあるかチェック付与

Slide 11

Slide 11 text

NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 ● 操作を行う側では、必要なpermissionがあるかどうかだけを確認すれば良い ○ 例えば、従業員情報の取得 APIで、従業員情報の読み取り権限が「モチベーション管理管理者」と「年末調整管理者」のどちらからやってきたかなどは気にする必要がない ● これだけでも結構制御が可能だが、全てのケースをカバーできるわけではない

Slide 12

Slide 12 text

NALYSYSの認可制御 NALYSYSではRBACを利用 ● 権限は、リソース + 動詞(verb)で構成される ○ 例: 全員の従業員情報+ read -> 全ての従業員情報を読み取れる ● 操作を行う側では、必要なpermissionがあるかどうかだけを確認すれば良い ○ 例えば、従業員情報の取得 APIで、従業員情報の読み取り権限が「モチベーション管理管理者」と「年末調整管理者」のどちらからやってきたかなどは気にする必要がない ● これだけでも結構制御が可能だが、全てのケースをカバーできるわけではない

Slide 13

Slide 13 text

NALYSYSの認可制御 RBACだけだと完結できない例 ● NALYSYSには組織階層がある会社1 部署A 子部署1 子部署2 チーム1 チーム2 子部署3 部署B

Slide 14

Slide 14 text

NALYSYSの認可制御 RBACだけだと完結できない例 ● 「モチ管リーダー」だと、自分が管理者の部署内の NALYスコアだけが見られる会社1 部署A 子部署1 子部署2 チーム1 チーム2 子部署3 部署B 子部署1の管理者 NALYスコアの閲覧可能範囲

Slide 15

Slide 15 text

NALYSYSの認可制御 RBACだけだと完結できない例 ● 単純なRBACだと、範囲の制限はアプリケーションのロジックでやる必要がある ● 例: 特定の従業員のNALYスコアを取得するAPI ○ 権限「read:全員のNALYスコア」or「read:同じ会社の人のNALYスコア」or「read:配下部署の人の NALYスコア」があれば実行は可能 ○ 「read:同じ会社の人のNALYスコア」以下の権限なら、会社 IDも追加でチェック ○ 「read:配下部署の人のNALYスコア」以下の権限なら、部署 IDも追加でチェック

Slide 16

Slide 16 text

NALYSYSの認可制御部署配下制御は特に地獄！ ● 配下部署かを判断するには、「間接的な配下部署」も考慮する必要がある ● つまり、部署の再帰的な解決を毎回行う必要がある ● さらに、会社レベルでのチェックも別で存在する → 会社・部署の両方に対するクエリを毎回書く必要がある 😢

Slide 17

Slide 17 text

NALYSYSの認可制御よりシンプルな認可制御を求めて ● アプリケーション側では、「ユーザー」「対象オブジェクト」「操作」を渡したら「できる」 or「できない」が返ってくるのが理想的 ○ 例：「ユーザー(id=1)」は、「従業員(id=123)」の「NALYスコア読み取り」をできるか ● ReBACを使うことでこのような認可クエリを実現できる

Slide 18

Slide 18 text

新たな認可制御 ReBAC

Slide 19

Slide 19 text

新たな認可制御 ReBAC ReBACとは ● ReBAC = Relation Based Access Control ● オブジェクト間の持つ関係に基づいて認可判断を行う ● Zanzibar(Googleの各種サービスの認可基盤)で用いられている手法

Slide 20

Slide 20 text

新たな認可制御 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を持ちうる

Slide 21

Slide 21 text

新たな認可制御 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

Slide 22

Slide 22 text

新たな認可制御 ReBAC ReBACにおける権限の扱い ● ReBACでは、リソース間の関係だけではなく、権限も relationで表す ● 例えば、部署情報を編集できることを表す場合 : ○ departmentがuserに対してcanEditというrelationを持てるようにする department:202 user:302 canEdit ● ただ、権限のrelation tupleを直接追加することは通常しない department:202を編集可能なリソースの1つはuser:302

Slide 23

Slide 23 text

新たな認可制御 ReBAC 間接的なrelationの定義 ● ReBACでは、既存のrelationに基づいて新しいrelationを作ることができる ● 例えば、departmentに対してviewerとeditorという2つのrelationを定義し、 ○ departmentのcanView = viewer or editor ○ departmentのcanEdit = editor ● このように定義することで、権限とその判断ロジックを分離する

Slide 24

Slide 24 text

新たな認可制御 ReBAC 間接的なrelationの例 department:202 editor user:302 canView canEdit viewer user:303 canView 実線は明示的に(relation tupleによって)付与されたrelation 点線は暗黙のうちに付与された relation

Slide 25

Slide 25 text

新たな認可制御 ReBAC typeを跨いだrelationの自動付与 ● 間接的なrelationの付与において、自身以外のrelationも参照することが可能 ● 例えば、corporationのeditorが配下departmentのeditorにもなって欲しい場合: ○ departmentのeditor = 直接付与 or editor from parent ● parentには親会社・親部署が含まれるので、これだけで再帰的に editorが付与される

Slide 26

Slide 26 text

新たな認可制御 ReBAC typeを跨いだrelationの自動付与の例 corporation:100 user:302 department:201 editor ● department#editor = editor from parentの場合 parent editor department:202 parent editor

Slide 27

Slide 27 text

新たな認可制御 ReBAC NALYSYSの認可制御を ReBACで表現してみる ● ここまで登場した概念を用いると、配下部署制御を簡単に実装できる ● 部署管理者をdepartment#managerとして表現 ○ さらに、manager from parentをこれに含める ● さらに、user#managerをmanager from belongsによって定義 ○ 所属部署のmanagerはuserのmanagerにもなる ● 最後に、user#managerがあればuser#canViewNalyScoreを付与するようにする

Slide 28

Slide 28 text

新たな認可制御 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

Slide 29

Slide 29 text

OpenFGAによるReBACの実装

Slide 30

Slide 30 text

OpenFGAによるReBACの実装 OpenFGAとは ● ReBACのオープンソース実装 ● Zanzibarの論文に登場する概念を実装している ● 高速で一貫性のある認可クエリを実行可能 ● CNCF Sandbox Projectsにも採択されている

Slide 31

Slide 31 text

OpenFGAによるReBACの実装 OpenFGAの実行形態 ● OpenFGAは認可クエリを受け付けるHTTPサーバーとして動作する ● データはMySQLやPostgreSQLなどのRDB上にストア ● 認可クエリに対するインメモリキャッシュも構成可能

Slide 32

Slide 32 text

OpenFGAによるReBACの実装 OpenFGAにおけるtypeとrelationの定義 ● OpenFGAでは、一連のtypeとrelationの定義をAuthorization Modelと呼んでいる ● サーバーにAuthorization Modelを登録する ● さらにRelation Tupleも登録することで認可クエリを実行できるようになる

Slide 33

Slide 33 text

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] ...

Slide 34

Slide 34 text

OpenFGAによるReBACの実装 NALYSYSでのOpenFGAの実装構想 ● NALYSYSでは、主に以下の用途でOpenFGAの権限制御を利用予定 ● 各APIの実行可否判断 ● 一覧系APIでのフィルタリング ● フィールドの閲覧可否判断

Slide 35

Slide 35 text

OpenFGAによるReBACの実装 NALYSYSのオブジェクトツリー概要 ● テナントを頂点として、リソース階層をそのまま表現する ● アプリケーション全体での権限はテナントの relationとして表現 tenant corporation department department corporation employee canAddCorporation canAddIpRestriction ... canListEmployees canAddEmployee ...

Slide 36

Slide 36 text

OpenFGAによるReBACの実装各APIの実行可否判断 ● 各リソースのcanXXXを用いて判断 ○ 例: ﬁndEmployeById($id)の場合、(employee:$id, canView, user:$userId)をcheck ● リソースの追加などは親コンテナの relationとして定義 ○ 例: 会社への従業員の追加は corporation#canAddEmployeeとして定義

Slide 37

Slide 37 text

OpenFGAによるReBACの実装一覧系APIでのフィルタリング ● 一覧系のAPIでは、結果のうち閲覧可能なものを返さなければならない ● これを実現するには以下の2つのパターンがある ● パターン1: 権限関係なく取得してから絞り込む ● パターン2: 閲覧可能なオブジェクトのIDを列挙して絞り込み検索

Slide 38

Slide 38 text

OpenFGAによるReBACの実装パターン1: 権限関係なく取得してから絞り込む ● 権限関係なく取得してから、全てのオブジェクトの閲覧可否を batch checkで判定 ● 既存のcanView relationなどをそのまま利用でき、直感的でわかりやすい ● 一方、検索結果の大部分が表示できない場合は非効率 ● また、取得件数が多い場合もOpenFGAへの負荷が高まってしまう ○ ページネーションの実装が前提

Slide 39

Slide 39 text

OpenFGAによるReBACの実装パターン2: 閲覧可能なオブジェクトの IDを列挙して絞り込み検索 ● 例えば、特定の会社配下しか見られない場合に予め会社 IDで絞り込むなど ● 合致するrelationを持つオブジェクトはListObjectという操作で列挙可能 ● 列挙されるオブジェクトIDが少ない時に適している ● デメリットとしては、employeeに対する権限をcorporationなどの親にリフトアップする必要がある上、アプリケーション側の認可ロジックに対する結合が増えてしまう ● 場合に応じて適切に使い分けていく必要がある

Slide 40

Slide 40 text

OpenFGAによるReBACの実装フィールドの閲覧可否判断 ● 例えば、従業員の生年月日は強い権限を持っている場合しか見られない ● GraphQLのﬁeldMiddleware機能を使って、フィールドごとの認可判断を行う ○ 認可クエリはdataloaderなどを使って適宜バッチ化

Slide 41

Slide 41 text

OpenFGAによるReBACの実装 (余談) RBACとのインピーダンスミスマッチについて ● RBACではロールから権限を参照していたが、 ReBACでRBACを再現する場合、権限からロールを参照する必要がある ○ 例えば、permissionAがroleAとroleBの両方にある場合、 permissionA: roleA or roleBと定義する必要がある ● 既存のロールを移行しようと思うとこれが分かりにくいため、トランスパイラなどによりこの逆変換を行うことを検討している

Slide 42

Slide 42 text

今後検証していきたい事項について

Slide 43

Slide 43 text

今後検証していきたい事項について認可クエリのパフォーマンス特性 ● OpenFGAは既存のRDB(PostgreSQLなど)の上にグラフを構築する ● グラフ演算がどのようなクエリに跳ねるのかは未知数 ○ 一応、andはorに比べて重たいという記述はあるが、情報が少ない ● 複雑なクエリがどのようなSQLを呼ぶのかを検証していきたい

Slide 44

Slide 44 text

今後検証していきたい事項について認可モデルの進化性 ● typeやrelationの追加・削除を無停止でうまいことロールアウトできるか ● typeやrelationの定義(authorization model)は、具体的なrelationの内容(relation tuples)とは完全に独立に更新可能となっている ○ 無効なtupleは単純に無視されるため ● authroziation modelを無理ない方法で複数保持できるかを検証したい ○ 使う側で必ずauthorization modelのIDを指定する必要があるので、毎回手動で更新するのは大変そう

Slide 45

Slide 45 text

まとめ

Slide 46

Slide 46 text

まとめ ● OpenFGAとReBACを用いることでよりきめ細かい認可制御が可能となる ● 一方、RBACと同じような体験も得たい場合は工夫が必要 ● 新しい技術で障壁もあるが、複雑な認可モデルの実現方法としてはかなり有力な選択肢になりうる本日のポイント

Slide 47

Slide 47 text

ご清聴ありがとうございました！