ホームページのセキュリティ対策とSSLの基本

攻撃や設定ミスが起きると、サイト表示だけでなく、事業と利用者へ影響します。

事象	主な影響
不正ログイン	内容変更、アカウント追加、データ取得
改ざん	偽情報、詐欺ページ、外部サイトへの転送
マルウェア	閲覧者への被害、検索・ブラウザーの警告
情報流出	利用者対応、信用低下、報告・調査の負担
大量送信	ドメイン・メールの評価低下、送信停止
サーバー停止	問い合わせ、予約、販売、案内の停止
ドメイン失効・乗っ取り	Webとメールの停止、第三者による悪用

原因は、古いCMS・プラグイン、弱い・使い回したパスワード、退職者アカウント、過大な権限、公開したバックアップ、外部スクリプト、設定ミスなど、複数あります。

安全性は「一度設定して終わり」ではありません。サイトの重要度、保存データ、機能、更新頻度に応じて、予防、検知、復旧の三つを用意します。

Webサイトで一般にSSLと呼ばれるものは、現在は主にTLSという仕組みを使い、ブラウザーとサーバー間の通信を暗号化・認証します。URLはhttp://ではなくhttps://で始まります。

HTTPSによって、通信途中で内容を盗み見られたり改変されたりする危険を減らせます。サーバー証明書により、接続先ドメインの確認にも使われます。

ただし、HTTPSは次を保証しません。

• 掲載内容や運営者が信頼できる
• Webアプリに脆弱性がない
• 管理者アカウントが乗っ取られない
• 保存された個人情報が暗号化されている
• 外部スクリプトやリンク先が安全

詐欺サイトでもHTTPSを使えます。鍵マークだけで安全と判断しないようにしましょう。

新規サイトでは、最初からHTTPSを前提に作成します。既存のHTTPサイトをHTTPSへ変更する場合は、証明書を有効にするだけでなく、URLと外部設定を一貫して切り替えます。

1. 対象URLを確認する：独自ドメイン、wwwの有無、必要なサブドメインを整理します。
2. バックアップを取る：サイトファイル、データベース、現在のDNS・サーバー設定を保存します。
3. 証明書を発行・設定する：サーバーまたは作成サービスの手順で、対象ドメインの証明書を有効にします。
4. サイト内URLをHTTPSへ統一する：内部リンク、画像、CSS、JavaScript、フォーム送信先、canonicalを確認します。
5. HTTPからHTTPSへ転送する：旧URLから対応する新URLへ恒久的にリダイレクトし、二つのURLを並存させません。
6. 検索・外部サービスを更新する：XMLサイトマップ、Search Console、アクセス解析、広告、外部連携の登録URLを確認します。
7. 公開後にテストする：全ページ、フォーム、ログイン、予約・決済、証明書更新、リダイレクトを確認します。

よくある不具合は、HTTP画像が残る混在コンテンツ、転送の繰り返し、www有無の不一致、canonical・サイトマップに残った旧URLです。ページを数件見るだけでなく、主要URLを一覧で検査し、証明書の自動更新に失敗した場合の通知先も設定しておきましょう。

ソフトウェアを更新する

WordPressなどのCMS本体、テーマ、プラグイン、PHP、サーバーOS、作成・連携サービスを現在サポートされる状態に保ちます。脆弱性修正を含む更新を放置しないようにします。

更新前後の基本手順は次のとおりです。

1. 更新内容、互換性、既知の問題を確認する
2. ファイルとデータベースをバックアップする
3. 重要サイトはテスト環境で確認する
4. 更新する
5. 表示、管理画面、フォーム、予約、決済などを確認する
6. 問題があれば原因を切り分け、必要に応じて復元する

自動更新を使う場合も、失敗通知と更新後確認が必要です。使っていないテーマ・プラグインは停止するだけでなく、必要性を確認して削除します。

バックアップは、改ざん、誤操作、更新失敗、障害、退職・引き継ぎなどから復旧するために用意します。

フォームを設置すると、氏名、メール、相談内容などを取得する場合があります。必要な情報だけを集め、送信、保存、閲覧、削除の流れを確認します。

• 取得目的を明示する
• 必須項目を最小限にする
• HTTPSで送信する
• 管理画面・通知メールの閲覧権限を絞る
• 保存期間と削除方法を決める
• 自動返信へ入力内容を過剰に載せない
• ファイル添付の種類・容量・検査を制限する
• スパム・大量送信・不正入力への対策を行う
• 外部フォームの保存先・再委託・国外移転などを確認する
• プライバシーポリシーと実際の運用を一致させる

取得する必要がなければ、フォームを設置しないことも対策です。このガイドサイトのように個人情報を取得しない方針なら、問い合わせフォーム、コメント、会員登録などを追加せず、将来追加するときに方針と対策を見直します。

決済情報は、自前で保存する構成を安易に選ばず、決済サービスの提供機能と適用基準を確認します。

• HTTPSと証明書の自動更新
• 管理者の多要素認証・パスキー
• 利用者・役割・操作履歴
• ソフトウェア更新の分担
• WAF、DDoS対策、アクセス制限
• マルウェア・改ざん検知
• バックアップの対象・保存期間・復元
• 障害情報と連絡手段
• データの保存場所・出力・削除
• 脆弱性報告・セキュリティ告知
• サービス終了・解約時のデータ取得

「セキュリティ対策済み」という一文では、何がサービス側の責任で、何が利用者の設定か分かりません。責任分界と初期設定を確認します。

WordPressのような設置型CMSでは、ホスティング側が基盤を守っても、利用者が追加したテーマ・プラグイン、管理者、本文、フォームは別途管理が必要です。クラウド型作成ツールでも、外部コード、ドメイン、権限、連携アプリは利用者側の確認が残ります。

完全に防ぐだけでなく、早く気づく仕組みを用意します。

• 主要ページの表示・HTTP状態を外部から監視する
• ファイル変更・管理者追加・ログインを通知する
• サーバー、CMS、WAF、メールのログを確認する
• Search Consoleのセキュリティ通知を確認する
• ブラウザーや検索結果の警告を確認する
• 外部リンク、フォーム送信、予約・決済を定期テストする
• ドメイン・SSL証明書・サーバー容量の期限を監視する
• 管理者メールと緊急連絡先を最新にする

監視通知が同じメールサーバーだけに届くと、そのサービスが停止したときに受け取れない場合があります。重要な障害通知は別の連絡経路も用意します。

異常を見つけたら、慌ててすべて削除する前に、被害拡大防止と記録保全を両立します。

1. 日時、発見者、URL、画面、症状を記録する
2. 影響する機能・データ・利用者を切り分ける
3. 必要に応じて公開停止、フォーム停止、アクセス遮断を行う
4. 正常な端末から認証情報を変更し、セッションを無効化する
5. 不審なアカウント、変更、ログ、外部通信を保全する
6. サーバー・サービス提供会社、保守担当、専門家へ連絡する
7. 信頼できるバックアップと原因を確認して復旧する
8. 表示・機能・脆弱性修正を確認して再開する
9. 必要な報告・通知・利用者対応を判断する
10. 原因、対応、再発防止を記録する

個人情報や決済情報の漏えいが疑われる場合は、自己判断だけで完結させず、適用法令、監督機関、契約先、専門家の指示を確認します。ログや改ざんファイルを先に消すと、原因調査が難しくなる場合があります。

公開前

• □ 全ページをHTTPSへ統一した
• □ 管理者・ドメイン・メールに多要素認証を設定した
• □ 初期・不要アカウントを削除した
• □ 権限を必要最小限にした
• □ CMS・テーマ・プラグインなどを更新した
• □ バックアップを取得し、復元方法を確認した
• □ フォームの取得項目・保存・通知・削除を確認した
• □ テストページ、バックアップ、設定ファイルを公開していない
• □ 外部スクリプト、APIキー、連携権限を確認した
• □ 障害・事故時の連絡先を記録した

SSLを設定すればホームページは安全ですか

通信を保護する重要な対策ですが、それだけでは不十分です。更新、認証、権限、バックアップ、フォーム、監視、事故対応も必要です。