セキュリティ設計原則 - yuuk1's Digital Garden

# セキュリティ設計原則 ## 定義セキュリティ設計原則とは、Jerome H. Saltzer と Michael D. Schroeder が1975年の論文 "The Protection of Information in Computer Systems" で定式化し、*Principles of Computer System Design* 第11章がそのまま引き継いで提示する、情報セキュリティの設計を導く7つの原則群である。本章はこれらを「セキュリティは負の目標である」という前提(§11.1.2、達成の証明ではなく未達成の証明が困難という非対称性)への対処として位置づけ、第8章(Part I、本wiki未取り込み)由来の**セーフティネット手法**(be explicit・design for iteration)と並置して提示する。原則は以下の7つである(訳語は [[Principles of Computer System Design]] の「設計原則の一覧」節に統一)。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.3, §11.1.4) 1. **Open design principle**(オープンデザインの原則) — 「誰にでも設計に意見させよ。助けはいくらあっても足りない。」機構をアルゴリズムの秘匿(クローズド設計)ではなく鍵の秘匿(オープン設計)に依存させる。WiFi WEP標準は、審査参加に高額な会費が必要だったために事実上クローズドな審査になり、脆弱性が量産された反例として挙げられる。 2. **Minimize secrets**(秘密を最小化せよ) — 「秘密はおそらく長くは秘密でいられない。」秘密が漏洩した際の被害を抑えるため、秘密の範囲を鍵に集約し交換可能にする。 3. **Complete mediation**(完全な仲介) — 「すべての操作について真正性・完全性・認可を検査せよ。」初期化・復旧・シャットダウン・保守を含む全アクセス経路を検査対象とする。認可チェック結果のキャッシュは権限変更時の更新が必要になるため懐疑的に扱うべきだとされる。 4. **Economy of mechanism**(機構の経済性) — 「機構が少ないほど、正しく作れる見込みが高い。」全アクセス経路(通常運用で行使されない経路も含む)を1行ずつ検査するには小さく単純な設計が要る。 5. **Minimize common mechanism**(共通機構の最小化) — 「共有された機構は望まぬ通信路を提供する。」カーネル手続きより各利用者固有のライブラリ手続きを選ぶ例が挙げられ、本章はこれを**エンドツーエンド論**の一種だと明記する。 6. **Fail-safe defaults**(フェイルセーフなデフォルト) — 「ほとんどの利用者はデフォルトを変えないのだから、安全側に倒しておけ。」デフォルトはアクセス不可とし許可を明示列挙するほうが、明示的に排除する設計より失敗モードが安全側になる(前者は誤って拒否に倒れて早期発見されやすく、後者は誤って許可に倒れて見過ごされやすい)。 7. **Least privilege principle**(最小権限の原則) — 「宝石を入れた金庫に弁当を入れるな。」特権プログラムや管理者は必要な操作の間だけ特権を持ち、通常の活動では特権を放棄する。監査対象コードを減らす効果もある。これらに加え、認可の使い勝手に関わる**Principle of least astonishment**(最小驚愕の原則)が仲介の文脈で論じられる。認可の仕組みは利用者の直観的な心的モデルに一致するよう透明であるべきで、そうでなければ利用者は不適切なデフォルト設定のまま使い続け、または機構自体を回避してしまう。通俗的な合成定式化として「攻撃対象領域(attack surface)を最小化せよ」も言及され、機構の経済性・秘密の最小化・最小権限・共通機構の最小化の組み合わせとして説明される。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4) ## 横断的知見 - 『ネットワークシステムについて語るときに我々の語ること』第8章は、これらの原則を Saltzer and Schroeder (1975) の二次的な引用として紹介し、最小権限の原則・オープンデザイン・フェイルセーフなデフォルトの3つに絞って言及している。一次情報である本章(Saltzer 自身が共著)を突き合わせると、二次情報の要約は正確だが、本章はさらに完全な仲介・機構の経済性・共通機構の最小化・秘密の最小化を加えた7原則(および最小驚愕の原則)としてより広い枠組みを提示しており、二次情報が引く3原則はその部分集合にあたる。特に「フェイルセーフなデフォルト」の字句は両書でほぼ完全に一致しており、二次情報の引用が正確であることを一次資料が裏付ける。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 8 セキュリティ：負の目標]] ch.8 §8.3) - 「セキュリティは負の目標である」という定式化そのものが、本章の節番号(§11.1.2)として明確に存在することが一次資料で確認できた。二次情報側([[Jerome H. Saltzer]] entity の既存記述)は、この言葉が『ネットワークシステムについて語るときに我々の語ること』第8章の章題「セキュリティ：負の目標」の由来になったと述べているが、一次資料はこの言葉自体を独立した節タイトルとして本章冒頭で導入しており、二次情報の由来説明と矛盾しない。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.2) - 「反復のための設計(design for iteration)」も同様に、二次情報が単独の思想として紹介するのに対し、一次資料では「セーフティネット手法」を構成する2原則(be explicit・design for iteration)のうちの1つとして、耐障害性(第8章、Part I)からの直接の転用だと明記される。一次資料のほうが「なぜこの2つが対になっているか」の理由(セキュリティが負の目標である以上、設計者は常に自分の設計を疑い続けるパラノイア的態度を取るべきだという論理)を明示している点で、二次情報より文脈情報が豊富である。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.3) - **「完全な仲介」の原則は、ネットワークアーキテクチャではモジュール境界そのものを実施点として具体化できる**: 本章のComplete mediation(すべての操作について真正性・完全性・認可を検査せよ)は抽象的な設計原則にとどまるが、*The Real Internet Architecture* 第6章はこれをネットワーク合成の具体的な機構として与える——レイヤリング境界を横切るすべてのパケットは、アンダーレイの明確なセッションで受信されオーバーレイの明確なリンク上で受信されたことが分かるため、境界そのものがprovenance(来歴)付与と検査の自然な実施点になる。第6章はこの効果を「通常見られない多くのセキュリティチェックを促す」ことと「カスタムで再利用不能なコードのアタックサーフェスを縮小する」ことの2つに整理しており、後者は本章のEconomy of mechanism・Minimize common mechanismが挙げる「攻撃対象領域の最小化」を、合成されたネットワークという別ドメインで再演したものと解釈できる。両ソースは扱う対象(汎用計算機システム対ネットワークアーキテクチャ)が異なるが、「モジュール境界を仲介・検査の場として使う」という具体化の方向性は一致する。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 6 Ideas for a Better Internet]] ch.6 §6.3, [[モジュラー検証]]) - **ミドルボックスを基盤ネットワークから排除するという第6章の提言は、本章のMinimize common mechanismが警告する「共有された機構は望まぬ通信路を提供する」というリスクの具体例になっている**: 第6章§6.4.1は、base InternetのミドルボックスがMultipath TCPの展開を妨げた実例(TCPオプション付きパケットの拒否・除去により実験の14%の経路でセットアップが失敗)を挙げ、ミドルボックスを仮想エッジネットワークへ移すことで、エンドポイントが自分の通過するミドルボックスを選択・制御できるようにすべきだと論じる。本章のMinimize common mechanismは、共有機構(カーネル手続き等)が望まぬ通信路を提供するリスクを一般論として述べるにとどまるが、第6章はこれを「base Internetという万人共有の基盤に置かれたミドルボックスが、無関係なプロトコルの進化を予測不能に妨げる」という具体的な失敗事例で裏づけている。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 6 Ideas for a Better Internet]] ch.6 §6.4.1) - **『Security Engineering』第3版第1章は、本章が扱う「機構」の設計原則群を、より広い「ポリシー・機構・保証・インセンティブ」という4象限の分析フレームワークの中に位置づけ直す**: 本章(Saltzer & Schroeder)の7原則(オープンデザイン・秘密の最小化・完全な仲介・機構の経済性・共通機構の最小化・フェイルセーフなデフォルト・最小権限)は、いずれも「機構をどう設計すれば正しく動くか」という単一の問いに答えるものであり、Anderson のフレームワークにおける**機構(mechanism)**象限にほぼ収まる。しかし Anderson は、機構が正しく設計されていることと、その機構に実際に依拠してよいか(**保証**)、機構を運用する人間・組織が正しく使い続ける動機を持つか(**インセンティブ**)、そもそも何を達成すべきかが正しく規定されているか(**ポリシー**)は、独立した別の問題だと明示する。9/11後の空港保安の例(ナイフ持ち込み)は、機構(スクリーニング技術)の巧拙ではなく、ポリシーの誤り(当時3インチ以下の刃物を許可)と保証の欠如(実物兵器の高い見逃し率)、インセンティブの歪み(可視的対策の優先)が実際の失敗要因だったことを示す。本章の7原則はこの4象限のうち機構の1つしか扱わないため、両ソースを合わせると「機構が原則どおりに設計されていても、ポリシー・保証・インセンティブが伴わなければ依存可能なシステムにはならない」という、本章単独では見えない上位の枠組みが得られる。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.3-§11.1.4, [[@2020__Wiley__Security Engineering 3e - Chapter 1 What Is Security Engineering?]] ch.1 §1.2, [[セキュリティ工学の分析フレームワーク]]) - **『Security Engineering』第4章が§4.8で論じる「プロトコルロバストネス原則」は、本章の7原則のうちOpen design・Economy of mechanism・Minimize common mechanismをプロトコル設計という限定領域に特化させたものと解釈できる**: 第4章は、プロトコルの解釈がメッセージの内容だけに依存し文脈に依存すべきでないこと、名前や種別など重要な情報はすべてメッセージ中に明示すべきことを「ロバストネス」の中核だとする。これは本章のOpen design principle(機構を秘匿に頼らせない、誰にでも検証可能にする)およびEconomy of mechanism(機構が少なく単純であるほど正しく作れる)を、プロトコルメッセージの構文という具体的な単位に落とし込んだものだと整理できる。両ソースに共通するのは「省略・暗黙の前提こそが失敗の温床である」という考え方だが、本章がシステム全体のアクセス制御機構を対象にするのに対し、第4章は個々の認証メッセージの構文を対象にしており、同じ原則がスケールの異なる2つの設計単位で繰り返し現れることを示している。第4章はさらに、形式手法(BAN logicなど)による検証は「検証した範囲にバグがないこと」しか保証せず、後から追加された機能や実装上の問題(タイミング攻撃)までは防げないと注意しており、これは本章のいずれの原則にも明示的な対応物がない——「原則どおりに設計されたことをどう保証するか」という保証(assurance)の問題は、7原則の外側にあることを示唆する。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 4 Protocols]] ch.4 §4.8, [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[認証プロトコルの失敗モード]]) - **『Security Engineering』第3版第6章は、Least privilege principleが破られる具体的な機序を、UnixのSUID機構という単一の実装上の妥協点に集約して示す**: 本章のLeast privilege principle(特権プログラムは必要な操作の間だけ特権を持つべき)は抽象的な要請だが、第6章はUnix ACLが(user, program, file)という3次元のアクセス制御を表現できないため、プログラムをSUID rootにする間接手段に頼らざるを得ず、「プログラマは怠慢や納期の都合でアプリケーションをSUID rootにしてしまいがちで、これが深刻なセキュリティホールを生んだ」と報告する。これは、原則が破られるのは設計者の無知からではなく、機構の表現力不足(2次元機構で3次元問題を解こうとする構造的なミスマッチ)と開発現場のインセンティブ(納期優先)の組み合わせから生じることを示す、具体的な一次資料である。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.2.3) - **Fail-safe defaultsの原則は、Windows Vista以降のUAC導入という具体的な産業史として裏付けられる**: 第6章は、Windows Vista以前は「多くの日常タスクが管理者権限を要求したため、多くの企業が全ユーザーを管理者にしていた」状態から、Vistaが「User Account Control(UAC)がデフォルト権限をユーザー権限に置き換える」という変更を導入した経緯を描く。これは本章のFail-safe defaults(デフォルトはアクセス不可とし許可を明示列挙するほうが失敗モードが安全側になる)が、20年以上にわたり業界の主流OSでは実践されていなかったこと、そしてそれが変わるには単一のベンダーの意思決定と大規模な後方互換性の犠牲を要したことを示す。原則自体は1975年から存在したが、実装への反映には数十年の遅れがあったという事実は、本章だけでは見えない。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.2.9) - **信頼計算基盤(TCB)を小さくするというEconomy of mechanismの実践が、SGXエンクレーブでは「エンクレーブが何をすべきか」という脅威モデルの未定義という新しい失敗モードを生んだ**: 第6章が報告するMichael Schwarz・Samuel Weiser・Daniel Grussのエンクレーブ発ROP攻撃は、TCBを縮小すること自体は本章の原則(機構が少ないほど正しく作れる)に沿うが、縮小した部分の振る舞いを厳密に規定しなければ攻撃面が別の形で再出現することを示す。これは [[信頼計算基盤（TCB）]] ページで詳述する知見と同根であり、本ページでは「機構の経済性」という原則の限界(原則を守っても脅威モデルの設計を怠れば無効化されうる)として位置づけられる。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3.1, [[信頼計算基盤（TCB）]]) - **『Security Engineering』第9章は、第1章が抽象的に導入した「ポリシー」象限そのものの中身——「セキュリティポリシー」という語自体が3層の精密な用語に分解されるべきこと——を、本章とは独立に詳述しており、両者を合わせて初めて「機構だけでは足りない」というポリシー象限の内実が見える**: 本章(Saltzer & Schroeder)の7原則はすべて「機構をどう設計すべきか」という問いに答えるものであり、機構が従うべき前提としての「ポリシー」自体の中身には立ち入らない。第1章はポリシーを機構・保証・インセンティブと並ぶ独立した象限として位置づけるにとどまるが(既出の横断的知見)、第9章§9.2はこの「ポリシー」象限そのものを詳細に分解する——多くの組織が「security policy」を「経営陣の承認」「職員は従う」といった空虚な声明の集合(図9.1)として誤用することを指摘し、これと区別して**セキュリティポリシーモデル**(1ページ程度に収まる、システムが持つべき保護特性の簡潔な記述)・**セキュリティターゲット**(特定実装の防護機構の詳細記述)・**プロテクションプロファイル**(実装非依存の比較可能な記述)という3層の精密な用語を導入する。本章の7原則が「機構をいかに正しく設計するか」を扱うのに対し、第9章は「そもそも機構が従うべきポリシーをいかに曖昧さなく書くか」を扱っており、両者を合わせて初めて、第1章が図式的に示した「ポリシー」象限と「機構」象限が、それぞれ独立に精緻化されるべき別問題であることが具体的に分かる。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.3-§11.1.4, [[@2020__Wiley__Security Engineering 3e - Chapter 1 What Is Security Engineering?]] ch.1 §1.2, [[@2020__Wiley__Security Engineering 3e - Chapter 9 Multilevel Security]] ch.9 §9.2, [[多層セキュリティ（MLS）]]) - **『Security Engineering』第3版第27章は、本章のEconomy of mechanism・Minimize secretsが「設計原則」として規定する内容を、安全工学由来の「ハザード除去(hazard elimination)」という分析手法の産物として、独立の角度から再導出している**: 本章(Saltzer & Schroeder)はEconomy of mechanism(機構が少ないほど正しく作れる)・Minimize secrets(秘密を最小化せよ)を、遵守すべき規範として提示するにとどまる。第27章は同じ発想を「信頼計算基盤(TCB)の最小化はハザード除去の一種である」と位置づけ直し、SWIFTの初期設計(銀行間で鍵を直接交換し、SWIFT自身が取引を偽造する手段を持たないようにした設計、第12章由来)を具体例として挙げる。さらに図27.2のモーター逆転回路(バッテリーとモーターの位置を入れ替えるだけでスイッチ故障時の被害を限定する)という、ソフトウェア工学とは無関係な機械設計の例で同じ発想を視覚化する。両ソースを合わせると、「機構を減らし秘密を集約する」という本章の規範的原則が、「まずハザードを分析し、それを設計から除去できないか検討する」という手続き的な分析プロセスの帰結としても独立に導出できることが分かる——原則(what)と手法(how)という異なるレイヤーから同じ設計判断に到達する、という関係である。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.3.2, [[リスク分析とハザード分析手法]]) - **『Security Engineering』第28章は、本章のOpen design principle(オープンデザインの原則)を、1641年のJohn Wilkinsから1883年のKerckhoffs、20世紀末のFOSS運動まで350年に及ぶ歴史的系譜として実証する**: 本章のOpen design principleは「機構をアルゴリズムの秘匿ではなく鍵の秘匿に依存させよ、誰にでも設計に意見させよ」という抽象的な要請にとどまるが、第28章§28.3.3は同じ主張の来歴を、暗号学の著述を擁護したJohn Wilkins(1641年)、「秘密は鍵にのみ依存すべき」と定式化したAuguste Kerckhoffs(1883年)、そしてこの哲学をアルゴリズムからソフトウェア実装そのものへ拡張した自由・オープンソースソフトウェア(FOSS)運動へと繋げて描く。さらに第28章はEric Raymondの「to many eyes, all bugs are shallow」という定式化と、オープン化が有利かどうかを判断する5基準(企業秘密ではなく共通工学知識に基づくか、失敗に敏感か、検証に査読が要るか、事業上重要で異なる利用者が協力してバグ取りするか、強いネットワーク外部性を持つか)を挙げ、セキュリティはこの5基準すべてを満たすとする。本章のOpen design principleが1行で述べる規範を、第28章は350年分の歴史的事例と実証的な判断基準にまで肉付けする。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.3.3) - **第28章は、Open design principleの「オープン性は誰に有利か」という問いに対し、標準的な信頼性成長モデルのもとでは攻撃・防御を対称に助けるという理論的な答えを与える**: 本章のOpen design principleは、なぜオープンな設計が望ましいかを規範として述べるにとどまるが、第28章§28.3.3は、標準的な信頼性成長モデル(k/t則)のもとでは開示は攻撃側・防御側を等しく助けることが理論的に示せると述べたうえで、実証研究(OpenBSDのバグが有意に相関していたためオープン性が有益だった事例)を挙げ、実際の有利・不利は「独立なバグ」という標準的前提からの乖離度に依存する経験的な問題だと結論づける。これは、本章が規範として提示するOpen design principleに対し、「いつ・なぜ有効か」という条件つきの理論的・実証的な裏づけを与えるものであり、原則の妥当性の限界を示す点で本ページの積み増しに寄与する。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]] ch.28 §28.3.3) - **『Building Secure and Reliable Systems』第1章は、本章のMinimize common mechanism・機構の経済性が扱う「攻撃対象領域の最小化」の裏面として、信頼性向上のための冗長性がセキュリティ上は攻撃対象領域の拡大になるというトレードオフを、独立した角度から提示する**: 本章(Saltzer & Schroeder)はMinimize common mechanism(共有機構は望まぬ通信路を提供する)・機構の経済性(機構が少ないほど正しく作れる)から「攻撃対象領域を最小化せよ」という通俗的な合成定式化を導くが、これは主に機構を減らす・共有しないという方向の議論であり、冗長性(redundancy)そのものは扱わない。『Building Secure and Reliable Systems』第1章は、信頼性設計が要求する冗長性(電子錠の物理鍵によるフェイルセーフ、火災避難経路の複数化など)が、まさにこの意味で攻撃対象領域を拡大すると明言する——敵対者は複数ある経路のうち1つの脆弱性を突けば成功するためである。両ソースを合わせると、「機構を減らす」という本章の原則群と「信頼性のために冗長性を持たせる」という設計要求が、同一の攻撃対象領域という尺度の上で綱引き関係にあることが分かる。本章単独では、冗長性がなぜ・どのように攻撃対象領域を広げるかという具体的なメカニズムまでは踏み込んでいない。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 1 The Intersection of Security and Reliability]] ch.1 §Reliability and Security Tradeoff: Redundancy) - **同章の Complete mediation(完全な仲介)は、`Building Secure and Reliable Systems` 第1章が示すセキュリティインシデント対応の need-to-know 原則と緊張関係にありうる**: 本章のComplete mediationは「すべての操作について真正性・完全性・認可を検査せよ」と述べ、検査(仲介)の網羅性を要求する。第1章は、セキュリティインシデント対応では関わる人数を絞り情報をneed-to-know原則で共有するほうが敵対者に対応を悟られずに済むと述べる。両者を突き合わせると、「機構レベルでの完全な仲介」(自動化された検査の網羅性)と「組織レベルでの情報制限」(人間の関与を絞る)は、どちらも敵対者を想定した設計判断でありながら、前者は検査を増やす方向、後者は共有を減らす方向という一見逆向きのベクトルを持つ。両者が両立する理由(検査は機械的に完全であるべきだが、検査結果や対応プロセスの人間への開示は最小化すべき、という層の違い)は、両ソースの範囲では明示的に論じられていない。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.4, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 1 The Intersection of Security and Reliability]] ch.1 §Reliability and Security Tradeoff: Incident Management) ## 未解決の問い - 第27章のハザード除去(hazard elimination)という分析手法と、本章のEconomy of mechanism・Minimize secretsという規範的原則は、体系的にどちらが先に来るべきか(ハザード分析の結果として原則が導かれるのか、原則を先に定めてからハザード分析で検証するのか)は、両ソースの突き合わせだけでは確定できない。 - 第6章が提案する「レイヤリング境界でのprovenance付与」は、本章の7原則のどれに最も対応するか(Complete mediationの具体化なのか、それとも独立した第8の原則的な発想なのか)は、両ソースを突き合わせただけでは確定できない。 - 第9章のセキュリティポリシーモデル/セキュリティターゲット/プロテクションプロファイルという3層の用語は、本章の7原則のうちどれか特定の原則に対応するものではなく、7原則全体が前提とする「そもそも何を守るべきか」を定める上位工程にあたる。この3層の区分と、本章のOpen design principle(機構をアルゴリズムの秘匿ではなく鍵の秘匿に依存させる)のような「機構」レベルの原則との間に、体系的な対応関係(どの原則がどの層の精緻化に依存するか)があるかは、両ソースの突き合わせだけでは確定できない。 - Windows UAC導入(2006年)がFail-safe defaultsの原則に20年以上遅れて追いついた経緯を、Unix系OS(1970年代からユーザー/root分離を持つ)や本章の7原則自体の来歴と比較すると、「原則の存在」と「原則の産業実装」の間のタイムラグを生む要因(市場構造、後方互換性の圧力、インセンティブの歪みなど)は何か。本章単独・第6章単独では体系的に答えられない。 - 本章は最小驚愕の原則を7原則とは別枠で(仲介の文脈の中で)言及するが、[[Principles of Computer System Design]] の巻頭原則一覧では「特定領域に適用される原則」の"Security:"接頭辞付き原則が7つ、"最小驚愕の原則"は「多くの領域に適用できる原則」に分類されている。本章内の位置づけと巻頭一覧の分類がどう対応するかは、他章(特にPart I)の原則運用例と突き合わせないと確定できない。 - 「攻撃対象領域の最小化」という合成定式化は本章では脚注的に触れられるのみで、4つの原始原則との厳密な対応関係(どの原則がどう寄与するか)の形式的な議論はない。 - Complete mediation(機構レベルでの検査の網羅性)とneed-to-know原則(組織レベルでの情報共有の制限)がなぜ両立するか(層の違いによる整理で説明できるのか)は、両ソースの突き合わせだけでは確定できない。 - 1975年の論文自体を本wikiはまだ一次情報として ingest していない(本章はその内容を引き継いだ教科書という二次的伝達者)。原論文 "The Protection of Information in Computer Systems" (Proceedings of the IEEE, 1975) を直接 ingest すれば、両方の教科書的要約と突き合わせる三点測量が可能になる。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 1 The Intersection of Security and Reliability]](§Reliability and Security Tradeoff: Redundancy, §Reliability and Security Tradeoff: Incident Management) / [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]](§11.1.3, §11.1.4) / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 8 セキュリティ：負の目標]](§8.3) / [[@2024__PrincetonUP__The Real Internet Architecture - Chapter 6 Ideas for a Better Internet]](§6.3, §6.4.1) / [[@2020__Wiley__Security Engineering 3e - Chapter 1 What Is Security Engineering?]](§1.2) / [[@2020__Wiley__Security Engineering 3e - Chapter 4 Protocols]](§4.8) / [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]](§6.2.3, §6.2.9, §6.3.1) / [[@2020__Wiley__Security Engineering 3e - Chapter 9 Multilevel Security]](§9.2) / [[@2020__Wiley__Security Engineering 3e - Chapter 28 Assurance and Sustainability]](§28.3.3) - 概念: [[ゼロトラスト]](最小権限の原則の派生) / [[信頼計算基盤（TCB）]](機構の経済性・完全な仲介の実装戦略) / [[ネットワークセキュリティアーキテクチャ]] / [[モジュラー検証]](完全な仲介の原則をモジュール境界で具体化する例) / [[セキュリティ工学の分析フレームワーク]](本章の7原則を機構象限として包含する上位フレームワーク) / [[認証プロトコルの失敗モード]](プロトコルロバストネス原則との対応) / [[認可モデル]](Least privilege principleがSUID機構で破られる経路) / [[多層セキュリティ（MLS）]](セキュリティポリシーモデルという用語の詳細な精緻化) / [[リスク分析とハザード分析手法]](ハザード除去という分析手法によるEconomy of mechanism・Minimize secretsの再導出) - 実体: [[Jerome H. Saltzer]] / [[Michael D. Schroeder]] / [[Principles of Computer System Design]] ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 1. - Jerome H. Saltzer and M. Frans Kaashoek, *Principles of Computer System Design: An Introduction*, Version 5.0, 2009, Chapter 11 §11.1.3-§11.1.4. MIT OpenCourseWare, CC BY-NC-SA 3.0 US. - Larry Peterson・Bruce Davie 著, 進藤資訓訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第8章 §8.3. - Pamela Zave, Jennifer Rexford, *The Real Internet Architecture*, Princeton University Press, 2024, Chapter 6, §6.3, §6.4.1. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 1, §1.2. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 4, §4.8. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 6, §6.2.3, §6.2.9, §6.3.1. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 9, §9.2. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 27, §27.3.2. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 28, §28.3.3.