WordPressサイトの不審アクセス調査とバックアップファイルの公開リスクへの対応

2026年10月、PHPに関するセキュリティ上の問題が話題となり、私も複数のクライアントサイトで状況確認や対策に追われていました。普段からWebサイトの制作や運用に関わっていますが、今回の対応ではサーバーの設定や保守状況を改めて確認する必要がありました。その流れで、自分が運営しているmarkeTransのWebサイトについても、どのようなアクセスが届いているのか調べてみることにしました。取得したのは、2026年10月21〜26日付のアクセスログ12,897件と、27日に追加取得した752件。合計13,649件の記録です。調べてみると、わずか数秒間に数百件のリクエストを送る自動スキャンや、サーバー内のファイルを探すようなアクセスが見つかりました。普段は目にすることのない通信の記録に、正直なところ驚かされました。

しかし、今回の調査で最も考えさせられたのは、外部からの攻撃そのものではありません。アクセスログをきっかけに調査を進めるなかで、自分が管理しているサイトのバックアップファイルが、外部から取得できる可能性の高い状態になっていたことが分かったのです。この記事では、実際のログで何を確認したのか、情報漏洩の可能性をどう判断したのか、そしてどのような対策を行ったのかを紹介します。あわせて、WordPressを利用しているWebサイト担当者が、自社サイトでも確認できるポイントを整理しました。

1. 自社サイトのアクセスログに残っていた大量の不審なリクエスト

セキュリティ対応をきっかけに、自社サイトのログを確認

2026年10月、PHPの脆弱性に関する情報を受け、Xserverでも予防的な安全対策や修正パッチの適用が進められていました。私自身もクライアントサイトのPHPバージョンを確認し、サーバー管理会社への問い合わせや関係者への連絡を行っていました。PHPは、WordPressなどのWebシステムで広く利用されているプログラミング言語です。今回の対応では、サーバー側での修正パッチの適用状況を確認するとともに、古いバージョンを利用しているサイトについて、今後の更新方針も検討する必要がありました。なお、Xserverは2026年10月26日までに、今回の脆弱性について対象サーバーへの修正対応を完了したと発表しています。ただし、今回自社サイトで確認された不審アクセスが、この脆弱性を悪用したものと特定できたわけではありません。

参考：Xserver公式｜PHPの脆弱性に関する安全対策について（2026年10月21日）

こうした対応を進めるなかで、自社サイトの状況も気になり、Xserverのサーバーパネルからアクセスログを取得しました。アクセスログとは、Webサイトに対して「どこから、いつ、どのURLに、どのようなリクエストが送られたか」を記録したものです。Webサイトの訪問状況を分析するGA4（Google Analytics 4）などとは異なり、ページが表示される前に発生したアクセスや、存在しないファイルへのアクセスなども確認できます。今回分析した7ファイルには、合計13,649件のリクエストが記録されていました。なお、Xserverのログファイル名に付く日付と、記録された個々のアクセス日時は必ずしも一致しません。実際、10月21日付のファイルにも22日未明のアクセスが含まれていたため、個別の出来事についてはログ内の日時を基準に確認しています。

わずか8秒ほどで482件のアクセス

特に目を引いたのは、10月21日15時10分頃の記録です。同じIPアドレスから、わずか8秒ほどの間に482件ものリクエストが送信されていました。IPアドレスは、ネットワーク上で通信相手を識別するための番号です。ログではアクセス元を調べる手がかりになりますが、IPアドレスだけで操作者個人を特定できるわけではありません。この482件のリクエスト先を調べると、一般的なページ閲覧とは異なる特徴がありました。WordPress関連のファイルだけでなく、サーバーの設定情報や、各種プログラムに関係するファイルを探すアクセスが短時間に集中していたのです。

そのほかにも、調査したログには次のような記録がありました。

例えば、.envや.gitといったファイル・ディレクトリを探すアクセスがありました。これらはシステムの設定情報や開発時の管理情報に関係するもので、公開してはいけない情報が含まれる場合があります。また、通常とは異なる名前のPHPファイルを探すリクエストも見られました。攻撃者が設置した不正プログラムの残骸や、悪用できるファイルを探す自動スキャンでは、こうした探索が行われることがあります。ただし、ファイルを探すアクセスがあったことと、そのファイルが実際に存在したことは別です。 ログに特定のファイル名が残っていたからといって、不正なプログラムが設置されていたとは判断できません。また、400エラーとなったアクセスについても、ログにはリクエスト内容が「-」としか記録されていないため、どのような通信が送られたのか、なぜその応答になったのかまでは特定できません。

10月22日の216件のアクセスも、慎重に読み解く必要がありました。このとき使用されていたPOSTは、Webサーバーにデータを送信する際に使う通信方法の一つです。リクエスト先のURLにはPHPコードに似た文字列が含まれていましたが、記録されたHTTPステータスコードはすべて301でした。301は別のURLへの転送を指示する応答であり、不正なコードの実行成功を意味しません。アクセスログには通常、POSTで送信されたデータの本文までは記録されないため、今回のログだけで試行の内容や結果をすべて把握できるわけでもありません。

AIクローラーを名乗るアクセスもあった

ログには、ChatGPTやClaudeなどに関連する名前をUser-Agentに含むアクセスも見られました。User-Agentとは、アクセスしているブラウザやプログラムが、自分の種類などをサーバーへ伝えるための情報です。ただし、User-Agentに書かれた名前はアクセス元が自由に指定できます。実際のAIクローラーによる正常な巡回の可能性もあれば、別のプログラムが名前を偽装している可能性もあるため、記載された名称だけでは判断できません。まして、AI関連の名前がログにあることをもって、AIによるサイバー攻撃が行われたと結論付けることはできません。

今回分析した13,649件という数字にも、通常の訪問者や検索エンジンのアクセス、私自身の管理操作などが含まれています。すべてが不正なアクセスというわけではありませんし、今回のPHPに関する脆弱性を利用した攻撃だったと特定できたわけでもありません。それでも、これほど多様なリクエストが自社サイトに届いていたことは、普段のアクセス解析だけでは意識していなかった事実です。そして、この調査を進めるうちに、外部からの攻撃とは別の問題が見つかりました。

2. 攻撃の調査中に見つかった、バックアップファイルの公開リスク

約163MBのバックアップファイルにHTTP 200が返っていた

アクセスログのなかに、WordPressのバックアップファイルへのアクセス記録がありました。使用していたのは「All-in-One WP Migration and Backup」という、WordPressサイトのバックアップや移行に利用できるプラグインです。このプラグインでは、バックアップを.wpressという形式のファイルとして保存できます。最初に気になったのは、そのファイルへのアクセスにHTTP 200というステータスコードが記録されていたことでした。HTTPステータスコードは、Webサーバーがリクエストにどのように応答したかを示す3桁の番号です。200はリクエストが正常に処理されたことを表しますが、それだけで何が成功したのかまでは分かりません。

そこで、ファイルが現在どのような状態で公開されているのか、実際のHTTP応答を確認することにしました。使用したのはcurlという、Webサーバーにリクエストを送って応答を確認できるツールです。今回はcurl -Iという指定でHEADリクエストを送りました。通常のGETがファイル本体などを取得するための方法であるのに対し、HEADは本文を受け取らず、応答ヘッダーと呼ばれる付加情報を確認するための方法です。その際、私が確認した応答は次のとおりです。

この応答では、サーバーが約163MBのバイナリファイルとして対象を扱っていることが分かります。Content-Lengthは応答で示されたデータのサイズに相当する値で、Accept-Ranges: bytesはファイルの一部を指定した取得に対応する旨をサーバーが示しているものです。HEADリクエストではファイル本体を取得していないため、この結果だけで第三者がファイル全体をダウンロードできたと実証したわけではありません。しかし、少なくとも認証を求める応答ではなく、対象ファイルへのリクエストが正常に処理されていました。バックアップが外部から取得可能な状態であることを強く疑うには、十分な材料でした。

バックアップファイルには何が含まれるのか

WordPressのバックアップには、作成方法や除外設定によって、記事やユーザーに関係するデータベース、画像、テーマ、プラグイン、各種設定情報などが含まれます。サイトを復元するための情報がまとめられているため、障害が起きたときには非常に役立つものです。一方で、バックアップの内容によっては、一般に公開していない情報も含まれます。ユーザー情報やサイト内部の設定、外部サービスとの連携情報などが含まれていれば、第三者による取得は情報漏洩につながる可能性があります。

ここで注意したいのは、今回の事象を「All-in-One WP Migrationの脆弱性」と断定できるわけではないということです。プラグインが通常どのようなアクセス制御を設定する仕様なのか、今回の環境でその制御が適切に適用されていたのかについては、追加の検証が必要です。私が確認できたのは、自分が管理しているサーバー上で、バックアップファイルへのHTTPリクエストに200が返される状態があったという事実でした。

そして、今回の調査で最も反省したのも、この点です。バックアップを作成することには注意を払っていましたが、作成したファイルが外部からどのように見えるのか、十分に確認できていませんでした。セキュリティに関する問題を調べていたはずが、調査対象はいつの間にか自分自身の運用に移っていたのです。バックアップは「取得できているか」だけでなく、「どこに保管され、誰がアクセスでき、必要なときに復元できるか」まで管理する必要があります。頭では理解していたつもりでしたが、今回の出来事でその重要性をあらためて実感しました。

3. 情報漏洩は起きたのか？ログとHTTP応答を照合して判断する

HTTP 200があっても、すぐに侵入成功とは判断できない

バックアップへのアクセスに200が返っていたことを確認し、次に気になったのは、すでに第三者がファイルを取得していないかということでした。そこで、アクセスログからバックアップファイルに関係する記録を抽出し、アクセス元、日時、通信方法、ステータスコードを照合しました。この作業で重要になるのが、HTTPステータスコードを過大評価しないことです。例えば200は、通常のページ閲覧でも返される番号です。攻撃を疑うURLに200が記録されていても、不正な処理が実行されたとは限りません。反対に、403や404が返されているからといって、サイト全体の安全性が保証されたわけでもありません。

主なコードの意味を整理すると、次のようになります。

今回のログ分析でも、これらのコードだけで結論を出さず、どのURLに、いつ、どのアクセス元からリクエストが送られ、その前後に何が起きていたかを確認しました。

バックアップへのGETは、管理者の操作と整合していた

再調査の結果、対象ログにおいてバックアップファイル本体への成功したGETリクエストとして確認されたのは、2026年10月21日23時19分51秒の1件でした。GETはサーバーからデータを取得する際に使われる通信方法で、この記録ではHTTP 200が返され、転送量は163,029,344バイトとなっていました。そこで、このアクセスの直前に何が起きていたかを確認しました。同じIPアドレスからWordPressの管理画面へアクセスしたあと、All-in-One WP Migrationのバックアップ画面を開き、バックアップ生成に関係する操作が連続して記録されています。その直後に対象ファイルへのGETが行われており、これは私が管理画面からバックアップを作成・取得した操作と時系列が整合するものでした。

もちろん、アクセスログだけで操作者の本人性まで証明できるわけではありません。また、サーバーのログに記録された転送量がファイルサイズと一致していても、受信側でファイルを正常に保存・利用できたことまで保証するものではありません。ただ、実際の管理操作と照合できたことから、このGETリクエストを第三者による不正取得の証拠と考える根拠はありませんでした。

10月27日に追加取得したログについても確認しましたが、第三者によるバックアップ本体の取得を示す記録は見つかりませんでした。ただし、ここから「情報漏洩はなかった」と断言することはできません。今回取得したアクセスログに含まれない期間や、記録されていない別の経路まで完全に調べられたわけではないからです。したがって、今回の調査結果を正確に表現するなら、「調査したアクセスログの範囲では、第三者によるバックアップファイルの取得を示す証拠は確認されなかった」となります。セキュリティに関する情報は、不安を感じるような数字や表現だけが注目されがちです。しかし、私は実際に何が確認できて、何がまだ分からないのかを分けて考えることが大切だと思っています。問題を過小評価しないことと、証拠のない被害を断定しないことは、両立できるはずです。

4. 実際に行ったセキュリティ対策と、確認した結果

まずバックアップへのアクセスを制限する

公開リスクが見つかったため、最初に優先したのはバックアップファイルへの外部アクセスを制限することでした。今回使用しているXserverには、指定したディレクトリにBasic認証を設定する機能があります。Basic認証は、Webサイトの特定の場所にアクセスする際に、ユーザーIDとパスワードの入力を求める仕組みです。通常の公開ページとは異なり、認証情報を持つ人だけがアクセスできるようにするために利用できます。

サーバーパネルの「アクセス制限」から、バックアップファイルを保管していたディレクトリを対象に設定を行いました。ただし、管理画面上で設定を有効にしただけでは、意図したとおりに機能しているとは限りません。そこで、設定前にHTTP 200が返っていたバックアップファイルへのリクエストを再度確認しました。その結果、10月27日13時11分47秒には200だったHEADリクエストが、アクセス制限の設定後、13時16分8秒には401を返すようになりました。さらに、同じバックアップの保管先に対するGETリクエストでも401を確認しています。なお、GET側はURLのスラッシュ表記に違いがあるため、HEADと完全に同じURL表記で両方を検証したわけではありません。それでも、確認したリクエストに対して認証が求められるようになったことは、設定変更が機能していると判断する根拠になります。

続いて、バックアップファイルをpublic_htmlの外側に退避しました。Xserverのpublic_htmlは、Webサイトの公開ファイルを配置するディレクトリです。その外にバックアップを移すことで、直接公開される領域に置かない運用へ変更しました。ただし、バックアップファイルの移動や削除は、復元に必要なデータやプラグインの管理画面に影響する場合があります。今回の対処を参考にする場合でも、いきなりファイルを削除することはおすすめしません。まずは保存場所、アクセス制限、復元方法を確認し、必要に応じて制作会社や保守会社と調整するのが適切です。

参考：Xserver公式｜アクセス制限（Basic認証）

XML-RPCへのアクセス制限とWAFの設定を確認

バックアップファイルへの対処に加えて、WordPressとサーバー側の設定についても点検しました。まず確認したのは、XML-RPCへのアクセス制限です。XML-RPCは、外部のアプリケーションなどからWordPressの記事を投稿したり、情報を操作したりするために使われてきた仕組みです。今回のアクセスログにも、この機能を利用するxmlrpc.phpへのPOSTリクエストが繰り返し記録されていました。

Xserverには、XML-RPC APIに対するアクセス制限機能があります。APIとは、外部のサービスやプログラムが、Webサイトなどの機能を利用するための窓口となる仕組みです。ただし、Xserverの制限機能はXML-RPC自体を完全に無効化するものではありません。公式マニュアルでは、国外および一部の国内ホスティングサービス環境からの接続を制限する機能と説明されています。外部サービスの利用状況によっては、制限が連携に影響する可能性もあるため、今回はその仕組みを理解したうえで設定を確認しました。

次に確認したのが、WAF（Web Application Firewall）です。WAFは、Webサイトに届く通信の内容を検査し、不正な操作につながる可能性のあるリクエストを検知・遮断する仕組みです。例えば、問い合わせフォームなどから不正な命令を送ってデータベースを操作しようとする攻撃や、ページに不正なプログラムを埋め込もうとする攻撃への対策に利用されます。Xserverでは、XSS（不正なスクリプトを埋め込む攻撃）、SQL（データベースへの不正な命令）、ファイル、メール、コマンド、PHPという6種類の対策項目が用意されています。今回はこれらの設定状態を確認し、見直しました。

ただし、WAFを有効にすればすべての攻撃を防げるわけではありません。正常な通信を不審なものと誤判定し、フォームの送信や外部サービスとの連携を妨げることもあります。重要なのは、単に設定を厳しくすることではなく、サイトで必要な機能を把握したうえで、適切な保護と正常な動作を両立させることです。

管理者権限と外部連携も点検

サーバー側の設定に加えて、WordPressの管理者アカウントとアプリケーションパスワードについても確認しました。アプリケーションパスワードとは、外部のツールやプログラムがWordPressのAPIを利用する際に使える専用の認証情報です。WordPressでは、外部ツールからの記事作成や情報取得などに利用されます。

こうした連携は便利ですが、利用しなくなった外部ツールの認証情報や、不要になった管理者アカウントが残っていると、管理すべきリスクが増えます。一方、必要な認証情報を誤って無効化すると、運用中のシステムが停止する場合もあります。今回は管理者権限と認証情報の利用状況を監査し、不要なものが残っていないか確認しました。今回実施した対策のうち、バックアップへのアクセス制限についてはHTTP応答で動作を確認できました。それ以外の設定も点検しましたが、設定状況の確認と、あらゆる攻撃に対する防御効果の実証は別の話です。確認した公開リスクに対して主要な対策は完了しましたが、それによってWebサイト全体の安全性が保証されたわけではありません。

5. AIによるアクセスログ分析でできたこと、できなかったこと

大量のログから、調査すべき箇所を絞り込む

今回のログ解析では、AIも活用しました。13,649件のアクセス記録をすべて人の目で確認し、アクセス元のIPアドレスや日時、URL、ステータスコードを照合していくのは、かなりの手間がかかります。そこで、ログの構造を読み取り、短時間に集中したアクセスや、不自然なファイル探索などを分類し、調査対象を絞り込む作業にAIを利用しました。

例えば、同じアクセス元から数秒間に何件のリクエストが送られたか、どのようなURLが繰り返し探索されているか、特定のファイルに成功したGETリクエストが存在するか、といった情報を整理できます。今回もこうした集計から、優先して確認すべきアクセスを把握できました。ただし、AIが「攻撃の可能性が高い」と分類したからといって、実際に攻撃が成功したことにはなりません。特定のURLへのアクセスを機械的に抽出するだけでは、正常な管理操作や検索エンジンのクロールまで不審なアクセスとして分類してしまう可能性もあります。そのため、今回は元ログを再集計し、重要なリクエストについては時系列とHTTP応答を照合しました。10月22日の216件のPOSTがすべて301だったことや、バックアップへのGETが管理者の操作と整合していたことも、こうした確認を通じて整理できたものです。

AIの分析結果と、実際のサーバーの状態は分けて考える

AIの強みは、大量の情報を整理し、調査の手がかりを見つけられることです。一方、実際のサーバー設定やファイルの公開状態を、ログの内容だけから確定できるわけではありません。今回のバックアップファイルについても、最終的な判断材料になったのは、実際に行ったHEADリクエストの200応答と、アクセス制限を設定したあとの401応答でした。AIによる分析が疑問を見つけ、実測によってその疑問を確かめる。こうした役割分担が適切だと感じています。

もう一つ注意したいのが、AIに渡すログそのものの取り扱いです。アクセスログにはIPアドレスやアクセス先のURLが含まれ、場合によってはURLのパラメータなどに認証に関係する情報が記録されることもあります。外部のAIサービスに入力する場合は、そのサービスのデータ取り扱い条件を確認したうえで、不要な個人情報や認証情報をマスキングするなどの対策が必要です。中小規模のWebサイトでも、AIを使えばログ分析を始めるハードルは下げられます。ただし、専門家の判断が不要になるわけではありません。特に侵害が疑われる場合や、個人情報の流出が懸念される場合には、ログやファイルなどの証拠を保全したうえで、適切な専門家に相談する必要があります。

6. 自社サイトは大丈夫？Web担当者が確認したい5つの項目

今回のような調査を行うには、アクセスログやHTTP通信に関する知識が役立ちます。しかし、すべてのWebサイト担当者が自分で詳細なログ解析を行う必要はありません。まずは現在のサイトの状態と運用体制を確認し、何が管理されていて、何が確認できていないのかを整理することから始められます。ここでは、WordPressを利用しているサイトを想定し、確認したい5つの項目を紹介します。WordPress以外のCMSを利用している場合も、同じ観点で保守・運用の状態を確認できます。

① WordPress本体・プラグイン・テーマは更新されているか

WordPressの管理画面にログインし、「ダッシュボード」の「更新」画面や「プラグイン」「外観」の画面から、更新が必要なものがないか確認します。更新には新機能の追加だけでなく、既知の不具合や脆弱性を修正するものもあるため、長期間更新されていないソフトウェアには注意が必要です。ただし、更新通知が表示されたからといって、重要なサイトですぐにすべてを更新すればよいとは限りません。テーマやプラグインの組み合わせによっては、更新後に表示や機能が変わる場合もあります。現在のバックアップと復元方法を確認したうえで、誰がいつ更新し、問題が起きたらどう戻すのかまで決めておくと安心です。

担当者自身で確認できるのは、更新の有無と、更新作業を誰が担っているかという点です。互換性や復元方法が分からない場合は、制作会社・保守会社に確認したうえで進めてください。

参考：WordPress公式｜WordPressの更新方法

② 不要な管理者アカウントや外部連携は残っていないか

WordPressの「ユーザー」画面では、現在登録されているアカウントと権限を確認できます。以前の制作会社の担当者や退職したスタッフなど、現在は利用していないアカウントが残っていないかを調べましょう。管理者権限はサイト全体の設定を変更できるため、必要な人だけに付与するのが基本です。あわせて、外部ツールとの連携に使用するアプリケーションパスワードも確認したいところです。WordPressでは通常、該当するユーザーのプロフィール画面から設定状況を確認できますが、サイトの構成によっては機能が無効化されていたり、表示方法が異なったりします。

見覚えのない認証情報があっても、すぐに削除するのは避けたほうがよいでしょう。外部サービスが現在も利用している可能性があるためです。まずは用途と管理者を確認し、不要だと判断できたものから整理します。どのシステムが利用しているのか分からない場合は、保守担当者へ確認してください。

参考：WordPress公式｜アプリケーションパスワード

③ バックアップファイルはどこに保存されているか

今回の経験から、特に確認してほしい項目です。WordPressのバックアッププラグインを利用している場合は、管理画面や設定からバックアップの保管場所を確認します。サーバー側の自動バックアップを利用している場合には、どこに保存され、どのような手順で復元できるのかも確認しておくとよいでしょう。

ここで重要なのは、バックアップが存在することだけで安心しないことです。保管先がWeb公開領域にある場合は、外部から直接取得できないよう、適切なアクセス制御が行われているかを確認する必要があります。ただし、Web公開領域にあるというだけで、必ず外部に公開されていると判断できるわけではありません。サーバーやプラグインによってアクセス制御の仕組みは異なります。Webサイト担当者は、まずバックアップの作成方法と保存先を把握してみてください。設定が分からない場合は、制作会社や保守会社に「バックアップファイルは外部から直接取得できない状態になっていますか」「実際に復元できることは確認していますか」と尋ねるだけでも、具体的な点検につながります。ファイルの削除や移動は、その回答を得てから検討するのが安全です。

④ WAFやログイン保護の設定は適切か

Xserverを利用している場合は、サーバーパネルの「WAF設定」や「WordPressセキュリティ設定」から、現在の保護機能の設定状況を確認できます。WAFは先ほど説明したとおり、不審な通信を検知・遮断する仕組みです。また、WordPressセキュリティ設定には、管理画面やXML-RPCなどへのアクセスを制限する機能があります。ただし、制限の対象や適用範囲は機能ごとに異なり、すべてのアクセスを遮断するものではありません。

Webサイト担当者は、まず現在の設定がどのような状態かを確認しましょう。設定を変更する場合は、問い合わせフォームや外部システムとの連携に影響が出ないかも検証する必要があります。判断が難しい場合は、設定項目の意味とサイトの利用状況を整理し、保守担当者に相談してください。

参考：Xserver公式｜WAF設定 ／ Xserver公式｜WordPressセキュリティ設定

⑤ 問題が起きたとき、誰が何を確認するか決まっているか

最後は、技術的な設定ではなく運用体制についてです。例えば、Webサイトへの不審なアクセスが増えたとき、誰がアクセスログを調べるのでしょうか。更新後にサイトが正常に表示されなくなった場合、誰が復旧を判断するのでしょうか。バックアップがあっても、復元手順が分からなければ、必要なときに対応が遅れてしまいます。

Xserverでは、サーバーパネルからアクセスログを確認・ダウンロードできます。ただし、確認できる期間や保存方法には条件があるため、問題が起きてから過去の記録を探しても、必要な情報が残っていない場合があります。重要なサイトでは、ログをいつまで保管し、どのような状況で調査するかも考えておく必要があります。すべてを社内で対応する必要はありません。制作会社や保守会社と契約している場合は、保守範囲に更新作業、監視、ログ調査、障害対応、バックアップの復元などがどこまで含まれるか確認しましょう。契約しているから対応してもらえると思っていた作業が、実際には契約範囲外だったという認識のずれを防ぐことも、運用上の大切な対策です。

参考：Xserver公式｜アクセスログ

7. WordPressが危険なのではなく、運用できる状態をつくることが大切

今回の出来事を振り返ると、大量の不審なアクセスを調べたことが、結果として自分自身のサイト運用を見直すきっかけになりました。ただ、この経験を理由に「WordPressは危険だから使うべきではない」と結論付けるつもりはありません。WordPressには柔軟なカスタマイズ性や豊富な機能があり、サイトの目的に応じてさまざまな使い方ができます。一方、利用者側でCMS本体やプラグインの更新、権限管理、バックアップなどを管理する必要がある場合もあります。

SaaS型CMSでは、システム基盤の保守や更新をサービス提供者が担うことが多く、利用者の負担を減らせる場合があります。しかし、アカウントの管理や外部サービスとの連携、コンテンツの取り扱いといった責任がなくなるわけではありません。静的サイトも、動的なCMSに由来する一部の攻撃対象を減らせる可能性はありますが、サーバーや公開ファイル、外部サービスの管理まで不要になるものではありません。

どの仕組みにも異なるメリットと管理上の課題があるため、私がWebサイトの仕組みを選ぶ際に重視したいのは、クライアントが実現したい機能や更新頻度だけでなく、保守に割ける予算と人的リソース、障害時に誰が対応するのかという条件です。機能が豊富であっても適切に管理できなければ、運用上の負担が増えることがあります。反対に、機能が限定されていても、必要な要件を満たし、無理なく管理できるのであれば、それが適切な選択となる場合もあります。

今回のバックアップファイルの問題も、こうした運用と管理の延長線上にあると考えています。バックアップを作成するという必要な作業は行っていました。しかし、外部からどのようにアクセスできるかまで把握できていなかった。その見落としに気づけたのは、不審なアクセスをきっかけに、普段は見ていなかったサーバーの状態を確認したからでした。

Webサイトの運用というと、コンテンツの更新やアクセス解析、問い合わせの改善など、マーケティングに関わる業務を思い浮かべることが多いと思います。私自身も日頃はそうした領域を中心に支援していますが、サイトが正常に稼働し、必要な情報を適切に管理できる状態を維持することも、運用の重要な一部です。プラグインの追加や外部サービスとの連携、担当者の交代などによって管理すべき内容は変わるため、制作時に適切だった設定が、その後もすべての状況に合っているとは限りません。

まずは自社サイトの状態を確認することから

今回の記事を読んで、まず何か一つ確認してみようと思った方は、以下の5項目から始めてみてください。

最初からすべての対策を自分で実施する必要はありません。現在の設定を把握し、分からないことを明確にして、必要な担当者へ確認するだけでも前進です。特にバックアップファイルの移動や削除、アクセス制限の変更などは、サイトの正常な動作や復旧方法に影響する可能性があるため、状況を確認してから判断してください。

今回、アクセスログから第三者によるバックアップファイルの取得を示す証拠は確認されませんでした。しかし、調査を通じて実際の公開リスクを発見し、対処できたことには意味がありました。もしアクセスログを確認していなければ、ファイルの公開状態にも気づかず、従来どおりの運用を続けていたかもしれません。どのツールを使うとしても、大切なのは自社のWebサイトが今どのような状態にあるのかを把握し、リスクを理解したうえで、必要な対応を判断できることです。その状態をつくり、維持していくことも、Web運用の大切な仕事だと考えています。