Googleドライブのような、きめ細かいアクセス制御を実装できるオープンソースの認可ソリューション「OpenFGA」に入門してみた

新屋司

2024.03.09

最近、Oktaから「Okta FGA」という新しいSaaSサービスがリリースされました。このサービスは、OpenFGAというオープンソースの認可ソリューションに基づいており、細かいアクセス制御を実現するためのものです。OpenFGAについてさらに詳しく知りたい方は、OpenFGAの公式ドキュメントをご覧ください。この記事ではFGAの概念や機能性を整理しつつ、私自身の見解をまとめたいと思います。

Oktaのプレスリリースに関する詳細は、こちらをご覧ください。

全体像

まずは全体を俯瞰して登場人物を整理します。

OpenFGAは認可サーバー上で動作する認可のシステムです。

OpenFGAとは

OpenFGAは、2022年にAuth0/Oktaによって公開されたオープンソースの細粒度アクセス制御（Fine-Grained Authorization）システムです。

OpenFGAは、ZanzibarというGoogle Drive、Google Map、YoutubeなどのGoogleサービスで利用されているグローバル認証システムからインスピレーションを得ており、アクセス制御リスト（ACL）、ロールベースのアクセス制御（RBAC）、属性ベースのアクセス制御（ABAC）などの従来のアクセス制御モデルを超えた柔軟性とパフォーマンスを備えています。

リポジトリはこちら

従来のアクセス制御モデルにおける課題

RBAC

RBACは、ユーザーにロールを割り当て、そのロールに応じてアクセス権限を管理するモデルです。しかし、RBACには以下のような課題がありました。

静的な権限割り当て: RBACでは、ロールに基づいて一括で権限を割り当てるため、ユーザーの状況やコンテキストに応じた動的な権限管理が困難です。
大量のロール: 複雑なビジネスルールを反映しようとすると、非常に多くのロールが必要になり、管理が煩雑になります。
限定的な柔軟性: あらゆるシナリオをカバーするためには、多数のロールと権限の組み合わせが必要になり、システムが複雑化します。

個人的に付け加えたい課題が、認可ロジックをアプリケーションコードに直接記述しなければならない点です。こうなると認可処理が分散するためメンテナンスするのがとても大変です。

ABAC

ABACは、ユーザーやリソースの属性に基づいてアクセス権限を動的に決定するモデルです。ABACは以下のような課題を持っています。

ポリシーの複雑さ: 属性を使用して細かいアクセスルールを定義することができますが、ポリシーが非常に複雑になる可能性があります。
パフォーマンスの問題: 属性に基づくポリシー評価は、システムのパフォーマンスに影響を与える可能性があり、特に大規模なシステムでは顕著です。
管理の難しさ: 多くの属性とルールを管理することは、時間がかかりエラーを起こしやすい作業になります。

弊社の過去記事でABACが紹介されています。こちらも参照ください。

OpenFGAだと何が嬉しいのか

端的に言うと、Google Driveのような複雑なアクセス制御を、直感的かつシンプルに構築できるようになります。

OpenFGAはReBAC（Relationship-based access control）というオブジェクト同士の「関係性」に着目したアクセス制御を行います。

Google Driveの例に戻ると、Google Driveには、アクセス対象であるドキュメントの他に、フォルダー、ユーザー、ユーザーグループといったオブジェクト存在し、それらが互いに「関係」を持っていると整理できます。

ドキュメントはフォルダーと親子の関係を持つ、ドキュメントとフォルダーはユーザーが所有する関係を持つ、ユーザーはグループに所属する関係を持つ、と言った感じです。

これにより、ユーザーがドキュメントにアクセスできるかどうかは

ユーザーが、ドキュメントの所有者か
ユーザーが、ドキュメントの親であるフォルダーの所有者か
ユーザーが、フォルダーの所有者であるグループに所属しているか
ユーザーが、ドキュメントの所有者からアクセス権限をもらっているか

を確認すればよいことになります。

ReBACのモデル定義を眺めてみる

以下のシナリオは openfga playground で実行することができます。

シナリオ

会社には複数の部署があり、各部署にはプロジェクトがあります。

各プロジェクトにはドキュメントがあり、以下のアクセス制御ポリシーを適用したいとします。

部署のマネージャーは、その部署のすべてのプロジェクトのドキュメントにアクセスできる。
プロジェクトのメンバーは、自分が属するプロジェクトのドキュメントにのみアクセスできる。
特定のドキュメントは、プロジェクト外の特定のユーザーにも共有されることがある。

モデル定義

type user

type department
  relations
    define manager: [user]

type project
  relations
    define member: [user]
    define part_of: [department]

type document
  relations
    define can_read: [user, user:*, project#member, department#manager]
    define owner: [project]
    define shared_with: [user]

タプルの例

タプルとは、モデルに対して挿入する権限情報レコードのようなものです。

(department:marketing#manager, user:alice)
(project:ad_campaign#member, user:bob)
(project:ad_campaign#part_of, department:marketing)
(document:campaign_plan#owner, project:ad_campaign)
(document:campaign_plan#shared_with, user:carol)

クエリの例

モデルとタプルを定義した後、以下のようなクエリを流すことで確認ができます。

クエリの形式としては

「Is X Related To Y As Z?」

「Who Is Related To Y As Z?」

です。

is user:alice related to department:marketing as manager?
who is related to department:marketing as manager?

クエリの結果は以下のようになりました。

その他

OpenFGAの最も注目すべき特徴として、先に述べたReBAC（Relationship-Based Access Control）が挙げられますが、その他にも私が特に注目したい点がいくつかあります。

権限情報を格納するデータストアとして、インメモリ、PostgreSQL、MySQLのいずれかを選択できる柔軟性があります。
ストアへの読み書きAPIはHTTPに加えてgRPCにも対応しており、さまざまなシステム環境に適応できます。
DockerやKubernetesに対応しており、Helm Chartのテンプレートが用意されているため、コンテナオーケストレーション環境でのデプロイが容易です。

また、オープンソース版のOpenFGAとは別に、「Okta OpenFGA」というSaaS版が提供されています。SaaS版にはFreeプランとEnterpriseプランがあり、Freeプランを利用すればサーバー構築の手間なくOpenFGAを試すことが可能です。SaaS版の詳細については、Okta OpenFGAのドキュメントを参照してください。