メインコンテンツへスキップ
ロールベースアクセス制御 (RBAC) とは、組織内での役割に基づいてユーザーに権限を割り当てる考え方です。ユーザーごとに個別に権限を割り当てる方法よりもミスが起こりにくく、シンプルで管理しやすいアクセス管理のアプローチを実現できます。 ロール管理に RBAC を使用する場合は、ユーザーのニーズを分析し、共通の責務に基づいてロールに分類します。次に、各ユーザーに 1 つ以上のロールを割り当て、各ロールに 1 つ以上の権限を割り当てます。ユーザーとロール、ならびにロールと権限の関係を定義することで、ユーザーごとに個別管理する必要がなくなり、それぞれのロールに割り当てられた権限に応じたアクセス権を持たせられるため、ユーザーへの割り当てを簡単に行えます。 たとえば、HR アプリケーションへのアクセス制御に RBAC を使用している場合、HR マネージャーには従業員情報を更新できるロールを付与し、その他の従業員には自分自身の情報のみを表示できるようにできます。 アクセス制御戦略を計画する際のベストプラクティスは、ユーザーが業務を遂行するために必要最小限の権限だけを割り当てることです。
より強力な認可モデルについては、属性ベースおよび関係ベースの認可を実現する Fine-Grained Authorization (FGA) を参照してください。

​
RBAC の利点

RBAC を使用すると、ロールの要件を厳密に守ることで、アクセス管理を容易に行えます。RBAC には、次のような利点があります。
  • 権限を体系的かつ一貫して割り当てられる
  • ユーザーの権限を容易に監査し、特定された問題を修正できる
  • ロールをすばやく追加・変更し、API 全体に適用できる
  • ユーザーへの権限割り当て時に発生する可能性のあるミスを減らせる
  • あらかじめ定義されたロールを付与することで、サードパーティのユーザーを組み込める
  • 機密性とプライバシーに関する規制要件や法的要件への準拠を、より効果的に実現できる

​
RBAC モデル

​
ロール

ロールは、ユーザーに適用できる権限の集合です。ロールを使用すると、ユーザーごとに個別に権限を割り当てる場合に比べて、権限の追加、削除、調整が容易になります。ユーザー数が増え、構成が複雑になるほど、ロールは特に有効です。 また、ロールを使って、さまざまな API で定義された権限をまとめることもできます。たとえば、ユーザーが顧客向けニュースレターを作成して配信できるマーケティングモジュールがあるとします。マーケティングコンテンツ担当者は、すべてのニュースレターを作成し、配信準備を行います。同様に、ユーザーがイベント登録を作成、公開、管理できるイベントモジュールがあるとします。イベントコーディネーターはイベントを作成します。マーケティング担当 VP がニュースレターとイベントを承認したら、そのアシスタントがイベントを公開し、ニュースレターを配信します。この場合、Newsletter API には distribute:newsletters 権限、Event API には publish:events 権限を定義できます。これらの権限を Marketing Publisher というロールにまとめて、マーケティング担当 VP のアシスタントに割り当てることができます。 さらに、組織固有のロールは組織メンバーに追加でき、エンドユーザーがどの組織でログインしているかに基づいて、アプリケーション内でのアクセスを許可するために利用できます。これは、特定のユーザーがある組織では特権ロールを持っていても、他の組織では持っていない場合があるマルチテナントの SaaS 製品をサポートする際に特に役立ちます。

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

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

​
Auth0 におけるロールベースアクセス制御

現在、ロールベースアクセス制御 (RBAC) を実装する方法として、次の 2 つを提供しています。これらは、API 独自の内部アクセス制御システムの代わりに使用することも、組み合わせて使用することもできます。 現在、Authorization Core 機能セットは、Authorization Extension と同等の機能を提供できるよう拡張を進めています。新しいコア RBAC 実装では、パフォーマンスとスケーラビリティが向上し、最終的には Authorization Extension より柔軟な RBAC システムを提供する予定です。 現時点では、どちらも RBAC の主要機能を実装しており、API 用に定義されたカスタム スコープ を、ユーザーに権限として割り当てられたもののみに制限できます。比較については、Authorization Core と Authorization Extension の比較を参照してください。
Authorization Core 機能セットと Authorization Extension は、完全に別個の機能です。グループ、ロール、または権限を管理するには、それらを最初に作成した機能を使用する必要があります。
Delegated Administration Extension (DAE) と Authorization Core 機能セットは完全に別個の機能ですが、Actions を使用して DAE のロールを作成および管理するために Authorization Core 機能セットを使用できます。詳細については、サンプルユースケース: 認可での Actions の使用を参照してください。

​
RBAC の拡張

Rules を使用すると、ユーザーの部門、時刻、アクセス元の場所、またはその他のユーザー属性や API 属性 (たとえば、username、セキュリティ クリアランス、API 名) など、複数の属性の組み合わせに基づいてアクセスを制限し、よりきめ細かな制御を実現できます。 認可ポリシーで Rules を使用する方法の詳細については、Rules with Authorization Policies を参照してください。

​
詳しくはこちら