開発・設計者向け / 第14章 WAF が必要な場面

ページ 1 / 7

第14章セキュリティ

約5分で読む

WAF が必要な場面

「ログインで守っているサイトにも、WAFは必要なの?」

本人確認だけでは防げない攻撃と、追加の検査を選ぶときの条件を見てみましょう。

  1. 01場面

    このサイトにもWAF?

    守る対象を決める

    入口の守りを考えたい。WAFは、ここでは何を補えるかな?

  2. 02条件確認

    構成と決まりを確認

    判断の前提を揃える

    扱う情報、公開範囲、規定、すでにある対策を確かめよう。

  3. 03評価

    残る攻撃を考える

    認証後のリスクも評価

    本人確認を通った通信にも攻撃はあり得る。追加の検査が役立つかな?

  4. 04判断

    運用まで含めて選ぶ

    導入後の運用も判断材料

    必要な守りと運用体制から選ぼう。誤検知の調整も続けるんだね。

この章の合言葉

WAFは役割と残るリスクで選ぶ。導入後の調整まで備える。

※WAFはWebへの通信を検査する仕組みです。認証・認可・脆弱性対策と組み合わせ、誤検知も調整します。

読みはじめる

社員限定でも WAF は要るのか

WAFはWebへの通信を検査し、攻撃を検知・遮断する仕組みです。たとえば、データベースへの不正な命令を入力に紛れ込ませるSQLインジェクションを検査します。認証済みの通信も検査対象になります。ログインを済ませた相手が、必ず安全な要求を送るとは限りません。

前段認証は未認証の通信を減らす有効な対策です。ただし、アプリへの直接アクセス、アカウントの乗っ取り、内部からの攻撃等は残ります。規定・基本対策・残るリスク・運用体制を合わせてWAFの要否を判断します。

世界中から入口に届く善意も悪意も同じ道
ログイン前の通信もアプリへアプリが全部受け止める
WAFの追加効果を評価基本対策と組み合わせる
入口で前段認証許可された相手に絞る
認証済みの通信にも注意攻撃面はゼロにならない
残るリスクから選ぶ追加効果と運用を評価

各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。

公開範囲が広いほど攻撃機会は増える — 基本対策とWAFの効果を評価

この図をテキストで読む

構成図「公開範囲で攻撃面は変わる — 認証後の通信にも注意」。ブロック6個、つながり4本。 枠: 誰でも来られる(公開サイト)(ブロック3個)、社員限定(前段認証で締める)(ブロック3個)。 【ブロック】 - 世界中から入口に届く: 善意も悪意も同じ道 - ログイン前の通信もアプリへ: アプリが全部受け止める - WAFの追加効果を評価: 基本対策と組み合わせる - 入口で前段認証: 許可された相手に絞る - 認証済みの通信にも注意: 攻撃面はゼロにならない - 残るリスクから選ぶ: 追加効果と運用を評価 【流れ】 - 公開サイトの世界: 世界中から入口に届く → ログイン前の通信もアプリへ → WAFの追加効果を評価 - 社員限定+前段認証の世界: 入口で前段認証 → 認証済みの通信にも注意 → 残るリスクから選ぶ

前段認証は攻撃面を減らす一層。認証後の通信にも攻撃があり得ます。

WAFの要否を判断する流れ

必要一律の指定なし不足あり整っている有効効果が限定的
決まりごと規定⁠・契約
基本対策守りの土台
残るリスク追加効果と運用
システムこれから公開するもの
判断3つの問い
結論入れる ⁠/ 入れない
Webシステムの条件を整理社外向け ⁠/ 社内向け
規定⁠・契約でWAFが必要⁠?① 要求事項を確認
基本対策は整っている⁠?② 基本対策と経路を確認
残るリスクにWAFが有効⁠?③ 追加効果と運用を評価
WAFを導入⁠・運用要求事項⁠/追加効果に応じて
基本対策を整えて再評価WAFだけに任せない
代替対策と監視で運用省略理由も記録
  • 焦点

各工程・分岐・レーンをクリックすると、その仕組みの説明がここに表示されます。

この図をテキストで読む

業務フロー図「規定・基本対策・追加効果から判断する」。レーン3本、工程7個。 【レーン(担当)】(左から右) - システム: これから公開するもの - 判断: 3つの問い - 結論: 入れる / 入れない 【図の符号】色つきの工程=焦点 【工程】(上から下へ。担当 → 工程名) ── フェーズ: 決まりごと(規定・契約) ── 1. システム: Webシステムの条件を整理〔開始・終了〕(社外向け / 社内向け) 2. 判断: 規定・契約でWAFが必要?〔分岐〕(① 要求事項を確認) 必要 → WAFを導入・運用 一律の指定なし → 基本対策は整っている? ── フェーズ: 基本対策(守りの土台) ── 3. 判断: 基本対策は整っている?〔分岐〕(② 基本対策と経路を確認) 不足あり → 基本対策を整えて再評価 整っている → 残るリスクにWAFが有効? 4. 結論: 基本対策を整えて再評価〔開始・終了〕(WAFだけに任せない) ── フェーズ: 残るリスク(追加効果と運用) ── 5. 判断: 残るリスクにWAFが有効?〔分岐〕(③ 追加効果と運用を評価) 有効 → WAFを導入・運用 効果が限定的 → 代替対策と監視で運用 6. 結論: WAFを導入・運用〔開始・終了〕(要求事項/追加効果に応じて) 7. 結論: 代替対策と監視で運用〔開始・終了〕(省略理由も記録)

規定 → 基本対策 → 残るリスクと追加効果、の順に判断します。

場面別の早見表

各セルをクリックすると、その意味や詳しい説明がここに表示されます。

この図をテキストで読む

比較表。2列 × 5行。 【列】 1. WAF の要否(目安) 2. 決め手(何で決まる?) 【比較】(観点ごとに) ■ 公開サイト - WAF の要否: 追加効果を評価 / 構成とリスクから判断 - 決め手: ログイン前後の脅威と運用を確認 / 構成とリスクから判断 ■ 誰でも登録できる会員制 - WAF の要否: 認証後も評価 / 構成とリスクから判断 - 決め手: 認可・入力・不正利用の対策と併用 / 構成とリスクから判断 ■ 社員限定+前段認証 - WAF の要否: 認証だけで不要としない / 構成とリスクから判断 - 決め手: 残る攻撃面と代替対策を確認 / 構成とリスクから判断 ■ 社員限定・アプリ内認証 - WAF の要否: 基本対策と併せて評価 / 構成とリスクから判断 - 決め手: 前段認証も含め、用途に合う対策を選ぶ / 構成とリスクから判断 ■ 規定・契約で要求あり - WAF の要否: 要求を満たす / 構成とリスクから判断 - 決め手: 導入後の監視と調整まで実施 / 構成とリスクから判断

自分のシステムに近い行をクリック。要否はあくまで目安で、最後は規定と費用対効果で決めます。

WAFを入れるとき、何を決める?

社員しか使わないWebシステムに、WAFは必要でしょうか。ログインで利用者を絞っても、乗っ取られたアカウントなどから攻撃の通信が届く可能性は残ります。認証は本人や資格情報を確かめ、WAFは通信の内容を検査します。役割を分けて考えます。

まず、社内規定・契約・業界基準の適用範囲と要求内容を確認します。そのうえで、公開範囲や扱う情報、残る攻撃の可能性を整理します。規定を作る側も、前段の認証だけを理由に不要とせず、残るリスクと代替対策を評価できる基準にします。

導入費だけでなく、検知ルールの更新、正常な通信を止める誤検知の調整、監視を誰が続けるかまで決めます。料金は製品・ルール・通信量・契約で変わるため、その条件と運用体制を合わせて比較します。

WAFで代わりにならない対策

WAFがあっても、アプリの認可や脆弱性修正は必要です。認証済みの通信も、検査対象になり得ます。

押さえておきたい用語

WAF(Web Application Firewall)
Web アプリに届く通信の中身を検査し、攻撃の型を入口で遮断する防火壁。多くのクラウドが月額のサービスとして提供する。
前段認証
アプリの手前(入口)で本人確認を済ませ、未認証の通信をアプリに届かせない方式。クラウド各社が標準機能として提供する。
SQL インジェクション
入力データにデータベース操作の命令(SQL)を紛れ込ませ、不正に実行させる攻撃。WAF が遮断する『攻撃の型』の代表例。
攻撃面(アタックサーフェス)
攻撃者が触れられる場所の総量。前段認証は検問を強くするのではなく、攻撃面そのものを減らす対策。
ISMS
情報セキュリティマネジメントシステム。会社として情報を守るための決まりごとと運用の仕組み。認証取得や監査の中で WAF の要否が問われることがある。
PCI DSS
カード決済の情報を扱う環境のセキュリティ基準(Payment Card Industry Data Security Standard)。公開 Web アプリには WAF などの防御策が求められる。
ページ 1 / 7