理Kotowary

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

大人こども
初級中級上級

概要 — まず全体をつかむ

サービスと利用者を、悪い人や事故から守る——その全体像がWebのセキュリティです。図の🔒の囲いは「あなたの手元（端末）以外を、まとめて守る」ことを表しています。

詳細 — 1段階ずつ追う

なぜ「端末以外」を守る？

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

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

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

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

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

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

登場人物メモ:

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

守りの5つの柱

  1. 認証 — そもそも「誰か」を確かめる（ログイン）
  2. 認可 — その人が「何をしてよいか」を決める（権限）
  3. 通信の保護 — 盗み見・改ざんを防ぐ（HTTPSで暗号化）
  4. 入力のチェック — あやしいお願いを弾く（WAF・入力の検証）
  5. 秘密の管理 — 鍵やパスワードを、見えない場所に隠す

登場人物メモ:

  • 認証と認可 — 「誰か」と「何してよいか」。似ているが別物
  • HTTPS — 通信を暗号化する仕組み（鍵マークの正体）
この部分をもっと深く（中級）
  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枚では破られます。だから何層も重ねる——入口で弾き、本人を確かめ、権限で絞り、暗号で隠す。1つ破られても、次の層で止める。これが多層防御です。

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

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

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

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

⚠️ 守りが破れると

  • 情報漏洩 — 見えてはいけないデータが外に出る
  • なりすまし — 他人になりきってログインされる
  • 改ざん — データを勝手に書き換えられる
  • 権限昇格 — 一般利用者が管理者の操作をしてしまう

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

この部分をもっと深く（中級）
  • 認可の抜け — APIで認可チェックを忘れ、他人のデータを取得できる（定番の重大事故）
  • 秘密の漏洩 — リポジトリや公開ストレージに鍵を置いてしまう
  • 依存の脆弱性 — 使っているライブラリの既知の穴を放置
  • ログ不足 — 攻撃されても気づけない・追えない

理解度チェック

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

問1. 通信を盗み見・改ざんから守るのは主にどれ？

問2. 「あなたが誰か」を確かめるのが認証。では「その人が何をしてよいか」を決めるのは？

問3. 「守りを1枚でなく何層も重ね、1つ破られても次の層で止める」考え方をなんという？

問4. 守りの5つの柱のうち、「あやしいお願いを入口で弾く（WAF・入力の検証）」に当たるのはどれ？

問5. 一般の利用者が、管理者だけができる操作をしてしまう破れ方を何という？

問6. フロント（ブラウザ側）でのチェックについて、本文の考え方として正しいのはどれ？

問7. 他人になりきってログインされてしまう被害を何という（ひらがな・カタカナ可）？

問8. 見えてはいけないデータが外に出てしまう被害を何という（漢字4文字）？

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