Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for Tech Leverages Tech Leverages
March 04, 2025
2.3k

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

Avatar for Tech Leverages

Tech Leverages

March 04, 2025
Tweet

More Decks by Tech Leverages

Transcript

  1. 自己紹介 桐生直輝 (25歳) • 入社:2023年3月 • 所属:NALYSYS開発部 ◦ リードエンジニアやらせていただいてます ◦

    主にバックエンド〜インフラ担当 • 趣味:コンピュータいじり、自宅サーバー構築 ◦ おうちKubernetes運用中です ◦ 最近は少し手が回らないがち・・
  2. NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • RBAC: 権限をひとまとめにしたロールを作り、それをユーザーに割り当てる ロール モチベーション管理

    管理者 read:全員の従業員情報 権限 read:全員のNALYサーベイ 権限 write:全員のNALYサーベイ 権限 ロール モチベーション管理 メンバー read:自分の従業員情報 権限 read:自分の性格診断結果 権限 write:自分のNALYサーベイ 権限
  3. NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • APIがアクセスを検証するときは、要求された権限があるかを判断する ロール モチベーション管理 管理者

    read:全員の従業員情報 権限 read:全員のNALYサーベイ 権限 write:全員のNALYサーベイ 権限 NALYサーベイ 一覧API • read:全員のNALYサーベイがあるかチェック 付与
  4. NALYSYSの認可制御 NALYSYSではRBAC(Role Base Access Control)を利用 • 操作を行う側では、必要なpermissionがあるかどうかだけを確認すれば良い ◦ 例えば、従業員情報の取得 APIで、従業員情報の読み取り権限が「モチベーション管理

    管理 者」と「年末調整 管理者」のどちらからやってきたかなどは気にする必要がない • これだけでも結構制御が可能だが、全てのケースをカバーできるわけではない
  5. NALYSYSの認可制御 NALYSYSではRBACを利用 • 権限は、リソース + 動詞(verb)で構成される ◦ 例: 全員の従業員情報+ read

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

    • オブジェクト間の持つ関係に基づいて認可判断を行う • Zanzibar(Googleの各種サービスの認可基盤)で用いられている手法
  7. 新たな認可制御 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を持ちうる
  8. 新たな認可制御 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
  9. 新たな認可制御 ReBAC ReBACにおける権限の扱い • ReBACでは、リソース間の関係だけではなく、権限も relationで表す • 例えば、部署情報を編集できることを表す場合 : ◦

    departmentがuserに対してcanEditというrelationを持てるようにする department:202 user:302 canEdit • ただ、権限のrelation tupleを直接追加することは通常しない department:202を編集可能なリソースの1つはuser:302
  10. 新たな認可制御 ReBAC 間接的なrelationの例 department:202 editor user:302 canView canEdit viewer user:303

    canView 実線は明示的に(relation tupleによって)付与されたrelation 点線は暗黙のうちに付与された relation
  11. 新たな認可制御 ReBAC NALYSYSの認可制御を ReBACで表現してみる • ここまで登場した概念を用いると、配下部署制御を簡単に実装できる • 部署管理者をdepartment#managerとして表現 ◦ さらに、manager

    from parentをこれに含める • さらに、user#managerをmanager from belongsによって定義 ◦ 所属部署のmanagerはuserのmanagerにもなる • 最後に、user#managerがあればuser#canViewNalyScoreを付与するようにする
  12. 新たな認可制御 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
  13. 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] ...
  14. OpenFGAによるReBACの実装 各APIの実行可否判断 • 各リソースのcanXXXを用いて判断 ◦ 例: findEmployeById($id)の場合、(employee:$id, canView, user:$userId)をcheck •

    リソースの追加などは親コンテナの relationとして定義 ◦ 例: 会社への従業員の追加は corporation#canAddEmployeeとして定義
  15. OpenFGAによるReBACの実装 パターン1: 権限関係なく取得してから絞り込む • 権限関係なく取得してから、全てのオブジェクトの閲覧可否を batch checkで判定 • 既存のcanView relationなどをそのまま利用でき、直感的でわかりやすい

    • 一方、検索結果の大部分が表示できない場合は非効率 • また、取得件数が多い場合もOpenFGAへの負荷が高まってしまう ◦ ページネーションの実装が前提
  16. OpenFGAによるReBACの実装 パターン2: 閲覧可能なオブジェクトの IDを列挙して絞り込み検索 • 例えば、特定の会社配下しか見られない場合に予め会社 IDで絞り込むなど • 合致するrelationを持つオブジェクトはListObjectという操作で列挙可能 •

    列挙されるオブジェクトIDが少ない時に適している • デメリットとしては、employeeに対する権限をcorporationなどの親にリフトアップする必要が ある上、アプリケーション側の認可ロジックに対する結合が増えてしまう • 場合に応じて適切に使い分けていく必要がある
  17. OpenFGAによるReBACの実装 (余談) RBACとのインピーダンスミスマッチについて • RBACではロールから権限を参照していたが、 ReBACでRBACを再現する場合、権限から ロールを参照する必要がある ◦ 例えば、permissionAがroleAとroleBの両方にある場合、 permissionA:

    roleA or roleBと定義す る必要がある • 既存のロールを移行しようと思うとこれが分かりにくいため、トランスパイラなどによりこの逆 変換を行うことを検討している