# プロキシとエージェント ## 定義 プロキシとは、他者に代わって働くエージェントである。Burgess (2004) は、ネットワークにおけるプロキシの目的を2つに分類する。(1) キャッシュ型: 要求を集約しローカルに複製を保持することで、低速なネットワーク越しのトラフィックと遅延を削減する(WWWプロキシが典型例)。(2) ファイアウォール型: 危険な可能性のあるネットワーク接続を本来のホストが直接扱わず、プロキシが代行して仲介・遮断することで、ホストが攻撃に晒されるリスクを避ける。爆弾処理ロボットの比喩(「自分で危険を冒すより代理を送り込む方がよい」)で説明される(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 9 Application-level services]] §9.2)。 『The Real Internet Architecture』第3章はプロキシを、目的(キャッシュ・ファイアウォール)ではなく形式的なメカニズムとして定義する: プロキシとは2つの単純セッションを内部の結合テーブル(join table)でエンドツーエンドに結合し、以後両側のメッセージをヘッダ書き換えつつ中継するミドルボックスである(複合セッション、compound session)。NAT・相互運用プロキシ・Level 4/7ロードバランサはすべてこの単一の形式的メカニズムの実例である。(Source: [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.2.3) ## 横断的知見 - **Burgessの目的論的分類(キャッシュ型・ファイアウォール型)と、RIAの形式的メカニズム(結合テーブルによるセッション結合)は、互いに排他的でなく異なる抽象度で同じ「プロキシ」を語っている**: Burgess (2004) はプロキシを「何のために使うか」で分類し、キャッシュ型はトラフィック削減、ファイアウォール型は危険な接続の代行という目的を挙げる。RIA第3章は「プロキシは形式的に何をしているか」を問い、2つのセッションを結合テーブルで結合しヘッダを書き換えて中継するという単一のメカニズムに還元する。この2つを重ねると、Burgessのキャッシュ型プロキシ(WWWプロキシ)もファイアウォール型プロキシも、RIAの形式的メカニズムの上に成り立ちうる特殊化(キャッシュ型は結合したセッションの応答をローカルに保持する拡張、ファイアウォール型は結合の可否を判定する拡張)として理解できる。ただしRIA自身はこの一般化を明示的には論じておらず、これは両ページを突き合わせた本wikiの解釈である。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 9 Application-level services]] §9.2, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]] §3.2.3, §3.3.5.5) - **ネットワーク中心の目的論(Burgess)と、運用セキュリティ中心の目的論(BSRS第3章)は、「単一の仲介点にリスクを集約する」という同型の発想を異なるレイヤーへ適用している**: Burgess (2004) のファイアウォール型プロキシは、危険なネットワーク接続を本来のホストの代わりに引き受けることで、ホストが直接攻撃に晒されるリスクを避ける。[[Building Secure and Reliable Systems]] 第3章の「セーフプロキシ」は、この発想をネットワーク接続ではなく本番環境への管理操作(RPC・CLIコマンド)というレイヤーに拡張し、人間の誤操作・悪意ある操作のリスクを、単一のプロキシでの監査ログ・多者承認(MPA)・レート制限によって縮小する。両者とも「プロキシに処理を集約すればリスクの発生源を1点に絞り込め、そこに保護策を後付けできる」という同一の構造を持つが、RIA第3章が定義するような結合テーブルによるセッション結合というネットワーク層の形式的メカニズムは、BSRS第3章のセーフプロキシには存在しない(BSRSのプロキシはアプリケーション層のRPC呼び出しをACLとMPAで仲介するだけで、2つのセッションを1つに結合するわけではない)。したがって両者は目的論的には同型だが、形式的なメカニズムのレベルでは異なる抽象を扱っている。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 9 Application-level services]] §9.2, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 3 Case Study - Safe Proxies]] §Safe Proxies in Production Environments) ## 未解決の問い - BSRS第3章の「セーフプロキシ」は運用セキュリティ(最小権限・監査ログ・多者承認)の文脈でプロキシを論じており、この観点はBurgess (2004) やRIAのネットワーク中心の議論には無い。運用セキュリティ視点でのプロキシパターンの深掘りは [[セーフプロキシ]] ページに委ね、本ページはネットワーク層の一般的なプロキシ定義(キャッシュ型・ファイアウォール型・結合テーブル)に留める、という役割分担を今後も維持する。 - 本章はファイアウォール型プロキシの詳細を第12章(§12.12)に持ち越している。当該章がingestされた際に、ファイアウォール文脈での役割分担(パケットフィルタ vs アプリケーションレベルプロキシ)を本ページへ統合する必要がある。 - 「エージェント」という語は本書ではネットワーク上の代理人(プロキシ)を指すが、wiki内の他の多数の概念(LLMエージェント、マルチエージェント協調など)とは語義がまったく異なる同音概念である。両者を混同しないよう、本ページはネットワーク文脈のプロキシ/エージェントに限定して育てる。 - RIA第3章の複合セッション(結合テーブルによるセッション結合)という形式的定義は、Burgessのキャッシュ型・ファイアウォール型プロキシをどこまで厳密に包摂できるか。特にキャッシュ型プロキシは「結合したセッションの応答を保持し、後続の別セッションに再利用する」という、単純な2セッション結合を超える振る舞いを持つ。RIA第3章はこの拡張を明示的には扱っておらず、複合セッションの定義がキャッシュを形式的にどうモデル化するかは未解決である。 ## 関連 - 概念: [[サービス導入の一般手順]] / [[ブリッジング]](複合セッションの形式的定義) / [[セーフプロキシ]](運用セキュリティ文脈でのプロキシの特殊化) - source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 9 Application-level services]] / [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 3 Composing Networks and Services]](§3.2.3 複合セッション、§3.2.4 NAT、§3.2.5 相互運用プロキシ、§3.3.5.5 ロードバランサ) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 3 Case Study - Safe Proxies]] - 実体: [[Mark Burgess]] / [[wiki/entities/Principles of Network and System Administration|Principles of Network and System Administration]] - 関連章: [[@2004__Wiley__Principles of Network and System Administration - Chapter 12 Security implementation]](§12.12でファイアウォール型プロキシを再論の予定) ## 出典 - Mark Burgess, *Principles of Network and System Administration*, Second Edition, John Wiley & Sons, 2004, Chapter 9, §9.2. - Pamela Zave, Jennifer Rexford, *The Real Internet Architecture*, Princeton University Press, 2024, Chapter 3, §3.2.3, §3.2.4, §3.2.5, §3.3.5.5. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 3.