レンタルサーバ・VPS・AWS の選び方：脆弱性の視点では「サイトの中身ごと」に考える

「うちのコーポレートサイトは、レンタルサーバのままで大丈夫でしょうか」というご相談をいただくことがあります。

サーバ選びの記事は、料金や表示の速さで比べるものが多いのですが、ここでは脆弱性が見つかったとき、どれだけの被害になりうるかという視点で考えます。この視点で見ると、答えはサーバの種類よりも、そのサーバに何を載せているかで決まります。

1. まず、サイトの中身を4つの問いで確かめる

1. 何が動いているか：HTML だけか、WordPress（PHP）などの CMS か、独自に作ったプログラムか。動いているプログラムが多いほど、脆弱性が見つかる可能性も増えます。
2. 何を持っているか：何も保存していないか、問い合わせ内容や応募者の情報、会員情報を保存しているか。
3. 侵入されたら何が起きるか：ページの改ざん、別のサイトへの誘導やフィッシングの踏み台、会社の信用の低下、そして個人情報の漏えい。漏えいのおそれがあれば、個人情報保護委員会への報告や本人への通知が必要になることもあります。
4. 誰が更新と監視をするか：サーバの事業者か、自社か、制作会社か。実は「誰も決まっていない」ことも少なくありません。

同じコーポレートサイトでも、HTML だけで何も保存していないサイトと、WordPress で応募者の履歴書を受け付けているサイトとでは、許容できるリスクがまったく違います。

2. レンタルサーバ・VPS・AWS の性格

レンタルサーバ：保守は任せられるが、構成は分けられない

OS や Web サーバの更新は事業者が行います。WAF が標準で付いていることも多く、サーバの知識がなくても一定の水準が保たれるのは大きな利点です。

一方で、実際に比較・検討してみると、次のような限界がありました。

• 構成を分けられない：公開ページ、管理画面、データベース、アップロードされたファイルが、同じ契約の中に並びます。1か所に穴があると、ほかの部分にも届きやすくなります。
• 1つの契約に複数のサイトを載せると、まとめて被害を受けやすい：同じアカウントの権限で動いているため、放置された古い WordPress から、同じ契約のほかのサイトへ広がることがあります。
• 入口の守り方を選べないことがある：サービスによっては、SSH のパスワード認証を無効にできない、接続元の IP アドレスを限定できない、といった制約があります。コントロールパネル・FTP・SSH が同じパスワードで、コントロールパネルに2要素認証をかけても、FTP や SSH から回り込まれる構造のものもあります。この場合、そのパスワード1本の強さが全体の守りを決めます。
• バックアップの対象を確かめる必要がある：事業者のバックアップが WordPress のデータベースしか対象にしておらず、独自のプログラムのデータが含まれないことがあります。また、決まった世代数で上書きされる方式では、「◯か月後に削除する」という社内の保管ルールと合わせにくくなります。

VPS：何でもできるが、すべてが自分の責任になる

サーバを1台まるごと使えるので、構成を自由に分けられます。SSH は鍵による認証だけにする、管理画面を VPN の内側に置いてインターネットから見えなくする、サーバから外への通信を必要な宛先だけに絞る、ファイルの改ざんを検知する、ログを別の場所に送って消されないようにする、といった対策がすべて可能です。

その代わり、OS の更新から監視まで、すべてが利用者の責任になります。VPS の本当の費用は、月額の料金よりも年間の保守の手間です。保守する人がいない VPS は、レンタルサーバより危険です。

当社では、VPS を使う場合は Cloudflare などで入口を前に出し、サーバを直接見せない構成を基本にしています。

AWS などのクラウド：侵入された後のことまで設計できる

データベースを外から見えない場所に置く、サーバに与える権限を最小限にする、といった構成が最も柔軟にとれます。たとえば次のような設計ができます。

• 普段はサーバからインターネットへの出口を閉じておき、保守のときだけ開ける。
• サーバにはログを書き込む権限だけを与え、乗っ取られてもログを消せないようにする。
• 期間限定のサービスであれば、終了時に環境ごと削除し、データが残っていないことを確かめやすくする。

一方で、設定の自由度が高い分、設定の誤りがそのまま事故につながります。費用も、アクセスが少なくても一定の固定費がかかります。設計と運用の知識がある人がいることが前提です。

3. サイト全体ではなく、中身ごとに置き場所を分ける

ここまでを踏まえると、「サイト全体をどのサーバに置くか」を1つに決める必要はありません。個人情報を持たない部分はシンプルな環境に、持つ部分だけを守りを固められる環境にと、中身ごとに分けて考えるのが現実的です。

4. 例：応募フォームを持つコーポレートサイト

たとえば、WordPress のコーポレートサイトの中に、履歴書などのファイルを受け付ける独自の応募フォームがある場合を考えます。よくあるのは、WordPress と応募フォームが同じサーバ・同じデータベースに同居している構成です。この場合、WordPress のプラグイン1つの脆弱性から、応募者の個人情報まで届いてしまうおそれがあります。

中身ごとに分けると、次のような構成になります。

• WordPress（会社案内や採用情報のページ）：レンタルサーバ、または静的化。
• 応募フォームと応募データ：別の契約の VPS やクラウドに切り出す。データベースも分ける。
• 応募データを見る管理画面：インターネットからは見えない場所に置く（VPN や接続元の制限）。
• 添付ファイル：公開フォルダの外に置き、ログインした担当者だけが取り出せるようにする。

どうしても同じサーバに置く場合でも、WordPress と応募フォームでデータベースのユーザーを分け、互いのデータを読めないようにすることが最低限の対策になります。

なお、Cloudflare のようなサービスは、サイトの配信を守るうえでは有効です。ただ、通信の経路に入るため、個人情報を受け付ける部分については、扱う事業者を増やさないという考え方で、あえて経路に入れない判断をすることもあります。

5. どこに置いても共通して大切なこと

• 持たないことが一番の対策：メールで受け取れば十分な情報は、サーバに保存しない。持っていないものは漏れません。
• 「削除」の範囲を確かめる：データベースから消しても、バックアップやスナップショット、ログに残っていれば、漏えいの対象に含まれます。
• 長く止めていたサイトは作り直す：休止中に裏口を仕込まれている可能性があります。再開するときは、古い環境を更新するよりも、新しい環境を作って移すほうが確実です。
• プログラム自体の脆弱性は、サーバの構成では塞ぎきれない：構成は被害を小さくするためのものです。プログラムの修正と更新は別に必要です。
• 担当者を決める：更新、バックアップの確認、ログの確認。担当者が決まっていない作業は、誰もやらない作業です。

まとめ

レンタルサーバが危ないわけではありません。VPS や AWS にすれば安全というわけでもありません。危ないのは、載せている中身と、サーバの種類や運用の体制が合っていない状態です。

まずは自分のサイトの中身を4つの問いで確かめ、個人情報を持つ部分があれば、そこだけでも切り分けられないかを考えてみてください。

• WordPress・PHP サイトのセキュリティ対策（サーバ構成の見直し） →
• WordPress の静的化 →