Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OpenFGAで拓く次世代認可基盤 〜予告編〜
Search
Tech Leverages
March 04, 2025
0
170
OpenFGAで拓く次世代認可基盤 〜予告編〜
Tech Leverages
March 04, 2025
Tweet
Share
More Decks by Tech Leverages
See All by Tech Leverages
ディメンショナルモデリングを軽く語る
leveragestech
0
170
アクターモデルによる効率的な分散システム設計
leveragestech
0
160
Terraform による運用効率化の取り組みと最新のテストアプローチの紹介
leveragestech
0
170
リソース・管理効率の向上だけでない、分散システムとしてのTiDBの魅力
leveragestech
0
170
作ってわかる!非同期ランタイム
leveragestech
0
160
レバテック開発部 技術広報 これまでとこれから
leveragestech
0
87
改めて「型」について考えてみよう
leveragestech
1
58
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
1.2k
Biome で Format と Lint のストレスをゼロに
leveragestech
0
61
Featured
See All Featured
Done Done
chrislema
182
16k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Adopting Sorbet at Scale
ufuk
75
9.2k
Typedesign – Prime Four
hannesfritz
41
2.5k
Agile that works and the tools we love
rasmusluckow
328
21k
Designing Experiences People Love
moore
140
23k
GraphQLとの向き合い方2022年版
quramy
44
14k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Transcript
OpenFGAで拓く次世代認可基盤 〜予告編〜 NALYSYS開発部 桐生直輝 2025/02/05
自己紹介 桐生直輝 (25歳) • 入社:2023年3月 • 所属:NALYSYS開発部 ◦ リードエンジニアやらせていただいてます ◦
主にバックエンド〜インフラ担当 • 趣味:コンピュータいじり、自宅サーバー構築 ◦ おうちKubernetes運用中です ◦ 最近は少し手が回らないがち・・
サービス紹介 • 社員のエンゲージメントを計測できる SaaS • パルスサーベイ(NALYアンケート) • 適性検査PIONALY • 性格診断NALYGRAM
今回のテーマ 認証と認可の「認可」のほう • 認証: アクセスしてきたユーザーが「誰であるか」を判断すること • 認可: アクセスしてきたユーザーが「何をして良いか」判断すること ◦ 基本的に認証ができている前提
• 今回は認証は扱いません
今回のテーマ 認可制御の新たな道を切り開きたい! • 従来の認可制御では、RBACと呼ばれるモデルが多く用いられてきた ◦ NALYSYSもRBACをベースとした認可方式を利用中 • 一方、複雑なシナリオではRBACだけでは不十分な場合も・・・ → 今回は、ReBACと呼ばれる新たな制御方式をご紹介
今回のテーマ 今回は予告編なので・・・ • まだ机上で検討中の内容がほとんどです • もしかしたら実装できない内容を含んでいるかも ◦ 変なところがあればこっそり教えてください
今回のテーマ アジェンダ 1. NALYSYSにおける認可制御の課題 2. 新たな認可制御ReBACとは何か 3. OpenFGAによるReBACの実装 4. 今後検証していきたい事項について
NALYSYSにおける認可制御の課題
NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • RBAC: 権限をひとまとめにしたロールを作り、それをユーザーに割り当てる ロール モチベーション管理
管理者 read:全員の従業員情報 権限 read:全員のNALYサーベイ 権限 write:全員のNALYサーベイ 権限 ロール モチベーション管理 メンバー read:自分の従業員情報 権限 read:自分の性格診断結果 権限 write:自分のNALYサーベイ 権限
NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • APIがアクセスを検証するときは、要求された権限があるかを判断する ロール モチベーション管理 管理者
read:全員の従業員情報 権限 read:全員のNALYサーベイ 権限 write:全員のNALYサーベイ 権限 NALYサーベイ 一覧API • read:全員のNALYサーベイがあるかチェック 付与
NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • 操作を行う側では、必要なpermissionがあるかどうかだけを確認すれば良い ◦ 例えば、従業員情報の取得 APIで、従業員情報の読み取り権限が「モチベーション管理
管理 者」と「年末調整 管理者」のどちらからやってきたかなどは気にする必要がない • これだけでも結構制御が可能だが、全てのケースをカバーできるわけではない
NALYSYSの認可制御 NALYSYSではRBACを利用 • 権限は、リソース + 動詞(verb)で構成される ◦ 例: 全員の従業員情報+ read
-> 全ての従業員情報を読み取れる • 操作を行う側では、必要なpermissionがあるかどうかだけを確認すれば良い ◦ 例えば、従業員情報の取得 APIで、従業員情報の読み取り権限が「モチベーション管理 管理 者」と「年末調整 管理者」のどちらからやってきたかなどは気にする必要がない • これだけでも結構制御が可能だが、全てのケースをカバーできるわけではない
NALYSYSの認可制御 RBACだけだと完結できない例 • NALYSYSには組織階層がある 会社1 部署A 子部署1 子部署2 チーム1 チーム2
子部署3 部署B
NALYSYSの認可制御 RBACだけだと完結できない例 • 「モチ管 リーダー」だと、自分が管理者の部署内の NALYスコアだけが見られる 会社1 部署A 子部署1 子部署2
チーム1 チーム2 子部署3 部署B 子部署1の管理者 NALYスコアの閲覧可能範囲
NALYSYSの認可制御 RBACだけだと完結できない例 • 単純なRBACだと、範囲の制限はアプリケーションのロジックでやる必要がある • 例: 特定の従業員のNALYスコアを取得するAPI ◦ 権限「read:全員のNALYスコア」or「read:同じ会社の人のNALYスコア」or「read:配下部署の人の NALYスコア」があれば実行は可能
◦ 「read:同じ会社の人のNALYスコア」以下の権限なら、会社 IDも追加でチェック ◦ 「read:配下部署の人のNALYスコア」以下の権限なら、部署 IDも追加でチェック
NALYSYSの認可制御 部署配下制御は特に地獄! • 配下部署かを判断するには、「間接的な配下部署」も考慮する必要がある • つまり、部署の再帰的な解決を毎回行う必要がある • さらに、会社レベルでのチェックも別で存在する → 会社・部署の両方に対するクエリを毎回書く必要がある
😢
NALYSYSの認可制御 よりシンプルな認可制御を求めて • アプリケーション側では、「ユーザー」「対象オブジェクト」「操作」を渡したら「できる」 or「でき ない」が返ってくるのが理想的 ◦ 例:「ユーザー(id=1)」は、「従業員(id=123)」の「NALYスコア読み取り」をできるか • ReBACを使うことでこのような認可クエリを実現できる
新たな認可制御 ReBAC
新たな認可制御 ReBAC ReBACとは • ReBAC = Relation Based Access Control
• オブジェクト間の持つ関係に基づいて認可判断を行う • Zanzibar(Googleの各種サービスの認可基盤)で用いられている手法
新たな認可制御 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を持ちうる
新たな認可制御 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
新たな認可制御 ReBAC ReBACにおける権限の扱い • ReBACでは、リソース間の関係だけではなく、権限も relationで表す • 例えば、部署情報を編集できることを表す場合 : ◦
departmentがuserに対してcanEditというrelationを持てるようにする department:202 user:302 canEdit • ただ、権限のrelation tupleを直接追加することは通常しない department:202を編集可能なリソースの1つはuser:302
新たな認可制御 ReBAC 間接的なrelationの定義 • ReBACでは、既存のrelationに基づいて新しいrelationを作ることができる • 例えば、departmentに対してviewerとeditorという2つのrelationを定義し、 ◦ departmentのcanView =
viewer or editor ◦ departmentのcanEdit = editor • このように定義することで、権限とその判断ロジックを分離する
新たな認可制御 ReBAC 間接的なrelationの例 department:202 editor user:302 canView canEdit viewer user:303
canView 実線は明示的に(relation tupleによって)付与されたrelation 点線は暗黙のうちに付与された relation
新たな認可制御 ReBAC typeを跨いだrelationの自動付与 • 間接的なrelationの付与において、自身以外のrelationも参照することが可能 • 例えば、corporationのeditorが配下departmentのeditorにもなって欲しい場合: ◦ departmentのeditor =
直接付与 or editor from parent • parentには親会社・親部署が含まれるので、これだけで再帰的に editorが付与される
新たな認可制御 ReBAC typeを跨いだrelationの自動付与の例 corporation:100 user:302 department:201 editor • department#editor =
editor from parentの場合 parent editor department:202 parent editor
新たな認可制御 ReBAC NALYSYSの認可制御を ReBACで表現してみる • ここまで登場した概念を用いると、配下部署制御を簡単に実装できる • 部署管理者をdepartment#managerとして表現 ◦ さらに、manager
from parentをこれに含める • さらに、user#managerをmanager from belongsによって定義 ◦ 所属部署のmanagerはuserのmanagerにもなる • 最後に、user#managerがあればuser#canViewNalyScoreを付与するようにする
新たな認可制御 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
OpenFGAによるReBACの実装
OpenFGAによるReBACの実装 OpenFGAとは • ReBACのオープンソース実装 • Zanzibarの論文に登場する概念を実装している • 高速で一貫性のある認可クエリを実行可能 • CNCF
Sandbox Projectsにも採択されている
OpenFGAによるReBACの実装 OpenFGAの実行形態 • OpenFGAは認可クエリを受け付けるHTTPサーバーとして動作する • データはMySQLやPostgreSQLなどのRDB上にストア • 認可クエリに対するインメモリキャッシュも構成可能
OpenFGAによるReBACの実装 OpenFGAにおけるtypeとrelationの定義 • OpenFGAでは、一連のtypeとrelationの定義をAuthorization Modelと呼んでいる • サーバーにAuthorization Modelを登録する • さらにRelation
Tupleも登録することで認可クエリを実行できるようになる
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] ...
OpenFGAによるReBACの実装 NALYSYSでのOpenFGAの実装構想 • NALYSYSでは、主に以下の用途でOpenFGAの権限制御を利用予定 • 各APIの実行可否判断 • 一覧系APIでのフィルタリング • フィールドの閲覧可否判断
OpenFGAによるReBACの実装 NALYSYSのオブジェクトツリー概要 • テナントを頂点として、リソース階層をそのまま表現する • アプリケーション全体での権限はテナントの relationとして表現 tenant corporation department
department corporation employee canAddCorporation canAddIpRestriction ... canListEmployees canAddEmployee ...
OpenFGAによるReBACの実装 各APIの実行可否判断 • 各リソースのcanXXXを用いて判断 ◦ 例: findEmployeById($id)の場合、(employee:$id, canView, user:$userId)をcheck •
リソースの追加などは親コンテナの relationとして定義 ◦ 例: 会社への従業員の追加は corporation#canAddEmployeeとして定義
OpenFGAによるReBACの実装 一覧系APIでのフィルタリング • 一覧系のAPIでは、結果のうち閲覧可能なものを返さなければならない • これを実現するには以下の2つのパターンがある • パターン1: 権限関係なく取得してから絞り込む •
パターン2: 閲覧可能なオブジェクトのIDを列挙して絞り込み検索
OpenFGAによるReBACの実装 パターン1: 権限関係なく取得してから絞り込む • 権限関係なく取得してから、全てのオブジェクトの閲覧可否を batch checkで判定 • 既存のcanView relationなどをそのまま利用でき、直感的でわかりやすい
• 一方、検索結果の大部分が表示できない場合は非効率 • また、取得件数が多い場合もOpenFGAへの負荷が高まってしまう ◦ ページネーションの実装が前提
OpenFGAによるReBACの実装 パターン2: 閲覧可能なオブジェクトの IDを列挙して絞り込み検索 • 例えば、特定の会社配下しか見られない場合に予め会社 IDで絞り込むなど • 合致するrelationを持つオブジェクトはListObjectという操作で列挙可能 •
列挙されるオブジェクトIDが少ない時に適している • デメリットとしては、employeeに対する権限をcorporationなどの親にリフトアップする必要が ある上、アプリケーション側の認可ロジックに対する結合が増えてしまう • 場合に応じて適切に使い分けていく必要がある
OpenFGAによるReBACの実装 フィールドの閲覧可否判断 • 例えば、従業員の生年月日は強い権限を持っている場合しか見られない • GraphQLのfieldMiddleware機能を使って、フィールドごとの認可判断を行う ◦ 認可クエリはdataloaderなどを使って適宜バッチ化
OpenFGAによるReBACの実装 (余談) RBACとのインピーダンスミスマッチについて • RBACではロールから権限を参照していたが、 ReBACでRBACを再現する場合、権限から ロールを参照する必要がある ◦ 例えば、permissionAがroleAとroleBの両方にある場合、 permissionA:
roleA or roleBと定義す る必要がある • 既存のロールを移行しようと思うとこれが分かりにくいため、トランスパイラなどによりこの逆 変換を行うことを検討している
今後検証していきたい事項について
今後検証していきたい事項について 認可クエリのパフォーマンス特性 • OpenFGAは既存のRDB(PostgreSQLなど)の上にグラフを構築する • グラフ演算がどのようなクエリに跳ねるのかは未知数 ◦ 一応、andはorに比べて重たいという記述はあるが、情報が少ない • 複雑なクエリがどのようなSQLを呼ぶのかを検証していきたい
今後検証していきたい事項について 認可モデルの進化性 • typeやrelationの追加・削除を無停止でうまいことロールアウトできるか • typeやrelationの定義(authorization model)は、具体的なrelationの内容(relation tuples)とは完全に独立に更新可能となっている ◦ 無効なtupleは単純に無視されるため
• authroziation modelを無理ない方法で複数保持できるかを検証したい ◦ 使う側で必ずauthorization modelのIDを指定する必要があるので、毎回手動で更新するのは 大変そう
まとめ
まとめ • OpenFGAとReBACを用いることでよりきめ細かい認可制御が可能となる • 一方、RBACと同じような体験も得たい場合は工夫が必要 • 新しい技術で障壁もあるが、複雑な認可モデルの実現方法としてはかなり有力な選択肢に なりうる 本日のポイント
ご清聴ありがとうございました!