※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料 作：｛作者名｝
※物語はフィクションです 即時通報案件は専門家にご通報ください※お手数ですが疑問点は各分野でご確認いただけましたら幸いです※
# BOOK-0360 情報防衛と復旧シリーズ 第1巻: 情報セキュリティ総論 — なぜ「守る」を体系だてて学ぶ必要があるのか
> 情報防衛と復旧シリーズ(BOOK-0360〜0371・全12巻)第1巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」を専門職として遂行するための背骨12冊のうち、全巻の土台となる第1巻。CIA三要素・脅威モデリング・多層防御・リスクの考え方・四本柱・信頼境界・最小権限という、以後11巻すべてが前提として使う共通言語をここで一冊にまとめる。
> **安全枠(全巻共通・変更不可)**: 本シリーズは正当な防御・インシデント対応・教育目的に限定する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・検知回避手法は一切書かない。脆弱性を扱う場面があっても「何が起きるか(仕組み)・どう防ぐか・どう検知するか」という防御的視点にとどめる。「これを読めば絶対に破られない」といった誇張はせず、「対策は突破の確率とコストを上げるが、ゼロにはしない」という正直な水準で書く。
> 接続先: →BOOK-0073/0133『情報派生 暗号』第1・2巻(機密性を支える数学的な道具はそちらに詳しい。本巻は暗号という道具を「何のために・どこで使うか」という設計判断の側から位置づけ直す)、→BOOK-0070/0119『情報派生 ネットワーク』第1・2巻(通信そのものの仕組みはそちらが扱う。本巻は同じ通信路を「どう区切り、どう守るか」という防御の側から見る)、→BOOK-0006/0340『OS』(権限・プロセス分離という土台の上に、本巻の最小権限の原則が乗る)、→次巻BOOK-0361『認証・認可・アクセス制御』(本巻で定義する信頼境界・最小権限を、実際の識別・認証・認可の仕組みへ落とし込む)。
> 水準: 一〜十二(なぜ「守る」が必要かという出発点から、組織のセキュリティ体系を設計する実務的な視野までを、一冊で貫通する)。
---
# BOOK-0360 情報防衛と復旧シリーズ 第1巻: 情報セキュリティ総論 — なぜ「守る」を体系だてて学ぶ必要があるのか
> 情報防衛と復旧シリーズ(BOOK-0360〜0371・全12巻)第1巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」を専門職として遂行するための背骨12冊のうち、全巻の土台となる第1巻。CIA三要素・脅威モデリング・多層防御・リスクの考え方・四本柱・信頼境界・最小権限という、以後11巻すべてが前提として使う共通言語をここで一冊にまとめる。
> **安全枠(全巻共通・変更不可)**: 本シリーズは正当な防御・インシデント対応・教育目的に限定する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・検知回避手法は一切書かない。脆弱性を扱う場面があっても「何が起きるか(仕組み)・どう防ぐか・どう検知するか」という防御的視点にとどめる。「これを読めば絶対に破られない」といった誇張はせず、「対策は突破の確率とコストを上げるが、ゼロにはしない」という正直な水準で書く。
> 接続先: →BOOK-0073/0133『情報派生 暗号』第1・2巻(機密性を支える数学的な道具はそちらに詳しい。本巻は暗号という道具を「何のために・どこで使うか」という設計判断の側から位置づけ直す)、→BOOK-0070/0119『情報派生 ネットワーク』第1・2巻(通信そのものの仕組みはそちらが扱う。本巻は同じ通信路を「どう区切り、どう守るか」という防御の側から見る)、→BOOK-0006/0340『OS』(権限・プロセス分離という土台の上に、本巻の最小権限の原則が乗る)、→次巻BOOK-0361『認証・認可・アクセス制御』(本巻で定義する信頼境界・最小権限を、実際の識別・認証・認可の仕組みへ落とし込む)。
> 水準: 一〜十二(なぜ「守る」が必要かという出発点から、組織のセキュリティ体系を設計する実務的な視野までを、一冊で貫通する)。
---
## 入口の物語 — 鍵をかけ忘れた家と、鍵をかけても入られる家
ある人が、旅行から帰ってきて自宅の鍵をかけ忘れていたことに気づいたとしよう。幸い何も盗まれていなかったが、背筋が寒くなる。次の旅行では、鍵を二重にかけ、窓にも補助錠をつけ、玄関に照明付きのセンサーを設置した。ところが数年後、今度は鍵をきちんとかけていたにもかかわらず、窓ガラスを割られて空き巣に入られてしまった。鍵をかけ忘れたときは何も盗まれず、鍵を厳重にかけていたときに被害に遭う——この一見矛盾した経験は、実は情報セキュリティという分野の本質を、驚くほど正確に映し出している。
守るべきものの価値と、それを狙う相手と、狙われる隙——この三つがそろって初めて被害は起きる。逆に言えば、この三つのどれか一つでも欠けていれば、被害は起きない。鍵をかけ忘れた家に空き巣が入らなかったのは、たまたまその晩、その家を狙う人がいなかっただけかもしれない。鍵を厳重にかけた家に空き巣が入られたのは、玄関という一箇所だけを固めても、窓という別の弱い場所が残っていたからである。この「守るべきものは何か」「誰が狙ってくるのか」「どこに隙があるのか」という三つの問いを、思いつきではなく体系立てて考える技術こそが、情報セキュリティという分野の中心にある。
パソコンやスマートフォン、会社のシステム、ゲームの中の資産データ——形は違っても、守るべきものが存在し、それを狙う相手が存在し、守り方には必ずどこかに隙があるという構造は、家の鍵の話とまったく同じである。ただし現実の家と違って、情報の世界では「鍵をどれだけ厳重にかけても、ゼロにはならない」という事実を、最初からはっきり認めておく必要がある。本巻はこの正直な出発点から、CIA三要素・脅威モデリング・多層防御・リスクという考え方・予防と検知と対応と復旧という四本柱・信頼境界・最小権限の原則までを、一歩ずつたどっていく。この一冊で身につけた共通言語が、後続の十一巻——認証、脆弱性の防御的理解、インシデント対応、フォレンジクス、バックアップと災害復旧、可用性工学、監視、監査、鍵管理、ネットワーク防御、セキュアな再構成——すべての土台になる。
家の防犯と情報セキュリティが決定的に違う点も、一つだけ挙げておきたい。家の鍵は、目に見える形で「かけたかどうか」を確認できる。ところが情報の世界の防御の多くは、目に見えない形でシステムの内部に組み込まれている。パスワードの強さも、通信の暗号化も、権限の設定も、意識して確認しない限り、正しく機能しているのかいないのかが分からない。この「見えない」という性質こそが、情報セキュリティを一段むずかしくしている理由であり、だからこそ、思いつきや感覚に頼らず、体系立てた考え方——本巻がこれから示す一冊分の言葉——が必要になる。
---
## 第一章: なぜ「守る」が必要か — 資産と脅威(水準一)
### 情報資産という考え方
情報セキュリティを学ぶ最初の一歩は、「何を守るのか」をはっきりさせることである。組織や個人にとって価値があり、保護する対象となる、データ・装置・仕組み・信用のすべてを、**情報資産(じょうほうしさん、水準一: 組織や個人にとって価値があり、保護する対象となる、データ・装置・仕組み・信用のすべて)**と呼ぶ。
情報資産という言葉は、「パソコンの中に保存されたファイル」だけを指すのではない。顧客の名簿、設計図、ソースコードといったデータそのものはもちろん、そのデータを保存しているサーバーやハードディスクという装置、データを処理する手順書やソフトウェアという仕組み、そして「この会社の情報は信頼できる」という顧客や取引先からの信用まで、価値があり失えば困るものはすべて情報資産に含まれる。本プロジェクトでいえば、gakumon以下の図鑑本文、library/funcdict以下の関数辞書カード、NUMBER_REGISTRY.mdという台帳そのものも、すべて情報資産である。資産の棚卸し(たな卸し、水準一: 手元にある資産を一つずつ数え上げ、種類・保管場所・価値を一覧にする作業)から始めなければ、次に述べる脅威が何を狙っているのかも、正しく判断できない。
### 脅威という考え方
情報資産に対して、望ましくない影響を与えるおそれのある、あらゆる出来事や存在を、**脅威(きょうい、水準一: 情報資産に対して、望ましくない影響を与えるおそれのある、あらゆる出来事や存在)**と呼ぶ。
脅威という言葉を聞くと、多くの人は「悪意を持った攻撃者」を思い浮かべる。確かにそれは脅威の代表例だが、脅威の範囲はもっと広い。悪意のある第三者による不正アクセスだけでなく、従業員の操作ミスによるデータ削除、ハードウェアの経年劣化による故障、地震や火災といった自然災害、電力会社の停電、さらにはソフトウェアそのものに潜む設計ミスまで、情報資産に望ましくない影響を与えうるものはすべて脅威に数えられる。脅威を「悪意ある攻撃者」だけに限定してしまうと、災害やヒューマンエラーへの備えが抜け落ちてしまう——これが、脅威という言葉をあえて広く定義しておく理由である。
### 脆弱性という考え方の入り口
脅威が実際に被害へつながるかどうかは、資産の側に「つけこまれる隙」があるかどうかにかかっている。この隙を、**脆弱性(ぜいじゃくせい、水準一: 資産や仕組みの中にある、脅威につけこまれる余地・弱さ)**と呼ぶ。玄関の鍵をかけ忘れることも、窓ガラスが割れやすい材質であることも、どちらも脆弱性の一種である。脆弱性そのものを掛け合わせてリスクを見積もる方法は第五章で正式に扱うが、ここでは「資産・脅威・脆弱性の三つがそろって初めて被害が起きる」という構造だけを、まず押さえておこう。
### なぜ体系だてて学ぶ必要があるのか
資産・脅威・脆弱性という三つの要素は、いずれも単独では被害を生まない。資産があっても脅威がなければ何も起きず、脅威があっても資産に脆弱性がなければ被害は防がれる。この三者の関係を思いつきではなく体系立てて洗い出す技術——それが本巻を貫く一本の糸であり、後続十一巻それぞれが、この三者のどこかの側面を深掘りしていくことになる。
### コラム — 資産の重みづけは、保険の考え方とよく似ている
「資産の価値をどう見積もるか」という問いは、実は情報セキュリティより古くから、保険という分野で扱われてきた。火災保険や海上保険の世界では、ある建物や積荷が失われたときの損失額をあらかじめ見積もり、その見積もりに応じて保険料を決めるという実務が、何世紀にもわたって積み重ねられてきたとされる。情報資産の棚卸しも、発想としては同じである。「この資産が失われたら、いくらの損失になるか」「復旧にどれだけの時間と費用がかかるか」を見積もっておくことで、初めてどの資産から優先して守るべきかが判断できるようになる。第五章で扱う資産価値という言葉も、この保険的な発想の延長線上にある。
### コラム — 資産を分類する: 公開・社内限り・秘密という三段階
実務の現場では、すべての情報資産を同じ重さで扱うのではなく、あらかじめ機密の度合いによって分類しておくことが多い。誰が見てもよい「公開」、組織の内部関係者だけが見てよい「社内限り」、特に限られた担当者だけが見てよい「秘密」という三段階に分ける**情報分類(じょうほうぶんるい、水準一: 情報資産を、機密の度合いに応じてあらかじめ段階分けしておく仕組み)**は、資産の棚卸しをさらに一歩進めた実務である。分類をあらかじめ決めておけば、第二章で扱う機密性をどの程度厳しく適用すべきかが、資産ごとに機械的に判断できるようになる。分類のない棚卸しは「何があるか」しか分からないが、分類のある棚卸しは「何をどう扱うべきか」まで分かる、という違いがある。
### コラム — 「セキュリティ」という言葉のもともとの意味
セキュリティ(security)という英単語は、「〜から離れて」を意味するラテン語の接頭辞と、「気がかり・心配」を意味する語根が組み合わさった言葉に由来するとされる。つまり語源をたどれば、セキュリティとは元来「心配から解放された状態」を指す言葉であった。この語源は、本章で述べた資産・脅威・脆弱性という技術的な整理と、少し違う角度から情報セキュリティの目的を照らし出している。多層防御やリスク評価といった技術は、それ自体が目的なのではなく、最終的には「資産の持ち主が安心して日々の活動に集中できる状態」を作り出すための手段である、という原点を、この語源は思い出させてくれる。
### 脅威の主体を大まかに分類する
脅威という言葉の範囲が広いことは第一章冒頭で述べたが、実務上は脅威の主体をいくつかの大まかな種類に分けて捉えておくと、対策の優先順位がつけやすくなる。金銭や情報を狙う組織的な集団、内部の関係者による意図的な不正または過失、自然災害や設備故障といった非人為的な要因——性質の異なるこれらの主体は、それぞれ発生の頻度も、有効な対策の種類も大きく異なる。本巻がこれ以降で扱う技術の多くは、特定の脅威の主体だけに効くものではなく、主体の種類を問わず効果を発揮する、汎用性の高い防御の型であるという点も、あわせて押さえておきたい。
---
> **定着量の目安(第一章)**: 自分の身の回りにある情報資産(スマートフォンの中の写真、SNSアカウント、仕事のファイルなど)を5つ書き出し、それぞれについて「失われたら何が困るか」を一行で説明する練習をしておくと、第二章以降のCIA三要素・第五章のリスクの考え方が、抽象論でなく自分ごととして理解しやすくなる。
---
## 第二章: CIA三要素 — 機密性・完全性・可用性(水準一〜二)
### 三つの目的を整理する枠組み
情報資産を守るとき、「守る」という言葉が指している内容は、実は一つではない。許可された人だけが情報にアクセスでき、許可されていない人には内容が明かされない性質を、**機密性(きみつせい、水準一: 許可された人だけが情報にアクセスでき、許可されていない人には内容が明かされない性質)**と呼ぶ。情報が、許可されない書き換えや破壊を受けず、正確で改ざんされていない状態に保たれている性質を、**完全性(かんぜんせい、水準一: 情報が、許可されない書き換えや破壊を受けず、正確で改ざんされていない状態に保たれている性質)**と呼ぶ。許可された人が、必要なときに情報や仕組みへ確実にアクセスし、使い続けられる性質を、**可用性(かようせい、水準一: 許可された人が、必要なときに情報や仕組みへ確実にアクセスし、使い続けられる性質)**と呼ぶ。
この三つの頭文字(Confidentiality・Integrity・Availability)をとって、**CIA三要素(シーアイエーさんようそ、水準二: 機密性・完全性・可用性の頭文字をとった呼び方で、情報セキュリティが達成すべき目的を三方向に整理する基本の枠組み)**と呼ぶ。この三分類そのものは、1980年代の米国防総省の文書(通称オレンジブック、正式名『信頼できるコンピュータシステム評価基準』)などを経て、情報セキュリティの分野で広く定着していったとされる。
### 三要素は互いに引っ張り合う
CIA三要素の面白さは、三つが単純に足し算できる目標ではなく、しばしば互いに引っ張り合う関係にあるという点にある。機密性を極端に高めようとして、あらゆる操作に多重の確認を要求すれば、正規の利用者にとっての可用性が下がる。逆に可用性を最優先し、誰でもすぐにアクセスできる仕組みにすれば、機密性が犠牲になる。第五章で扱うリスクの考え方も、第七章で扱う信頼境界の設計も、突き詰めればこの三要素のどこにどれだけ重みを置くかという判断の積み重ねである。
### 検算的な小演習 — 図書室の本という題材で三要素の重みを比べる
三要素の引っ張り合いを、身近な題材で具体的に確かめてみよう。学校や公共の図書室にある「一般に貸し出される本」と「貴重な郷土資料(一冊しかない古い記録)」を比べる。
```
一般に貸し出される本:
機密性の重み: 低(誰が読んでもよい)
完全性の重み: 中(多少の汚れは許容されるが、ページの欠落は困る)
可用性の重み: 高(いつでも借りられることが最も重要)
貴重な郷土資料(一冊しかない):
機密性の重み: 中(閲覧者を記録する程度)
完全性の重み: 最高(汚損・劣化は取り返しがつかない)
可用性の重み: 低(閲覧室でのみ、係員の立ち会いのもとで見られれば十分)
```
同じ「本」という情報資産でも、性質が違えば三要素の重みづけはまったく逆転する。一般書は可用性を最優先し、郷土資料は完全性を最優先する——この判断は、第一章で扱った資産の棚卸しと分類があって初めて可能になる。三要素をすべての資産に一律に同じ強さで適用しようとすることこそが、しばしば実務上の失敗の原因になる。
### 完全性を機械的に確かめる実例
完全性は「改ざんされていないこと」を意味するが、これを人間の目視だけで確かめるのは現実的ではない。任意長のデータを固定長の要約値に変換する一方向写像を使えば、この確認を機械的に行える。**ハッシュ化(はっしゅか、水準二: 任意長のデータを固定長の要約値〈ハッシュ値〉に変換する一方向の写像。同じ入力からは常に同じ出力が得られるが、出力から入力を復元することは意図的に困難にされている)**と呼ばれるこの技術は、本プロジェクトの関数辞書でもFUNC-0188として索引されている。元のデータと保存しておいたハッシュ値を突き合わせ、一致すれば改ざんされていないと判断できる——この仕組みは第五巻(フォレンジクス)で改ざん検知の一般原理として、また第十巻(鍵管理とPKI)で証明書の検証原理として、それぞれ深掘りされる。
本プロジェクトには、完全性を継続的に検査する別の実例もある。資産の生成・消費・移動が発生するたびに、システム全体の資産総量が想定どおりの帳尻に一致しているかを検査する**保存則監査(ほぞんそくかんさ、水準二: 資産の生成・消費・移動が発生するたびに、システム全体の資産総量が想定どおりの帳尻に一致しているかを機械的に検査する手法)**が、tools/check_conservation.js(索引: FUNC-0662「資源保存則検証」)として実装されている。「複製バグ」のような不正な資産増殖を、個々の操作の見た目上の正しさではなく、台帳全体の帳尻という構造から検出する——これは完全性という抽象的な目的を、実際に動くコードへ落とし込んだ具体例である。
### 可用性は「動いていること」だけではない
可用性は、システムが単に動いていることではなく、「必要なときに」使えることを意味する。年に一度しか使わない機能が99%の時間動いていても、ちょうど必要な瞬間に落ちていれば、利用者にとっての可用性は実質ゼロである。可用性をどう数値化し、どう保証するかは、第七巻(可用性・信頼性工学)でRTO・RPOという指標とあわせて詳しく扱う。
### コラム — CIA三要素だけでは足りない、という議論もある
CIA三要素は広く使われている枠組みだが、これだけで情報セキュリティのすべてを説明しきれるわけではない、という指摘も専門家の間でなされてきた。たとえば、情報セキュリティの研究者ドン・パーカーは、機密性・完全性・可用性の三つに加えて、所有・真正性・効用という要素を加えた6要素のモデルを提唱したとされる。真正性(しんせいせい、水準二: その情報が、本当に主張どおりの発信元から送られたものであるという性質)は、完全性(内容が改ざんされていないこと)とは別の軸であり、「内容は正しいが、送り主が偽物である」という状況を見分けるために必要になる。この真正性という考え方は、第二巻(認証・認可・アクセス制御)で「なりすまし対策」として、また第十巻(鍵管理とPKIの実務)で「デジタル署名」として、それぞれ具体的な技術へ展開される。三要素という枠組みは出発点として優れているが、唯一絶対の分類ではないという事実を知っておくことも、専門職としての正直さの一部である。
### コラム — 否認防止という第四の目的
CIA三要素と並んでよく挙げられるもう一つの目的に、ある操作を行った本人が、後になって「自分はやっていない」と言い逃れできないようにする性質——**否認防止(ひにんぼうし、水準二: ある操作を行った本人が、後になって「自分はやっていない」と言い逃れできないようにする性質)**がある。契約書に署名や捺印を残すのと同じように、デジタルの世界でも「誰が・いつ・何をしたか」を後から証明できる記録を残しておくことが、組織の統制において重要な役割を果たす。この考え方は第九巻(監査・統制とコンプライアンス)で、証跡(しょうせき)という言葉とともに詳しく扱われる。
---
> **定着量の目安(第二章)**: 自分がふだん使っているサービス(メール・SNS・ゲームアカウントなど)を一つ選び、「機密性が破られたらどう困るか」「完全性が破られたらどう困るか」「可用性が破られたらどう困るか」をそれぞれ一行で書き分けてみると、三要素が別々の目的であることが実感しやすくなる。
---
## 第三章: 脅威モデリング — 何を・誰から・どう守るか(水準二〜三)
### 脅威を思いつきでなく洗い出す
第一章で「脅威は悪意ある攻撃者だけではない」と述べたが、では実際にどうやって脅威を漏れなく洗い出せばよいのか。何を守るのか(資産)・誰から守るのか(脅威の主体)・どう守るのか(対策)を、体系立てて洗い出す作業を、**脅威モデリング(きょういもでりんぐ、水準二: 何を守るのか・誰から守るのか・どう守るのかを、体系立てて洗い出す作業)**と呼ぶ。
脅威モデリングが重要なのは、思いつきで対策を積み上げると、目立つ脅威にだけ対策が集中し、地味だが確実に起こる脅威が見落とされがちだからである。「派手な不正アクセス」への対策ばかりに気を取られ、「バックアップを取り忘れる」という地味なヒューマンエラーへの備えが抜け落ちる、というのはよくある失敗の型である。
### 攻撃対象面という考え方
脅威モデリングを行ううえで欠かせないのが、「どこから働きかけを受けうるか」を洗い出す作業である。外部からの働きかけを受けうる、システムの接点の集合を、**攻撃対象面(こうげきたいしょうめん、水準三: 外部からの働きかけを受けうる、システムの接点の集合)**と呼ぶ。ログイン画面、外部から送られてくるファイルを開く機能、外部サービスとの連携部分などは、いずれも攻撃対象面の一部である。攻撃対象面を洗い出すこと自体は防御的な作業であり、洗い出した接点それぞれに「何が起きうるか」「どう防ぐか」を対応づけていく。
脅威を分類する代表的な考え方として、なりすまし・改ざん・否認・情報漏えい・サービス停止・権限昇格という六つの観点から検討する手法が、大手ソフトウェア企業によって1990年代末に整理され、広く紹介されている。この六分類自体は、脅威の種類を整理するための語彙であり、いずれも「何が起きうるかを洗い出し、それぞれにどう備えるか」を考えるための防御的な道具である。
### 脅威モデリングの成果物
脅威モデリングの結果は、多くの場合、資産・脅威・想定される影響・現状の対策・残る課題を一覧にした表として整理される。この表は一度作って終わりではなく、システムの構成が変わるたびに更新する必要がある。第三巻(脆弱性の防御的理解)では、この攻撃対象面の中でも特に頻出する種類の弱さを、悪用手順ではなく防御と検知の視点から掘り下げる。
### 検算的な小演習 — 簡単なログイン画面の脅威モデリング
抽象論だけでは実感が湧きにくいので、ごく単純な例で脅威モデリングの手順を確かめておこう。「利用者名とパスワードを入力するログイン画面」という、ありふれた仕組みを題材にする。
```
資産: 利用者のアカウント(ログインできる権利そのもの)
脅威の主体: 不特定多数からの自動的な試行、身近な人物によるのぞき見
攻撃対象面: ログイン画面の入力欄、パスワードを忘れたときの再設定機能
想定される影響: 他人による不正ログイン、アカウントの乗っ取り
現状の対策(防御的視点のみ): 一定回数失敗したら一時的に試行を制限する仕組み、
パスワードとは別の確認手段を追加する仕組み(第二巻で詳しく扱う)
残る課題: 再設定機能自体が新しい攻撃対象面になっていないかの点検
```
この表からわかるとおり、脅威モデリングは「攻撃の手口を暗記する」作業ではなく、「資産・脅威・対象面・対策・課題」という決まった型に沿って、抜け漏れなく情報を整理する作業である。この型そのものが、悪用手順を書かずに防御を語るための、安全な思考の枠組みになっている。
### コラム — 脅威モデリングにはいくつもの流派がある
脅威モデリングの手法は一つではない。本章で紹介した「なりすまし・改ざん・否認・情報漏えい・サービス停止・権限昇格」という六分類のほかにも、攻撃者の動機や目的から逆算して考える手法や、攻撃の道筋を木構造で図示して整理する手法など、複数の流派が実務の現場で使われている。いずれの流派も「資産・脅威・対策を体系立てて洗い出す」という共通の目的を持っており、どの流派を使うかよりも「思いつきで済ませず、必ず体系立てて洗い出す」という姿勢そのものが、脅威モデリングの本質である。
### 脅威モデリングは一人で完結しない
脅威モデリングを、一人の担当者だけで机上で行うと、その担当者の知識や経験の範囲でしか脅威を洗い出せない、という限界がある。実務では、開発者・運用担当者・利用者側の代表など、立場の異なる複数の関係者を集めて脅威を洗い出すことが推奨される。開発者には見えていない「利用者が実際にどう操作しているか」という視点や、運用担当者にしか分からない「過去にヒヤリとした出来事」といった情報は、一人の机上の想像だけでは決して出てこない。第八章で扱う職務分掌が「権限を一人に集中させない」という原則であるのと同様に、脅威モデリングもまた「洗い出しの視点を一人に集中させない」ことで、抜け漏れを減らすことができる。
---
> **定着量の目安(第三章)**: 自分が管理しているファイルやアカウントを一つ選び、「誰が」「どこから」「どんな理由で」それを狙いうるかを3パターン書き出す練習をしておくと、脅威を思いつきでなく体系立てて洗い出す感覚が身につく。
---
## 第四章: 多層防御 — 単一の壁でなく層で守る(水準三〜四)
### 一つの壁だけに頼らない
第三章で洗い出した攻撃対象面のすべてに、完璧な壁を築くことは現実的ではない。どんなに厚い壁も、いつかは破られる可能性がある。そこで発想を転換し、単一の防御策だけに頼らず、性質の異なる複数の防御層を重ねることで、一つの層が破られても全体がただちに破綻しないようにする設計思想を、**多層防御(たそうぼうぎょ、水準三: 単一の防御策だけに頼らず、性質の異なる複数の防御層を重ねることで、一つの層が破られても全体がただちに破綻しないようにする設計思想)**と呼ぶ。
入口の物語で触れた家の防犯を例にとれば、鍵・補助錠・センサー・近隣の見回りという複数の層を重ねておけば、鍵が破られても補助錠が、補助錠が破られてもセンサーが、次の壁として機能する。どれか一つが完璧である必要はなく、層を重ねることで全体としての強度が上がる、という考え方である。
### 単一障害点を避ける
多層防御と対になる考え方として、その一箇所が機能しなくなるだけで、システム全体が止まってしまう部分を、**単一障害点(たんいつしょうがいてん、水準四: その一箇所が機能しなくなるだけで、システム全体が止まってしまう部分)**と呼ぶ。単一障害点は可用性の観点からも危険だが、セキュリティの観点からも危険である。防御をすべて一つの仕組み(たとえば一つのパスワードだけ)に集約してしまうと、その一点が破られた瞬間に全層が同時に崩れる。多層防御とは、単一障害点を作らないように、独立した性質の異なる防御を意図的に分散させる作業でもある。
### 本プロジェクトにおける多層防御の実例
多層防御は抽象的な理念にとどまらない。本プロジェクトのtools/check_funcdict_langs.jsは、全カードの構造的な過不足を毎回全数検査する静的層と、実際にコードを実行して言語間の挙動が一致するかを確かめる挙動層とを分けて運用しており、これは多層防御という考え方が実際の開発現場でも通用することを示す実例である。静的層は0.44秒・LLMトークン0で全1,358カードを毎日検査でき、見落としを構造的に防ぐ「面」の守りを担う。挙動層は実際にコードを実行して初めて分かる「言語間の実行結果のずれ」という、静的層だけでは検出できない種類の異常を担当する。二つの層は互いの弱点を補い合っており、片方だけでは見えない異常が、層を重ねることで初めて見えるようになる——この構造は、第八巻(監視と観測可能性)・第十一巻(ネットワーク防御)で、それぞれ別の技術領域における多層防御として再登場する。
### 多層防御は魔法の杖ではない
ここで一つ、正直に述べておかなければならないことがある。層を重ねれば重ねるほど安全になる、というのは半分正しく半分誤解を招く言い方である。層が増えれば運用の手間も増え、正規の利用者にとっての使い勝手(第二章の可用性)が損なわれることもある。「どの層を、どれだけ重ねるべきか」は、次章で扱うリスクの大きさに応じて判断すべき問題であり、無限に層を重ねればよいわけではない。
### コラム — 多層防御という発想の起源
多層防御という考え方そのものは、情報セキュリティのために発明されたわけではない。城を囲む堀と城壁と天守という何重もの防御構造や、船の内部を複数の区画に分けて一箇所が浸水しても船全体が沈まないようにする設計など、「一つが破られても全体は残る」という発想は、軍事や造船の分野で古くから使われてきたとされる。情報セキュリティの分野でこの発想が明確な用語として定着したのは、1990年代以降、政府機関や標準化団体の文書で「多層防御」という言葉が使われるようになってからだと広く紹介されている。城壁も船の区画も、コンピュータの中の防御層も、根っこにある発想は同じ——「唯一の防御に頼らない」という、驚くほど単純な知恵である。
### コラム — 生物の免疫系も多層防御である
もう一つの身近な実例として、人間の体を守る免疫の仕組みが挙げられる。皮膚という物理的な壁(第一層)を通り抜けられても、粘膜にある化学的な防御(第二層)が待ち構えており、それも突破されれば、体内を巡回して異物を見つけ出す白血球という仕組み(第三層)が働く。どの層も単独では万能ではないが、性質の異なる層を重ねることで、全体としては非常に高い防御力を実現している。この生物学的な多層防御は、第六章で扱う予防・検知・対応・復旧という時間軸の四本柱とも重なる構造を持っている——皮膚は予防、免疫細胞による発見は検知、白血球の活動は対応、傷の治癒は復旧に、それぞれ対応づけて理解することができる。
### 層の性質をあえて変える
多層防御で見落とされがちな注意点として、「層の数を増やす」ことと「層の性質を変える」ことは同じではない、という点がある。同じ種類の鍵を三つ並べても、その鍵をこじ開ける一つの技術さえあれば三つとも同時に破られてしまう。第三章で洗い出した攻撃対象面ごとに、性質の異なる防御(物理的な対策・仕組み上の対策・運用上の対策など)を組み合わせてこそ、多層防御は本来の効果を発揮する。層の数を誇るのではなく、層どうしが互いの弱点を補い合っているかを確かめることが、多層防御を設計するうえでの実務上の要点である。
---
> **定着量の目安(第四章)**: 自分の身の回りで「多層防御になっている仕組み」を一つ探し(例: 家の鍵+保険+近隣の目)、それぞれの層がどんな種類の脅威に効くのかを対応づけて書き出してみると、層を重ねる意味が具体的に理解できる。
---
## 第五章: リスク = 脅威×脆弱性×資産価値(水準四〜五)
### 三つの掛け算として捉える
第一章で「資産・脅威・脆弱性の三つがそろって初めて被害が起きる」と述べた。この関係をもう一歩具体化し、対策の優先順位を決めるための考え方が、リスクという概念である。ある資産が持つ、金銭的・機能的・信用上の重みを、**資産価値(しさんかち、水準四: ある資産が持つ、金銭的・機能的・信用上の重み)**と呼ぶ。この関係は、しばしば**リスク(risk、水準五: 脅威×脆弱性×資産価値の掛け合わせとして捉えられる、望ましくない結果が起きる可能性と影響の大きさ)** = 脅威 × 脆弱性 × 資産価値、という掛け算の形で表される。
この式が掛け算である点が重要である。三つの要素のうち、どれか一つでもゼロに近ければ、リスク全体もゼロに近づく。どれだけ深刻な脆弱性があっても、それを狙う脅威が実質存在しなければリスクは小さい。逆にどれだけ多くの脅威にさらされていても、脆弱性がなければリスクは小さい。対策を検討する際に「脅威を減らす」「脆弱性を塞ぐ」「資産価値そのものを下げる(重要データを分散させるなど)」という三方向すべてが選択肢になる、というのがこの式の実務上の意味である。
### 脆弱性を機械的に見つける実例
脆弱性は、人間の目視だけに頼ると見落としが起きやすい。本プロジェクトのtools/check_conservation.jsは、資産の複製という重大な脆弱性を、個々のイベントの見た目上の正しさではなく、台帳全体の帳尻という構造的な不変量から検出する設計になっている。生成合計から消費合計を差し引いた値が、全所有者の保有量の合計と一致するかどうかという等式だけを検査することで、正規の操作では絶対に崩れないはずの帳尻が崩れた瞬間に、複製という脆弱性の発現を検出できる。これは「起きた後に気づく」のではなく「起きた瞬間に構造から検出する」という、脆弱性対策の一つの型である。
### リスクの大きさに応じて対策を選ぶ
リスクをすべてゼロにすることはできない(第九章で改めて正直に述べる)。だからこそ、リスクの大きさを見積もり、大きいリスクから優先して対策する、という順序立てが必要になる。この優先順位づけの技術は、第九巻(監査・統制とコンプライアンス)で、組織全体のリスク評価という実務としてさらに深く扱われる。
### 検算的な小演習 — リスク評価マトリクスで優先順位をつける
リスク=脅威×脆弱性×資産価値という式は、実務では「発生可能性」と「影響の大きさ」という二軸の表(リスク評価マトリクス)に単純化して使われることが多い。それぞれを高・中・低の3段階で採点し、掛け合わせて優先度を決める例を見てみよう。
```
影響:小 影響:中 影響:大
発生可能性:高 優先度=中 優先度=高 優先度=最高
発生可能性:中 優先度=低 優先度=中 優先度=高
発生可能性:低 優先度=最低 優先度=低 優先度=中
例1: 「バックアップの取り忘れ」→ 発生可能性:高(うっかり忘れは日常的に起こる)
× 影響:大(失えば復旧不能) → 優先度=最高
例2: 「非常に高度な標的型の攻撃」→ 発生可能性:低(自分が狙われる可能性は低い)
× 影響:大(狙われれば深刻) → 優先度=中
```
この例からわかるとおり、「いかにも恐ろしそうな脅威」が必ずしも最優先とは限らない。発生可能性の低い派手な脅威よりも、発生可能性の高い地味な脅威(バックアップの取り忘れなど)のほうが、優先度で上回ることも珍しくない。この「地味だが確実に起こることへの過小評価」を防ぐのが、思いつきに頼らずマトリクスで機械的に採点する意義である。
### コラム — リスクを数値で見積もる分野の源流
「起こりうる悪いことの大きさと確率をかけ合わせて見積もる」という発想そのものは、情報セキュリティより古く、保険や金融の分野で長い歴史を持つ。海運の損失を見積もる実務が積み重なって発展したとされるロンドンの保険市場の歴史はその代表例であり、統計に基づいて将来の損失を見積もるという手法は、その後、工学分野の安全性評価や、情報セキュリティのリスク評価へも応用されていった。第五巻(フォレンジクスとログ解析)では、実際に起きた事象の記録を積み重ねることで、このリスク見積もりの精度をさらに高めていく手法を扱う。
### 定性的評価と定量的評価
リスクの見積もり方には、大きく分けて二つの流儀がある。本章で示した「高・中・低」のような三段階で採点する方法を**定性的評価(ていせいてきひょうか、水準五: リスクの大きさを、高・中・低のような段階的な言葉で見積もる方法)**と呼び、金額や発生確率のパーセンテージのような具体的な数値で見積もる方法を**定量的評価(ていりょうてきひょうか、水準五: リスクの大きさを、金額や確率といった具体的な数値で見積もる方法)**と呼ぶ。定性的評価は手早く実施でき、多くの資産を一度に見渡すのに向いている一方、定量的評価は精度が高い分、正確な数値を集めるための手間がかかる。実務では、まず定性的評価で優先度の高い資産を絞り込み、絞り込んだ資産についてのみ定量的評価を行う、という二段構えがよく使われる。この使い分けそのものが、限られた労力を最も効果の高いところへ配分するという、リスク評価の実務的な知恵である。
---
> **定着量の目安(第五章)**: 自分の情報資産を3つ選び、それぞれについて「資産価値(高・中・低)」「脅威の可能性(高・中・低)」「脆弱性の大きさ(高・中・低)」を主観でよいので採点し、掛け算的にどれが最優先で対策すべきかを順位づけしてみると、リスクという考え方が実感として理解できる。
---
## 第六章: 予防・検知・対応・復旧という四本柱(水準五〜六)
### 時間軸で防御を四つに分ける
ここまでの章では「被害を防ぐ」ことを中心に見てきたが、実際には被害が起きる前と後とで、必要な働きが異なる。時間の流れに沿って、防御の働きを四つに分けて考えることができる。脅威が資産に到達する前に、あらかじめその可能性を減らしておく働きを、**予防(よぼう、水準五: 脅威が資産に到達する前に、あらかじめその可能性を減らしておく働き)**と呼ぶ。防御をすり抜けた異常や侵害の兆候に、できるだけ早く気づく働きを、**検知(けんち、水準五: 防御をすり抜けた異常や侵害の兆候に、できるだけ早く気づく働き)**と呼ぶ。検知した異常や侵害に対して、被害の拡大を止め、原因を取り除く働きを、**対応(たいおう、水準六: 検知した異常や侵害に対して、被害の拡大を止め、原因を取り除く働き)**と呼ぶ。対応によって止めた被害から、正常な状態へ回復させる働きを、**復旧(ふっきゅう、水準六: 対応によって止めた被害から、正常な状態へ回復させる働き)**と呼ぶ。
この四本柱は、それぞれ独立した専門分野として発展している。予防は第二巻(認証・認可)・第十巻(鍵管理とPKI)・第十一巻(ネットワーク防御)が、検知の前提となる観測基盤は第八巻(監視と観測可能性)が、対応は第四巻(インシデント対応の一本道)が、復旧は第六巻(バックアップと災害復旧)・第七巻(可用性・信頼性工学)が、それぞれ深掘りする。本巻は、この四本柱がどう連なっているかという全体地図だけを示す。
### 検知の限界を正直に見つめる — 「緑を騙る赤」という現象
四本柱のうち、検知は特に難しい。なぜなら、検知の仕組み自体が「異常はない」と誤って報告してしまう可能性があるからである。本プロジェクトの過去の記録には、この難しさを示す実例がある。ある決定的乱数生成の関数(索引: FUNC-0278)について、複数回にわたる「読む検定」——コードを人間や機械が読んで正しさを確認する検定——では欠陥が発見されなかったが、実際にコードを実行して言語間の出力を突き合わせる検定を行った結果、python実装がjs実装と同じ乱数の種を与えられているにもかかわらず異なる数列を生成するという欠陥が発見された。検定を通過していたにもかかわらず内部には欠陥が潜んでいた、というこの種の状態は、しばしば「緑を騙る赤」と呼ばれる。この現象を一般化し、正常を装う異常をどう見破るかを専門に扱うのが、第五巻(フォレンジクスとログ解析)である。
### リトライという回復の基本部品
対応と復旧の境目でよく使われる基本的な部品として、処理が失敗したとき、一定回数を上限に同じ処理を再試行する**リトライ(retry、水準六: 処理が失敗したとき、一定回数を上限に同じ処理を再試行する仕組み)**がある(索引: FUNC-0293)。すべての障害が再試行だけで解決するわけではないが、一時的な不具合による失敗と、根本的な欠陥による失敗を切り分けるための、最も基本的な回復手段の一つである。
### ログという、四本柱すべてを下支えする記録
四本柱のどの働きも、記録が残っていなければ十分に機能しない。予防が効いているかを後から確認するのも、検知の手がかりを探すのも、対応の経緯を残すのも、復旧が正しく完了したかを確かめるのも、すべて記録があって初めて可能になる。肥大化し続けるログファイルを、一定のサイズや時間間隔で区切って新しいファイルへ切り替え、古いファイルは圧縮・世代管理・削除する**ログローテーション(log rotation、水準六: 肥大化し続けるログファイルを、一定のサイズや時間間隔で区切って新しいファイルへ切り替え、古いファイルを圧縮・世代管理・削除する仕組み)**は、本プロジェクトの関数辞書でもFUNC-0398として索引されている、記録を長期にわたって健全に保つための基本技術である。ログという記録そのものをどう設計し、どう分析するかは、第八巻(監視と観測可能性)・第五巻(フォレンジクスとログ解析)で本格的に扱われる。
### コラム — インシデント対応の型: 準備・識別・封じ込め・根絶・復旧・教訓
対応と復旧をさらに細かく分解した、実務でよく使われる型として、準備・識別・封じ込め・根絶・復旧・教訓という6段階に分ける手法が、セキュリティ教育機関によって整理され、広く紹介されている。この型は、第六章で述べた「検知」の後の「対応」を、封じ込め(被害の拡大を止める)と根絶(原因を取り除く)にさらに分け、最後に「教訓」という段階を明示的に加えている点が特徴である。事件から得た教訓を次の予防に還元することで、四本柱は一度きりの直線ではなく、ぐるぐると回り続ける循環になる。この6段階の型は、第四巻(インシデント対応の一本道)で、本シリーズの背骨として正式に扱われる。
### 四本柱のバランス — どこか一本だけを厚くしない
四本柱を学ぶと、多くの人はまず「予防」に力を入れたくなる。予防は分かりやすく、被害そのものを未然に防げるからである。しかし第九章で述べる正直な限界のとおり、予防だけを厚くしても被害はゼロにならない。予防に偏りすぎて検知への投資を怠ると、防御をすり抜けた異常に気づくまでの時間が長引き、結果として被害が深刻化してから発覚する、という事態を招きやすい。逆に検知ばかりを厚くして対応・復旧の手順を整えていなければ、異常に気づいたところで、その後どう動けばよいか分からず現場が混乱する。四本柱は、どれか一本だけを伸ばすのではなく、四本のバランスを意識して整えることが、実務上もっとも大切な心構えである。
---
> **定着量の目安(第六章)**: 自分が過去に経験したトラブル(パソコンの故障、うっかり削除、パスワード忘れなど)を一つ思い出し、それが「予防」「検知」「対応」「復旧」のどの段階でつまずいたのかを分類してみると、四本柱が具体的な出来事とどう対応するかが理解しやすくなる。
---
## 第七章: 信頼境界という考え方(水準六〜七)
### どこまでを信頼してよいか
システムの内部と外部を区別せず、すべてを同じように信頼してしまうと、外部から来たどんなデータも無条件に受け入れてしまうことになる。これを防ぐために、システムの中で、信頼してよいデータ・処理の領域と、信頼できない外部からの入力の領域とを、明確に区切る境界線を、**信頼境界(しんらいきょうかい、水準六: システムの中で、信頼してよいデータ・処理の領域と、信頼できない外部からの入力の領域とを、明確に区切る境界線)**と呼ぶ。
信頼境界という考え方が重要なのは、「内部だから安全」という思い込みが、しばしば被害を広げる原因になるからである。一度信頼境界の内側に入り込まれてしまうと、内部の仕組みは互いを疑わずに動作するよう設計されていることが多く、被害が一気に広がりやすい。近年広まった、社内・社外という所在地だけで信頼を判断せず、すべてのアクセスをその都度検証するという考え方(ゼロトラストという呼び名で、2010年前後から業界で広く使われるようになったとされる)は、この信頼境界を「一度きりの壁」ではなく「毎回検証する仕組み」に作り替える発想である。この設計思想は第十一巻(ネットワーク防御の設計)で詳しく扱われる。
### 境界で入力を検証する
信頼境界を実際に機能させるには、境界を越えて入ってくるデータを、その都度確かめる仕組みが必要になる。外部から受け取ったデータが、あらかじめ定義した構造の規則に適合しているかどうかを検査する**入力検証(にゅうりょくけんしょう、水準七: 外部から受け取ったデータが、あらかじめ定義した構造の規則に適合しているかどうかを検査する仕組み)**は、本プロジェクトの関数辞書でもFUNC-0387「スキーマ検証」として索引されている。境界を越えるすべてのデータに対して、この検証を一貫して適用することが、信頼境界を絵に描いた餅で終わらせない実務上の鍵になる。第三巻(脆弱性の防御的理解と対策)では、この入力検証が不十分だった場合にどのような種類の不具合が起こりうるかを、防御と検知の視点から扱う。
### 境界は一つとは限らない
大きなシステムでは、外部との境界だけでなく、内部の部門やサービスの間にも信頼境界を設けることが多い。これは第四章で扱った多層防御の考え方そのものであり、一つの境界が破られても、内部の別の境界がさらに被害の広がりを食い止める。信頼境界は静的な図面ではなく、システムの成長にあわせて見直し続ける、生きた設計判断である。
### コラム — 「every access must be checked」という原則
信頼境界を設けるだけでは十分ではなく、その境界を越えるすべてのアクセスに対して、例外なく検証を適用しなければならない、という設計原則がある。第八章で紹介する最小権限の原則と同じ1975年の論文の中で、この「すべてのアクセスを毎回確認する」という考え方も、完全な仲介(かんぜんなちゅうかい)という原則として整理されたとされる。「一度確認したら、あとは信頼して素通りさせる」という近道を作ってしまうと、その近道自体が新しい信頼境界の穴になる——これは、第七章冒頭で述べた「内部だから安全という思い込みが被害を広げる」という話と、まったく同じ構造の教訓である。
### コラム — 境界の内と外を分けるもう一つの実例: ゾーンという考え方
信頼境界という考え方は、情報セキュリティに限らず、複数の領域を明確に区切って管理するという、より一般的な設計パターンの一種である。本プロジェクトのカードゲームの仕組みには、カードが所属しうる複数の領域(手札・山札・場・墓地・追放領域など)を明示的な区画として管理し、カードは常にちょうど1つの区画に属するようにする**ゾーン管理(ぞーんかんり、水準七: 資産や要素が所属しうる複数の領域を明示的な区画として管理し、常にちょうど1つの区画に属するようにする仕組み)**という設計(索引: FUNC-0609)がある。「あるものが今どの区画に属しているかを、あいまいさなく常に一つに定める」という発想は、信頼境界の内側と外側をあいまいにしないという本章の主題と、根っこの部分で同じ設計思想を共有している。
### 境界を越えるときは、必ず一つの決まった通路を通す
信頼境界を守るうえでもう一つ大切なのが、境界を越える手段を一つの決まった通路(門・API・インターフェースなど)に絞り、それ以外の抜け道を作らないようにすることである。門が一つしかなければ、その門にだけ検証の仕組みを集中させればよい。ところが便利さを優先して裏口を作ってしまうと、その裏口には検証が及ばず、信頼境界そのものが形骸化してしまう。「便利な近道は、たいてい新しい信頼境界の穴になる」という警句は、第四章の単一障害点、第八章の最小権限とも通じる、本巻全体を貫く共通の教訓の一つである。
### 信頼境界と組織の境界は一致するとは限らない
信頼境界は、必ずしも組織の壁(会社の建物やネットワークの範囲)と一致するとは限らない。在宅勤務やクラウドサービスの利用が広がった環境では、「社内にいるかどうか」が「信頼できるかどうか」の目安として機能しなくなりつつある。第七章冒頭で紹介したゼロトラストという考え方が広まった背景には、まさにこの「組織の境界と信頼境界が一致しなくなった」という現実の変化がある。信頼境界を「場所」ではなく「その都度の検証」で定義し直す、という発想の転換は、第十一巻(ネットワーク防御の設計)でさらに具体的な技術として展開される。
---
> **定着量の目安(第七章)**: 自分が使っているサービス(SNS・ゲーム・仕事のシステムなど)について、「どこからが外部で、どこからが内部か」という境界線を自分なりに図に描いてみると、信頼境界という考え方が具体的なイメージとして定着する。
---
## 第八章: 最小権限の原則(水準七〜八)
### 必要な分だけ与える
信頼境界の内側であっても、すべての利用者やプログラムに同じだけの権限を与えてよいわけではない。利用者やプログラムに対して、その時々の作業に本当に必要な権限だけを与え、それ以上の権限は与えないという考え方を、**最小権限の原則(さいしょうけんげんのげんそく、水準七: 利用者やプログラムに対して、その時々の作業に本当に必要な権限だけを与え、それ以上の権限は与えないという考え方)**と呼ぶ。
この原則の古典的な定式化は、1975年に発表された計算機システムの保護に関する論文にまでさかのぼるとされ、以来半世紀にわたって、情報セキュリティの設計原則の中でも特に基本的なものの一つとして扱われ続けている。既刊のOS(BOOK-0006/0340)で扱われる、プロセスやユーザーごとの権限分離という仕組みは、この原則を実際のオペレーティングシステムの中で実現するための土台である。
### 最小権限の効果
最小権限の原則を守っておくと、仮に一つのアカウントやプログラムが乗っ取られたとしても、そのアカウントが本来持っていた権限の範囲までしか被害が及ばない。すべての利用者に管理者権限を与えてしまえば、どこか一箇所が突破されただけでシステム全体が危険にさらされる——これは第四章で扱った単一障害点の、権限という側面での現れである。
### 組織における最小権限 — 職務分掌
最小権限の原則は、個々のアカウントだけでなく、組織の役割分担にも当てはまる。一人の担当者に、記録・承認・監査という複数の権限を集中させず、複数の担当者に分けて互いに牽制させる仕組みを、**職務分掌(しょくむぶんしょう、水準八: 一人の担当者に権限を集中させず、複数の担当者に分けて互いに牽制させる仕組み)**と呼ぶ。本プロジェクトの検定文化における「書き手≠採点者」という原則(索引: FUNC-1100「検定の鍵分離」)は、まさにこの職務分掌の考え方をソフトウェア開発の検証プロセスに応用したものである。制作した本人が自分の成果物を自分で採点すると、本人の思い込みや見落としがそのまま検定側にも紛れ込み、自己採点になってしまう——これを構造的に避けるために、検定を行う側と実装する側を独立させておく。この考え方は第九巻(監査・統制とコンプライアンス)で、組織の統制という実務にさらに一般化される。
### コラム — 「知る必要のある人だけ」という発想の起源
最小権限の原則と、しばしば対で語られる考え方に、業務上その情報を本当に必要とする人だけに開示範囲を限る、いわゆる「知る必要のある人だけ(need to know)」という発想がある。この発想は、軍事・外交の機密情報を扱う分野で古くから使われてきたとされ、後に情報セキュリティの分野へ取り入れられた。「権限があるかどうか」と「その時点で本当に必要かどうか」は必ずしも同じではない、という区別がここでの要点である。管理者権限を持つ担当者であっても、日常のちょっとした作業では、あえて権限の低いアカウントを使う、という実務上の工夫が広く推奨されているのは、この「必要なときにだけ、必要な分だけ」という発想の延長線上にある。
### なぜ権限は際限なく広がりやすいのか
最小権限の原則を知っていても、実際の組織では権限が徐々に広がっていく傾向がある。新しい業務を任されるたびに権限を追加してもらう一方で、その業務が終わっても権限が回収されないまま放置される、という積み重ねがしばしば起こる。この「使われなくなった過剰な権限」は、第五章のリスクの式でいえば、脆弱性の側に静かに積み上がっていく厄介な要素である。定期的に権限を棚卸しし、不要になった権限を削除する作業は、地味だが第九章で扱う正直な限界と向き合ううえで欠かせない、継続的な取り組みである。
### OSにおける最小権限の実例
最小権限の原則は、抽象的な理念ではなく、日々使っているオペレーティングシステムの中にすでに組み込まれている。多くのOSでは、システム全体を管理できる強い権限を持つ利用者(いわゆる管理者アカウント)と、自分のファイルやアプリケーションの範囲内でしか操作できない一般利用者とを区別しており、日常的な作業は一般利用者の権限で行い、システムの設定を変更するときだけ管理者権限を一時的に借りる、という運用が広く推奨されている。既刊のOS(BOOK-0006/0340)で扱われるプロセスごとの権限分離やサンドボックスという仕組みは、まさにこの最小権限の原則を、利用者だけでなく、動いているプログラム一つひとつのレベルにまで徹底したものである。「常に一番強い権限で作業したほうが手っ取り早い」という誘惑に負けないことが、最小権限の原則を実務で守り続けるうえでの、最も基本的で、最も破られやすい一線である。
---
> **定着量の目安(第八章)**: 自分がふだん使っているサービスで「本当に必要な権限だけを与えているか」を見直し(例: 使っていないアプリの過剰な許可を確認する)、一つでも権限を絞り込む実践をしておくと、最小権限の原則が抽象論でなく自分の手で実行できることが確認できる。
---
## 第九章: 正直な限界 — 確率とコストを上げるが、ゼロにはしない(水準八〜九)
### ゼロにはならないという前提
ここまで、資産と脅威、CIA三要素、脅威モデリング、多層防御、リスクの考え方、四本柱、信頼境界、最小権限という、いくつもの防御の技術を見てきた。ここで一度立ち止まり、これらの技術に共通する、正直に認めなければならない限界を述べておく。多層防御は、突破の確率とコストを上げるが、ゼロにはしない——これが、本シリーズが繰り返し立ち返る、誇張のない正直な水準である。
この限界を認めることは、防御をあきらめることではない。むしろ逆である。「ゼロにできる」という前提に立ってしまうと、対策を尽くした後に想定外の被害が起きたとき、どう対応すればよいかという備え(第四章の四本柱でいう対応・復旧)が抜け落ちてしまう。「ゼロにはならない」と正直に認めたうえで、被害が起きた後にどう立て直すかまでを設計に含めておくことこそが、専門職としての誠実な姿勢である。
### 攻撃側と防御側の非対称性
なぜゼロにできないのか。防御側は、あらゆる攻撃対象面(第三章)をすべて完璧に守り切る必要があるのに対し、攻撃を試みる側はたった一つの隙を見つければよい、という非対称な構造がある。この非対称性のもとでは、防御側にできることは「隙をゼロにする」ことではなく、「隙を見つけて突破するまでのコストと不確実性を、相手にとって割に合わないほど大きくする」ことである。これが「確率とコストを上げる」という言い回しの意味である。
### 残余リスクという考え方
対策を尽くしてもなお残る、ゼロにはならないリスクの部分を、**残余リスク(ざんよリスク、水準九: 対策を尽くしてもなお残る、ゼロにはならないリスクの部分)**と呼ぶ。組織のセキュリティ設計とは、残余リスクをゼロにしようとする終わりのない努力ではなく、残余リスクの大きさを正しく見積もり、その大きさを組織として受け入れられる範囲に収める、という現実的な意思決定の連続である。この意思決定の実務は、第十一章と第九巻(監査・統制とコンプライアンス)で、より具体的に扱われる。
### 対策には収穫逓減がある
対策への投資を増やせば増やすほどリスクが減る、という関係も、実は単純な比例関係ではない。最初のわずかな対策(たとえば、パスワードを使い回さないようにするだけ)で、リスクは大きく下がる。しかし、すでに基本的な対策が行き届いた状態から、さらに残余リスクをわずかに減らそうとすると、投資に対して得られる効果は小さくなっていく——この関係を、経済学では**収穫逓減(しゅうかくていげん、水準九: 投資を増やしていくと、追加の投資1単位あたりから得られる効果が、次第に小さくなっていく関係)**と呼ぶ。この事実は、「対策には終わりがある」という誤解ではなく、「限られた資源をどこまで投じるべきかは、残余リスクの大きさと投資額を見比べて判断すべきである」という、第五章のリスク評価と地続きの実務的な教訓を示している。
### コラム — セキュリティは製品ではなく継続的な工程である
情報セキュリティの実務家の間では、セキュリティを一度導入すれば完了する「製品」としてではなく、環境の変化にあわせて見直し続ける「工程」として捉えるべきだという考え方が、繰り返し語られてきた。新しい脅威が現れ、新しい脆弱性が見つかり、組織の構成そのものも変わり続ける以上、ある時点で「これで完成」と言い切れる防御は存在しない。第十一章で扱う組織のセキュリティ体系が、一回限りの構築物ではなく継続的な仕組みとして設計されるべき理由も、この「製品ではなく工程である」という認識に根ざしている。
### 正直さは、専門職としての信頼の土台である
「ゼロにはならない」と正直に述べることは、一見すると自信のなさの表れのように思われるかもしれない。しかし実際には逆である。すべてを完璧に守れると請け合う専門家よりも、守れる範囲と守れない範囲をあらかじめ正直に説明できる専門家のほうが、いざ被害が起きたときに、慌てず段取りどおりに対応できる可能性が高い。「絶対に安全です」と言い切ってしまうと、万が一被害が起きたときに、その言葉自体が組織の信用を大きく損なう。第十一章で扱う段階判断も、日頃から残余リスクを正直に共有できている組織でなければ、いざというときに適切な一手を選べない。本章で述べた正直な限界という視点は、技術的な限界の話であると同時に、専門職としての信頼をどう築くかという、組織運営の話でもある。
---
> **定着量の目安(第九章)**: 「絶対に安全」「完全に防げる」という表現を見かけたときに、それが誇張ではないかを一度立ち止まって疑う習慣をつけておくと、本章で述べた正直な限界という視点が、日常の情報との付き合い方にも生きてくる。
---
## 第十章: セキュリティの規格と共通言語(水準九〜十)
### なぜ規格が必要なのか
ここまでの章で扱ってきた概念(CIA三要素・脅威モデリング・四本柱など)は、組織や国が違っても通用する共通言語として、いくつかの公的な規格に整理されている。規格を知っておくことは、単なる知識の暗記ではなく、他の組織や専門家と話がかみ合うようにするための実務上の道具である。
組織が情報セキュリティを継続的に計画・実行・点検・改善する仕組みを、**ISMS(あいえすえむえす、水準九: 情報セキュリティマネジメントシステムの略称で、組織が情報セキュリティを継続的に計画・実行・点検・改善する仕組み)**と呼ぶ。ISMSの国際規格であるISO/IEC 27001は、2000年代に整備され、以後改訂を重ねながら世界的に広く使われている情報セキュリティマネジメントの標準である。
### NISTサイバーセキュリティフレームワーク
米国国立標準技術研究所(NIST)が策定した、特定・防御・検知・対応・復旧という機能に沿って組織のセキュリティ対策を整理する枠組みを、**NISTサイバーセキュリティフレームワーク(水準十: 特定・防御・検知・対応・復旧という機能に沿って組織のセキュリティ対策を整理する、米国国立標準技術研究所が策定した枠組み)**と呼ぶ。2014年に最初の版が公開されたとされるこの枠組みは、本巻第六章で扱った四本柱(予防・検知・対応・復旧)と、第一章で扱った資産の特定という考え方を、ほぼそのまま公的な枠組みの形に落とし込んだものである。本巻の四本柱がこうした公的な枠組みと同じ骨格を持っているという事実は、本巻の内容が机上の空論ではなく、実務の世界で広く共有されている考え方であることを裏づけている。
### 規格は法的助言ではない
規格や標準を扱う本章、そして後続の第九巻(監査・統制とコンプライアンス)の内容は、あくまで制度の型を学ぶための教材であり、特定の法的助言ではない。実際の規制対応や認証取得にあたっては、有資格の専門家や監督当局が公開している最新の指針に従う必要がある。
### コラム — 脆弱性を共通の言葉で数える仕組み
規格が「組織の体制」を共通言語にするのに対し、個々の弱点そのものを共通言語で扱うための仕組みもある。世界中で見つかった脆弱性一つひとつに、重複のない識別番号を割り振って公開する仕組みや、その深刻度を統一された基準で点数化する仕組みが、公的な機関や業界団体によって運用されている。これらの識別番号や点数は、いずれも「どの脆弱性がどれだけ深刻か」を組織を超えて共有するための共通言語であり、悪用の手順そのものではない。第三巻(脆弱性の防御的理解と対策)では、この共通言語を使って「どの弱点から優先して塞ぐべきか」を判断する実務を、防御的な視点から扱う。
### コラム — 規格どうしの関係を俯瞰する
本章で紹介したISMS(組織の体制を継続的に改善する仕組み)とNISTサイバーセキュリティフレームワーク(特定・防御・検知・対応・復旧の5機能)は、互いに矛盾するものではなく、視点の違う地図として補い合う関係にある。ISMSは「どう継続的に改善する体制を作るか」という運営の骨組みに重心を置き、NISTの枠組みは「具体的にどんな機能を備えるべきか」という機能の一覧に重心を置く。加えて、統制項目を一覧化した業界標準のチェックリスト群(たとえばCIS Controlsと呼ばれる一覧)のように、より実務的な「何を設定すべきか」の一覧を提供する規格も存在する。複数の規格を「どれが正しいか」ではなく「どの視点を補ってくれるか」で使い分けることが、実務上の賢い付き合い方である。
### 認証取得と、実際に守れているかは別の話
規格には、外部の審査機関による審査を経て認証を取得できるものもある。認証を取得すること自体は、組織が一定の水準の体制を整えていることを対外的に示す意味を持つが、認証取得の瞬間から未来永劫「守れている」ことを保証するものではない、という点には注意が必要である。第九章で述べた「セキュリティは製品ではなく工程である」という認識のとおり、認証はある時点の体制のスナップショットにすぎず、その後も体制を維持し続けているかどうかは、日々の運用そのものにかかっている。規格や認証を「ゴール」ではなく「継続的な改善を回すための道具」として捉える姿勢が、第十一章で扱う組織のセキュリティ体系の設計において欠かせない。
---
> **定着量の目安(第十章)**: 本章で紹介したNISTサイバーセキュリティフレームワークの5機能(特定・防御・検知・対応・復旧)を、第六章の四本柱(予防・検知・対応・復旧)と見比べ、どこが同じでどこが違うかを自分の言葉で説明できるようにしておくと、規格と本巻の内容のつながりが定着する。
---
## 第十一章: 組織のセキュリティ体系を設計する実務 — 後続十一巻への地図(水準十〜十二)
### 十本の糸を一つに束ねる
ここまでの十章で見てきた資産と脅威(第一章)、CIA三要素(第二章)、脅威モデリング(第三章)、多層防御(第四章)、リスクの考え方(第五章)、四本柱(第六章)、信頼境界(第七章)、最小権限(第八章)、正直な限界(第九章)、規格という共通言語(第十章)は、それぞれ独立した道具ではなく、一つの体系として組み合わさって初めて機能する。資産と脅威を組織全体で洗い出す仕組みを持ち、その仕組みを実際に運用する担当者に最小権限で役割を割り振り、信頼境界を毎回検証する仕組みを整え、四本柱それぞれに責任者を置き、規格に沿って定期的に点検する——このすべてを一つの体系として設計し、日々の運用に落とし込む実務を、**組織のセキュリティ体系(そしきのせきゅりてぃたいけい、水準十一: 資産の洗い出し・権限設計・信頼境界・四本柱の運用・規格に沿った点検を、一つの継続的な仕組みとして組み合わせたもの)**と呼ぶ。
### 段階判断という到達点
組織のセキュリティ体系が本当に試されるのは、平時ではなく、深刻な事態が起きたときである。すべてを一律に止めるのか、一部だけを止めて様子を見るのか、あるいは平常運用を続けながら裏で対応を進めるのか——状況の深刻さに応じて、日常運用の継続から一時停止・全面的な再構成までの複数の選択肢の中から、最も適切な一手を選び取る、専門職としての意思決定を、**段階判断(だんかいはんだん、水準十二: 状況の深刻さに応じて、日常運用の継続から一時停止・全面的な再構成までの複数の選択肢の中から、最も適切な一手を選び取る、専門職としての意思決定)**と呼ぶ。
段階判断は、本巻一冊だけでは身につかない。第一章の資産の洗い出しなくして「何を止めるべきか」は判断できず、第六章の四本柱なくして「今どの段階にいるか」は分からず、第九章の正直な限界を知らなければ「ゼロを目指す判断」という誤った理想に引きずられてしまう。本巻で共有した言葉のすべてが、この段階判断という到達点のための部品である。
### 体系を支える三つの層 — 方針・基準・手順
組織のセキュリティ体系を実際に文書として組み立てるとき、一枚岩の分厚い規則集を作るのではなく、抽象度の異なる三つの層に分けて整理することが実務上よく行われる。組織として何を大切にするかという方向性を示す**方針(ほうしん、水準十一: 組織として何を大切にし、どう情報セキュリティに取り組むかという方向性を示す、最も抽象度の高い文書)**、その方針を満たすために満たすべき具体的な条件を示す**基準(きじゅん、水準十一: 方針を満たすために、満たすべき具体的な条件を示す文書)**、そして日々の作業手順を示す**手順書(てじゅんしょ、水準十一: 基準を満たすために、実際に誰が何をどう行うかを示す、最も具体的な文書)**という三層である。方針が変わることは滅多にないが、手順書は環境の変化にあわせて頻繁に見直される——この抽象度の違いを意識して文書を分けておくことで、細かい手順の変更のたびに組織全体の方針から書き直す、という非効率を避けられる。
### 継続的に見直す輪 — 計画・実行・点検・改善
組織のセキュリティ体系は、一度作って終わりではなく、計画し・実行し・点検し・改善するという輪を回し続けることで初めて機能し続ける。この計画・実行・点検・改善という4段階の輪(しばしば頭文字をとってPDCAサイクルと呼ばれる)は、情報セキュリティに限らず品質管理全般で広く使われている考え方であり、ISMS(第十章)もこの輪を回し続けることを前提に設計されている。第九章で述べた「セキュリティは製品ではなく工程である」という認識は、この輪を止めないことの重要性と、そのまま重なっている。
### 後続十一巻への読了系統
本巻を土台として、後続の十一巻は次の順序で読み進めることを推奨する。まず予防を固める第2巻(認証・認可・アクセス制御)・第3巻(脆弱性の防御的理解と対策)・第10巻(鍵管理とPKIの実務)・第11巻(ネットワーク防御の設計)へ進み、次に検知の前提となる第8巻(監視と観測可能性)へ、続いて判定を担う第5巻(フォレンジクスとログ解析)へ、そして特命業務の背骨である第4巻(インシデント対応の一本道)へと進む。そのうえで復旧と再構成を担う第6巻(バックアップと災害復旧)・第7巻(可用性・信頼性工学)・第12巻(セキュアな再構成の実務)へ進み、最後に制度側から全体を締める第9巻(監査・統制とコンプライアンス)で仕上げる。この一本道が、「一日停止・全システム再構成の段階判断」を専門職として遂行するための、蔵書一覧の読了系統である。
### 既刊との接続で、すでに半分は準備できている
この読了系統は、まったくのゼロから始まるわけではない。第一章冒頭で触れたとおり、暗号(BOOK-0073/0133)・ネットワーク(BOOK-0070/0119)・OS(BOOK-0006/0340)という既刊三分野は、いずれも本シリーズが土台とする糸である。暗号の理論は第十巻(鍵管理とPKI)の実務接続を待っており、ネットワークの通信理論は第十一巻(ネットワーク防御)の防御構成を待っており、OSの権限分離は本巻第八章の最小権限の原則を通じてすでに接続されている。後続十一巻を新しい知識として身構えるのではなく、「すでに読んだ既刊に、防御という新しい軸を一本足すだけ」という感覚で読み進めると、十一巻という分量も、決して大きな壁ではなくなる。
---
> **定着量の目安(第十一章)**: 本巻で登場した10の考え方(資産と脅威・CIA三要素・脅威モデリング・多層防御・リスク・四本柱・信頼境界・最小権限・正直な限界・規格)を、白紙に自分の言葉で一行ずつ書き出せるかを試してみる。すべて書き出せれば、後続十一巻をどの順番で読んでも、本巻の共通言語をよりどころにして読み進められる状態になっている。
---
## 四つの実践解 — 特別な道具を使わない、安全な実践
理論を、実際に手を動かして確かめる方法を四つ紹介する。いずれも実在システムへの侵入や特別な道具を必要とせず、紙とペン、あるいは自分自身の情報資産だけで完結する、安全な実践解である。
1. **資産棚卸し実践**: 自分が日常使っているアカウント・端末・データを、思いつく限りすべて紙に書き出す(スマートフォン、SNSアカウント、メール、クラウドストレージ、ゲームアカウントなど)。それぞれについて「機密性・完全性・可用性のうち、どれが最も大事か」を一つ選び、理由を一行添える。これを10個以上行うと、第一章・第二章の内容が、抽象論でなく自分の持ち物の話として定着する。
2. **多層防御の図解実践**: 自分の情報資産のうち一つを選び、それを守っている防御層を紙に描き出す(例: メールアカウント→パスワード+二段階認証+ログイン通知+定期的なパスワード変更)。層が一つしかない資産が見つかったら、それが単一障害点になっていないかを検討し、どんな層を追加できそうかを考える。
3. **四本柱による経験の分類実践**: 過去に自分が経験した情報関連のトラブル(端末の故障、ファイルの誤削除、パスワード忘れ、アカウントへの不審なログイン通知など)を3つ思い出し、それぞれが「予防」「検知」「対応」「復旧」のどの段階でつまずいたのかを分類する。すべての段階に一つも経験がなければ、それは幸運なだけで、いずれかの段階の備えがまだ試されていないという意味でもある。
4. **リスク評価マトリクス実践**: 第五章の検算的な小演習で示したリスク評価マトリクス(発生可能性×影響の3×3の表)を白紙に描き、自分の情報資産に関連する「起こりうる望ましくないこと」を5つ以上書き出して、それぞれをマトリクスの9マスのどこかに当てはめてみる。「優先度=最高」に入ったものが、今すぐ対策すべき最優先課題である。この実践を数か月おきに繰り返すと、環境の変化にあわせてリスクの優先順位がどう動くかも実感できるようになる。
---
## まとめ — 一冊の共通言語が、十一冊の背骨になる
本巻では、鍵をかけ忘れた家と鍵を厳重にかけても入られた家という、一見矛盾した経験から出発し、情報資産と脅威という最も基本的な語彙(第一章)、機密性・完全性・可用性というCIA三要素(第二章)、何を・誰から・どう守るかを体系立てて洗い出す脅威モデリング(第三章)、単一の壁でなく層で守る多層防御(第四章)、脅威×脆弱性×資産価値というリスクの掛け算(第五章)、予防・検知・対応・復旧という時間軸の四本柱(第六章)、信頼してよい領域とそうでない領域を区切る信頼境界(第七章)、必要な分だけ権限を与える最小権限の原則(第八章)、そして「対策は確率とコストを上げるが、ゼロにはしない」という正直な限界(第九章)、公的な規格という共通言語(第十章)までをたどり、最後に組織のセキュリティ体系と段階判断という、本シリーズ全体の到達点を見た(第十一章)。
この一冊で共有した言葉は、単独では大きな力を持たない。しかし、後続の十一巻——認証・認可、脆弱性の防御的理解、インシデント対応、フォレンジクス、バックアップと災害復旧、可用性・信頼性工学、監視と観測可能性、監査・統制、鍵管理とPKI、ネットワーク防御、セキュアな再構成——のどの巻を開いても、本巻で定義した言葉が土台として使われている。足し算から出発してPCの中身にたどり着いた別シリーズと同じように、本巻もまた「鍵をかけ忘れた家」という素朴な経験から出発し、専門職としての段階判断という到達点まで、一本の糸でつながっている。
本巻を通じて繰り返し確認してきたのは、華やかな技術の話ではなく、地味だが裏切らない型の話である。資産を数え、脅威を洗い出し、層を重ね、優先順位をつけ、記録を残し、権限を絞り、境界を検証し、そして「ゼロにはならない」と正直に認める——この八つの動作を組織の隅々にまで行き渡らせることこそが、専門職としての情報防衛の実務であり、後続十一巻はいずれも、この八つの動作のどこかを深く掘り下げたものにほかならない。次巻からは、いよいよ個々の技術領域へ分け入っていく。
---
## 章末: 簡易階段図
```
[水準十二] 組織のセキュリティ体系・段階判断
日常運用の継続から全面的な再構成までの複数選択肢から最適な一手を選ぶ(第十一章)
▲
│ 十の考え方を一つの継続的な仕組みへ束ねる
[水準九〜十] 規格という共通言語(ISMS・ISO/IEC 27001・NISTサイバーセキュリティフレームワーク)
NIST CSF=特定・防御・検知・対応・復旧の5機能(第十章)
▲
│ 組織を超えて通用する語彙に翻訳する
[水準八〜九] 正直な限界(残余リスク)
多層防御は突破の確率とコストを上げるが、ゼロにはしない(第九章)
▲
│ ゼロを目指す幻想を捨て、現実的な水準を認める
[水準七〜八] 最小権限の原則・職務分掌
利用者やプログラムに、必要な権限だけを与える(第八章)
▲
│ 境界の内側でも、権限は絞り込む
[水準六〜七] 信頼境界・入力検証
信頼してよい領域と信頼できない領域を明確に区切る(第七章)
▲
│ どこまでを信頼するかを、毎回検証可能な形にする
[水準五〜六] 予防・検知・対応・復旧の四本柱
「緑を騙る赤」=検定を通過しても内部に欠陥が潜む現象(FUNC-0278実例・第六章)
▲
│ 被害が起きる前と後とで、必要な働きを時間軸で分ける
[水準四〜五] リスク=脅威×脆弱性×資産価値
資産複製という脆弱性を台帳の帳尻から機械検出(tools/check_conservation.js・第五章)
▲
│ 三要素の掛け算として優先順位をつける
[水準三〜四] 多層防御・単一障害点
静的層+挙動層の二層構造(tools/check_funcdict_langs.js実例・第四章)
▲
│ 単一の壁でなく、層を重ねて守る
[水準二〜三] 脅威モデリング・攻撃対象面
何を・誰から・どう守るかを体系立てて洗い出す(第三章)
▲
│ 脅威を思いつきでなく漏れなく洗い出す
[水準一〜二] CIA三要素(機密性・完全性・可用性)
ハッシュ化(FUNC-0188)で完全性を機械的に確認(第二章)
▲
│ 「守る」という言葉を三つの目的に分解する
[水準一] 資産と脅威
情報資産・脅威・脆弱性の三つがそろって初めて被害が起きる(第一章)
横の広がり:
[水準一] 予防 ←(第六章・時間軸で対になる)→ 検知
[水準一] 機密性 ←(第二章・引っ張り合う関係)→ 可用性
[水準四] 多層防御 ←(第四章・対になる概念)→ 単一障害点
現在のフロンティア(第七章・第十章):
2010年前後 ゼロトラストという考え方が業界で広まり始めたとされる(所在地でなく毎回検証する発想への転換)
2014年 NISTサイバーセキュリティフレームワークの最初の版が公開されたとされる
※本巻で扱ったCIA三要素・多層防御・四本柱という考え方は、現在もなお、規格の改訂や新しい脅威の
出現にあわせて実務の最前線で更新され続けている、現役の設計原理である。
次の冊子(水準一〜五・BOOK-0361『認証・認可・アクセス制御』):
識別と認証の分離・多要素認証・認可の設計・最小権限の実装 ─────▶
```
---
## 参照文献(定番教科書・公的規格・原著)
1. 情報セキュリティ分野の標準的教科書群(大学初年次〜専門課程向けに広く使われている、CIA三要素・脅威モデリング・多層防御・アクセス制御の基礎を扱う定番の入門教科書群)。
2. 米国国防総省『信頼できるコンピュータシステム評価基準』(通称オレンジブック)、1983年。CIA三要素の定着に影響を与えたとされる歴史的文書の一つ。
3. Saltzer, J. H. and Schroeder, M. D. *The Protection of Information in Computer Systems*, 1975年。最小権限を含む設計原則群の古典的な定式化として広く引用される。
4. マイクロソフト社による脅威分類手法(なりすまし・改ざん・否認・情報漏えい・サービス停止・権限昇格の六分類)、1990年代末に整理され、脅威モデリングの実務教材として広く紹介されている。
5. ISO/IEC 27001(情報セキュリティマネジメントシステム — 要求事項)。国際標準化機構による情報セキュリティマネジメントの国際規格。
6. 米国国立標準技術研究所(NIST) *Framework for Improving Critical Infrastructure Cybersecurity*(サイバーセキュリティフレームワーク)、2014年初版公開とされる。
7. 本プロジェクト内部資料: tools/check_conservation.js(保存則監査器)、tools/check_funcdict_langs.js(構造層・挙動層の二層検査器)、library/funcdict/FUNC-0188・FUNC-0278・FUNC-0293・FUNC-0387・FUNC-0662・FUNC-1100(関数辞書カード群)、NUMBER_REGISTRY.md(2026-07-13付・FUNC-0278事件の記録)。
8. ドン・パーカーによる情報セキュリティの6要素モデル(パーカーの六角形)に関する著作群、1990年代後半に提唱されたとされる。CIA三要素を拡張する議論の代表例として広く紹介されている。
9. マイクロソフト社の脅威モデリング手法解説書群、および攻撃木(attack tree)による脅威整理手法に関する定番文献。いずれも防御的な整理手法としての紹介にとどめ、悪用手順には立ち入らない。
## 用語索引(本巻での初出章)
情報資産・脅威・脆弱性・情報分類(第一章)/機密性・完全性・可用性・CIA三要素・ハッシュ化・保存則監査・真正性・否認防止(第二章)/脅威モデリング・攻撃対象面(第三章)/多層防御・単一障害点(第四章)/資産価値・リスク・定性的評価・定量的評価(第五章)/予防・検知・対応・復旧・ログローテーション(第六章)/信頼境界・入力検証・ゾーン管理(第七章)/最小権限の原則・職務分掌(第八章)/残余リスク・収穫逓減(第九章)/ISMS・NISTサイバーセキュリティフレームワーク(第十章)/組織のセキュリティ体系・段階判断・方針・基準・手順書(第十一章)。
---
（本冊子は情報防衛と復旧シリーズ BOOK-0360。全12巻の第1巻(情報セキュリティ総論)。次巻BOOK-0361『認証・認可・アクセス制御』(水準一〜五)では、本巻で定義した信頼境界・最小権限の原則を、識別・認証・認可という具体的な仕組みへ落とし込む。CATALOG_情報防衛と復旧シリーズ.md・GAKUMON_UNIVERSE.md進捗台帳を参照。）
# BOOK-0360 情報防衛と復旧シリーズ 第1巻: 情報セキュリティ総論 — なぜ「守る」を体系だてて学ぶ必要があるのか