Overview
RBAC（Role-Based Access Control：ロールベースアクセス制御）とは、ユーザーに直接権限を割り当てるのではなく、組織内の「ロール（役割）」に権限を紐づけ、ユーザーをロールに割り当てることでアクセス制御を実現するモデルです。例えば「経理担当者」というロールに「経費システムの閲覧・編集権限」を付与し、経理部の社員をそのロールに割り当てるという形で運用されます。
RBACの最大の利点は、管理の効率化とセキュリティの一貫性です。ユーザー個別に権限を設定する方式では、組織の規模が大きくなるにつれて管理が煩雑になり、設定ミスによるセキュリティリスクが増大します。RBACでは、ロールの権限を変更するだけで、そのロールに属するすべてのユーザーの権限が一括で更新されるため、大規模組織でも効率的な権限管理が可能です。
RBACは現在最も広く採用されているアクセス制御モデルであり、Active Directory、AWS IAM、Azure AD、Google Workspace、Salesforceなど、主要なエンタープライズシステムやクラウドプラットフォームで標準的に実装されています。NIST（米国国立標準技術研究所）が標準モデルを策定しており、その体系的なフレームワークが業界全体で参照されています。
Details
RBACの基本構成要素
RBACはユーザー（User）、ロール（Role）、パーミッション（Permission）の3つの基本要素で構成されます。ユーザーはシステムを利用する個人やサービスアカウント、ロールは組織内の職務や職位に対応する論理的なグループ、パーミッションはリソースに対する操作権限（読み取り、書き込み、削除など）を表します。
ユーザーは1つ以上のロールに割り当てられ、ロールは1つ以上のパーミッションを保持します。この間接的な権限割り当てにより、ユーザーとパーミッションの直接的な紐づけが不要になり、管理が大幅に簡素化されます。
ロール階層（Role Hierarchy）
ロール階層は、上位ロールが下位ロールのすべての権限を継承する仕組みです。例えば「部長」ロールは「課長」ロールの権限をすべて継承し、さらに追加の管理権限を持つという構造を定義できます。これにより、組織の階層構造を忠実に反映したアクセス制御が実現できます。
ロール階層を適切に設計することで、権限定義の重複を排除し、管理の複雑性を低減できます。ただし、階層が深くなりすぎると、意図しない権限の継承が発生するリスクがあるため、定期的なレビューが必要です。
ロールエンジニアリング
ロールエンジニアリングとは、組織に最適なロール構造を設計するプロセスです。アプローチとしては、トップダウン方式（組織構造や職務分析からロールを定義）とボトムアップ方式（既存の権限割り当てパターンからロールを抽出するロールマイニング）があります。
実際のプロジェクトでは、両方のアプローチを組み合わせたハイブリッド方式が推奨されます。初期のロール設計ではトップダウンで大枠を定義し、ロールマイニングによって実際の利用パターンを分析して最適化します。ロールの数が多すぎる「ロール爆発」を防ぐことが、ロールエンジニアリングの最大の課題です。
NISTのRBACモデル
NISTはINCITS 359-2004として標準化されたRBACモデルを定義しています。このモデルは4つのレベルで構成されます。Core RBACはユーザー・ロール・パーミッションの基本的な割り当て、Hierarchical RBACはロール階層の導入、Static Separation of Duty（SSD）は相互に排他的なロールの同時割り当て禁止、Dynamic Separation of Duty（DSD）は同一セッション内での排他的ロールの同時有効化禁止を規定します。
特に職務分離（Separation of Duty）は内部不正の防止に重要な概念です。例えば「購買申請者」と「購買承認者」のロールを同一ユーザーに割り当てることを禁止することで、不正な購買を防止できます。
他のアクセス制御モデルとの比較
DAC（任意アクセス制御）はリソースの所有者が自由にアクセス権を設定できるモデルで、柔軟性は高いですが一貫性のある管理が難しくなります。MAC（強制アクセス制御）はセキュリティラベルに基づく厳格なモデルで、軍事・政府機関で使用されます。ABAC（属性ベースアクセス制御）は、ユーザー属性、リソース属性、環境属性を組み合わせた柔軟なポリシーベースのモデルです。
RBACは管理のシンプルさと効率性で優れていますが、複雑なアクセス制御要件（時間帯やアクセス元IPによる制限など）にはABACが適しています。多くの組織では、RBACを基本としつつABACで補完するハイブリッドアプローチが採用されています。
Security Measures
- 01最小権限の原則に基づくロール設計：各ロールに付与する権限は、その職務を遂行するために最低限必要な権限のみに限定してください。過剰な権限を持つ「スーパーロール」の作成を避け、業務に必要な操作だけを許可するきめ細かいロール設計を行いましょう。
- 02職務分離（Separation of Duties）の実装：相互に排他的な権限を持つロール（承認者と申請者、開発者と本番デプロイ担当者など）が同一ユーザーに割り当てられないよう、静的・動的な職務分離制約を設定してください。
- 03ロール割り当ての定期的な棚卸し（アクセスレビュー）：少なくとも四半期ごとに、すべてのユーザーのロール割り当てをレビューしてください。異動・退職したユーザーの不要なロール、プロジェクト終了後に残存しているロールを速やかに削除し、権限の肥大化（Privilege Creep）を防止しましょう。
- 04ロール爆発の防止と管理：ロールの数が過度に増加する「ロール爆発」を防ぐため、類似するロールの統合、パラメータ化されたロールの導入、属性ベースの制御（ABAC）との併用を検討してください。ロール数の上限目安を設定し、新規ロール作成時には既存ロールとの重複を確認しましょう。
- 05ロール変更の監査ログと変更管理：ロールの作成・変更・削除、ユーザーへのロール割り当て・解除のすべてを監査ログに記録してください。変更管理プロセスを整備し、ロール変更には適切な承認ワークフローを適用しましょう。
- 06テスト環境でのロール検証：新しいロールや権限変更は、本番環境に適用する前にテスト環境で検証してください。ロールに意図しない権限が含まれていないか、職務分離制約が正しく機能しているかを確認し、設定ミスによるセキュリティリスクを防止しましょう。
Incidents
📋 Capital One クラウド環境におけるロール設定不備による大規模情報漏洩（2019年）
2019年、Capital OneのAWS環境において、WAF（Web Application Firewall）のIAMロールに過剰な権限が付与されていたことが原因で、約1億人分の顧客情報が漏洩しました。攻撃者はSSRF（Server-Side Request Forgery）脆弱性を利用してWAFサーバーのIAMロールの認証情報を取得し、本来アクセスすべきでないS3バケットのデータを大量に窃取しました。
WAFのIAMロールに対してS3バケットへの広範なアクセス権限が付与されていなければ、被害は大幅に限定できた可能性があります。この事件は、クラウド環境におけるIAMロールの最小権限設計の重要性を業界に強く示しました。
📋 医療機関における職務分離不備による処方箋改ざん
国内の大規模医療機関において、電子カルテシステムのロール設計に職務分離の考慮が不足していたことから、特定の職員が処方箋の作成と承認の両方を行える状態にありました。この不備を悪用し、職員が架空の処方箋を作成して医薬品を不正に入手する事件が発生しました。
この事件を受け、当該医療機関ではRBACモデルを全面的に見直し、処方箋の作成者と承認者のロールに職務分離制約を適用しました。また、ロール割り当ての定期的な棚卸しプロセスを導入し、不適切な権限の組み合わせが発生していないかを継続的に監視する体制を構築しました。
📋 SaaS企業におけるロール爆発による管理破綻とデータ漏洩
ある急成長中のSaaS企業において、顧客ごとにカスタムロールを作成し続けた結果、ロール数が数千に膨れ上がる「ロール爆発」が発生しました。管理が困難になったため、便宜的に広範な権限を持つ「管理者」ロールを多用するようになり、最小権限の原則が形骸化しました。
最終的に、退職した元従業員のアカウントに残存していた管理者ロールを通じて、顧客データが不正にアクセスされる事態に至りました。この事例は、ロール管理の設計段階から拡張性を考慮し、定期的な棚卸しを行うことの重要性を示しています。