最小権限アクセスの設計 - RBACとABACの使い分け

ゼロトラストセキュリティにおいて、「必要最小限のアクセス権のみを付与する」という最小権限の原則は、認証・認可の基盤となる重要な概念です。たとえ正当なユーザーであっても、業務に不要なリソースへのアクセスを許可すべきではありません。この原則を実現するためのアクセス制御モデルとして、RBAC（Role-Based Access Control）とABAC（Attribute-Based Access Control）があります。

本記事では、最小権限アクセスの設計について以下の内容を解説します。

• 最小権限の原則（Principle of Least Privilege）の定義と重要性
• RBACとABACの仕組みと特徴の比較
• 適切な権限モデルの選択基準
• 過剰権限のリスクと検出方法
• ゼロトラスト環境における権限設計のベストプラクティス

この記事を読むことで、アクセス制御モデルの違いを理解し、最小権限に基づく権限設計ができるようになります。

前提知識

本記事を理解するために、以下の知識があることを前提としています。

• ゼロトラストの基本原則を把握している
• 認証と認可の違いを理解している
• IAMの基本的な概念を知っている

ゼロトラストの基本原則についてはゼロトラストセキュリティ入門 - 基本原則と7つの柱を理解するを、アイデンティティ管理の基礎についてはゼロトラストにおけるアイデンティティ管理 - IAMとIdPの基礎を先に読むことをお勧めします。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

1. 最小権限の原則を自分の言葉で説明できる
2. RBACとABACの違いを明確に説明できる
3. 組織やシステムに適したアクセス制御モデルを選択できる
4. 過剰権限のリスクを特定し、対策を立案できる
5. ゼロトラスト環境に適した権限設計の方針を策定できる

最小権限の原則とは

最小権限の原則（Principle of Least Privilege: PoLP）は、ユーザー、プロセス、システムに対して、その機能を実行するために必要最小限の権限のみを付与するセキュリティ原則です。この原則は、1975年にJerome SaltzerとMichael Schroederによって提唱されました。

最小権限の原則の3つの側面

最小権限を実現するには、以下の3つの側面を考慮する必要があります。

flowchart TB
    subgraph polp["最小権限の原則"]
        direction TB
        
        subgraph scope["スコープの制限"]
            direction LR
            resource1["リソースA"]
            resource2["リソースB"]
            resource3["リソースC"]
        end
        
        subgraph permission["権限の制限"]
            direction LR
            read["読み取り"]
            write["書き込み"]
            delete["削除"]
            admin["管理"]
        end
        
        subgraph time["時間の制限"]
            direction LR
            start["開始時刻"]
            end_time["終了時刻"]
            duration["有効期間"]
        end
    end
    
    user["ユーザー/プロセス"]
    
    user --> polp
    
    scope --> |"必要なリソースのみ"| resource1
    permission --> |"必要な操作のみ"| read
    time --> |"必要な期間のみ"| duration
    
    style resource2 fill:#ccc,stroke:#999
    style resource3 fill:#ccc,stroke:#999
    style write fill:#ccc,stroke:#999
    style delete fill:#ccc,stroke:#999
    style admin fill:#ccc,stroke:#999

なぜ最小権限が重要なのか

最小権限の原則がゼロトラストセキュリティで重視される理由は、以下の3点に集約されます。

攻撃面の最小化

ユーザーやプロセスが持つ権限が少なければ、アカウントが侵害された場合の被害範囲を限定できます。管理者権限を持つアカウントが乗っ取られた場合と、読み取り専用アカウントが乗っ取られた場合では、被害の深刻度が大きく異なります。

内部脅威の軽減

悪意のある内部者による情報漏洩や破壊行為のリスクを軽減できます。従業員が業務に不要なデータにアクセスできなければ、意図的な情報持ち出しの機会を減らせます。

コンプライアンス要件の充足

多くの規制やフレームワーク（SOX法、HIPAA、PCI DSS、GDPR、NIST CSFなど）が最小権限の原則の実装を要求しています。

最小権限の原則における課題

最小権限を実現するには、いくつかの課題を克服する必要があります。

アクセス制御モデルの基礎

最小権限の原則を実装するためのアクセス制御モデルには、主に以下の種類があります。本記事ではRBACとABACを中心に解説しますが、まず全体像を把握しておきましょう。

主要なアクセス制御モデル

flowchart LR
    subgraph models["アクセス制御モデルの進化"]
        direction LR
        dac["DAC<br/>所有者ベース"]
        mac["MAC<br/>ラベルベース"]
        rbac["RBAC<br/>役割ベース"]
        abac["ABAC<br/>属性ベース"]
        rebac["ReBAC<br/>関係ベース"]
    end
    
    dac --> mac --> rbac --> abac --> rebac
    
    style dac fill:#f9f,stroke:#333
    style rbac fill:#9f9,stroke:#333
    style abac fill:#9ff,stroke:#333

企業環境で最も広く採用されているのはRBACであり、近年はより柔軟なABACへの移行や、RBACとABACのハイブリッドアプローチが増えています。

RBACの仕組みと特徴

RBAC（Role-Based Access Control）は、ユーザーに直接権限を付与するのではなく、役割（ロール）を介して権限を付与するアクセス制御モデルです。NIST SP 800-207やNIST RBAC標準で定義されており、企業システムで広く採用されています。

RBACの基本構造

RBACでは、以下の要素で構成されるモデルを使用します。

flowchart TB
    subgraph users["ユーザー"]
        user1["Alice<br/>営業部"]
        user2["Bob<br/>開発部"]
        user3["Carol<br/>経理部"]
    end
    
    subgraph roles["役割（ロール）"]
        role1["営業担当者"]
        role2["開発者"]
        role3["経理担当者"]
        role4["管理者"]
    end
    
    subgraph permissions["権限"]
        perm1["顧客データ閲覧"]
        perm2["ソースコード編集"]
        perm3["経費申請承認"]
        perm4["システム設定変更"]
    end
    
    user1 --> role1
    user2 --> role2
    user2 --> role4
    user3 --> role3
    
    role1 --> perm1
    role2 --> perm2
    role3 --> perm3
    role4 --> perm4

RBACの階層モデル

NIST RBACモデルでは、以下の4つのレベルが定義されています。

Core RBAC（基本RBAC）

ユーザー、役割、権限、セッションの基本要素で構成されます。

Hierarchical RBAC（階層的RBAC）

役割間に継承関係を持たせ、上位役割が下位役割の権限を継承します。

flowchart TB
    subgraph hierarchy["役割の階層構造"]
        direction TB
        admin["システム管理者"]
        senior["シニア開発者"]
        junior["ジュニア開発者"]
        intern["インターン"]
    end
    
    admin --> senior
    senior --> junior
    junior --> intern
    
    note1["上位役割は下位役割の<br/>すべての権限を継承"]

SSD（Static Separation of Duty）

同一ユーザーに付与できない役割の組み合わせを定義します。例えば、「発注者」と「承認者」を同一人物に付与しないことで、不正を防止します。

DSD（Dynamic Separation of Duty）

同一セッション内で同時に有効化できない役割の組み合わせを定義します。

RBACの実装例

Microsoft Entra ID（旧Azure AD）でのRBAC設定例を示します。

組み込みロールの活用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
  "Name": "Virtual Machine Contributor",
  "Id": "9980e02c-c2be-4d73-94e8-173b1dc7cf3c",
  "IsCustom": false,
  "Description": "Lets you manage virtual machines, but not access to them, and not the virtual network or storage account they're connected to.",
  "Actions": [
    "Microsoft.Authorization/*/read",
    "Microsoft.Compute/virtualMachines/*",
    "Microsoft.Network/networkInterfaces/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ]
}

カスタムロールの作成

業務要件に合わせてカスタムロールを作成できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "Name": "Custom VM Operator",
  "Description": "Can start, restart, and stop virtual machines",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}/resourceGroups/{resource-group}"
  ]
}

RBACのメリットとデメリット

特に「役割の爆発」は深刻な問題です。部門、地域、プロジェクトなどの組み合わせごとに役割を作成すると、管理すべき役割が指数関数的に増加します。

flowchart TB
    subgraph explosion["役割の爆発問題"]
        direction TB
        dept["部門: 営業、開発、経理"]
        region["地域: 東京、大阪、名古屋"]
        level["レベル: 閲覧、編集、管理"]
        
        result["必要な役割数:<br/>3 × 3 × 3 = 27役割"]
    end
    
    dept --> result
    region --> result
    level --> result

ABACの仕組みと特徴

ABAC（Attribute-Based Access Control）は、主体（Subject）、リソース（Object）、アクション、環境の属性を評価し、動的にアクセス制御を行うモデルです。NIST SP 800-162で定義されており、RBACよりも柔軟で細かい制御が可能です。

ABACの基本構造

ABACでは、アクセス判定に以下の4種類の属性を使用します。

flowchart LR
    subgraph subject["主体属性"]
        s1["部門: 営業"]
        s2["役職: マネージャー"]
        s3["クリアランス: L2"]
    end
    
    subgraph object["リソース属性"]
        o1["種別: 顧客データ"]
        o2["機密度: 機密"]
        o3["所有部門: 営業"]
    end
    
    subgraph action["アクション"]
        a1["読み取り"]
    end
    
    subgraph env["環境属性"]
        e1["時刻: 9:00-18:00"]
        e2["場所: 社内"]
        e3["デバイス: 準拠"]
    end
    
    pdp["Policy Decision Point<br/>ポリシー評価エンジン"]
    
    subject --> pdp
    object --> pdp
    action --> pdp
    env --> pdp
    
    pdp --> |"許可/拒否"| result["アクセス判定結果"]

ABACポリシーの記述

ABACポリシーは通常、自然言語に近い形で記述できます。以下は代表的なポリシー記述方法です。

XACML（eXtensible Access Control Markup Language）

OASIS標準のポリシー言語です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<Policy PolicyId="CustomerDataPolicy"
        RuleCombiningAlgId="deny-unless-permit">
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="string-equal">
          <AttributeValue DataType="string">CustomerData</AttributeValue>
          <AttributeDesignator Category="resource"
                               AttributeId="resource-type"
                               DataType="string"/>
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  
  <Rule RuleId="AllowSalesDeptRead" Effect="Permit">
    <Description>営業部門は顧客データを閲覧可能</Description>
    <Condition>
      <Apply FunctionId="and">
        <Apply FunctionId="string-equal">
          <AttributeDesignator Category="subject"
                               AttributeId="department"
                               DataType="string"/>
          <AttributeValue DataType="string">Sales</AttributeValue>
        </Apply>
        <Apply FunctionId="string-equal">
          <AttributeDesignator Category="action"
                               AttributeId="action-id"
                               DataType="string"/>
          <AttributeValue DataType="string">read</AttributeValue>
        </Apply>
      </Apply>
    </Condition>
  </Rule>
</Policy>

自然言語に近いポリシー記述

多くのABACシステムでは、より読みやすい形式でポリシーを記述できます。

1
2
3
4
5

PERMIT read ON CustomerData
WHERE subject.department == "Sales"
  AND subject.clearance >= resource.classification
  AND environment.time BETWEEN "09:00" AND "18:00"
  AND environment.device.compliant == true

ABACアーキテクチャ

NIST SP 800-162では、ABACシステムの標準的なアーキテクチャが定義されています。

flowchart TB
    user["ユーザー"]
    pep["PEP<br/>Policy Enforcement Point<br/>ポリシー実施点"]
    pdp["PDP<br/>Policy Decision Point<br/>ポリシー決定点"]
    pip["PIP<br/>Policy Information Point<br/>ポリシー情報点"]
    pap["PAP<br/>Policy Administration Point<br/>ポリシー管理点"]
    resource["保護対象リソース"]
    
    user -->|"1. アクセス要求"| pep
    pep -->|"2. 認可要求"| pdp
    pdp -->|"3. 属性取得"| pip
    pip -->|"4. 属性情報"| pdp
    pap -->|"ポリシー配布"| pdp
    pdp -->|"5. 認可決定"| pep
    pep -->|"6. アクセス許可/拒否"| user
    pep -->|"許可時"| resource

ABACの実装例

AWS IAMでのABAC実装例を示します。

タグベースのアクセス制御

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}",
          "ec2:ResourceTag/Environment": "Development"
        },
        "ForAnyValue:StringEquals": {
          "aws:PrincipalTag/Role": ["Developer", "DevOps"]
        }
      }
    }
  ]
}

このポリシーでは、以下の条件を満たす場合にEC2インスタンスの起動・停止を許可します。

• ユーザーのDepartmentタグとリソースのDepartmentタグが一致
• リソースのEnvironmentタグがDevelopment
• ユーザーのRoleタグがDeveloperまたはDevOps

ABACのメリットとデメリット

RBACとABACの比較

RBACとABACはどちらか一方が優れているというわけではなく、それぞれに適した用途があります。

比較表

選択基準

以下のフローチャートを参考に、適切なモデルを選択してください。

flowchart TB
    start["アクセス制御モデルの選択"]
    q1{"動的な条件<br/>（時刻、場所など）<br/>が必要？"}
    q2{"役割の組み合わせが<br/>複雑？"}
    q3{"細かい<br/>リソースレベルの<br/>制御が必要？"}
    q4{"組織規模は<br/>大きい？"}
    
    rbac["RBAC"]
    abac["ABAC"]
    hybrid["ハイブリッド<br/>RBAC + ABAC"]
    
    start --> q1
    q1 -->|"はい"| abac
    q1 -->|"いいえ"| q2
    q2 -->|"はい"| hybrid
    q2 -->|"いいえ"| q3
    q3 -->|"はい"| abac
    q3 -->|"いいえ"| q4
    q4 -->|"はい"| hybrid
    q4 -->|"いいえ"| rbac

ハイブリッドアプローチ

実際の企業環境では、RBACとABACを組み合わせたハイブリッドアプローチが効果的です。

ハイブリッドモデルの構成

flowchart TB
    user["ユーザー"]
    
    subgraph rbac_layer["RBAC層：基本的な役割割り当て"]
        role1["開発者ロール"]
        role2["管理者ロール"]
    end
    
    subgraph abac_layer["ABAC層：動的な条件評価"]
        cond1["部門 = リソース所有部門？"]
        cond2["時間内？（9:00-18:00）"]
        cond3["デバイス準拠？"]
    end
    
    resource["保護対象リソース"]
    
    user --> rbac_layer
    rbac_layer --> abac_layer
    abac_layer -->|"すべての条件を満たす"| resource

実装例：Microsoft Entra Conditional Access

条件付きアクセスポリシーは、RBACとABACのハイブリッドアプローチの代表例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

ポリシー名：機密データアクセス制御

割り当て（RBAC的な要素）：
  - 対象ユーザー：財務部門メンバー
  - 対象アプリ：財務レポートシステム

条件（ABAC的な要素）：
  - デバイス：準拠デバイスのみ
  - 場所：指定されたIP範囲から
  - サインインリスク：中以下

アクセス制御：
  - 許可 + MFA必須

過剰権限のリスクと検出方法

最小権限の原則が守られていない状態、つまり過剰権限は深刻なセキュリティリスクをもたらします。

過剰権限の発生パターン

過剰権限がもたらすリスク

flowchart TB
    excess["過剰権限"]
    
    subgraph risks["リスク"]
        risk1["データ侵害の被害拡大"]
        risk2["内部不正の機会増加"]
        risk3["アカウント乗っ取り時の影響拡大"]
        risk4["コンプライアンス違反"]
        risk5["監査・追跡の困難化"]
    end
    
    subgraph impacts["影響"]
        impact1["機密情報の漏洩"]
        impact2["システム破壊"]
        impact3["規制当局からの処分"]
        impact4["信頼の失墜"]
    end
    
    excess --> risks
    risks --> impacts

過剰権限の検出方法

1. アクセスレビュー（Access Review）

定期的に権限の妥当性を確認するプロセスです。

flowchart LR
    start["アクセスレビュー開始"]
    notify["レビュアーに通知"]
    review["権限の確認"]
    decision{"権限は適切？"}
    keep["権限維持"]
    revoke["権限削除"]
    report["レポート作成"]
    
    start --> notify --> review --> decision
    decision -->|"はい"| keep
    decision -->|"いいえ"| revoke
    keep --> report
    revoke --> report

2. 未使用権限の分析

一定期間使用されていない権限を検出します。

1
2
3
4
5
6
7
8
9

検出クエリ例（概念的な表現）：

SELECT user_id, permission, last_used_date
FROM access_logs
WHERE permission NOT IN (
    SELECT DISTINCT permission 
    FROM user_activities 
    WHERE activity_date > DATEADD(day, -90, GETDATE())
)

3. 異常検知（UEBA）

User and Entity Behavior Analytics（UEBA）を活用し、通常と異なるアクセスパターンを検出します。

4. 権限スコアリング

各ユーザーの権限リスクをスコア化し、高リスクユーザーを優先的にレビューします。

1
2
3
4
5

リスクスコア = Σ(権限の機密度 × 未使用日数 × アクセス頻度係数)

例：
- 本番DB管理権限（機密度:10）× 180日未使用 × 0.5 = 900
- 開発環境閲覧権限（機密度:2）× 30日未使用 × 0.8 = 48

過剰権限への対策

Just-In-Time（JIT）アクセス

必要な時にのみ一時的に権限を付与し、タスク完了後に自動的に削除します。

sequenceDiagram
    participant User as ユーザー
    participant PIM as Privileged Identity<br/>Management
    participant Approver as 承認者
    participant Resource as リソース
    
    User->>PIM: 権限の有効化をリクエスト
    PIM->>Approver: 承認依頼
    Approver->>PIM: 承認
    PIM->>User: 一時的な権限を付与（例：4時間）
    User->>Resource: アクセス
    Note over PIM: 4時間後
    PIM->>User: 権限を自動削除

Standing Access Zero（常設権限ゼロ）

特権アクセスに対して常設の権限を持たせず、すべてJITで付与する方針です。

ゼロトラスト環境における権限設計のベストプラクティス

最後に、ゼロトラスト環境で最小権限を実現するためのベストプラクティスをまとめます。

権限設計の原則

実装チェックリスト

以下のチェックリストを使用して、最小権限の実装状況を確認してください。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[ ] すべてのユーザーに対してデフォルト拒否ポリシーが適用されている
[ ] 役割の定義が業務プロセスと整合している
[ ] 定期的なアクセスレビューのプロセスが確立されている
[ ] 特権アカウントにJITアクセスが適用されている
[ ] 未使用の権限を検出・削除する仕組みがある
[ ] 環境（本番/開発/テスト）ごとに権限が分離されている
[ ] 監査ログですべてのアクセスが記録されている
[ ] 職務分離が重要なプロセスに適用されている
[ ] 緊急アクセス手順（Break Glass）が定義されている
[ ] 権限変更の承認フローが確立されている

段階的な導入アプローチ

最小権限の実装は一度にすべてを行うのではなく、段階的に進めることをお勧めします。

flowchart LR
    phase1["フェーズ1<br/>可視化"]
    phase2["フェーズ2<br/>整理"]
    phase3["フェーズ3<br/>最適化"]
    phase4["フェーズ4<br/>自動化"]
    
    phase1 --> phase2 --> phase3 --> phase4
    
    p1["・現状の権限を棚卸し<br/>・過剰権限を特定<br/>・ベースラインを確立"]
    p2["・不要な権限を削除<br/>・役割を再定義<br/>・職務分離を適用"]
    p3["・ABACの導入検討<br/>・JITアクセス導入<br/>・アクセスレビュー自動化"]
    p4["・ポリシーの自動適用<br/>・異常検知の導入<br/>・継続的な改善"]
    
    phase1 --- p1
    phase2 --- p2
    phase3 --- p3
    phase4 --- p4

まとめ

本記事では、最小権限の原則とRBAC・ABACの使い分けについて解説しました。

最小権限の原則は、ゼロトラストセキュリティの基盤となる重要な概念です。権限の範囲、スコープの範囲、時間の範囲という3つの側面から、必要最小限のアクセス権のみを付与することで、攻撃面の最小化、内部脅威の軽減、コンプライアンス要件の充足を実現できます。

RBACは役割ベースのシンプルで管理しやすいモデルですが、役割の爆発や動的な条件への対応が課題となります。ABACは属性ベースの柔軟なモデルで細かい制御が可能ですが、ポリシー設計と運用が複雑になります。多くの場合、両者を組み合わせたハイブリッドアプローチが効果的です。

過剰権限のリスクに対しては、定期的なアクセスレビュー、未使用権限の分析、JITアクセスの導入などの対策を講じることが重要です。

次の記事では、特権アクセス管理（PAM）とJust-In-Time（JIT）アクセスについて、より詳しく解説します。

参考リンク

• NIST SP 800-207 Zero Trust Architecture
• NIST SP 800-162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations
• Microsoft Entra RBAC Best Practices
• AWS ABAC Documentation
• OASIS XACML Standard