サイト運営者のサイバー攻撃対策ガイド

サイトを守るには、更新だけでなく、管理アカウント、公開するデータ、外部サービス、バックアップまで管理する必要があります。WordPressの更新が済んでいても、盗まれたサーバーのパスワードや、公開された顧客データから被害が起きることがあります。

このページは、会社・店舗のWebサイト、ブログ、会員サイト、通販サイトを運営する方のための総合ガイドです。自分で操作する項目と、サーバー会社・制作会社へ確認する項目を分け、予防から異常の発見、復旧までを整理します。PHP以外の実行環境や、静的サイト・SaaS型のサイトにも関わる対策を扱います。

対象:サイト運営者・保守担当者 / 情報確認日:2026年10月23日(日本時間)

サイト運営者が最初に確認する5つの対象

「ログインできる」「トップページが開く」だけでは、安全を確認したことになりません。サイトの管理に使う入口、稼働中のソフトウェア、保存データ、外部サービス、復旧手段を分けて点検します。小規模サイトでも、公開された管理画面や古いソフトウェアが自動的な攻撃の対象になり得ます。

例えば、メールを乗っ取られると管理アカウントの再設定につながり、古いプラグインの欠陥から入られるとページやデータを書き換えられる場合があります。入口が異なるため、一つの製品を入れるだけで対策が終わるわけではありません。

今日の着手順:被害の有無、重要な更新、管理権限、復元手段

1. 異常と緊急告知を確認する。改ざんの兆候があれば初動対応へ。通常の状態なら、利用製品の公式告知と自サイトの版を照合し、悪用が確認されている問題や、外部から管理権限を奪われる重大な問題を優先します。
2. 重要アカウントを保護する。メール、ドメイン管理、サーバー、CMS(サイトを管理・更新するシステム)の管理者を洗い出し、二段階認証と復旧手段の登録状況を確認します。
3. 更新前に戻せる状態を確保する。直近のバックアップの中身、取得日時、復元担当を確認します。更新を先送りするためではなく、短時間で安全に実施するための準備です。
4. 担当と期限を決める。自分で直せない項目は、保守会社へ対象・作業予定・完了を示す情報を確認します。「対応を依頼した」と「実際に直った」を分けて記録します。

基本的な保護対象と責任分担: WordPress公式の安全管理ガイド。攻撃や改ざんの手口: 警察庁のウェブサイト改ざん対策。

保守を任せているサイトも、対象と責任者を台帳にする

最初に、公開ドメイン・サブドメイン、本番と検証環境、CMS・実行環境、フォーム、決済、メール、DNS、バックアップを一覧にします。DNSは、ドメイン名と接続先を結び付ける仕組みです。古いサイトや使っていない管理ツールも、公開されたままなら点検対象です。

台帳には、対象・管理画面・契約者・担当者・保守期限・更新前後の版・最終確認日・次の作業期限を記録します。パスワード、APIキー、二段階認証の復旧コードは台帳へ平文で並べず、閲覧者を制限した専用の保管方法で管理してください。サイトが止まっても読める連絡先一覧も用意します。

メール・ドメイン・サーバー・CMSのアカウントを守る

二段階認証は、管理者本人の登録と復旧方法まで確認する

二段階認証は、パスワードに加えて別の要素でも本人を確認する仕組みです。対応していれば、フィッシングに強いパスキーやセキュリティキーを優先して検討します。認証アプリのワンタイムコードを使う場合も、偽のログイン画面へコードを入力させられる危険は残るため、普段のブックマークから管理画面を開きます。

• メール、ドメイン管理、レンタルサーバー・クラウド、CMSをそれぞれ確認する。一つに設定しても、他のサービスには自動で適用されません。
• 管理者ごとに専用アカウントを使い、使い回さない長いパスワードをパスワード管理ツールなどで管理する。退職者・契約終了した委託先の権限を回収する。
• 二段階認証の設定後は再ログインを試し、予備の認証手段や復旧コードを安全に保管する。登録用QRコードやコードの画面を公開・共有しない。
• 心当たりのない承認通知を押さない。通知が繰り返される場合は拒否して管理担当へ報告し、ログイン履歴を確認する。

WordPressに二段階認証用のプラグインを入れただけでは、各管理者の登録や適用確認は終わりません。また、ブラウザーの二段階認証とは別に使われるアプリパスワード・APIトークン・SSH鍵も、用途と権限を確認します。不要なものを失効させる際は、予約投稿や外部連携への影響を先に確かめてください。

認証方式と復旧時の注意: CISAの多要素認証ガイド / OWASPの多要素認証・復旧の説明。

ドメインと管理用メールは、サイトの復旧にも必要

ドメイン管理アカウントを奪われると、接続先や登録情報を変更される危険があります。更新通知の受信先、連絡先、契約期限、移管ロックの設定を確認します。移管ロックは他社への移管を抑える保護であり、すべてのDNS変更を防ぐ機能とは限りません。提供元が説明する保護範囲を確認してください。

管理用メールを失うと、パスワードの再設定や事業者からの通知も受け取れなくなります。メールにも二段階認証を設定し、自サイトのドメインが使えない場合の連絡手段を確保します。制作会社任せでも、登録名義とアカウントを誰が管理しているかは把握してください。ICANNのドメイン乗っ取り防止策が参考になります。

CMS・追加機能・実行環境を分けて更新する

WordPress本体、プラグイン、テーマ、PHPなどの実行環境、OS・Webサーバーは、それぞれ別の更新対象です。管理画面の「最新」という表示が、サーバー全体の安全を意味するわけではありません。Node.jsやJavaなどを使うサイトでも、実行環境とアプリの保守を分けて確認します。

公式告知で確認するのは、製品名だけでなく、影響する版、悪用に必要な条件、修正版、すでに攻撃が確認されているか、自サイトで該当機能を使っているかです。重大な脆弱性は月次点検の日を待たずに扱います。更新できない事情がある場合は、修正までの公開制限や機能停止を保守担当と決め、期限のない先送りにしないでください。

WordPressでは、使っていない追加機能も一覧に入れる

正規の更新機能と提供元の配布物を使い、入手元不明の「有料プラグイン無料版」などを入れないようにします。停止中のプラグインやテーマも残存ファイルと依存関係を調べ、不要と確認できたものは設定・データの退避後に整理します。子テーマが必要とする親テーマや、復旧用に維持しているテーマを一律に消さないでください。

自動更新を使う場合は、成功・失敗の通知と、更新後の主要機能を確認する担当を決めます。更新が頻繁なサイトほど、修正を急ぐことと、不具合を早く見つけることをセットにします。提供終了した製品は、最新版の番号だけでなく移行先を検討する必要があります。

PHPを使うサイトで確認すべき脆弱性と更新手順

2026年10月21日に公表されたPHPの重大な脆弱性は、CMSの更新だけでは実行環境の欠陥を修正できない例です。PHPを使うサイトは、Web用の実行版とサーバー会社の対応状況を確認してください。IPAの注意喚起も参照できます。

PHP脆弱性対策・安全管理ガイドへ
自分のサイトで動くPHPを調べる。修正版、サポート期限、更新前後の確認は専用特集で詳しく解説しています。

最新の修正・不具合の続報は速報・最新トラブルページへ。個別の告知で示された修正版を、将来も固定して使い続ける版と受け取らず、後続のセキュリティ更新も確認します。

フォーム・会員情報・アップロードを、必要な人だけが使える状態にする

運営者がコードを書かなくても、フォームや会員機能で「何が保存され、誰が読めるか」は確認できます。集める個人情報を業務上必要な範囲に絞り、保存先・閲覧者・保存期間を決めます。顧客情報を含む本番データを検証サイトへ丸ごとコピーして公開する運用は避けてください。

会員機能は、管理者として正常に動くことだけでなく、一般会員や未ログインの人が見てはいけない情報を取得できないことを、テスト用データで確認します。公開フォルダーに置いたデータベースの書き出し、設定ファイルのコピー、ログ、クラウドストレージの公開設定も対象です。検索に出さない指定は、閲覧制限の代わりになりません。

実装と診断の基礎: IPA「安全なウェブサイトの作り方」 / SQLインジェクション対策 / OWASPの権限制御 / アップロード保護。診断で指摘がなかったことは、あらゆる攻撃を防げる保証ではありません。

WAF・HTTPS・DDoS対策は、守る対象がそれぞれ違う

WAFは、対象ドメインで有効か、どこで検査されるか、検知ログを誰が確認するかまで点検します。記事保存やフォームが止まった場合は、時刻・URL・操作内容とログを照合し、必要な例外だけを調整します。全ルールを無期限に無効にして解決としないでください。エックスサーバーの公式説明も、WAFだけで完全に防御できるわけではないと案内しています。

HTTPSは通信中の保護であり、正規のサイト自体が改ざんされていれば、不正な内容も暗号化して届けられます。証明書の期限・自動更新失敗を点検し、管理画面と利用者向け画面の両方で安全な通信を維持します。OWASPのTLS運用ガイドを参照してください。

DDoSが疑われるときは、サーバー会社やCDNなどの対策事業者へ早めに連絡します。CDNはコンテンツ配信を分散する仕組みですが、契約していればすべての通信や接続先が自動で守られるとは限りません。事前に保護範囲と緊急時の手順を確認してください。単にアクセスが増えた、サイトが遅いというだけで攻撃と断定せず、負荷・通信・エラーの記録を照合します。CISAなどのDDoS対応ガイド(PDF)。

広告・計測タグ・外部連携も、管理者と変更履歴を把握する

自分のサーバーを更新していても、ページが読み込む外部スクリプトや、外部サービスに渡した権限から影響を受けることがあります。広告、アクセス解析、チャット、予約、決済、タグ管理サービスについて、提供元・用途・管理者・読める情報・設置場所を一覧にします。OWASPは外部JavaScriptの変更や情報漏えいのリスクを説明しています。

対策として必要なタグを一括削除するのではなく、変更を管理します。タグ管理サービスの権限と二段階認証を確認し、追加・差替えには担当者と履歴を残します。広告枠、同意管理、フォームや決済が、変更前後で正常に働くかを点検してください。機密情報を外部タグへ渡さないため、送信される項目も保守担当が確認します。

CSPは、ブラウザーが読み込めるスクリプトなどを制限する仕組みです。汎用の設定例をそのまま強制すると、広告・計測・埋め込み・ログインなどを止める場合があります。導入するなら、まず遮断せず違反を報告するReport-Onlyで影響を調べ、必要な許可と安全性を整理してから適用します。MDNのCSP導入ガイドに沿って、技術担当者が検証してください。

バックアップは「取得済み」ではなく「安全に復元できる」で判断する

バックアップは、改ざん・削除・ランサムウェア・更新失敗から戻すための備えです。ただし、盗まれた情報を取り返すことや、侵入された原因を直すことはできません。復元手段と、侵入経路を塞ぐ作業は別に必要です。

• 必要なものがそろうか:データベース、画像などのファイル、設定、独自コードを確認します。注文や会員情報が増えるサイトは、どの時点まで失ってよいかを決めて取得間隔を設定します。
• 同時に消されないか:本番と同じ管理権限だけで全世代を削除できる状態を避けます。別の保管先、オフライン保管、改変・削除を制限する機能などを、契約条件に合わせて組み合わせます。
• 中身と鍵を守れているか:バックアップをWebからダウンロードできないようにし、個人情報を含む場合は暗号化やアクセス制限を行います。復号鍵を失うと戻せないため、鍵の復旧も含めて管理します。
• 実際に戻せるか:本番を上書きせず、隔離した検証環境へ復元して主要機能を確認します。外部へのメール送信や本番決済は止め、所要時間と不足した情報を記録します。

前日のコピーがあっても、改ざんが一週間前から始まっていれば、そのコピーにも不正な内容が含まれるかもしれません。複数世代を持ち、正常と判断できる時点と根拠を確認します。復旧で古いデータベースを戻す際は、最新の受注・問い合わせを失わないための差分の扱いも決めてください。

保管先の分離と復元試験: CISAのランサムウェア対策ガイド。容量・世代数・復元費用・保持期限は、利用中のサービスの契約で確認します。

改ざん・不正ログイン・情報漏えいが疑われる場合の初動

覚えのない管理者や外部転送、身に覚えのないページ、フォームの送信先変更、異常なデータ読出しなどは調査のきっかけです。一方、更新ミスや外部サービスの障害でもサイトは止まります。システム障害・復旧情報で外部要因も確認しつつ、自サイトのログや変更履歴と照合してください。他社の障害が出ていることだけで原因を決めないようにします。

1. 記録を取り、連絡する。発見した日時・タイムゾーン、URL、症状、画面、直前の変更を控え、保守担当とサーバー会社へ連絡します。侵害された可能性のあるメールだけに依存せず、安全な連絡手段を使います。
2. 被害拡大を抑える。利用者へ不正なページを配信している場合などは、担当者と公開停止・アクセス制限・環境の分離を急ぎます。証拠保全も並行し、ログ・対象ファイル・必要なスナップショットを保護します。
3. 入口と影響を調べる。CMSだけでなく、メール、ホスティング、管理端末、APIキー、同じ契約内のサイトも確認します。どのデータが読まれた・書き換えられた可能性があるかを調べます。
4. 原因を直し、信頼できる状態へ復旧する。修正版の適用、侵害前と確認できるデータや正規ファイルからの再構築、不要権限の回収を組み合わせます。安全な端末・経路から認証情報を変更し、必要に応じて既存セッションやトークンも失効させます。
5. 再開条件を確認する。原因への対処、主要機能、利用者データの整合、認証情報、ログの状態を確認して再開します。トップページが表示されたことだけを復旧完了にせず、再発や不審な通信を継続して確認します。

不審なファイルの一括削除、ログの初期化、原因不明のままの再インストールは、調査に必要な手掛かりを失う場合があります。攻撃者への対抗アクセスも行わず、技術担当者や調査機関へつないでください。警察庁はログの保全と通報・相談を案内しています。WordPressでは公式の侵害時対応ガイドも参考になります。

個人情報の漏えいは、調査完了を待たずに報告の要否を確認する

個人データの漏えい等が起きた場合や、そのおそれがある場合は、法令上の報告・本人への通知が必要になることがあります。不正な目的による漏えい等は、人数だけで報告不要と判断できません。責任者・法務担当は、個人情報保護委員会の要件・期限・報告先を速やかに確認してください。業種等で報告先が異なる場合もあります。

利用者への案内は、確認できた事実、影響範囲、利用者に必要な対応、問い合わせ先を分けて伝えます。「漏えいはありません」と調査前に断定したり、未確認の攻撃者名・原因を公表したりしないようにします。

防御を強める変更は、広告と業務機能を含めて検証する

設定を厳しくするほど安全になるとは限りません。管理画面全体への制限がフォームの通信を止めたり、認証の変更が外部連携を止めたりすることがあります。対象を絞り、変更前の状態と戻し方を残し、一つの変更ごとに結果を確認します。

REST API、XML-RPC、Cron、管理画面配下の通信などは、利用状況を調べず一括遮断しないでください。不要な経路を整理する場合も、機能や外部連携への依存を確認します。不具合時に脆弱な版へ戻して公開し続けるのではなく、必要な公開制限と、修正済み環境での復旧を検討します。

サイトを再開した後も、漏洩した情報の調査と利用者への通知が必要

自社サイトが復旧しても、外部へ流出した個人情報を回収できるとは限りません。運営会社は、どの期間の誰の情報が対象なのかを調べ、利用者が取るべき対応と問い合わせ先を案内します。対象範囲の追加や訂正が判明した場合も、利用者への説明が必要です。

フォームや予約システムなどの外部サービスで漏洩が起きた場合は、自社サイトから送信されたデータが含まれるか、サービス提供元に確認してください。情報漏洩が起きた企業の被害範囲や通知・相談窓口は、サイバー攻撃・情報漏洩の最新情報で確認できます。

日常管理は、担当・期限・確認結果を残して続ける

以下は運用を決めるための目安です。決済・個人情報を扱うサイトや更新頻度の高いサイトでは、確認間隔と通知体制を厳しくします。重要な脆弱性・侵害の兆候は定例日を待たず対応します。

「対策済み」という回答だけで終えず、対象ドメイン・実際の版・適用日時・確認結果をそろえると、次の更新や担当交代で同じ確認をやり直す負担が減ります。運営者が自分で確認できない技術項目は、責任者と確認方法を決めるところまで進めてください。

サイトのサイバー攻撃対策で迷いやすいこと

小さなブログや静的サイトも狙われますか?

規模だけで対象外にはなりません。静的サイトでも、ドメイン、公開用アカウント、配信基盤、外部スクリプト、別サービスのフォームは残ります。PHPを使わないならPHPの更新は不要ですが、残っている管理対象を確認する必要があります。

セキュリティプラグインを増やせば安心ですか?

機能の重複は、誤遮断や不具合の切り分けを難しくする場合があります。現在の保護機能と不足する機能を一覧にし、更新・認証・権限・復旧をそれぞれ確認してください。プラグイン導入だけで侵害後の調査や復元まで完了するわけではありません。

障害とサイバー攻撃はどう区別しますか?

画面のエラーだけでは決められません。事業者の公式情報、発生時刻、対象地域・機能、直前の変更、負荷とアクセスの記録を合わせて調べます。システム障害ページは外部サービスの確認、速報ページは更新や既知の不具合の確認に使い、自サイトの侵害調査とは分けて進めてください。