RBAC と ABAC：主な違い、ユースケース、選び方

アイデンティティは、企業セキュリティにおける主要な戦場になっています。 IBM X-Force 2025 Threat Intelligence Index では、有効なユーザー・アイデンティティの悪用が、侵入（intrusions）の約30%に関与していたことが分かっています。しかも攻撃者は、侵入（break in）するのではなく、ログインするケースがますます増えています。

したがって、これらのアイデンティティの背後にあるデータ、アプリケーション、インフラへのアクセスを制御することは、現代のセキュリティにおける最も影響の大きい設計判断の一つです。そして、その判断の中心にあるのが RBAC vs ABAC という議論です。これを誤ると、侵害の影響を増幅させてしまう過剰権限のユーザーか、仕事ができないほど過度に制約された従業員のどちらか、という結果になります。

ロールベースのアクセス制御（Role-based access control, RBAC）と属性ベースのアクセス制御（Attribute-based access control, ABAC）は、「誰が何にアクセスできるか」を決めるための代表的な2つのモデルです。どちらも常に正しいわけではなく、多くの組織にとって現実的な答えは、両者を層状に組み合わせ、さらにそれらを結び付けるガバナンスの枠組みとしてポリシーベースのアクセス制御（Policy-based access control, PBAC）を拡張して適用することです。

このガイドでは、2つのモデルをそれぞれ詳しく解説し、どのような場面でそれが適しているのかを説明します。さらに、ハイブリッドなアプローチに PBAC を組み合わせることで、現代の access control management がどのように形作られるのかを示します。

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

ロールベースのアクセス制御（RBAC） は、組織内でユーザーが保有するロールに基づいてリソースへのアクセスを付与します。管理者はロールを定義し、各ロールに権限を割り当て、さらにユーザーにロールを割り当てます。ユーザーが保有するロールによって、到達できる IT リソースが決まります。

3つの中核となる構成要素は、ユーザー、ロール、権限です。管理者は権限をユーザーに直接割り当てるのではなく、ロールに紐づけます。そのため、ロールの権限を変更すると、そのロールを保有している全員のアクセスが自動的に更新されます。この“間接化”によって、RBACはユーザーから権限への直接割り当てに比べてスケールしやすくなります。

NIST の RBAC モデルは ANSI/INCITS 359 として標準化され、ロールがどれほど厳密に構造化され、統制・管理されているかを示す 4 つの RBAC 成熟度レベルを定義しています。

1. フラット RBAC が基本形です。ユーザーはロールを保持し、ロールには権限が付与されます。ロール階層はなく、責務の分離も強制されません。
2. 階層型 RBAC はロールの継承を導入します。マネージャー ロールは、直属の部下ロールのすべての権限を継承し、階層構造が組織を自然に反映できるようになります。
3. 制約付き RBAC は職務分掌を実現します。財務取引を作成できるユーザーは、それを承認することもできないため、ロール（役割）レベルの制御によって不正を防ぎます。
4. 対称型 RBAC は定期的な見直しを加えます。特権とロールは定期的に確認され、正当性がなくなった場合はアクセス権が取り消されます。

多くのエンタープライズの取り組みでは、制約付きまたは対称型 RBAC を目指します。SOX、HIPAA、PCI DSS などの監査フレームワークでは、文書化された職務分掌と定期的なアクセス確認が求められるためです。

RBAC の仕組み

RBACは、MicrosoftのIDおよびコラボレーションのスタックを含む、多くのエンタープライズプラットフォームでデフォルトの認可モデルとして使われています。同じ基本パターン（ユーザー → ロール → 権限）が、ほとんどの組織が実際に運用しているシステム全体に共通して見られます。

Microsoft Entra の Microsoft Entra は、管理者がクラウド リソースへのアクセスを管理するのに役立ちます。Entra RBACでは：

• あるユーザー グループに仮想ネットワークの管理を許可し、別のグループに仮想マシンの管理を許可できます。
• データベース管理者が SQL データベースを管理できるようにします。
• 特定のWebサイトに対して、指定したグループに制御権を付与するか、アプリケーションにリソース グループ内のすべてのリソースへのアクセスを許可できます。

Active Directory の RBAC は Active Directory を担うセキュリティ グループ上で動作します。各グループは特定のリソースへのアクセスを保持し、すべてのメンバーがそれらの権限を継承します。AD には既定のセキュリティ グループが含まれており、管理者は追加のグループを作成できます。組み込みの例には次のようなものがあります。

• Backup Operators は、標準のファイル権限に関係なくファイルを復元および置き換えできます。
• Remote Desktop Users は、RD Session Host サーバーにリモート接続できます。
• Domain Admins は、特定の AD ドメインにおいて広範な権限を持ちます。
• Enterprise Admins は、子ドメインの追加など、フォレスト全体に及ぶ変更を行えます。
• Schema Admins は Active Directory のスキーマを変更できます。

RBAC in SharePoint では、メンバーが継承するあらかじめ定義されたロールを使用します。例：

• エンドユーザーは、リストやドキュメント ライブラリ内のコンテンツを扱います。
• パワーユーザーは、リスト、ページ、ライブラリなどのサイト コンポーネントとやり取りします。
• サイト オーナーは、SharePoint サイト全体を制御します。
• サイト コレクション管理者は、サイト コレクション内のサイトを制御します。
• SharePoint ファーム管理者は、SharePoint ファームに対して完全な制御を持ちます。

Exchange の RBAC も、ロールベースの割り当てに従います。組み込みの管理ロールには次のものがあります：

• 受信者管理（Recipient Management）のメンバーは、Exchange の受信者を作成または更新します。
• ヘルプデスクのメンバーは、住所や電話番号などのユーザー属性を表示し、更新します。
• Server Management のメンバーは、サーバー固有の機能を設定します。
• Organization Management のメンバーは、Exchange 組織全体に対して最上位レベルのアクセス権を持ちます。
• Hygiene Management のメンバーは、スパム対策およびマルウェア対策の機能を設定します。

RBAC の利点

• 導入して説明しやすい：ロールの定義は、関係者がすでに理解している業務機能に対応します。
• 役割を定義すれば、管理の手間が少ない： オンボーディング、役割の変更、オフボーディングはいずれも役割の割り当てを通じて行われます。
• 監査しやすい： 監査担当者は、誰がどの役割を持っているか、またその役割がどの権限を付与するかを列挙できます。
• 組織の階層構造に自然に合致します： マネージャー、アナリスト、管理者は、事業の構成に合わせて設計された役割に収まります。
• 主要なあらゆるアイデンティティ基盤で幅広く対応： Active Directory、Microsoft Entra、SharePoint、Exchange にはすべて RBAC が標準で組み込まれています。

RBAC のデメリット

• ロールが爆発的に増えることは、典型的な失敗パターンです。: 組織が成長し、例外が増えていくと、ロール数が数百〜数千に達し、ロールを管理できなくなります。
• 静的なロールでは文脈を考慮できません。: 場所、デバイスの状態（姿勢）、アクセス時間、そしてリソースの機密性は、ロールだけでは表現できません。
• 広範な常時権限は横方向（lateral movement）のリスクを生みます。: ロール保有者のアカウントが侵害されると、攻撃者はそのロールが付与するすべての権限を継承します。
• 例外対応はその場限りのロールを生み出します。: チームは例外的なケース（エッジケース）を処理するために、範囲を狭めたロールを作成しますが、それらのロールはほとんど廃止されません。
• ロール数に比例してレビューの負担が増えます。: 自動化なしで対称RBACを大規模に運用するのはコストがかかります。

属性ベースのアクセス制御（ABAC）とは？

属性ベースのアクセス制御（ABAC） は、ユーザー、リソース、要求されている操作、および要求が発生する環境の属性に基づいてアクセスを許可します。RBAC が「ユーザーにどの役割があるか」を問うのに対して、ABAC は「ユーザー、リソース、操作、コンテキストの組み合わせとして、今この瞬間に何が許可されるか」を問います。

管理者は、特定のリソースに対して所定の操作を実行するために必要な属性の組み合わせを指定するポリシーを定義します。

ユーザーがアクセスを要求すると、ABAC は実行時にその要求を関連するポリシーと照合して評価します。属性がポリシーを満たせばアクセスは許可され、満たせなければアクセスは拒否されます。

ABAC は、すべてのアクセス判断において次の4つの属性カテゴリを評価します。:

1. ユーザー（主語）属性：これらの属性は、リクエストを行う人物を説明します。役職、部署、シニアリティ（職位・経験年数）、セキュリティクリアランス（許可レベル）、雇用状態。
2. リソース属性：これらの属性は、アクセスされる資産を説明します。ファイルの種類、データの分類、所有者、機密性レベル、プロジェクトタグ。
3. アクション属性：これらの属性は、ユーザーが行いたいことを説明します。読み取り、書き込み、エクスポート、削除、変更。
4. 環境属性：これらの属性は、リクエストの状況（コンテキスト）を説明します。時間帯、場所、IP アドレス、デバイスのセキュリティ状態、ネットワークの種類。

典型的な ABAC ポリシーでは、4つのカテゴリすべてをまとめて評価します。たとえば、「財務ユーザーは、勤務時間中のみ、かつ会社が承認した暗号化デバイスからのみ、個人を特定できる情報（PII）にアクセスできます。」

この単一のルールは、ユーザー属性（財務部門）、リソース属性（PIIの分類）、アクション属性（読み取り）、および環境属性（営業時間、管理対象デバイス）を組み合わせて、1つの「許可または拒否」の判断を生成します。

ABAC はどのように機能しますか

ABAC ポリシーは、常設のロール割り当てに依存するのではなく、アクセス要求が行われた“その時点”で属性を評価します。リクエストが届くと、ポリシーエンジンが関連するユーザー、リソース、アクション、環境属性を調べ、すべての条件が満たされた場合にのみアクセスが許可されます。

典型的な ABAC ポリシーは次のようになります:

• 給与情報にアクセスするには、ユーザーが人事（HR）部門のメンバーである必要があり、アクセスは営業時間内に行われ、ユーザーは自分の支店の記録のみを参照できる必要があります。
• 営業リードにアクセスするには、ユーザーが米国（United States）地域に割り当てられた営業担当者である必要があります。
• 請求書をエクスポートするには、要求は管理対象デバイスから発信され、営業時間内に実行され、マネージャーが承認しない限り 2,000 件未満の記録を対象にする必要があります。

Microsoft Entra における ABAC は、ABAC が RBAC を置き換えるのではなく拡張することを示す実践的な例です。Microsoft Entra はロールによって基本的な権限を割り当てますが、属性を評価する条件もサポートしています。

管理者は、アクセスを許可する前に、そのオブジェクトに対してロールの割り当てと特定のメタデータタグの両方が必要だと要求できます。ほとんどの最新のクラウド IAM プラットフォーム（AWS IAM、Entra、GCP IAM）は、タグとポリシー条件によってこのパターンをサポートしています。クラウド環境では、ABAC は通常 RBAC を置き換えるのではなく拡張する形で運用されます。

ABAC の利点

• 実行時におけるきめ細かくコンテキストを考慮した判断：アクセスは、恒常的なロールの割り当てではなく、現在の状況を反映します。
• ロールの肥大化を抑えます：属性により、あらゆる例外ケースごとに狭く定義されたロールを用意する必要がなくなります。
• Zero Trust の考え方に自然に合致します：すべての要求は現在のコンテキストに照らして評価されます。これは Zero Trust の認可の中核です。
• 組織の複雑さに応じて拡張できます：属性によって、新しいシナリオにも対応でき、ロールを追加する必要がありません。
• ジャストインタイムおよび時間制限付きのアクセスをサポートします: "active incident ticket" や "scheduled maintenance window" のような環境属性によって、短期間のアクセスが自然になります。

ABAC のデメリット

• 導入の複雑さが高い: 属性セット、ポリシー言語、ガバナンスモデルを定義するには、かなりの初期投資が必要です。
• 属性のスプロール（attribute sprawl）は、ABAC におけるロール爆発（role explosion）の同等の問題です: 一貫した命名、所有者（オーナーシップ）、ガバナンスがないと、属性ライブラリは時間の経過とともに混乱していきます。
• アクセス判断のデバッグが難しい: 結果は複数の属性を同時に評価した結果に依存するため、トラブルシューティングが複雑になります。
• 監査証跡には専用のツールが必要です：意思決定ログがないと、「どのポリシーに一致したのか」と「その理由」を再構成するのは簡単ではありません。
• 大規模環境でのパフォーマンス負荷：すべてのリクエストごとに属性ベースのポリシーを評価することは、ロール権限を参照するよりも重くなります。ただし、現代のポリシーエンジンは企業規模でもこれを処理できます。

RBAC と ABAC：主な違い

RBAC と ABAC は、アクセスがどのように許可されるかから、圧力がかかったときにモデルがどのように破綻するかまで、あらゆる重要な観点で異なります。下の表は、そのトレードオフをまとめたものです。

一言でいうと、RBAC は監査しやすい安定したロール定義を通じてアクセスを整理しますが、コンテキストには適応できません。一方 ABAC は、柔軟な属性ベースのポリシーに基づいて実行時にアクセスを評価し、コンテキストをうまく扱えるものの、運用・統治のコストはより高くなります。

RBAC と ABAC がセキュリティとコンプライアンスを支える方法

両方のモデルは 最小権限 を強制しますが、仕組みは異なります。RBAC は役割レベルで最小権限を強制します。つまり、ユーザーは職務機能に必要な役割だけを保持し、各役割はその機能に必要な権限だけを付与する必要があります。

ABAC はリクエスト（要求）レベルで最小権限を強制します。役割を持つユーザーであっても、リクエストの全体的なコンテキスト（デバイス、時間、リソースの機密性）がポリシーに一致するときだけアクセスできます。

ABAC は Zero Trust アーキテクチャとより自然に整合します。Zero Trust は、すべてのリクエストに対して継続的でコンテキストを認識した検証を要求するためです。RBAC だけでは要件を満たせません。役割の割り当ては固定され、静的だからです。

実際には、ハイブリッドモデルが Zero Trust を大規模に運用する方法です。RBAC が「そもそも誰が何らかのアクセス権を持つべきか」の基準を定め、ABAC が「いま発生しているその特定のリクエスト」が、そのアクセスを適切と判断できる条件を満たしているかどうかを評価します。

規制の整合性は、フレームワークによって異なるモデルを有利にします。

• SOX と PCI DSS は、役割レベルで職務を明確に分離できる RBAC の利点を活用できます。監査人は役割を列挙し、それらを財務上の統制に対応付け、互いに両立しない役割が同一ユーザーに保持されていないことを検証できます。
• HIPAA と GDPR は、データの機微性、アクセスの目的、そしてデータ主体の権利（いずれも属性ベースの概念）を考慮したアクセス判断を両方の規制が求めているため、ますます ABAC スタイルの統制を好む傾向にあります。
• NIST SP 800-53 と ISO 27001 は両方のモデルを参照しており、資産のリスクプロファイルに最も適合する統制を適用することを推奨しています。

コンプライアンス監査では、RBAC が分かりやすい権限の証拠を作成します（ここに役割があり、ここにその権限があり、ここにそれを保持している人がいます）。

ABAC は意思決定ログの証拠（ここにポリシーがあり、ここに評価された属性があり、ここにアクセスが許可された理由があります）を生成します。成熟したコンプライアンス プログラムは、どちらも確実に記録します。

RBAC と ABAC はどちらを選ぶべきか

選択は、組織構造、アクセスの複雑さ、コンプライアンスの範囲（footprint）、および identity governance and administration (IGA) の成熟度によって決まります。

次の場合は RBAC を選択します。

• 貴社の組織では、職務の機能が明確に定義されており、アクセス要件も安定しています。
• アクセスの判断は、職位名や部署以外の文脈にほとんど依存しません。
• コンプライアンスのフレームワークでは、役割レベルでの責任の明確な分離が求められます。
• 貴チームには、利用可能な IAM ツールや専任のアイデンティティガバナンスのリソースが限られています。
• 組織が小規模または中規模で、成長パターンが予測可能です。
• 監査の明確さは何よりも重要であり、監査人は簡単に説明できるエンタイトルメント（権限）レポートを必要とします。

次のような場合は ABAC を選択してください。

• アクセス判断は、役割では表現できない条件に依存します：場所、デバイスの状態（posture）、時間帯、データの機密度、テナント境界。
• 環境が分散している、マルチクラウドである、またはハイブリッドな人員体制をサポートしています。
• HIPAA や GDPR のような規制要件では、状況（コンテキスト）を踏まえたアクセス判断が求められます。
• 貴社の規模が大きいため、例外ケースに対応するためにロールのリストが増え始めています。
• Zero Trust は、明言されたアーキテクチャ上の目標です。
• アクセス要件は頻繁に変化し、あらゆるシナリオごとに新しいロールを作成するのは現実的ではありません。

RBAC と ABAC の組み合わせ：ハイブリッドアプローチ

多くの成熟した組織は、どちらか一方のモデルを選ぶことはしません。ベースラインのアクセスには RBAC を使い、その上に ABAC を重ねて、文脈に応じた判断を行います。

ハイブリッドモデルの仕組み：

• 基盤としての RBAC: ロールは、どの人がどのシステムに対して基礎的なアクセス権を持つかを定義します。財務アナリスト（Finance Analyst）のロールでは、財務レポーティング プラットフォームへのアクセスが許可されます。エンジニアリング（Engineering）のロールでは、コード リポジトリへのアクセスが許可されます。この層は、オンボーディング、オフボーディング、および通常のアクセス権プロビジョニングの大部分を扱います。
• 精緻化のための ABAC: そのベースラインの上に、属性ベースのポリシーが追加され、機微な操作に対して状況を考慮した強制適用を行います。財務アナリストは RBAC を通じてレポートを読むことはできますが、PII（個人を特定できる情報）のエクスポートを行うと ABAC ポリシーがトリガーされます。このポリシーでは、管理されたデバイス、営業時間内での実行、そして行数のしきい値を超えるエクスポートに対する承認が必要になります。

具体的な医療の例：組織は RBAC により、医療従事者に患者記録への基礎的なアクセス権を付与します。次に ABAC ポリシーによって、実際の記録アクセスは、医療従事者が当直中のシフト時間、病院から支給されたデバイスからのみ許可され、さらに医療従事者の所属ユニットに割り当てられた患者に限定されます。

RBAC は「その人が医療従事者（clinician）かどうか」を答えます。ABAC は「そのアクセスが今この時点で適切かどうか」を答えます。

ハイブリッドなアプローチにより、両方の方式の「最悪の部分」を回避できます。文脈はロール名ではなく属性にあるため、ロールの爆発（ロール数の急増）を防げます。

ロールの安定した構造に沿って大まかなアクセス判断が行われるため、ABAC の混乱を回避できます。さらに、説明しやすく、かつ文脈に富んだ監査証拠も生成します。

PBACがRBACとABACをどのように拡張するか

ポリシー ベースのアクセス制御（Policy-based access control、PBAC）は、RBAC と ABAC を結び付けるガバナンスの枠組みです。ロールをそのまま適用したり、属性を単独で評価したりするのではなく、両方を組み合わせられる、人が読めるポリシーにアクセスルールを集中管理します。

PBAC のポリシーでは、例えば次のように記載できます。「アナリストは、非機密文書に対しては任意の場所からアクセスできる。また、機密文書には、営業時間中に企業ネットワークからのみアクセスできる。」最初の条文はロールベースで、2つ目の条文は属性ベースです。これらはいずれも単一のポリシー内にあり、中央で一元管理されます。

PBAC が重要なのは、承認（authorization）をガバナンスされ、監査可能な（auditable）機能に変えるからです。チームは、XACML（eXtensible Access Control Markup Language）などの形式的な言語、またはポリシー・コード化（policy-as-code）フレームワークを使ってポリシーを記述し、バージョン管理、レビュー、そしてプログラムによる展開（deploy）を行えます。

これは、各システムがそれぞれ独自のネイティブなアクセス制御（access control）実装を持つマルチクラウド、ハイブリッド、分散環境において重要です。PBAC は、大規模な組織がハイブリッド RBAC + ABAC を大規模に運用（operationalize）するための方法であり、特に privileged access management によって機密性の高いアカウントを保護する場面で効果を発揮します。

Netwrix が RBAC、ABAC、そしてハイブリッドのアクセス制御を支援する方法

Netwrix は RBAC と ABAC のどちらかを選ばせることはありません。同社のプラットフォームは両方をサポートしており、両者の組み合わせこそが、実際に多くの成熟したプログラムで必要とされるものです。

Netwrix Identity Manager が、役割ベースの基盤を担います。ハイブリッドの Active Directory および Microsoft Entra ID にまたがる RBAC ポリシー、自動化された joiner-mover-leaver（入社・異動・退職）ワークフロー、そして時間の経過とともに役割が正確に保たれるようにするアクセス認証キャンペーンです。

そのノーコードのワークフロー ビルダーにより、社内チームは専門サービスの契約なしにロール、承認、プロビジョニングを調整できます。これが、RBACプログラムが例外主導のロール拡散へと崩れていくのを防ぎます。

Netwrix Access Analyzer は、ハイブリッド環境および ABAC モデルが依存する「確かな根拠（ground truth）」を提供します。ファイル システム、SharePoint、Active Directory、データベース、クラウド プラットフォーム全体で有効なアクセスをマッピングし、存在する権限だけでなく、グループの入れ子、継承、データの機密性を踏まえたうえで、その権限が実際に付与するアクセス内容を明らかにします。

デモを依頼 ご自身の RBAC のベースライン全体と、その上に重ねられる状況（コンテキスト）に応じたポリシーの中で、Identity Manager と Access Analyzer がどのように連携するのかをご覧ください。