「うちのような小さな会社のサイトは、わざわざ狙われないだろう」。そう考えて、公開後のセキュリティ対策を後回しにしていないでしょうか。
Webサイトへの攻撃は、有名企業だけを狙うものではありません。古いソフトウェアや推測しやすいパスワードといった弱点があれば、会社の規模に関係なく侵入の入口になります。被害は自社にとどまらず、サイトを訪れたお客さまに及ぶこともあります。
この記事では、Webサイトと、それを動かすCMS・サーバー・管理画面を対象に、どんな被害が起きるのか、どう守るのか、自社のサイトで何を確かめればよいのかを順に説明します。最後に、制作会社や保守会社にそのまま聞ける6つの質問をまとめました。
攻撃はAIで手間が下がり、数が増えている
ここ数年、サイバー攻撃の被害は身近なものになっています。IPA（情報処理推進機構）が毎年まとめる「情報セキュリティ10大脅威」の2026年版でも、組織への脅威の1位は「ランサム攻撃による被害」でした。2025年もデータを暗号化して身代金を求める攻撃に感染した企業・組織が多く、取引先を含むサプライチェーン全体に深刻な影響が出た事例もあったと説明されています（IPA「情報セキュリティ10大脅威 2026」）。
同じ2026年版では、「AIの利用をめぐるサイバーリスク」が初めて3位に入りました。IPAは、その中身の1つとして「AIの悪用によるサイバー攻撃の容易化、手口の巧妙化」を挙げています。
実際に、AIに攻撃の大半を実行させた事例も報告されています。AI開発企業のAnthropicによると、2025年に見つかった攻撃では、AIが作業全体の8〜9割をこなし、人が判断したのは数か所だけでした。ピーク時には1秒に何回ものペースで数千回の通信を送っており、人の手では到底追いつけない速さだったといいます。同社は、経験や資金の少ない集団でも、こうした大規模な攻撃ができるようになりつつあると指摘しています（Anthropic「Disrupting the first reported AI-orchestrated cyber espionage campaign」）。
この事例の標的は大企業や政府機関でした。ただ、攻撃にかかる手間が下がれば、弱点のあるサイトを片っ端から探して試す、ローラー作戦のような攻撃もしやすくなります。「小さな会社だから見つからない」という前提は、ますます通用しにくくなっていると考えられます。
Webサイトにはどんな被害が起きるのか
攻撃の手口の名前を覚えるより、何が起きるかを知っておく方が、対策の必要性を判断しやすくなります。事業者の立場から見ると、被害は次の6つに分けられます。1つの侵入から、いくつもの被害が同時に起きることもあります。
| 被害 | 具体的に起きること |
|---|---|
| ① ページや情報を書き換えられる | 文章や画像が変えられる、無関係な広告が差し込まれる、見覚えのないページが追加される |
| ② サイトを乗っ取られる | 管理者のアカウントやパスワードを変えられ、更新も修正もできなくなる |
| ③ 詐欺や攻撃に悪用される | 訪問者が詐欺サイトへ転送される、偽のログイン画面を置かれる、ウイルスの配布元や他のサイトへの攻撃の踏み台にされる |
| ④ 情報を盗まれる | 問い合わせ内容、会員情報、注文情報、非公開の資料などが外部に流出する |
| ⑤ サイトや機能が使えなくなる | 大量の通信を送りつけられてサイトが止まる。フォームへの大量投稿で受付業務が回らなくなる |
| ⑥ データを消される | ページやデータベースを削除・暗号化され、元に戻せなくなる |
被害は、サイトを訪れた人にも及びます。
改ざんに合わせて、ウェブサイト等に保存していた個人情報が窃取されたり、ウェブサイトを閲覧した者がウイルス感染してしまうおそれがあります。
出典：警察庁「ウェブサイト改ざん対策」
被害はサイトの中だけでは終わりません。サイトが止まれば問い合わせや売上が減り、復旧には費用と時間がかかります。お客さまへの説明やお詫びの対応も必要です。そして、「この会社のサイトは安全なのか」という不安は、復旧した後も残ります。
Webサイトを守るために実施したい6つの対策
ここからは、被害を防ぐための対策を6つ紹介します。どれか1つで全部を防げるわけではないため、組み合わせて考えます。
対策1：CMSやプラグインの弱点を放置しない
まず取り組みたい対策です。IPAの「10大脅威」でも、「システムの脆弱性を悪用した攻撃」が組織への脅威の4位に入っています。IPAはWebサイトの運営者向けに、次のように呼びかけています。
ウェブアプリケーションは様々なソフトウェアやフレームワーク、CMS等で構成されています。これらのソフトウェアに脆弱性が発見された場合、適宜バージョンアップ等の対策が必要です。
出典：IPA「安全なウェブサイトの運用管理に向けての20ヶ条」
WordPressなどのCMS本体、プラグイン、テーマは、弱点が見つかるたびに修正版が出ます。更新しないまま使い続けると、修正済みの弱点を残したまま公開していることになります。サポートが終わったソフトウェアは、修正版そのものが出なくなるため、入れ替えを検討します。
見落としやすいのが、使っていないものです。停止したまま残っているプラグインや、制作時に作ったテスト用のサイトも、更新されなければ入口になり得ます。不要なものは整理しましょう。独自に開発した機能があれば、制作会社に弱点の確認と修正を依頼します。
サーバー側のソフトウェアも同じです。レンタルサーバーなら事業者が更新する部分と、自社や制作会社が更新する部分があります。公開した後も、誰かが更新し続けて初めて安全が保たれる。この前提で、担当を契約書で確かめてください。
対策2：WAFなどで、攻撃と疑われる通信を止める
弱点を突こうとする通信を、サイトに届く前に止める仕組みもあります。
- WAF（Webアプリケーションファイアウォール）：Webサイトの弱点を狙った不正な通信を見つけて遮断する。
- IPS（侵入防止システム）：ネットワークの通信に含まれる攻撃を見つけて遮断する。
- DDoS対策：大量の通信でサイトを止める攻撃に備える。
それぞれ守る範囲が違うため、まずは契約しているサーバーにWAFの機能があるか、有効になっているかを確認してください。レンタルサーバーには、管理画面から有効にできるWAFを備えたものもあります。IPSやDDoS対策は、サーバーの契約にどこまで含まれているかを事業者に確認します。
注意したいのは、WAFを入れれば弱点を直さなくてよい、というわけではない点です。IPAもWAFを、弱点が見つかってから修正されるまでの間、攻撃の影響を減らす手段の1つとして位置づけています。弱点を直すことが先で、WAFはそれまでの間や見落としを補う仕組みと考えましょう。
対策3：管理画面に入れる人を絞る
管理画面を乗っ取られると、ページの書き換えも、情報の持ち出しも、データの削除もできてしまいます。ここを守ることは、①〜⑥のほとんどの被害を防ぐことにつながります。
- 管理者のログインに多要素認証を設定する（パスワードに加え、スマートフォンのアプリなどで本人確認する）。
- 他のサービスで使い回していないパスワードにする。
- 必要に応じて、ログインできる場所（IPアドレス）を制限する。
- 退職者や過去の外注先のアカウントを削除し、担当者には必要な権限だけを与える。
対象はCMSだけではありません。サーバーやドメインの管理アカウントを乗っ取られると、サイトの表示先そのものを別のサーバーへ切り替えられるおそれがあります。米国のサイバーセキュリティ・社会基盤安全保障庁（CISA）も、重要なシステムにアクセスするアカウントを中心に、すべてのサービスで多要素認証を使うよう勧めています（CISA「#StopRansomware Guide」）。
なお、管理画面のURLを変えるだけで対策が済んだと考えるのは早計です。見つかりにくくはなりますが、パスワードが漏れていれば意味がありません。
対策4：問い合わせフォームを悪用させない
問い合わせフォームは、誰でも送信できる入口です。だからこそ、プログラムによる大量投稿や、不正な入力の標的になります。
- GoogleのreCAPTCHA（リキャプチャ）などで、人間ではないプログラムからの送信を減らす。
- 短い時間に何度も送信できないよう制限する。
- 入力内容や添付ファイルを、サーバー側でも確認する。
- 自動返信メールが、第三者への迷惑メール送信に使われない作りにする。
大量投稿を防ぐ対策と、フォームそのものの弱点を塞ぐ対策は、別々に必要です。reCAPTCHAも、画面に表示するだけでは十分ではありません。Googleの説明では、送信時に受け取った判定用の情報をサイトのサーバーからGoogleに送り、その判定結果を見て処理を決める流れになっています（Google Cloud「reCAPTCHA（Fraud Defense）の概要」）。導入済みでも、この確認までできているかを制作会社に聞いてみてください。
対策5：情報が漏れにくい保存と公開の設定にする
ここでは、社内の情報管理ではなく、サイトの設定と作りに絞って確認します。
- サイト全体をHTTPS化し、閲覧者とサイトの間の通信を暗号化する。
- 非公開の資料、バックアップ、設定ファイルを、外から見える場所に置かない。
- 会員向けの情報は、URLを知っているだけでは見られないよう、アクセスの権限を確かめる。
HTTPSは、通信の途中での盗み見を防ぐ仕組みです。サイトへの侵入そのものを防ぐわけではないため、対策1〜3と組み合わせて考えます。
対策6：異常に早く気づき、元に戻せるようにする
どれだけ備えても、被害を完全には防げないと考えるようにします。だから、早く気づき、確実に戻せる状態を作っておきます。
- サイトの停止、ファイルの書き換え、不審なログインを監視し、異常があれば通知する。
- アクセスや操作の記録（ログ）を保存しておく。
- ファイルとデータベースの両方を、定期的にバックアップする。
- 公開サーバーとは別の場所に、過去の複数の時点のバックアップを保管する。
- 実際にバックアップから元に戻せるかを試しておく。
バックアップの保管場所は特に重要です。CISAは、重要なデータのバックアップをネットワークから切り離して保管し、復元できるかを定期的に試すよう勧めています。データを暗号化して身代金を要求する攻撃（ランサムウェア）の多くが、手の届くバックアップを探して消したり暗号化したりするためです。公開サーバーの中にしかバックアップがなければ、サーバーと一緒に失われるかもしれません。
また、バックアップから戻すだけでは、同じ入口から再び侵入されます。被害に遭ったときは、原因を調べて弱点を塞ぎ、パスワードも変更します。調査に必要なログは、バックアップと同じように保管しておきましょう。
まずは制作会社・保守会社に、この6点を確認する
6つの対策をすべて自社で実施する必要はありません。多くは、制作会社や保守会社、サーバー事業者が担っている、または担える部分です。
その前に確かめたいのが、そもそも保守の契約を結んでいるかどうか。サイトを作ってくれた会社が、公開後の保守まで引き受けているとは限りません。制作の契約は公開で終わり、その後の更新や監視は誰も担当していない、ということも珍しくないのです。保守の契約がないなら、自社で更新や確認を続けられるのかを考える必要があります。
保守の契約があるなら、次の6点を契約先にそのまま聞いてみてください。自社で保守している場合も、同じ6点を自分たちで確かめます。
- CMSやプラグインの更新と、弱点が見つかったときの対応は、誰が行っていますか？
- WAFは有効になっていますか？DDoS対策はどこまで含まれていますか？
- 管理画面に、多要素認証やアクセス制限を設定できますか？
- フォームに、大量投稿への対策、連続送信の制限、不正な入力への対策はありますか？
- 問い合わせ内容や非公開のファイルは、どこに、どんな設定で保存されていますか？
- 異常があったときの通知先、バックアップの保管場所と期間、元に戻す手順は決まっていますか？
答えが「分からない」「誰も担当していない」なら、そこが今いちばん手薄な部分です。対策の有無だけでなく、誰が継続して確認し、何かあったときに誰が動くのかまで決めておくと、いざというときに慌てずに済みます。
もっと細かく点検したい場合は、IPAの「安全なウェブサイトの運用管理に向けての20ヶ条」が参考になります。公開すべきでないファイルや不要になったページの扱い、パスワード、ログの確認、不正な通信の遮断など、運営者が定期的に確かめたい20の項目がまとめられています。
まとめ｜Webサイトも、設備と同じように保守しながら使う
Webサイトの被害は、情報を預かったお客さまに迷惑をかけてしまったり、社会的な信用を失ったり、ビジネスに大きな損失を被る可能性があります。
まずはWebサイトは機械・設備と同じように保守・メンテナンスをしながら利用するものだという認識を持ち、更新、通信の遮断、管理画面の保護、フォームの対策、保存と公開の設定、監視とバックアップといった対応ができているかを確認、状況を把握して不足している対応があれば早急に対応を取るようにしましょう。
自社サイトの対策状況を確かめたい方へ
今の契約や設定で何が守られていて、どこが手薄なのか。現在のサイトと保守の状況を伺い、確認する順番を一緒に整理します。
