理Kotowary

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

大人こども
初級中級上級

概要 — まず全体をつかむ

初級・中級では「端末以外を守る囲い」と「攻撃の境界」を見ました。上級では、層で守るアーキテクチャと運用へ。

詳細 — 1段階ずつ追う

守りを「層」で設計する

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

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

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

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

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

登場人物メモ:

  • ※1 最小権限 — 仕事に必要な最小の権限だけを与える
  • ※2 信頼境界 — どこまでを信用するかの線。境界を越える入力は必ず検証

各層の柱（詳細）

  1. エッジ／通信 — WAFルール、レート/ボット、TLS1.3、証明書自動更新
  2. セキュリティヘッダ — CSP・HSTS・COOP/COEP・Permissions-Policy・SameSite
  3. 認証・認可 — セッション/トークン、MFA、RBAC/ReBAC、最小権限
  4. アプリの守り — 入力(検証/正規化)・出力(文脈別エスケープ)・依存(SCA/SBOM)
  5. データ — 保存時暗号、機密の分離、バックアップ
  6. 可観測性 — 監査ログ、異常検知、改ざん検知
やさしく言うと（中級）
  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→パラメータ化／なりすまし→認証・セッション管理／漏洩→秘密管理

運用と文化

  • ゼロトラスト — 内側も都度検証。境界防御の限界を補う
  • サプライチェーン／CI — ビルド・依存・シークレットの汚染に備える（DevSecOps）
  • 脅威モデリング — 設計段階でSTRIDE等で洗い出す
  • 多層防御 — どこか1枚破られても、次の層で止める
やさしく言うと（中級）
  • 設定ミス・パッチ漏れ — クラウドの公開設定、古い依存ライブラリ（運用の穴。最多の原因）
  • 総当たり／乱用 — レート制限・WAFで緩和
  • ゼロトラスト — 境界の内側も無条件には信用しない
  • フェイルセーフ — 異常や判断に迷う場面では、安全側に倒す（例：認可の可否が確定しないなら拒否する）

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

⚠️ 破れ方

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

理解度チェック

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

問1. Webのセキュリティを「層」で守るとき、各層の対応で正しいのは？

問2. 「内側のネットワークでも無条件に信用しない」Web運用の考え方は？

問3. 一度アクセスした以後は常時HTTPSを強制し、平文での接続をブラウザに禁じさせるヘッダはどれ？

問4. 「どこか1枚が破られても、次の層で止める」設計思想を指すのはどれ？

問5. 設計段階でSTRIDEなどを使い、起こりうる脅威を洗い出す活動はどれ？

問6. 本文が「最多の原因」として挙げる、Webセキュリティの破れ方はどれ？

問7. 「どの出所のスクリプトを実行してよいか」をブラウザに宣言し、XSSなどを緩和するセキュリティヘッダを英字3文字で答えてください。

問8. ソフトウェアに含まれる依存部品の一覧（部品表）を指す略語を英字4文字で答えてください。