Webサイトの脆弱性を対策する方法

脆弱性とは何か：中小企業でも「狙われる」前提で考える

Webサイトの脆弱性とは、攻撃者にとって「侵入口」になり得る弱点のことです。専門的にはソフトウェアや設定、運用の不備を指しますが、非エンジニアの方は「鍵の閉め忘れ」や「壊れた窓」をイメージすると理解しやすいでしょう。鍵を閉め忘れていなくても、古い鍵（古いソフト）を使い続けているとピッキング（既知の攻撃）で開けられる、といった状況も起こります。

「当社は小さいから狙われない」と思われがちですが、現実は逆です。攻撃は手作業よりも自動化されており、インターネット上を巡回して“見つけやすい弱点”を機械的に探します。つまり、規模よりも見つけやすさ（古いCMS、弱いパスワード、放置された管理画面など）が標的になります。

脆弱性を放置すると、次のような被害に直結します。

• Web改ざん・フィッシング誘導：トップページが書き換えられ、顧客が偽サイトに誘導される
• 個人情報漏えい：問い合わせフォームや会員DB、予約情報が盗まれる
• 踏み台化：自社サーバーが他社攻撃の中継点にされ、取引先へ迷惑が及ぶ
• ランサムウェア被害：データ暗号化で業務停止、復旧・対応コストが膨らむ
• 検索順位・ブランド毀損：マルウェア配布サイト扱いで警告表示、SEOにも悪影響

情シスや経営側が最初に押さえるべきは、「脆弱性対策＝ツールを買うこと」ではなく、資産（どのサイト・どのデータが重要か）とリスクの優先順位を決め、継続運用することです。本記事では、開発知識がなくても判断できるように、具体的な対策手順・体制・外注のポイントまで整理します。

よくある脆弱性の原因：技術より「運用の穴」で起きやすい

脆弱性はプログラムのミスだけでなく、日々の運用から生まれます。特に中小企業や、予算はあるが専任が少ない情シスでは、更新の遅れ・管理の分散・権限の放置が原因になりがちです。代表的な原因を、技術用語を抑えて解説します。

CMS・プラグイン・ライブラリの更新停止

WordPressなどのCMSやプラグインは便利ですが、更新しないと既知の脆弱性が残ります。攻撃者は「古いバージョン」を狙うため、アップデート停止＝公開された弱点を抱えたまま公開し続ける状態です。担当者が退職した、制作会社との契約が切れた、更新が怖くて止めた、というケースが非常に多いです。

認証・権限管理の弱さ（ID/パスワード運用）

管理画面のIDが「admin」のまま、パスワードが使い回し、退職者アカウントが残ったまま、などは典型です。さらに、二要素認証がない、管理画面URLが誰でも辿れる、VPNやIP制限がないといった状態だと突破されやすくなります。ここは開発より運用で改善できる領域です。

入力フォームやAPIのチェック不足（想定外の値が入る）

問い合わせフォーム、検索窓、ログイン画面、予約フォームなど、ユーザーが入力できる箇所は攻撃の入口になりやすいです。例えば「住所欄に住所以外を入れられてしまう」ことで、システムが誤作動したり情報が盗まれたりするケースがあります。これらはアプリケーションの脆弱性として扱われ、テストや設計方針が不十分なまま公開されると発生します。

設定ミス・公開範囲ミス

クラウドストレージの公開設定、管理画面の公開設定、デバッグ用ページの残骸など、設定ミスは非常に多いです。「社内だけのつもり」の情報がインターネットから見えてしまうと、漏えいに直結します。特にクラウドは便利な分、初期設定の理解不足が脆弱性につながることがあります。

ログ監視・検知がない（気づけない）

侵入を100%防ぐのは現実的ではありません。だからこそ「異常を早く検知して被害を小さくする」設計が重要です。ところが、アクセスログを見ていない、アラートがない、改ざん検知がない、といった状況では、侵害されても気づけません。結果として、被害が長期化し、取引先や顧客への影響が拡大します。

まずやるべきは棚卸し：どこに脆弱性があり得るか可視化する

対策の第一歩は「何を守るか」「どこが危ないか」を把握することです。専門知識がなくても、チェックシート形式で進められます。ここで重要なのは、Webサイトは1つでも、裏側の構成要素は複数という点です。ドメイン、サーバー、CMS、フォーム、決済、外部タグ、CDNなど、要素ごとに脆弱性の発生点が異なります。

資産リスト（最低限これだけ）

• 対象Webサイト：コーポレート、採用、EC、LP、会員サイト、管理画面
• ドメインとDNS：管理会社、ログイン手段、二要素認証の有無
• サーバー/クラウド：レンタルサーバー、VPS、AWS/Azure/GCP、契約者、保守窓口
• CMS/フレームワーク：WordPress、Drupal、独自開発、利用中の主要プラグイン
• 外部サービス：問い合わせフォームSaaS、MA、決済、チャット、アクセス解析、タグマネージャ
• 保守体制：社内担当、制作会社、開発会社、連絡先、SLA

「誰が管理しているか分からない」「ログイン情報が散らばっている」状態自体がリスクです。棚卸しでは、管理の責任者（オーナー）を明確化してください。

重要度の分類（全部を同じ強さで守らない）

脆弱性対策はコストがかかります。そこで、重要度をざっくり3段階に分けます。

• 高：個人情報や決済、会員DB、業務システム連携がある
• 中：問い合わせはあるが個人情報は最小、ブランド毀損の影響は大きい
• 低：静的ページ中心、更新頻度が低く、機密データを扱わない

高の領域は「継続的な脆弱性診断＋運用監視」が必要になりやすく、中・低は「更新と設定の適正化」で効果が出やすい、という考え方ができます。

現状把握の質問（非エンジニアでも答えられる）

• 更新：CMS/プラグインはいつ更新したか。自動更新か。検証環境はあるか。
• 認証：管理者は何人か。二要素認証はあるか。退職者の権限削除は即日か。
• バックアップ：頻度、保管場所、復元手順のテスト実施有無。
• 監視：改ざん検知、WAF、ログ監視、アラート通知の有無。
• 連絡：事故時に誰が判断し、どこへ連絡するか（社内・外注・顧客）。

これらに「分からない」が多いほど、脆弱性があるかどうか以前に、攻撃を受けた際に詰む可能性が高まります。まずは分からない項目を潰すことが、最短の改善になります。

今すぐできる実務対策：優先順位つきチェックリスト

ここからは「今すぐ実施でき、効果が大きい」順に対策を並べます。すべてを一度にやる必要はありません。重要なのは、やったかどうかを記録し、毎月・毎四半期の運用に組み込むことです。

更新（パッチ適用）を止めない仕組みを作る

脆弱性対策の王道は更新です。特にCMS系は、更新停止がリスクを増やします。

• 更新方針：緊急（セキュリティ更新）は即日〜数日、通常更新は月次など期限を決める
• 検証環境：本番と同等のコピー（ステージング）で更新テスト→問題なければ本番
• 互換性確認：主要プラグインの依存関係を一覧化し、不要なプラグインは削除

「更新が怖い」という不安は、検証環境とバックアップがあれば現実的に解消できます。逆に、更新しないことで将来の復旧がもっと大変になります。

認証強化：二要素認証と権限の最小化

• 二要素認証：管理画面・クラウド・DNS・メールに必須化（SMSより認証アプリ推奨）
• 権限：管理者権限は必要最小限、編集者・投稿者など役割を分ける
• 退職/異動：即日で無効化、共有アカウントを禁止
• アクセス制限：管理画面はIP制限やVPN、少なくとも推測困難なURLにする

ここは投資対効果が高い領域です。「侵入口を減らす」より「突破されにくくする」ことから始めると、被害確率が大きく下がります。

バックアップと復元テスト：最後の保険を“使える状態”に

バックアップは「ある」だけでは不十分で、復元できることが重要です。

• 頻度：更新があるサイトは日次、重要DBはより高頻度も検討
• 世代管理：最低でも数世代、できれば30日程度の履歴
• 保管：本番と別環境（別アカウント/別ストレージ）に保管
• 復元テスト：四半期に1回でも良いので手順の確認と実施

ランサムウェアなどで暗号化されると、同じ場所のバックアップも巻き込まれることがあります。分離保管がポイントです。

WAF・セキュリティヘッダ・TLS：設定で効く防御

アプリケーションの修正には時間がかかりますが、設定で防げる攻撃も多くあります。

• WAF：既知の攻撃パターンをブロック。まずは学習/検知モード→段階的に遮断へ
• TLS（HTTPS）：常時HTTPS、古い暗号スイートの無効化、証明書の自動更新
• セキュリティヘッダ：Content-Security-Policy、X-Frame-Options等で被害を抑制

WAFは万能ではありませんが、“量産型攻撃”を減らす効果が期待できます。導入時は誤検知（正しいアクセスを止める）に注意し、段階的に調整します。

ログと改ざん検知：早期発見で被害を小さくする

• 監視対象：管理画面ログイン失敗の急増、海外IPからの不自然なアクセス、ファイル変更
• 通知：メール/チャットへのアラート、夜間の当番や外注窓口を決める
• 証跡：ログの保管期間を定め、調査に必要な情報を残す

脆弱性が突かれたかどうかは、ログがないと判断できません。「何が起きたか説明できる状態」を作ることが、顧客対応・法務対応でも重要になります。

脆弱性診断・ペネトレーションテストの使い分け：発注側の判断ポイント

予算がある企業ほど「診断を入れたいが、何を頼めばいいか分からない」という悩みがあります。結論から言うと、目的が違います。脆弱性診断は弱点の洗い出し、ペネトレーションテストは想定シナリオで実際に侵入できるかの検証です。どちらが必要かは、サイトの重要度とリスク許容度で決めます。

脆弱性診断（Webアプリ診断・プラットフォーム診断）

Webアプリ診断はフォームやログイン、APIなどアプリケーション部分の弱点をチェックします。プラットフォーム診断はOSやミドルウェア、設定面の弱点を確認します。おすすめの発注観点は次の通りです。

• 対象範囲：URL範囲、ログイン後画面、API、管理画面を含めるか
• 手法：ツールだけか、手動検査を含むか（重要サイトは手動が有効）
• 報告：再現手順、影響、優先度、具体的な修正案があるか
• 再診断：改修後の再チェックが含まれるか

診断を「受けて終わり」にしないために、改修までの責任分界（誰が直すか）を先に決めておくのが重要です。

ペネトレーションテスト（侵入テスト）

侵入テストは、例えば「外部の攻撃者が会員情報に到達できるか」「管理者権限を奪えるか」など、実際の攻撃シナリオで検証します。全社的な影響が大きいサービスや、重要データを扱う場合に有効です。

• 向いているケース：会員DB、決済、基幹連携、複数システムを跨ぐ構成
• 事前合意：許可範囲、実施時間、停止時の連絡、検証用アカウント
• 成果物：侵入経路の図解、改善の優先順位、再テスト計画

ペネトレーションテストは「怖い」印象を持たれますが、正しく設計すれば、重大事故の前に“現実の弱点”を見つけるための投資になります。

見積もり比較で失敗しないコツ

価格差が出るのは、主に「範囲」「手動の深さ」「報告の品質」「再診断」の違いです。発注側は次を確認するとブレにくくなります。

• 診断対象は漏れていないか：ログイン後、管理画面、API、サブドメイン
• “指摘数”ではなくリスクで評価：軽微な指摘が多いより、重大リスクを潰せるか
• 改修支援：開発会社と連携して直せる体制か、修正案が具体的か

事故対応まで設計する：脆弱性は「見つかった後」が勝負

脆弱性はゼロにできません。だからこそ、見つかったとき・悪用されたときに被害を抑える設計が必要です。ここは情シスや管理部門が主導しやすい領域で、事前に決めておくだけで対応スピードが変わります。

インシデント対応フロー（最小構成）

1. 検知：監視アラート、外部通報、社員からの報告
2. 一次判断：影響範囲（停止すべきか、隔離すべきか）を判断する責任者を決める
3. 封じ込め：管理アカウント無効化、WAF強化、アクセス制限、該当機能停止
4. 調査：ログ保全、改ざん箇所の特定、侵入経路の推定
5. 復旧：安全なバックアップから復元、パッチ適用、パスワード再発行
6. 再発防止：原因の根絶、運用ルール見直し、再診断

「誰が意思決定するか」が曖昧だと、停止判断が遅れ被害が広がります。経営判断が必要なライン（停止・公表・顧客連絡）を、平時に決めておくことが肝です。

連絡先と証跡の準備

• 連絡先：サーバー会社、DNS管理、開発会社、保守会社、社内責任者、法務/広報
• ログイン情報管理：共有の方法（パスワード管理ツール等）、緊急時の取り出し手順
• 証跡：ログ保全の手順、改ざんファイルの退避、タイムライン記録

事故時は時間との勝負です。平時の準備は地味ですが、最も費用対効果が高い脆弱性対策の一つです。

社内教育：最低限これだけ周知する

全社員に難しいセキュリティ教育は不要ですが、次の3点は共有すると事故が減ります。

• 不審メール：添付・リンクを開く前に確認、怪しい場合は情シスへ転送
• パスワード：使い回し禁止、二要素認証の徹底
• 異常時報告：「サイトが変」「ログインできない」「警告が出る」など小さな違和感を早期共有

まとめ

Webサイトの脆弱性対策は、技術だけでなく運用設計で大きく改善できます。まずは棚卸しで「何を、誰が、どう管理しているか」を可視化し、更新・認証・バックアップ・監視の順で優先度高く整備するのが現実的です。加えて、重要サイトは脆弱性診断やペネトレーションテストを活用し、見つかった弱点を改修し切るところまでを計画に含めることが成果につながります。

最後に、脆弱性はゼロにできない前提で、事故対応フローと連絡体制を作っておくことが重要です。準備がある企業ほど、被害を小さく、説明責任を果たしやすくなります。自社だけで判断が難しい場合は、現状整理からでも外部の知見を取り入れるとスムーズです。