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

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

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

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

登場人物メモ:

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

1. 認証 — トークン・セッション・多要素認証（MFA）で本人確認
2. 認可 — ロール（RBAC）等で「何ができるか」を制御。最小権限が基本
3. 通信の保護 — TLS（HTTPS）で暗号化と相手の正当性確認
4. 入力・出力の扱い — 検証・エスケープ・パラメータ化で守る（XSS/SQLi/CSRF の具体策は姉妹ユニット Webの中のセキュリティ）
5. 秘密管理 — 鍵・資格情報はコードに直書きせず、シークレット管理へ
6. 監査・監視 — ログを残し、異常を検知する

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

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

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