ロールベースのアクセス制御（RBAC）とは

RBACシステムでは、管理者は個々のユーザーに1つ以上のロール（役割）を割り当てます。新しいロールはそれぞれ、ユーザーのアクセス権または特権のセットを表します。

財務ロールは、ユーザーが購入を行ったり、予測ソフトウェアを実行したり、サプライチェーン・システムへのアクセスを付与したりなどを許可する場合があります。人事ロールは、人事ファイルの閲覧や従業員福利厚生システムの管理をユーザーに許可する場合があります。

多くの従業員を抱える大規模な組織では、アクセス管理を簡素化し、デジタル・リソースの情報セキュリティーを維持するためにRBACがよく使用されます。また、RBACを使って、ビルやオフィス、データセンターの電子ロックなど、物理的な資産のセキュリティー・クリアランスを付与する企業もあります。

RBACにより、ユーザーの役割に必要なリソースへのアクセスを制限することで、悪意のあるインサイダー、従業員の過失、外部の脅威アクターから企業を防御できます。

ロールベースのアクセス制御システムにより、組織は、IDおよびアクセス管理（IAM）に対してきめ細かなアプローチをとりながら認証プロセスとアクセス制御ポリシーを合理化することができます。具体的には、組織はRBACを通じて以下を実現できるようになります。

• 権限をより効果的に割り当てる
• コンプライアンスの維持
• 機密データを保護する

RBACを使用すると、個々のユーザーにカスタマイズされたユーザー権限セットをプロビジョニングする必要がなくなります。その代わりに、定義されたRBACロールによってアクセス権が決定されます。このプロセスにより、組織は従業員のオンボーディングやオフボーディング、職務の更新、事業運営の変革などをより簡単に行えるようになります。

RBACのメリットには、請負業者、ベンダー、その他のサードパーティー・ユーザーに対するアクセス許可を迅速に追加できることも含まれます。例えば、共同マーケティングのロールを割り当てられることで、外部ビジネス・パートナーに製品関連データベースへのアプリケーション・プログラミング・インターフェース（API）アクセスが付与される場合があります。こうすることで、ユーザーは必要な情報にアクセスできるようになる一方、会社の機密リソースが漏洩することはありません。

RBACの導入は、金融サービスや医療機関対象の規制など、データ保護規制に準拠するうえでも役立ちます。RBACは、誰に、いつ、どのように機密情報がアクセスまたは変更されているかについて規制当局に透明性を提供します。

RBACポリシーは、最小権限の原則（PoLP）を適用することで、サイバーセキュリティーの脆弱性に対処するうえでも役立ちます。PoLPでは、ユーザーのロールによって、タスクを完了したりジョブを実行したりするために必要な最低レベルの権限へのアクセス権が付与されます。例えば、ジュニア・デベロッパーはアプリのソースコードで作業する権限を持つ一方で、監督者の承認がなければ変更をコミットできないといった具合にそのロールに必要なレベルの権限を付与します。

RBACは機密データへのアクセスを制限することで、偶発的なデータ損失と意図的なデータ侵害の両方を防ぐのに役立ちます。具体的には、RBACにより、ハッカーが最初のネットワーク・アクセス・ベクトルを使用してシステム全体に徐々に範囲を拡大する横方向の移動を抑制することができます。

X-Force Threat Intelligence Indexによると、有効なアカウントの不正使用（ハッカーが正当なユーザーのアカウントを乗っ取り、その権限を使用して危害を加える行為）が、最も一般的なサイバー攻撃ベクトルです。RBACは、そのアカウントがアクセスできるものを最初から制限することで、ハッカーがユーザーのアカウントを悪用できる損害を軽減します。

同様に、内部脅威はデータ侵害の最もコストのかかる原因の1つです。データ侵害のコストに関する調査によると、悪意のあるインサイダーによる侵害の平均コストは492万米ドルで、侵害全体の平均コストの444万米ドルを上回っています。

RBACによってユーザーの権限を制限することで、従業員が悪意を持ってまたは不注意にアクセス権限を悪用または誤用し、組織に損害を与えてしまうことが難しくなります。

高度な人工知能（AI）の利用が増えるにつれて、システムへのアクセスを慎重に制限することがさらに重要になります。ユーザーが許可なく機密情報を生成AIツールに入力し、ガードレールがほとんど整っていないと、問題が発生する可能性があります。IBM Institute for Business Valueの調査によると、現在の生成AIプロジェクトのうち、取り組みを保護するためのコンポーネントを備えているのはわずか24％でした。

RBACシステムでは、組織はまず特定のロール（役割）を作成し、次にそれらのロールにどのアクセス権と特権が付与されるかを定義する必要があります。多くの場合、管理者、専門家、または専門家ユーザー、エンド・ユーザーの3つのカテゴリーに大きく分けることから始まります。

特定のユーザーセットに対してさまざまな役割をさらに細かく設定するには、権限、責任、スキル・レベルなどのより詳細な要素が考慮されます。時に、ロールが役職に直接対応する場合もあります。または、役職に関係なく、特定の条件を満たしているユーザーに割り当てることができる一連のアクセス権限である場合もあります。

多くの場合、ユーザーは複数のロールを割り当てられたり、複数レベルのアクセスを含むロール・グループに割り当てられたりします。一部のロールは階層化されており、マネージャーに完全な権限セットを提供する一方で、そのロール権限のサブセットがマネージャー以下のロールに提供されます。例えば、スーパーバイザーのロールを持つユーザーに文書への書き込み権限が付与される一方で、チーム・メンバーには閲覧権限のみが許可されるといった形です。

1. 病院のIT管理者が、「看護師」用にRBACロールを作成します。
2. この管理者は、薬の閲覧や電子カルテ（EHR）システムへのデータ入力など、看護師のロールに対する権限を設定します。
3. 病院の看護スタッフには、RBAC看護師のロールが割り当てられます。
4. 看護師ロールに割り当てられたユーザーがログオンすると、RBACはユーザーにどの権限が与えられているかを確認し、そのセッションへのアクセスを許可します。
5. 薬の処方や検査の注文といったその他のシステム権限は、看護師のロールでは許可されていないため、これらのユーザーに対しては拒否されます。

多くの組織は、IDおよびアクセス管理（IAM）ソリューションを使用して、組織全体にRBACを導入しています。IAMシステムは、RBACスキームでの認証と認可の両方に役立ちます。

• 認証：IAMシステムは、一元管理されたユーザー・ディレクトリーまたはデータベースと照合してユーザーの認証情報を確認し本人確認を行うことができます。
  
  
• 認可：IAMシステムは、ユーザー・ディレクトリーでユーザーのロールをチェックし、組織のRBACスキームでそのロールに基づいて適切な権限を付与することで、そのユーザーを認可することができます。

RBACモデルを開発した米国国立標準技術研究所（NIST）は、すべてのRBACシステムに対して3つの基本的なルールを提供しています。

1. ロールの割り当て：ユーザーには、権限または特権を行使するために、1つ以上のアクティブなロールを割り当てる必要があります。
   
   
2. ロールの認可：ユーザーは、割り当てられたロールを引き受けることを認可されている必要があります。
   
   
3. 権限の認可：権限または特権は、ロールの割り当てによって認可されたユーザーにのみ付与されます。

RBACの実装には4つの個別のモデルがありますが、どのモデルも同じコア構造から始まります。後続モデルはそれぞれ、前のモデルに基づいて新しい機能と特徴を構築します。

• コアRBAC
• 階層型RBAC
• 制約付きRBAC
• 対称RBAC

フラットRBACと呼ばれることもあるこのモデルは、あらゆるRBACシステムに必要な基盤です。このモデルは、RBACの3つの基本ルールに従います。ユーザーにはロールが割り当てられ、それらのロールにより特定の権限と特権のセットへのアクセスが許可されます。コアRBACは、主要なアクセス制御システムとして、またはより高度なRBACモデルの基礎として使用できます。

このモデルでは、組織のレポート構造を複製するロール階層が追加されます。ロール階層では、各ロールはその下にあるロールの権限を引き継ぎ、新しい権限を取得します。

例えば、ロール階層には、エグゼクティブ、マネージャー、スーパーバイザー、ライン従業員などが含まれます。階層の最上位に位置するエグゼクティブにはフルセットの権限が与えられ、マネージャー、スーパーバイザー、ライン従業員には、その権限セットのサブセットが順次付与されます。

役割階層に加えて、このモデルには職務の分離（SOD）を適用する機能が追加されています。職務の分離では、特定のタスクの完了に2人が必要となるため、利益相反を防ぐことができます。

たとえば、業務経費の払い戻しを要求するユーザーと、その要求を承認するユーザーが同一であってはなりません。制約付きのRBACポリシーにより、このような種類のタスクのためにユーザー権限を確実に分離することができます。

このモデルは、RBACの最も先進的で柔軟かつ包括的なバージョンです。これまでのモデルの機能に加え、企業全体の権限をより深く可視化することができます。

組織は、各権限がシステム内の各ロールと各ユーザーにどのように対応しているかを確認できるうえ、ビジネス・プロセスや従業員の責任の変化に応じて、ロールに関連付けられた権限を調整・更新することもできます。

これらの機能は、すべてのロールとすべてのユーザーがタスクの実行に必要な最小限のアクセス権を確保する必要がある大規模組織にとって特に価値があります。

組織がRBACの代わりに使用できるアクセス制御フレームワークは他にもあります。一部のユースケースでは、組織はRBACを他の認証モデルと組み合わせてユーザー権限を管理しています。一般的に使用されているアクセス制御フレームワークには、次のようなものがあります。

• 強制アクセス制御（MAC）
• 任意アクセス制御（DAC）
• 属性ベースのアクセス制御（ABAC）
• アクセス制御リスト（ACL）

MACシステムは、すべてのユーザーに一元的に定義されたアクセス制御ポリシーを適用します。MACシステムはRBACよりも粒度が低く、多くの場合アクセス権は設定されたクリアランス・レベルまたは信頼スコアに基づいて付与されています。多くのオペレーティング・システムで、機密性の高いシステム・リソースへのプログラム・アクセスを制御するためにMACが使用されています。

DACシステムでは、リソースの所有者はそのリソースに対して独自のアクセス制御ルールを設定できます。DACは、MACの包括的なポリシーよりも柔軟性が高く、RBACの構造化されたアプローチよりも制限が少なくなっています。

ABACは、ユーザー、オブジェクト、アクションの属性（ユーザーの名前、リソースのタイプ、時刻など）を分析して、アクセスが許可されるかどうかを判断します。RBACは個々のユーザーの属性ではなく組織のロールを使用してアクセスを許可するため、RBACはABACよりも簡単に実装できます。

RBACとABACの違いは、ABACがいくつかの要因に基づいてアクセス許可をその場で動的に決定するのに対し、RBACはユーザーの事前定義されたロールのみに基づいてアクセス許可を決定することです。

ACLは、ユーザーとルールのリストを参照して、システムまたはリソースにアクセスできるユーザーと、ユーザーが実行できるアクションを決定する基本的なアクセス制御システムです。

ACLとRBACの違いは、ACLは各ユーザーに対してルールを個別に定義するのに対し、RBACシステムはロールに基づいてアクセス権を割り当てることです。

大規模な組織の場合、RBACの方がスケーラブルで管理が容易であるため、アクセス制御に適した選択肢と考えられています。