Skip to main content
ロールベースのアクセス制御 (ロールベースのアクセス制御) とは、組織内での役割に応じてユーザーに権限を割り当てる考え方です。ユーザーごとに個別に権限を割り当てる方法に比べてミスが起こりにくく、シンプルで管理しやすいアクセス管理の手法です。 Role Management でロールベースのアクセス制御を使用する場合は、まずユーザーのニーズを分析し、共通の責任に基づいてロールごとに整理します。次に、各ユーザーに1つ以上のロールを割り当て、各ロールに1つ以上の権限を割り当てます。ユーザーとロール、そしてロールと権限の関係によって、ユーザーを個別に管理する必要がなくなり、それぞれのロールに割り当てられた権限に応じた特権を持つようになるため、ユーザーへの割り当てを簡単に行えます。 たとえば、HRアプリケーションへのアクセスを制御するためにロールベースのアクセス制御を使用している場合、HRマネージャーには従業員の詳細を更新できるロールを付与し、他の従業員には自分の詳細のみを表示できるようにできます。 アクセス制御の戦略を計画する際は、ユーザーが業務を遂行するために必要な最小限の権限だけを割り当てるのがベストプラクティスです。
より堅牢な認可モデルについては、属性ベースおよび関係ベースの認可に対応した Fine-Grained Authorization (FGA) をご覧ください。

​
ロールベースのアクセス制御の利点

ロールベースのアクセス制御では、ロールの要件を厳密に守ることで、アクセス管理が容易になります。ロールベースのアクセス制御には、次のようなメリットがあります。
  • 権限の割り当てを体系化し、一貫して繰り返し運用できる
  • ユーザー権限を容易に監査し、特定された問題を修正できる
  • ロールをすばやく追加・変更し、API全体に適用できる
  • ユーザー権限の割り当て時に発生しうるエラーを減らせる
  • あらかじめ定義されたロールを付与することで、サードパーティのユーザーを組み込める
  • 機密性やプライバシーに関する規制および法令上の要件に、より効果的に準拠できる

​
ロールベースのアクセス制御モデル

​
ロール

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

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

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

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

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

​
ロールベースのアクセス制御の拡張

Actions を使用すると、ユーザーの部署、時間帯、アクセス元の場所、その他のユーザー属性や API 属性 (たとえば、ユーザー名、セキュリティ クリアランス、API 名) を組み合わせてアクセスを制限し、よりきめ細かな制御を行えます。 認可ポリシーで Actions を使用する方法の詳細については、Sample Use Cases: Actions with Authorization を参照してください。

​
詳細はこちら