理Kotowary

Webのセキュリティ（全体像）— 端末以外をまとめて守る

大人こども
初級中級上級

概要 — まず全体をつかむ

初級ではセキュリティを「重なった防犯」と捉えました。中級では、何を守るか（CIA）・信頼境界・多層防御を軸に整理します。

詳細 — 1段階ずつ追う

何を・何から守る？

守る対象は3つの軸（CIA）で捉えます。

  • 機密性 — 見られてはいけない（漏洩を防ぐ）
  • 完全性 — 書き換えられてはいけない（改ざんを防ぐ）
  • 可用性 — 使いたいときに使える（停止を防ぐ）

そして設計の前提は 信頼境界。「手元（クライアント）は信用しない／サーバ側で必ず検証する」。守りは多層防御（defense in depth） で重ねます。

登場人物メモ:

  • ※1 最小権限 — 仕事に必要な最小の権限だけを与える
  • ※2 信頼境界 — どこまでを信用するかの線。境界を越える入力は必ず検証
この部分をもっと深く（上級）

Webの守りは、リクエストが通る各層に配置します。手元（クライアント）は信用しない、が前提。

  • エッジ — WAF、レート制限、ボット対策、DDoS緩和
  • 通信 — TLS（HTTPS）、HSTSで常時暗号化を強制
  • アプリ — 認証・認可、入力検証、出力エスケープ、CSP
  • データ — 保存時暗号、最小権限、鍵管理
  • 運用 — ログ・監視・シークレット管理・パッチ
やさしく言うと（初級）

あなたのブラウザ（手元）は、あなたのもの。でも、サーバ側から見ると手元は信用できません（中身が見え、書き換えられる）。だから大事な守りは、サーバ側でまとめて行います。

お店の防犯にたとえると、守りは1つではなく重なっています。

  • 入口の警備（あやしい人を止める）
  • 本人確認（会員かどうか）
  • 権限（バックヤードに入れるのは店員だけ）
  • 金庫（大事なものは鍵をかける）
  • 裏口の戸締まり（変なものを入れない）

守りの柱（層ごと）

  1. 認証 — トークン・セッション・多要素認証（MFA）で本人確認
  2. 認可 — ロール（RBAC）等で「何ができるか」を制御。最小権限が基本
  3. 通信の保護 — TLS（HTTPS）で暗号化と相手の正当性確認
  4. 入力・出力の扱い — 検証・エスケープ・パラメータ化で守る（XSS/SQLi/CSRF の具体策は姉妹ユニット Webの中のセキュリティ）
  5. 秘密管理 — 鍵・資格情報はコードに直書きせず、シークレット管理へ
  6. 監査・監視 — ログを残し、異常を検知する
アニメーション『Webの攻撃面マップ』を開く
Webの攻撃面マップ — 端末から秘密まで、どこにリスクがあるかブラウザクライアント側⚠ XSS：画面乗っ取り通信路ネット経由⚠ 盗聴・改ざんサーバ側（受け口・認証・DB・秘密）入力（フォーム/API）外から来る値の受け口⚠ 注入：入力が命令に混ざる認証・セッション本人確認と状態の保持⚠ なりすまし：奪取・CSRFサーバ・DBデータの保管と検索⚠ SQLi：命令の書き換え秘密情報鍵・資格情報⚠ 漏洩：直書き・公開設定境界のあらゆる場所にリスク。層ごとに対策を重ねる（多層防御）XSS→出力エスケープ／盗聴→TLS／注入→検証／SQLi→パラメータ化／なりすまし→認証・セッション管理／漏洩→秘密管理
この部分をもっと深く（上級）
  1. エッジ／通信 — WAFルール、レート/ボット、TLS1.3、証明書自動更新
  2. セキュリティヘッダ — CSP・HSTS・COOP/COEP・Permissions-Policy・SameSite
  3. 認証・認可 — セッション/トークン、MFA、RBAC/ReBAC、最小権限
  4. アプリの守り — 入力(検証/正規化)・出力(文脈別エスケープ)・依存(SCA/SBOM)
  5. データ — 保存時暗号、機密の分離、バックアップ
  6. 可観測性 — 監査ログ、異常検知、改ざん検知
やさしく言うと（初級）
  1. 認証 — そもそも「誰か」を確かめる（ログイン）
  2. 認可 — その人が「何をしてよいか」を決める（権限）
  3. 通信の保護 — 盗み見・改ざんを防ぐ（HTTPSで暗号化）
  4. 入力のチェック — あやしいお願いを弾く（WAF・入力の検証）
  5. 秘密の管理 — 鍵やパスワードを、見えない場所に隠す

登場人物メモ:

  • 認証と認可 — 「誰か」と「何してよいか」。似ているが別物
  • HTTPS — 通信を暗号化する仕組み（鍵マークの正体）

運用と全体の考え方

  • 設定ミス・パッチ漏れ — クラウドの公開設定、古い依存ライブラリ（運用の穴。最多の原因）
  • 総当たり／乱用 — レート制限・WAFで緩和
  • ゼロトラスト — 境界の内側も無条件には信用しない
  • フェイルセーフ — 異常や判断に迷う場面では、安全側に倒す（例：認可の可否が確定しないなら拒否する）

※ XSS・SQLインジェクション・CSRF など「入力を悪用する攻撃」の仕組みと対策は、アプリのコードを書く視点でまとめた姉妹ユニット Webの中のセキュリティ を参照。

この部分をもっと深く（上級）
  • ゼロトラスト — 内側も都度検証。境界防御の限界を補う
  • サプライチェーン／CI — ビルド・依存・シークレットの汚染に備える（DevSecOps）
  • 脅威モデリング — 設計段階でSTRIDE等で洗い出す
  • 多層防御 — どこか1枚破られても、次の層で止める
やさしく言うと（初級）

守りは1枚では破られます。だから何層も重ねる——入口で弾き、本人を確かめ、権限で絞り、暗号で隠す。1つ破られても、次の層で止める。これが多層防御です。

アニメーション『多層防御（層で守る）』を開く
Webのセキュリティ＝層で守る（多層防御）👁 運用（ログ・監視）🛡 エッジWAF・レート制限で入口をふるいにかける🔒 通信TLS／HTTPS で暗号化（盗み見・改ざんを防ぐ）🔑 アプリ認証・認可・入出力の扱い🗄 データ保存時暗号・最小権限リクエスト各層を1つずつ通過1枚破られても、次の層で止める ── だから重ねて守る

そして根っこにあるのは「手元（クライアント）は信用しない」。フロントでのチェックは親切機能で、本当の守りはサーバ側でやり直します。

⚠️ 破れ方のパターン

  • 認可の抜け — APIで認可チェックを忘れ、他人のデータを取得できる（定番の重大事故）
  • 秘密の漏洩 — リポジトリや公開ストレージに鍵を置いてしまう
  • 依存の脆弱性 — 使っているライブラリの既知の穴を放置
  • ログ不足 — 攻撃されても気づけない・追えない
この部分をもっと深く（上級）
  • 設定ミス — 公開設定・デフォルト資格・冗長な権限（最多の原因）
  • ヘッダ不足 — CSP/HSTS未設定でXSSや盗聴の被害拡大
  • 依存の脆弱性 — ライブラリの既知の穴を放置
  • 境界の思い込み — 「内側だから安全」「TLSだから安全」（宛先やメタデータは見える）
やさしく言うと（初級）
  • 情報漏洩 — 見えてはいけないデータが外に出る
  • なりすまし — 他人になりきってログインされる
  • 改ざん — データを勝手に書き換えられる
  • 権限昇格 — 一般利用者が管理者の操作をしてしまう

「どの柱の穴か」を考えると、原因と対策の見当がつきます。

理解度チェック

そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

問1. 情報セキュリティの基本「CIA」のうち、「勝手に書き換えられていない」を指すのは？

問2. 「必要最小限の権限だけを与える」設計原則はどれ？

問3. 情報セキュリティ「CIA」のうち、「使いたいときに使える」を指すのはどれ？

問4. 情報セキュリティ「CIA」のうち、「見られてはいけない（漏洩を防ぐ）」を指すのはどれ？

問5. 「異常や判断に迷う場面では安全側に倒す（認可の可否が確定しないなら拒否する）」原則はどれ？

問6. 本文が「定番の重大事故」として挙げる破れ方はどれ？

問7. トークンやセッション、多要素認証（MFA）で「そもそも誰か」を確かめることを何という（漢字2文字）？

問8. 認証で本人と分かった相手に対し、「何をしてよいか」をロール（RBAC）などで制御することを何という（漢字2文字）？