情報漏洩のニュースを、自社には関係ないと片づけていませんか。まずはサイトに入る情報の流れと管理担当を把握し、更新・権限・公開範囲を順番に確認することから始められます。
この記事を見るべき方
- 自社サイトの安全管理をどこから確認するか迷っている方
- 保守会社の担当範囲と社内で行う点検を整理したい方
情報確認日：2026年11月10日。この記事は企業サイトの点検を始めるための整理です。個別の漏洩事案の原因を推定するものではありません。
国内の情報漏洩事案から、自社が確認したいこと
情報漏洩のニュースを見たとき、自社の確認は「うちは狙われるほど大きくない」で終わらせず、公開している機能、保存している情報、管理する人を整理するところから始めます。
IPAは2026年10月9日、国内の幅広い事業者で不正アクセスによる情報漏洩の公表が相次いでいるとして、点検を呼びかけました。その時点で、特定の製品・サービスの脆弱性だけが狙われたとは断定していません。IPAの注意喚起
ここから自社の対策を考えるなら、使っているCMSの更新状況だけでなく、フォーム、会員ページ、社内向け管理画面、外部サービスへの接続まで確認する必要があります。
会社案内だけのサイトに見えても、問い合わせがメールへ送られ、フォームの管理画面にも残り、担当者がCSVを保存しているかもしれません。どこに何があるかが曖昧だと、更新や削除の担当も曖昧になります。
まず、どこに情報を保存しているか整理する
入力された情報がどこへ送られ、誰が使い、いつまで残るかを一枚にまとめてみてください。次は問い合わせフォームを使う会社の記入例で、実際の事故例ではありません。
情報の置き場所 | 保存される情報の例 | 社内で確認すること |
|---|---|---|
フォーム管理画面 | 氏名・連絡先・相談内容 | 閲覧できる人と保存期間 |
通知メール | フォームの入力内容 | 宛先、転送先、退職者の受信権限 |
営業管理サービス | 顧客情報・対応履歴 | 連携アカウントと利用権限 |
CSV・バックアップ | 過去の問い合わせ情報 | 保存先、共有範囲、削除担当 |
「保存しているか分からない」も、点検で見つかった課題です。操作を知らないまま一括削除せず、業務上必要なデータや契約上の条件を確認して整理します。
企業サイトで確認したい7つの項目
ここでは、スターウィーブに保守を相談する前の整理にも使えるよう、点検項目を7つにまとめています。各項目は「確認済み・要対応・不明」に分け、根拠となる画面や回答を残すと、次の担当者へ引き継ぎやすくなります。
1. CMS・PHP・プラグインの更新状況
WordPress本体、テーマ、プラグイン、PHPの一覧を作り、更新を判断する人を確認します。更新通知を見ている人と、実際に作業する人が違うなら、連絡の流れも必要です。
使っていない機能や更新提供が終了したものについても、残している理由を確認します。PHPについては、脆弱性の確認とアップデートの進め方で具体的な確認先を整理しています。
2. 管理アカウントと権限
管理画面に入れる人を一覧にし、退職者、契約が終了した委託先、用途の分からないアカウントが残っていないか確かめます。
共有アカウントしかない場合は、誰の操作か記録できるか、担当変更時にアクセスを止められるかを確認します。多要素認証の利用可否と、端末を失った場合の復旧担当も合わせて整理します。
3. 管理画面やAPIの公開範囲
APIは、サービス同士がデータをやり取りする窓口です。画面上のメニューを非表示にすることと、APIで権限を確認することは別です。
JPCERT/CCは、管理用APIの不正操作や、一般公開を想定していない管理・運用システムの被害にも注意を促しています。JPCERT/CCの注意喚起
担当者には「この管理機能は誰が使うのか」「インターネットからアクセスできる必要があるか」「利用者ごとに権限が確認されるか」を聞いてみてください。
4. 設定ファイルとバックアップの置き場所
設定ファイルや作業用の圧縮ファイルを、外部から取得できる場所に残していないか確認します。ファイル名を推測しにくくするだけでなく、公開されない保存先やアクセス制御を確認することが必要です。
保守担当への依頼では、「公開フォルダに一時ファイルや過去のバックアップが残っていないか確認してほしい」と、対象を明示すると伝わります。
5. 外部サービスと委託先の担当範囲
予約、決済、メール配信、アクセス解析などの契約先を一覧にします。「契約を管理する人」「設定を変える人」「障害通知を受ける人」が誰なのかも記載してください。
連携用の認証情報は、使い道と管理者を記録し、不要になった場合の停止手順を決めます。台帳に秘密鍵やパスワードそのものを平文で並べる必要はありません。
6. ログと異常時の連絡先
ログとは、アクセスや操作の記録です。記録されている場所、保存される期間、確認できる人を押さえます。通知を出す設定があっても、宛先が以前の担当者なら対応につながりません。
「通知を受ける」「状況を確認する」「作業を判断する」という3つの役割を確認します。夜間・休日にどこまで対応できるかも、実際の契約に合わせて決めます。
7. データの保存期間と復元準備
保管する必要がある情報と、利用が終わった情報を分けて整理します。一方で、事故の疑いがある場合に、記録を通常の削除作業で消してしまわないよう注意が必要です。
バックアップは、取得の成否、保管先の権限、復元方法を確認します。バックアップがあることは、情報漏洩を防いだことの証明にはなりません。事業を再開するための備えとして、別に確認する項目です。
WordPress公式も、アクセスの制限、バックアップ、ログ、監視を含む継続的な対策を説明しています。単一の設定やプラグインに任せず、複数の確認を組み合わせます。WordPressのセキュリティ対策
優先して直すものを決める
点検後は、すべてを同じ順番で処理するのではなく、公開状況と影響を見て、担当者・期限を決めます。次は社内で会話を始めるための例です。
見つかった状態 | 次に取る行動 |
|---|---|
身に覚えのない管理者や変更がある | 通常作業を止め、管理責任者へ連絡し、記録保全と調査を相談する |
外部公開の機能に未対応の重大な脆弱性がある | 管理者に影響と緊急対応を確認し、修正・公開範囲を判断する |
サポート終了が近い機能がある | 移行先と検証範囲、実施日を決める |
誰が管理しているか分からない | 契約・権限・連絡先を整理し、対応漏れを確認する |
優先順位はサイトの状態によって変わります。「不明だから問題なし」にせず、調べる担当と期限を割り当てることが大切です。
不審な動きがある場合は、通常の保守と対応を分ける
侵害が疑われる状態では、更新だけで対応完了としません。 更新は今後の侵入を減らすための作業であり、既に行われた操作や、取得された情報の範囲を明らかにする作業とは異なります。
知らない管理者の追加、不審なファイル、身に覚えのない設定変更などが見つかった場合は、発見時刻と状況を記録し、管理責任者へ連絡してください。ログやファイルを削除・上書きする前に、証拠の保全、封じ込め、専門調査の進め方を相談します。
IPAも、異常なログやアカウントが見つかった場合のインシデント対応と、専門のセキュリティベンダーによる詳細調査を推奨しています。IPAの対応案内
点検で分かった課題を、改善と継続管理につなげる
点検結果は「担当・期限・完了を確認する方法」まで残すと、その後の保守に使えます。たとえば「フォームを更新する」だけでなく、「更新後に通知メールと管理画面の記録を確認する」と決めます。
スターウィーブでは、サイトの管理状況を整理し、WordPressなどの更新、設定の見直し、日常の保守で必要な作業を一緒に考えます。侵害範囲の特定など専門調査が必要な場合は、通常の更新作業とは切り分けて対応範囲を確認します。
よくある質問：問い合わせフォームだけでも点検は必要ですか？
フォームには氏名や連絡先が入力される場合があります。会員機能がなくても、保存先・通知先・閲覧権限を確認する意味があります。
よくある質問：サーバー会社に任せれば十分ですか？
サーバー側の対策と、サイト内の権限・フォーム設定・外部連携などの管理範囲を確認してください。何が契約に含まれているかを整理すると、重複と対応漏れが見えやすくなります。
よくある質問：他社制作のサイトも相談できますか？
対象URLと、分かる範囲の契約・管理状況をお知らせください。まず必要な確認と対応可能な範囲を整理します。継続して任せる範囲を考えたい方は、Webサイト保守の体制と契約の確認ポイントもご覧ください。
