アクセス制御の本質 — 4つの基本概念

ソフトウェアシステムにおいてアクセス制御（Access Control）とは、「誰が、何に、どんな操作をする権限を持つか」を定義・強制するメカニズムの総称です。 1960年代のタイムシェアリングシステムから現代のクラウドネイティブ、AIエージェントまで、この問いへの答え方こそがシステムセキュリティの根幹を形作ってきました。

NIST Interagency Report 7316（2006年）は、アクセス制御の4つの中核概念を以下のように定義しています。

概念英語定義例
サブジェクトSubjectシステムリソースへのアクセスを開始する能動的エンティティユーザー、プロセス、サービスアカウント、AIエージェント
オブジェクトObjectアクセスを受ける受動的エンティティ（保護対象リソース）ファイル、データベース行、APIエンドポイント、S3バケット
オペレーションOperationサブジェクトがオブジェクトに対して実行できる処理の種類read / write / execute / delete / admin
パーミッションPermission特定のオブジェクトに対する特定のオペレーションを許可する権限file.txt に対する read 権限

この4概念の組み合わせが、アクセス制御ポリシーの最小単位となります。 「ユーザーAliceが（Subject）、ファイルsecret.txtに対して（Object）、読み取りを（Operation）許可する（Permission）」というように表現されます。

能動的エンティティ vs 受動的エンティティ

SubjectとObjectの区別は、一見単純ですが実装上は複雑さを孕みます。 あるプロセスはデータベースに対してはSubjectですが、別のプロセスからはObjectとして参照されることがあります。 クラウドではEC2インスタンスもIAMロールを通じてSubjectとなり、S3バケットはObjectとして振る舞います。 AIエージェントが他のエージェントを呼び出す構成では、呼び出し側がSubject、呼ばれる側がObjectという多段構造が生まれます。

認証（Authentication）と認可（Authorization）の明確な区別

アクセス制御を理解する上で最も重要な概念の分離が、認証（AuthN）と認可（AuthZ）の違いです。 この2つは実装上しばしば混在しますが、本質的に異なる問いに答えています。

概念問い手段失敗した場合
認証 Authentication「あなたは誰ですか？」アイデンティティの確認パスワード、MFA、証明書、生体認証、OAuthトークンHTTP 401 Unauthorized（実際には未認証）
認可 Authorization「あなたはそれをしてもよいですか？」権限の確認ACL、RBAC、ABAC、ReBAC、ポリシーエンジンHTTP 403 Forbidden（認証済みだが権限なし）

「ログインできたからアクセスできる」という混同が、水平権限昇格（BOLA/IDORと呼ばれる脆弱性）の根本原因となります。 認証は「本人確認の扉」であり、認可は「各部屋の鍵」です。扉を通過しただけでは、全ての部屋に入れるわけではありません。

参照モニタ（Reference Monitor）の誕生 — 1972年

現代のアクセス制御アーキテクチャのすべては、1972年に発表された一つの報告書にさかのぼります。 米国防総省の委託でJames P. Andersonが著した「Computer Security Technology Planning Study」（通称Anderson Report）です。

Andersonは、安全なコンピュータシステムには参照モニタ（Reference Monitor）と呼ばれる概念的コンポーネントが必要だと主張しました。 参照モニタとは、「あらゆるSubjectによるObjectへのアクセスを常に仲介し、認可されたアクセスのみを許可する抽象概念」です。

TCB（Trusted Computing Base）との関係

参照モニタの概念から生まれたのがTCB（Trusted Computing Base：信頼されたコンピューティング基盤）です。 TCBとは、セキュリティポリシーを正しく施行する責任を持つ、ハードウェア・ファームウェア・ソフトウェアの集合です。 1983年の米国防総省のOrange Book（TCSEC）がこの概念を公式化しました。

TCBの核心的な設計原則は「小さくあること」です。 検証可能性（Verifiable）の条件を満たすには、TCBが十分に小さく単純でなければなりません。 これは現代のゼロトラストアーキテクチャで「Policy Decision Point（PDP）は単一責任を持つ専用コンポーネントとして実装せよ」という設計思想に直結します。

PEP/PDPアーキテクチャへの継承

Andersonの参照モニタは、2000年代にXACMLが標準化する過程でPEP（Policy Enforcement Point）とPDP（Policy Decision Point）という2つのコンポーネントに具体化されました。

graph LR
  S[Subject] -->|アクセス要求| PEP[PEP\nPolicy Enforcement Point]
  PEP -->|認可クエリ| PDP[PDP\nPolicy Decision Point]
  PDP -->|Permit / Deny| PEP
  PDP --- PAP[PAP\nPolicy Administration Point]
  PDP --- PIP[PIP\nPolicy Information Point]
  PEP -->|許可された場合| OBJ[Object]

  style S fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style PEP fill:#f97316,stroke:#ea580c,color:#fff
  style PDP fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style PAP fill:#64748b,stroke:#475569,color:#fff
  style PIP fill:#64748b,stroke:#475569,color:#fff
  style OBJ fill:#10b981,stroke:#059669,color:#fff
参照モニタ概念のPEP/PDPアーキテクチャへの具体化。PEP（境界での強制）とPDP（ポリシーに基づく決定）の分離が、Anderson 1972年の「Always Invoked」と「Verifiable」の条件を満たす現代的実装となる

PEPは「Always Invoked（常時起動）」と「Tamper-proof（改ざん耐性）」を担い、 PDPは「Verifiable（検証可能性）」のために単純でテスト可能な設計が求められます。 OPA（Open Policy Agent）、Zanzibar、Cedarといった現代の認可システムはすべて、このPEP/PDP分離パターンを実装しています。

歴史的年表 — 1965年から2026年まで

アクセス制御の60年の歴史は、「どのようにSubject・Object・Permissionの関係を表現・管理するか」という問いへの解答が進化してきた歴史です。 各時代のモデルは、前の時代の限界を補う形で生まれています。

timeline
  title アクセス制御モデルの進化年表
  1965 : Multics - ACLの原型
  1971 : Lampsonアクセス行列論文
  1972 : Anderson報告書 - 参照モニタ
  1973 : Bell-LaPadulaモデル - MAC機密性
  1977 : Bibaモデル - 完全性
  1983 : Orange Book - DAC/MAC公式定義
  1987 : Clark-Wilsonモデル
  1992 : RBAC - Ferraiolo & Kuhn
  2004 : ANSI/INCITS 359 RBAC標準
  2014 : NIST SP 800-162 ABAC
  2019 : Google Zanzibar - ReBAC
  2020 : NIST SP 800-207 ZTA
  2025 : MCP + Cedar AIエージェント認可
アクセス制御モデルの主要マイルストーン。DAC（任意アクセス制御）→ MAC（強制アクセス制御）→ RBAC（ロールベース）→ ABAC（属性ベース）→ ReBAC（関係ベース）→ ZTA（ゼロトラスト）→ AI時代の認可へと進化

各マイルストーンの詳細

年表の各点が解決しようとした課題と、残した限界を順に見ていきます。

1965年: Multics — ACLの原型

MIT、ベル研究所、GEが共同開発したMultics（Multiplexed Information and Computing Service）が、 ファイルごとにユーザーとパーミッションを指定するAccess Control List（ACL）の概念を初めて実装しました。 「誰が何を読み書きできるか」をファイルに付属した名簿として管理するこのアプローチは、現代のUNIXパーミッション、NTFS ACL、クラウドIAMポリシーへと直接受け継がれています。

1971年: Butler Lampson「Protection」論文 — アクセス行列

Butler Lampsonが発表した論文「Protection」は、アクセス制御の理論的基盤となるアクセス行列モデル（Access Matrix Model）を定式化しました。 行がSubject（ドメイン）、列がObject、セルが許可されたOperationの集合を表す二次元行列として、システムの全アクセス権を統一的に表現する方法を提示しました。 ACLは「列を見た実装」、Capabilityリストは「行を見た実装」として、このモデルから派生します（第2章で詳述）。

1972年: Anderson報告書 — 参照モニタ

前節で詳述したAnderson報告書。理論ではなく「どう実装すれば安全が保証されるか」という設計原則を初めて体系化した点が歴史的意義を持ちます。

1973年: Bell-LaPadulaモデル — MACと機密性の形式化

米国防総省の委託でDavid Elliott BellとLeonard J. LaPadulaが開発したBell-LaPadula（BLP）モデルは、機密情報の漏洩防止を形式的に保証する最初のアクセス制御モデルです。 「No Read Up（低いクリアランスのSubjectは高いクラスのObjectを読めない）」と「No Write Down（高いクリアランスのSubjectは低いクラスのObjectに書けない）」という2つの単純なルールで、情報の上位への漏洩を数学的に防止します。 軍・政府システムで標準モデルとなり、後の強制アクセス制御（MAC）概念の基礎となりました。

1975〜77年: Bibaモデル — 完全性の形式化

Kenneth J. BibaがBLPの「完全性版」として開発。BLPが機密性（Confidentiality）を保護するのに対し、 Bibaモデルはデータの完全性（Integrity）を保護します。 「No Read Down（高い完全性レベルのSubjectは低いレベルのObjectを読めない）」と「No Write Up（低い完全性のSubjectは高いレベルのObjectに書けない）」という双対ルールを持ちます。 金融システムや医療記録など、データの正確性が最重要なドメインで参照されます。

1983〜85年: Orange Book（TCSEC）— DAC/MACの公式定義

米国国防総省が発行した「Trusted Computer System Evaluation Criteria（TCSEC）」、通称Orange Bookが、DAC（Discretionary Access Control：任意アクセス制御）とMAC（Mandatory Access Control：強制アクセス制御）を公式に定義しました。 D（最低保証）からA1（最高保証）まで7段階の評価クラスを規定し、商業・政府システムのセキュリティ評価の標準となりました。 DACとMACの区別は今なお認可設計の基本語彙として生きています。

1992年: RBAC — 現実のビジネスロジックへの対応

NISTのDavid FerraioloとRick Kuhnが提案したRBAC（Role-Based Access Control）は、 権限を「ユーザー → ロール → パーミッション」という二段階構造で管理します。 ユーザーに直接権限を付与するのではなく、職務上の役割（ロール）に権限を割り当て、ユーザーをロールに割り当てることで、 人事異動や組織変更に伴う権限管理を大幅に簡素化しました。 2004年のANSI/INCITS 359標準化を経て、現代の企業システムにおける事実上のデフォルト認可モデルとなりました（第4章で詳述）。

2014年〜現在: ABAC・ReBAC・ZTA・AI認可

NIST SP 800-162（2014）が定義したABAC（Attribute-Based Access Control）はSubject・Object・Environment属性を組み合わせた動的ポリシーで、 RBACの「ロール爆発」問題を解決します。 2019年のGoogle Zanzibar論文は、Googleが10億ユーザー規模で運用するReBAC（Relationship-Based AC）を公開し、 OpenFGAなどのOSSへと発展しました。 NIST SP 800-207（2020）のZero Trust Architectureは「境界によるセキュリティの終焉」を宣言し、 全アクセスを継続的に検証するモデルを提示しました。 そして2025〜26年には、MCPプロトコルやCedar言語がAIエージェントの非人間アイデンティティ認可という新しいフロンティアに挑んでいます。

なぜアクセス制御は難しいのか

60年以上の研究と実装の歴史があるにもかかわらず、OWASPはアクセス制御の欠陥（Broken Access Control）を「OWASP Top 10 2021」の第1位（A01:2021）に選定しています。 これはWebアプリケーションの実世界でのセキュリティ侵害の94%がアクセス制御に関係する問題を含むという調査に基づきます。 なぜ、これほど根深い問題であり続けるのでしょうか。

セキュリティとユーザビリティのトレードオフ

完璧なアクセス制御を追求すると、ユーザーは必要なリソースへのアクセスを制限されすぎて業務が止まります。 逆に使いやすさを優先すると、権限が緩くなりセキュリティが低下します。 このトレードオフは技術的な問題ではなく、組織のリスク許容度・ビジネス要件・ユーザー行動という社会的問題と深く絡み合います。 セキュリティチームが厳格なポリシーを設定しても、開発者が「とりあえず全権限」のサービスアカウントを使い回す文化があれば無意味です。

スケーリング問題 — 数百万ユーザー × 数十億リソース

初期段階では10人のユーザーと100個のファイルを管理するACLで十分でも、 ユーザーが100万人、リソースが10億個になったとき、全組合せのアクセス権を管理・評価するコストは現実的ではありません。 Googleが2019年のZanzibar論文で公開したデータでは、1秒あたり100万回以上の認可チェックを1ms未満で処理する必要があると記されています。 スケールを実現しながらも正確な権限制御を維持することは、分散システム設計の難問の一つです。

動的な組織変化への対応

組織は常に変化します。人が入社・退職・異動し、プロジェクトが始まり・終わり、合併・買収が起きます。 アクセス権は組織構造の写像であるため、組織の変化に追従できないアクセス権管理は 「退職者が半年後もシステムにアクセスできる」「前プロジェクトの権限が削除されず蓄積する（Permission Creep）」という問題を生みます。 この問題を自動化・ライフサイクル管理で解決しようとしているのが、現代のIGA（Identity Governance and Administration）製品です。

複雑性の本質的な難しさ

Harrison-Ruzzo-Ullman（HRU）問題（1976年）は、「任意のアクセス制御システムにおいて、特定の権限が取得できるかを判定する問題は決定不可能である」と証明しました。 これはアクセス制御の安全性分析が原理的に計算不可能なケースがあることを示します。 完全な安全性を数学的に証明できないため、実際のシステムは「実用的な制約のもとでの近似」として設計せざるを得ません。 この理論的限界と実践的解決策の間の緊張こそが、アクセス制御研究・実装の醍醐味です（第2章で詳述）。

本シリーズの全体像

本シリーズ「アクセス制御モデルの設計」では、基礎理論から現代的実装まで10章で体系的に学びます。 第1章（本章）で歴史と基礎概念を押さえ、第2章で理論的基盤を固め、第3〜6章で主要モデルを深掘りし、 第7〜8章で現代的実装パターンを学び、第9章でセキュリティ検証、第10章でAI時代の展望を見渡します。

理解度チェック

問題 0 / 40%
Q1

アクセス制御の4つの基本概念（NISTIR 7316の定義）として正しい組み合わせはどれですか？

キーボード: 1〜4 で選択、Enter で回答