運用中の Webサーバーに Cloudflare を導入する方法

Cloudflare とは?

より良いインターネットの構築をミッションとして作られたもので、ネットワーク / クラウド / アプリケーションをより安全でパフォーマンスが高くあらゆる接続を実現する統合プラットフォームです。これは コネクティビティクラウド と呼ばれていて Cloudflare でも言及されています。そのコネクティビティクラウドを Cloudflare ではどう実現するかについて、「マルチクラウド環境およびハイブリッドクラウド環境を含む、あらゆるタイプのクラウドインフラストラクチャのための一元化されたコントロールプレーンとしての役割を果たす」と表現しています。大雑把にいうと、「クラウドで必要なセキュリティを一元管理できる」ということだと思います。

では、クラウドで必要なセキュリティとはなんでしょうか?
Cloudflare はプランによってできることが増えるのですが、今回はフリープランを元に話を進めていきますので、フリープランで使えるWebサイトのセキュリティに関わる機能をまとめてみました。

  • DNS
  • 従量制の DDoS 保護
  • CDN
  • ユニバーサルSSL証明書
  • 無料のマネージド ルールセット
  • ウェブ アプリケーション ファイアウォール (WAF)
  • 3 ページルール

※ これは 2024/4 時点です。詳しい内容はこちらです。

一番のメリットは CDN が使えてパフォーマンスの向上につながることだと思います。また CDN を導入することで、Webサーバーの負荷を軽減できたり、重複トラフィックの削減が見込めます。加えて SSL が利用できるので、SSL のないサーバーを利用しているサービスにもおすすめです。

Cloudflare の導入

導入にあってですが、ドメイン / DNS / Webサーバーが必要です。今回は、ドメインをお名前.com、DNS を Cloudflare、Webサーバーを Xserver でテストしています。Cloudflare にもドメインの発行とサーバーレスが使えるのですが、運用中の Webサーバーに導入というタイトルですので利用していません。サーバーレス機能の Workers は Webサーバーとしては使用しませんが、キャッシュ機能を実現するために後でご紹介します。また、Webアプリケーションは弊社開発の a-blog cms を使用してテストしています。本記事は a-blog cms とは関係ない内容ですが、a-blog cms を使用する場合に a-blog cms で設定が必要な箇所が出てきますので、掻い摘んで説明していきます。

add site から サイトの登録を行います。ステップは ドメイン設定 → プラン → DNS設定 → アクティベーション があり、基本的には add site の流れに沿っていただければ大丈夫です。一つだけ注意点があり、アクティベーションの際にDNS が割り当てられます。この DNS は取得したドメインに割り当ててください。お名前.com を使用している場合は、お名前.com 管理画面からドメインを選択し、ネームサーバー情報から DNS の変更ができます。また、アクティベーションには最大24時間かかる可能性があるのでご注意ください。


add site の画面

add site の画面

Cloudflare の導入だけであればこれで完了です。ただ、これだけだと Cloudflare を通っているだけで、オリジンサーバーに接続していてメリットがありません。SSL の設定がうまくいっておらず、表示すらできなくなっているかもしれません。次からのセクションで Cloudflare が動作するように設定していきます。

Cloudflare SSL/TLS

まずは SSL の設定が必要です。Cloudflare では無料で SSL を提供おり、SSL/TLS から設定できます。4つのモードがあり、以下の設定ができます。



Off (not secure) 暗号化(SSL)は適用されません 。
Flexible ブラウザと Cloudflare 間のトラフィックを暗号化します。
Full
サーバー上の自己署名証明書を使用して end-to-end で暗号化します。
Full (strict) エンドツーエンドで暗号化します。サーバー上に信頼できる CA または Cloudflare Origin CA 証明書が必要です。

ここで一つ注意点があり、http に アクセスすると https にリダイレクトするという処理が Webサーバーで行われている場合、end-to-end でSSL化する必要があります。end-to-end というのは、ブラウザと Cloudflare の間と、Cloudflare と Webサーバーの間を指します。もし、Cloudflare から Webサーバー へ http で通信しようとするとリダイレクトループが発生します。なので、cloudflare から Webサーバーの間は、SSLの設定をしておかなければなりません。既に Webサーバーで SSL化されている場合は、リダイレクト処理がされてある可能性があるのでご注意ください。

a-blog cms でも、htaccess(Apache Webサーバーの設定ファイル) で SSL アクセスについての記述がありますので、Cloudflare からアクセスするときは SSL でないとリダイレクトされてしまいです。


Cloudflare のSSL設定画面で使われているコネクト画像

SSL/TLS の設定画面

CDN のキャッシュ

次にキャッシュについてです。運用をしていると、全てをキャッシュするのではなく特定の場合にはキャッシュさせたくない状況も出てきます。例えば、CMS の運用でユーザーがログインし記事を更新する際にキャッシュが効いていると、更新したのに以前の情報が表示されてリアルタイムな情報でなくなってしまうので、キャッシュサーバーではなくオリジンサーバーにアクセスさせる必要がある場合です。

特定のURLパターンで判別する場合は Cache Rules を使って GUI で設定することができます。管理ページであれば URL が閲覧ページとは別のものになると思いますので Cache Rules が使えます。しかし、Cookie や Request Header のみで判断する場合、Cache Rules で設定しきれない時もあります​。そういった時は、Workers を利用することで解決できます。Workers は、Javascript または WebAssembly を使用して、リクエストに対してプログラム的な操作を行うことができます。よって、Cookieやヘッダー・リクエストの種類など、リクエストの詳細に基づいて複雑なキャッシュの決定や制御を行うことができるようになります。

Workers で Cookie を利用したキャッシュ動作の判別を行う

Workers & Pages > Create application > Create worker で Workers が作成できます。作成画面では、既に Hello, World! の文字列をレスポンスで返す処理がされているのですが、そのままデプロイしていただいて大丈夫です。そうすると以下の画面が表示されるので、Edit code からキャッシュの処理をしていきます。


Cloudflare Workers デプロイ後の画面

Cloudflare Workers デプロイ後の画面

Edit code の画面では、先ほど作成した Workers の処理(Hello, World! の文字列をレスポンスで返す)が書かれています。このコードを Cookie によってキャッシュの処理を切り替えるコードに置き換えます。

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const cookie = request.headers.get('Cookie')
  if (cookie && cookie.includes('acms-logging-in=administrator')) {
    // ログインしている場合はキャッシュをバイパス
    return fetch(request)
  } else {
    // ログインしていない場合はキャッシュされたコンテンツを利用
    return fetch(request, { cf: { cacheTtl: 7200 } })
  }
}

上記のコードは HTTPリクエストから処理を行うためのサンプルコードで、Cookie に personal-blog-logging-in=administrator があるかどうかによってキャッシュの利用を決めています。ご利用される場合は、ご自身の環境によって Cookie のキー、値を変えるようにしてください。

a-blog cms の場合、 v3.1 から/private/system.default.yamlextra_logged_in_cookie: on を追記すると、ログイン時に Cookie を残せるようになっています。さらに、extra_logged_in_cookie_name: "personal-blog-logging-in" のように追記をすると Cookie に登録するキーを変更することができます。この設定でできた Cookie を条件にして キャッシュにすると、ログイン時だけオリジンサーバーにアクセスするようになります。

Workers の作成ができたら、どの URL で利用するか指定しなければなりません。Websites > 利用しているサイト > Workers Routes > Add route から URL と Workers の指定ができます。

これで設定が完了しました。最後にきちんとキャッシュが動作しているかを確認してみます。

Cloudflare の動作を確認

ブラウザからレスポンスヘッダーを確認してみてください。そこに Cf-Cache-Status があると思います。以下の画像は Google Chrome の検証ネットワークタブから確認しています。このステータスがあると Cloudflare を通して実行されています。ここの値が HIT​ だとキャッシュが返ってきており、BYPA SS または DYNAMIC​ だとオリジンサーバーにアクセスされています。BYPASS は意図的(ヘッダーなどによるキャッシュルール)によるキャッシュ無視を示し、DYNAMIC は動的コンテンツを示します。


Cloudflare Zaraz に少し触れてみる

Cloudflare には Zaraz というサービスもあり、サードパーティツールが管理できます。今回試したのは Google Analytics 4(以下、GA4) の連携です。Zaraz を使用すると、Tag Manager や Analytics へブラウザからアクセスし計測するのではなく、Cloudflare が GA4 と連携してくれるのでパフォーマンスの向上に繋がります。また、クライアントのIPアドレスをGoogle側に送信しない設定ができるので、高いプライバシーを実現することができます。しかし、Webサイトにスクリプトを読み込まずに GA4 がデータを収集できる反面、 Webサイトの読み込みが必要な計測ができなくなる可能性があります。状況に合わせて利用していただければと思います。
詳しくは、CloudflareでGoogle Analyticsを使用する をご確認ください。


シェアする

Webにまつわる お困りごとをご相談ください。

こんなお手伝いができます

Webコンサルタントとしてのお手伝い/UIデザインのご相談/デジタルメディアの総合プロデュース/パンフレット・DMなどのDTP、ロゴ制作などのビジュアルデザイン