ロール ベース アクセス制御（RBAC）とは？実務に役立つ完全ガイド

ロール ベース アクセス制御（RBAC）とはユーザーのアクセス権限管理に基づくセキュリティ手法です。RBACでは、ロールごとに定義された特権に基づいて、ユーザーがアクセスできる情報、閲覧や変更など実行できる操作。およびアクセス可能な時間が制御されます。

RBACのはじまり

ロール ベース アクセス制御（RBAC）システムが誕生したのは、1970年代にマルチ ユーザーとマルチ アプリケーションのオンライン システムが登場したときでした。一度に一人のユーザーが単一のアプリケーションを使用するという状況が変化したことで、複数のユーザーがシステムにアクセスできるようにしつつ、各ユーザーが使用できる機能とデータを制御できるセキュリティ制御の必要性が浮き彫りとなりました。RBACによってこのようなマルチ ユーザー システムを管理するシステムが提供され、誰がどのようなアクセス権限を持っているかを確認して監査を実施する手段が実現されました。

組み込み型からスタンドアロン型への進化

初期のアプリケーションには開発時にRBAC機能が組み込まれていました。ただし、このようなアプリケーションが広く使用されるようになるにつれ、組み込みのRBACではセキュリティ制御に変更や更新が迫られた際に問題が生じることが明らかになりました。このような背景が、さまざまなユーザー ベースにまたがって複数のアプリケーションのセキュリティ保護と管理に使用できる、スタンドアロンのセキュリティ ツールとしてのRBACへの移行を促しました。このアプリケーション レベルのセキュリティ モデルによって、管理者はロールを作成し、複数のシステムにまたがるアクセス制御と特権の更新を一元的に適用できるようになりました。

RBACの高度化とセキュリティポリシーの実現

さらに進歩したRBACシステムでは、管理者はユーザーとロールの関係を確立できるようになりました。これにより、最小限の管理サポートでさらに詳細な制御（権限委譲や職務分掌といったセキュリティ ポリシーなど）が可能になりました。

ロールに基づく柔軟な権限管理

1. ロール ベース アクセス制御ではアクセス権許諾はロールのみに基づくため、管理が簡素化されます。ユーザーの役職が変わった場合（退職を含む）、管理者はユーザーのロールを変更するだけでアクセス権許諾が自動で更新されます。RBACを使用すると、複数のロールをユーザーに割り当てることができます。
2. ユーザー ロールの割り当てでは、ロールまたはタスクに基づいてユーザーのアクセス権許諾またはアクセス権限を定義します。
3. ユーザー ロールの認可では、ユーザーがロールに対して承認されていることを、また関連機能の実行が承認されていることを確認します。
4. ユーザー ロールのアクセス権許諾とアクセス権限では、ユーザーが実行できる/できない操作を具体的に定義します。

RBACを構成する基本要素とその役割

RBACを構成する主要な概念を理解し、全体像を把握しましょう。

それぞれ解説します。

オペレーション

オペレーションとは、コンピューティング環境で実行されるアクティビティを指します。コンピューティング環境における最も一般的なオペレーションは、入力、処理、出力、保存、制御です。RBACシステムで制限されるオペレーションの一例としては、システム構成の変更が挙げられます。通常、オペレーションのアクセス権許諾を管理するのは、管理者やその他のパワー ユーザーです。

アクセス権許諾

アクセス権許諾により、どのロールがどのリソースとオペレーションにアクセスできるかが決定されます。アクセス権許諾によってロール/リソース/オペレーション間の関係を定義することで、ユーザーが実行できるオペレーションに関するルールを明確に確立します。

リソース（オブジェクト）

リソース（オブジェクトとも呼ばれます）とはデジタル資産（ファイルやデータ ストア、システムなど）のことで、ユーザーにはそれらを使用するアクセス権許諾（アクセスや共有、変更など）が付与されます。RBACシステムは、リソースへのユーザー アクセス権限の許可を定義するのに加え、使用ログ（どのユーザーがどのリソースにアクセスしたか、何を行ったか、アクセスの日時と期間など）を保持する目的にも使用されます。

ロール

ロールとは、ユーザーに適用されるアクセス権許諾のコレクションです。RBACシステムでは、許可されるアクションは個々のアイデンティティ（ID）ではなくロールに基づきます。場合によっては、一人のユーザーに複数のロールが割り当てられることがあります。 通常、ロールは階層に従って作成されます。たとえば、低位のロールにはファイルを閲覧するアクセス権許諾は付与されますが、ファイルを編集/共有するアクセス権許諾は付与されません。 通常、ロールの割り当てはユーザーのさまざまな特徴に基づきます。たとえば、ユーザーの職務や場所、リソースへのアクセスに使用しているデバイスなどです。ほとんどの組織では、職務に基づいて事前に構築されたロール セットが用意されています。

セッション

セッションはユーザーがリソースやオペレーションを操作した時間の長さで、ユーザーが最初にリソースやセッションにアクセスした日時とファイルやアプリケーションが閉じられた日時が追跡されます。セッションの詳細（実行内容、接続元のデバイスや場所など）はRBACシステムによって記録され、監査目的で使用されます。

ユーザー

ユーザーは、ロールの割り当てを通じてアクセス権限が付与されるエンティティです。RBACシステムでは、利用者だけではなくサービスやコンピューティング エンティティ（エンドポイント デバイスや仮想マシンなど）もユーザーに含まれます。つまり、ユーザーとはシステムを操作する必要がある個人やプロセス、アプリケーションを指します。

RBACアクセス権許諾

ロール ベース アクセス制御で重要なのは、「アクセス権許諾がロールに従う」べきであり、その逆ではないことを覚えておくことです。各ロールで実行すべきことを判断したうえで、アクセス権許諾を適用しましょう。ユーザーがシステム内でアクセスできる内容と実行できる操作を指定するようにRBACアクセス権許諾を設定する際は、以下の点も考慮する必要があります。

アクセス

1. 特定のアイテム（ファイルやアプリケーション、データベースなど）を開くことができるのはどのユーザーか
2. 特定の資産の存在を認識させる必要があるのはどのユーザーか
3. 表示範囲にはどのような制限を設けるべきか

変更

1. 特定のアイテムに変更を加えることができるのはどのユーザーか
2. 変更を行うにはどのような承認が必要か

共有

1. ドキュメントをダウンロードできるのはどのユーザーか
2. ドキュメントを共有できるのはどのユーザーか

RBACのベスト プラクティス

以下は、企業がロール ベース アクセス制御（RBAC）を導入する際に考慮すべきベスト プラクティスの例です。

1. ユーザー（ワークフローや必要なリソースを含む）を分析する
2. ロールの監査を継続的に実施することで、ロールを最新状態に保って現在の要件に適合させる
3. すべてのユーザーに必要なアクセス権限を含む、基本的なロールを作成する
4. 一般的なアクセス諸要件を満たしているロールを特定する
5. 組織全体にあるすべてのシステムにまたがってRBACが統合されていることを確認する
6. ロールの変更を処理するプロセスを確立する（ユーザーの設定と削除など）
7. アクセス制御が必要なリソースを特定する
8. 従業員トレーニング プログラムにRBACの原則とその仕組みを含める
9. ロールを作成しすぎないように注意する

ロール ベース アクセス制御の種類

RBAC標準には、4種類のアクセス制御（コア、階層型、対称、制約付き）があります。

それぞれ解説します。

コアRBAC

コア ロール ベース アクセス制御では、システムの主なコンポーネントが詳細に規定されます。単独でも、階層型RBACと制約付きRBACのベースとしても使用できます。コアRBACは5つの静的な要素（ユーザー、ロール、アクセス権許諾、オペレーション、オブジェクト）から、その中のアクセス権許諾はオブジェクトに適用されるオペレーションから構成されています。

階層型RBAC

階層型ロール ベース アクセス制御では、ロール構造内の階層を使用してロール間の関係（シニア、ミドル レベル、ジュニアなど）を確立します。階層型RBACでは、シニア ロールを持つユーザーには、部下全員のアクセス権許諾すべてと、各自のニーズに応じたアクセス権許諾が付与されます。

対称RBAC

対称ロール ベース アクセス制御では、管理者はアクセス権許諾ロール レビューとユーザー ロール レビューを実施することで、既存のロールに割り当てられたアクセス権許諾を評価できます。

制約付きRBAC

制約付きロール ベース アクセス制御では、静的/動的な職務分掌（SoD）によってコアRBACを補強します。静的な職務分掌（SSD）を用いると、ユーザーは相互排他的なロールを持つことはできません。たとえば、ユーザーは提案を作成・承認できなくなります。動的な職務分掌（DSD）を用いるとユーザーは競合するロールを持つことができるようになりますが、同じセッション中に両方のロールを利用することはできません。

その他の種類のアクセス制御

それぞれ解説します。

属性ベース アクセス制御（ABAC）

属性ベース アクセス制御はユーザー認可ソリューションで、ロールではなくユーザーの属性や特性を評価することで、組織のセキュリティ ポリシーに基づいて特権アクセス権限を決定します。ABACでは、アクセス ルールを極めて詳細に設定できます。

アクセス制御リスト（ACL）

アクセス制御リストには、リソースに関連付けられたアクセス権許諾が記載されています。ユーザーごとにエントリが用意されており、各オブジェクトのセキュリティ属性に関する詳細が記載されています。

ACLによってOSは、オブジェクトにアクセスできるユーザーと実行が認証されているアクションを把握できます。アクセス権限は2種類のカテゴリ（ネットワークシステムとファイルシステム）で許可/拒否されます。ネットワークでは、トラフィックを評価するため、ルーターとスイッチにACLが適用されます。

また、ACLではアクティビティが評価され、ネットワーク経由のアクセスが許可されているかどうかも評価されます。ファイル システムではACLが使用され、ファイルとディレクトリへのOS経由のアクセスがフィルタリング・管理されます。

任意アクセス制御（DAC）

任意アクセス制御は、オブジェクトの所有者グループまたはサブジェクトが決定したポリシーに従い、オブジェクトへのアクセスを許可/制限します。DACによってリソースに対する完全な制御がユーザーに付与されるため、他のアクセス制御オプションよりも制限が少なくなります。

DACによってオブジェクトへのアクセス権許諾がサブジェクトに付与されている場合は、以下の操作を実行できます。

1. ユーザーが他のサブジェクトと特権を共有できるようにする
2. セキュリティ属性を変更する
3. 新規/更新されたオブジェクトに関連付けるセキュリティ属性を選択する
4. アクセス制御を統制するルールを変更する
5. 他のサブジェクトやオブジェクトと属性情報を共有する

強制アクセス制御（MAC）

強制アクセス制御では、情報の機密性とユーザーのアクセス権許諾レベルに応じ、リソースへのアクセスが制限されます。管理者はMACの基準を定義します。OSまたはセキュリティ カーネルによってMACは適用され、ユーザーはMACを変更できません。

RBACとアクセス制御リスト（ACL）の比較

アクセス制御リストはOSなどに搭載されているセキュリティ機能の1つで、ファイルやシステムなどへの利用者の権限を列挙したリストです。では、RBACの違いを解説します。

ロール ベース アクセス制御（RBAC）とACLは目的が異なります。たとえば、RBACはビジネス アプリケーションとデータ アクセスの管理に最適であるとして、ACLは個々のユーザー レベルと全体的なデータのセキュリティの管理に長けていると考えられています。また、RBACは組織全体のセキュリティに、ACLは特定ファイルへのアクセスを付与するのに適しています。

RBACと属性ベース アクセス制御（ABAC）の比較

両者の主な違いはアクセス付与方法にあります。RBACではユーザーのロールと責任に基づいて、ABACでは以下のような属性や特性に基づいてアクセスが付与されます。

ユーザーの種類

1. セキュリティ クリアランス
2. ユーザー名
3. 年齢
4. 職務
5. 部門

時間帯

1. リソースへの夜間アクセスをロック ダウンする
2. ユーザーが監督下にない時間帯の編集を制限する
3. 週末の資料へのアクセスを制限する

地域

1. 特定のエリア（オフィスや大学、国など）へのアクセスを制限する
2. 特定のデバイス（スマートフォンやWi-Fi対応ノート パソコンなど）からのアクセスを拒否する

一般的に、組織は全般的なアクセス制御にRBACを、詳細なアクセス制御にABACを使用します。

RBACモデルの種類と導入プロセスの全体像

ロール ベース アクセス制御システムを導入する際には、体系的なアプローチが欠かせません。このようなアプローチには、最適なロール ベース アクセス制御モデルの決定に加え、導入プロセスにおける各ステップの理解と準備が含まれます。

RBACモデルを用いたロールとアクセス権許諾の効果的な設定

ロール ベース アクセス制御モデルには、コアRBAC、階層型RBAC、制約付きRBACの3種類があります。RBACシステムを導入する際には、3種類ともしっかり理解する必要があります。

以下、それぞれ解説します。

コア ロール ベース アクセス制御

コアRBACモデルは、階層型RBACモデルと制約付きRBACモデルの基盤として、基本的なRBACシステムとRBACサーバーで使用されます。コアRBACシステムのコンポーネントと機能を備え、すべてのRBACモデルに適用される以下のルールに従います。

• ロール割り当て：RBACシステムでロールが割り当てられたユーザーにのみ、アクセス権限が付与される
• ロール認可：アクセスがユーザーに付与される前に、RBACシステムでユーザーのロールを検証する必要がある
• アクセス権許諾認可：ユーザーに付与できるのは、RBACシステムで確立されたアクセス権限の許可のみ

階層型ロール ベース アクセス制御

階層型ロール ベース アクセス制御では、コアRBACモデルを基盤にロール階層が導入されます。このモデルでは、組織構造に基づいてロールが構造化されます。階層型RBACではロール間の共有と継承に加え、ロール同士の相互連携を行うことができます。たとえば、以下を実現することができます。

• ゲスト ユーザーに最低限のアクセス権許諾セットを用意する
• 通常ユーザーにゲスト アクセス権許諾と追加のアクセス権許諾を用意する
• パワー ユーザーにゲスト ユーザーや通常ユーザーに付与される以上のアクセス権許諾を用意する
• 管理者に他のユーザー タイプのアクセス権許諾を含む広範なアクセス権許諾セットを用意する

このモデルには、以下のようなさまざまな種類の階層を適用できます。

• ツリー階層はボトムアップ型で、ツリー最下位のアクセス権許諾が上位のアクセス権許諾に適用されます（上述）。
• 逆ツリー階層はトップダウン型で、アクセス権許諾を継承している上位レベルのロールが下位レベルのロールに付与されます。
• 格子階層はボトムアップ型とトップダウン型のアプローチの融合であり、さまざまなレベルのユーザーが上位/下位のロールからアクセス権許諾を継承できるようになっています。

制約付きロール ベース アクセス制御

制約付きロール ベース アクセス制御ではコア モデルに職務分掌（SoD）が適用され、管理者は以下2種類のSoDのいずれかを使用できます。

1. 静的な職務分掌：組織によって定義された相互排他的なロールを、単一のユーザーが持てないことが決定されます。この種の職務分掌の一例として、小切手の作成権限は認証済みだが署名はできない状態が挙げられます。
2. 動的な職務分掌：相反するロールをユーザーに割り当てることができますが、単一のセッションでは両方のロールを実行することはできません。この種の職務分掌では、通常、2名の異なるユーザーがアクションを承認する必要がある旨のルールが適用されます。うち1名は、相反するロールを持つユーザーである可能性があります。

RBACの導入ステップ

システムがセキュリティ要件を確実に満たすようにするため、詳細の分析に時間をかける必要があります。RBACを導入する際に実行する必要がある具体的なステップには、以下が含まれます。

1. 全リソースの完全なインベントリを作成する（アプリケーション（オンプレミスとクラウド）、サーバー、ドキュメント、ファイル、ファイル サーバー、データベース、その他のセキュリティが必要な記録など）
2. マネージャーや人事部と協力してロールを特定する
3. すべてのロールを確認のうえ、含める必要があるロール数と混合グループにまとめることができるロールを決定する
4. マネージャーやその他の主な関係者から、ロールに関するフィードバックとアクセス権許諾レベルに関する意見を募る
5. ロールにアクセス権限の許可を割り当てる
6. 統合連携スケジュールを作成する（システム開発に加え、ユーザーへの周知とトレーニングを含む）
7. 計画の実行。不具合が一切ないことを注視し、必要に応じて修正と調整を加える

RBACの導入を管理するためのベスト プラクティス

1. ロール ベース アクセス制御システムの使用方法に関するポリシーを文書化する（変更プロセスの詳細を含む）
2. RBACシステムの最適化方法に関するマネージャーとユーザーからの意見を積極的に集め、必要に応じて関連性のある変更を加える
3. ロールとセキュリティのステータスを継続的に評価する
4. 変更を導入する前に、ユーザーのアクセス権許諾に対する変更リクエストの理由と影響を考慮する
5. アクセス権許諾に関連するセキュリティ プロトコルを適用する

RBACにおけるロール指定とアクセス権許諾の具体例

RBAC指定先の例

RBACシステムには、以下のような一般的な指定先があります。

1. 管理ロールの割り当て（ロール グループにロールを関連付ける）
2. 管理ロール グループ（メンバーを追加/削除可能）
3. 管理ロールの範囲（ロール グループによって管理されるオブジェクトに制限を設ける）

RBACロールの例

ロール ベース アクセス制御では、アプリケーション内のさまざまなロールをユーザーに指定できます。これらのロールは、アプリケーションの種類によって異なります。例としては、以下のようなRBACロールが挙げられます。

KubernetesのRBACロールの割り当て要素

1. Role：名前空間レベルでアクセス権許諾を指定する
2. ClusterRole：クラスター レベルや環境全体の名前空間に対してアクセス権許諾を指定する
3. Subject：ユーザー、グループ、またはサービス アカウントが記述される
4. RoleBinding：名前空間レベルでエンティティにロールをバインドするためのサブジェクトとその割り当てられたロールを一覧表示する
5. ClusterRoleBinding：クラスター内にあるすべての名前空間について、クラスター レベルでサブジェクトとその割り当てられたロールを一覧表示する

Microsoft AzureのRBACロールの割り当て要素

1. Principal：リソースを要求し、アクセス権限が付与されるユーザー、グループ、サービス プリンシパル、またはマネージドID
2. Role definition：アクセス権許諾セット。特定のロールでプリンシパルがリソースに関して実行できる操作を定義する
3. Scope：ロールがアクセスできるリソースとアクセス権許諾レベルを定義する

RBACアクセス権許諾の例

ロール ベース アクセス制御のアクセス権許諾は、ロールとアクセス要件に基づいて付与されます。ロールとアクセス権許諾は、組織におけるユーザーの役職に応じて割り当てられます（管理者やスペシャリスト ユーザー、エンド ユーザーなど、）。以下のようなRBACアクセス権許諾があります。

1. Administrative：管理機能を実行するユーザー用
2. Billing：請求先アカウントにアクセスするエンド ユーザー用
3. Primary：特定のアカウントまたはロールの主な連絡先用
4. Technical：技術的なタスクを実施するユーザー用

RBACでは、ユーザーのアクセス権限の許可は、グループ共通の責任とニーズに結び付けられます（人事や営業、財務など）。以下のように、各ロールにはアクセス権許諾セットが付与されます。

ロール ベース アクセス制御（RBAC）の主なメリット

職務分掌の実現

ロールが分離されているため、ハッカーのアクセス権限はアカウントに許可されたリソースに限定されることになり、理論上は単一のユーザーが重大な侵害を引き起こすことは不可能です。

運用効率の向上

ロール ベース アクセス制御では、アクセス権限の許可の割り当てと管理を簡素化するアプローチを実現することで、管理を簡素化して運用効率を向上させます。また、RBACによって管理者は、ロールを迅速に追加/変更し、OS、プラットフォーム、アプリケーションにまたがってグローバルに導入できます。以上は、内部ユーザーとサード パーティ ユーザーに対して実行できます（一時的なアクセス権限のみを必要とするユーザーを含む）。

コンプライアンスの向上

ロール ベース アクセス制御ではリソースへのアクセス権限を制限することで、無数の規制で定められているデータ保護要件とプライバシー要件を、組織が遵守できるようにします。

また、ロールに基づくアクセスの自動化では、未認証のユーザーに機密データを誤って公開する可能性のあるヒューマン エラーを削減することで、コンプライアンス面をサポートできます。

また、RBACは監査対応でもあるため、コンプライアンス要件への対処もサポートできます。

貴重な管理時間の解放

ロール ベース アクセス制御により、管理者はユーザー アクセス権許諾の管理に必要な時間を削減できるため、価値も重要度もより高いタスクに集中できます。さらに、特定のプロセスとアプリケーションへのアクセスを制限することで、組織はリソースの使用（ネットワーク帯域幅やメモリ、ストレージなど）を最適化できます。

可視性の向上

ロール ベース アクセス制御によってネットワーク管理者とマネージャーは、オペレーションとユーザーのアクティビティをより詳細に把握・監視できます。また、ユーザーがアクセスできるリソースを把握できるようになるため、セキュリティ プロトコルへのコンプライアンスと準拠を確保できます。

ゼロ トラスト セキュリティの実現

ロール ベース アクセス制御により、ゼロ トラスト セキュリティの基本原則である最小権限の原則が導入・適用できるようになります。RBACでは、ユーザーのロールと、そこに関連するタスクを実行するために必要な権限に基づいてユーザーへのアクセス権限の許可を制限することで、侵害とデータ漏洩のリスクが大幅に軽減されます。

まとめ

ロール ベース アクセス制御は、ユーザー中心主義のセキュリティを実現するための実績のあるソリューションであり、管理者にとっては定番の選択肢です。使いやすいうえに信頼性も高いRBACを用いれば、リソースを保護し、組織が多くの規制に含まれるセキュリティ基準とプライバシー基準を遵守できるようになります。