2026年8月26日（水）
WEB改ざん検知はなぜ必要？ファイアウォールやWAFとはどう違う？
ファイアウォール・WAFが「見ている場所」と改ざん検知の役割の違いを解説
「うちはファイアウォールもWAFも入れているから大丈夫」——WEBサイトのセキュリティについて担当者の方とお話ししていると、こう聞くことがよくあります。
結論から言うと、ファイアウォールやWAFは「外部からの不審な通信」を防ぐための仕組みであるのに対し、改ざん検知は「侵入されたあとにファイルへ生じた変化」に気づくための仕組みです。両者はそもそも見ている対象が異なるため、ファイアウォールやWAFを導入していても、それだけで改ざんを防ぎきれるとは限りません。だからこそ、通信を防ぐ仕組みと、変化に気づく仕組みをあわせて備えておくことが重要になります。
ここからは、脅かすためではなく、まず現状を正しく理解していただくために、ファイアウォール・WAFがどこを守り、どこを守っていないのかを整理してみたいと思います。
目次
ファイアウォールとWAFは、どうやってWEBサイトを守っているか
まず、それぞれの役割を確認しておきましょう。
ファイアウォール：「誰を通すか」を判断する仕組み
ファイアウォールは、どのIPアドレス・ポートからの通信を許可し、どれを拒否するかを判断する仕組みです。たとえるなら、マンションの共用玄関に設置されたオートロックのようなものです。入館できる相手かどうかを、部屋番号や鍵といった「情報」だけで判定します。中に何を持ち込もうとしているか、どんな用件で訪ねてきたのかまでは見ていません。
WAF：「持ち込む中身」を判断する仕組み
これに対してWAF（Web Application Firewall）は、WEBアプリケーションへのリクエスト——たとえば問い合わせフォームへの入力内容や、検索窓に打ち込まれた文字列など——の「中身」をチェックする仕組みです。マンションの例で言えば、オートロックを通過したあとに各部屋の前に立つ警備員のようなイメージです。訪問者が持っているカバンの中身を確認し、そこにSQLインジェクションやクロスサイトスクリプティング（XSS）といった、WEBアプリの脆弱性を突く攻撃パターンが仕込まれていないかを検査します。
ここで注意したいのは、WAFが見ているのはあくまで「危険な構文パターンが紛れ込んでいないか」という点であって、「その操作を行っている人物が本人かどうか」「その操作が正当な意図によるものかどうか」までは判断していない、ということです。たとえば漏えいしたID・パスワードで正しくログインし、CMSの管理画面が本来許可している機能を使ってファイルを編集する——という操作には、SQLインジェクションのような攻撃パターンは一切含まれません。カバンの中身に危険物が入っていなければ、警備員はその人を通してしまうのと同じで、WAFもこうした操作はそのまま通過させてしまいます。
つまり同じ「入口の防御」でも、ファイアウォールは「誰を通すか」、WAFは「通した相手が持ち込む中身が安全か」を見ている、という違いがあります。役割は異なりますが、どちらも「外部から届く通信をリアルタイムに検査する」という点は共通しています。いわば、建物の入口に立って、不審な人物や物が「入ってこようとする瞬間」を見張るセンサーのような存在です。
WEB改ざんは「通信の外側」で起きることがある
一方で、WEBサイトの改ざんは、必ずしも「不審な通信」を伴って起きるとは限りません。実際に改ざん被害の原因として報告されている経路を、もう少し詳しく見てみましょう。
１．正規の認証情報を使った「正規のログイン」経由で侵入する
フィッシングメールやマルウェア感染、あるいは他のサービスから流出したID・パスワードの使い回しなどによって、管理画面のログイン情報そのものが第三者の手に渡ってしまうケースです。この場合、攻撃者は「間違ったID・パスワードで何度もアクセスを試みる」ような不審な挙動を取る必要がなく、最初から正しい情報でログインします。
ファイアウォールやWAFから見れば、これは正規の利用者による正規のアクセスと区別がつきません。通信のルール上は何も違反していないため、検知のしようがないのです。
２．CMSやプラグインの脆弱性を狙う
WordPressなどのCMSや、そこに追加するプラグイン・テーマには、日々新しい脆弱性が発見されています。これはCMSが危険になっているというより、世界中で広く使われているからこそ、研究者や攻撃者双方の目に触れる機会が多く、これまで気づかれていなかった穴が次々と見つかる、という構造によるものです。バージョンアップは、新たに危険にするものではなく、こうして見つかった穴をふさぐための対応にあたります。
問題は、脆弱性が発見されてから、実際に自社サイトへ修正パッチが適用されるまでの間にタイムラグが生じることです。攻撃者はこの「公表されているが、まだ塞がれていない穴」を狙って動くため、深刻度が高く悪用の実例も報告されているような修正ほど、対応が遅れるだけ狙われる隙になります。攻撃者はこうした脆弱性を悪用し、公開されている入力フォームや管理機能を通じて、正規の機能の延長線上でファイルを書き換えます。こうした操作は「攻撃用の特別な通信」ではなく、普段からその経路で行われている正規のやり取りに紛れてしまうため、通信内容を見るタイプの防御では捕捉しにくい領域です。
ただし、すべての更新を無条件に即時適用すべき、というわけではありません。緊急度は、修正内容の深刻度や影響範囲、悪用が実際に報告されているかどうかによって変わります。軽微な修正であれば定期メンテナンスのタイミングでまとめて対応する、機能追加が中心のアップデートであれば既存プラグインとの互換性を確認してから計画的に進める、といった判断も必要です。急いで適用した結果、確認不足で別の不具合を招いては本末転倒なので、パッチの中身を見て優先度を判断することが大切です。
３．委託先・グループ会社経由のサプライチェーンから
サイト運用を委託している制作会社や、グループ会社が管理するシステムのアカウントが乗っ取られ、そこを踏み台にして改ざんされるケースも報告されています。委託先やグループ会社が狙われやすいのには理由があります。取引先の数だけセキュリティレベルにばらつきが生まれるうえ、自社のセキュリティをどれだけ固めても、委託先のアカウントが正規の権限で自社サイトにアクセスできる以上、そこが手薄であれば全体の弱点になってしまうためです。攻撃者にとっても、直接狙うより守りの薄い委託先を経由するほうが効率的、という側面があります。
こうした背景から、近年は取引先・委託先を含めたサプライチェーン全体でセキュリティ水準を評価する動きが広がっています。その一つが「SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）」で、委託先を含めた体制がどの程度のレベルにあるかを星の数で示す仕組みです。発注元・委託先どちらの立場でも、自社の対策状況を客観的に示す手段として活用が広がりつつあります。
SCS評価制度とWEBサイト改ざん検知の関係についてのコラムはこちら
４．サーバー・アカウントの設定不備につけ込む
FTP/SFTPのパスワードが単純だったり、サーバーの管理者権限が必要以上に広く付与されていたりすると、そこが弱点になります。こうした設定不備は、通信の入口で異常として検知されるものではなく、いわば「鍵はかかっているが、鍵自体が壊れやすい」状態です。ファイアウォールやWAFはあくまで「入口に鍵がかかっているか」を見る仕組みであり、「鍵の品質」や「合鍵が渡っていないか」までは判定の対象にしていません。
これら4つに共通するのは、いずれのケースでも通信そのものは「正規のもの」として扱われてしまう、という点です。ファイアウォールやWAFは通信の中身や送信元をあらかじめ決められたルールに照らして判定する仕組みなので、正規の認証情報を使われたり、監視対象外の経路から手が加えられたりすると、その先でファイルに何が起きているかまでは見えません。
つまり「侵入を防ぐ仕組み」と「侵入後の変化に気づく仕組み」は、そもそも見ている場所が違う、ということです。
「入口の監視」と「中の変化への気づき」は役割が違う
ここまでの整理をシンプルにまとめると、次のようになります。
- ファイアウォール・WAF＝「入口」で不審な通信を見張る仕組み
- 改ざん検知＝サイトの「中身」に生じた変化に気づく仕組み
どちらか一方があれば十分、というものではなく、役割の異なる仕組みを組み合わせることで、初めて「侵入を防ぐ」から「万が一の変化にも気づける」体制に近づきます。
まずは、ご自身のサイトが今「入口」と「中身」のどちらをどこまでカバーできているのかを整理してみることが、次の一歩を考えるうえでの出発点になるはずです。
WEBセキュリティ関連の用語集
ファイアウォール
IPアドレスやポート番号をもとに、ネットワークの出入口で通信を許可／拒否する仕組み。「誰を通すか」を判断する。
WAF（Web Application Firewall）
Webアプリケーションへのリクエストの中身を検査し、攻撃パターンを検知・遮断する仕組み。「持ち込む中身が安全か」を判断する。
SQLインジェクション
入力フォームなどを悪用し、データベースを不正に操作する攻撃手法。
クロスサイトスクリプティング（XSS）
Webページに不正なスクリプトを埋め込み、閲覧者のブラウザ上で実行させる攻撃手法。
CMS（コンテンツ管理システム）
WordPressなど、WEBサイトのコンテンツを管理・更新するためのシステム。
サプライチェーン攻撃
委託先やプラグインなど、直接ではなく取引先・関連システムを経由して行われる攻撃。
SCS評価制度
サプライチェーン強化に向けたセキュリティ対策評価制度。委託先を含めた体制のセキュリティレベルを星の数で示す仕組み。
改ざん検知
WEBサイトを構成するファイルの内容や状態に生じた変化を検知する仕組み。侵入そのものではなく「侵入後に起きた変化」に気づくためのもの。
よくあるご質問
Q. ファイアウォールとWAF、両方入れていれば改ざんは防げますか？
A. 入口からの不審な通信に対する防御力は高まりますが、正規の認証情報を使った侵入やサプライチェーン経由の脆弱性など、通信内容の検査だけでは判定できない経路も存在します。そのため、両方導入していても改ざんのリスクをゼロにはできません。
Q. WordPressのバージョンアップはどの程度対応すべきですか？
A. すべての更新を一律に即時適用すべき、というわけではありません。深刻度が高く、悪用の実例が報告されているような修正パッチは、公開後できるだけ早く適用するのが基本です。一方、軽微な修正は定期メンテナンスのタイミングでまとめて対応し、機能追加が中心のアップデートは既存プラグインとの互換性を確認したうえで計画的に進める、といった判断でも問題ありません。パッチの中身を確認し、深刻度・影響範囲・悪用報告の有無に応じて優先度を決めるのが実態に近い進め方です。
Q. 委託先経由はなぜ侵入される可能性が高いのですか？
A. 委託先やグループ会社は、自社のシステムに正規の権限でアクセスできる立場にあります。取引先が増えるほどセキュリティレベルにばらつきが生まれやすく、そのうち最も守りの薄いところが全体の弱点になってしまうためです。攻撃者にとっても、直接ではなく守りの薄い経路から狙うほうが効率的、という側面があります。
Q. WordPressのセキュリティを高めるために、バージョンアップ以外でやるべきことは？
A. 管理画面のID・パスワードを推測されにくいものにする、多要素認証を有効にする、不要なプラグインを整理する、管理者アカウントの権限を必要最小限にする、といった対応が基本になります。加えて、万が一の侵入を前提に、ファイルの変化に早く気づける仕組みを備えておくことも重要です。
Q. フィッシングメールやマルウェアで、どのようにID・パスワードが流出するのですか？
A. フィッシングメールでは、実在するサービスを装った偽サイトへ誘導し、そこで入力させたID・パスワードをそのまま盗み取ります。マルウェアの場合は、感染した端末上でキー入力やブラウザに保存された認証情報を収集し、外部へ送信する手口が一般的です。いずれも本人が気づかないうちに情報が盗まれるため、気づいたときには既に悪用されている、というケースが少なくありません。
Q. 改ざんはどのくらいの頻度で起きるものですか？
A. 業種や規模を問わず発生しており、特にCMSの脆弱性やプラグインの管理不備を突かれるケースが多く報告されています。頻度よりも「気づくまでの時間」が被害の大きさを左右する点が重要です。
Q. 自社サイトが改ざん対策として何をすべきか分かりません。何から始めればよいですか？
A. まずは現在の防御体制が「入口の監視」と「中身の変化の把握」のどちらをどこまでカバーしているかを棚卸しすることから始めるのがおすすめです。