※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料 作：｛作者名｝
※物語はフィクションです 即時通報案件は専門家にご通報ください※お手数ですが疑問点は各分野でご確認いただけましたら幸いです※
# BOOK-0361 情報防衛と復旧シリーズ 第2巻: 認証・認可・アクセス制御 — 「あなたは誰か」「何をしてよいか」を切り分けて設計する
> 情報防衛と復旧シリーズ(BOOK-0360〜0371・全12巻)第2巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」を専門職として遂行するための背骨12冊のうち、予防の中核を担う第2巻。前巻(BOOK-0360)が定義した信頼境界・最小権限の原則を、識別・認証・認可という具体的な三工程へ落とし込み、パスワードの弱点からMFA・セッション管理・RBAC/ABAC・特権管理・SSO/OAuth・ゼロトラスト・パスキーまで、「あなたは誰か」を確かめ「何をしてよいか」を決める仕組み全体を一冊で貫通する。
> **安全枠(全巻共通・変更不可)**: 本シリーズは正当な防御・インシデント対応・教育目的に限定する。実在システムへの侵入手順・パスワード解析の実行手順・認証回避手法は一切書かない。認証・認可の仕組みを扱う場面があっても「何を確かめる仕組みか・どう防ぐか・どう検知するか」という防御的視点にとどめる。「これを導入すれば絶対に破られない」といった誇張はせず、「対策は突破の確率とコストを上げるが、ゼロにはしない」という前巻の正直な水準を、本巻でも引き継ぐ。
> 接続先: →BOOK-0360『情報防衛と復旧シリーズ 第1巻 情報セキュリティ総論』(信頼境界・最小権限・CIA三要素という本巻全体の前提はそちらに詳しい)、→BOOK-0006/0340『OS』(プロセス・ユーザーごとの権限分離という土台の上に、本巻のアクセス制御モデルが乗る)、→BOOK-0073/0133『情報派生 暗号』第1・2巻(ハッシュ化・公開鍵暗号という数学的な道具はそちらに詳しい。本巻は同じ道具を「認証にどう使うか」という設計判断の側から位置づけ直す)、→次巻BOOK-0362『脆弱性の防御的理解と対策』(本巻で扱う認証の仕組みに欠陥があった場合、何が起こりうるかを防御的視点でさらに掘り下げる)。
> 水準: 一〜十二(識別・認証・認可の三分離という出発点から、達人術としての認証技術の進化のメタ的推移までを、一冊で貫通する)。
---
# BOOK-0361 情報防衛と復旧シリーズ 第2巻: 認証・認可・アクセス制御 — 「あなたは誰か」「何をしてよいか」を切り分けて設計する
> 情報防衛と復旧シリーズ(BOOK-0360〜0371・全12巻)第2巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」を専門職として遂行するための背骨12冊のうち、予防の中核を担う第2巻。前巻(BOOK-0360)が定義した信頼境界・最小権限の原則を、識別・認証・認可という具体的な三工程へ落とし込み、パスワードの弱点からMFA・セッション管理・RBAC/ABAC・特権管理・SSO/OAuth・ゼロトラスト・パスキーまで、「あなたは誰か」を確かめ「何をしてよいか」を決める仕組み全体を一冊で貫通する。
> **安全枠(全巻共通・変更不可)**: 本シリーズは正当な防御・インシデント対応・教育目的に限定する。実在システムへの侵入手順・パスワード解析の実行手順・認証回避手法は一切書かない。認証・認可の仕組みを扱う場面があっても「何を確かめる仕組みか・どう防ぐか・どう検知するか」という防御的視点にとどめる。「これを導入すれば絶対に破られない」といった誇張はせず、「対策は突破の確率とコストを上げるが、ゼロにはしない」という前巻の正直な水準を、本巻でも引き継ぐ。
> 接続先: →BOOK-0360『情報防衛と復旧シリーズ 第1巻 情報セキュリティ総論』(信頼境界・最小権限・CIA三要素という本巻全体の前提はそちらに詳しい)、→BOOK-0006/0340『OS』(プロセス・ユーザーごとの権限分離という土台の上に、本巻のアクセス制御モデルが乗る)、→BOOK-0073/0133『情報派生 暗号』第1・2巻(ハッシュ化・公開鍵暗号という数学的な道具はそちらに詳しい。本巻は同じ道具を「認証にどう使うか」という設計判断の側から位置づけ直す)、→次巻BOOK-0362『脆弱性の防御的理解と対策』(本巻で扱う認証の仕組みに欠陥があった場合、何が起こりうるかを防御的視点でさらに掘り下げる)。
> 水準: 一〜十二(識別・認証・認可の三分離という出発点から、達人術としての認証技術の進化のメタ的推移までを、一冊で貫通する)。
---
## 入口の物語 — 名札と鍵と、扉の向こうにある部屋
前巻(BOOK-0360)の入口の物語では、鍵をかけ忘れた家と、鍵を厳重にかけても入られた家という、一見矛盾した経験から出発した。本巻では、その「鍵」という言葉そのものを、もう一段掘り下げるところから始めたい。
ある会社のオフィスビルを思い浮かべてほしい。受付では、来訪者がまず名札を提示し、「私は誰々です」と名乗る。次に受付の担当者が、その名札の顔写真と本人の顔を見比べ、あるいは事前に届いていた訪問予定と照らし合わせて、「確かに本人である」ことを確認する。そして最後に、確認が済んだ来訪者に対して、「何階のどの部屋までなら入ってよいか」を記したゲスト用のICカードを手渡す——応接室までは入れるが、サーバー室には入れない、というように。
この三つの場面は、一見すると一つの手続きのように見えるが、実は性質のまったく異なる三つの工程である。「私は誰々です」と名乗る場面、それが本当に本人かどうかを確かめる場面、そして「どこまで入ってよいか」を決める場面——この三つを一つの動作として済ませてしまうと、たとえば「名乗っただけの人を、確認もせずに、無条件にどこへでも通してしまう」という重大な穴が生まれかねない。逆に、この三つを明確に分けて設計しておけば、名乗りの内容に不備があればその時点で止められ、本人確認まで済んでいても行き先の権限は別途チェックされる、という何重もの安全策が自然に働くようになる。
本巻がこれから一歩ずつたどるのは、まさにこの三つの工程——識別・認証・認可——を、正しく切り分けて設計するための言葉である。名乗りの中身が推測されやすい弱いパスワードだったらどうするか(第三章)、名乗りに加えてもう一つの証拠を求めるにはどうするか(第四章)、確認が済んだ状態をどう安全に保ち続けるか(第五章)、「どこまで入ってよいか」をどう体系立てて決めるか(第六章)、特に強い権限を持つ立場をどう別枠で扱うか(第七章)、これらの対策が実際にどれだけの効果を持つのかを感覚ではなく数字で検算する姿勢(第八章)、複数のシステムをまたいで名乗りを一度で済ませる工夫(第九章)、「社内にいるから安全」という思い込みを手放し毎回確かめ続ける最新の設計思想(第十章)、パスワードそのものを手放す現代最先端の技術(第十一章)、そして最後に、なぜ認証技術がこの順序で進化してきたのかというメタ的な視点(第十二章)まで、一冊を通じて積み上げていく。
前巻で学んだ「鍵をかけ忘れた家」の教訓は、本巻でも生き続けている。名札(識別)・本人確認(認証)・入室許可(認可)という三つの鍵を、それぞれ別の性質の鍵として重ねて使うことこそが、前巻第四章で学んだ多層防御を、認証という具体的な領域に落とし込んだ姿にほかならない。
---
## 第一章: 識別・認証・認可の三分離 — 名乗る・確かめる・決めるを分ける(水準一)
### なぜ三つに分けるのか
入口の物語で見たとおり、「あなたは誰か」を扱う仕組みは、実は一つの動作ではなく、性質の異なる三つの工程に分解できる。利用者がシステムに対して、自分が誰であるかを申告する行為を、**識別(しきべつ、水準一: 利用者がシステムに対して、自分が誰であるかを申告する行為)**と呼ぶ。利用者名(ユーザーID)やメールアドレスを入力欄に打ち込む行為が、この識別にあたる。
申告された本人が、確かに本人であることを確認する行為を、**認証(にんしょう、水準一: 申告した本人が、確かに本人であることを確認する行為)**と呼ぶ。パスワードの入力や、後述する生体情報の読み取りは、この認証の段階で行われる。
確認された本人に対して、どの操作・どの資源へのアクセスを許すかを決定する行為を、**認可(にんか、水準一: 確認された本人に対して、どの操作・どの資源へのアクセスを許すかを決定する行為)**と呼ぶ。オフィスビルの例でいえば、ゲスト用のICカードが「応接室までは入れるが、サーバー室には入れない」と決めている部分が、この認可にあたる。
### 三つを分ける理由
識別・認証・認可を一つの動作にまとめてしまうと、前巻第四章で扱った単一障害点(たんいつしょうがいてん)と同じ危うさが生まれる。名乗り(識別)が誤っていた場合でも、確認(認証)や権限決定(認可)という別の工程がその後に控えていれば、そこで誤りを食い止められる。三つを別々の工程として設計しておくことは、前巻第四章の多層防御という考え方を、認証という具体的な領域にそのまま当てはめたものである。
認証の際に提示する、本人であることを裏付けるための情報の総称を、**資格情報(しかくじょうほう、水準一: 認証の際に提示する、本人であることを裏付けるための情報〈パスワード・鍵・生体データなど〉の総称)**と呼ぶ。英語では credential(クレデンシャル)と呼ばれ、この語はセキュリティの実務文書で頻繁に使われる。資格情報という言葉が広く使われるのは、パスワードだけでなく、後述する所持要素・生体要素まで含めた、認証に使うあらゆる証拠を一つの言葉でまとめて扱う必要があるからである。
### 識別の入り口を検証する
識別の段階で入力される利用者名やメールアドレスも、外部から到達可能な入力である以上、前巻第七章で扱った信頼境界を越える入力の一種である。本プロジェクトの関数辞書に索引されている、外部から受け取ったデータがあらかじめ定義した構造の規則に適合しているかどうかを検査する仕組み(索引: FUNC-0387「スキーマ検証」)は、識別段階の入力(利用者名の文字種・長さの制限など)にもそのまま応用できる。識別の入力を検証しておくことは、その後に続く認証・認可の工程が、そもそも成り立たない形式の入力によって混乱させられることを防ぐ、地味だが確実な予防策である。
### コラム — AuthNとAuthZという実務上の略称
英語圏のセキュリティ実務の現場では、認証(Authentication)を「AuthN」、認可(Authorization)を「AuthZ」と略して呼び分ける慣習が広く使われている。語尾の「N」と「Z」だけで区別するというやや紛らわしい略称だが、この略称が定着していること自体が、「認証と認可は別物である」という区別を、実務家が日常的に意識し続けていることの表れである。本巻でも、両者を混同しないよう、章を分けて丁寧に扱っていく。
### コラム — 三分離が崩れるとどうなるか、を一般論として考える
三分離のどこかが崩れると何が起こりうるかを、具体的な悪用手順ではなく、一般的な構造としてだけ理解しておくことには意味がある。たとえば、認可の判断が、認証の結果を正しく参照せずに行われる設計になっていたとすれば、「確認が済んでいない申告」に対して権限が与えられてしまう、という事態が理論上は起こりうる。この種の不具合を防ぐ設計原則については、第七章で扱う特権昇格の防御と合わせて、防御的な視点からさらに掘り下げる。ここで押さえておくべきなのは、「三つの工程を明確に分け、それぞれが独立して正しく機能しているかを個別に確認できる設計にしておく」ことが、崩れを未然に防ぐ最も基本的な備えだという点である。
---
> **定着量の目安(第一章)**: 自分が普段使っているサービスへのログイン画面を一つ思い浮かべ、「利用者名を入力する場面(識別)」「パスワードを入力する場面(認証)」「ログイン後にできることとできないことが分かれている場面(認可)」の三つを、実際の画面の動きに沿って書き出してみると、三分離が抽象論でなく具体的な画面操作として理解しやすくなる。
---
## 第二章: 三要素認証 — 知っている・持っている・その人自身であるか(水準二)
### 認証を支える三種類の証拠
第一章で「認証とは、申告した本人が確かに本人であることを確認する行為」だと述べたが、その確認には、いったいどんな種類の証拠が使えるのだろうか。本人だけが知っているはずの情報を提示することで認証する要素を、**知識要素(ちしきようそ、水準二: 本人だけが知っているはずの情報を提示することで認証する要素〈パスワード・PINなど〉)**と呼ぶ。本人だけが持っているはずの物を提示することで認証する要素を、**所持要素(しょじようそ、水準二: 本人だけが持っているはずの物を提示することで認証する要素〈ICカード・スマートフォン・ハードウェアトークンなど〉)**と呼ぶ。本人の身体的・行動的な特徴そのものを用いて認証する要素を、**生体要素(せいたいようそ、水準二: 本人の身体的・行動的な特徴そのものを用いて認証する要素〈指紋・顔・虹彩など〉)**と呼ぶ。
この三種類——知識要素・所持要素・生体要素——の総称を、**三要素認証(さんようそにんしょう、水準二: 知識要素・所持要素・生体要素という、性質の異なる三種類の認証手段の総称)**と呼ぶ。英語ではしばしば「something you know / something you have / something you are」という、覚えやすい三つの言い回しで紹介される。
### 三要素はそれぞれ違う弱さを持つ
三要素認証の要点は、この三種類が、それぞれまったく異なる性質の弱点を抱えているという事実にある。知識要素(パスワードなど)は、本人が忘れてしまう、あるいは他人に推測されてしまう可能性がある。所持要素(ICカードなど)は、紛失や盗難によって物理的に失われる可能性がある。生体要素(指紋など)は、一度登録した特徴を、パスワードのように後から変更することができないという、他の二要素にはない特有の制約を持つ。どの要素も単独では完全ではない、というこの事実こそが、次章以降で扱うハッシュ化やMFA(多要素認証)が必要になる、そもそもの出発点である。
### コラム — 生体要素は「変更できない」という特殊さ
パスワードを忘れたり、他人に知られてしまったりした場合、利用者はパスワードを変更すればよい。ICカードを紛失した場合も、カードを無効化して新しいカードを再発行すればよい。ところが生体要素は、指紋や顔立ちといった身体的な特徴そのものを認証に使っているため、パスワードのように「別の値に変更する」ということが原理的にできない。この特殊さゆえに、生体要素をどう安全に扱うか(たとえば、生体情報そのものではなく、生体情報から計算された特徴量だけをシステム側に保存する設計など)は、生体認証を扱う実務において特に慎重な設計が求められる領域である。
### コラム — 二要素と三要素は、種類の数であって回数ではない
多要素認証を初めて学ぶときによくある誤解に、「同じ種類の証拠を二回求めれば、二要素認証になる」というものがある。たとえば、パスワードを二回連続で入力させることは、知識要素を二回使っているだけであり、性質の異なる要素を組み合わせているわけではない。この誤解を避けるための考え方は、前巻第四章で扱った「層の性質をあえて変える」という教訓——同じ種類の鍵を三つ並べても、その鍵をこじ開ける一つの技術さえあれば三つとも同時に破られる——と、まったく同じ構造を持っている。多要素認証の効果は、要素の「数」ではなく「種類の違い」によって生まれる、という点は、第四章で正式に扱う。
---
> **定着量の目安(第二章)**: 自分が使っている認証手段(パスワード、指紋認証、スマートフォンでの承認など)を三つ以上書き出し、それぞれが知識要素・所持要素・生体要素のどれに当たるかを分類してみると、三要素認証という枠組みが具体的な体験と結びついて理解しやすくなる。
---
## 第三章: パスワードの弱点とハッシュ化・ソルト・ストレッチング(水準三)
### 知識要素という選択の弱さ
知識要素の代表であるパスワードは、導入のしやすさから今も広く使われているが、いくつかの構造的な弱さを抱えている。同一のパスワードを複数のサービスで繰り返し使う利用習慣は、一つのサービスから漏えいした場合の被害が他のサービスにまで連鎖する原因になりうる。また、覚えやすさを優先するあまり、短く単純な文字列を選んでしまう傾向も、広く知られた弱点である。これらの弱点は、利用者の不注意だけを責めて済む話ではなく、サービスを設計する側が、パスワードという仕組みそのものの限界を前提に、防御の仕組みを組み込んでおく必要がある、というのが本章の主題である。
### パスワードを保存する側の責任 — ハッシュ化
サービス側がパスワードをそのまま(平文で)保存してしまうと、そのデータベース自体が漏えいした場合、利用者のパスワードがそのまま流出してしまう。これを防ぐために、前巻第二章で定義した、任意長のデータを固定長の要約値に変換する一方向の写像(索引: FUNC-0188「ハッシュ化の概念」)を応用し、利用者が入力した生のパスワードを保存せず、ハッシュ化によって得られる要約値だけをシステム側に保存する設計を、**パスワードハッシュ化(ぱすわーどはっしゅか、水準三: 利用者が入力した生のパスワードを保存せず、ハッシュ化によって得られる要約値だけをシステム側に保存する設計)**と呼ぶ。ログインのたびに、入力されたパスワードを同じ手順でハッシュ化し、保存されている要約値と一致するかどうかだけを確認すればよいので、サービス側は一度も生のパスワードそのものを保持する必要がない。
### 同じパスワードを見分けにくくする — ソルト
パスワードハッシュ化だけでは、実は一つ弱点が残る。同じパスワードを使っている利用者が複数いた場合、その全員のハッシュ値がまったく同じ値になってしまい、あらかじめ大量のパスワード候補とそのハッシュ値の対応表を用意しておく(事前計算による対応表を用意しておく)という防御回避の余地が生まれる。これを防ぐために、同じパスワードでも利用者ごとに異なるハッシュ値になるよう、ハッシュ化の前に付加するランダムな値を、**ソルト(salt、水準三: 同じパスワードでも利用者ごとに異なるハッシュ値になるよう、ハッシュ化の前に付加するランダムな値)**と呼ぶ。ソルトを利用者ごとに異なる値にしておけば、同じパスワードを使う利用者が複数いても、保存されるハッシュ値はそれぞれ異なるものになり、あらかじめ用意された対応表を使った照合の効率を大きく落とすことができる。
### 計算コストそのものを引き上げる — ストレッチング
ソルトは「同じ表を使い回されにくくする」対策だが、もう一つ、ハッシュ計算そのものにかかる時間を意図的に引き延ばす対策がある。ハッシュ化の計算を意図的に何度も繰り返し、1回あたりの計算コストを高めることで、総当たり的な照合1回あたりのコストを引き上げる防御技術を、**ストレッチング(key stretching、水準三: ハッシュ化の計算を意図的に何度も繰り返し、1回あたりの計算コストを高めることで、総当たり的な照合1回あたりのコストを引き上げる防御技術)**と呼ぶ。
### 検算的な小演習 — ストレッチングが計算コストに与える影響を概算する
ストレッチングの効果を、具体的な数値で検算してみよう。1回のハッシュ計算に要する時間を仮に1マイクロ秒(100万分の1秒)とする。
```
ストレッチングなし(1回のみ): 1回 × 1マイクロ秒 = 1マイクロ秒
ストレッチング1万回: 10,000回 × 1マイクロ秒 = 10,000マイクロ秒 = 10ミリ秒
ストレッチング10万回: 100,000回 × 1マイクロ秒 = 100,000マイクロ秒 = 100ミリ秒
```
正規の利用者が1回ログインする際にかかる時間は、10ミリ秒程度であれば、体感としてはほとんど気づかない範囲に収まる。しかし、この「1回あたりのコスト」が、大量の候補を機械的に試そうとする側にとっては、候補の数だけ積み重なっていく。ストレッチングを1万回にするだけで、1回あたりのコストが1万倍に引き上げられる——この「正規の利用者にはほぼ影響がないが、大量の機械的な試行を行う側にとっては負担が積み重なる」という非対称性こそが、ストレッチングという防御技術の設計思想である。なお、この演習はあくまで防御側の設計判断を検算するためのものであり、実際の攻撃の実行手順や成功率の見積もりには立ち入らない。
### 攻撃回数そのものを制限する — レート制限とリトライの間隔
ハッシュ化・ソルト・ストレッチングが「1回あたりの計算コスト」を引き上げる対策であるのに対し、そもそも短時間に試行できる回数そのものを制限してしまう対策もある。一定時間内に許容する処理の回数に上限を設ける仕組み(索引: FUNC-0255「レート制限」)を、ログイン試行に適用すれば、短時間に大量の試行を繰り返すこと自体を難しくできる。さらに、処理が失敗するたびに再試行までの待ち時間を段階的に引き延ばす仕組み(索引: FUNC-0384「リトライ〈retry with backoff〉」)を組み合わせれば、失敗が続くほど次の試行までの間隔が広がっていく。前巻第四章で扱った多層防御そのままに、ハッシュ化・ソルト・ストレッチング(照合側の計算コストを上げる層)と、レート制限・リトライ間隔の調整(試行の回数と頻度を絞る層)という、性質の異なる二つの層を重ねることで、パスワードという弱い知識要素を、少しでも現実的な強度に引き上げることができる。
### コラム — 一定回数の失敗でアカウントを一時的にロックする設計
多くのサービスでは、一定回数ログインに失敗すると、そのアカウントへのそれ以上の試行を一時的に受け付けなくする設計が取り入れられている。この「一時的に締め出す」という発想は、本プロジェクトの関数辞書に索引されている、複数の処理が同時に同じ資源へアクセスすることを防ぐ仕組み(索引: FUNC-0298「排他ロック〈mutex lock/unlock〉」)と、発想の根っこの部分で似ている——どちらも「ある条件が満たされている間は、それ以上の操作を受け付けない」という制御である。ただし、この種のロックアウトの仕組みは、正規の利用者が何らかの理由で連続して入力を誤った場合にも作動してしまうため、可用性(前巻第二章)とのバランスを考慮した設計が必要になる、という実務上の注意点も付け加えておきたい。
---
> **定着量の目安(第三章)**: ハッシュ化・ソルト・ストレッチングという三つの対策が、それぞれ「何を」防いでいるのかを一行ずつ自分の言葉で説明できるようにしておく(ハッシュ化=平文保存を防ぐ、ソルト=対応表の使い回しを防ぐ、ストレッチング=1回あたりの計算コストを引き上げる)と、三つを混同せずに整理できる。
---
## 第四章: 多要素認証(MFA)の仕組み(水準四)
### 種類の異なる要素を組み合わせる
第二章で見た三要素認証のうち、性質の異なる2種類以上を組み合わせて認証を行う仕組みを、**多要素認証(たようそにんしょう、水準四: 知識要素・所持要素・生体要素のうち、性質の異なる2種類以上を組み合わせて認証を行う仕組み〈MFA〉)**と呼ぶ。パスワード(知識要素)に加えて、スマートフォンに送られてくるコード(所持要素)の入力を求める仕組みは、多要素認証の代表的な実例である。
第二章のコラムで触れたとおり、多要素認証の効果は「要素の数」ではなく「要素の種類の違い」から生まれる。パスワードを破ろうとする側にとって、知識要素だけを突破すればよい状況と、知識要素に加えて所持要素まで同時に突破しなければならない状況とでは、後者のほうがはるかに難易度が高い——これは前巻第四章の多層防御が、認証という文脈で具体的な形をとった姿である。
### 使い捨ての値という発想 — ワンタイムパスワード
多要素認証でよく使われる仕組みに、一度使用すると無効になる、その場限りのパスワードがある。これを、**ワンタイムパスワード(OTP、水準四: 一度使用すると無効になる、その場限りのパスワード)**と呼ぶ。ワンタイムパスワードは、たとえその値が一度誰かの目に触れてしまったとしても、次のログインでは別の値が必要になるため、パスワードのように長期間同じ値を使い続けることで生じるリスクを小さくできる。
ワンタイムパスワードの中でも特によく使われる方式に、現在時刻をもとに、一定の時間間隔(多くは30秒程度)ごとに新しい値へ切り替わるものがある。これを、**時間ベースワンタイムパスワード(TOTP、水準四: 現在時刻をもとに、一定の時間間隔ごとに新しい値へ切り替わるワンタイムパスワード)**と呼ぶ。TOTPは、認証アプリと呼ばれるスマートフォン向けのソフトウェアで広く実装されている方式であり、事前に登録した鍵情報と現在時刻から、双方が独立に同じ値を計算できるという性質を利用している。この「一定時間だけ有効」という性質を実装する際には、本プロジェクトの関数辞書に索引されている、指定した時間を超えたら処理を打ち切る仕組み(索引: FUNC-0297「タイムアウト付き実行〈timeout wrapper〉」)と同種の「時間の窓」を扱う考え方が、コードの実装レベルでは応用されている。
### 多要素認証の手段ごとの相対的な性質
多要素認証には、SMSで届く確認コード、認証アプリが生成するTOTP、スマートフォンへのプッシュ通知による承認、専用のハードウェアトークンなど、複数の実現方式がある。これらの方式は、いずれも知識要素に所持要素(あるいは生体要素)を組み合わせるという点では共通しているが、それぞれの方式が持つ相対的な堅牢さには違いがあるという事実は、防御側の設計判断として押さえておく価値がある。たとえば、電話回線を経由するSMSによる確認コードは、携帯電話網に関する別種の手続き上の脆弱性の影響を受けうることが、業界内で広く知られている。この違いは、どの認証方式を採用するかを決める際の判断材料であり、第十一章で扱うパスキー・FIDO2は、この相対的な堅牢さをさらに一段引き上げる目的で登場した技術である。
### コラム — 「もう一つの証拠」は、便利さとのトレードオフでもある
多要素認証は防御力を高める一方で、利用者にとっては、ログインのたびに一手間増えることを意味する。前巻第二章で扱ったとおり、機密性を高めようとする対策は、しばしば可用性(使い勝手)を犠牲にする形で現れる。多要素認証を「常に」求めるのではなく、普段と異なる端末や場所からのアクセスなど、リスクが高いと判断される場面でだけ追加の確認を求める、という設計上の工夫も広く行われている。この工夫は、第十章で扱うゼロトラストの考え方——所在地だけで信頼を判断せず、状況に応じてその都度検証する——と地続きの発想である。
---
> **定着量の目安(第四章)**: 自分が使っているサービスのうち、多要素認証が設定できるものを一つ選び、実際に設定画面を開いて(設定を変更する必要はなく、確認するだけでよい)、どの方式(SMS・認証アプリ・プッシュ通知など)が提供されているかを確認してみると、本章の内容が抽象論でなく具体的な選択肢として理解しやすくなる。
---
## 第五章: セッション管理とトークン(水準五)
### 認証のたびに毎回すべてをやり直さない
第一章から第四章までは、識別と認証という「最初の一回」に焦点を当ててきた。しかし実際のシステムでは、利用者は一度ログインしたあと、何度もページを移動したり操作を行ったりする。そのたびにパスワードとMFAをすべてやり直すのは現実的ではない。そこで、認証に成功してから、利用者とシステムとの間で一定期間有効に保たれる、やり取りのひとまとまりという考え方が使われる。これを、**セッション(session、水準五: 認証に成功してから、利用者とシステムとの間で一定期間有効に保たれる、やり取りのひとまとまり)**と呼ぶ。
セッションを識別するために発行される、推測されにくいランダムな値を、**セッショントークン(session token、水準五: セッションを識別するために発行される、推測されにくいランダムな値)**と呼ぶ。セッショントークンは、いわば「認証を済ませたことを示す、その場限りの通行証」であり、これ以降のやり取りでは、パスワードの再入力の代わりに、このトークンを提示することで本人であることを示す。
### トークンには強い乱数が要る
セッショントークンが果たすべき最も重要な性質は、「他人に推測されない」ことである。本プロジェクトの関数辞書には、値のランダムな識別子を生成する仕組み(索引: FUNC-0287「ランダムID生成〈random ID/UUID〉」)や、生成した識別子どうしが偶然一致してしまうことを避ける仕組み(索引: FUNC-0289「衝突回避ID生成〈collision-avoiding ID〉」)が索引されている。これらはいずれも「一意性」を目的とした技術だが、セッショントークンにはさらに一段厳しい要件——「一意であるだけでなく、次にどんな値が来るかを外部から予測できない」という要件が加わる。
本プロジェクトの過去の記録には、この違いを考えるうえで示唆に富む実例がある。前巻第六章で紹介した、決定的な乱数生成の関数(索引: FUNC-0278「シード付き決定的乱数〈seeded RNG/mulberry32〉」)は、同じ種(シード)を与えれば毎回同じ数列を再現できるという性質を持ち、ゲームのリプレイや検証可能性が重要な場面では、この「再現できる」という性質こそが価値になる。ところが、この同じ性質は、セッショントークンのような「他人に予測されては困る」値の生成には、まったく向いていない。もし種の情報が推測できてしまえば、後続の値の並びも理論上は再現できてしまうからである。セッショントークンのような、安全性が求められる値の生成には、再現性ではなく予測不可能性を重視した、暗号論的に安全な乱数生成の仕組みを使うべきである、というのが本節の教訓であり、この対比は、前巻の「緑を騙る赤」の教訓——検定を通過していたにもかかわらず内部には別の性質の欠陥が潜んでいた、という現象——とも通じる、「用途に応じて適切な性質の道具を選ぶ」ことの重要性を示している。
### 検算的な小演習 — トークン空間の広さを桁で見積もる
セッショントークンの安全性を、具体的な数値で検算してみよう。128ビットのランダムな値を使う場合、取りうる値の総数は `2^128` 通りにのぼる。
```
2^10 ≈ 1,000(約千)
2^20 ≈ 100万
2^40 ≈ 1兆
2^80 ≈ 1兆の1兆倍(約10の24乗)
2^128 ≈ 3.4 × 10^38 通り
```
仮に、1秒間に10億(10^9)個のトークンを発行し続けたとしても、`2^128 ÷ 10^9 ≈ 3.4 × 10^29` 秒かかる計算になり、これは宇宙の年齢(約140億年 ≈ 4.4 × 10^17秒)をはるかに超える桁数である。この演習が示しているのは、「十分な長さのランダムな値を使えば、偶然の一致(衝突)や総当たり的な推測を、現実的な時間の範囲では考えなくてよい水準まで引き下げられる」という、乱数の桁数と安全性の関係である。ただし、この安全性はあくまで「値の空間が十分広い」という前提の上に成り立っており、乱数の生成方法そのものが予測可能であれば、この計算はまったく意味を失う——だからこそ、前段で述べた「予測不可能性を重視した乱数生成」が欠かせない。
### セッションを終わらせる — タイムアウトと無効化
セッションは、いつまでも有効であってはならない。一定時間操作がない場合に、セッションを自動的に無効化する仕組みを、**セッションタイムアウト(session timeout、水準五: 一定時間操作がない場合に、セッションを自動的に無効化する仕組み)**と呼ぶ。この仕組みの実装には、前章でも触れた、指定した時間を超えたら処理を打ち切る仕組み(索引: FUNC-0297「タイムアウト付き実行」)や、処理の取り消しと時間切れを統一的に扱う仕組み(索引: FUNC-1347「キャンセルとタイムアウト」)と同種の「時間で区切る」設計が使われる。
一方、利用者が明示的にログアウトを選んだ場合など、時間経過を待たずにセッションを終わらせる必要もある。ログアウトなどの操作によって、有効だったセッショントークンを明示的に使えなくする処理を、**セッション無効化(session invalidation、水準五: ログアウトなどの操作によって、有効だったセッショントークンを明示的に使えなくする処理)**と呼ぶ。この「有効だったものを、明示的な操作によって無効なものへ切り替える」という発想は、本プロジェクトの関数辞書に索引されている、保存済みの値を最新でないものとして扱い直す仕組み(索引: FUNC-0244「キャッシュ無効化〈cache invalidate〉」)と、構造的によく似ている——どちらも「以前は有効だったものを、明示的な操作によって無効な状態へ切り替える」という同じ骨格を共有している。
### コラム — セッションが乗っ取られるとはどういう状態か、を防御的に理解する
セッショントークンが何らかの理由で第三者の手に渡ってしまうと、その第三者はパスワードを知らなくても、トークンを提示するだけで正規の利用者になりすませてしまう——これが、セッション管理を軽視できない理由である。この状態への備えとして、通信経路を暗号化したうえでのみトークンをやり取りする、トークンに有効期限を設ける、普段と異なる環境からの利用を検知したら再認証を求める、といった防御策が広く実務で使われている。具体的な奪取の手口そのものには立ち入らず、「なぜトークンの扱いに注意が必要なのか」という構造だけを理解しておくことが、本章の目的である。
---
> **定着量の目安(第五章)**: 自分が普段使っているサービスで、しばらく操作しないと自動的にログアウトされる(セッションタイムアウト)ことを経験した場面を思い出し、それがなぜ必要な仕組みなのかを自分の言葉で説明できるようにしておくと、セッション管理という抽象的な概念が実体験と結びつく。
---
## 第六章: 認可モデル — RBACとABACの違い(水準六)
### 「誰に」ではなく「役割に」権限を紐づける
第一章で定義した認可を、実際の組織やシステムでどう体系立てて設計するかを扱うのが本章である。利用者に役割(ロール)を割り当て、権限をロールに紐づけて管理する認可モデルを、**ロールベースアクセス制御(RBAC、水準六: 利用者に役割〈ロール〉を割り当て、権限をロールに紐づけて管理する認可モデル)**と呼ぶ。「編集者」「閲覧者」「管理者」といったロールをあらかじめ定義しておき、個々の利用者にはロールだけを割り当てる——この仕組みにより、利用者が増えるたびに一人ひとりへ個別に権限を設定し直す手間を省ける。
RBACの実装でよく使われる区別に、資源を読み取るだけの権限と、資源を書き換える権限を分ける、というものがある。本プロジェクトの関数辞書に索引されている、複数の読み取りは同時に許すが、書き込みは排他的に一つだけを許す制御方式(索引: FUNC-1338「読み書きロック〈reader-writer lock〉」)は、直接RBACを実装する技術ではないものの、「読む」権限と「書く」権限という、性質の異なる二種類の操作を明確に区別して扱うという発想において、RBACのロール設計と共通する構造を持っている——ロールを設計する際にも、まず「読み取りだけでよい操作」と「書き換えを伴う操作」を分けて考えることが、実務上の出発点になることが多い。
### 状況に応じて動的に判断する — ABAC
RBACが「あらかじめ定義したロール」に基づく静的な仕組みであるのに対し、もう一つの認可モデルとして、利用者・資源・環境の属性の組み合わせを条件式として評価し、その都度アクセスの可否を判定する認可モデルがある。これを、**属性ベースアクセス制御(ABAC、水準六: 利用者・資源・環境の属性の組み合わせを条件式として評価し、その都度アクセスの可否を判定する認可モデル)**と呼ぶ。「平日の営業時間内で、かつ社給端末からのアクセスであれば、この資源への書き込みを許可する」といった、複数の条件を組み合わせた柔軟な判定は、ABACの得意分野である。
### RBACとABACの使い分け
RBACは、ロールの一覧さえ見れば「誰が何をできるか」がひと目で把握しやすく、組織の役割分担が比較的固定的な場面に向いている。一方ABACは、状況に応じた柔軟な判定ができる代わりに、条件式が複雑になりやすく、「結局のところ誰が何をできるのか」を一覧で把握することが難しくなりがちである。前巻第五章で扱った定性的評価と定量的評価の使い分けと同様に、実務ではまずRBACで大枠を整理し、RBACだけでは表現しきれない例外的な条件だけをABAC的な条件式で補う、という二段構えがよく採用される。
### コラム — RBACという考え方が整理された経緯
役割に権限を紐づけて管理するという発想自体は、組織における職務分担として古くから存在していたが、これを情報システムのアクセス制御モデルとして体系立てて整理したのは、1990年代前半に米国国立標準技術研究所(NIST)の研究者らによる論文群だとされる。それ以前のアクセス制御は、資源ごとに「誰が」「何をできるか」を個別に列挙する方式(アクセス制御リストと呼ばれる)が主流だったが、利用者の数が増えるにつれて、この個別列挙方式は管理しきれなくなっていった。役割という一段抽象化した単位を間に挟むことで、利用者の増減や異動があっても、ロールの割り当てを変更するだけで済むようになる——この「個々の利用者を直接列挙せず、間に一段抽象化した単位を挟む」という発想は、実務上のアクセス制御の管理コストを大きく引き下げた、RBACという考え方の最大の貢献だとされている。
### コラム — 認可モデルは前巻の最小権限の原則を実装する道具である
前巻第八章で扱った最小権限の原則——利用者やプログラムに対して、その時々の作業に本当に必要な権限だけを与えるという考え方——は、それ自体は抽象的な理念であり、単独では実装にならない。RBACやABACは、この理念を実際のシステムの中で機械的に判定可能な形にするための、具体的な道具立てである。ロールの設計が粗すぎれば(たとえば「一般社員」というロール一つに広範な権限をまとめてしまえば)、最小権限の原則は理念のまま実現されない。ロールを適切な粒度に分割し、それぞれのロールに本当に必要な権限だけを紐づける作業こそが、最小権限の原則を現場で実現する実務そのものである。
---
> **定着量の目安(第六章)**: 自分が所属する組織やチームで使われているサービス(共有フォルダ、チャットツールなど)を一つ選び、そこにどんなロール(管理者・メンバー・閲覧者など)が存在するかを書き出し、それぞれのロールにどんな権限が紐づいているかを整理してみると、RBACという考え方が具体的な実例として理解しやすくなる。
---
## 第七章: 最小権限の原則と特権管理・特権昇格の防御(水準七)
### 強い権限を持つアカウントを、別枠で扱う
前巻第八章で定義した最小権限の原則は、本巻のRBAC・ABACという道具立てによって、日常的な権限の粒度では実現できる。しかし、システム全体の設定を変更できるような、通常より強い権限を持つアカウントは、日常的なロール設計とは別に、特別な注意を払って管理する必要がある。システム全体に強い影響を及ぼせる、通常より強い権限を持つアカウントを、**特権アカウント(とっけんあかうんと、水準七: システム全体に強い影響を及ぼせる、通常より強い権限を持つアカウント)**と呼ぶ。特権アカウントを通常のアカウントと区別して別枠で管理し、必要なときだけ一時的に権限を昇格させる実務を、**特権管理(とっけんかんり、水準七: 特権アカウントを通常のアカウントと区別して別枠で管理し、必要なときだけ一時的に権限を昇格させる実務)**と呼ぶ。
特権管理の実務でよく使われる工夫に、普段は権限の低いアカウントで作業し、システムの設定変更など、特権が必要な操作を行うときだけ、一時的に権限を借りて作業を終えたらすぐに手放す、というものがある。この「常に強い権限で作業しない」という姿勢は、前巻第八章のOS実例(管理者アカウントと一般利用者アカウントの使い分け)で紹介した考え方の、組織的な特権管理への拡張である。
### 権限チェックの抜け漏れを構造的に防ぐ
本来はより弱い権限しか持たないはずの利用者やプログラムが、意図しない形でより強い権限に相当する操作を行えてしまう状態を、**特権昇格(とっけんしょうかく、水準七: 本来はより弱い権限しか持たないはずの利用者やプログラムが、意図しない形でより強い権限に相当する操作を行えてしまう状態)**と呼ぶ。特権昇格がどのような具体的な手口で引き起こされるかについては、本シリーズの安全枠に基づき立ち入らない。ここで扱うのは、あくまで「なぜそれが起こりうるのか」という構造と、「どう防ぐか」という設計原則である。
特権昇格の多くは、権限のチェックがシステムの一部だけで行われ、別の経路からは同じチェックが素通りされてしまう、という抜け漏れから生じるとされる。前巻第七章のコラムで紹介した、境界を越えるすべてのアクセスに対して例外なく検証を適用しなければならないという原則(完全な仲介)は、この特権昇格の防御においても中心的な考え方である。加えて、本プロジェクトの関数辞書に索引されている、複数の資源に対するロックを常に決まった順序で取得することで、順序の食い違いによる不具合を防ぐ規律(索引: FUNC-1344「ロック順序規律〈lock ordering discipline〉」)は、直接権限チェックのための技術ではないものの、「チェックや処理の順序を厳密に固定し、状況によって抜け道が生まれないようにする」という設計思想において、権限チェックの一貫性を保つ実務と共通する構造を持っている。
権限の確認と、確認結果に基づく操作の実行が、途中で他の処理に割り込まれることなく、ひとまとまりの単位として実行されることも重要である。本プロジェクトの関数辞書に索引されている、複数の処理を分割されない一つの単位として実行する仕組み(索引: FUNC-1339「アトミック操作」)は、権限チェックの設計において、「確認した瞬間と、実際に操作が行われる瞬間との間に、状態が変わってしまう隙を作らない」という原則の技術的な土台になる。確認と実行の間に別の変更が割り込めてしまう設計は、確認そのものを形骸化させてしまう——これは前巻第七章の「完全な仲介」を、時間軸の観点から補強する考え方である。
### 特権管理も職務分掌で支える
前巻第八章で紹介した職務分掌(一人の担当者に権限を集中させず、複数の担当者に分けて互いに牽制させる仕組み)は、特権管理においても重要な役割を果たす。特権アカウントの発行・使用・棚卸しを一人の担当者だけに任せてしまうと、その担当者自身が単一障害点になる。本プロジェクトの検定文化における、検定を行う側と実装する側を独立させる仕組み(索引: FUNC-1100「検定の鍵分離〈test oracle separation from implementation〉」)は、職務分掌の一つの実例として前巻でも紹介されたが、特権管理の文脈では、「特権を要求する担当者」と「特権の付与を承認する担当者」を分けるという、同じ発想の別の実装として応用できる。
### コラム — 権限は「使われなくなっても自動では消えない」
前巻第八章で「なぜ権限は際限なく広がりやすいのか」というコラムを扱ったが、特権アカウントについても同じ問題が起こりやすい。ある業務のために一時的に特権を付与されたにもかかわらず、その業務が終わっても特権が回収されないまま放置される、という積み重ねは、特権管理における最も基本的で、最も見落とされやすい課題である。定期的に特権アカウントの一覧を棚卸しし、使われていない特権を回収する作業は、地味だが特権昇格のリスクを構造的に減らす、最も費用対効果の高い対策の一つとされている。
---
> **定着量の目安(第七章)**: 自分が管理しているアカウントのうち、通常より強い権限(管理者権限、共有フォルダの編集権限など)を持つものを一つ選び、「その権限は今も本当に必要か」を棚卸しし、不要であれば権限を落とす実践をしておくと、特権管理という考え方が抽象論でなく自分の手で実行できることが確認できる。
---
## 第八章: 補助技術の定量効果 — 公表値からの検算(水準八)
### 感覚ではなく数字で語る
ここまでの章では、パスワードの弱点、MFA、セッション管理、認可モデル、特権管理という、いくつもの補助技術を見てきた。これらの対策は、いずれも「導入すれば安全になる」という定性的な説明にとどまりがちだが、専門職としては、可能な限り定量的な検算に基づいて効果を語る姿勢が求められる。前巻第五章で扱った定性的評価と定量的評価の使い分けを思い出しつつ、本章では、実際に公表されている数値をもとに、対策の効果を検算するという作業そのものを扱う。
### 公表されている数値の例と、その扱い方
大手クラウド事業者の一つであるマイクロソフト社は、2019年から2022年にかけて公開した複数の分析記事の中で、「多要素認証を有効にするだけで、自動化された大量の不正ログイン試行の99.9%以上を防ぐことができる」という趣旨の分析結果を、繰り返し公表してきたとされる。この「99.9%」という数値は、その後もセキュリティ業界で多要素認証の効果を語るときの代表的な引用例として広く紹介されているが、年ごとの発表や対象とする攻撃の種類によって具体的な数値には幅があり、唯一絶対の確定値として扱うべきではない、という点には注意が必要である。前巻第九章で述べた「多層防御は突破の確率とコストを上げるが、ゼロにはしない」という正直な水準は、この数値にもそのまま当てはまる——99.9%という数値は「非常に高い効果」を示してはいるが、「絶対に防げる」ことを意味してはいない。
### 検算的な小演習 — 99.9%という数値を、具体的な件数に当てはめて検算する
この公表値を、具体的な件数に当てはめて検算してみよう。ある組織(架空の設例)が、年間10万件の自動化されたログイン試行を受けているとする。多要素認証を導入していない状態で、そのうち0.5%(500件)が実際に不正ログインの成功に至っていたと仮定する。
```
不正ログイン成功件数(MFA導入前): 10万件 × 0.5% = 500件
MFAが防ぐ割合(公表値の一例): 99.9%
MFAによって防がれる件数: 500件 × 99.9% = 499.5件
MFA導入後になお残る成功件数: 500件 − 499.5件 = 0.5件(検算成立)
```
同じ10万件の試行に対して、不正ログインの成功件数が500件からおよそ0.5件へ、桁で言えばおよそ1000分の1にまで減る、という規模感である。これは前巻第五章のリスク評価マトリクスでいえば、「脅威×脆弱性×資産価値」のうち、多要素認証という対策が「脆弱性」の値を大きく引き下げる方向に働くことを、具体的な数字で示した一例である。
### この検算の限界を正直に述べる
ただし、この検算はあくまで「公表値をそのまま当てはめた場合の概算」であり、実際の効果は認証方式の種類(第四章で扱ったSMS・TOTP・プッシュ通知などの違い)や、想定する攻撃の性質によって変わる。自動化された大量の試行に対しては非常に高い効果を発揮する一方で、利用者本人が正規のログイン画面だと信じ込まされて一時的なコードそのものを入力してしまうような状況では、MFAを導入していても防げない場合があることが、業界でも広く指摘されている。この限界は、具体的な手口を語るためではなく、「対策には得意な範囲と不得意な範囲がある」という正直さを保つために述べている。この限界への理解は、第九章以降で扱うSSOやゼロトラストの設計、そして次巻(脆弱性の防御的理解と対策)へとつながっていく。
### 検算という姿勢そのものの重要性
本プロジェクトには、数値の主張を鵜呑みにせず、独立した手段で再確認するという文化がある。関数辞書に索引されている、ある結果を独立した別の手段で再度実行し、一致するかどうかを確かめる仕組み(索引: FUNC-0774「独立再実行検証〈independent re-execution verification〉」)や、資産の生成・消費の帳尻が想定どおりに一致しているかを機械的に検査する仕組み(索引: FUNC-0662「資源保存則検証」)は、いずれも分野は違えど、「主張された数値を、検算という行為を通じて確かめる」という同じ精神を体現している。セキュリティ対策の効果を語るときも、公表された数値を鵜呑みにするのではなく、本章で行ったような検算を自分の手で一度たどってみる姿勢が、専門職としての誠実さの一部である。
---
> **定着量の目安(第八章)**: 本章の検算の型(件数 × 対策が防ぐ割合 = 防がれる件数、残る件数 = 元の件数 − 防がれる件数)を使い、自分の身の回りにある別の対策(たとえば、ロック画面のパスコード)についても、仮の数値を置いて同様の概算をしてみると、定量的に語る姿勢が自分の手で実践できることを確認できる。
---
## 第九章: シングルサインオン(SSO)とOAuth/OIDCの概念(水準九)
### 一度の認証で複数のシステムを使う
これまでの章では、一つのシステムに対する認証を中心に見てきた。しかし実務では、利用者が一日のうちに複数のシステム(社内メール、勤怠管理、共有ドライブなど)を横断して使うことが多い。そのたびに毎回パスワードとMFAをやり直すのは、可用性の観点から負担が大きい。一度の認証で、複数の連携したシステムを、再度の認証なしに横断して利用できるようにする仕組みを、**シングルサインオン(SSO、水準九: 一度の認証で、複数の連携したシステムを、再度の認証なしに横断して利用できるようにする仕組み)**と呼ぶ。
SSOは、第五章で扱ったセッションの考え方を、一つのシステムの中だけでなく、複数のシステムをまたいで拡張したものだと理解できる。利用者は一箇所(認証を専門に担当するサービス)でだけ認証を行い、以後はそのサービスが発行する証拠を、連携する他のシステムへ提示することで、再認証なしに利用を続けられる。
### 権限を委譲するための仕組み — OAuth
SSOと混同されやすいが、本質的に異なる目的を持つ仕組みに、OAuthがある。あるサービスが、別のサービスに対して、利用者に代わって限定的な操作の権限を委譲するための、認可のためのしくみを、**OAuth(オーオース、水準九: あるサービスが、別のサービスに対して、利用者に代わって限定的な操作の権限を委譲するための、認可のためのしくみ〈プロトコル〉)**と呼ぶ。「あるアプリに、自分のカレンダーの予定を読み取る権限だけを与える」といった場面は、OAuthが使われる典型例である。OAuthの名前に「Auth」が含まれているため、しばしば認証の仕組みだと誤解されるが、OAuthが本来担っているのは第一章で定義した認可であって、認証そのものではない、という区別が重要である。
### 認証の情報を伝える拡張 — OIDC
OAuthが「限定的な操作権限の委譲」を目的とした認可の仕組みであるのに対し、OAuthの仕組みの上に、利用者が誰であるかという認証の情報を伝える層を追加した拡張を、**OpenID Connect(OIDC、水準九: OAuthの仕組みの上に、利用者が誰であるかという認証の情報を伝える層を追加した拡張)**と呼ぶ。「他のサービスのアカウントでログインする」という、多くのWebサービスで見かける仕組みの多くは、このOIDCによって実現されている。OAuthが「何をしてよいか(認可)」を扱う仕組みであるのに対し、OIDCはその上に「あなたは誰か(認証)」の情報を明示的に乗せる、という関係にある——この区別は、第一章の三分離をそのまま、複数サービス間の連携という文脈に当てはめたものである。
### コラム — SSOの標準規格はOAuthより先にあった
複数のシステムをまたいで認証情報をやり取りする標準規格は、OAuthが登場するより前から存在していた。企業や教育機関の間でよく使われる規格として、2000年代前半に標準化団体によって整備されたSAML(Security Assertion Markup Language)がある。SAMLは主に企業内・組織間のSSOで広く使われ続けている一方、OAuth(2010年前後に標準化)とOIDC(2014年策定)は、Webサービスやスマートフォンアプリの世界で急速に普及していった。用途や技術的な背景は異なるものの、いずれも本章の主題である「一度の認証・限定的な権限委譲を、複数のシステムで安全に共有する」という同じ課題への、異なる時代の異なる応答である、という位置づけで理解しておくとよい。
### コラム — OAuthを認証の代わりに使ってしまう誤用への注意
OAuthとOIDCが登場する以前、一部の実装では、OAuthが返す「操作権限があること」を示す証拠を、そのまま「本人であることの証拠」として誤用してしまう設計が見られたことが、業界の議論の中でたびたび指摘されてきたとされる。この誤用がなぜ問題なのかは、まさに第一章の三分離に立ち返れば理解できる——認可(操作権限があること)は、認証(本人であること)の代わりにはならない。OIDCという拡張が別途整備された背景には、この「認可を認証の代用にしない」という、三分離の原則を守るための設計上の反省があったと理解しておくとよい。
---
> **定着量の目安(第九章)**: 自分が「他のサービスのアカウントでログイン」を使ったことのあるサービスを一つ思い出し、その画面で「どの情報へのアクセスを許可しますか」という確認画面が表示されたことを思い出してみると、SSO・OAuth・OIDCがそれぞれ担っている役割の違いが、実体験として整理しやすくなる。
---
## 第十章: ゼロトラストの認証設計(水準十)
### 「社内にいるから安全」という前提を手放す
前巻第七章で、社内・社外という所在地だけで信頼を判断せず、すべてのアクセスをその都度検証するという考え方に触れた。所在地〈社内か社外か〉だけで信頼を判断せず、すべてのアクセスをその都度検証するという設計思想を、あらためて本巻で正式に、**ゼロトラスト(zero trust、水準十: 所在地〈社内か社外か〉だけで信頼を判断せず、すべてのアクセスをその都度検証するという設計思想)**と呼ぶ。
ゼロトラストという考え方が広まった背景には、在宅勤務やクラウドサービスの利用が広がり、「社内ネットワークの中にいること」がそのまま「安全である」ことを意味しなくなった、という現実の変化がある。かつては、社内ネットワークという境界の内側に入れば、以後の細かいチェックを省略する設計が一般的だった。しかしこれは、前巻第七章で扱った信頼境界を「一度きりの壁」として扱う設計であり、一度その境界の内側に侵入されてしまえば、内部では検証が働かないという弱点を抱えていた。
### 一度の認証で終わらせない — 継続的検証
ゼロトラストを認証・認可の設計に落とし込む際の中心的な考え方が、一度の認証で信頼を固定せず、セッションの継続中も利用者やデバイスの状態をその都度確認し続ける設計である。これを、**継続的検証(けいぞくてきけんしょう、水準十: 一度の認証で信頼を固定せず、セッションの継続中も利用者やデバイスの状態をその都度確認し続ける設計)**と呼ぶ。第五章で扱ったセッションは、一度確立されたら一定時間そのまま有効であり続けるという前提を置いていたが、継続的検証の考え方は、この前提そのものに疑いの目を向け、セッションが有効な間も、利用しているデバイスの状態や、アクセスしようとしている資源のリスクの高さに応じて、追加の確認を求める場面を組み込む。
### 「完全な仲介」の現代的な実装
前巻第七章のコラムで紹介した、境界を越えるすべてのアクセスに対して例外なく検証を適用しなければならないという原則(完全な仲介、1975年の論文にさかのぼる)は、ゼロトラストという設計思想の理論的な先祖にあたる。1975年の論文が示した「一度確認したら、あとは信頼して素通りさせる近道を作ってはいけない」という半世紀前の原則が、クラウドや在宅勤務が当たり前になった現代において、ゼロトラストという具体的な設計運動として、あらためて実務の最前線で再発見されている——この歴史的なつながりは、本巻第十二章で扱う「認証技術の進化の推移」を理解するうえでも重要な手がかりになる。
### コラム — ゼロトラストは特定の製品名ではない
ゼロトラストという言葉は、特定のソフトウェア製品や、単一の技術を指す言葉ではなく、「所在地でなく、その都度検証する」という設計思想そのものを指す言葉である。この点は、前巻第九章で扱った「規格は法的助言ではない」という注意点と同様、ゼロトラストを導入すること自体がゴールなのではなく、その思想に沿って個々のアクセス制御・認証の仕組みを継続的に見直していく実務こそが本質である、という理解が重要である。
---
> **定着量の目安(第十章)**: 自分が使っているサービスで、「いつもと違う場所や端末からログインした際に、追加の確認を求められた」経験があるかを思い出してみる。もしあれば、それがまさに継続的検証の実例であることを確認し、なければ、そのサービスがどんな条件で追加確認を行っているかを設定画面で調べてみると、ゼロトラストという考え方が具体的な体験と結びつく。
---
## 第十一章: 現代最先端 — パスキーとFIDO2(水準十一)
### パスワードそのものを手放す
第三章から第十章まで、私たちはパスワードという知識要素の弱点を、ハッシュ化・MFA・セッション管理・ゼロトラストといった、さまざまな補助技術で補強する方法を見てきた。しかし、これらの補強はいずれも「パスワードを使い続けること」を前提にした対策である。現代の最先端の潮流は、この前提そのものを問い直し、パスワードを使わずに、公開鍵暗号を用いて認証を行うための、業界標準規格群の総称——**FIDO2(ふぁいどつー、水準十一: パスワードを使わずに、公開鍵暗号を用いて認証を行うための、業界標準規格群の総称)**——という方向へ進んでいる。
FIDO2の仕組みを用いて、利用者の端末内に秘密鍵を保持し、パスワードの代わりに生体認証や端末のPINと組み合わせて使う認証方式を、**パスキー(passkey、水準十一: FIDO2の仕組みを用いて、利用者の端末内に秘密鍵を保持し、パスワードの代わりに生体認証や端末のPINと組み合わせて使う認証方式)**と呼ぶ。パスキーでは、利用者が覚えて入力するパスワードそのものが存在しない。かわりに、スマートフォンやパソコンの中に安全に保管された鍵情報と、指紋や顔などの生体要素(または端末のPIN)を組み合わせて、その場で認証を完了させる。
### なぜ「フィッシング耐性」があるとされるのか
パスキーが従来のパスワードやOTPと比べて優れているとされる大きな理由の一つに、正規のサービスのドメインと暗号的に紐づいた認証情報を使うことで、偽のサイトに認証情報を渡してしまう被害の仕組み自体が成立しなくなる性質がある。これを、**フィッシング耐性(ふぃっしんぐたいせい、水準十一: 正規のサービスのドメインと暗号的に紐づいた認証情報を使うことで、偽のサイトに認証情報を渡してしまう被害の仕組み自体が成立しなくなる性質)**と呼ぶ。パスワードやOTPは、利用者自身が「これは正規のサイトだ」と信じて入力する値であるため、見た目が本物そっくりの偽サイトに誘導されてしまうと、利用者が気づかないまま値を渡してしまう可能性が構造的に残る。一方パスキーは、認証の鍵情報がどのドメイン向けに発行されたものかをシステム側が自動的に照合する仕組みになっているため、偽のドメインに対しては、そもそも鍵情報自体が反応しない、という設計になっている。この性質のしくみそのものは公開されている標準規格の一般的な説明であり、本節も回避手法や実行手順には立ち入らず、「なぜ構造的に成立しなくなるのか」という設計原理の説明にとどめている。
### コラム — 鍵はサーバーに送られない
パスキーの設計で押さえておくべきもう一つの要点は、秘密鍵が利用者の端末の外に出ないという性質である。サービス側が保存するのは、対になる公開鍵だけであり、たとえサービス側のデータベースが漏えいしたとしても、公開鍵だけでは利用者になりすますことはできない。この「秘密の情報を一箇所に集中させず、必要な検証だけを行えるようにする」という設計は、前巻第八章の最小権限の原則——本当に必要な範囲だけに情報や権限を与えるという考え方——を、認証情報の保管という文脈にまで徹底したものだと理解できる。
### コラム — 生体要素の弱点を補う組み合わせ
第二章のコラムで、生体要素は「変更できない」という特有の制約を持つことを述べた。パスキーは、生体要素そのものをサービス側に送信するのではなく、端末内で生体要素を使って秘密鍵へのアクセスを許可するかどうかだけを判断する、という設計を取ることで、この制約を回避している。生体情報そのものは常に端末の中にとどまり、サービス側には一切渡らない——この設計は、第二章で述べた「生体要素は変更できないからこそ、慎重な扱いが求められる」という課題に対する、現代的な一つの解答例である。
---
> **定着量の目安(第十一章)**: 自分のスマートフォンやパソコンで「パスキー」という設定項目が用意されているサービスがあるかを確認してみる(設定を変更する必要はなく、確認するだけでよい)。見つかれば、それがパスワードとどう違うかを、本章の言葉(公開鍵暗号・端末内の秘密鍵・フィッシング耐性)を使って自分なりに説明してみると、最先端の技術が抽象論でなく具体的な選択肢として理解しやすくなる。
---
## 第十二章: 達人術 — なぜ認証技術はこの順で進化してきたのか(水準十二)
### 十一の技術を、一本のメタな流れとして見直す
ここまでの十一章で、識別・認証・認可の三分離(第一章)、三要素認証(第二章)、パスワードの弱点とハッシュ化・ソルト・ストレッチング(第三章)、多要素認証(第四章)、セッション管理とトークン(第五章)、RBAC・ABAC(第六章)、特権管理(第七章)、補助技術の定量効果(第八章)、SSO・OAuth・OIDC(第九章)、ゼロトラスト(第十章)、パスキー・FIDO2(第十一章)という、性質の異なる十一の技術を見てきた。本章では、これらを個別の技術としてではなく、一本のメタな流れとして見直す。
この流れを俯瞰すると、ある共通のパターンが浮かび上がる。**それぞれの技術は、直前の技術が抱えていた弱点への、具体的な応答として登場している**、というパターンである。パスワード(知識要素)単独の弱さへの応答として、ハッシュ化・ソルト・ストレッチング(第三章)という保存側の防御と、多要素認証(第四章)という追加の証拠が登場した。一度の認証だけでは、その後の長いやり取りをどう安全に保つかが解決しないという課題への応答として、セッション管理(第五章)が整理された。個々のアカウントへの権限付与が煩雑になり、抜け漏れが起きやすいという課題への応答として、RBAC・ABAC(第六章)という体系的な認可モデルが整備された。特に強い権限が乱用・誤用されるリスクへの応答として、特権管理(第七章)が独立した実務領域として確立した。複数のシステムを使うたびに認証をやり直す煩雑さへの応答として、SSO・OAuth・OIDC(第九章)が整備された。社内・社外という所在地による信頼判断が現実に合わなくなったという課題への応答として、ゼロトラスト(第十章)が広まった。そして、パスワードという知識要素そのものが抱える根本的な弱さ(推測されうる・使い回されうる・盗まれうる)への応答として、パスワードを使わないパスキー・FIDO2(第十一章)が登場した。
### 「なぜこの順か」という問いへの答え
この推移が、なぜこの順序で起きたのかを一段抽象化すると、次のような法則性が見えてくる。まず、最も単純で導入コストの低い仕組み(パスワードという単一の知識要素)が先に広く普及する。次に、その仕組みの弱点が実務の現場で繰り返し表面化し、その弱点を補うための追加の層(ハッシュ化・MFA・セッション管理)が、既存の仕組みを置き換えるのではなく、重ねる形で導入される——これは前巻第四章の多層防御そのものである。層を重ねる対応にも限界が見えてくると、今度は仕組み全体の設計思想そのものを見直す、より根本的な転換(ゼロトラストのような、境界の考え方そのものを変える転換、パスキーのような、知識要素そのものを手放す転換)が起こる。「まず単純な仕組みが広まる→弱点に層を重ねて補う→層を重ねる対応にも限界が見え、設計思想そのものを転換する」という三段階のパターンは、認証技術に限らず、前巻第十章で扱った規格の進化(ISMS・NIST CSFが、個別の対策の寄せ集めから、継続的な体系へと発展してきた経緯)にも共通して見られる、情報セキュリティ全体を貫くメタ的な構造である。
### この推移は、まだ終わっていない
正直に述べておかなければならないのは、パスキー・FIDO2が「最終形態」であると請け合うことはできない、という点である。前巻第九章で述べた「セキュリティは製品ではなく継続的な工程である」という認識のとおり、認証技術もまた、新しい利用形態(たとえば、複数の端末を持ち歩く働き方や、AIエージェントが人間に代わって操作を行う場面など)が広まるたびに、新しい弱点が表面化し、それに応答する新しい層、あるいは新しい設計思想の転換が、これからも繰り返し起こっていくと考えられる。本章で示した「単純な仕組み→層を重ねる→設計思想を転換する」という三段階のパターンそのものを覚えておくことこそが、個々の技術の暗記よりも長く役に立つ、達人術としての視点である。
### 本巻から次巻への橋渡し
本巻では、識別・認証・認可という「予防」の中核技術を扱ってきたが、前巻第六章で扱った四本柱(予防・検知・対応・復旧)のうち、本巻はあくまで予防の側だけを扱っている。どれだけ本巻の技術を組み合わせても、前巻第九章で述べたとおり、対策は突破の確率とコストを上げるがゼロにはしない。本巻で整備した予防の仕組みに、たとえ欠陥があった場合に何が起こりうるかを、防御的な視点からさらに掘り下げるのが、次巻BOOK-0362『脆弱性の防御的理解と対策』の役割である。
---
> **定着量の目安(第十二章)**: 本章で示した十一の技術(第一章〜第十一章)を、白紙に時系列順で書き出し、それぞれの技術が「直前のどんな弱点への応答だったか」を一行ずつ自分の言葉で説明できるかを試してみる。すべて説明できれば、個々の技術を暗記するのではなく、認証技術全体の推移をメタな視点で理解できている状態になっている。
---
## 四つの実践解 — 特別な道具を使わない、安全な実践
理論を、実際に手を動かして確かめる方法を四つ紹介する。いずれも実在システムへの侵入や特別な道具を必要とせず、自分自身のアカウントの設定画面と、紙とペンだけで完結する、安全な実践解である。
1. **三分離の棚卸し実践**: 自分が普段使っているサービスを一つ選び、「利用者名を入力する場面(識別)」「パスワードや生体情報を入力する場面(認証)」「ログイン後にできることとできないことが分かれている場面(認可)」の三つを、実際の画面の動きに沿って書き出す。これを3つ以上のサービスで行うと、第一章の三分離が、抽象論でなく具体的な画面操作として定着する。
2. **多要素認証の設定点検実践**: 自分の主要なアカウント(メール、クラウドストレージ、金融関連サービスなど)を3つ選び、多要素認証が設定できるかどうかを確認する(設定画面を開いて確認するだけでよい)。まだ設定していないものがあれば、この機会に設定してみる。第四章・第八章で学んだ「効果が大きい割に導入コストが低い」対策を、自分の手で実践できる。
3. **権限の棚卸し実践**: 自分がスマートフォンやパソコンにインストールしているアプリのうち、位置情報・連絡先・写真などへのアクセス権限を持つものを5つ以上書き出し、それぞれ「本当に今も必要な権限か」を見直す。前巻第八章と第六章・第七章の最小権限の原則を、自分の手元の設定で実践する練習になる。
4. **定量効果の検算実践**: 第八章で示した検算の型(件数 × 対策が防ぐ割合 = 防がれる件数)を使い、自分が知っている別のセキュリティ対策(たとえば、画面ロックのパスコードや、玄関の補助錠など)について、仮の数値を置いて同様の概算をしてみる。この実践を通じて、「効果を感覚でなく数字で語る」という第八章の姿勢が、自分の言葉で再現できるようになる。
---
## まとめ — 「あなたは誰か」から「何をしてよいか」まで、一本の糸で
本巻では、名札と本人確認と入室許可という、オフィスビルの入口の物語から出発し、識別・認証・認可という三つの工程を明確に分ける考え方(第一章)、知識・所持・生体という三要素認証(第二章)、パスワードの弱点をハッシュ化・ソルト・ストレッチングで補う設計(第三章)、性質の異なる要素を組み合わせる多要素認証(第四章)、認証済みの状態を安全に保つセッション管理とトークン(第五章)、権限を体系立てて割り当てるRBAC・ABAC(第六章)、特に強い権限を別枠で扱う特権管理と特権昇格の防御(第七章)、対策の効果を感覚でなく数字で検算する姿勢(第八章)、複数システムをまたぐ認証を整理するSSO・OAuth・OIDC(第九章)、所在地でなく毎回検証するゼロトラスト(第十章)、パスワードそのものを手放すパスキー・FIDO2(第十一章)までをたどり、最後にこれら十一の技術を貫く「単純な仕組み→層を重ねる→設計思想を転換する」というメタなパターンを見た(第十二章)。
この一冊で共有した言葉は、前巻(BOOK-0360)が定義した信頼境界・最小権限の原則を、実際に動く仕組みへと翻訳したものである。前巻が「なぜ守るのか」という土台を示したとすれば、本巻は「誰を、どこまで信頼してよいかを、具体的にどう判定するか」という、予防の中核部分を担っている。次巻(BOOK-0362『脆弱性の防御的理解と対策』)からは、本巻で整備した予防の仕組みに欠陥があった場合に何が起こりうるかを、防御的な視点でさらに掘り下げていく。
---
## 章末: 簡易階段図
```
[水準十二] 達人術・認証技術の進化のメタ的推移
単純な仕組み→層を重ねる→設計思想を転換する、という三段階のパターン(第十二章)
▲
│ 十一の技術を、一本のメタな流れとして見直す
[水準十一] 現代最先端: パスキー・FIDO2
公開鍵暗号+端末内の秘密鍵でフィッシング耐性を実現(第十一章)
▲
│ パスワードそのものを手放す設計思想への転換
[水準十] ゼロトラストの認証設計
所在地でなく毎回検証、継続的検証という考え方(第十章)
▲
│ 「社内だから安全」という前提を手放す
[水準九] SSO・OAuth・OIDC
OAuth=認可の委譲、OIDC=認証情報を伝える拡張(第九章)
▲
│ 複数システムをまたぐ認証を一度で済ませる
[水準八] 補助技術の定量効果
MFA公表値99.9%を検算: 500件→0.5件(約1000分の1・第八章)
▲
│ 効果を感覚でなく数字で検算する
[水準七] 最小権限の原則と特権管理・特権昇格の防御
ロック順序規律(FUNC-1344)・アトミック操作(FUNC-1339)実例(第七章)
▲
│ 強い権限を別枠で管理し、チェックの抜け漏れを防ぐ
[水準六] 認可モデル: RBACとABAC
読み書きロック(FUNC-1338)に見る「読む」「書く」の権限分離(第六章)
▲
│ 「誰に」でなく「役割に」権限を紐づける
[水準五] セッション管理とトークン
2^128通り≈3.4×10^38、宇宙年齢を超える衝突までの時間(検算・第五章)
▲
│ 一度の認証を、安全に長続きさせる
[水準四] 多要素認証(MFA)の仕組み
知識要素+所持要素、TOTPは30秒ごとに切り替わる(第四章)
▲
│ 種類の異なる証拠を組み合わせる
[水準三] パスワードの弱点とハッシュ化・ソルト・ストレッチング
ストレッチング1万回=1回あたりのコストが1万倍(検算・第三章)
▲
│ 知識要素という弱い土台を、保存側から補強する
[水準二] 三要素認証(知識・所持・生体)
something you know / have / are という三区分(第二章)
▲
│ 認証を支える証拠の種類を洗い出す
[水準一] 識別・認証・認可の三分離
名乗る(識別)・確かめる(認証)・決める(認可)を分ける(第一章)
横の広がり:
[水準二] 知識要素 ←(変更可能)→ 生体要素(変更不可・第二章コラム)
[水準九] OAuth(認可の委譲) ←(混同されやすい対概念)→ OIDC(認証情報の伝達)
現在のフロンティア(第十章・第十一章):
2010年前後 ゼロトラストという考え方が業界で広まり始めたとされる(前巻第七章から接続)
2019年 FIDO2/WebAuthnがW3C勧告として策定されたとされる
※本巻で扱った三分離・多要素認証・RBAC/ABAC・ゼロトラストという考え方は、現在もなお、
新しい利用形態の広がりにあわせて実務の最前線で更新され続けている、現役の設計原理である。
次の冊子(BOOK-0362『脆弱性の防御的理解と対策』・予防+検知):
本巻の認証・認可の仕組みに欠陥があった場合、何が起きるかを防御的視点で掘り下げる ─────▶
```
---
## 参照文献(定番教科書・公的規格・原著)
1. 情報セキュリティ分野の標準的教科書群(大学初年次〜専門課程向けに広く使われている、認証・認可・アクセス制御の基礎を扱う定番の入門教科書群)。
2. 米国国立標準技術研究所(NIST) *Special Publication 800-63: Digital Identity Guidelines*。デジタルアイデンティティ・認証保証レベルに関する代表的な公的ガイドライン。
3. Saltzer, J. H. and Schroeder, M. D. *The Protection of Information in Computer Systems*, 1975年。最小権限・完全な仲介を含む設計原則群の古典的な定式化として、前巻に続き本巻でも参照。
4. IETF RFC 6749 *The OAuth 2.0 Authorization Framework*, 2012年。OAuthの標準仕様。
5. OpenID Foundation *OpenID Connect Core 1.0*, 2014年。OIDCの標準仕様。
6. FIDO Alliance / World Wide Web Consortium(W3C) *Web Authentication (WebAuthn)*, FIDO2関連仕様群。公開鍵暗号を用いたパスワードレス認証の業界標準。
7. マイクロソフト社による多要素認証の効果分析記事群、2019年から2022年にかけて公開されたとされる(具体的な数値は年ごとの発表により幅がある点に注意)。
8. 本プロジェクト内部資料: tools/check_conservation.js(保存則監査器)、library/funcdict/FUNC-0188・FUNC-0244・FUNC-0255・FUNC-0278・FUNC-0287・FUNC-0289・FUNC-0297・FUNC-0298・FUNC-0384・FUNC-0387・FUNC-0662・FUNC-0774・FUNC-1100・FUNC-1338・FUNC-1339・FUNC-1344・FUNC-1347(関数辞書カード群)、NUMBER_REGISTRY.md。
9. BOOK-0360『情報防衛と復旧シリーズ 第1巻 情報セキュリティ総論』(信頼境界・最小権限・CIA三要素・多層防御という本巻全体の前提)。
## 用語索引(本巻での初出章)
識別・認証・認可・資格情報(第一章)/知識要素・所持要素・生体要素・三要素認証(第二章)/パスワードハッシュ化・ソルト・ストレッチング(第三章)/多要素認証・ワンタイムパスワード・時間ベースワンタイムパスワード(第四章)/セッション・セッショントークン・セッションタイムアウト・セッション無効化(第五章)/ロールベースアクセス制御(RBAC)・属性ベースアクセス制御(ABAC)(第六章)/特権アカウント・特権管理・特権昇格(第七章)/(補助技術の定量効果は既出用語の応用のため新語なし・第八章)/シングルサインオン(SSO)・OAuth・OpenID Connect(OIDC)(第九章)/ゼロトラスト・継続的検証(第十章)/FIDO2・パスキー・フィッシング耐性(第十一章)/(認証技術の進化のメタ的推移は既出用語の総括のため新語なし・第十二章)。
---
（本冊子は情報防衛と復旧シリーズ BOOK-0361。全12巻の第2巻(認証・認可・アクセス制御)。前巻BOOK-0360『情報セキュリティ総論』で定義した信頼境界・最小権限の原則を、識別・認証・認可という具体的な仕組みへ落とし込んだ。次巻BOOK-0362『脆弱性の防御的理解と対策』(予防+検知)では、本巻で扱った認証の仕組みに欠陥があった場合、何が起きるかを防御的視点から掘り下げる。CATALOG_情報防衛と復旧シリーズ.md・GAKUMON_UNIVERSE.md進捗台帳を参照。）
# BOOK-0361 情報防衛と復旧シリーズ 第2巻: 認証・認可・アクセス制御 — 「あなたは誰か」「何をしてよいか」を切り分けて設計する