> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ロールベースアクセス制御の概念と、Auth0 での適用方法について説明します。

# ロールベースアクセス制御

ロールベースアクセス制御 (RBAC) とは、組織内での役割に基づいてユーザーに権限を割り当てる考え方です。ユーザーごとに個別に権限を割り当てる方法よりもミスが起こりにくく、シンプルで管理しやすいアクセス管理のアプローチを実現できます。

ロール管理に RBAC を使用する場合は、ユーザーのニーズを分析し、共通の責務に基づいてロールに分類します。次に、各ユーザーに 1 つ以上のロールを割り当て、各ロールに 1 つ以上の権限を割り当てます。ユーザーとロール、ならびにロールと権限の関係を定義することで、ユーザーごとに個別管理する必要がなくなり、それぞれのロールに割り当てられた権限に応じたアクセス権を持たせられるため、ユーザーへの割り当てを簡単に行えます。

たとえば、HR アプリケーションへのアクセス制御に RBAC を使用している場合、HR マネージャーには従業員情報を更新できるロールを付与し、その他の従業員には自分自身の情報のみを表示できるようにできます。

アクセス制御戦略を計画する際のベストプラクティスは、ユーザーが業務を遂行するために必要最小限の権限だけを割り当てることです。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  より強力な認可モデルについては、属性ベースおよび関係ベースの認可を実現する [Fine-Grained Authorization (FGA)](https://docs.fga.dev/authorization-concepts) を参照してください。
</Callout>

<div id="benefits-of-rbac">
  ## RBAC の利点
</div>

RBAC を使用すると、ロールの要件を厳密に守ることで、アクセス管理を容易に行えます。RBAC には、次のような利点があります。

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

<div id="rbac-model">
  ## RBAC モデル
</div>

<div id="roles">
  ### ロール
</div>

ロールは、ユーザーに適用できる権限の集合です。ロールを使用すると、ユーザーごとに個別に権限を割り当てる場合に比べて、権限の追加、削除、調整が容易になります。ユーザー数が増え、構成が複雑になるほど、ロールは特に有効です。

また、ロールを使って、さまざまな API で定義された権限をまとめることもできます。たとえば、ユーザーが顧客向けニュースレターを作成して配信できるマーケティングモジュールがあるとします。マーケティングコンテンツ担当者は、すべてのニュースレターを作成し、配信準備を行います。同様に、ユーザーがイベント登録を作成、公開、管理できるイベントモジュールがあるとします。イベントコーディネーターはイベントを作成します。マーケティング担当 VP がニュースレターとイベントを承認したら、そのアシスタントがイベントを公開し、ニュースレターを配信します。この場合、Newsletter API には `distribute:newsletters` 権限、Event API には `publish:events` 権限を定義できます。これらの権限を `Marketing Publisher` というロールにまとめて、マーケティング担当 VP のアシスタントに割り当てることができます。

さらに、組織固有のロールは[組織メンバーに追加](/ja/docs/manage-users/organizations/configure-organizations/add-member-roles)でき、エンドユーザーがどの組織でログインしているかに基づいて、アプリケーション内でのアクセスを許可するために利用できます。これは、特定のユーザーがある組織では特権ロールを持っていても、他の組織では持っていない場合があるマルチテナントの SaaS 製品をサポートする際に特に役立ちます。

<div id="overlapping-role-assignments">
  ## 重複するロールの割り当て
</div>

RBAC は加算型モデルであるため、重複するロールの割り当てがある場合、有効な権限は各ロール割り当てに含まれる権限の和集合になります。

たとえば、イベントアプリケーション向けのデータを提供する API があるとします。`Organizer` というロールを作成し、イベントの表示、作成、編集を許可する権限を割り当てます。また、`Registrant` というロールを作成し、イベントの表示と登録を許可する権限を割り当てます。`Organizer` と `Registrant` の両方のロールを持つユーザーは、イベントの表示、作成、編集、登録を行えます。

<div id="role-based-access-control-in-auth0">
  ## Auth0 におけるロールベースアクセス制御
</div>

現在、ロールベースアクセス制御 (RBAC) を実装する方法として、次の 2 つを提供しています。これらは、API 独自の内部アクセス制御システムの代わりに使用することも、組み合わせて使用することもできます。

* [Authorization Core](/ja/docs/manage-users/access-control/configure-core-rbac)
* [Authorization Extension](/ja/docs/customize/extensions/authorization-extension)

現在、Authorization Core 機能セットは、Authorization Extension と同等の機能を提供できるよう拡張を進めています。新しいコア RBAC 実装では、パフォーマンスとスケーラビリティが向上し、最終的には Authorization Extension より柔軟な RBAC システムを提供する予定です。

現時点では、どちらも RBAC の主要機能を実装しており、API 用に定義されたカスタム スコープ を、ユーザーに権限として割り当てられたもののみに制限できます。比較については、[Authorization Core と Authorization Extension の比較](/ja/docs/manage-users/access-control/authorization-core-vs-authorization-extension)を参照してください。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  [Authorization Core](/ja/docs/manage-users/access-control/rbac) 機能セットと [Authorization Extension](/ja/docs/customize/extensions/authorization-extension) は、完全に別個の機能です。グループ、ロール、または権限を管理するには、それらを最初に作成した機能を使用する必要があります。
</Callout>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  [Delegated Administration Extension (DAE)](/ja/docs/customize/extensions/delegated-administration-extension) と [Authorization Core](/ja/docs/manage-users/access-control/rbac) 機能セットは完全に別個の機能ですが、Actions を使用して DAE のロールを作成および管理するために Authorization Core 機能セットを使用できます。詳細については、[サンプルユースケース: 認可での Actions の使用](/ja/docs/manage-users/access-control/sample-use-cases-actions-with-authorization)を参照してください。
</Callout>

<div id="extending-rbac">
  ### RBAC の拡張
</div>

[Actions](/ja/docs/customize/actions) を使用すると、ユーザーの部門、時刻、アクセス元の場所、またはその他のユーザー属性や API 属性 (たとえば、username、セキュリティ クリアランス、API 名) など、複数の属性の組み合わせに基づいてアクセスを制限し、よりきめ細かな制御を実現できます。

認可ポリシーで Actions を使用する方法の詳細については、[サンプルユースケース: 認可での Actions の使用](/ja/docs/manage-users/access-control/sample-use-cases-actions-with-authorization) を参照してください。

<div id="learn-more">
  ## 詳しくはこちら
</div>

* [API でロールベースアクセス制御を有効にする](/ja/docs/get-started/apis/enable-role-based-access-control-for-apis)
