不正アクセスとは？自社サイトとサーバーが狙われる入口と防ぎ方を解説

不正アクセスとは、本来は利用権限がないのに、他人のIDとパスワードを入力したり脆弱性を突いたりして、機器やサービスを使える状態にする行為です。定義は総務省の国民のためのサイバーセキュリティサイト⁠によります。

今日やることは、自社が外に公開しているものと、それに入れるIDを書き出すことです。会社のサイト、採用サイト、問い合わせフォーム、サーバーの管理画面、VPN機器を並べ、それぞれに更新の担当者がいるかを確かめます。

担当者の欄が空いている行が、最初に手を付ける場所です。

不正アクセスは自社にも関係がある？

関係があるかどうかは、会社の規模より、外に公開しているものがあるかで決まります。

警察庁の令和7年の報告では、センサーが検知した脆弱性探索などの不審なアクセスは、1日・1IPアドレスあたり9,605.7件でした。2025年⁠の不正アクセスの認知件数⁠は7,190件で、前年より1,832件増えています。

この7,190件⁠の内訳は、ネットバンキングの不正送金等が4,747件⁠と最も多く、ウェブサイトの改ざん・消去は上位3つ⁠に入っていません。統計は警察が把握した件数なので、自社サイトの危険の大きさをそのまま表す数字ではないと考えてください。

緊急度を見るなら、2026年10月9日⁠に公表されたIPAの点検の呼びかけ⁠が参考になります。金融機関や通信事業者などで情報漏えいの公表が相次ぐなか、外部公開のアプリケーションやサービスの侵害、アカウントの侵害が起点になっているとうかがえる、としています。

自社サイトとサーバーで狙われる入口はどこ？

順番は次の4つ⁠で見ます。件数の統計と、公開している側で手を打ちやすいかを踏まえた、私たちの整理です。

1. 管理画面のログイン

不正アクセスの入口として、最初に見るのがIDとパスワードです。2025年の統計では、検挙された不正アクセス行為407件⁠のうち399件が、他人のIDなどを入力する型でした。脆弱性などを突く型は8件です。

ただし、これは検挙できた事件の内訳で、被害全体の割合ではありません。脆弱性を軽く見る根拠にはしないでください。

399件⁠の入手経路は、パスワードの設定・管理の甘さにつけ込んだものが84件⁠、フィッシングサイトが77件でした。同じ資料は管理者側の対策として、推測されやすいパスワードを設定できないようにすること、使い回しをしないよう周知すること、二要素認証やパスキーの導入を挙げています。

管理画面には、ID・パスワードに加えて別の確認を組み合わせる多要素認証を入れます。製品を選ぶときは多要素認証の製品比較で、対応する認証方式と、自社のサービスとつながるかを確かめます。

2. 公開中のソフトの脆弱性

CMS本体やプラグインの更新が止まっているサイトは、脆弱性が残ったままになります。

2026年7月には、IPAがWordPressの脆弱性（CVE-2026-60137、CVE-2026-63030）について注意を呼びかけ⁠、影響を受けるサイトは直ちに更新するよう案内しました。自動更新が効いたかどうかを確認し、更新されていなければ手動での更新を検討するよう書かれています。

「自動更新にしているから大丈夫」⁠で止めず、実際の版数を見て確かめる手順を残します。古い検証サイト、終わったキャンペーンのページ、使っていないプラグインは、閉じるか消すほうが守る範囲を減らせます。

更新まで時間がかかるサイトは、WAFの製品比較で、攻撃の影響を減らす手段も検討できます。WAFの要否はWAFが自社サイトに要るかの判断基準⁠で整理しています。

3. 遠隔接続の入口

サイトそのものの外にある入口です。警察庁の令和7年の報告は、ランサムウェア被害組織へのアンケートで、侵入経路の6割以上⁠がVPN機器だったとしています。

サーバーの保守用の接続も同じ考え方で扱います。誰が、どこから、何のために接続するのかを決め、必要な接続元に絞ります。サーバーの中の守りはサーバーセキュリティの製品比較で見比べられます。

4. 残ったID

統計では、IDを知り得る立場にあった元従業員や知人等による犯行が61件ありました。同じ資料は、利用する立場でなくなった人のIDの削除やパスワードの変更を速やかに行うよう求めています。

サイトの場合、社内の人より制作会社や以前の保守業者のIDが盲点になりがちです。たとえば、部品メーカーが5年前に制作会社へ依頼した製品カタログサイトで、当時の担当者用の管理者IDが残っている場合です。社内の退職手続きには出てこないので、契約の終了時に消す手順が要ります。

不正アクセスされていないか確かめるには？

見るのはログとIDです。IPAの2026年10月の案内は、公開しているアプリケーションごとに直近のログを確認し、エラーの出力量や平時との差異を手がかりに、直近1か月から3か月へと範囲を広げる方法を示しています。

外部サービスでは、次の点を確かめるよう挙げています。

• ログイン失敗の量
• ログイン元のIPアドレスとログイン時間が、平時と違っていないか
• 作った覚えのないアカウントがないか
• 削除や無効化をしたはずのアカウントが有効になっていないか

ログの保有期間はサービスごとに違い、提供者と利用者で見られる範囲も違うとされています。調べたい時点のログが残っていないこともあるので、保有期間は今のうちに確かめます。

Webサーバーのログを自社で持っている場合は、IPAの攻撃兆候検出ツール iLogScanner⁠が使えます。アクセスログから攻撃と思われる痕跡を検出するためのツールで、SSHやFTPサーバのログも対象です。

異常なログやIDを見つけたら、IPAは速やかにセキュリティインシデントと判定して対応を進め、専門のセキュリティベンダーに詳細調査を依頼することを強く勧めています。ログの削除やサイトの作り直しを先に進めると調査の手がかりが減るおそれがあるので、依頼先に相談してから動いてください。

どこまで対策すれば十分？

サイトで何を扱っているかで変わります。次の3段階で考えると、社内で説明しやすくなります。

ECサイトを自社で構築している場合は、IPAのECサイト構築・運用セキュリティガイドラインに、管理画面のアクセス制限やログの保管などの要件が並んでいます。チェックリスト形式の対策要件も載っています。

IPAの案内には、持っている情報そのものを減らす視点もあります。不要な情報は持たないという原則で、保有情報を必要最小限にする点検です。問い合わせフォームの受信データを何年分もサーバーに残しているなら、消してよい範囲を決めるだけで、漏れたときの影響を小さくできます。

サイト全体の守り方はWebサイト・サーバー防御のカテゴリ⁠にまとめています。止まる被害への備えはDDoS攻撃への備えの決め方⁠、通信の暗号化の確認はSSL証明書の確かめ方⁠を読むと、同じ一覧表に項目を足せます。