Webセキュリティの全体像
このページで学ぶこと
Section titled “このページで学ぶこと”- セキュリティを「診断で問題が出なければよい」ものではなく、要件・設計・開発・運用にまたがる活動として捉える方法
- 資産、脅威、脆弱性、リスク、対策の関係
- 認証、認可、暗号化、入力処理、設定、依存ライブラリ、ログ等の主な領域
- OWASP Top 10:2025を、攻撃手法の暗記ではなくPMの確認観点として読む方法
- 脆弱性診断、レビュー、監視、インシデント対応の役割と限界
Webセキュリティは、攻撃を一つの機能で完全に防ぐことではありません。
守る対象を把握し、起こり得る問題を想定し、複数の対策を組み合わせ、問題が起きたときに検知・対応・復旧できるようにする活動です。
flowchart LR
A[守る資産] --> T[想定する脅威]
T --> V[悪用され得る脆弱性]
V --> R[事業・利用者へのリスク]
R --> C[予防・検知・対応・復旧]
セキュリティは、エンジニアだけの作業ではありません。
PM・ディレクターは、次を要件・体制・契約へ落とし込みます。
- 何を守るか
- どの程度のリスクを想定するか
- どこまでを制作範囲に含めるか
- 誰が確認し、誰が承認するか
- 公開後に誰が更新・監視・対応するか
資産・脅威・脆弱性・リスク
Section titled “資産・脅威・脆弱性・リスク”守る価値があるものです。
- 個人情報
- 会員・従業員情報
- 問い合わせ内容
- 決済・予約情報
- CMSコンテンツ
- ソースコード
- APIキー・秘密鍵
- 管理者アカウント
- ドメイン・DNS
- サービスの可用性
- 企業・ブランドへの信頼
資産へ悪影響を与える可能性がある出来事や主体です。
- 外部からの不正アクセス
- Botや大量アクセス
- 内部者の誤操作・不正
- アカウントの漏えい
- 外部サービスの侵害
- 災害・障害
- 設定ミス
- 更新忘れ
- 端末の紛失
脅威が悪用できる弱点です。
- 過剰な権限
- 古いライブラリ
- 不適切な入力処理
- 秘密情報の公開
- 誤ったクラウド設定
- 弱い認証
- ログ不足
- エラー処理不足
- バックアップ不能
脅威が脆弱性を悪用したときの、発生可能性と影響を合わせた考え方です。
同じ脆弱性でも、公開情報だけを扱うサイトと、決済・個人情報を扱うサイトでは、事業影響が異なります。
機密性・完全性・可用性
Section titled “機密性・完全性・可用性”情報セキュリティでは、主に三つの性質を守ります。
| 性質 | 意味 | Web制作の例 |
|---|---|---|
| 機密性 | 許可された人だけが見られる | 会員情報、管理画面、APIキー |
| 完全性 | 内容が不正に変更されない | 記事改ざん、予約金額、公開データ |
| 可用性 | 必要なときに利用できる | サイト停止、フォーム停止、DNS障害 |
個人情報保護やプライバシーでは、収集目的、保存期間、第三者提供、削除等も重要です。
「漏えいしなければ安全」ではなく、改ざん・停止・誤処理もセキュリティ上の問題です。
攻撃対象領域と信頼境界
Section titled “攻撃対象領域と信頼境界”攻撃対象領域は、外部からアクセス・操作できる箇所の総体です。
flowchart LR
U[利用者・外部] --> W[公開Web]
U --> API[公開API]
STAFF[社内担当] --> CMS[CMS管理画面]
W --> EXT[外部サービス]
CMS --> DATA[データ・メディア]
DEV[開発者] --> GIT[Git・CI/CD]
GIT --> PROD[本番環境]
守る対象は公開ページだけではありません。
- CMS管理画面
- API
- Gitリポジトリ
- CI/CD
- クラウド管理画面
- DNS
- 外部フォーム
- 計測タグ
- 開発・検証環境
- 担当者端末
システムや組織の境界をまたぐ場所を信頼境界と考え、どの主体をどこまで信頼するかを明確にします。
セキュア・バイ・デザイン
Section titled “セキュア・バイ・デザイン”セキュリティを公開直前に追加するのではなく、設計段階から組み込みます。
flowchart LR
P[企画・要件] --> D[設計]
D --> I[実装]
I --> T[テスト]
T --> R[公開]
R --> O[運用]
O --> P
- 扱うデータ
- 利用者と権限
- 法務・社内基準
- リスク水準
- ログ・保存
- 障害時の業務
- 認証・認可
- データフロー
- 外部連携
- 秘密情報
- エラー・例外
- バックアップ
- 監視
実装・テスト
Section titled “実装・テスト”- 安全な実装
- コードレビュー
- ライブラリ検査
- 設定確認
- 脆弱性診断
- 異常系テスト
- 権限棚卸し
- アップデート
- ログ・アラート
- インシデント対応
- バックアップ復元
- 定期診断
初期設計にない安全要件を後付けすると、認証方式、データ構造、画面フローを大きく作り直すことがあります。
一つの対策が破られても、別の層で影響を抑える考え方です。
flowchart LR
A[認証] --> B[最小権限]
B --> C[入力・出力の安全化]
C --> D[ネットワーク・WAF]
D --> E[ログ・検知]
E --> F[バックアップ・復旧]
たとえば管理画面では、
- 多要素認証
- 必要最小限の権限
- IP・端末等の制限
- 操作ログ
- 異常ログイン通知
- 退場者の権限削除
を組み合わせます。
WAFやHTTPSだけで安全になるわけではありません。
OWASP Top 10:2025をPMの確認観点として読む
Section titled “OWASP Top 10:2025をPMの確認観点として読む”OWASP Top 10は、Webアプリケーションの重要なセキュリティリスクについての啓発資料です。
2025年版の10領域を、PM向けに単純化すると次のようになります。
| OWASP Top 10:2025 | 概要 | PMが確認すること |
|---|---|---|
| A01 Broken Access Control | 許可されていない情報・操作へアクセスできる | ロール、対象データ、URL/API単位の権限 |
| A02 Security Misconfiguration | 不安全な設定や不要機能が残る | 本番設定、管理画面、公開範囲、初期設定 |
| A03 Software Supply Chain Failures | 依存物やビルド・配布経路の問題 | ライブラリ、提供元、ロック、CI/CD、更新 |
| A04 Cryptographic Failures | 暗号化や鍵管理が不適切 | HTTPS、保存時暗号化、鍵・証明書、期限 |
| A05 Injection | 入力が命令として不正に解釈される | 入力処理、API、CMS、外部データ |
| A06 Insecure Design | 設計段階で安全要件が不足 | 脅威想定、権限、業務悪用、例外設計 |
| A07 Authentication Failures | 本人確認やセッション管理が不十分 | MFA、パスワード、ログイン制御、退会 |
| A08 Software or Data Integrity Failures | ソフトウェアやデータの正当性を確認できない | デプロイ、Webhook、更新元、改ざん検知 |
| A09 Security Logging and Alerting Failures | 問題を記録・検知・通知できない | ログ、保管、アラート、調査手順 |
| A10 Mishandling of Exceptional Conditions | 想定外状態を安全に処理できない | タイムアウト、部分失敗、上限、復旧 |
これは診断項目の完全な一覧ではありません。
案件のリスクに応じ、OWASP ASVS等の具体的なセキュリティ要件や、クライアントの社内基準を使います。
認証は「誰かを確かめる」、認可は「何を許可するかを決める」ことです。
flowchart LR
L[ログイン・API認証] --> I[主体を確認]
I --> P[権限を確認]
P --> R[許可されたデータ・操作]
ログインできることと、すべての情報を見てよいことは別です。
PMが確認すること
Section titled “PMが確認すること”- 利用者の種類
- ロールごとの操作
- 自分の情報と他人の情報
- 管理者の範囲
- 退職・退会・契約終了
- パスワード再設定
- 多要素認証
- セッション期限
- ログアウト
- 不正試行の制限
- 代理操作
- 操作履歴
画面でボタンを隠すだけでは権限制御になりません。
API・サーバー側でも権限を確認する必要があります。
秘密情報と鍵
Section titled “秘密情報と鍵”秘密情報には次があります。
- APIシークレット
- データベース認証情報
- クラウドアクセスキー
- 秘密鍵
- Webhook署名キー
- 管理者パスワード
- 暗号鍵
これらをソースコード、公開JavaScript、チャット、メール、共有スプレッドシートへ不用意に置きません。
- 専用の秘密情報管理機能へ保存
- 開発・検証・本番を分離
- 必要な担当だけアクセス
- 有効期限・ローテーション
- 漏えい時の失効
- 利用履歴
- 退場者の権限削除
- バックアップへの含まれ方
「環境変数にした」だけでは安全とは限りません。誰が値を見られ、ビルド後にブラウザへ公開されるかを確認します。
データ保護と暗号化
Section titled “データ保護と暗号化”HTTPSは、通信経路上の盗聴・改ざんを防ぐための重要な対策です。
しかし、HTTPSだけでは次を解決しません。
- 保存先での漏えい
- 管理者の過剰権限
- 誤送信
- 不要な長期保存
- ログへの個人情報記録
- 外部サービスへの不適切な送信
データについて次を整理します。
- 何を収集するか
- なぜ必要か
- どこへ送るか
- どこへ保存するか
- 誰が閲覧できるか
- 何日保存するか
- いつ・どう削除するか
- バックアップからも消せるか
- 本番データを検証へ使うか
必要のないデータを収集しないことは、強いリスク低減策です。
入力・出力・外部データ
Section titled “入力・出力・外部データ”利用者の入力、CMS本文、外部APIのデータ等を、そのまま安全だと信頼しません。
- フォーム
- 検索条件
- URLパラメータ
- アップロードファイル
- CSV
- CMSリッチテキスト
- APIレスポンス
- Webhook
- 外部埋め込み
入力形式、文字数、ファイル種類、権限等を確認し、表示・保存・別システムへの送信時に適切に処理します。
PMは実装方式を指定するより、許可するデータ、拒否時の表示、最大値、ファイル検査、運用確認を要件化します。
例外・上限・異常状態
Section titled “例外・上限・異常状態”正常な入力だけを想定したシステムは、異常時に安全でない動作をすることがあります。
- APIが返らない
- 同じ送信が重複する
- ファイルが巨大
- データ件数が0件・数十万件
- 必須データが欠ける
- 外部サービスが部分的に成功する
- ディスク・料金上限へ到達
- 予期しない形式が返る
- 期限切れ・時刻ずれ
- 複数操作が同時に起きる
エラー時に秘密情報や内部構成を利用者へ表示しません。
旧データ・代替表示・再試行・手動確認へ安全に移行できるようにします。
ソフトウェアサプライチェーン
Section titled “ソフトウェアサプライチェーン”Webサイトは、フレームワーク、npmパッケージ、CMSプラグイン、GitHub Actions、外部スクリプト等に依存します。
flowchart LR
SRC[自社ソース] --> B[ビルド]
DEP[外部パッケージ] --> B
CI[CI/CDアクション] --> B
B --> ART[公開成果物]
EXT[外部タグ・ウィジェット] --> PAGE[公開ページ]
ART --> PAGE
PMが確認すること
Section titled “PMが確認すること”- 依存一覧
- 採用基準
- 公式・信頼できる配布元
- ライセンス
- 更新頻度
- 脆弱性通知
- ロックファイル
- Renovate・Dependabot等
- 更新後のテスト
- 外部タグの管理者
- 不要依存の削除
- 保守終了時の代替
ライブラリを更新しないリスクと、更新によって不具合を起こすリスクの両方があります。
自動更新は、レビュー・テスト・公開手順と組み合わせます。
コードが安全でも、設定で情報が公開される場合があります。
- ストレージの公開範囲
- 管理画面のアクセス
- デバッグ表示
- 検証環境のnoindexだけに依存した公開
- CORSの過剰許可
- 不要なポート・機能
- 初期パスワード
- 過剰なクラウド権限
- ログ・バックアップの公開
- DNS・サブドメインの残置
- 本番の環境変数誤設定
開発・検証・本番で設定が異なるため、本番設定を独立して確認します。
Infrastructure as Code等で設定をコード管理する場合も、レビューと権限管理が必要です。
ログ・アラート・監視
Section titled “ログ・アラート・監視”ログは、問題を後から調べるためだけではありません。
異常を早期に発見し、影響範囲を判断するために使います。
- ログイン成功・失敗
- 権限変更
- CMS公開・削除
- APIエラー
- 管理操作
- 設定変更
- 大量アクセス
- Webhook失敗
- デプロイ
- バックアップ・復元
- 誰が見るか
- 何をアラートにするか
- 何分以内に確認するか
- 保存期間
- 時刻・タイムゾーン
- 利用者・処理を追える識別子
- 個人情報・秘密情報を残さない
- 改ざん防止
- 外部サービスログの取得
ログがあるだけで、誰も見ていなければ検知にはなりません。
静的サイトも安全対策が必要
Section titled “静的サイトも安全対策が必要”静的HTMLをCDNから配信する構成は、サーバー側プログラムやデータベースの攻撃対象を減らしやすい構成です。
しかし、次のリスクは残ります。
- ドメイン・DNSの乗っ取り
- Git・CI/CDの侵害
- 公開ストレージ設定
- 外部JavaScript
- フォーム・API
- CMSアカウント
- 秘密情報のビルド混入
- 依存パッケージ
- コンテンツ改ざん
- クラウド権限
- DDoS・大量アクセス
「静的なので診断・保守不要」と一律に判断しません。
構成に応じて対象と方法を変えます。
セキュリティ確認の種類
Section titled “セキュリティ確認の種類”| 方法 | 主な対象 | 特徴 |
|---|---|---|
| 要件・設計レビュー | データ、権限、構成、業務フロー | 実装前に大きな問題を防ぐ |
| 脅威分析 | 悪用シナリオ、信頼境界 | 高リスク案件で重点を決める |
| コードレビュー | 実装 | 自動検査で分からない意図も確認 |
| SAST | ソースコード | 開発中に自動検査しやすい |
| SCA | 依存ライブラリ | 既知脆弱性・ライセンスを確認 |
| DAST | 動作中のWeb | 外部からの挙動・設定を検査 |
| クラウド設定診断 | 権限・公開範囲・設定 | インフラ構成の問題を確認 |
| 脆弱性診断・ペネトレーションテスト | 実システム | 専門家が範囲・目的に応じて検証 |
| 運用監視 | 公開後 | 異常・侵害・失敗を検知 |
一つの方法ですべての問題を検出できません。
案件のデータ、機能、公開範囲、予算、社内基準に応じて組み合わせます。
脆弱性診断を依頼するとき
Section titled “脆弱性診断を依頼するとき”「診断してください」だけでは、対象と深さが揃いません。
- 対象URL・API・管理画面
- 本番・検証
- ログインあり・なし
- ロール別アカウント
- 外部サービスの扱い
- 負荷をかけてよい範囲
- 個人情報
- 実施日時
- 連絡先
- 対象外
- 判定基準
- 報告書
- 再診断
- 修正期限
- 公開判定
診断会社が発見した項目をすべて同じ優先度で直すのではなく、技術的重大度、事業影響、悪用可能性、代替策を踏まえて判断します。
ただし、受容するリスクは、担当者個人ではなく責任者が明示的に承認します。
インシデント対応
Section titled “インシデント対応”セキュリティ問題が起きたときの流れを準備します。
flowchart LR
D[検知] --> T[一次切り分け]
T --> C[封じ込め]
C --> E[原因除去]
E --> R[復旧]
R --> L[報告・再発防止]
事前に決めること
Section titled “事前に決めること”- 連絡網
- 夜間・休日
- 意思決定者
- サービス停止権限
- アカウント・キー失効
- 証拠・ログ保全
- クライアント・利用者・関係先への通知
- 法務・広報・セキュリティ部門
- バックアップ復元
- 再公開条件
インシデント中に初めて管理者アカウントや契約者を探す状態を避けます。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”問い合わせフォーム
Section titled “問い合わせフォーム”- 収集項目を最小化
- 送信先・保存先
- スパム・大量送信
- 入力・ファイル
- 個人情報ログ
- CRM連携の失敗
- 自動返信に入力内容を含めるか
- 保存・削除期間
を要件化します。
ヘッドレスCMS＋静的サイト
Section titled “ヘッドレスCMS＋静的サイト”- CMSの管理者権限
- 読み取り・書き込みAPIキー
- Webhook署名
- Git・CI/CD権限
- ビルドログ
- 外部フォーム
- 依存ライブラリ
- CDN・ストレージ設定
を対象にします。
会員・予約サイト
Section titled “会員・予約サイト”- ロール・本人データ
- なりすまし
- 二重予約
- 料金・在庫の改ざん
- セッション
- 退会・削除
- 監査ログ
- API・外部決済
- 障害時の業務継続
を設計段階から確認します。
PMチェックリスト
Section titled “PMチェックリスト”- 守る資産と扱うデータを一覧化している
- 利用者・管理者・外部システムの信頼境界を図示している
- リスク水準に応じたセキュリティ要件を設定している
- 認証と認可を分け、ロール・対象データ・操作を定義している
- 秘密情報の保管・更新・失効方法を決めている
- 個人情報の収集目的・保存先・保持期間を確認している
- 入力、ファイル、CMS、外部APIを信頼しすぎない設計にしている
- タイムアウト、重複、上限、部分失敗を定義している
- 依存ライブラリ・外部タグ・CI/CDを一覧化している
- 開発・検証・本番の設定と権限を分けている
- ログ、アラート、保存期間、確認担当を決めている
- 設計レビュー、SCA、診断等の実施範囲を決めている
- 指摘の修正・再診断・リスク受容の責任者を決めている
- インシデント時の連絡・停止・失効・復旧手順がある
- 公開後の更新・権限棚卸し・定期診断を保守へ含めている
よくある誤解・失敗
Section titled “よくある誤解・失敗”「HTTPSとWAFがあれば安全」
Section titled “「HTTPSとWAFがあれば安全」”通信・一部攻撃への対策にはなりますが、権限、設定、秘密情報、依存物、業務ロジック、ログ等は別途必要です。
「公開前の脆弱性診断でセキュリティ対応は完了」
Section titled “「公開前の脆弱性診断でセキュリティ対応は完了」”診断は一時点・一定範囲の検証です。公開後の変更、更新、監視、アカウント管理が必要です。
「静的サイトなのでセキュリティリスクはない」
Section titled “「静的サイトなのでセキュリティリスクはない」”Git、CI/CD、CMS、DNS、外部タグ、フォーム、クラウド設定等が攻撃対象になります。
「エンジニアが安全に作るので要件は不要」
Section titled “「エンジニアが安全に作るので要件は不要」”認証、保存期間、権限、障害時の業務等は、技術者だけでは決められない事業要件です。
「すべての診断指摘を機械的に同じ期限で直す」
Section titled “「すべての診断指摘を機械的に同じ期限で直す」”重大度と事業影響で優先順位を決めます。ただし対応しない判断は根拠・代替策・責任者の承認を残します。
理解度チェック
Section titled “理解度チェック”Q1. 資産、脅威、脆弱性、リスクの関係を説明してください。
Section titled “Q1. 資産、脅威、脆弱性、リスクの関係を説明してください。”回答と解説
守る資産に対し、脅威が脆弱性を悪用すると被害が発生します。その可能性と影響を合わせてリスクと考え、予防・検知・対応・復旧策を選びます。Q2. 認証と認可の違いは何ですか。
Section titled “Q2. 認証と認可の違いは何ですか。”回答と解説
認証は誰であるかを確認し、認可はその主体がどの情報・操作を利用できるかを決めます。ログインできても全データを見てよいとは限りません。Q3. 静的サイトで確認する主なセキュリティ対象を挙げてください。
Section titled “Q3. 静的サイトで確認する主なセキュリティ対象を挙げてください。”回答と解説
DNS、CDN・ストレージ設定、Git・CI/CD、CMS、APIキー、外部フォーム、第三者スクリプト、依存パッケージ、管理者権限等です。Q4. SCAとDASTの大まかな違いは何ですか。
Section titled “Q4. SCAとDASTの大まかな違いは何ですか。”回答と解説
SCAは主に利用する依存ライブラリの既知脆弱性等を確認し、DASTは動作中のWebへ外部からアクセスして挙動・設定上の問題を検査します。Q5. 脆弱性診断の指摘を対応しない場合、何が必要ですか。
Section titled “Q5. 脆弱性診断の指摘を対応しない場合、何が必要ですか。”回答と解説
技術的重大度、事業影響、悪用可能性、代替策、対応期限を評価し、残存リスクを責任者が明示的に承認して記録します。- OWASP「OWASP Top 10:2025」
https://owasp.org/Top10/2025/
Webアプリケーションの重要なリスク領域を把握するための啓発資料。 - OWASP「Application Security Verification Standard」
https://owasp.org/www-project-application-security-verification-standard/
セキュリティ要件、検証、調達時の基準として利用できる公式プロジェクト。最新版を採用時に確認する。 - OWASP「Secure-by-Design Framework」
https://owasp.org/www-project-secure-by-design-framework/
設計段階からセキュリティを組み込むための参考資料。プロジェクトの成熟度・版を確認して利用する。 - OWASP Cheat Sheet Series
https://cheatsheetseries.owasp.org/
個別の安全対策を実装・レビューするための公式補助資料。