脆弱性の発見が多発する今見直したい、デジタルマーケティングを止めないためのWebサイトのあり方
プロデューサー 服部PHP2ShellやHTTP2Shellなど、Webサイトを支える基盤技術で重大な脆弱性が相次いで明らかになっています。
脆弱性が公表されるたびに、「自社サイトは影響を受けるのか」「すぐにアップデートすべきか」「アップデートによってサイトに不具合が生じないか」と対応に追われているWeb担当者も少なくないのではないでしょうか。
もちろん、迅速なアップデートは重要です。しかし、脆弱性への対応を「見つかったら直す」だけで考え続けていてよいのでしょうか。
本記事では、Webサイトをデジタルマーケティングの重要な事業基盤と捉え、CMSそのものをインターネットから分離する「CMSアイソレーション」という考え方から、Webサイトのセキュリティと安定運用について考えます。
Webサイトの「緊急対応」が当たり前になっていませんか？
「重大な脆弱性」という言葉を2026/10/21を境に見る機会が多くなりました。
今話題となっているPHP2ShellのCVEがリリースされたあの日です。
PHP2Shellとは、PHP本体に存在する2件の脆弱性、CVE-2026-109618とCVE-2026-109619の組み合わせです。IPA（独立行政法人情報処理推進機構）も2026年10月22日に注意喚起を公開しており、悪用された場合、遠隔の第三者によって任意のコードを実行される可能性があります。IPAによれば、PHP 5.4以降のバージョンは、これらの脆弱性の少なくともいずれかの影響を受けるとの報告があります。
PHPはCMSを含むさまざまなWebシステムで利用されています。そのため、これは決して一部の特殊なシステムだけの話ではありません。
また、ほぼ同時期には、Brotliデコーダーの脆弱性CVE-2026-111497も公表され、「HTTP2Shell」「Node2Shell」などの名称で注目されました。こちらはNode.jsだけでなく、Python向けパッケージやBun、Envoy、Istioなどにも影響が及んでいます。なお「HTTP2Shell」という通称からHTTP/2そのものの脆弱性とも受け取れますが、実際にはBrotliの展開処理に起因する問題です。
こうした事例を見ると、Webサイトの担当者に突き付けられている課題が見えてきます。
それは、「いつどこにどのような脆弱性が見つかるのかわからない、そしてそれはAI駆動による調査で今まで以上に多発する」ということです。
パッチを当て続けるだけでは解決しにくい問題
もちろん、脆弱性が明らかになれば、対象を確認して必要なアップデートを行うことは重要です。
PHP2ShellについてもIPAは最新版へのアップデートを対策として挙げています。同時に、古いシステムの場合、アプリケーション改修や動作確認、資料やノウハウの不足、担当者の不在、保守契約の終了などによって対策そのものが難しくなる可能性にも言及しています。
PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)
Webサイトの現場では、ここに大きなジレンマがあります。
CMSやミドルウェアのアップデートが必要だとわかっていても、
- CMSを更新して既存ページに影響が出ないか
- プラグインが正常に動作するか
- 問い合わせフォームや検索などに影響しないか
- 外部サービス連携は問題ないか
- 本番環境へいつ反映するか
などを確認しなければなりません。
緊急性が高ければ高いほど、「早くアップデートしたい」というセキュリティ上の要求と、「Webサイトを止めたくない、壊したくない」という事業上の要求がぶつかります。
だからこそ、考えておきたいことがあります。
そもそも、Webサイトを閲覧するすべてのユーザーからCMSへ到達できる必要はあるのでしょうか。
CMSを守るだけでなく、「CMSを外から遠ざける」
CMSを利用した一般的なWebサイトでは、訪問者が閲覧する公開サイトと、担当者が利用するCMSが、同じ公開環境上で稼働していることがあります。
この構成では、CMSやプラグインなどに脆弱性が存在した場合、インターネットから該当システムへ到達される可能性があります。
そこで私たちが推奨する考え方をサービス化したのが、「CMSアイソレーション」です。
CMSアイソレーションでは、CMSの管理環境とユーザーが閲覧する公開環境を分離します。
CMS管理環境は許可されたネットワークやIPアドレスなどから利用できる領域に配置し、一般ユーザー向けの公開環境では、CMSから生成された静的コンテンツを中心に配信します。さらにIP制限、WAF、監視、バックアップなどを組み合わせ、多層的にリスクを低減する考え方です。
「脆弱性をなくす」ではなく「影響を受けにくい構造をつくる」
ここで重要なのは、CMSアイソレーションを導入すれば、脆弱性対応が不要になるわけではないということです。
OSも、CMSも、ミドルウェアも、これから先、新しい脆弱性が見つかる可能性があります。
したがって、アップデートや監視を継続する必要があります。
変わるのは、脆弱性が存在するシステムと、一般のインターネット利用者との距離です。
一般ユーザーがアクセスする公開環境からCMSやデータベース、管理画面などを分離しておけば、攻撃者が直接狙える対象、つまり「攻撃面（アタックサーフェス）」を減らせます。
CMSアイソレーションでは、CMSから生成したHTML、CSS、JavaScript、画像などの静的コンテンツを、CMSとは分離した配信先に配置し、CDNを通じて配信します。公開ページへのアクセスをCMSサーバーに転送せず、ページの配信時にCMSやPHPの処理を実行しない構成を採用しています。
つまり目指すべきなのは、「絶対に脆弱性が存在しないWebサイト」ではなく、「脆弱性が発見されても事業への影響を抑えやすいWebサイト」なのです。
Webサイト停止は、セキュリティだけの問題ではない
ここはマーケティング担当者にもぜひ考えていただきたい部分です。
企業Webサイトは、会社案内を掲載するだけの場所ではなくなっています。
広告や検索、SNS、メールなどから集めたユーザーを受け入れ、商品やサービスを理解してもらい、問い合わせ、資料請求、採用応募など、次のアクションにつなげる場所です。
つまり、Webサイトはデジタルマーケティングのハブでもあります。
どれだけ広告費を投入していても、キャンペーンを企画していても、検索順位を高めていても、Webサイトが停止すればその導線は途切れてしまいます。
さらに、セキュリティ上の問題によるWebサイト停止は、単純なアクセス機会の損失だけでは済まない可能性があります。
緊急メンテナンス、社内外への説明、問い合わせ対応、影響範囲の調査、復旧作業など、本来マーケティング活動やサイト改善に使われるはずだったリソースまで奪われるからです。
だからWebサイトのセキュリティは、情報システム部門だけが考える技術課題ではありません。
「デジタルマーケティングを止めない」ための事業継続の課題として考える必要があります。
セキュリティ対策はスイスチーズモデルで考えてください
各対策には穴がありえることをスイスチーズのスライスに例えて、その穴がたまたま一列に並んだときにしか突破されないように多層的な安全対策を行うことをスイスチーズモデルといいます。
「CMSを分離すればWAFはいらないのか」「アップデートをしなくてもよいのか」というと、そうではありません。
重要なのは、一つの対策だけに依存しないことです。
CMSアイソレーションでは、管理環境と公開環境の分離に加え、IP制限、WAF、CMS・プラグイン・ミドルウェアの保守、内部監視、外部監視、バックアップなどを組み合わせることを想定しています。
つまり、
- 侵入させない
- 攻撃できる場所を減らす
- 異常を検知し判断し止める
- 問題が起きても復旧できる
という複数のレイヤーで考えます。
新しい脆弱性の発見を止めることはできません。
だからこそ、「次に何が起きるか」を完璧に予測するのではなく、何かが起きても影響を局所化し、Webサイトをできるだけ継続できる構造をつくっておくことに意味があります。
すべてを静的化すればいい、という話でもありません
一方で、CMSアイソレーションは、単純にCMSからHTMLを書き出せば完成するものでもありません。
実際の企業Webサイトには、
- 問い合わせフォーム
- サイト内検索
- 会員機能
- MAなどとの連携
- 外部API
- パーソナライズ
など、多くの動的機能があります。
そのため、まず「何を静的コンテンツとして分離できるのか」「何を別システムにする必要があるのか」を整理する必要があります。
CMSアイソレーションでも、フォーム、会員機能、サイト内検索などは、サイトの要件に応じて外部SaaSや別システムとして設計しなおす場合があります。アクセス解析や外部サービス連携なども含め、公開サイトの機能と運用への影響を考慮した配信システムを設計します。
つまりポイントは、製品を一つ導入することではありません。
現在のWebサイトがどのような仕組みで動いていて、どこをインターネットへ公開する必要があり、どこは公開する必要がないのかを整理すること。
そこからがスタートです。
次の「脆弱性」が来る前に、Webサイトの構造を見直してみませんか？
PHP2ShellやHTTP2Shellのように、これまで普通に利用してきたソフトウェアやライブラリから、突然、重大な脆弱性が明らかになる可能性は今後もあります。
そのたびに、
- うちのサイトは対象なのか
- 誰に確認すればよいのか
- アップデートして大丈夫なのか
- サイトを止めなければならないのか
という確認から始める状態では、Web担当者にも情報システム担当者にも大きな負担がかかります。
まず、一度こんなことを確認してみてください。
- CMSの管理画面はインターネットから到達できる状態になっていないか
- 公開サイトとCMSは同一環境で動作していないか
- CMSやPHPなどのバージョン、サポート期限を把握しているか
- WAFや監視の対象と責任範囲が決まっているか
- 障害時に誰へ連絡すればよいか決まっているか
- CMSが停止した場合でも公開サイトを提供し続けられるか
- バックアップから実際に復旧する手順が整理されているか
- フォームや検索など、CMSから切り離せない機能を把握しているか
一つでも「わからない」があれば、次の脆弱性が発見されてからではなく、今こそWebサイトの構成を見直すタイミングかもしれません。
まとめ
脆弱性へのアップデート対応は、これからもいつくるかわからない時代です。
しかし、脆弱性が明らかになるたびに緊急対応を繰り返すだけでは、Webサイトの運用負荷はなかなか減りません。
そこで重要になるのが、「脆弱性をどう塞ぐか」だけでなく、 「脆弱性があったとしても攻撃されにくく、事業を止めにくい構造をどうつくるか」という視点です。
CMSをインターネットへ直接さらさず、公開環境と管理環境を分離するCMSアイソレーションは、そのための一つのアプローチです。
私たちミツエーリンクスでは、CMS管理環境と公開環境の分離だけでなく、AWS、WAF、監視、バックアップ、CMSの保守、コンテンツ移行、公開後の運用まで含めて、Webサイトとインフラ双方の観点から構成をご提案しています。CMSアイソレーションでは、AWSのVPC、EC2、S3、ALB、CloudFront、WAFなどを組み合わせた構成などで対応しています。現状調査から構築・移行・運用までの目安は3カ月～としていますがすべて実施する場合の目安で、緊急度の高いところから随時実施することも可能です。
- CMSアイソレーションが自社サイトに適しているのかわからない
- まず現在の構成のどこにリスクがあるのか知りたい
- 次回のリニューアルに合わせてセキュリティ設計も見直したい
そのような段階からでも構いません。
次の脆弱性が発見されてから慌てるのではなく、まずは現在のWebサイトの構成を一緒に整理するところから始めてみませんか。
CMSを「守り続ける」だけでなく、「外部から遠ざける」という選択肢を。