RBAC（役割ベースアクセス制御）とは？

担当者は業務遂行に必要なデータのみ参照できる。アクセスは、権限、役割、職務能力など複数の要素で設定される。同様に、コンピュータ資産への権限も、参照、作成、更新などの操作に限定できる。

また、下位の従業員は業務に不要な場合、機密情報に触れることはない。従業員が多数いたり、外部委託やプロジェクトチームを利用している場合、ネットワークアクセスの厳格な管理が難しくなるため、特に有用である。RBACを利用すれば、組織の機密情報や大規模なアプリを守ることができる。

RBACの歴史

非デジタル資産の場合、RBACシステムは古くから存在すると考えられる。古代より、国は限られた役人や一般人がアクセスできるよう、資源や書類を分割していた。しかし、コンピュータの世界では、1970年代にその起源を持つ。

商用コンピュータの時代に、デジタル上で役割や権限が定義されるようになったのが始まりである。しかし、当初は各企業やネットワークごとにカスタム開発された運用であった。

現代のRBACは1992年以降、本格的な形を整え始めた。最初にこのモデルを標準化したのはNISTである。FerraioloとKuhnが考案し、今日では学術、商業、民間分野で広く利用されている。この二人は2000年代まで約20年間、経済的利益と最良の運用方法について研究するチームを率した。

詳細な分析と調査の結果、各役割がどのように異なる権限を持つかを包括した統一モデルが作られ、2004年に公式に採用された。

アクセス制御の種類

RBACを利用することで、エンドユーザが行える操作を大枠にも細部にも管理できる。ユーザが管理者、上級ユーザ、または一般ユーザかを選び、組織の方針に基づいて役割やアクセス権を変更することができる。各従業員には、業務遂行に必要な範囲でアクセス権が割り当てられる。

例えば、エンドユーザの業務内容が変わった場合、その役割を別のユーザに再割り当てしたり、プロジェクトチームに役割を割り当てたり、タスクグループからユーザを追加・削除するなどの対応が可能である。

RBACシステムでのタスクの一部は以下の通り:

• 管理者の役割範囲 – その役割グループが行える操作を制限する。
• 管理者の役割グループ – ユーザの追加や削除を行う。
• 管理者の役割 – 特定の役割グループが実行できるタスクの種類。
• 管理者の役割割り当て – ユーザを役割グループに紐付ける。

ユーザをタスクグループに追加すると、そのグループに紐付く全ての権限が付与される。削除されると、アクセスは制限される。さらに、一時的に特定の資産やプロジェクトへの権限が必要な場合、別グループへの割り当てを行い、タスク完了後に解除することも可能である。

ユーザアクセスの異なる方式には以下がある:

• Essential – 特定のレコードやタスクへの基本的なアクセス。
• Charging – エンドユーザがチャージングアカウントにアクセスする権限。
• Specialized – 専門的なタスクを担うユーザに割り当てられる権限。
• Regulatory – 管理業務を実施するユーザへのアクセス。

Discretionary Access Control (DAC)

特定のシステムや資産の所有者が、誰がアクセスできるかを定める方法を構築する。DACは物理的または自動化された手段を組み合わせ、所有する資産へ自由なアクセスを可能にするため、他の方式より制限が緩い。しかし、その反面、各タスクへセキュリティ設定が引き継がれ、エンドユーザの知らないうちにマルウェアが悪用する恐れもある。RBACを用いてDACを補完することも可能である。

Mandatory Access Control (MAC)

アクセス権は、安全性の各レベルに基づく必須の基準によって制御される。必須アクセス制御では、資産の属性やシステム、セキュリティ要素に基づいて管理が行われ、機密情報の取扱いが定められたユーザやデバイスのみがアクセスできる。政府や軍事組織など、機密性の高い情報を扱う組織ではMACが採用されることが多い。MACの実施には、業務に基づいたアクセス制御が利用できる。

アクセス制御のその他の方式

RBACはアクセス制御を管理する一つの方法だが、それだけが唯一の選択肢ではない。アクセス制御は単に出入りを管理するだけでなく、貴社の安全性に応じた必要な要件やアクセス権カスタマイズに対応する必要がある。さらに、アクセス制御は貴社が取る基本方針でもある。

適切なアクセス制御方式は、システムを守るのみならず、先進的な考え方を示すものでもある。

RBAC以外の明確な選択肢として、アクセス制御リスト（ACL）や属性に基づくアクセス制御（ABAC）があり、それぞれ利点と欠点が存在する。

各アクセス制御方式の詳細を確認し、貴社の業務に最適なものを見極めてほしい。

アクセス制御リスト (ACL)

ACLは、特定の資産に紐付いた表であり、どの操作が許可または禁止されるかを示す。どのユーザが資産にアクセスでき、アクセス後にどの操作が行えるかを明記する。

この方式は下位レベルのアクセス制御に適している。例えば、ファイアウォールでは各システムからのトラフィックが許可されるかどうかを示すためにACLが用いられる。特別に設定されたファイアウォールACLは、アクセス権を厳格に限定し、攻撃を困難にする。

ビジネス運用の観点では、ACLよりRBACの方が優れている。ACLは個々のユーザや下位の情報保護に適するが、RBACは包括的なセキュリティ体制の運用により適している。例えば、ACLは特定のレコードへのアクセス権を付与できても、ユーザがそのレコードをどのように変更するかは制御できない。

属性に基づくアクセス制御 (ABAC)

ABACはRBACの別の選択肢である。ABACシステムでは、ユーザに対し、役職や会計部所属などさまざまな属性が割り当てられる。特定の資産へのアクセスルールは、eXtensible Access Control Markup Language（XACML）を用いて、属性に基づくブール論理で条件が記述される。

ABACは、セキュリティと効率性のトレードオフを図る。ABACを用いれば、詳細なアクセスルールを柔軟に記述でき、資産に対する最適なセキュリティと権限管理を実現するため、非常に細かい規則が必要な場合に適する。

ただし、ユーザが特定の資産にアクセスすべきかを評価する過程は、複雑で計算資源を要する。ABACでは、ユーザの全属性に対してブール論理の評価が行われるため、アクセスの厳密な管理が必要な場合には有力だが、頻繁にアクセスが発生する資産にはRBACの方が適している。

RBACは事前に定義された役割に依存するが、ABACは属性に基づくアクセス制御を採用する。RBACは大まかな条件によるアクセス制御に向く一方、ABACはより細かい管理が可能である。例えば、RBACでは全ての管理者にアクセスが許されるが、ABACでは会計部に所属する管理者にのみ権限が与えられる。ABACは計算資源と時間を多く必要とするため、RBACで不十分な場合に利用すべきである。

‍

RBACモデル

組織内での役割は、ユーザに対し様々な方法や階層で割り当てられる。同様に、RBACモデルではユーザへの権限も3通りの方法で付与できる。以下の通りである:

• Core RBAC

コアモデルは、RBACの各要素を詳細に定めるものである。各役割から各権限まで、このモデルで規定される。そのため、他の2種類のRBACの基礎となるとともに、単独のユーザアクセス権管理手法としても機能する。

まず、すべてのRBACモデルが従うべき3つのルールは以下である:

1. 役割の割り当て: ユーザに特定の役割が割り当てられて初めて、その役割に対応した権限が行使できる。
2. 権限: 割り当てられた役割が、付与された権限を使用する権限を持っていなければならない。
3. 権限付与: ユーザに割り当てた役割が、その権限の使用を許可されている場合にのみ利用できる。

• Hierarchical RBAC

RBACでは、組織と同様に役割の階層を設けることができる。上位の階層にあるユーザはより多くの権限と厳重なセキュリティが与えられ、下位では限られた権限しか持たない。下位層では、公開データや限定的な機能のみがアクセス可能である。

この方式は、複数のユーザ役割に対して高いセキュリティを適用したい場合に有用である。例えば、有料アカウントのビジネスユーザに対して、無料トライアルユーザ以上の機能やセキュリティ設定を追加する場合などが該当する。

ユーザを階層で分けることで、サイバー攻撃が発生した際の被害を軽減できる。また、必要なユーザ（例：管理者やリーダー）に対してのみ高コストな運用を割り当てることで、業務コストを削減できる。

• Constrained RBAC

RBAC運用時の責任や職務は、この基準で定められる。役割分離（SD）の実装は、貴社の要件に応じて静的または動的に設定できる。

静的モデル（SSD）の採用により、相反する役割が同一ユーザに付与されるのを防ぐ。例えば、eCommerceマーケットプレイスにおいて、エンドユーザが出品者とならないよう、購入と販売を排他的な役割とし、出品者は販売のみ、購入者は購入のみとする。

一方、動的モデル（DSD）にはその制約がなく、権限が衝突しても一人のユーザに両方の権限を与えることが可能である。しかし、同一セッション内で両方の権限を同時に使用することはできず、何らかの認証が必要となる。例えば、Windowsでプログラムを変更するには管理者権限が必要であり、ポップアップでの承認が必須である。

RBACの例

RBACシステムの導入を計画する際、中心となるガイドラインがあることは重要である。一見複雑に見えるRBACも、多くの一般的なシステムで利用されている。

WordPress CMSにおけるユーザ役割の再編成は、その代表例である。標準のWordPressシステムでは、主要なユーザ役割は以下のように定義されている:

• Super Admin: サイト全体の管理機能など、あらゆる権限を有する
• Admin: 単一のWordPressサイトの管理機能を有する
• Editor: 他ユーザの投稿も含め、投稿の公開や編集が可能
• Author: 自身の投稿を公開できる
• Contributor: 投稿を執筆できるが、公開はできない
• Subscriber: 投稿を閲覧できるのみ

全体として、WordPressのユーザシステムは、全ユーザに必要最低限の業務が割り当てられ、不必要な高権限が与えられないよう設計されている。WordPressでは『RBAC』と明記されていなくとも、その仕組みが採用されている。

‍

RBACの利点

ネットワークアクセスの管理と監視は情報セキュリティにおいて重要であり、必要に応じアクセスは更新されるべきである。多数の従業員がいる場合でも、各ユーザの役割により機密情報への不正アクセスが制限され、セキュリティの維持が容易になる。利点は以下の通りである:

1. 正当な雇用とITサポートコストの削減

RBACを利用すれば、採用時や役割変更時の手間が削減できる。システム、ステージ、アプリ全体でユーザの追加・変更・移動が容易になり、ユーザの割り当てによってミスも減少する。規制対応に費やす時間の短縮も、RBACの経済的メリットの一つである。また、適切なユーザを組織に統合するための事前設定シナリオも提供される。

1. 運用効率の向上

RBACはシンプルで明確な手法であり、下位のアクセス制御を手作業で行う煩雑さを解消するだけでなく、事業の拡大に合わせた役割管理により、ユーザがより自由に業務を遂行できるようになる。

1. 一貫性の向上

全ての組織は政府や規制に依存している。RBACフレームワークを整えることで、IT部門や管理者がデータのアクセス・利用を確実に管理でき、法令や管理上の要求を満たすことができる。これは、PHIやPCI情報など多くの機密情報を扱う医療・金融関連に特に重要である。

1. 規範の適切な実施の確保

方針やガイドラインに基づき、上級リーダーの業務を通して段階的に手法が導入され、各システムやユーザ間で異なる役割がシームレスかつ確実に適用される。さらに、ユーザ権限の自動更新により、役割や責任の変化が即座に反映され、企業レベルのアクセス制御はユーザ認証、品質管理、監査準備を含む統制維持に寄与する。

経営者やプロジェクトリーダーにとってのその他の利点は、個々のユーザへの権限割当の標準化や、人事情報の変化に応じた動的な権限更新などである。これにより、管理者は明確な統制水準と監査可能な操作履歴を維持し、コンプライアンスの管理と効果的なセキュリティ監査計画を実施できる。

導入後、貴社は以前に比べ格段に安全になり、データの盗難リスクも大幅に低減される。さらに、ユーザやITスタッフの生産性向上といった多方面のメリットも享受できる。Wallarm的には、選ぶに迷う余地はないといえる。

‍

他システムとのRBACの比較

最適なアクセス管理手法を選ぶなら、貴社のネットワーク階層や組織内での権限配分に最も合致するものを採用すべきである。つまり、ネットワーク内での権限の衝突を減らし、データやアプリの安全性を高める必要がある。

そのため、RBACをはじめ、ACL、ポリシー型、属性型などの各方式を検討することになる。ここでは、それぞれをRBACと比較する。

RBAC vs. ABAC（属性に基づくアクセス制御）

ユーザの権限を役割で定義するのではなく、ABACモデルはユーザ名、職位、セキュリティレベル、所在地などの属性に依存する。組織内で必要な、より厳格なアクセス制御に有用であり、場合によってはユーザ役割と属性を併用して業務資産のアクセス権を定義する。

ABACを理解しやすくするため、多支店のオフィスを例にとるとよい。分類基準は地域とユーザ役割となり、たとえばノースカロライナの管理者がコロラドの管理者権限を持つことはない。つまり、所属する部門だけでなく、地域もアクセス可否の判断に影響する。

RBAC vs. ACL（アクセス制御リスト）

RBACと異なり、ACLは、資産の利用・変更が可能なユーザと不可能なユーザのリストを管理する。リストに名前があればアクセスが許可され、なければ要求は却下される。ACLでは、二種類の資産に対してアクセスの許可と拒否が行われる。

• ファイルやフォルダ（例：データ）：ドキュメントやその他のファイルに対し、利用を許可するまたは禁止するユーザや機器をオブジェクトごとにリスト管理する。
• ‍ルータ／スイッチング：ネットワークの場合、ACLはエンドポイント、トラフィック、またはプロセスが特定のルータやスイッチを通過できるかをチェックする。許可・禁止のユーザやシステムのリストで判断される。

一般に、この方式は特定の資産を複数のユーザが利用する場合や、逆に多数のユーザ・役割に対してアクセスを遮断する場合に有用である。

ACLは主にネットワークやトラフィックに関するシナリオで用いられ、各エンドポイントのアクセス可否を制御することで、高いセキュリティと監視能力を実現する。

下位レベルの資産や広域用途には適しているが、ビジネス用途としてはRBACの方が実用的で管理しやすい。

RBAC vs. PBAC（ポリシー型アクセス制御）

PBACは、組織の方針と権限レベルに全面的に依拠する。ユーザ役割ごとに静的な権限リストを保持するのではなく、業務の動的なルールやポリシーを利用するため、業務ポリシー変更時の大幅なシステム改修が不要である。

PBACはABACに類似するが、実装はより容易であり、属性数の多い複雑なABACシステムに比べてITおよび開発リソースをあまり必要としない。

適切に導入すれば、優れた監視機能、高い柔軟性、動的な権限制御、透明性の向上といった多くの利点が得られる。

‍

RBACセキュリティ - ビジネスでの実装

企業でRBACを導入する際は、軽視してはならない。ネットワークの整備と同時に、小さな不便や業務上の混乱を避けるため、段階的な対策が求められる。RBAC導入前に検討すべき点は以下の通りである:

1. 現状把握

現在、アクセス権が設定されている全システム、資産、アプリをリストアップする。場合によっては複雑に見えるが、機密性の高いシステムの一覧も作成すること。セキュリティ認証は重要な情報資産である。基本的に、これらのシステムやエリアの現状を把握することが、全体のデータ状態の理解につながる。

1. 現行の役割

各担当者が何をしているかを明確にするには、正式な役割一覧や現状の確認が必要である。非公式な情報や過去の経験に頼らず、組織内の正式な役割情報を集めるようにする。

1. 方針の策定

実施する全ての変更は、現職および将来の専門家が確認できるよう記録しておく必要がある。RBACシステムの導入に際しても、新たな設計を明確に文書化することで、トラブルを未然に防げる。

1. 変更の実施

現状のセキュリティ状況と役割が把握され、方針が策定されたら、改善を実施する最適なタイミングである。

1. 継続的な対応

RBACの基本モデルは後々調整が必要となる。定期的に役割とセキュリティ状況を評価し、運用状況および組織の安全性を確認すること。

RBAC導入を成功させるため、実施プロセスを段階的に進めることが重要である:

• 貴社の業務ニーズの把握 — RBAC導入前に業務要件、業務フロー、変化点を詳細に分析し、規制や監査の要件、現状のセキュリティ状況を評価する。また、各種アクセス制御方式のメリットも検討する。
• 実装規模の整理 — RBACの必要レベルを考慮し、組織の要求に応じた実装計画を策定する。機密データを扱うシステムやアプリに絞ると、変化を円滑に進められる。
• 役割の定義 — 要件分析と業務実態の把握が済めば、役割定義が容易になる。粒度の不足、役割の重複、不要な権限付与といった落とし穴に注意する。
• 段階的な展開 — RBACの導入は一度に全体を行うのではなく、段階的に実施する。まずは大まかなアクセス制御から開始し、徐々に細分化していく。ユーザの意見を取り入れながら、現状を評価し、次の実施フェーズを計画する。

情報保護は、どの組織にとっても重要な経営課題である。RBAC設計により、データが認証やセキュリティ基準に準拠することが保証され、さらにIPアドレスの一覧化など、戦略的視点での主要指標が得られる。

結局、役員だからといって全てにアクセスする必要はない。組織の最上層、すなわちCXO層が最も関心を持つ分野である。全ユーザが業務に必要な最低限のアクセスに留めれば、万一ハックが発生した際のデータ流出リスクを低減できる。