※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料 作：｛作者名｝
※物語はフィクションです ※
※即時通報案件は専門家にご通報ください※
※お手数ですが疑問点は各分野でご確認いただけましたら幸いです※
# BOOK-0370 情報防衛と復旧シリーズ 第11巻: ネットワーク防御の設計 — セグメンテーション・ゼロトラスト・IDS/IPSで境界をどう作り直すか
> 情報防衛と復旧シリーズ(全12巻・BOOK-0360〜0371・設計書=CATALOG_情報防衛と復旧シリーズ.md)第11巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務のうち、本巻が担うのは**予防**——境界を最初からどう設計しておけば、破られたときの被害を小さく留められるか——である。CATALOG §0.3が指摘するとおり、既刊BOOK-0070・BOOK-0119は通信の一般理論(パケット・階層・TCP/IP・信頼性・暗号とTLS)を扱ったが、そこに「防御構成」は無かった。本巻はセグメンテーション・ゼロトラストアーキテクチャ・ファイアウォール/IDS/IPSの設計思想を主眼に、この欠落を接続する。
> **安全枠(§16.18・本巻での適用範囲・最重要)**: 本巻は防御・検知・教育に限定する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・ファイアウォール回避手順・検知回避手法は一切書かない。防御に欠陥があった場合に何が起こりうるかに触れる場面があっても、「何を・どこに・なぜ置くか」という防御側の設計判断にとどめ、攻撃側の技術詳細には立ち入らない(IMPORTANT: authorized security testing/defensive securityの枠内)。「この構成なら絶対に侵入されない」といった誇張はしない——多層の防御は侵入の確率とコストを上げるが、ゼロにはしない、という正直な水準で書く。
> 接続先: →BOOK-0360『情報セキュリティ総論』第四章(多層防御・単一障害点)・第七章(信頼境界・完全な仲介・ゾーン管理)——本巻の全設計は、この土台の上に立つ。→BOOK-0361『認証・認可とアクセス制御』第十章(ゼロトラスト・継続的検証)——本巻第七章・第八章は、そちらが認証・認可の視点から定義したゼロトラストを、ネットワークアーキテクチャの視点から実装する。→BOOK-0070・BOOK-0119『ネットワーク』(通信の一般理論=パケット・階層・IP/TCP・暗号とTLS)——本巻はこれらの定義を再定義せず引き継ぐ。→BOOK-0367『監視と観測可能性』(しきい値という考え方)——本巻第五章のアノマリ型検知は、そちらの考え方をネットワーク層に適用したものである。→BOOK-0366『可用性・信頼性工学(SRE)』(冗長化・段階的縮退)——本巻第九章のレート制限は、可用性を守る設計とも接続する。→BOOK-0363『インシデント対応の一本道』——本巻の防御が破られた先には、そちらの封じ込め→根絶→復旧→教訓という一本道が続く。
> 水準: 一〜十二(初心者→熟練者→上級専門家→講師級の四段は、おおむね水準一〜三/四〜七/八〜十/十一〜十二に対応する。「境界だけでは守れない」という出発点から、ファイアウォールとセグメンテーションという基本の道具立て、IDS/IPSという検知と防止、ゼロトラストアーキテクチャという設計思想、そして講師級の視点として「なぜ境界防御からゼロトラストへのパラダイム転換が起きたのか」というメタ的推移までを、一冊で貫通する)。
---
# BOOK-0370 情報防衛と復旧シリーズ 第11巻: ネットワーク防御の設計 — セグメンテーション・ゼロトラスト・IDS/IPSで境界をどう作り直すか
> 情報防衛と復旧シリーズ(全12巻・BOOK-0360〜0371・設計書=CATALOG_情報防衛と復旧シリーズ.md)第11巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務のうち、本巻が担うのは**予防**——境界を最初からどう設計しておけば、破られたときの被害を小さく留められるか——である。CATALOG §0.3が指摘するとおり、既刊BOOK-0070・BOOK-0119は通信の一般理論(パケット・階層・TCP/IP・信頼性・暗号とTLS)を扱ったが、そこに「防御構成」は無かった。本巻はセグメンテーション・ゼロトラストアーキテクチャ・ファイアウォール/IDS/IPSの設計思想を主眼に、この欠落を接続する。
> **安全枠(§16.18・本巻での適用範囲・最重要)**: 本巻は防御・検知・教育に限定する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・ファイアウォール回避手順・検知回避手法は一切書かない。防御に欠陥があった場合に何が起こりうるかに触れる場面があっても、「何を・どこに・なぜ置くか」という防御側の設計判断にとどめ、攻撃側の技術詳細には立ち入らない(IMPORTANT: authorized security testing/defensive securityの枠内)。「この構成なら絶対に侵入されない」といった誇張はしない——多層の防御は侵入の確率とコストを上げるが、ゼロにはしない、という正直な水準で書く。
> 接続先: →BOOK-0360『情報セキュリティ総論』第四章(多層防御・単一障害点)・第七章(信頼境界・完全な仲介・ゾーン管理)——本巻の全設計は、この土台の上に立つ。→BOOK-0361『認証・認可とアクセス制御』第十章(ゼロトラスト・継続的検証)——本巻第七章・第八章は、そちらが認証・認可の視点から定義したゼロトラストを、ネットワークアーキテクチャの視点から実装する。→BOOK-0070・BOOK-0119『ネットワーク』(通信の一般理論=パケット・階層・IP/TCP・暗号とTLS)——本巻はこれらの定義を再定義せず引き継ぐ。→BOOK-0367『監視と観測可能性』(しきい値という考え方)——本巻第五章のアノマリ型検知は、そちらの考え方をネットワーク層に適用したものである。→BOOK-0366『可用性・信頼性工学(SRE)』(冗長化・段階的縮退)——本巻第九章のレート制限は、可用性を守る設計とも接続する。→BOOK-0363『インシデント対応の一本道』——本巻の防御が破られた先には、そちらの封じ込め→根絶→復旧→教訓という一本道が続く。
> 水準: 一〜十二(初心者→熟練者→上級専門家→講師級の四段は、おおむね水準一〜三/四〜七/八〜十/十一〜十二に対応する。「境界だけでは守れない」という出発点から、ファイアウォールとセグメンテーションという基本の道具立て、IDS/IPSという検知と防止、ゼロトラストアーキテクチャという設計思想、そして講師級の視点として「なぜ境界防御からゼロトラストへのパラダイム転換が起きたのか」というメタ的推移までを、一冊で貫通する)。
---
## 入口の物語 — 一つの扉が、すべての部屋につながっていた
ある組織の情報システム部門が、年に一度の構成図の棚卸しをしていたときのことである。図を描き終えて全員が黙り込んだ。ネットワーク図の中心には、経理担当者の一台のノートパソコンから、人事データベース・設計図面のファイルサーバー・顧客情報を扱う基幹システムまで、線を引けば一直線につながる経路が、何の区切りもなく描かれていたのだ。
このネットワークには、外周を守るファイアウォールが一台、きちんと設置されていた。インターネットから社内への通信は、そこでしっかり検査されている。しかし、いったんその一台のファイアウォールを通過して「社内」に入ってしまえば、その先には区切りが何もなかった。経理の部屋も、人事の部屋も、設計図面の部屋も、まるで一枚の巨大なワンルームのように、内側ではどこへでも自由に行き来できる構造になっていた。
これは、決して珍しい話ではない。「外の敵から城を守るために、頑丈な城壁とお堀を築く」という発想——**境界防御(きょうかいぼうぎょ、perimeter defense、水準一: ネットワークの外周に単一の防御線を設け、外部と内部とを分けたうえで、内部を信頼する設計思想)**——は、長らくネットワーク防御の主役だった。しかしこの発想には、ある前提が隠れている。それは「城壁の内側にいる者は、みな味方である」という前提だ。もしこの前提が崩れる場面——一台の端末が想定外の状態になる、内部にいるはずの誰かの認証情報が想定外に使われる、といった場面——が起きたとき、城壁の内側に区切りが無ければ、被害は城全体に広がりうる。
本巻が案内するのは、この「一つの扉が、すべての部屋につながっていた」という状態を、どう作り直すかという設計の仕事である。ネットワークを区画に分け(第二章〜第四章)、その区画をまたぐ通信を見張り(第五章)、区画・見張り・境界という道具立てがどう補い合うのかを整理し(第六章)、続いて「社内にいるから安全」という前提そのものを手放すゼロトラストアーキテクチャへと歩みを進め(第七章〜第八章)、負荷そのものへの防御的な備えを固め(第九章)、境界を増やすことの現実的なコストを検算し(第十章)、現代最先端のクラウド時代の防御を見渡し(第十一章)、最後に、なぜ「城壁一枚」という古い発想が「その都度検証する」という新しい発想へと転換していったのかを、講師級の視点でたどる(第十二章)。
一つの扉が、すべての部屋につながっていた組織の物語の続きを、この一冊で最後までたどり切ろう。
---
## 第一章: 境界だけでは守れない — 境界防御の限界(水準一)
### 境界防御という古くからの発想
姉妹巻BOOK-0360第七章は、システムの中で、信頼してよいデータ・処理の領域と、信頼できない外部からの入力の領域とを、明確に区切る境界線を**信頼境界**と定義した。本巻ではこの定義をそのまま引き継ぐ。ネットワークの世界において、この信頼境界を、外周に単一の防御線として築く古典的な設計思想が、入口の物語で見た**境界防御**である。組織のネットワークを一つの建物にたとえれば、境界防御は「正面玄関に頑丈な鍵を一つ付け、建物の中には自由に出入りできる廊下を通す」設計にあたる。
境界防御を実現する代表的な道具が、ネットワークの境界に置かれ、通過する通信を検査して許可・拒否を判定する機器・仕組みである**ファイアウォール(firewall、水準一: ネットワークの境界に置かれ、通過する通信を検査して許可・拒否を判定する機器・仕組み)**である。ファイアウォールの内部の仕組み(パケットフィルタリング・ステートフルインスペクション)は第二章で詳しく扱うが、ここではまず「境界に置かれた検問所」という役割だけを押さえておけば十分である。
### なぜ境界一枚では守れないのか
姉妹巻BOOK-0360第四章は、その一箇所が機能しなくなるだけで、システム全体が止まってしまう部分を**単一障害点**と定義した。境界防御を、ネットワーク全体でただ一つの検問所だけに頼る形で運用してしまうと、この検問所は可用性の単一障害点であるだけでなく、防御そのものの単一障害点にもなる。入口の物語のネットワークでは、外周のファイアウォールという検問所さえ通過してしまえば、その先には検証の仕組みが何も無かった。これは、姉妹巻BOOK-0360第四章の多層防御——単一の防御策だけに頼らず、性質の異なる複数の防御層を重ねる設計思想——が、ネットワークの内部にはまったく適用されていない状態だと言い換えられる。
境界防御という発想そのものが誤りだというわけではない。境界に検問所を置くことは、今なお防御の重要な一部である。問題なのは、境界を「一度きりの壁」として扱い、内部に足を踏み入れた通信をそれ以上検証しない設計にしてしまうことである。この限界への応答として、ネットワークを内部でも区切り直す**セグメンテーション**(第三章)、その区切りをさらに細かくする**マイクロセグメンテーション**(第四章)、そして「内部だから安全」という前提そのものを手放す**ゼロトラストアーキテクチャ**(第七章〜第八章)という、本巻の主題である一連の設計思想が積み上がっていく。
### コラム — 「境界防御」と「多層防御」は対立しない
境界防御という言葉を聞くと、「境界だけに頼る古い考え方」という否定的な響きを感じるかもしれないが、正確には「境界を"唯一"の防御層として扱う設計」が問題なのであって、境界そのものを撤去すべきだという話ではない。実務では、外周のファイアウォールは今もなお防御の第一層として広く使われ続けている。本巻がこれからたどるのは、境界という第一層に、姉妹巻BOOK-0360第四章の多層防御をどう重ねていくか、という積み上げの物語である。
---
> **定着量の目安(第一章)**: 境界防御という言葉と、姉妹巻BOOK-0360第七章の信頼境界という言葉が、それぞれ何を指しているかを、自分の言葉で一行ずつ整理しておく。あわせて、「境界一枚だけに頼る設計」の弱点を、姉妹巻BOOK-0360第四章の単一障害点という言葉を使って説明できるようにしておく。
---
## 第二章: ファイアウォールの設計思想 — パケットフィルタリングとステートフルインスペクション(水準二)
### ヘッダ情報だけを見る、最も基本的な検問
姉妹巻BOOK-0070、および前提を引き継ぐBOOK-0119第一章は、送りたいデータを小さな単位に分割して送る仕組み(パケット交換)と、宛先の管理・配送を担うIP、正確な組み立て直しを担うTCPという役割分担をすでに扱っている。本巻ではこれらの定義を再定義せず引き継ぐ。ファイアウォールの最も基本的な動作方式は、この送信元・宛先のIPアドレスやポート番号など、パケットのヘッダ情報だけを見て通過の可否を判定する方式であり、これを**パケットフィルタリング(packet filtering、水準二: 送信元・宛先のIPアドレスやポート番号など、パケットのヘッダ情報だけを見て通過の可否を判定する方式)**と呼ぶ。
パケットフィルタリングの判定は、あらかじめ用意した規則の一覧と、パケットのヘッダの値を照合する作業である。この照合は、本プロジェクトの関数辞書に索引されている、ある値があらかじめ定めた範囲・境界の内側に収まっているかどうかを検査する仕組み(索引: FUNC-0390「境界値検査〈boundary/range check〉」)と、発想の根っこの部分で共通している——どちらも「値が、あらかじめ決めた条件に収まっているかどうか」を一件ずつ機械的に確かめる作業である。パケットフィルタリングの規則は、多くの場合、あらかじめ許可した送信元・ポートだけを通す構成で書かれる。本プロジェクトの関数辞書に索引されている、あらかじめ許可した呼び出し元だけに処理を許す仕組み(索引: FUNC-1077「ホワイトリスト方式の呼び出し制限〈whitelist call restriction〉」)や、通信の出所があらかじめ定めた許可リストに含まれているかを検査する仕組み(索引: FUNC-0771「出所ホワイトリスト検査〈source reason whitelist check〉」)は、直接ネットワークのファイアウォール規則を扱う技術ではないものの、「あらかじめ許可した相手だけを通す」という設計思想において、ファイアウォールの規則設計と構造的に共通している。
### 通信の文脈を覚えておく、一歩進んだ検問
パケットフィルタリングには弱点がある。一つ一つのパケットを独立に検査するため、「この応答パケットは、こちらから出した要求への正当な返事なのか」という文脈を判定に使えない。この弱点に応えるのが、通信の状態(セッションの確立状況)を記憶し、その文脈に照らして各パケットの可否を判定する方式である**ステートフルインスペクション(stateful inspection、水準二: 通信の状態〈セッションの確立状況〉を記憶し、その文脈に照らして各パケットの可否を判定する方式)**である。ステートフルインスペクションを行うファイアウォールは、「こちらから外部へ要求を出した通信については、その応答だけを一時的に通す」という記憶を保持できるため、要求してもいない通信が外部から一方的に内部へ届いた場合には、それを不審なものとして扱いやすくなる。
さらに一歩進み、パケットのヘッダだけでなく、通信の中身(どのアプリケーションの、どんな種類のやり取りか)まで検査対象に含める設計を、**次世代ファイアウォール(NGFW、next-generation firewall、水準二: パケットのヘッダだけでなく、通信の中身〈アプリケーションの種別など〉まで検査対象に含めるファイアウォールの設計)**と呼ぶ。パケットフィルタリングが「封筒の宛名だけを見る検問」だとすれば、ステートフルインスペクションは「この封筒が、こちらが送った手紙への返事かどうかを覚えている検問」、次世代ファイアウォールは「封筒の中身の種類まで確認する検問」だと段階的に理解しておくとよい。
### 許可リストと拒否リスト、そしてデフォルト拒否の原則
ファイアウォールの規則を設計する際には、大きく分けて二つの方針がある。あらかじめ許可した通信だけを通し、それ以外はすべて拒否する方針を、**デフォルト拒否(default deny、水準二: あらかじめ許可した通信だけを通し、それ以外はすべて拒否するという規則設計の方針)**と呼ぶ。逆に、あらかじめ拒否した通信だけを止め、それ以外はすべて通す方針を、**デフォルト許可(default allow、水準二: あらかじめ拒否した通信だけを止め、それ以外はすべて通すという規則設計の方針)**と呼ぶ。
デフォルト拒否は、想定していなかった種類の通信が現れた場合、その通信は自動的に拒否される。デフォルト許可は逆に、想定していなかった種類の通信が現れた場合、その通信は自動的に通ってしまう。この違いは小さく見えるが、姉妹巻BOOK-0360第七章が扱った「便利な近道は、たいてい新しい信頼境界の穴になる」という教訓と直結している——デフォルト許可の設計は、規則の書き漏れそのものが、そのまま抜け道になってしまう。このため、実務のファイアウォール設計では、外部との境界においてはデフォルト拒否を基本方針とし、業務上必要な通信だけを個別に許可していく、という積み上げ型の規則設計が広く推奨されている。この積み上げの発想は、本章ですでに触れたホワイトリスト方式の呼び出し制限(索引: FUNC-1077)が体現する「あらかじめ許可した相手だけを通す」という設計思想を、規則設計の方針そのものにまで一段押し広げたものだと理解できる。
### コラム — ファイアウォールは「万能の壁」ではない
ファイアウォールは、あらかじめ定義した規則に基づいて通過の可否を判定する仕組みである以上、その規則が想定していない通信パターンについては、判定のしようがない。次世代ファイアウォールであっても同様であり、「ファイアウォールさえ置けば内部は考えなくてよい」という理解は、第一章で見た境界防御の限界をそのまま繰り返すことになる。ファイアウォールは本巻全体を通じて積み上げる多層防御の第一層であって、唯一の層ではない、という理解を持ち続けてほしい。
---
> **定着量の目安(第二章)**: パケットフィルタリング・ステートフルインスペクション・次世代ファイアウォールという三つの方式が、それぞれ「何を見て」判定しているかを、自分の言葉で一行ずつ整理してみる。あわせて、「封筒の宛名だけを見る検問」「返事かどうかを覚えている検問」「中身の種類まで確認する検問」という本章のたとえを、自分なりの別のたとえに置き換えられるかを試してみるとよい。
---
## 第三章: セグメンテーションの基礎 — VLAN・サブネットとDMZ(水準三)
### ネットワークを区画に分ける
第一章で見た「一つの扉が、すべての部屋につながっていた」という状態を作り直す、最も基本的な設計が、ネットワークを複数の区画に分割し、区画間の通信を意図的に制限する設計である**セグメンテーション(network segmentation、水準三: ネットワークを複数の区画に分割し、区画間の通信を意図的に制限する設計)**である。セグメンテーションの発想そのものは、決してネットワーク特有のものではない。本プロジェクトの関数辞書に索引されている、資産や要素が所属しうる複数の領域を明示的な区画として管理し、常にちょうど1つの区画に属するようにする仕組み(索引: FUNC-0609「ゾーン管理〈手札・山札・場・墓地の区画分離〉」、姉妹巻BOOK-0360第七章でも「境界の内と外を分けるもう一つの実例」として紹介済み)は、「あるものが今どの区画に属しているかを、あいまいさなく常に一つに定める」という発想を体現しており、この発想はネットワークのセグメンテーションにもそのまま当てはまる。手札という区画にあるカードが、無条件に墓地という区画のカードへ影響を及ぼせないのと同じように、ある区画にあるサーバーが、無条件に別の区画のサーバーへ通信できてはならない、という設計判断が、セグメンテーションの中心である。
### 物理と論理、二つの分け方
ネットワークを区画に分ける方法には、大きく分けて二つの筋道がある。一つは、物理的な配線に関わらず、機器を論理的にグループ分けする技術である**VLAN(仮想LAN、virtual LAN、水準三: 物理的な配線に関わらず、機器を論理的にグループ分けする技術)**である。VLANを使えば、同じ配線を共有していても、設定によって別々の区画として扱うことができる。もう一つは、姉妹巻BOOK-0070・BOOK-0119ですでに定義済みのIPアドレスの体系を、より小さな範囲に区切って管理する**サブネット(subnet、水準三: IPアドレスの体系を、より小さな範囲に区切って管理する単位)**である。VLANが「論理的なグループ分け」、サブネットが「住所の範囲としての区切り」という、それぞれ異なる角度からの区画分けであり、実務では両者を組み合わせて使うことが多い。
### 外に見せる部分だけを、隔離した緩衝地帯に置く
外部に公開する必要のあるサーバー(自社のウェブサイトなど)は、内部ネットワークにそのまま置くと、外部からの通信をそのサーバー経由で内部の奥深くまで届けてしまう危険がある。この課題に応えるのが、外部に公開する必要のあるサーバーを、内部ネットワークからも外部ネットワークからも隔離した緩衝地帯に置く設計である**DMZ(非武装地帯、demilitarized zone、水準三: 外部に公開する必要のあるサーバーを、内部ネットワークからも外部ネットワークからも隔離した緩衝地帯に置く設計)**である。DMZに置かれたサーバーは、外部からの通信を受け付けるが、そこから内部ネットワークの奥深くへ直接進めるような通信は、原則として許可されない構成になる。
DMZという設計は、本プロジェクトの関数辞書に索引されている、公開してよい情報と、公開してはならない情報とを明確に分けて管理する仕組み(索引: FUNC-0612「公開情報・非公開情報の分離管理〈hidden information partition〉」)と、発想の根っこの部分で共通している——どちらも「外に見せてよい部分」と「内側にだけ留めておくべき部分」を、あいまいにせず明確な区画として分離するという設計思想である。
### 内部の実体を、さらに一枚隠す
DMZに置かれたサーバーであっても、その実体(具体的な内部アドレスや構成)を外部にそのまま晒すことには慎重であるべきである。この課題への一つの応答が、外部からの通信を一度代理で受け止め、内部の実サーバーへ改めて転送する仕組みである**リバースプロキシ(reverse proxy、水準三: 外部からの通信を一度代理で受け止め、内部の実サーバーへ改めて転送する仕組み)**である。外部から見ると、通信の相手はリバースプロキシだけであり、その先にどんな構成の実サーバーが何台あるのかは、直接には見えない。これは、第二章で見たファイアウォールが通信の可否を判定する検問所であるのに対し、リバースプロキシは「代わりに応対する受付係」に近い役割を果たす、という違いがある。両者は排他的な選択肢ではなく、実務ではDMZの中にファイアウォールとリバースプロキシを組み合わせて配置することが多い。
### コラム — DMZは「安全地帯」ではなく「隔離された緩衝地帯」
DMZという名前から、「DMZに置けば安全になる」という誤解が生まれることがあるが、これは正確ではない。DMZに置かれたサーバーは、外部から到達可能である以上、姉妹巻BOOK-0360第三章の攻撃対象面の一部であり続ける。DMZの本当の意味は、「そのサーバーが想定外の状態になった場合でも、被害が内部ネットワークの奥深くまで直接広がらないよう、あらかじめ隔離しておく」という被害の封じ込めにある。この「封じ込め」という発想は、次章のマイクロセグメンテーションでさらに掘り下げる。
---
> **定着量の目安(第三章)**: セグメンテーション・VLAN・サブネット・DMZという四つの言葉を、「何を」「どう区切るか」という観点で一行ずつ整理してみる。あわせて、姉妹巻BOOK-0360第七章のゾーン管理(FUNC-0609)のたとえ(手札・山札・場・墓地)を、本章のネットワークの区画分けにどう対応づけられるか、自分の言葉で説明できるようにしておく。
---
## 第四章: マイクロセグメンテーション — 内部の通信をどこまで細かく区切るか(水準四)
### 南北の通信と、東西の通信
ネットワークを流れる通信には、向きによる呼び分けがある。外部と内部との間を行き来する通信を**南北トラフィック(north-south traffic、水準四: 外部ネットワークと内部ネットワークとの間を行き来する通信)**、内部ネットワークの中で、サーバー同士・区画同士の間を行き来する通信を**東西トラフィック(east-west traffic、水準四: 内部ネットワークの中で、サーバー同士・区画同士の間を行き来する通信)**と呼ぶ。第一章・第二章で見た境界のファイアウォールは、主に南北トラフィックを検査する仕組みである。しかし、入口の物語で見たとおり、いったん内部に入ってしまえば、東西トラフィックには何の検証もかからないという設計は、依然として危うい。
### 区画をさらに細かくする
第三章のセグメンテーションを、ネットワークの外周や大きな部門単位だけでなく、内部の個々のワークロード・サーバー単位まで区画を細分化し、区画間の通信を制御する設計まで押し広げたものを、**マイクロセグメンテーション(micro-segmentation、水準四: 従来のネットワーク境界〈外周〉だけでなく、内部の個々のワークロード・サーバー単位まで区画を細分化し、区画間の通信を制御する設計)**と呼ぶ。第三章のセグメンテーションが「建物をいくつかの階に分ける」設計だとすれば、マイクロセグメンテーションは「各階の、さらに一部屋一部屋にまで鍵を付ける」設計に近い。
この「一部屋一部屋に鍵を付ける」という発想は、本プロジェクトの関数辞書に索引されている、乱数を呼び出す箇所をあらかじめ分離しておく仕組み(索引: FUNC-0649「乱数呼び出し箇所の分離〈RNG call-site isolation〉」)や、辞書の索引をフィールドごとに分離して管理する仕組み(索引: FUNC-0919「フィールド別索引分離〈per-field index separation〉」)と、発想の根っこの部分で共通している——いずれも、大きな一つの領域として扱うのではなく、呼び出し元・管理単位を細かく分離しておくことで、ある一箇所の想定外の挙動が、他の箇所に無条件に波及しないようにする、という同じ設計原則を体現している。
### 検算的な小演習 — 区画を分けることで、届く範囲がどう変わるかを計算する
架空の設例として、400台のサーバーが一つの区画にまとめられた、区画分けの無いネットワークを考える(教材用の架空の数値)。もしこのネットワークで、区画をまたぐ通信が制限されていない状態のまま、ある1台のサーバーが想定外の状態になったとする。区画が無い以上、理論上は残り399台すべてに、区切りなく到達しうる経路が存在する。
ここで、同じ400台を、8つの区画に均等に分割し、区画をまたぐ通信を原則として制限する設計に変えたとする。
```
区画分け前: 到達しうる理論上の範囲 = 400台(区画が無いため、全体が一続き)
区画分け後(8区画・各50台):
1区画あたりの台数 = 400 ÷ 8 = 50台
ある区画内で何かが想定外の状態になった場合の理論上の到達範囲
= その区画の50台(他の7区画へは、制限された経路以外で到達しない)
400台に対する割合 = 50 ÷ 400 = 12.5%(検算成立)
```
区画を8つに分けるだけで、理論上の到達範囲は400台から50台へ、全体の12.5%にまで縮小する。この検算が示しているのは、区画分けそのものが、想定外の事態が起きた場合に「どこまで被害が広がりうるか」という理論上の範囲——**被害範囲(blast radius、水準四: ある区画で想定外の事態が起きた場合に、理論上どこまで影響が及びうるかの範囲)**——を、具体的に縮小させる効果を持つという事実である。
### この検算の限界を正直に述べる
ただし、この検算はあくまで「区画をまたぐ通信が完全に制限されている」という理想的な前提のもとでの理論上の上限にすぎない。実際の設計では、業務上どうしても必要な区画をまたぐ通信(たとえば管理用のアクセス経路)が残ることが多く、その経路の設計が甘ければ、理論上の被害範囲はこの計算よりも広がる。また、区画の分け方そのものが業務の実態に合っていなければ、区画を増やしても実質的な効果は薄い。「区画を分ければ絶対に被害が広がらない」という理解は誤りであり、区画分けは被害が広がる理論上の範囲とその確率を下げる設計であって、ゼロにする設計ではない、という正直な水準で理解しておく必要がある。
### すべての区画が必要とする、共有された仕組みへの例外
区画を細かく分けても、どうしても複数の区画すべてから到達できなければならない、共有された仕組みが残ることが多い。たとえば、名前から住所を引く仕組み(姉妹巻BOOK-0070・BOOK-0119ですでに定義済みのDNS)や、時刻を合わせる仕組みなどは、性質上、ほぼすべての区画から利用される。このような共有された仕組みを提供するサーバーは、区画分けの例外として、意図的に扱いに注意を払う必要がある——共有された仕組みが想定外の状態になれば、その影響は特定の区画に留まらず、それを利用するすべての区画に及びうるからである。姉妹巻BOOK-0360第四章の単一障害点という考え方が、ここでもそのまま当てはまる。共有された仕組みそのものを冗長化し、一箇所への依存を減らす設計は、姉妹巻BOOK-0366『可用性・信頼性工学(SRE)』の領分である。
### コラム — マイクロセグメンテーションのコストも正直に
区画を細かく分けるほど、被害範囲の理論上の上限は小さくなるが、同時に、区画をまたいで正当に必要な通信を許可するための規則の数も増えていく。この規則の数がどのように増えていくかという現実的なコストは、第十章で検算的に扱う。マイクロセグメンテーションは「細かければ細かいほど良い」という単純な話ではなく、業務上必要な通信の実態と、管理できる規則の複雑さとの、綱引きの中で設計される。
---
> **定着量の目安(第四章)**: 本章の検算の型(1区画あたりの台数 = 全体の台数 ÷ 区画数)を使い、自分で別の台数・区画数を仮に設定して、被害範囲の割合を計算してみる。あわせて、南北トラフィックと東西トラフィックという二つの言葉を、自分の言葉で説明できるようにしておく。
---
## 第五章: IDS/IPSの設計 — シグネチャ型とアノマリ型(水準五)
### 検問所を通過した後も、見張り続ける
第二章のファイアウォールは、通過の可否をその場で判定する検問所である。しかし検問所の判定基準に合致してしまえば、その通信は内部に入ってしまう。この先も見張り続ける仕組みが要る。ネットワークやホストの通信・挙動を監視し、不審な兆候を検知して通知する仕組みを、**IDS(侵入検知システム、Intrusion Detection System、水準五: ネットワークやホストの通信・挙動を監視し、不審な兆候を検知して通知する仕組み)**と呼ぶ。IDSの検知に加え、検知した不審な通信を自動的に遮断・防止する仕組みを、**IPS(侵入防止システム、Intrusion Prevention System、水準五: IDSの検知に加え、検知した不審な通信を自動的に遮断・防止する仕組み)**と呼ぶ。IDSが「異常に気づいて知らせる見張り」だとすれば、IPSは「異常に気づいたその場で通せんぼする見張り」だという違いがある。
### 二つの検知の仕方
不審な兆候をどう見分けるかについては、大きく分けて二つの方式がある。既知の攻撃パターンとの一致を照合して検知する方式を、**シグネチャ型検知(signature-based detection、水準五: 既知の攻撃パターンとの一致を照合して検知する方式)**と呼ぶ。あらかじめ登録された「このパターンに一致したら不審」という照合の仕組みは、辞書に載っている単語と入力を照合する仕組みに近い。シグネチャ型検知は、既知のパターンに対しては高い精度で検知できる一方、まだ登録されていない未知のパターンには気づけないという弱点を持つ。
もう一つの方式が、平時の通信の基準(ベースライン)からの逸脱を検知する方式である**アノマリ型検知(anomaly-based detection、水準五: 平時の通信の基準〈ベースライン〉からの逸脱を検知する方式)**である。アノマリ型検知は、「これが正常な状態だ」という基準をまず学習・設定し、そこから外れた通信を不審なものとして扱う。姉妹巻BOOK-0367第七章で扱った、ある指標がこの値を超えたら異常とみなすしきい値という考え方は、アノマリ型検知の最も基本的な形にほかならない——姉妹巻BOOK-0367が「平時から続く継続監視」の文脈で積み上げたしきい値という考え方を、本巻ではネットワークの防御という文脈に適用し、「正常な状態の基準」という意味を込めてベースラインと呼び直している、という関係にある。シグネチャ型検知が「知っている顔を見分ける」のに対し、アノマリ型検知は「いつもと違う様子に気づく」という違いを押さえておくとよい。
### 検知した後の選択肢 — 遮断するか、隔離するか
IPSが不審な兆候を検知した際の対応は、「その通信を遮断する」だけとは限らない。実務では、検知した端末そのものを、通常の区画から切り離し、限られた範囲の通信しか許されない特別な区画へ一時的に移す設計もよく使われる。この、検知対象を通常の環境から切り離し、限られた範囲でだけ動作させる発想は、本プロジェクトの関数辞書に索引されている、外部から隔離された環境の中でプログラムを実行する仕組み(索引: FUNC-1076「サンドボックス化〈sandboxing execution〉」)や、対象を読み取り専用の隔離された環境で実行し、周囲へ影響を及ぼさないことを保証する仕組み(索引: FUNC-0688「サンドボックス実行による対象コード非改変保証〈sandboxed read-only execution guarantee〉」)と、発想の根っこの部分で共通している——いずれも「疑わしい対象を、いきなり排除するのではなく、周囲への影響を遮断した狭い範囲に閉じ込めたうえで、落ち着いて確認する」という設計思想である。この「隔離」という選択肢は、第三章・第四章で積み上げたセグメンテーション・マイクロセグメンテーションの区画設計があって初めて実行可能になる——区画そのものが存在しなければ、「隔離用の区画へ移す」という対応そのものが選べない。
### 検知した後の記録
IDS/IPSが不審な兆候を検知した際の記録は、姉妹巻BOOK-0367第二章で扱った集中ログ管理の仕組みにそのまま乗る。権限の変更や重要な操作を、誰が・いつ・何の目的で行ったかに絞って記録する監査ログ(索引: FUNC-0399「監査ログ記録〈audit log〉」)は、IDS/IPSの検知記録にも同じ性質が求められる——検知した事実、その根拠、その後の対応の記録は、事件が起きた後にBOOK-0364『フォレンジクスとログ解析』がタイムラインを再構成する際の重要な材料になる。
### コラム — IDS/IPSは「見つけたものだけ」に反応する
IDS/IPSがどれだけ精巧であっても、シグネチャ型は登録されていないパターンに、アノマリ型は基準の設定が甘ければ、それぞれ気づけない事態が起こりうる。この限界は、姉妹巻BOOK-0367第十二章が扱った「既知の未知」と「未知の未知」という区別ともつながる話であり、本巻第十二章で改めて掘り下げる。IDS/IPSは強力な道具だが、「これさえ導入すればあらゆる不審な通信を見逃さない」という理解は誤りである。
---
> **定着量の目安(第五章)**: IDSとIPSの違いを、「知らせるだけ」か「その場で遮断するか」という観点で説明できるようにしておく。あわせて、シグネチャ型検知とアノマリ型検知が、それぞれどんな種類の不審さを見つけるのが得意で、どんな種類を見逃しやすいかを、自分の言葉で一行ずつ書き出してみる。
---
## 第六章: 三つの道具の関係 — ファイアウォール・セグメンテーション・IDS/IPSをどう組み合わせるか(水準六)
### それぞれ、防いでいる場所が違う
第二章から第五章まで、ファイアウォール・セグメンテーション・IDS/IPSという三つの道具立てを、それぞれ個別に見てきた。本章ではこれらを一本の視点でまとめ直す。ファイアウォールは主に境界(南北トラフィック)で通過の可否を判定する検問所、セグメンテーション・マイクロセグメンテーションは内部(東西トラフィック)を区画に分けて被害範囲を絞る仕切り、IDS/IPSはその両方を通過した通信を見張り続ける監視役、という役割分担になる。姉妹巻BOOK-0360第四章の多層防御を、ネットワークという具体的な領域に落とし込むと、この三つの道具立てが層として重なる姿になる。
### 検算的な小演習 — 層を重ねることの理論上の効果を確かめる
架空の設例として、ある想定外の通信が、この三つの層をすべてすり抜けてしまう理論上の確率を考えてみる(教材用の架空の数値であり、実測値ではない)。ファイアウォールが、ある種の想定外の通信を検知・遮断する割合を仮に95%(すり抜ける割合5%)、セグメンテーションの境界がさらに検知・制限する割合を仮に90%(すり抜ける割合10%)、IDS/IPSがさらに検知する割合を仮に80%(すり抜ける割合20%)と置く。
もしこの三層が、互いに完全に独立して働くと仮定すれば、三層すべてをすり抜けてしまう理論上の割合は、次のように概算できる。
```
すり抜け割合(三層独立と仮定) = 0.05 × 0.10 × 0.20 = 0.001 = 0.1%(検算成立)
ファイアウォール一層だけに頼った場合のすり抜け割合 = 5%
0.1% ÷ 5% = 0.02(=1/50。層を重ねることで、理論上のすり抜け割合は50分の1に縮む)
```
この検算が示しているのは、境界一枚だけに頼っていれば5%だった理論上のすり抜け割合が、三層を重ねることで理論上0.1%まで縮む、という掛け算の効果である。これは、第一章で見た「境界一枚では守れない」という直感を、数字の上でも裏付けている。
### この検算の限界を、特に強く正直に述べる
この検算には、見過ごしてはならない前提がある。それは「三層が互いに完全に独立している」という仮定である。実際には、三層が同じ設計者・同じ運用チームによって構築されることが多く、ある一つの見落としが複数の層に共通して存在してしまう(いわゆる「共通の盲点」)場合、層は見かけ上は三つでも、実質的には独立していない。その場合、実際のすり抜け割合は、この0.1%という数字よりもずっと高くなりうる。加えて、この95%・90%・80%という数字自体、教材用に仮に置いた架空の値であり、実在の製品や構成の性能を保証するものではない。**多層防御は、想定外の通信が内部まで届いてしまう理論上の割合とコストを下げるが、ゼロにする保証ではない**——この一文は、本巻を通じて繰り返し立ち返るべき、最も重要な正直さである。
### コラム — 三つの道具を、バラバラに運用してはいけない
ファイアウォールの規則、セグメンテーションの区画設計、IDS/IPSの検知基準を、それぞれ別々の担当者が、互いに連携のないまま個別に設定してしまうと、ある区画への到達経路が、ファイアウォールの規則上は許可されているのにセグメンテーションの設計では想定されていない、といった食い違いが生まれやすい。三つの道具は、それぞれ独立した技術でありながら、同じネットワーク構成図の上で整合させて初めて、本章で見た層の重なりが機能する、という点を強調しておきたい。
---
> **定着量の目安(第六章)**: 本章の検算の型(すり抜け割合 = 各層のすり抜け割合の掛け算)を使い、自分で別の割合を仮に設定して、層を重ねることの理論上の効果を計算してみる。あわせて、「三層が独立している」という仮定がなぜ現実には崩れやすいかを、自分の言葉で説明できるようにしておく。
---
## 第七章: ゼロトラストアーキテクチャの構成要素 — ポリシー決定点と実施点(水準七)
### 「社内にいるから安全」を、ネットワークの側からも手放す
姉妹巻BOOK-0361第十章は、所在地(社内か社外か)だけで信頼を判断せず、すべてのアクセスをその都度検証するという設計思想を、**ゼロトラスト**と定義した。本巻ではこの定義をそのまま引き継ぐ。姉妹巻BOOK-0361第十章が主に認証・認可の視点からこの設計思想を掘り下げたのに対し、本巻ではネットワークアーキテクチャの視点から、この設計思想をどう実装するかを扱う。
第一章から第六章まで見てきたセグメンテーション・マイクロセグメンテーションは、区画を細かく分けることで被害範囲を絞る設計だったが、まだ「一度区画に入ってしまえば、その区画の中では信頼される」という前提が残っている。ゼロトラストアーキテクチャは、この前提そのものに踏み込み、区画の内外を問わず、通信ごとに検証を求める設計へと歩みを進める。
### 決める役と、実行する役を分ける
ゼロトラストアーキテクチャをネットワークの構成要素として実装する際、中心になるのが、あるアクセスを許可するかどうかを判断する役割と、その判断を実際に強制する役割とを、明確に分けて設計するという発想である。あるアクセス要求に対して、あらかじめ定めた方針(ポリシー)に照らして許可・拒否を判断する構成要素を、**ポリシー決定点(Policy Decision Point、PDP、水準七: あるアクセス要求に対して、あらかじめ定めた方針に照らして許可・拒否を判断する構成要素)**と呼ぶ。PDPが下した判断を、実際の通信の経路上で強制的に実行する構成要素を、**ポリシー実施点(Policy Enforcement Point、PEP、水準七: PDPが下した判断を、実際の通信の経路上で強制的に実行する構成要素)**と呼ぶ。
この「決める役」と「実行する役」を分けるという設計は、本プロジェクトの関数辞書に索引されている、検定を行う側と実装する側を独立させる仕組み(索引: FUNC-1100「検定の鍵分離〈test oracle separation from implementation〉」)と、発想の根っこの部分で深く共通している——どちらも「判断する主体」と「その判断に従って動く主体」を、同じ場所・同じ権限に固定せず独立させておくことで、判断そのものが実行側の都合で書き換えられてしまう危うさを避ける、という同じ設計原則を体現している。もしPDPとPEPが未分離のまま一体化していれば、ある通信経路の実装そのものが、自分自身の可否を自分で判定してしまう——これは、検定する側と実装する側が同一であってはならないという、検定文化の根本原則がネットワークアーキテクチャに姿を変えたものだと理解できる。
### あらゆる通信の要求元・要求先を細分化する
ゼロトラストアーキテクチャでは、区画そのものを、従来のセグメンテーションよりもさらに動的かつ細かい単位——理想的には、通信を要求する一つ一つの主体(利用者・端末・サービス)ごと——で扱う考え方が広がっている。この、ゼロトラストの文脈で使われる、通信の主体ごとに動的に定義される最小単位の防御範囲を、**マイクロペリメタ(micro-perimeter、水準七: ゼロトラストの文脈で、通信の主体ごとに動的に定義される最小単位の防御範囲)**と呼ぶ。第四章のマイクロセグメンテーションが「サーバー単位」で区画を細分化したのに対し、マイクロペリメタは、さらに「その通信を要求している主体が誰で、どんな状態か」までを条件に含める、という違いがある。
### コラム — ゼロトラストは「境界を無くす」ことではない
ゼロトラストという言葉から、「境界という考え方そのものを捨てる」という誤解が生まれることがあるが、これは正確ではない。ゼロトラストが手放すのは「一度その境界の内側に入れば、以後は信頼する」という近道であって、境界という区切りそのものを撤去するわけではない。むしろゼロトラストは、境界をマイクロペリメタという単位まで細分化し、その一つ一つの境界で毎回検証を行う、という意味では、境界という考え方をより徹底させた設計だと理解するほうが正確である。
---
> **定着量の目安(第七章)**: ポリシー決定点(PDP)とポリシー実施点(PEP)が、それぞれ何を担っているかを、自分の言葉で説明できるようにしておく。あわせて、この分離が、検定の鍵分離(FUNC-1100)という考え方とどう似ているかを、自分の言葉で説明してみるとよい。
---
## 第八章: ソフトウェア定義境界とネットワークレベルの継続的検証(水準八)
### 認証されるまで、存在すら見せない
姉妹巻BOOK-0361第十章は、一度の認証で信頼を固定せず、セッションの継続中も利用者やデバイスの状態をその都度確認し続ける設計を、**継続的検証**と定義した。この考え方を、ネットワークの構成そのものに落とし込んだ設計が、ネットワークの構成を、物理的な配線ではなくソフトウェアによる制御で動的に定義し、認可されていない接続元からはネットワークの存在そのものを見えなくする設計である**ソフトウェア定義境界(Software-Defined Perimeter、SDP、水準八: ネットワークの構成を、物理的な配線ではなくソフトウェアによる制御で動的に定義し、認可されていない接続元からはネットワークの存在そのものを見えなくする設計)**である。
従来のDMZ(第三章)は、外部に公開するサーバーの存在自体は外部から見える設計だった。これに対しSDPは、第七章のPDP・PEPによる検証を先に済ませた接続元にだけ、必要な範囲のネットワーク経路を動的に開いて見せる、という順序を取る。認可されていない接続元からは、そもそも接続先が「そこに存在する」ことすら分からない、という設計思想は、境界を「通過を判定する検問所」から「そもそも見えない扉」へと一段引き上げたものだと理解できる。
### 一度きりの確認で終わらせない
SDPやゼロトラストアーキテクチャの実装においては、経路が一度開いたあとも、その状態を固定せず、定期的に、あるいは条件が変わるたびに、あらためて検証をやり直す設計が広く使われる。この「一度確認して終わりにせず、独立にもう一度確かめ直す」という発想は、本プロジェクトの関数辞書に索引されている、ある結果を独立した別の手段で再度実行し、一致するかどうかを確かめる仕組み(索引: FUNC-0774「独立再実行検証〈independent re-execution verification〉」)と、発想の根っこの部分で共通している——どちらも、一度の確認結果を無条件に信頼し続けるのではなく、独立した手段・タイミングで確認をやり直すことによって、確認そのものの信頼性を保ち続けるという設計思想である。
### コラム — SDP/ゼロトラストも「二度と破られない壁」ではない
第六章で確認したとおり、多層防御は理論上のすり抜け割合を下げるが、ゼロにする保証ではない。SDPやゼロトラストアーキテクチャについても、まったく同じ正直さが求められる。PDP・PEPの判断ロジック自体に想定外の欠陥があれば、そこを起点に想定外の状態が起こりうる可能性は理論上残る。「ゼロトラストを導入すれば、もはや境界という考え方は不要になる」という理解は誤りであり、ゼロトラストは境界という考え方を捨てる設計ではなく、境界を極限まで細分化し、検証をその都度やり直し続ける設計である、という第七章のコラムの整理を、ここでも繰り返しておきたい。
---
> **定着量の目安(第八章)**: ソフトウェア定義境界(SDP)が、従来のDMZ(第三章)とどう違うかを、「存在が見えるかどうか」という観点で説明できるようにしておく。あわせて、独立再実行検証(FUNC-0774)という考え方が、なぜ「一度きりの認証で終わらせない」というゼロトラストの発想と結びつくのかを、自分の言葉で説明してみる。
---
## 第九章: 負荷そのものへの防御的な備え — レート制限とタイムアウト(水準九)
### 個々の通信の正当性とは別に、量そのものを制御する
ここまでの章では、「この通信は許可された相手からのものか」という正当性の判定を中心に見てきた。しかし、たとえ一つ一つの通信が正規の形式に見えても、その量が想定を大きく超えて集中すれば、システムが処理しきれなくなり、可用性が損なわれる場合がある。この課題への、防御的な備えの一つが、一定時間内に許容する処理の回数に上限を設ける仕組み(索引: FUNC-0255「レート制限〈rate limiting〉」)である。レート制限は、姉妹巻BOOK-0367第七章でも、しきい値を用いたアラートの代表例として触れられているが、本巻ではこれを、ネットワークの境界(第一章〜第二章)やAPIの入口に置く、防御的な負荷制御の仕組みとして位置づける。
処理の速度そのものを一定の上限以下に抑える仕組み(索引: FUNC-0254「スロットル〈throttle〉」)も、同じ系統の考え方である。レート制限が「一定時間あたりの回数」に上限を設けるのに対し、スロットルは処理の速度そのものを絞る、という違いがあるが、いずれも「集中した負荷が、システム全体を押し流してしまわないよう、あらかじめ流量を制御しておく」という、防御的な設計思想を共有している。
### 応答が返らない相手を、待ち続けない
想定外に応答が返ってこない通信先を、いつまでも待ち続けてしまうと、待っている側の資源(接続の枠など)が徐々に消費され尽くしてしまう。指定した時間を超えたら処理を打ち切る仕組み(索引: FUNC-0297「タイムアウト付き実行〈timeout wrapper〉」)は、この課題への基本的な備えである。姉妹巻BOOK-0367第七章では、タイムアウトをヘルスチェック(サービスが生きているかを確認する処理)への応用として扱ったが、本巻ではこれを、境界を越える通信そのものが、想定外に長く居座り続けることを防ぐ、防御的な資源管理の仕組みとして位置づける。
処理が失敗するたびに、再試行までの待ち時間を段階的に引き延ばす仕組み(索引: FUNC-0294「指数バックオフ〈exponential backoff〉」)や、処理が失敗するたびに再試行までの待ち時間を調整する仕組み(索引: FUNC-0384「リトライ〈retry with backoff〉」)も、負荷制御と関係が深い。正当な利用者が一時的な混雑によって接続に失敗した場合でも、すぐに何度も再接続を試みるのではなく、段階的に間隔を空けて再試行する設計にしておけば、混雑そのものをさらに悪化させることを避けられる。
### どこに置くか — 境界の外縁と、個々のサービスの前
レート制限やタイムアウトをどこに配置するかも、設計上の重要な判断である。組織のネットワーク全体の入口という、最も外側の一点に置く配置を**エッジ(edge、水準九: ネットワーク全体の入口という、最も外側の一点)**と呼び、個々のサービス・APIのすぐ手前に置く配置を**オリジン側(origin、水準九: 個々のサービス・APIのすぐ手前という配置)**と呼ぶことがある。エッジに置けば、想定を超える負荷が内部の奥深くまで進む前に一括して制御できるが、サービスごとに必要な制限の細かさが異なる場合には、オリジン側にも個別の制限を重ねて置くことが多い。この「外側で大まかに絞り、内側でさらに個別に絞る」という配置は、第四章のマイクロセグメンテーションが「区画を外周から内部へと段階的に細分化していく」のと同じ発想の繰り返しである。
### レート制限・タイムアウト・バックオフの位置づけを、正直に述べる
これらの仕組みは、想定を超える通信の集中がシステム全体を押し流してしまうことを防ぐための、防御的な負荷制御であって、第一章から第八章までで見た「通信の正当性そのものを判定する」仕組み(ファイアウォール・IDS/IPS・ゼロトラストアーキテクチャ)とは、防いでいる種類の課題が異なる。姉妹巻BOOK-0366『可用性・信頼性工学(SRE)』が扱う冗長化・段階的縮退の設計とも接続する話であり、正当性の判定と負荷の制御という二つの防御軸を、両方とも備えておく必要がある、という理解が本章の要点である。
### コラム — レート制限は「境界」の外でも「内」でも使われる
レート制限やタイムアウトは、第一章から第八章で見た「外部との境界」だけに置かれる仕組みではない。第四章のマイクロセグメンテーション・第七章のマイクロペリメタが実装するような、内部の区画同士の通信に対しても、同じ発想の負荷制御が適用されることがある。「境界の外側だけを警戒すればよい」という考え方ではなく、区画の内側であっても、想定を超える負荷の集中には備えておく、という姿勢が、本巻を通じて積み上げてきた多層防御の考え方と一貫している。
---
> **定着量の目安(第九章)**: レート制限・スロットル・タイムアウト・指数バックオフという四つの言葉が、それぞれどんな種類の負荷の課題に応えているかを、自分の言葉で一行ずつ整理してみる。あわせて、「通信の正当性を判定する仕組み」と「負荷そのものを制御する仕組み」が、なぜ別々に備えるべき、異なる防御軸なのかを説明できるようにしておく。
---
## 第十章: 検算 — 区画を増やすことの現実的なコスト(水準十)
### 区画同士を、すべてつなぎたくなる誘惑
第四章で見たとおり、区画を増やすほど、理論上の被害範囲は縮小する。しかし実務では、区画をいくつ用意するかを決める際、もう一つの現実的な制約——区画同士の間で、業務上必要な通信を許可する規則を、いったいいくつ書かなければならないか——を無視できない。
### 検算的な小演習 — 規則の数が、区画数の増加とともにどう増えるかを計算する
架空の設例として、N個の区画があり、業務上の必要に応じて、すべての区画の組(ペア)ごとに、個別の許可規則を用意する設計(全区画総当たり方式)を考える。この場合に必要な規則の数は、次の式で計算できる。
```
全区画総当たり方式での規則数 = N × (N − 1) ÷ 2
N = 10区画のとき: 10 × 9 ÷ 2 = 45規則
N = 20区画のとき: 20 × 19 ÷ 2 = 190規則(検算成立)
区画数が10から20へ2倍になっただけで、規則数は45から190へ、
約4.2倍に増える(区画数の2乗に近い勢いで増える)。
```
この検算が示しているのは、区画同士を総当たりでつなごうとすると、規則の数は区画数が増えるにつれて、単純な比例よりもずっと急な勢いで増えていく、という事実である。姉妹巻BOOK-0367第十章が扱ったカーディナリティ爆発(ラベルの組み合わせ数が掛け算的に増える現象)と、根っこの部分で同じ「組み合わせの数は、要素を増やすと急増する」という構造がここにも表れている。
### 増やし方を変えると、増え方も変わる
この急増を避けるため、実務では、すべての区画を直接つなぐのではなく、通信を一つの中継点(ハブ)経由に絞る設計がよく使われる。各区画がハブとだけ通信し、区画同士は直接つながない構成では、必要な規則の数は次のようになる。
```
ハブ経由方式での規則数 = N(各区画とハブとの間の規則が1本ずつ)
N = 20区画のとき: 20規則(全区画総当たり方式の190規則の、約10分の1)
```
区画数が同じ20個であっても、つなぎ方の設計次第で、必要な規則の数は190から20へと大きく変わる。この検算は、第四章・第七章で見た「区画を細かくするほど良い」という考え方に、もう一つの現実的な視点——「区画をどうつなぐ設計にするかが、管理できる複雑さを大きく左右する」——を付け加えるものである。
### 規則は、作った時点で終わりではない
区画設計と規則は、一度作って終わりにできるものではない。業務の変化にあわせて、新しい区画が増え、既存の規則の一部は使われなくなっていく。使われなくなった規則が放置されたまま蓄積していく状態を、**規則の陳腐化(きそくのちんぷか、rule sprawl、水準十: 使われなくなった規則が放置されたまま蓄積していく状態)**と呼ぶ。陳腐化した規則は、それ自体が想定外に広い通信経路を許してしまっている可能性があり、しかも規則の数が多いほど、どれが今も必要でどれが不要かを人手で判別することが難しくなる。この課題への備えとして、規則を定期的に棚卸しし、実際の通信実績と照らし合わせて、使われていない規則を洗い出す運用が実務では推奨される。
### この検算の限界を正直に述べる
この検算は、規則の数という一つの指標だけに着目した単純化であり、実際の設計では、ハブ経由方式にすることで生じる別の課題(ハブそのものが新たな単一障害点になりうるという、姉妹巻BOOK-0360第四章の教訓が、ここでも形を変えて現れる)も同時に検討しなければならない。規則の数を機械的に検査し、想定した区画設計と実際の規則が食い違っていないかを確かめる作業は、本プロジェクトの関数辞書に索引されている、資産の生成・消費の帳尻が想定どおりに一致しているかを機械的に検査する仕組み(索引: FUNC-0769「保存則検査〈conservation law check〉」)や、複数の値を束ねて一つの総量として扱う仕組み(索引: FUNC-0662「資源保存則検証〈resource conservation invariant check〉」)と、「部分の積み上げが、想定した全体の姿と食い違っていないかを検算する」という発想において共通している——区画設計もまた、机上の図面のまま放置せず、実際に設定された規則の数・中身を定期的に検算し直す実務が求められる。
---
> **定着量の目安(第十章)**: 本章の検算の型(全区画総当たり方式の規則数 = N×(N−1)÷2)を使い、自分で区画数を仮に設定して規則数を計算してみる。あわせて、ハブ経由方式に変えると規則数がどう変わるかも計算し、二つの方式の違いを自分の言葉で説明できるようにしておく。
---
## 第十一章: 現代最先端 — クラウド時代のネットワーク防御とSASE(水準十一)
### 建物の壁の中に、もはや収まらない
第一章で見た境界防御は、「組織のネットワークは、物理的な建物・配線の中に収まっている」という前提のもとで、最も自然に機能する設計だった。しかし、クラウドサービスの利用や在宅勤務が広がった現代では、業務で使われるサーバーやサービスの多くが、もはや組織の建物の中にはない。利用者も、社内の机からだけでなく、自宅や外出先からアクセスする。この変化は、姉妹巻BOOK-0361第十章がゼロトラストの広まりの背景として述べた変化と、まったく同じものである。
### 防御機能を、クラウド側にまとめて提供する
この変化への現代的な応答として登場したのが、ネットワークセキュリティ機能(第一章〜第九章で見たファイアウォール・第七章〜第八章で見たゼロトラストアーキテクチャの実装など)と、ネットワークへの接続機能とを、クラウド上で統合して提供するアーキテクチャの総称——**SASE(サシー、Secure Access Service Edge、水準十一: ネットワークセキュリティ機能とネットワークへの接続機能とを、クラウド上で統合して提供するアーキテクチャの総称)**である。SASEという言葉は、大手調査会社の複数のアナリストによって2019年ごろに提唱されたとされる。
SASEが目指すのは、組織の建物の中に物理的な機器を置いて防御を組み立てるのではなく、利用者や拠点が、どこからアクセスしていても、クラウド上の同じ防御機能を経由してから、目的のサービスへとつながるようにする構成である。この構成では、第七章・第八章で見たゼロトラストアーキテクチャの考え方——通信ごとにPDPで判断し、PEPで実施する——が、クラウド上のサービスとして提供される。この、ゼロトラストの考え方をネットワークへのアクセス制御として実装したものを指して、**ZTNA(Zero Trust Network Access、水準十一: ゼロトラストの考え方を、ネットワークへのアクセス制御として実装した仕組み)**と呼ぶことがある。
### SASEを構成する代表的な機能
SASEという言葉は、単一の製品を指すのではなく、複数の機能を束ねた総称である。代表的な構成要素として、利用者がインターネット上のウェブサイトへアクセスする際の通信を検査する、クラウド上に置かれた中継点である**SWG(Secure Web Gateway、水準十一: 利用者がインターネット上のウェブサイトへアクセスする際の通信を検査する、クラウド上に置かれた中継点)**、組織が利用するクラウドサービスの利用状況を可視化し、その利用に対して組織のポリシーを適用する仕組みである**CASB(Cloud Access Security Broker、水準十一: 組織が利用するクラウドサービスの利用状況を可視化し、その利用に対して組織のポリシーを適用する仕組み)**、そして第二章で見たファイアウォールの機能を、専用の物理機器ではなくクラウド上のサービスとして提供する形態である**FWaaS(Firewall as a Service、水準十一: 第二章のファイアウォールの機能を、専用の物理機器ではなくクラウド上のサービスとして提供する形態)**などが挙げられる。SASEは、これらの機能と、第七章・第八章で見たZTNAとを、一つの統合されたクラウド上の基盤としてまとめて提供する、という位置づけになる。
### コラム — 標準化は「最終形態」ではない
SASEやZTNAが現時点で広く採用が進んでいる考え方であることは事実だが、これが最終形態であると請け合うことはできない。姉妹巻BOOK-0367第十一章のコラムでも述べられているとおり、技術の標準化そのものが、新しい利用形態が広まるたびに、新しい要求に応じて見直され続けていく、継続的な工程である。ネットワーク防御という領域も、この例外ではない。
---
> **定着量の目安(第十一章)**: SASEとZTNAという二つの言葉を、それぞれ自分の言葉で一行ずつ説明できるようにしておく。あわせて、なぜクラウドサービスの利用や在宅勤務の広まりが、境界防御(第一章)からSASE/ゼロトラストへの移行を後押ししたのかを、具体的な理由とともに説明できるかを確認しておくとよい。
---
## 第十二章: 達人術 — なぜ境界防御からゼロトラストへのパラダイム転換が起きたのか(水準十二)
### 「城壁一枚」という前提を、あらためて振り返る
第一章で見た境界防御という発想には、一つの隠れた前提があった。それは、「組織のネットワークの範囲を、あらかじめ明確に線引きできる」という前提である。城壁を築くには、まず城の輪郭がはっきりしていなければならない。20世紀後半から21世紀初頭にかけての多くの組織にとって、この前提は現実におおむね成り立っていた——社員は社内の建物で働き、サーバーは社内のデータセンターに置かれ、ネットワークの境界は、物理的な配線と建物の壁におおむね一致していた。
### 前提が崩れていった過程
しかし、この前提は、いくつもの変化が積み重なる中で、徐々に崩れていった。クラウドサービスの利用が広がり、業務で使うサーバーの多くが、もはや組織の建物の中にはなくなった(第十一章)。在宅勤務やモバイル端末からのアクセスが広がり、利用者も、もはや社内の机の前にだけいるとは限らなくなった。取引先や外部の協力者が、組織の内部システムに直接アクセスする場面も増えた。これらの変化が積み重なった結果、「ネットワークの境界を、線一本ではっきりと描く」ということ自体が、現実的に難しくなっていった。境界が消えたのではなく、境界が「どこか一箇所」ではなく「あらゆる通信の一つ一つ」に分散していった、と理解するほうが正確である。
この変化を見据え、所在地だけで信頼を判断しないという設計思想に、**ゼロトラスト**という名前を与え、業界に広めるうえで大きな役割を果たしたのが、大手調査会社の分析者**ジョン・キンダーバーグ(John Kindervag)**であり、2010年前後にこの考え方が広まり始めたとされる(姉妹巻BOOK-0361の階段図「現在のフロンティア」でも同時期として言及されている)。その後、この設計思想をアーキテクチャとして体系立てて整理した公的な指針として、米国国立標準技術研究所(NIST)による文書*Zero Trust Architecture*(NIST SP 800-207)が、2020年ごろに公開されたとされる。この文書が、本巻第七章で扱ったポリシー決定点・ポリシー実施点という構成要素の整理に、大きな影響を与えたとされている。
### 一本のメタなパターンとして振り返る
本巻を通じて見てきた技術の推移を、一段抽象化して振り返ると、姉妹巻BOOK-0361第十二章・BOOK-0367第十二章と共通する、ある一つのパターンが浮かび上がる。**単純な仕組みが先に生まれ、その限界が明らかになるたびに、より広い範囲を扱える仕組みへと発展してきた**、というパターンである。境界に一枚の壁を置くだけの境界防御(第一章・第二章)から、内部を区画に分けるセグメンテーション(第三章)、区画をさらに細かくするマイクロセグメンテーション(第四章)へと進み、それでもなお「区画の中では信頼する」という前提が残っていた限界に応えて、通信そのものを主体単位で検証し続けるゼロトラストアーキテクチャ(第七章・第八章)という、より大きな設計思想への転換が起きた。この「単純な道具→道具を増やして補う→道具の集まりを支える設計思想そのものへ転換する」という流れは、情報防衛と復旧シリーズ全体を貫くメタ的な構造である。
### まだ終わっていない推移
正直に述べておかなければならないのは、ゼロトラストという考え方もまた、「最終形態」だと請け合うことはできないという点である。第十一章で見たSASE/ZTNAのような現在の到達点も、クラウドやAIエージェントのような新しい利用形態が広がるにつれて、これからも見直され続けていくと考えられる。「境界一枚で守る境界防御」から「境界を細分化し、その都度検証するゼロトラスト」への転換そのものが、まだ推移の途中にある、という謙虚さを持ち続けることが、本巻から持ち帰ってほしい、達人術としての最後の視点である。
### 本巻から次巻への橋渡し
本巻では、境界の設計という、予防の一部を扱ってきた。しかし第六章・第八章で繰り返し確認したとおり、どれだけ層を重ねた防御も、想定外の事態が起きる理論上の可能性をゼロにはしない。本巻の防御が実際に破られた——あるいは破られた疑いが生じた——その先には、姉妹巻BOOK-0363『インシデント対応の一本道』の、封じ込め・根絶・復旧・教訓という一本道が続いている。本巻で積み上げたセグメンテーション・ゼロトラストアーキテクチャ・IDS/IPSという設計は、その一本道が始まる前の、最初の備えを支える巻である。
---
> **定着量の目安(第十二章)**: 「境界防御」と「ゼロトラスト」の違いを、「境界を線一本で引く」「境界を通信ごとに細分化する」という二つの言葉を使って、自分の言葉で説明できるようにしておく。あわせて、本巻を通じて見てきた技術の推移(境界防御→セグメンテーション→マイクロセグメンテーション→ゼロトラストという設計思想そのものへの転換)を、白紙に時系列順で書き出し、それぞれが「直前のどんな限界への応答だったか」を一行ずつ説明できるかを試してみる。
---
## 四つの実践解 — 特別な道具を使わない、安全な実践
理論を、実際に手を動かして確かめる方法を四つ紹介する。いずれも実在システムへの侵入や特別なネットワーク機器を必要とせず、自分自身の身の回りにあるものと、紙とペンだけで完結する、安全な実践解である。
1. **間取り区画分け実践**: 自分の自宅やよく知っている建物(学校・職場など)の間取り図を紙に描き、「玄関の鍵(境界防御・第一章)」「各部屋の鍵の有無(セグメンテーション・第三章)」「各部屋の中のさらに細かい収納の鍵(マイクロセグメンテーション・第四章)」がそれぞれどこにあるかを書き込んでみる。鍵が玄関にしか無ければ、それは「境界防御一枚」の状態そのものである。
2. **被害範囲の暗算実践**: 第四章の検算の型(1区画あたりの台数 = 全体の台数 ÷ 区画数)を使い、自分の身の回りにある集団(クラスの人数、職場の部署の人数など)を、いくつかのグループに仮に分けたとき、一つのグループの人数が全体の何パーセントになるかを計算してみる。区画を増やすほど、この割合がどう小さくなるかを自分の手で確認できれば、被害範囲という概念が実感として定着する。
3. **毎回確かめる実践**: 自分が普段利用しているサービス(宅配便の受け取り、マンションのオートロックなど)で、「顔なじみだから」「いつもの人だから」と確認を省略される場面と、毎回きちんと確認が行われる場面をそれぞれ書き出してみる(第七章・第八章)。確認を省略される場面がどこにあるかに気づければ、ゼロトラストがなぜ「毎回検証する」ことにこだわるのかが、身近な体験と結びついて理解しやすくなる。
4. **規則の数え上げ実践**: 第十章の検算の型(N × (N − 1) ÷ 2)を使い、自分の身の回りにある小さな集団(友人グループ、部活のメンバーなど)の人数をNとして、「全員が互いに直接連絡を取り合う」場合の連絡経路の数と、「一人の連絡係(ハブ)を通す」場合の連絡経路の数を、それぞれ計算して比べてみる。人数が増えるほど、二つの数え方の差がどれだけ開くかを確認できれば、区画の増やし方が設計に与える影響が、具体的な感覚として身につく。
---
## まとめ — 境界防御から、ゼロトラストアーキテクチャまで
本巻では、「一つの扉が、すべての部屋につながっていた」という入口の物語から出発し、境界防御の限界と姉妹巻BOOK-0360の信頼境界・多層防御・単一障害点との接続(第一章)、パケットフィルタリング・ステートフルインスペクションというファイアウォールの設計思想(第二章)、VLAN・サブネット・DMZによるセグメンテーションの基礎(第三章)、南北トラフィックと東西トラフィックの区別と被害範囲を絞るマイクロセグメンテーション(第四章)、シグネチャ型とアノマリ型というIDS/IPSの二つの検知方式(第五章)、ファイアウォール・セグメンテーション・IDS/IPSという三つの道具の層としての組み合わせ(第六章)、姉妹巻BOOK-0361のゼロトラストをポリシー決定点・ポリシー実施点として実装する設計(第七章)、ソフトウェア定義境界とネットワークレベルの継続的検証(第八章)、レート制限・タイムアウトによる負荷そのものへの防御的な備え(第九章)、区画を増やすことの現実的な規則数のコスト(第十章)、クラウド時代のSASE/ZTNA(第十一章)までをたどり、最後に、なぜ「境界防御」という古い設計思想が「ゼロトラスト」という新しい設計思想へと発展してきたのかという、メタ的な推移を見た(第十二章)。
この一冊で積み上げた言葉は、情報防衛と復旧シリーズ全体における**予防**を担っている。本巻が設計するセグメンテーション・ゼロトラストアーキテクチャ・IDS/IPSは、姉妹巻BOOK-0367が担う検知の前提の土台の一部でもあり、これらの防御が実際に破られた瞬間から、姉妹巻BOOK-0363『インシデント対応の一本道』の封じ込め・根絶・復旧・教訓という一本道が始まる。「一日停止・全システム再構成の段階判断」という特命業務全体の中で、本巻は「境界をどう作り直せば、破られたときの被害を小さく留められるか」という、予防の設計を支える巻である。
---
## 章末: 簡易階段図
```
[水準十二] 達人術・なぜ境界防御からゼロトラストへのパラダイム転換が起きたのか
John Kindervag 2010年前後、NIST SP 800-207 2020年ごろとされる(第十二章)
▲
│ 単純な道具→道具を増やして補う→設計思想そのものへ転換する
[水準十一] 現代最先端: クラウド時代のネットワーク防御とSASE
SASE 2019年ごろ提唱とされる、ZTNAというゼロトラストの実装(第十一章)
▲
│ 組織の境界が、建物の壁の中に収まらなくなった
[水準十] 検算: 区画を増やすことの現実的なコスト
全区画総当たり10区画45規則→20区画190規則、ハブ経由なら20規則(検算・第十章)
▲
│ 区画を細かくするほど、管理する規則の数も増える
[水準九] 負荷そのものへの防御的な備え: レート制限とタイムアウト
FUNC-0255・FUNC-0254・FUNC-0297・FUNC-0294・FUNC-0384(第九章)
▲
│ 正当な通信でも、量が集中すれば可用性を損なう
[水準八] ソフトウェア定義境界とネットワークレベルの継続的検証
認証前は存在を見せない設計、独立再実行検証(FUNC-0774)(第八章)
▲
│ 一度の確認で終わらせず、その都度確かめ直す
[水準七] ゼロトラストアーキテクチャの構成要素: PDPとPEP
検定の鍵分離(FUNC-1100)と同じ「決める役/実行する役」の分離(第七章)
▲
│ 「社内にいるから安全」という前提を、ネットワークの側からも手放す
[水準六] 三つの道具の関係: FW・セグメンテーション・IDS/IPS
三層独立と仮定すればすり抜け率5%→0.1%(検算・独立性の仮定に強い限界あり・第六章)
▲
│ それぞれ防いでいる場所が違うので、層として重ねる
[水準五] IDS/IPSの設計: シグネチャ型とアノマリ型
「知っている顔を見分ける」/「いつもと違う様子に気づく」(第五章)
▲
│ 検問所を通過した後も、見張り続ける必要がある
[水準四] マイクロセグメンテーション: 内部をどこまで細かく区切るか
400台8区画で被害範囲400→50、12.5%に縮小(検算・第四章)
▲
│ 区画の中でも、被害はさらに絞り込める
[水準三] セグメンテーションの基礎: VLAN・サブネット・DMZ
ゾーン管理(FUNC-0609)・公開/非公開の分離(FUNC-0612)(第三章)
▲
│ 内部にも区切りが要る
[水準二] ファイアウォールの設計思想: パケットフィルタリングとステートフルインスペクション
「宛名だけ見る検問」→「文脈を覚える検問」→「中身も見る検問」(第二章)
▲
│ 境界に、まず検問所を置く
[水準一] 境界だけでは守れない: 境界防御の限界
信頼境界(BOOK-0360第七章)を、境界一枚だけに頼ると単一障害点になる(第一章)
横の広がり:
[水準四] 南北トラフィック(境界を越える通信) ←(対概念)→ 東西トラフィック(内部同士の通信・第四章)
[水準五] シグネチャ型検知(既知パターン照合) ←→ アノマリ型検知(ベースラインからの逸脱・第五章)
現在のフロンティア(第十一章・第十二章):
2010年前後 ゼロトラストという考え方がJohn Kindervagらにより広められ始めたとされる
2019年ごろ SASEという言葉が大手調査会社のアナリストにより提唱されたとされる
2020年ごろ NIST SP 800-207『Zero Trust Architecture』が公開されたとされる
※本巻で扱ったセグメンテーション・ファイアウォール・IDS/IPS・ゼロトラストという考え方は、
現在もなお、クラウドと分散化の進展にあわせて実務の最前線で更新され続けている、現役の設計原理である。
次の冊子(BOOK-0363『インシデント対応の一本道』・判定→対応の背骨):
本巻が設計したセグメンテーション・ゼロトラストアーキテクチャ・IDS/IPSが実際に破られた
その先で、封じ込め→根絶→復旧→教訓という一本道が始まる ─────▶
```
---
## 参照文献(定番教科書・公的規格・原著)
1. 情報セキュリティ・ネットワーク運用分野の標準的教科書群(大学初年次〜専門課程向けに広く使われている、ファイアウォール・IDS/IPS・ネットワーク防御の基礎を扱う定番の入門教科書群)。
2. 米国国立標準技術研究所(NIST), *Guidelines on Firewalls and Firewall Policy*(NIST Special Publication 800-41), 2009年ごろ改訂版が公開されたとされる。パケットフィルタリング・ステートフルインスペクションの標準的な整理。
3. 米国国立標準技術研究所(NIST), *Guide to Intrusion Detection and Prevention Systems (IDPS)*(NIST Special Publication 800-94), 2007年ごろ公開されたとされる。IDS/IPSの標準的な整理。
4. 米国国立標準技術研究所(NIST), *Zero Trust Architecture*(NIST Special Publication 800-207), 2020年ごろ公開されたとされる。ポリシー決定点・ポリシー実施点というゼロトラストの構成要素の標準的な整理。
5. John Kindervag(大手調査会社アナリスト), ゼロトラストという設計思想の提唱, 2010年前後に広まり始めたとされる。
6. 大手調査会社の複数のアナリストによる, SASE(Secure Access Service Edge)という概念の提唱, 2019年ごろとされる。
7. Saltzer, J. H. and Schroeder, M. D., *The Protection of Information in Computer Systems*, 1975年。完全な仲介(complete mediation)という原則の原典(姉妹巻BOOK-0360第七章で既出)。
8. 本プロジェクト内部資料: tools/check_conservation.js(保存則監査器)、tools/check_funcdict_langs.js(関数辞書の言語間整合検査器)、tools/assign_quiz_positions.js(検定配置ツール)、library/funcdict/FUNC-0254・FUNC-0255・FUNC-0294・FUNC-0384・FUNC-0390・FUNC-0399・FUNC-0609・FUNC-0612・FUNC-0649・FUNC-0662・FUNC-0688・FUNC-0769・FUNC-0771・FUNC-0774・FUNC-0919・FUNC-1076・FUNC-1077・FUNC-1100(関数辞書カード群)、NUMBER_REGISTRY.md。
9. BOOK-0360『情報防衛と復旧シリーズ 第1巻 情報セキュリティ総論』第四章(多層防御・単一障害点)・第七章(信頼境界・完全な仲介・ゾーン管理)。
10. BOOK-0361『情報防衛と復旧シリーズ 第2巻 認証・認可とアクセス制御』第十章(ゼロトラスト・継続的検証)。
11. BOOK-0070『ネットワーク — 遠くの相手に記号を届ける技術』・BOOK-0119『ネットワーク 第2巻 — 信頼性と規模の設計』(通信の一般理論・パケット・階層・IP/TCP・暗号とTLSは本巻ではそちらの定義を引き継ぐ)。
12. BOOK-0367『情報防衛と復旧シリーズ 第8巻 監視と観測可能性』(しきい値という考え方は、本巻第五章のアノマリ型検知の土台になっている)。
## 用語索引(本巻での初出章)
境界防御・ファイアウォール(第一章)/パケットフィルタリング・ステートフルインスペクション・次世代ファイアウォール・デフォルト拒否・デフォルト許可(第二章)/セグメンテーション・VLAN・サブネット・DMZ・リバースプロキシ(第三章)/南北トラフィック・東西トラフィック・マイクロセグメンテーション・被害範囲(第四章)/IDS・IPS・シグネチャ型検知・アノマリ型検知(第五章)/(三つの道具の組み合わせ・第六章)/ゼロトラスト(引き継ぎ)・ポリシー決定点(PDP)・ポリシー実施点(PEP)・マイクロペリメタ(第七章)/ソフトウェア定義境界(SDP)(第八章)/(レート制限・スロットル・タイムアウト・指数バックオフ・リトライは引き継ぎ)・エッジ・オリジン側(第九章)/規則の陳腐化(第十章)/SASE・ZTNA・SWG・CASB・FWaaS(第十一章)/(境界防御からゼロトラストへの推移・第十二章)。
---
（本冊子は情報防衛と復旧シリーズ BOOK-0370。全12巻の第11巻(ネットワーク防御の設計)。セグメンテーション・ゼロトラストアーキテクチャ・ファイアウォール/IDS/IPSの設計思想を通じて、特命業務における「予防」を担った。姉妹巻BOOK-0360『情報セキュリティ総論』の信頼境界・多層防御と、BOOK-0361『認証・認可とアクセス制御』のゼロトラストを、ネットワークアーキテクチャの視点から接続した。次なる一本道はBOOK-0363『インシデント対応の一本道』へ続く。CATALOG_情報防衛と復旧シリーズ.md・GAKUMON_UNIVERSE.md進捗台帳を参照。）
# BOOK-0370 情報防衛と復旧シリーズ 第11巻: ネットワーク防御の設計 — セグメンテーション・ゼロトラスト・IDS/IPSで境界をどう作り直すか