メインコンテンツへスキップ
Role-based Access Control（RBAC）とは、組織内での役割を基にして、ユーザーに許可を割り当てるという考え方のことです。アクセスの管理にシンプルで扱いやすいアプローチを取り入れることで、ユーザーに個別に権限を割り当てるよりも、エラーの発生を少なく抑えられるようになっています。 RBACをRole Management（ロール管理）に使用する場合、ユーザーが必要としているものを分析し、共通の責任を基に役割のグループにまとめます。そして、それぞれのユーザーに1つまたは複数のロールを割り当て、それぞれのロールに1つまたは複数の権限を割り当てます。関係を「ユーザーとロール」、「ロールと権限」として扱えば、ユーザーを個別に管理するのではなく、ロールに割り当てた権限がユーザーに適用されることになるため、ユーザーの割り当てがよりシンプルになります。 たとえば、RBACを使用して人事管理アプリケーションへのアクセスを制御している場合、社員の詳細情報を更新できるロールを人事部の担当者に割り当てて、他の社員は自分の情報のみを閲覧できるようにすることができます。 アクセス制御の戦略を立てる際には、職務を遂行できるようにする必要最小限の権限をユーザーに割り当てるというのが、ベストプラクティスになっています。
より堅牢な認可モデルについては、「Fine-Grained Authorization（FGA）」に記載されている属性ベースと関係ベースの認可を参照してください。

​
RBACの利点

ロールの要件さえ厳密に守っていれば、RBACによってアクセス管理の作業がより簡単になります。RBACを使用すると：
  • 反復して適用できる体系的な権限の割り当てを作成できる
  • ユーザーの権限を手軽に監査し、特定した問題を解決できる
  • ロールを素早く追加・変更して、各種のAPIに実装できる
  • ユーザー権限を割り当てる際の潜在的なエラーが低減する
  • 予め定義したロールを使ってサードパーティのユーザーを統合できる
  • 守秘義務やプライバシーに関する規制や法的要件がより効果的に順守される

​
RBACのモデル

​
ロール

ロールとは、本質的に、ユーザーに適用できる権限の集まりです。ロールを利用することで、権限をユーザーに個別に割り当てる場合よりも、権限の追加・削除・調整を素早く処理できます。ユーザーベースの規模と複雑性が増すにつれて、ロールは特に便利になります。 さまざまなAPIに定義された許可を集めるのに、ロールを使用することもできます。たとえば、ユーザーが顧客にニュースレターを作成して配信できるマーケティングモジュールがあるとします。マーケティングコンテンツの専門企業がすべてのニュースレターを作成して、配信の準備をします。同様に、ユーザーがイベント登録を作成、公開して管理できるイベントモジュールがあるとします。イベントを制作するのは、イベントコーディネーターです。マーケティング部のVPがニュースレターとイベントを承認すると、VPのアシスタントがイベントについて公表してニュースレターを配信します。この事例では、ニュースレターAPIにdistribute:newsletters 権限を、イベントAPIにpublish:events権限を付与できます。そして、これらの権限を併せ持つ「Marketing Publisher」という名前のロールを作成し、このロールをマーケティング部VPのアシスタントに割り当てます。 さらに、組織固有のさまざまなロールを組織メンバーに追加して、エンドユーザーがログインに使用する組織を基に、それらのロールをアプリケーションでのアクセス許可に使用します。これは、あるユーザーが1つの組織では権限があるのに、他の組織では権限がないことがあるような、複数テナントのSaaSモデルでは特に便利です。

​
重複するロールの割り当て

RBACは加法モデルであるため、ロールの割り当てが重複した場合、有効な権限は、ロールの割り当ての和集合になります。 たとえば、イベントアプリケーションにデータを提供するAPIがあるとします。「Organizer」というロールを作成して、イベントの表示、作成、編集の権限を割り当てます。また「Registrant」というロールを作成して、イベントの表示と登録の権限を割り当てます。「Organizer」と「Registrant」の両方のロールがあるユーザーには、イベントの表示、作成、編集、そして登録の権限があることになります。

​
Auth0でのRole-based Access Control（RBAC）

現在、Role-based Access Control（RBAC）の実装に2つの方法を提供しており、API独自の内部アクセス制御システムの代わりに、または、それとの組み合わせで、これらの方法を使用することができます。 Authorization Extension（認可拡張機能）の機能性と同等になるように、Authorization Core（認可コア）の機能セットの拡張を進めているところです。新しいコアのRBAC実装は、性能と拡張性を向上しながら、究極的にはAuthorization Extension（認可拡張機能）よりも柔軟なRBACシステムを提供する計画です。 現時点では、どちらもRBACの主要な機能を実装し、APIに定義したカスタムのスコープを、権限としてユーザーに割り当てたスコープに制約できるようにします。比較については、「認可コアと認可拡張機能」をお読みください。
Authorization Core（認可コア）の機能セットとAuthorization Extension（認可拡張機能）は完全に別途の機能です。グループ、ロール、権限を管理するには、それらの作成に使用した方の機能を使う必要があります。
Delegated Administration Extension（DAE：委任管理拡張機能）とAuthorization Core（認可コア）は全く別の機能ですが、Authorization Core（認可コア）機能セットを使用すると、ActionsでDAEのロールを作成し、管理することができます。方法については、「サンプルユースケース：認可のあるアクション」を参照してください。

​
RBACの拡張

ルールを使用すると、ユーザーの部署、時刻、アクセスの場所、その他のユーザーまたはAPIの属性（ユーザー名、セキュリティクリアランス、API名など）といった属性の組み合わせを基にアクセスを制限し、より細かく制御できるようになります。 ルールと認可ポリシーの使用については、「ルールと認可ポリシー」をご覧ください。

​
もっと詳しく