アクセス制御モデル

認可（Authorization）は「認証されたユーザーが何にアクセスできるか」を決定するプロセスであり、認証（Authentication）の次のステップとなる。ゼロトラストアーキテクチャにおいては、認証が通っても「最小権限」の原則のもとで必要最小限のリソースにしかアクセスできないよう、きめ細かい認可制御が必要となる。本記事は RBAC・ABAC・ReBAC という主要な認可モデル、Google Zanzibar・OpenFGA、特権アクセス管理（PAM）と JIT アクセス、標準化動向（AuthZEN 1.0）を俯瞰し、モデル選択の指針と落とし穴を整理する。

認可の枠組み：PDP / PEP / PIP / PAP

認可システムは次の四つのコンポーネントで構成される（XACML の概念モデル）。

この分離により、ポリシーロジック（PDP）とポリシー適用（PEP）が分かれ、柔軟な認可システムを構築できる。

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

RBAC（Role-Based Access Control） は最も広く普及した認可モデルであり、ユーザーをロール（役割）に割り当て、ロールにパーミッションを付与する。

特徴

• シンプルさ: 「管理者ロールは全リソースにアクセス可」のように直感的に理解・設定できる。
• 監査容易性: ロール一覧とパーミッション一覧が明確なため、誰が何にアクセスできるかを追跡しやすい。
• 広い採用: AWS IAM ロール・Kubernetes RBAC・Entra ID ロール・GitHub リポジトリ権限など、プラットフォームを横断して標準的に使われる。

役割爆発（Role Explosion）の問題

RBAC の最大の課題は、組織が成長するにつれてロールが増殖することである。部門・プロジェクト・権限レベルの組み合わせが増えると、数百〜数千のロールが生まれ、管理不能になる。「このユーザーのアクセスは本当に必要か」を定期的にレビューする Access Review プロセスが必要となる。

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

ABAC（Attribute-Based Access Control） は、主体（ユーザー）・リソース・環境の属性に基づいてアクセスを制御するモデルである。

属性の種類

• 主体属性: ユーザーの部署・職種・セキュリティクリアランス・在籍期間
• リソース属性: データの機密分類（Public / Confidential / Secret）・作成者・プロジェクト
• 環境属性: アクセス時刻・場所（IP アドレス・国）・デバイス posture

ポリシー例

「ドキュメントが classification=confidential かつ アクセス者が department=legal かつ location=Japan であればアクセス許可」のように、複合条件でアクセスを制御できる。

実装例

• XACML（eXtensible Access Control Markup Language）: OASIS 標準の XML ベースポリシー言語。エンタープライズ環境での実績があるが複雑性が高い。
• OPA（Open Policy Agent） + Rego: CNCF Graduated プロジェクト。汎用ポリシーエンジンとして Kubernetes・API Gateway・マイクロサービスで採用が広がる。
• クラウドネイティブ実装: AWS IAM Condition（リソース属性・タグ・時刻条件）、Google Cloud IAM Conditions、Microsoft Entra ID Conditional Access が ABAC 的なポリシーを実装している。

注意点

ABAC は柔軟性が高い反面、ポリシーが複雑化すると「どのポリシーが適用されるか」のデバッグが困難になる（ポリシー肥大問題）。ポリシーのテスト・ドキュメント化が重要である。

ReBAC（関係ベースアクセス制御）

ReBAC（Relationship-Based Access Control） は、ユーザーとリソースの間の「関係」に基づいてアクセスを制御するモデルである。Google が内部システム向けに開発した Google Zanzibar が最も有名な実装であり、Google Drive・Google Calendar・Google Photos・YouTube の権限管理に使われている。

Google Zanzibar の概念

Zanzibar は object # relation @ user というタプル（組）でアクセス権を表現する。

document:readme#viewer@user:alice        # alice は readme を閲覧できる
folder:projects#viewer@user:alice        # alice は projects フォルダを閲覧できる
document:readme#parent@folder:projects  # readme は projects フォルダ配下

「alice が readme を閲覧できるか」というチェックは、これらのタプルを再帰的にたどることで回答する。フォルダの閲覧権限を継承する、共有リンクによるアクセス、グループメンバーシップ経由のアクセスなど、複雑な権限関係を直感的に表現できる。

OpenFGA — Zanzibar の OSS 実装

OpenFGA（Open Fine-Grained Authorization）は Auth0/Okta が開発した Zanzibar 系 OSS であり、CNCF Incubating プロジェクト（2025 年 10 月） に認定された。v1.13 は 2026 年 3 月にリリースされた（情報カットオフ ~2025-08 以降は要確認）。

OpenFGA は認可ロジックをアプリケーションコードから分離し、独立したサービスとして運用できる。RBAC・ABAC・ReBAC のいずれもモデリング可能であり、「ReBAC は RBAC の上位集合であり ABAC も表現可能」とされる。

ReBAC が有効なシナリオ

• ドキュメント共有: Google Drive のように、ドキュメントをフォルダ階層や共有リンクで権限管理する場合
• コラボレーションツール: Notion・Figma・GitHub のように、チーム・プロジェクト・リポジトリという関係でアクセスを制御する場合
• マルチテナント SaaS: テナント → プロジェクト → リソースという階層的な権限継承が必要な場合

特権アクセス管理（PAM）

PAM（Privileged Access Management） は、管理者権限・特権アカウントへのアクセスを厳格に管理するプラクティスとツールセットである。特権アカウントはシステム全体へのアクセスを持つため、攻撃者にとって最も価値が高い標的となる。

PAM の主要機能

1. 特権アカウント保管庫（Vault）: 特権パスワード・秘密鍵を暗号化して一元保管する。ユーザーはパスワードを直接知らずに、保管庫経由で取得・使用する。CyberArk・HashiCorp Vault・Delinea（旧 Centrify / Thycotic）が代表的製品。
2. セッション記録: 特権セッション（SSH・RDP・データベース接続）をリアルタイムまたは後から再生可能な形で記録する。コンプライアンス要件（SOC 2・PCI DSS）の監査証跡にもなる。
3. パスワード自動ローテーション: 特権パスワードを定期的に自動変更し、長期利用による漏洩リスクを軽減する。

恒久特権の排除

「管理者ロールを常時持つ」恒久特権（Standing Privilege）はゼロトラスト原則と相容れない。アカウントが侵害されると即座に全権限を奪われるためである。PAM と JIT アクセスの組み合わせで恒久特権を排除することが推奨される。

JIT アクセス（Just-in-Time Access）

JIT（Just-in-Time）アクセスは、必要な時間帯・作業範囲にのみ一時的に権限を昇格させるアプローチであり、最小権限の原則の実践的実装形態である。

仕組み

1. ユーザーが「○○の作業のために管理者権限が必要」と申請する
2. 承認フロー（マネージャー・セキュリティチーム）が判断する
3. 承認されると、指定された時間（例: 4 時間）だけ権限が付与される
4. 時間経過で権限が自動失効する

Microsoft Entra PIM（Privileged Identity Management）

Microsoft Entra ID に組み込まれた JIT ソリューション。Entra ID のロール（グローバル管理者・User Access Administrator 等）を「有資格（Eligible）」として登録し、使用時だけアクティベートする。アクティベーションには MFA・承認・業務理由の入力を要求でき、すべての操作が監査ログに記録される。

JIT 承認の形骸化に注意

JIT を導入しても「いつも承認される」「形式的な理由で通過する」場合、実質的な恒久特権と変わらない。承認者が意図をもってレビューし、必要以上の期間・スコープの申請を却下するプロセス設計が重要である。

AuthZEN — 認可 API の標準化

OpenID AuthZEN Authorization API 1.0 が 2026 年 1 月に Final Specification として公開された。PDP と PEP の間の標準 API を定義し、認可エンジン（OPA・OpenFGA・Axiomatics 等）と認証レイヤー（OIDC）の間の相互運用性を高める。AuthZEN により、認可エンジンを入れ替えてもアプリ側の変更が不要になる。

モデル選択の指針

よくある落とし穴（Anti-Pattern）