ロールベースのアクセスコントロール（RBAC）はIAM内の認可モデルで、アプリケーション内のどのリソースに誰がアクセスできるかを定義します。

RBACは、「この認証済みのユーザーは何ができるのか？」という認可に関する重要な質問に対処します。すべてのユーザーに個別の権限を割り当てるのではなく、権限をロールとしてまとめます。ユーザーに1つ以上のロールを割り当て、定義された一連の権限がロールから付与されます。このアプローチにより、ユーザー管理が簡素化され、セキュリティが向上して、最新のアプリケーションに合わせて拡張できます。

RBACモデルは、ユーザー、ロール、権限の関係性によって定義されます。

• ユーザー：認証済みでシステムへのアクセスを求める個人またはエンティティ
• 権限（または特権）：リソースに対して特定の操作を実行するためのきめ細かい権利
  権限は操作/リソースのペアとして表現します。
  • read:Patients
  • update:Settings
  • delete:Posts
• ロール：アプリケーション内の特定の職務やアクセスレベルを定義する権限の集合（1人のユーザーが複数のロールを持てる）。

RBACの仕組み

RBACは、次の3つのロジックに基づく手順で実行されます。

1. 権限の定義：ユーザーがアプリケーションで実行できる最小レベルの操作を決定します（特定のリソースに対するcreate、read、update、deleteなど）。
2. ロールへの権限の割り当て：権限をロジックに基づいたロールにまとめます（「管理者」ロールはすべての権限を持ち、「閲覧者」ロールはread権限のみを持つなど）。
3. ユーザーへのロールの割り当て：ユーザーにその責任に応じたロールを付与します。

ユーザーがリソースへのアクセスを開始すると、システムはユーザーに割り当てられたロールを確認し、ユーザーが必要な権限の組み合わせを保持しているかどうかを判断します。

RBACは、API駆動型アプリケーションに調和されたシンプルさとセキュリティを提供します。

• 管理の簡素化：何千人もの個々のユーザーの権限を管理する代わりに、より少数のロールを管理するだけで済みます。ロールの権限を変更すると、割り当てられたすべてのユーザーのアクセス権が即座に更新されます。
• 明確性と可監査性：RBACのロールは、人間が読み取り可能で、マシンが強制できるアクセス権限の制御を提供するため、監査が容易になり、最小権限のセキュリティ原則への準拠もしやすくなります。
• スケーラビリティ：アプリケーションの成長に合わせて、新しい複雑な権限セットを作成するのではなく、既存のロールを割り当てるだけで新規ユーザーをオンボーディングできます。

製品、注文、顧客、分析という主要なリソースを備えた典型的なEコマースのバックエンドAPIを考えてみましょう。

ロール権限のサンプルユーザー

役割	アクセス許可	サンプルユーザー
管理者	（すべてのリソースに対する全権限）	サラ
在庫マネージャー	create:Products、read:Products、update:Products	マッテオ、プリヤ
サポート担当	read:Orders、read:Customers	リアム
アナリスト	read:Analytics	デビッド

プリヤ（在庫マネージャー）が次の操作を試みる場合：

• 製品リストの閲覧：在庫マネージャーのロールにread:Products権限が含まれているため、アクセスは許可されます。
• 製品説明の編集：在庫マネージャーのロールにupdate:Products権限が含まれているため、アクセスは許可されます。
• 顧客の個人データの閲覧：在庫マネージャーのロールにread:Customers権限が含まれていないため、アクセスは拒否されます。

この例では、権限がロールを通じて自動的に継承され、ユーザーと権限を直接マッピングしなくても、きめ細かいアクセスコントロールを行える仕組みを示しています。

複数の顧客組織が、同じアプリケーション基盤を共有するB2B SaaSプラットフォームでは、RBACは組織のスコープで設定されます。そのため、ユーザーは、異なる組織をまたがって別のロールを持つことができます。

ユーザーが認証すると、認可システムは「このユーザーのロールは何か？」だけでなく、「この特定の組織におけるユーザーのロールは何か？」も評価する必要があります。JWTにはユーザーのアイデンティティと組織識別子の両方が含まれており、正しいテナント境界内でロールベースの権限が確実に適用されます。これにより、顧客組織全体における特権のエスカレーションが防止され、マルチテナントのアーキテクチャで厳密なデータ分離が維持されます。

RBACは、ほとんどのアプリケーションで適切に機能しますが、より複雑なシナリオでは他のAuthZモデルの方が適している場合があります。

モデル	焦点	ユースケース	使用すべきケース
ロールベースのアクセスコントロール（RBAC）	ユーザーの職務/ロール	静的で明確に定義されたユーザーグループ（管理者、編集者、閲覧者）を持つ企業アプリ	権限が予測可能なアプリケーションにおいて最も一般的で十分なモデル
属性ベースのアクセスコントロール（ABAC）	ユーザー属性、リソース属性、環境属性	動的なポリシー式［（user.department == resource.departmentの場合など）］、またはコンテキスト要因（場所、時間帯など）で決定されるアクセス	認可の判断が複雑でコンテキストに依存する場合
関係性ベースのアクセスコントロール（ReBAC）	ユーザーとリソースの関係性	ソーシャルメディアプラットフォーム（「この投稿の投稿者本人のみが削除できる」など）、またはマルチテナントアプリ	認可が所有権またはユーザーとデータ間の直接的な関係性に依存する場合

RBACは、ほとんどのアプリケーションに強固な認可を提供します。特にユーザーの権限が、定義された組織ロールと一致する場合に効果的です。大半のB2B SaaSアプリケーションでは、RBAC（基本的な属性チェックで強化される可能性あり）によって、不必要な複雑さを伴うことなく十分なアクセスコントロールを実現できます。

ただし、アクセスの決定にロールだけでは捉えられないコンテキストが必要になると、RBACは限界に達します。たとえば、「ユーザーは自分が作成したドキュメントのみを編集できる」、「営業時間外はアクセスが制限される」などのルールを適用する必要がある場合は、これらのシナリオには特定のリソースや環境属性との関係性が関わってきます。このような場合、RBACに複雑な回避策を積み重ねるのではなく、ABACやReBACモデルが必要になります。

最新のAPI主導のアーキテクチャでは、アクセストークンによってRBACが適用されます。OAuth 2.0やOpenID Connect（OIDC）などのプロトコルを用いてAPIを保護します。（OAuth 2.0では、スコープが権限を表すため、IdPの実装に応じてロールをスコープまたはカスタムクレームに変換します。）

1. 認証（AuthN）：ユーザーが、アイデンティティプロバイダー（IdP）を通じてサインインします。
2. 認可マッピング：IdPが、定義されたRBACモデルに基づいて、ユーザーのロールと対応する権限を決定します。
3. トークン発行：IdPが、JSON Web Token（JWT）形式のアクセストークンを生成します。JWTのペイロードには、ロール、スコープ、またはカスタム属性といったクレームが含まれており、これを用いてダウンストリームAPIがRBACを適用します。
4. API適用（AuthZ）：ユーザーがAPIを呼び出すと、バックエンドAPIは、まずJWTを検証します。次に、トークン内のロール/権限クレームを確認し、RBACルールを適用してリソースや操作へのアクセスを許可します。

このトークンベースのアプローチによって、APIはステートレスになります。必要な認可データはトークン内に自己完結型で含まれており、暗号的に署名されています。

JWTは、ロールと権限データをアクセストークン内に保持することで、ステートレスでスケーラブルにRBACを適用しますが、脆弱性を回避するために、次のセキュリティ対策を実施してください。

• 最小権限の原則：ユーザーの職務に必要な最小限のロールと権限のみを割り当てます。
• トークンの有効期間と取り消し：JWT形式のアクセストークンはローカルで検証されるため、すぐに取り消すのは困難です。
  • 推奨事項：短期間のアクセストークン（15～60分）を使用し、リフレッシュトークンをローテーションします。
• サーバー側での検証：リクエストごとに、以下についてすべてのJWTを検証します。
  • 完全性：トークンの署名を検証します。
  • 有効期限：expクレームを確認します。
  • オーディエンス：audクレームがアプリケーションと一致していることを確認します。
  • 認証局：issクレームが予期される発行者と一致することを確認します。
  • キーのローテーション：キーのローテーションをサポートし、署名の完全性を維持するために、IdPのJSON Web Key Set（JWKS）に対してトークンを検証します。
• ロールと権限の格納：必要なロールと権限のクレームのみを含めます。機密性の高い個人データは含めません。
• トークンの保存：クロスサイトスクリプティング（XSS）攻撃を受ける可能性があるため、機密性の高いトークンは、localStorageまたはsessionStorageに保存しません。安全なHttpOnly Cookieまたはバックエンド側のセッションストレージを使用します。
• 明確なエラーの処理：APIがリクエストを受信した場合、エラータイプに応じて特定のHTTPステータスコードを返します。
  • 401 Unauthorized：ユーザーが自分のアイデンティティを証明できなかった（トークンがないまたは無効などの認証エラー）。
  • 403 Forbidden：ユーザーのアイデンティティは確認（認証）済みだが、ユーザーのロール/権限（RBAC）によって、要求されたリソースまたは操作へのアクセスが拒否された（認可エラー）。

RBACの主な利点は何ですか？

RBACによって、ユーザー管理が簡素化し、可監査性が向上します。ユーザーごとの大規模で複雑な権限マトリクスではなく、少数のロールを管理するだけで済みます。

RBACは堅牢なセキュリティモデルですか？

はい、RBACは、ユーザーの職務と権限が静的で予測可能なアプリケーションにおいて、基本となる堅牢な認可モデルです。

RBACは条件付きアクセスを処理しますか？

いいえ。時間、場所、リソース値などの要素に基づく条件付きアクセスには、属性ベースのアクセスコントロール（ABAC）を使用します。RBACは、ユーザーに割り当てられたロールに重点を置いています。

RBACはアクセスコントロールの強力なモデルですが、包括的なアイデンティティとアクセス管理戦略を構成する要素の1つにすぎません。アイデンティティとアクセス管理に関連するその他のトピックについては、「IAM入門」シリーズをご覧ください。

詳細を見る

これらの資料は一般的な情報提供のみを目的としています。本資料の利用者は、自身の責任において、自身の専門アドバイザーからセキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本資料に記載された情報のみに依存すべきではありません。