モダンアプリケーションにおけるロールと権限の管理方法

ユーザーがドキュメントを閲覧できるとします。しかし、それを共有できるでしょうか?誰とでも共有できるのか、それとも組織内のみでしょうか?付与したアクセス権を取り消すことはできるでしょうか?これらの疑問は、従来のロールベースアクセス制御がモダンアプリケーションにおいて機能しなくなる理由を浮き彫りにします。

「admin」「editor」「viewer」といった静的なロールは、アプリケーションがシンプルだった時代には有効でした。しかし今日の協調的でマルチテナント型のSaaS製品には、より柔軟な仕組みが必要です。本記事では、モダンな認可パターンがこれらの課題をどのように解決するか、そして業界がロールのみの考え方から細粒度の認可へと移行した理由を解説します。

従来のRBACが不十分な理由

ロールベースアクセス制御(RBAC)は、ロールを通じて権限を割り当てます。ユーザーは「editor」ロールを取得し、それによって事前定義された一連の権限が付与されます。シンプルで直感的です。

問題はアプリケーションが成長するにつれて現れます。プロジェクト管理ツールを考えてみましょう。ユーザーはプロジェクトごと、ワークスペースごと、ドキュメントタイプごとに異なるアクセスレベルが必要です。すると「project-A-editor」や「workspace-B-admin」といったロールを作り始めることになります。このロールの爆発的増加により、システムは管理不能になります。

RBACは関係性に基づく質問にも苦戦します。「このユーザーはこのドキュメントを編集できるか?」という問いは、そのユーザーがドキュメントを所有しているか、誰かが共有したか、またはアクセス権を持つチームに所属しているかに依存します。静的なロールではこれらの条件をエレガントに表現できません。

モダンな認可パターン

リレーションシップベースアクセス制御(ReBAC)

ReBACはエンティティ間の関係を通じてアクセスを決定します。「このユーザーはeditorロールを持っているか?」ではなく、「このユーザーはこのドキュメントに対してeditorの関係を持っているか?」と問います。

GoogleのZanzibarシステムが、このアプローチを大規模に先駆けて実装しました。Google Docを共有すると、関係性が作成されます。システムはこれらの関係をトラバースして権限の質問に答えます。OpenFGA、SpiceDB、Permifyなどのツールは、あらゆる規模のアプリケーション向けにZanzibarにインスパイアされたモデルを実装しています。

ReBACは協調シナリオを自然に処理します。共有、チームメンバーシップ、組織階層が、不格好なロールの回避策ではなく、ファーストクラスの概念になります。

属性ベースアクセス制御(ABAC)

ABACは、ユーザー、リソース、コンテキストの属性に基づいてアクセスを評価します。ポリシーは次のように述べるかもしれません:「ユーザーの部署がドキュメントの部署と一致し、かつリクエストが営業時間内に発生した場合、ユーザーはドキュメントにアクセスできる」

このモデルは文脈依存のルールに優れています。医療アプリケーションはABACを使用してHIPAA要件を強制します—アクセスは患者と医療提供者の関係、データの機密性、アクセスのコンテキストに依存します。

RBAC vs ReBAC:それぞれをいつ使うべきか

RBACは、明確で静的な権限境界を持つアプリケーションに適しています。明確に定義されたユーザータイプを持つ社内ツールは、そのシンプルさから恩恵を受けます。

ReBACは、権限がリソースの所有権、共有、または組織構造に依存する場合により適しています。「共有」機能やマルチテナンシーを持つアプリケーションはReBACを検討すべきです。

ほとんどの本番システムは両方を組み合わせています。RBACは広範なカテゴリ(管理者vs一般ユーザー)を処理し、ReBACはリソースレベルの権限を管理します。

Webアプリケーションにおけるアクセス制御のアーキテクチャパターン

認証と認可の分離

認証は「このユーザーは誰か?」に答えます。認可は「彼らは何ができるか?」に答えます。モダンなアーキテクチャは、これらを別々の関心事として扱い、それぞれに専用のサービスを持ちます。

IDプロバイダーが認証を処理します。別の認可サービス—社内構築でもマネージドでも—が権限の決定を処理します。この分離により、各システムが独立して進化できます。

Policy-as-Code

モダンな認可パターンは、データベース設定ではなくコードとしてルールを表現することを好みます。Policy-as-codeとは、認可ロジックがバージョン管理に存在し、プルリクエストでレビューされ、標準的なパイプラインを通じてデプロイされることを意味します。

Open Policy Agent (OPA)はポリシー定義にRegoを使用します。AWSが開発したCedarは別のポリシー言語を提供します。これらのツールは認可ロジックをテスト可能かつ監査可能にします。

集中型ポリシー、分散型実行

スケールするパターン:ポリシーを集中的に定義し、各サービスで実行します。ポリシーエンジンがルールを維持します。各マイクロサービスはエンジンに権限決定を問い合わせ、パフォーマンスのために結果をキャッシュすることが多いです。

このアーキテクチャは、単一障害点を避けながら、サービス間で認可の一貫性を保ちます。

フロントエンドへの影響

バックエンドがすべての権限決定の信頼できる情報源であり続けます。セキュリティについてフロントエンドを信頼してはいけません。

とはいえ、フロントエンドは良好なUXのために権限情報が必要です。機能ゲーティング—ユーザーがクリックできないボタンを非表示にする、送信できないフォームを無効にする—には、クライアント側で権限を知る必要があります。パターンは単純です:UI決定には権限チェック(例:「このユーザーはこのアクションを実行できるか?」)を使用しますが、常にサーバー側で検証します。

CASLのようなライブラリは、実際の実行をサーバー側に保ちながら、クライアント側の権限ロジックの管理を支援します。

結論

細粒度の認可は実験的なものではありません—これがモダンアプリケーションの動作方法です。Google、GitHub、Notionはすべて関係性ベースのモデルを使用しています。ポリシーエンジンはあらゆる規模の企業で認可を支えています。

現在のRBACが苦戦している箇所を特定することから始めましょう。すべての権限の組み合わせに対してロールを作成している場合、または共有とコラボレーションが後付けのように感じられる場合、モダンな認可パターンはシステムをシンプルにしながら、より強力にします。

「このユーザーはどのロールを持っているか?」から「このユーザーはこのリソースに対してどのような関係を持っているか?」への移行は、権限についての考え方を変えます。これは、ユーザーがモダンアプリケーションと実際にどのように対話するかについて、より優れたメンタルモデルです。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.