# ポリシー Navigation: [[index]] | [[concepts/_index]] ## 定義 Mark Burgess は『Principles of Network and System Administration』第2版第3章で、ポリシー(policy)を「できる限り形式化された、インフラのための青写真と、起こりうる事象に対する応答(コンティンジェンシー)の枠組みへ codify された、目標と願望の声明」と定義する(Definition 2)。ポリシーの役割は、環境からの制御不能な影響や、システム自身の構成要素の制御不足から生じかねない混沌に対して秩序を維持することにある。ポリシーが規定する要素は次の4つに分解される。 1. インフラの青写真(blueprint of infrastructure) 2. 生産目標(production targets、リソースの可用性) 3. 行動の制限(restriction of behavior、権限・アクセスの制限) 4. 刺激-応答チェックリスト(stimulus-response checklists、保守) ポリシーが定める状態は、静的で凍結された設定ではなく、動的な均衡(dynamical equilibrium)、すなわち釣り合いの取れた一点である。人間-計算機システムは決定論的ではないが、ポリシーの目的はその振る舞いの予測不能な部分を背景ノイズの水準まで制限することにある(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] §3.2)。 ポリシーが必要とされる根拠は、より広い「共同体(community)の原理」(Principle 5)に遡る。協力的な共同体では、ある成員の行動が他のすべての成員に影響し、その逆も成り立つ。この相互依存性を無視すると対立が生じるため、共同体はルール・法律・ポリシーを定めて安定を保とうとする。これらの違いは深刻さの程度の違いに過ぎず、いずれも根源的な正・不正が存在するから定められるのではなく、共同体の合意を要約する必要から定められる。社会的規則は (a) 判断を単純化する広く受け入れられた慣習の集合を提供し、(b) 共同体の意志を記録として文書化する、という2つの目的を持つ。この原理はマルチユーザーホストのユーザー共同体にも、世界規模のネットワーク共同体にも系(corollary)として適用される——ネットワークに接続された計算機はもはや自分だけのものではなく、リソースを共有し全体と通信する機械の社会の一部である(Source: 同上 §3.1)。 ## 横断的知見 - **同著者の2000年の理論論文([[@2000__LISA__Theoretical System Administration]])が前提として用いる「十分に完全なシステムポリシー(sufficiently complete system policy)」という言葉は、2004年の本書第3章が与える定義によって初めて内実を与えられる**: [[収束型システム管理]]が扱う中心定理(「十分に完全なシステムポリシーの仕様は理想平均状態の概念を導く」)は、2000年の論文単独では「ポリシー」を所与の一次概念として扱い、その中身を定義しない。本書第3章 Definition 2 は、ポリシーを「インフラの青写真」「生産目標」「行動の制限」「刺激-応答チェックリスト」の4要素からなる形式化された目標記述として定義し、かつポリシーが定める状態は「静的な凍結された設定ではなく動的な均衡」であると明示する。この「動的な均衡」という表現は、収束型システム管理が説明する「理想状態は時間とともにゆっくり劣化し、システム管理はその近傍にシステムを保ち続ける調整的な営みである」という主張と字面のレベルで一致しており、2004年の教科書が2000年の理論論文の数理的定式化に、事後的に概念的な基礎を与えていると読める。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] §3.2, [[@2000__LISA__Theoretical System Administration]]) - **第11章はポリシーを「セキュリティの水準を決める尺度」として再定義する**: 第3章(Definition 2)がポリシーを「インフラの青写真・生産目標・行動の制限・刺激-応答チェックリスト」からなる目標記述として定義したのに対し、第11章は Definition 8「セキュアなシステムとは、あらゆる脅威が分析され、すべてのリスクが評価されポリシーとして受容されたシステムである」で、**セキュリティそのものをポリシーの関数として定義**する。第3章の「行動の制限」要素(権限・アクセスの制限)が、第11章では「組織内外・同一ホスト内・サービス中断・ユーザー過失のどこまでを脅威とみなし、どこまでの利便性の犠牲を許容するか」という具体的な受容基準に肉付けされる。両章を合わせると、ポリシーは単に理想状態を記述するだけでなく、**その理想状態からの逸脱のうちどこまでを「許容されたリスク」とし、どこからを「セキュリティ侵害」と呼ぶかの境界線**を引く役割を担うことが分かる——この意味で、セキュリティはポリシーが定義する「動的な均衡」からの逸脱の可否判定装置である。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] §3.2 Definition 2, [[@2004__Wiley__Principles of Network and System Administration - Chapter 11 Principles of security]] §11.4 Definition 8) - **第7章§7.1は、第3章 Definition 2 の「インフラの青写真」要素を、組織・利用者・ネットワーク・メール・WWW・印刷・セキュリティ・プライバシーという8つの具体的な運用領域へ展開し、抽象的な定義に実務的な内実を与える**: 第3章の定義は「インフラの青写真・生産目標・行動の制限・刺激-応答チェックリスト」という4要素からなる形式的な骨格を示すにとどまり、それが具体的にどの業務領域をカバーすべきかには立ち入らない。第7章§7.1は同じ「システム設定ポリシー」を扱いながら、各領域で決めるべき事項を列挙する——利用者領域では「ソフトウェア利用の許可・禁止」「ディスククォータか自由放任か」「ガベージコレクションの基準」、ネットワーク領域では「セグメンテーション」「ファイアウォールの要否」、セキュリティ領域では「パスワードの有効期限」のように、Definition 2 の「行動の制限」「刺激-応答チェックリスト」という抽象的な要素それぞれに具体的な決定項目を当てはめる。両章を合わせると、ポリシーは単一の定義文だけでなく、組織が実際に決定すべき事項のチェックリストとして機能することが分かる。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] §3.2 Definition 2, [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.1) - **第7章§7.5は、ポリシーによる codify(明文化)が持つ両義性——効率化と「愚鈍化(dumbing down)」のトレードオフ——を論じ、第3章が述べる「共同体の合意の要約」という肯定的な機能に、否定的な副作用を対置する**: 第3章は、ポリシー・ルール・法律がいずれも「根源的な正・不正が存在するから定められるのではなく、共同体の合意を要約する必要から定められる」と述べ、判断の単純化と意志の記録という2つの肯定的機能を挙げる(既出の定義)。第7章§7.5はこれと同じ「知恵をポリシーへ codify する」過程を扱いながら、その代償を指摘する——標準化されたメソッドへ制御を委譲することは、それを使う人間から詳細な理解を奪う「愚鈍化」であり、この過程が長く続くと、系を診断・運用できる専門知識そのものが失われ、「できる者」と「できない者」への分極化を招きうる。それでもなお、いったん十分に成熟したアルゴリズムをポリシーとして固定化することは、疑う必要のない事柄を都度再考する手間を省くという点で正当化される。第3章が「ポリシーはなぜ必要か」という肯定的な根拠を与えたのに対し、第7章はその同じ codify という行為が孕む倫理的なコストを対置しており、両者を合わせて初めてポリシーの明文化が持つ功罪の全体像が見える。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] §3.1, [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.5) - **第12章§12.10は、これまでの各章が扱わなかった軸——単一のポリシーの中の規則順序ではなく、複数の権威が独立に発したポリシーどうしが現場で衝突したときに何が起きるか——を導入する**: 第3章はポリシーを「共同体の合意を要約する目標記述」として定義し、第6章はその同じポリシーが単一の中央から星型・メッシュ型・階層型のネットワークをどう伝播するかを類型化した(いずれも「1つのポリシーがどう成立し、どう広がるか」という視点)。第12章§12.10はこれらと異なり、「2つ以上の独立したポリシーが同時に存在する」場合を扱う。Principle 65「競合しうる規則が存在する状況では、結果は規則の評価順序に敏感である」を、IPSecのトンネル構成の3つの実例で具体化する——ある構成では、H1が定めた暗号化トンネル規則と、別の管理者がFW1に定めたファイアウォール規則が独立に存在するために、正当なトラフィックまで誤って遮断される(Example 20・21)。別の構成では、2つの部門の管理者がそれぞれ独立にゲートウェイ間トンネルを設定した結果、経路の一部が重なり合う区間で意図せず暗号化が外れる(Example 22)。いずれの失敗も、単一の管理者が規則の順序を間違えたのではなく、**互いを知らない複数の権威が、それぞれは正しいポリシーを独立に発行し、それらが現場で組み合わさって初めて矛盾が顕在化する**という点で共通する。これは第3章の「共同体の合意」というポリシー観に、「合意が単一の共同体の内部で閉じている保証はない」という限界を突きつける——複数の共同体(部門・組織)がそれぞれ合意したポリシーどうしの整合性は、個々のポリシーの正しさからは自動的に導かれない。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] §3.1, [[@2004__Wiley__Principles of Network and System Administration - Chapter 12 Security implementation]] §12.10 Principle 65, Example 20-22) - **Anderson の『Security Engineering』第1章は、Burgess の Definition 8(「セキュアなシステムとはあらゆる脅威が分析されすべてのリスクが評価されポリシーとして受容されたシステムである」)と同じ「セキュリティ=ポリシーの関数」という定式化に、独立に到達しているが、Anderson はさらにポリシーと実装の間に2つの中間層を挿入する**: Burgess(第11章§11.4)は、セキュリティをポリシーが受容したリスクとして定義するにとどまり、ポリシーがどう特定の製品・システムへ具体化されるかには立ち入らない。Anderson(第1章§1.7)は、Burgess とほぼ同じ内容の**セキュリティポリシー**(システムの防護戦略の簡潔な声明、例:「各取引で貸方と借方の合計が一致し、100万ドルを超える取引は2名の管理者の承認を要する」)を独立に定義した上で、その下に**セキュリティターゲット**(ポリシーを特定製品でどう実装するかを詳細に定めた評価基準)と**プロテクションプロファイル**(セキュリティターゲットに似るが機器非依存で書かれ製品間の比較評価を可能にするもの)という2つの中間仕様層を置く。両者を合わせると、「セキュリティ=ポリシーが受容したリスク」という定義そのものは異なる著者・異なる文脈(システム管理論とセキュリティ工学)で独立に収束する頑健な定式化だと分かる一方、Burgess の枠組みには Anderson が導入するポリシーから実装への段階的な具体化(ポリシー→プロテクションプロファイル→セキュリティターゲット)に相当する層が欠けている。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 11 Principles of security]] §11.4 Definition 8, [[@2020__Wiley__Security Engineering 3e - Chapter 1 What Is Security Engineering?]] ch.1 §1.7) ## 未解決の問い - 「共同体の原理」(Principle 5)から「ポリシー」(Definition 2)への導出は、本書第3章内では規範的な主張として提示されるにとどまり、経験的な裏付け(ポリシーの欠如が実際に対立や不安定化を招いた事例)は本章には無い。他章・他ソースでの実証は確認できるか。 - Anderson のセキュリティターゲット・プロテクションプロファイルという中間仕様層は、Common Criteria のような評価制度に由来する概念である可能性が高い。Burgess の枠組み(システム管理論)がこの層を持たないのは、対象読者・目的の違い(評価制度を前提としない運用論)によるものか、単に本書が扱わなかっただけかは、他ソースで確認できるか。 - 第12章§12.10は、複数の権威が独立に定めたポリシーが実装レベル(IPSecのトンネル規則)でどう衝突するかを示したが、この衝突を事前に検出・防止する体系的な手段(ポリシーどうしの整合性検証)は本章には無い。単一組織内でのポリシー統合手順は、他ソースで確認できるか。 ## 関連 - 概念: [[収束型システム管理]] / [[信頼関係]] - 実体: [[Mark Burgess]] - ソース: [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 11 Principles of security]] / [[@2004__Wiley__Principles of Network and System Administration - Chapter 12 Security implementation]] / [[@2000__LISA__Theoretical System Administration]] / [[@2020__Wiley__Security Engineering 3e - Chapter 1 What Is Security Engineering?]](§1.7) - 既存資産(一方向参照): `structures/SRE - MOC.md` ## 出典 - Mark Burgess, *Principles of Network and System Administration*, Second Edition, John Wiley & Sons, 2004, Chapter 3, §3.1–3.2; Chapter 7, §7.1, §7.5; Chapter 11, §11.4; Chapter 12, §12.10. - [[@2000__LISA__Theoretical System Administration]](Mark Burgess, USENIX LISA 2000) - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 1, §1.7.