ある地方の製造業の社長から、深夜に電話がありました。

「うちのホームページが、なんだか変なサイトに飛ぶようになったんですが……」

ブラウザで確認すると、その会社のコーポレートサイトにアクセスした瞬間、海外のオンラインカジノサイトにリダイレクトされる状態でした。金曜の夜から月曜の朝まで、丸2日間そのまま放置されていたそうです。原因は、3年間アップデートされていなかったWordPressの脆弱性を突かれた不正アクセス。プラグインのひとつに既知の脆弱性があり、そこからバックドアを仕込まれていました。

復旧に4日、調査と再発防止策の実装に2週間。その間、取引先から「御社のサイト、大丈夫ですか」と何件も連絡が入り、商談中だった案件が2つ流れたそうです。

この会社のサイトにはSSL（https化）すら導入されていませんでした。

中小企業にとってWebサイトのセキュリティは「IT部門の仕事」ではなく、信用問題であり、経営リスクそのものです。この記事では、まずSSL対応の基本から始めて、WordPressを含むWebサイト全体のセキュリティ対策を、技術者ではない経営者・Web担当者向けに書いていきます。

SSLとは何か

ブラウザのアドレスバーに表示される鍵マークと「https://」。これがSSL（正確にはTLS）で通信が暗号化されている状態を示しています。

SSLは「Secure Sockets Layer」の略ですが、実際には後継規格のTLS（Transport Layer Security）が使われています。業界ではまとめて「SSL/TLS」と呼ぶことが多く、この記事でも「SSL」で統一します。

仕組みをかなり簡略化して説明すると、こうなります。

  1. ユーザーがhttps://のURLにアクセスする
  2. サーバーが「SSL証明書」をブラウザに提示する
  3. ブラウザが証明書の正当性を確認する
  4. 暗号化された通信路（トンネル）が確立される
  5. 以降のデータ送受信はすべて暗号化される

暗号化されていない通信（http://）は、途中で誰でも読める状態です。SSL対応された通信は、中身を覗くには封を開ける必要がある状態に近い。問い合わせフォームで送信した名前、電話番号、メールアドレスが暗号化されないまま飛んでいると考えると、リスクの大きさがわかると思います。

GoogleはSSL対応を検索順位のランキングシグナルとして明示しています。Chrome、Edge、Firefoxなど主要ブラウザは、SSL未対応のサイトにアクセスすると「保護されていない通信」という警告を表示します。BtoB企業の場合、取引先の担当者がその警告を見た瞬間に「この会社、大丈夫か」と感じるリスクは無視できません。

SSL証明書の3つの種類（DV・OV・EVの違い）

SSL証明書には認証レベルによって3種類あります。どれを選ぶかで費用も信頼性の担保レベルも変わります。

種類正式名称認証対象費用感（年額）発行までの期間向いているサイト
DVDomain Validationドメインの所有権のみ無料〜数千円数分〜数時間個人サイト、小規模コーポレートサイト
OVOrganization Validationドメイン＋組織の実在性3万〜10万円数日〜2週間中小企業のコーポレートサイト、BtoBサイト
EVExtended Validationドメイン＋組織の厳格な審査10万〜30万円1〜4週間EC、金融、大企業のコーポレートサイト

DV証明書は、ドメインの所有者であることだけを証明します。Let’s Encryptという無料の認証局があり、多くのレンタルサーバーが標準機能として提供しています。費用ゼロで導入できるので、まずはここから始めるのが現実的です。

OV証明書は、ドメインの所有権に加えて、その組織が実在することを認証局が確認します。帝国データバンクやDUNSナンバーなどで企業の存在確認が入る。BtoBで取引先に一定の信頼を示したい場合はOV以上が望ましいです。

EV証明書は、もっとも厳格な審査を経て発行されます。以前はブラウザのアドレスバーに企業名が緑色で表示されていましたが、2019年以降はChrome・Firefoxともにその表示は廃止されています。ただし、証明書の詳細を確認すれば組織名は表示されるので、金融やEC領域では引き続き採用されています。

中小企業のコーポレートサイトであれば、まずはDV証明書で常時SSL化を完了させる。BtoBの信頼性を重視する場合は予算に応じてOVを検討する。この2段階で十分です。

常時SSL化の手順

「常時SSL化」とは、サイト内のすべてのページをhttpsで配信することです。トップページだけhttpsにして下層ページがhttpのまま、というのは不完全な対応です。

手順を整理します。

ステップ1：SSL証明書の取得・設定

利用しているレンタルサーバーの管理画面からSSL設定を行います。エックスサーバー、さくらインターネット、ConoHa WINGなどの主要レンタルサーバーは、Let’s Encrypt（無料SSL）をワンクリックで設定できる機能を持っています。

共有サーバーの場合は管理画面からの操作で完結しますが、VPSや専用サーバーの場合はサーバー設定ファイルの編集が必要になるケースがあります。

ステップ2：サイト内のURLをhttpsに書き換える

WordPressの場合、管理画面の「設定」→「一般」で、WordPressアドレスとサイトアドレスの両方を「https://」に変更します。

ただし、これだけでは不十分です。記事本文やウィジェットに書かれた内部リンク、画像のURLが「http://」のまま残っていることが多い。いわゆる「混在コンテンツ（Mixed Content）」の問題です。ページ自体はhttpsで配信されているのに、ページ内の画像やスクリプトがhttpで読み込まれていると、ブラウザが警告を出します。

WordPressなら「Really Simple SSL」や「Search Regex」というプラグインで一括置換できます。手動で全ページのソースをチェックするのは現実的ではないので、ツールに頼るのが効率的です。

ステップ3：httpからhttpsへのリダイレクト設定

http://でアクセスされた場合に、自動的にhttps://にリダイレクトする設定です。.htaccessファイルに以下のような記述を追加します。

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

301（恒久的なリダイレクト）を使うことで、SEO上の評価もhttpからhttpsに引き継がれます。

ステップ4：外部サービスの設定変更

Google Search Console、Googleアナリティクス、Googleビジネスプロフィールなどに登録しているURLをhttpsに変更します。Search Consoleはhttp版とhttps版で別プロパティ扱いになるので、https版を新たに登録してサイトマップを送信し直す必要があります。

SNSのプロフィールに掲載しているURL、名刺やパンフレットに印刷しているURLも忘れがちなポイントです。

サイト表示速度やCore Web Vitalsの改善と合わせて進めると効率がよいです。表示速度の改善方法についてはサイト表示速度の改善方法｜Core Web Vitals対策ガイドも参考にしてください。

常時SSL化でよくあるトラブルと対処法

SSL化の作業自体は難しくないのですが、実務では意外とトラブルが起きます。ディレクターとして対応してきた中で多いものを挙げます。

ひとつ目は、Mixed Contentの警告が消えないケースです。httpsに切り替えたのに、ブラウザに「安全でないリソースが含まれています」と表示される。原因のほとんどは、テーマやプラグインの中でhttpのURLがハードコードされているケースです。ブラウザの開発者ツール（F12キー）のConsoleタブにどのリソースがhttpなのか表示されるので、そこを手がかりに修正します。外部サービスのウィジェット（Googleマップの埋め込み、SNSのシェアボタンなど）が古い形式のhttpリンクを使っているケースもあります。

ふたつ目は、リダイレクトループが発生するケースです。「このページはリダイレクトが多すぎます」というエラーで、CloudflareなどのCDNを使っている場合に起きやすいです。CDN側のSSL設定とサーバー側の設定が競合して、http→https→httpと無限ループする。CDNのSSLモードを「Full」または「Full (strict)」に変更すると解決することが多いです。

みっつ目は、SSL証明書の期限切れです。Let’s Encryptの証明書は有効期限が90日間です。通常は自動更新されますが、サーバーのcron設定やレンタルサーバーの仕様によっては手動更新が必要な場合がある。証明書が期限切れになると、サイトにアクセスした瞬間に「この接続ではプライバシーが保護されません」という全画面の警告が表示されます。ユーザーはほぼ確実に離脱します。証明書の有効期限はSSLチェッカー（Qualys SSL Labsなど）で確認できます。定期的に確認するか、期限切れを通知してくれるモニタリングサービスを入れておくことをおすすめします。

WordPressのセキュリティリスク

冒頭で紹介した不正アクセスの事例はWordPressでした。WordPressは世界中のWebサイトの約43%で使われています。裏を返せば、攻撃者にとってもっとも効率のいいターゲットだということです。

ひとつの脆弱性を見つければ、世界中の何百万というサイトに同じ手口が使える。しかも、中小企業のサイトはセキュリティ対策が甘いことが多いので、攻撃の成功率が高い。

IPA（独立行政法人情報処理推進機構）の「情報セキュリティ10大脅威 2025」では、「Webサイトの改ざん」や「脆弱性を悪用した攻撃」が引き続き上位に挙げられています。

WordPressが攻撃される主な経路は3つあります。

経路1：本体・プラグイン・テーマの脆弱性

WordPress本体、プラグイン、テーマのいずれかに脆弱性があると、そこが侵入口になります。特にプラグインが危険です。WordPress公式ディレクトリには約60,000以上のプラグインがありますが、開発が放棄されたまま脆弱性が放置されているものも少なくない。

2024年だけでも、WordPressプラグインの重大な脆弱性が複数報告されています。Wordfenceのレポートによれば、2024年に報告されたWordPress関連の脆弱性は数千件に上ります。

経路2：管理画面への不正ログイン

WordPressの管理画面URL（wp-admin）は、デフォルトのまま変更していないサイトが大半です。攻撃者はボットを使って大量のID・パスワードの組み合わせを試す「ブルートフォースアタック（総当たり攻撃）」を仕掛けてきます。

パスワードが「company123」や「admin2024」のような推測しやすいものだと、数時間で突破されます。

経路3：サーバー環境の脆弱性

PHP、MySQL（MariaDB）、Webサーバー（Apache/Nginx）のバージョンが古い場合、それ自体が攻撃対象になります。特に共有レンタルサーバーでPHPのバージョンが7.4以前のまま放置されている環境は要注意です。PHP 7.4は2022年11月にセキュリティサポートが終了しています。

WordPressセキュリティ対策で最低限やりたい7つのこと

全部やるのが理想ですが、まずは効果の大きいものから順に対応します。

対策1：本体・プラグイン・テーマを常に最新に保つ

これがもっとも基本で、もっとも効果が大きいです。WordPressの管理画面にログインして、「ダッシュボード」→「更新」から一括アップデートできます。

ただし、アップデートでサイトが崩れるリスクもあるので、更新前には必ずバックアップを取ってください。BackWPupやUpdraftPlusといったバックアッププラグインを入れて、自動バックアップのスケジュールを設定しておくのが基本です。

使っていないプラグインやテーマは「無効化」ではなく「削除」してください。無効化しただけではファイルがサーバー上に残っているので、脆弱性がある場合は攻撃対象になります。

対策2：管理画面のログインURLを変更する

デフォルトの /wp-admin や /wp-login.php を別のURLに変更します。「SiteGuard WP Plugin」（日本製で設定が日本語）を入れるだけでURLの変更、ログイン試行回数の制限、画像認証の追加が一括でできます。

対策3：強固なパスワードと二要素認証

パスワードは最低16文字以上、英大文字・小文字・数字・記号を含むランダムな文字列にしてください。覚えられないなら1Passwordなどのパスワードマネージャーを使う。

さらに二要素認証（2FA）を導入すると、パスワードが漏洩しても即座に突破されません。「WP 2FA」や「Two Factor Authentication」プラグインで設定できます。

対策4：WAF（Web Application Firewall）の導入

WAFは、Webアプリケーションへの攻撃パターン（SQLインジェクション、クロスサイトスクリプティングなど）を自動的に検知・遮断する仕組みです。

レンタルサーバーによっては標準機能として提供されています。エックスサーバーの「WAF設定」、さくらインターネットの「Webアプリケーションファイアウォール」などがこれにあたります。追加費用なしで有効化できるなら、すぐにオンにすることをおすすめします。

レンタルサーバーにWAF機能がない場合は、Cloudflareの無料プランでもある程度のWAF機能が使えます。

対策5：ファイルのパーミッション設定

WordPressの設定ファイル（wp-config.php）にはデータベースのパスワードが書かれています。このファイルのパーミッションが「644」（誰でも読める）になっていたら、「400」または「440」に変更してください。

.htaccessファイルも同様に「604」以下に設定します。ディレクトリのパーミッションは「755」が基本です。

対策6：定期的なバックアップ

攻撃を100%防ぐことは不可能です。だからこそバックアップが保険になります。

バックアップの基本ルールは「3-2-1ルール」です。データのコピーを3つ持ち、2種類の異なるメディアに保存し、1つはオフサイト（別の場所）に置く。Webサイトの場合、サーバー上の自動バックアップに加えて、クラウドストレージ（Google Drive、Dropboxなど）にも保存する運用が現実的です。

BackWPupを使えば、週1回の自動バックアップをDropboxに保存する設定が短時間で終わります。

対策7：セキュリティプラグインの導入

「Wordfence Security」は無料版でもファイアウォール、マルウェアスキャン、ログイン試行制限の機能があります。日本語環境との相性がやや悪い場合は「SiteGuard WP Plugin」が代替候補です。

ただし、セキュリティプラグインは入れすぎないことが望ましいです。プラグイン同士が競合して不具合を起こしたり、サイトの表示速度が遅くなったりします。セキュリティ系は1〜2個に絞ってください。

保守運用全般のポイントについてはWebサイト保守・運用の重要性｜放置リスクと適切な管理方法も併せてご覧ください。

中小企業で実際に起きたセキュリティインシデント事例

冒頭の事例以外にも、直接・間接に関わったケースをいくつか紹介します。固有名詞は伏せますが、すべて実際にあった話です。

事例1：問い合わせフォームからのスパム爆撃

ある不動産会社のサイトでは、問い合わせフォームにreCAPTCHA（ロボット対策）を入れていなかったため、1日に数百件のスパムメールが送信される事態になりました。フォームの送信先メールアドレスが「スパム配信元」として各種ブラックリストに登録され、正規の取引先へのメールまで届かなくなった。

復旧にはメールサーバーのIPアドレスのブラックリスト解除申請が必要で、完全に復旧するまで3週間かかりました。

対策としては、Google reCAPTCHA v3の導入（無料）、フォームの送信レート制限、送信先メールアドレスの分離が有効です。

事例2：改ざんによるSEO汚染

建設会社のコーポレートサイトでは、見た目は正常に表示されているのに、検索結果に「バイアグラ 格安」といったスパムキーワードが表示される状態になりました。Googleのキャッシュを確認すると、HTMLのhead内に大量のスパムリンクが挿入されていた。

この手法は「SEOスパムインジェクション」と呼ばれ、サイト管理者が気づきにくいのが厄介です。ブラウザで見た目は正常なので発覚が遅れ、Googleからペナルティを受けて検索順位が大幅に下落。復旧後も順位が戻るまで3ヶ月以上かかりました。

対策としては、定期的なマルウェアスキャン（Wordfenceの定期スキャン機能）、Google Search Consoleの「セキュリティの問題」レポートの定期確認が挙げられます。

事例3：管理画面への不正ログインによる情報漏洩

士業事務所のサイトでは、WordPressの管理画面に不正ログインされ、問い合わせフォームから送信された顧客の個人情報（氏名、電話番号、相談内容）が流出した可能性が発覚しました。個人情報保護委員会への報告、該当者への通知、再発防止策の策定に追われた。

2022年4月に施行された改正個人情報保護法では、漏洩等が発生した場合の個人情報保護委員会への報告と本人への通知が義務化されています。中小企業であっても例外ではありません。

対策としては、管理画面URLの変更、二要素認証の導入、アクセスログの監視、個人情報の保存期間の見直しが有効です。

サーバー・ネットワークレベルのセキュリティ対策

ここまではWordPress中心に書いてきましたが、Webサイトのセキュリティはアプリケーション層だけでは完結しません。

サーバーのPHP・データベースのバージョン管理

先述の通り、古いPHPバージョンはそれ自体がリスクです。レンタルサーバーの管理画面でPHPバージョンを確認し、最新の安定版（2026年3月時点ではPHP 8.2または8.3）に更新してください。レンタルサーバーによってはワンクリックで切り替えられます。

ディレクトリリスティングの無効化

サーバーの設定によっては、URLにディレクトリ名を直打ちするとフォルダ内のファイル一覧が表示される場合があります。これを無効化するには、.htaccessに以下を追記します。

Options -Indexes

XML-RPCの無効化

WordPressのXML-RPC機能は、外部アプリからの投稿に使われますが、ブルートフォースアタックの踏み台にもなります。使っていないなら無効化してください。SiteGuard WP Pluginで設定可能です。

ファイルの編集を管理画面から禁止する

WordPressの管理画面にはテーマやプラグインのPHPファイルを直接編集する機能がありますが、不正ログインされた場合にここからバックドアを仕込まれるリスクがあります。wp-config.phpに以下を追記して無効化します。

define('DISALLOW_FILE_EDIT', true);

中小企業向けセキュリティチェックリスト

最後に、自社サイトのセキュリティ状態を確認するためのチェックリストを置きます。まずはここから始めてください。

SSL対応

#チェック項目確認方法
1SSL証明書が導入されているブラウザのアドレスバーに鍵マークが表示されるか
2全ページがhttpsで配信されているhttp://でアクセスしてhttps://にリダイレクトされるか
3Mixed Contentがないブラウザの開発者ツール（Console）にwarningが出ていないか
4SSL証明書の有効期限に余裕があるSSL Labs（ssllabs.com）でチェック

WordPress基本対策

#チェック項目確認方法
5WordPress本体が最新版管理画面「ダッシュボード」→「更新」
6プラグイン・テーマが最新版同上
7使っていないプラグイン・テーマを削除済み「プラグイン」一覧に無効化状態のものがないか
8管理画面のURLを変更している/wp-admin にアクセスしてログイン画面が出ないか
9パスワードが16文字以上のランダム文字列パスワードマネージャーで確認
10二要素認証を有効化しているログイン時に認証コードを求められるか

サーバー・運用

#チェック項目確認方法
11WAFが有効になっているレンタルサーバーの管理画面で確認
12PHPバージョンが8.1以上レンタルサーバーの管理画面で確認
13自動バックアップが設定されているバックアッププラグインの設定を確認
14wp-config.phpのパーミッションが400または440FTPクライアントで確認
15Google Search Consoleの「セキュリティの問題」を定期確認月1回はSearch Consoleにログインして確認

15項目すべてに「OK」がつかなくても、まず上から5つ（SSL関連＋WordPress最新化）をクリアするだけで、リスクは大幅に下がります。

「うちは小さい会社だから大丈夫」は通用しない

セキュリティの話をすると、「うちのような小さい会社のサイトなんて、誰も狙わないでしょう」という反応が返ってくることがあります。

これは誤解です。攻撃者は特定の企業を狙っているわけではなく、脆弱性のあるサイトをボットで自動的にスキャンして、見つけた順に攻撃しています。会社の規模は関係ありません。むしろ、セキュリティ対策の甘い中小企業のサイトのほうが入りやすいから狙われます。

JPCERT/CCの報告によれば、Webサイト改ざんのインシデント報告は中小規模のサイトが多数を占めています。

冒頭で紹介した製造業の会社は、復旧と対策に合計で80万円以上かかりました。最初からSSL対応とWordPressの基本的なセキュリティ対策をやっていれば、月額数千円の保守費用で済んだ話です。

保険と同じで、事故が起きてからでは遅い。サイトのセキュリティは「コスト」ではなく「投資」と考えるのが望ましいです。

制作段階から組み込むセキュリティ対策

Webサイトのセキュリティは、公開後に慌てて対応するよりも、制作段階から設計に組み込んでおくほうが負担も少なく確実です。

株式会社ティーラが提供するWeb制作・運用支援では、制作から保守運用までワンストップで対応する体制をとっており、セキュリティ面も制作段階から組み込んでいます。納品時点でSSL常時化、WAF設定、管理画面のセキュリティ強化、バックアップ体制の構築を標準で行い、公開後は定期的なWordPressアップデート対応、脆弱性のモニタリング、月次のセキュリティレポートを保守契約の中で提供しています。

「サイトは作ったけれど、セキュリティは何もしていない」「SSL対応したいけれどやり方がわからない」という状態であれば、現状のリスク診断から対応策のご提案までお手伝いできます。気になった方はお気軽にお問い合わせください。

参考文献