「うちは大企業じゃないから狙われない」が最も危険な思い込み

サイバー攻撃のニュースを見ても「うちみたいな会社は攻撃対象にならない」と考えていないでしょうか。

IPA（独立行政法人情報処理推進機構）の情報セキュリティ10大脅威 2026を見ると、「サプライチェーンの弱点を悪用した攻撃」が組織向け脅威の上位にランクインしています。大企業を直接攻撃するよりも、セキュリティが手薄な取引先を経由して攻撃するほうが容易だからです。

JPCERT/CCのインシデント報告対応レポートでも、Webサイト改ざんやフィッシングサイト設置が依然として高い割合を占めています。攻撃者は脆弱なサイトを自動スキャンで発見するため、企業規模に関係なく標的になります。

さらに、CISA（米国サイバーセキュリティ・インフラストラクチャセキュリティ庁）のKnown Exploited Vulnerabilities Catalogには、実際に悪用が確認された脆弱性が日々追加されています。WordPressプラグインやネットワーク機器の脆弱性も多数含まれており、中小企業のWebサイトが使う製品も例外ではありません。

つまり、御社のWebサイトのセキュリティホールが、取引先の大企業への攻撃の踏み台になりかねないのです。セキュリティインシデントが発覚した場合、取引先からの信頼を失い、取引停止に至るケースも珍しくありません。

この記事では、専任のセキュリティ担当者がいない企業でも、今週中に確認・対応できる5つのチェックポイントを解説します。なお、内閣サイバーセキュリティセンター（NISC）の「小さな中小企業とNPO向け情報セキュリティハンドブック」も、組織全体のセキュリティ方針を整理する際の参考になります。

チェック1：SSL証明書は正しく設定されているか

WebサイトのURLが「https://」で始まっていることを確認してください。「http://」のままのサイトはブラウザが「保護されていない通信」と警告を表示し、訪問者に不安を与えます。

SSLの確認方法は簡単です。ブラウザのアドレスバーに鍵マークが表示されていれば、SSLは有効です。鍵マークをクリックすると、証明書の有効期限も確認できます。より詳細な診断が必要な場合は、Qualys SSL Labs のSSL Server Testにドメインを入力すると、証明書の設定状況や暗号化強度をA〜Fのランクで評価してくれます。

Cloudflareを使っている場合、SSL証明書は自動で発行・更新されるため、期限切れの心配は基本的にありません。自社でSSL証明書を管理している場合は、更新期限をカレンダーに登録しておくことを強く推奨します。証明書の期限切れでサイトが表示できなくなるトラブルは、いまだに頻発しています。

SSLに加えて、**HSTS（HTTP Strict Transport Security）**の設定も確認しましょう。HSTSを有効にすると、ブラウザが常にHTTPS接続を強制するため、HTTP経由での中間者攻撃を防止できます。Cloudflareの場合、ダッシュボードの「SSL/TLS」→「エッジ証明書」から簡単に有効化できます。

SSL/TLSの設定に自信がない場合は、Mozilla SSL Configuration Generatorも活用してください。Webサーバーの種類とバージョンを選ぶだけで、推奨される暗号スイートやプロトコル設定を自動生成してくれます。

チェック2：CMSとプラグインは最新版か

WordPressなどのCMSを使っている場合、本体・テーマ・プラグインすべてを最新版に更新しているかが最重要のチェックポイントです。

WordPress公式のセキュリティガイドでも強調されている通り、WordPress関連の脆弱性の大半は、古いバージョンのプラグインやテーマに起因します。攻撃者は公開された脆弱性情報を利用して、更新されていないサイトを自動的にスキャンし攻撃します。

その深刻さを示す数字があります。PatchstackのWordPressエコシステム脆弱性レポートによると、週あたり300件を超える新しい脆弱性が報告されています。さらに、パッチが提供されていない脆弱性も相当数含まれるため、不要なプラグインを残すこと自体がリスクです。

2026年に入ってからは、サプライチェーン攻撃も深刻化しています。正規のプラグイン開発者のアカウントが乗っ取られ、バックドアが仕込まれた更新が配信されるケースが実際に報告されています。プラグインの更新は重要ですが、同時に「信頼できるプラグインだけを使う」という選定の目も求められます。

管理画面にログインし、ダッシュボードに「更新」の通知が出ていないか確認してください。更新がある場合は、バックアップを取った上で速やかに適用します。使っていないプラグインやテーマは削除してください。存在するだけで攻撃の対象になり得ます。

WordPress 5.6以降は、マイナーバージョンの自動更新が標準で有効になっています。メジャーバージョンの自動更新も「ダッシュボード」→「更新」画面から有効化でき、プラグインの自動更新も個別にオンにしておくと、脆弱性パッチが迅速に適用されます。

利用中のソフトウェアに既知の脆弱性がないか確認するには、JVN（Japan Vulnerability Notes）でCMSやプラグイン名を検索してください。CVE番号と対策方法が日本語で確認できます。

チェック3：管理画面のアクセス制限

WordPressの管理画面（/wp-admin/）やログインページ（/wp-login.php）は、初期設定では世界中の誰でもアクセスできる状態になっています。これは玄関の鍵を開けっぱなしにしているようなものです。

対策として、管理画面へのアクセスをIPアドレスで制限するか、二要素認証（2FA）を導入してください。CloudflareのZero Trustを使えば、Access機能で管理画面へのアクセスをメールアドレス認証付きに変更でき、技術的な難易度は低く抑えられます。

パスワードについても確認が必要です。「admin」「password123」のような脆弱なパスワードが使われていないか、管理者アカウントのパスワードを12文字以上のランダムな文字列に変更してください。パスワードマネージャー（1Password、Bitwardenなど）を使えば、複雑なパスワードでも管理の負担はほとんどありません。

2026年現在、パスワードに代わる認証手段として**パスキー（Passkeys）**が急速に普及しています。パスキーはFIDO2/WebAuthn標準に基づく認証方式で、フィッシング耐性があり、パスワード漏洩のリスクそのものを排除できます。WordPressでもプラグインでパスキー認証を導入でき、Google・Apple・Microsoftのアカウントですでに対応が進んでいます。FIDO Allianceで技術仕様と対応サービスの一覧を確認できます。

さらに、ログイン試行回数の制限も有効です。ブルートフォース攻撃（総当たり攻撃）では、ログインページに大量のパスワードを自動試行されます。Cloudflare WAFのレート制限ルール、またはWordPressプラグイン（Limit Login Attempts Reloadedなど）で、一定回数のログイン失敗後にアクセスをブロックできます。

チェック4：WAF（Webアプリケーションファイアウォール）の導入

WAFは、Webサイトへの不正なリクエスト（SQLインジェクション、クロスサイトスクリプティング等）を自動的に検知・ブロックする仕組みです。これらの攻撃手法はOWASP Top 10として体系化されており、WAFはこれらの既知の攻撃パターンを網羅的に防御します。

Cloudflareを利用している場合、マネージドルールセットを有効化するだけでWAFが機能します。Freeプランでも基本的なWAF機能が利用可能です。

WAFに加えて、Bot Fight Modeの有効化も強く推奨します。ボットによる自動攻撃（クレデンシャルスタッフィング、スクレイピング、脆弱性スキャン等）は、人間によるアクセスよりも圧倒的に多い場合があります。京谷商会では実際に、1日126万リクエストものボット攻撃をCloudflare無料プランの機能だけで撃退した実績があります。詳しくは「1日126万リクエストのボット攻撃をCloudflare無料プランだけで撃退した全記録」をご覧ください。

WAFの導入が特に重要なのは、お問い合わせフォームや検索機能など、ユーザーからの入力を受け付けるページがあるサイトです。これらのページは、不正な入力を使った攻撃の標的になりやすいためです。

WAFを導入したら、HTTPセキュリティヘッダーの設定も検討してください。Content-Security-PolicyやX-Content-Type-Optionsなどのヘッダーを適切に設定することで、WAFと合わせてより堅牢な防御層を構築できます。詳しくは「HTTPセキュリティヘッダー完全ガイド」をご覧ください。

チェック5：バックアップは自動で取れているか

セキュリティ対策をどれだけ施しても、インシデントの発生をゼロにすることはできません。万が一の際に復旧できるかどうかを分けるのが、バックアップの有無です。

バックアップの基本原則として「3-2-1ルール」を覚えておいてください。データのコピーを3つ保持し、2種類の異なるメディアに保存し、そのうち1つはオフサイト（別の場所）に保管する、というルールです。

バックアップの確認ポイントは3つです。まず、自動バックアップが毎日実行されているか。次に、バックアップデータがWebサーバーとは別の場所に保管されているか（サーバーごと攻撃されたら意味がないため）。最後に、バックアップからの復旧手順が文書化され、テスト済みか。

この3つ目が意外と見落とされます。バックアップは「取っている」だけでは不十分で、実際に復元できるかを定期的にテストしなければ意味がありません。ランサムウェア被害に遭った際に、バックアップデータが破損していた・復元手順が誰もわからなかったという事例は後を絶ちません。半年に1回でよいので、復元テストをスケジュールに組み込んでください。

Cloudflare Pagesで運用している静的サイトの場合、ソースコードがGitリポジトリに保存されているため、実質的にバックアップが常に取れている状態です。データベースを使っている場合は、D1の自動バックアップ機能やCronジョブによるエクスポートを設定してください。

まとめ

Webセキュリティは「完璧を目指す」のではなく、「最低限の対策を確実に実行する」ことが重要です。

まずは来週、この記事の5つのチェックポイントを1つずつ確認し、対応が必要な項目をリストアップしてください。SSL、CMS更新、管理画面保護の3つだけでも対応すれば、サイバー攻撃のリスクは大幅に低減できます。

あわせて読みたい