ロールベースアクセス制御(RBAC).

ロールベースアクセス制御は、権限を抽象的なロール(例:「請求管理者」や「読み取り専用監査人」)に割り当て、ユーザーをそのロールに追加することでアクセスを付与します。この間接化により管理が簡素化され、職務分掌が実現し、権限がユーザー単位ではなくロール単位で文書化されるため監査も容易になります。RBAC はエンタープライズ IAM、クラウド基盤(AWS IAM、Azure RBAC、Kubernetes RBAC)、ERP における支配的なモデルです。

RBAC は 1992 年に NIST の David Ferraiolo と Rick Kuhn が論文「Role-Based Access Controls」で定式化し、その後 Sandhu らのフレームワークと統合され、ANSI/INCITS 359-2004(2012 年に INCITS 359-2012 として改訂)として標準化されました。この標準は累積的な 4 つの要素を定義します。コア RBAC(ユーザー・ロール・権限)、階層 RBAC(ロールが上位ロールを継承)、そして 2 種類の制約付き RBAC — 静的・動的な職務分掌(SSD/DSD)— で、同一ユーザーが支払いを作成と承認の両方を行うといった有害な権限の組み合わせを禁止します。

主な弱点はロールの爆発です。大規模組織では、細粒度の業務要件を個別のロールとして表現すると、ほぼ重複した数千のロールが生まれ管理不能になります。そのため、ロールが粗い基準を定め、属性(部門、時刻、リソースタグ)が各判断を精緻化するハイブリッド ABAC/RBAC 設計へと向かいます。これが AWS IAM の条件キーや Kubernetes の RBAC + アドミッション Webhook モデルの背後にある考え方です。

flowchart LR
  U["ユーザー: アリス"] -->|割り当て| R1["ロール: 請求管理者"]
  U -->|割り当て| R2["ロール: 監査人"]
  R1 -->|継承| R3["ロール: 請求閲覧者"]
  R1 -->|付与| P1["権限: 請求書作成"]
  R3 -->|付与| P2["権限: 請求書閲覧"]
  R2 -->|付与| P3["権限: ログ書き出し"]
  P1 --> RES[("請求システム")]
  P2 --> RES
  P3 --> RES
  SSD["SSD 制約:<br/>承認者と作成者を兼任不可"] -. 阻止 .-> R1