RBAC

RBAC（Role-Based Access Control：ロールベースアクセス制御）とは、ユーザーに直接権限を付与するのではなく、「ロール（役割）」を介してアクセス権限を管理するセキュリティモデルです。ユーザーはロールに割り当てられ、ロールには特定のリソースに対する権限（パーミッション）が紐付けられます。

RBACの概念は1990年代にDavid Ferraiolo氏とRick Kuhn氏によって体系化され、2004年にはNIST（米国国立標準技術研究所）によってANSI/INCITS 359-2004として標準化されました。組織における権限管理の複雑さを大幅に軽減するモデルとして、現在最も広く採用されているアクセス制御方式です。

たとえば、「経理担当者」ロールには「経費精算の承認」「会計データの閲覧」などの権限が付与されます。新しい従業員が経理部門に配属された場合、個別の権限を設定する代わりに「経理担当者」ロールを割り当てるだけで、必要な権限が自動的に付与されます。異動や退職の際も、ロールの変更・削除のみで権限管理が完了します。

AWS IAM、Azure RBAC、Google Cloud IAM、Kubernetes RBACなど、主要なクラウドプラットフォームやインフラ技術がRBACを採用しており、エンタープライズセキュリティの基盤となっています。

NIST RBACモデルの4つのレベル

NISTはRBACを4つのレベルに分類しています。

• Core RBAC（コアRBAC）：ユーザー、ロール、パーミッション、セッションの基本的な関係を定義するモデル。ユーザーはロールに割り当てられ、ロールにはパーミッションが付与される。セッション中にユーザーがどのロールをアクティブにするかを制御できる。
• Hierarchical RBAC（階層的RBAC）：ロール間の継承関係を定義する。上位ロールは下位ロールの権限をすべて継承する。たとえば「部長」ロールは「課長」ロールの権限を継承し、さらに追加の権限を持つ。
• Static Separation of Duty（静的職務分離：SSD）：特定のロールの組み合わせを同一ユーザーに割り当てることを禁止する。たとえば「発注担当」と「支払承認担当」を同一人物に割り当てないことで、不正を防止する。
• Dynamic Separation of Duty（動的職務分離：DSD）：ユーザーが複数のロールを保有できるが、同一セッション内で同時にアクティブにできるロールを制限する。たとえば「監査人」ロールと「被監査部門管理者」ロールを同時にアクティブにできないようにする。

RBACの構成要素

• ユーザー（User）：システムを利用する個人。人間だけでなく、サービスアカウントやアプリケーションも含む。
• ロール（Role）：組織における職務や機能を表す抽象概念。「システム管理者」「閲覧者」「編集者」など。
• パーミッション（Permission）：特定のリソースに対する操作権限。「読み取り」「書き込み」「削除」「実行」など。オペレーションとオブジェクトの組み合わせで定義される。
• セッション（Session）：ユーザーがシステムにログインしてからログアウトするまでの期間。セッション中にアクティブなロールを切り替えることが可能。

RBAC vs 他のアクセス制御モデル

• DAC（任意アクセス制御）：リソースの所有者が自由にアクセス権限を設定できるモデル。ファイルシステムの権限設定が典型例。柔軟だが、管理が困難になりやすい。
• MAC（強制アクセス制御）：セキュリティラベル（機密レベル）に基づいて中央管理者がアクセスを制御するモデル。軍事・政府機関で使用される。非常に厳格だが、柔軟性に欠ける。
• ABAC（属性ベースアクセス制御）：ユーザー属性、リソース属性、環境条件など、複数の属性に基づいてアクセスを制御するモデル。RBACより細かい粒度の制御が可能だが、ポリシー設計が複雑。

最小権限の原則（Principle of Least Privilege）

最小権限の原則は、RBACの運用における最も重要な原則です。ユーザーには業務遂行に必要な最小限の権限のみを付与すべきであり、不必要な権限は付与しません。この原則に従うことで、内部不正や権限昇格攻撃のリスクを最小化できます。定期的な権限棚卸し（Access Review）を実施し、不要になった権限を速やかに削除することが重要です。

エンタープライズにおけるRBAC実装

• AWS IAM：IAMポリシーをIAMロールにアタッチし、ユーザーやサービスがロールを引き受ける（AssumeRole）ことでアクセスを制御する。
• Azure RBAC：組み込みロール（Owner、Contributor、Reader）とカスタムロールを使用し、管理グループ、サブスクリプション、リソースグループ、リソースの各スコープで権限を割り当てる。
• Kubernetes RBAC：Role/ClusterRoleでパーミッションを定義し、RoleBinding/ClusterRoleBindingでユーザーやサービスアカウントに紐付ける。

• 01
  最小権限の原則を徹底する：すべてのロールに対して、業務遂行に必要な最小限の権限のみを付与する。管理者権限（Admin/Root）の付与は厳格に制限し、日常業務には権限の限られたロールを使用する。「とりあえずAdmin権限を付与する」という運用を排除する。
• 02
  定期的な権限棚卸し（Access Review）を実施する：四半期ごとまたは半年ごとに、全ユーザーのロール割り当てを確認し、不要になった権限を削除する。特に退職者や異動者のアカウントに残存する権限（オーファンアカウント）を速やかに削除する。
• 03
  職務分離（Separation of Duties）を実装する：相互に牽制すべき権限の組み合わせ（例：申請と承認、開発と本番デプロイ）を同一ユーザーに付与しないよう、静的または動的な職務分離ルールを設定する。
• 04
  ロール爆発（Role Explosion）を防止する：細かすぎるロール設計はロール数の爆発的増加を招き、管理が困難になる。ロール設計はビジネス機能単位で行い、例外的な権限はABACとの組み合わせで対応することを検討する。
• 05
  特権アクセス管理（PAM）との連携：管理者ロールなどの特権ロールには、PAM（Privileged Access Management）ソリューションと連携し、Just-In-Time（JIT）アクセスを導入する。恒久的な特権付与を避け、必要な時のみ一時的に権限を昇格させる。
• 06
  ロール割り当てと権限使用の監査ログを記録する：誰がいつどのロールを割り当てられたか、どの権限がいつ使用されたかを監査ログに記録する。異常なロール割り当てや未使用の権限を検知するための自動アラートを設定する。