サーバの堅牢化で Cloudflare を使う良い点と気になる点
公開 有限会社カルフ 栗山
サーバの堅牢化をご提案するとき、当社では Cloudflare をサーバの前に置く構成を基本にしています。ただ、正直に書くと、この提案がそのまま採用されることは多くありません。
見送りになる理由は、技術的な欠点よりも、社内の規程や管理の分担、なんとなくの印象であることがほとんどです。この記事では、Cloudflare を使う良い点と気になる点を整理し、どう判断すればよいかを考えます。
1. Cloudflare の使い方は1つではない
「Cloudflare を使う」と言っても、大きく2つの使い方があります。
- サーバの前に置く：今あるサーバ（VPS やレンタルサーバ）はそのままにして、アクセスをいったん Cloudflare で受け、そこからサーバへ中継します。堅牢化でご提案しているのはこちらです。
- 配信そのものを任せる：HTML などのファイルを Cloudflare に置き、サーバを持たずにサイトを公開します。静的なサイトであれば、これだけで運用できます。
どちらの場合も、ドメインの DNS を Cloudflare で管理するのが基本の形です。
2. 良い点
- サーバを直接見せずに済む：外から見えるのは Cloudflare の IP アドレスだけになります。サーバ側で Cloudflare からの通信だけを受け付けるようにすれば、サーバを直接狙う攻撃の多くを入口で止められます。
- DDoS 攻撃への対策と WAF：大量のアクセスでサイトを止める攻撃は、サーバ1台では防ぎきれません。Cloudflare の大きな設備で受け止められます。よく知られた攻撃のパターンを止める WAF も使えます。
- 脆弱性が公表されたときの時間稼ぎ：大きな脆弱性が公表されると、それを狙う通信を止めるルールが比較的早く用意されることがあります。プログラムの修正の代わりにはなりませんが、更新するまでの間の守りになります。
- 証明書とキャッシュ：HTTPS の証明書の更新や、画像などのキャッシュを任せられます。サーバの負荷も下がります。
- 無料のプランでもかなり使える：小さなサイトであれば、無料の範囲で上の多くを使えます。
3. 気になる点・議論になる点
通信の中身が Cloudflare を通る
HTTPS の通信は、Cloudflare の中で一度復号されてから、サーバへ中継されます。WAF やキャッシュはこの仕組みがあって初めて働くので、避けられません。つまり、お問い合わせの内容や応募者の情報も、Cloudflare を通ります。
個人情報を扱う部分について、取り扱う事業者を増やしたくない、という考え方は自然なものです。
海外の事業者を経由することが、社内の規程に合わない
「データは国内に置く」「AWS でも東京リージョンに限る」といった規程があり、Cloudflare は採用できない、という判断になることがあります。同じ理由で、AWS の CloudFront も使えないとされることがあります。
ここで整理しておきたいのは、CDN はもともと、世界中の拠点で通信を処理する仕組みだということです。国内からのアクセスは国内の拠点で処理されることが多いものの、それが約束されているわけではありません。規程が「保存場所」を決めたものなのか、「通信が通る場所」まで決めたものなのかで、答えが変わります。
上位の契約では、通信を処理する地域を限定する仕組みも用意されています。規程に合わせる必要がある場合は、そうした契約を検討するか、CDN を使わない構成にするかの判断になります。
DNS を移せない、移したくない
基本の形では、ドメインの DNS の管理を Cloudflare に移します。DNS はメールや社内のほかのシステムにも関わるため、「情報システムの部門が管理していて動かせない」「管理の場所が分かれるのが嫌だ」という声はもっともです。
有料のプランには、DNS を移さずに、一部のホスト名だけを Cloudflare に通す設定もあります。また、サイト用に別のドメインを用意する方法もあります。
なんとなく印象が良くない
漫画村などの海賊版サイトが Cloudflare を使っていたことが報道され、出版社との裁判にもなりました。そのため、良くない印象を持っている方もいます。
これは、Cloudflare が悪意のあるサイトにも使われてきた、という問題です。Cloudflare を使う側のサイトが危なくなる、という話とは別です。ただ、取引先や社内にそう受け取られるかどうかは、技術とは別に考える必要があります。
障害に巻き込まれる
Cloudflare 自体に障害が起きると、自社のサーバが正常でもサイトが見られなくなります。過去には、世界中の多くのサイトに影響する障害も起きています。1つの事業者に入口を預けることの裏返しです。
設定を誤ると、守っているつもりで守れていない
- サーバの IP アドレスが知られていれば、Cloudflare を通らずにアクセスできる：以前の DNS の記録や、同じサーバから送るメールなどから分かることがあります。サーバ側で、Cloudflare 以外からの通信を受け付けない設定が必要です。
- Cloudflare とサーバの間が暗号化されない設定がある：利用者からは HTTPS に見えていても、その先は暗号化されていない、という状態になりえます。サーバ側にも証明書を置き、証明書を確かめる設定にします。
- キャッシュしてはいけないページまでキャッシュする：表示を速くしようと「すべてをキャッシュする」設定にすると、ログイン中の画面や、入力した個人情報が表示される確認画面までキャッシュされ、ほかの人に表示されてしまうことがあります。Cloudflare の不具合ではなく設定の誤りですが、起きると個人情報の漏えいになります。キャッシュするページを決め、管理画面やフォームの周りは外しておきます。
- ログに、本当のアクセス元が残らない：そのままでは、サーバのログに Cloudflare の IP アドレスが並びます。調査のときに困らないよう、本当のアクセス元を記録する設定を入れておきます。
4. 判断の目安
レンタルサーバ・VPS・AWS の選び方と同じく、ここでもサイト全体で1つに決める必要はありません。
| 中身 | Cloudflare の使い方 |
|---|---|
| 会社案内などの公開ページ | 前に置く、または配信を任せる。良い点が大きく、気になる点は小さい |
| WordPress の管理画面 | 前に置き、さらに接続元を限定する。理想は外から見えない場所に置くこと |
| お問い合わせ・応募など個人情報を受け付ける部分 | 規程と相談して決める。経路に入れない場合は、別のホスト名にして、その部分だけ守りを固める |
Cloudflare を使えない場合でも、目的は同じです。サーバを直接見せない、管理画面を隠す、本当のアクセス元を記録する。手段が変わるだけです。
5. 実例：知人のバンドのサイト
知人のバンドのサイトは、Cloudflare に配信を任せる形で運用しています。
- サイトは静的な HTML で、GitHub に変更を反映すると自動で公開されます。
- お問い合わせフォームは、Cloudflare の上で動く小さなプログラムで受け付け、メールで送っています。内容はサーバに保存していません。
- スパム対策には、画像を選ばせるパズルを使わない Cloudflare の仕組み（Turnstile）を使っています。
- ドメインの DNS と、メールアドレスの転送も Cloudflare で管理しています。
OS の更新も、サーバの監視もありません。守るべきものが少ないサイトでは、この形がいちばん手間がかからず、安全に近いと感じています。一方で、企業のサイトでは DNS やメールを動かせないことが多く、そのまま当てはめられるわけではありません。
まとめ
Cloudflare は、小さなサーバだけでは難しい守りを、手頃に手に入れられる道具です。一方で、通信の中身を預けること、DNS の管理を移すこと、1つの事業者に入口を任せることを受け入れる必要があります。
見送りになる理由の多くは、もっともなものです。大切なのは、使うか使わないかを二択で決めることではありません。どの部分に使い、どの部分には使わないかを、サイトの中身と社内の規程に合わせて決めることです。