サイバー攻撃・情報漏洩に備える。サイトの安全性と速さ、運用コストを一緒に見直す
CMS・ECの脆弱性やSQLインジェクションへの備えと、侵入されなくても起こるサイトの遅延。自社開発、WAF・CDN・負荷分散、負荷の高いページの改善から、サーバーコストを30％削減した当社の運用経験を紹介します。
実践ノート ｜ CMS・ECのセキュリティと運用改善
サイトが急に重くなる。注文画面がなかなか開かない。売上が増えたわけでもないのに、サーバーへのアクセスと費用が増えている。原因を調べると、お客様ではなく、システムの弱点を探すアクセスが押し寄せていることがあります。
サイバー攻撃への備えは、顧客情報を守ることに加えて、お客様が快適に使える状態を保ち、無用な運用コストを抑えることにもつながります。今回は、たっきゅんがCMS・ECを開発し、サーバーを運用する中で取り組んできた対策を紹介します。
CMSやECの「更新されていない弱点」が入口になる
WEBサイトの更新に使うWordPressやDrupal、ECサイトを構築するEC-CUBEやMagento Open Source。便利なオープンソースのソフトウェアですが、本体や追加機能に脆弱性が見つかることがあります。修正が公開されても、利用中の環境に適用しなければ弱点は残ります。
各製品の公式情報でも、更新やセキュリティ対策が案内されています。例えば、WordPressのセキュリティ対策、Drupalのセキュリティ情報、EC-CUBEの脆弱性情報、AdobeによるMagento Open Sourceの更新情報です。
本体だけを更新しても、プラグインやテーマ、周辺のライブラリが古いままでは対策が十分とは限りません。使っているものを把握し、不要な機能を減らし、更新と動作確認を続ける。その担当と手順まで決まっているかが大切です。
SQLインジェクションは、入力の扱いから情報漏洩につながる
代表的な攻撃の一つが、SQLインジェクションです。検索欄やフォームなどから受け取った値を、データベースへの命令に不適切に組み込む実装があると、攻撃者に意図しない命令を実行される可能性があります。顧客情報の読み出し、データの改ざん・削除、不正ログインなどにつながる問題です。
根本的な対策は、入力値を命令として扱わせない実装です。プレースホルダと値のバインドを使う方法などで、命令とデータを分けます。データベースの権限を必要最小限にし、詳細なエラーを外部へ表示しないことも対策になります。IPA「SQLインジェクション」の解説に、原因と対策がまとめられています。
WAFで不審な通信を止めることと、アプリケーション側の脆弱性を直すことは、両方必要です。また、情報漏洩の原因はSQLインジェクションだけではありません。ログインや権限、情報の公開設定も、合わせて確認します。
2016年から、自社開発のCMS・ECを育ててきた
たっきゅんでは、2016年から自社開発のCMS・ECを推奨し、事業の中で使用してきました。サイトの更新から受注・決済・顧客とのやり取りまで、必要な機能を自分たちで把握し、運用に合わせて改善を続けるためです。
自社開発を選ぶ意味は、設計から運用までをつないで考えられることにあります。公開された汎用製品の弱点を狙う攻撃が、そのまま自社の仕組みに当てはまるとは限りません。ただし、自社開発であれば安全、ということではありません。入力の扱い、認証・権限、利用するライブラリの更新、設定やログの確認は、同じように必要です。
侵入されなくても、お客様への影響は起こりうる
当社が管理するサーバーにも、WordPressなどのCMSの弱点を探すアクセスが届いています。実際にはそのCMSを使っていないサイトにも、関連する機能やファイルを探す通信が来るのです。
AIが普及した近年、当社の運用現場でも、こうした攻撃性のあるアクセスがより激しくなっていると感じています。個々の攻撃にAIが使われたかはログだけでは判断できませんが、継続して監視し、対策を見直す必要性を実感しています。
当社の管理環境では、これらの攻撃による直接的な被害は確認していません。それでも、大量のリクエストを処理すれば、サーバーやデータベースの資源を使います。その結果、本来のお客様が見るページの表示や操作に影響が出ることがあります。
侵入を防ぐことと、正規のお客様が使える状態を守ること。
私たちは、その両方を運用の課題として扱っています。
監視・遮断・負荷分散・自動増強を組み合わせる
当社では、サーバーの監視を行い、WAFやロードバランサー、CDNを使いながら、環境に合わせて対策を組み合わせています。それぞれの役割は異なります。
監視：何が起きているかを知る。
アクセスの傾向、エラー、応答時間、サーバーの負荷を見て、不審な通信と負荷の高い処理を調べます。WAF：不審なリクエストを見分ける。
攻撃の特徴やアクセス頻度に応じたルールで、通信を検査・制御します。設定後は、本来のお客様まで遮断していないかも確認します。CDN：配信できるものを手前で届ける。
画像など、キャッシュ可能なコンテンツを配信し、元のサーバーへのアクセスを減らします。会員情報や注文画面は、内容に合ったキャッシュ設定が必要です。ロードバランサー：負荷を分ける。
複数のサーバーへリクエストを振り分け、一台への集中を避けます。処理そのものが重い場合は、アプリケーション側も見直します。
各機能の基本的な役割は、AWSの公式資料でも確認できます：WAF、CDN（CloudFront）、ロードバランサー。
さらに、当社のサーバー運用では、負荷に合わせてサーバーを自動増強する仕組みを標準で搭載しています。アクセスが増えたときに、処理能力を補えるようにしています。
ここで気をつけたいのは、攻撃を受けるたびに増強するだけでは、費用も増えてしまうことです。不要な通信を抑える対策と、必要な処理能力を確保する対策を一緒に設計する。自動増強にも上限や費用の監視を設け、需要に見合った構成を考えます。
重いページを見直し、サーバーコストを30％削減
サーバーの容量を増やす前に、「どのページ・処理が負荷を生んでいるのか」を調べることにも価値があります。当社では、負荷の高いページを定期的に観測し、見直してきました。
その運用改善によって、サーバーコストを30％削減できた実例があります。すべての環境で同じ削減率になるわけではありませんが、処理の無駄を減らすことで、必要な性能をより少ない資源で支えられる可能性があります。
安全性、使いやすさ、費用を一つの運用として見る。余分な支出を抑えられれば、その資金を次の商品改善や集客に回せます。これは、当社が大切にしている「削減した経費を、次の投資に変える」考え方にもつながっています。
まず、自分のサイトで確認したい5つのこと
何を使っているか、書き出す。
CMS・ECの名前とバージョン、プラグイン、サーバー、管理担当を整理します。分からない項目は、保守会社に確認します。更新と復旧の手順を確認する。
誰が更新情報を確認し、誰が適用するのか。事前の動作確認やバックアップ、問題が出たときの復旧方法まで確認します。ログインと情報の公開範囲を見直す。
不要な管理者アカウント、過剰な権限、利用できる多要素認証、外部へ公開する必要のない情報や機能を確認します。アクセス数だけでなく、負荷の原因を見る。
不審な通信と正規のお客様のアクセスを分け、表示の遅いページやエラーを調べます。サーバー増強が必要なのか、処理の改善が先なのかを判断します。対策後の使いやすさと費用を確かめる。
遮断ルールで購入やログインが妨げられていないか、表示速度や費用はどう変わったか。設定を入れて終わりにせず、運用の中で確認します。
確認項目を整理する際には、IPA「安全なウェブサイトの作り方」も参考になります。ご自身で確認できるところから進めていただき、判断が難しい部分や改修が必要な部分を切り分けると、相談も具体的になります。
事業を止めないために、直す順番を決める
たっきゅんでは、システムをつくるだけでなく、稼働後の負荷や費用、お客様の使い方を見ながら改善してきました。気になる箇所を調べ、事業への影響を考えて、どこから手を入れるかを決める。その先の改修と継続運用までつなげられることが、当社の強みです。
「以前から使っているサイトが心配」「更新を任せているが、何を確認しているか分からない」「サイトが重く、サーバー費も増えている」。対象のURLと困っている状況から、確認範囲と優先順位を整理します。診断・改修・再確認の範囲と費用は、事前にすり合わせます。
公式情報の確認日：2026年10月11日。本文の運用経験と30％削減の実績は、当社での取り組みに基づきます。
