📑 INDEX

はじめに

前回の記事では、Cloudflare導入後に確認しておきたい初期設定として、SSL/TLS、キャッシュ、WAF、ログイン画面保護の基本を整理しました。

blogs.networld.co.jp

これらの設定だけでも一定の保護は可能ですが、管理画面や特定URLにアクセスできる利用者そのものを絞りたい場合は、Cloudflare Access を使った追加認証も有効です。

本記事では、Cloudflare Access を利用して、管理画面や限定URLに追加認証をかける基本的な手順を整理します。

前提条件

本記事は、以下のような前提で Cloudflare Access を設定するケースを想定しています。

Cloudflare の Full setup（ネームサーバー切り替え）が完了している
対象サイトが Cloudflare 経由で公開されている
Cloudflare の Zero Trust / Access を利用する
本記事では、まずメールOTPによる追加認証を例に扱う

既存のIDプロバイダー（Entra ID、Okta、Google Workspace など）との連携は、必要に応じて別途発展編として整理します。

本記事では、以下の順に設定を進めます。

Zero Trust （Cloudflare Access）の有効化
アクセスを許可するユーザー条件（ルールグループ）の作成
ポリシーの作成（Allow / Block）
保護対象アプリケーションの登録
動作確認

1. Cloudflare Accessでできること

Cloudflare Access は、特定のURLやアプリケーションに対して、追加の認証を要求できる機能です。

WAFやIP制限が「どのリクエストを通すか」を入口で制御するのに対し、Accessは「そのURLにアクセスできる利用者を絞る」ことに向いています。

Cloudflare Access でセルフホストアプリケーションを作成し、公開URLに対してアクセス制御を適用できます。

1-1. WAFやログイン画面保護との違い

WAFやログイン画面保護は、不審なアクセスや不要なボットアクセスを減らすのに有効です。

一方で、Cloudflare Access は、そもそも認証済みユーザー以外を対象URLの前段で止めることができます。

そのため、管理画面、ステータスページ、検証用URLなど、限られた利用者だけに見せたいパスの保護に向いています。

1-2. まずはメールOTPで始める

Cloudflare Access は既存のIDプロバイダー連携にも対応していますが、最初の導入ではメールOTPを使うと動作確認しやすくなります。

メールOTP は、外部IdPがない場合でも利用しやすい認証方法です。

2. Zero Trustを有効化する

Cloudflare Access を利用するには、まず Zero Trust の画面へ入り、対象のアカウントで利用できる状態にします。

Cloudflareダッシュボードから「Zero Trust」を開くと、チーム名や初期セットアップを進める画面が表示されます。

2-1. チーム名を入力する

初回は、組織名やチーム名などの入力を求められます。

ここで設定した名称は、Zero Trust 側の管理単位やURLに使われるため、後から見て分かりやすい名前にしておくと運用しやすくなります。

2-2. 料金プランを選択する

次に、料金プランの選択画面に移ります。本記事ではFreeで進めます。Freeプランでも50人までの接続が可能なため、個人利用や検証用途であれば問題ありません。

支払い画面で、料金が0ドルであることを確認して購入します。

2-3. 初期セットアップはスキップする

プラン選択が完了すると初期セットアップウィザードの画面に移ります。ここでは、画面下部の「今はスキップ」で問題ありません。設定については後の項目で説明していきます。

補足：まずは最低限の初期セットアップでよい

この段階では、すべての機能を細かく設定する必要はありません。

今回は Access の利用が目的なので、まずは Zero Trust に入れる状態にするところまで進めれば十分です。

3. Accessポリシーを作成する

次に、Access で「誰のアクセスを許可するか」を定義します。

Cloudflare Access では、ポリシーの条件としてメールアドレスやグループなどを指定できます。

3-1. まずはメールアドレス単位で条件を作る

最初の例としては、自分のメールアドレスだけを許可する形が分かりやすいです。

Zero Trust ダッシュボードから、Access コントロール → ポリシー → ルールグループ から、「グループを追加する」をクリックします。

以下のように設定します。

ルールグループ名：任意の名前
セレクター：Emails を選択
値：ご自身のメールアドレスを入力

ここで入力したメールアドレス宛に、OTPのメールが届きます。

補足：最初は絞り込みすぎない

最初から複数の条件を組み合わせすぎると、動作確認時に原因を切り分けにくくなります。

まずは1つのメールアドレス、もしくは最小限の対象で許可条件を作ると確認しやすくなります。

3-2. Allow ポリシーを作る

ユーザー条件を用意したら、次にポリシーを作成します。ポリシーでは、どの条件に一致したリクエストを許可し、どれを拒否するかを決めます。

Zero Trust ダッシュボードから、Access コントロール → ポリシー → 再利用可能なポリシー から、「ポリシーを追加する」をクリックします。

まずは、許可したいメールアドレスや条件に対して Allow ポリシーを作成します。本記事では、先ほどルールグループに含めた、対象のメールアドレスで認証したユーザーだけが先へ進める構成になります。

以下のように設定します。

ポリシー名：任意の名前
アクション：Allow
セレクター：Rule group
値：先ほど設定したルールグループ名を選択

アクションはデフォルトでAllowなので、特に触らなくても問題ありません。

他項目は特に変更せず、画面下部の「保存」をクリックします。

3-3. 必要に応じて明示的な Block も入れる（任意）

Access ではデフォルトですべてのアクセスが拒否されるため、Allow ポリシーがなければ誰もアクセスできません。

そのため、明示的な Block ポリシーは必須ではありませんが、ポリシーの意図を分かりやすくしたい場合に追加します。

developers.cloudflare.com

Add Access policies to control who can connect to your application. All Access applications are deny by default -- a user must match an Allow policy before they are granted access.

ポリシー名：任意の名前
アクション：Block
セレクター：Everyone
値：Everyoneで固定

先ほどと違い、アクションはBlockに変更しておきます。

4. 保護対象のアプリケーションを追加する

次に、どのURLやパスを保護するのかを Access のアプリケーションとして登録します。

管理画面や限定公開したいURLを保護する場合は、セルフホスト を利用します。

Access コントロール → アプリケーション → から、「アプリケーションを追加する」をクリックします。

4-1. セルフホストを選ぶ

一番左の「セルフホスト」を選択します。

これにより、特定のURLにだけ Access を適用できます。

4-2. 保護対象URLを設定する

セルフホストを選択すると、以下のような画面に移ります。まず、アプリケーション名は任意の名前を入力しておきます。

次に、「パブリックホスト名を追加」をクリックします。

すると、以下のように設定入力画面が追加されるので、以下のように設定します。

入力方法：デフォルト
サブドメイン：www等。ルートドメインの場合は空欄
ドメイン：プルダウンからご自身のドメインを選択
パス：保護対象のパスを入力（wp-admin/ 等）

例えば保護対象のパスが2つ、ルートドメインとサブドメイン（www等）を全て保護したい場合、合計4つのパブリックホスト名を登録する必要があります。

最初からサイト全体に認証をかけるのではなく、まずは管理画面や検証用パスなど、影響範囲の限定しやすいURLから試すと安全です。

4-3. アプリケーションにポリシーを設定する

次に、このアプリケーションに先ほど作成したポリシーを登録します。

「既存のポリシーを選択」をクリックします。

ここで先ほど作成したポリシーにチェックを入れ、「確認」をクリックします。

その後は他設定は変更せず、「次へ」→「次へ」→「保存」とクリックして、作成したアプリケーションを保存します。

補足：ポリシー順序に注意する

もしこの時、↓の画像のようにBlockポリシーが最上段にあると、誰もアクセスできなくなってしまいますので、ドラッグしてポリシーの順序を変更します。

Access のポリシーは順序も含めて評価されるため、許可したい条件と拒否したい条件の並びは意識しておくと安全です。

補足：
厳密には、Access のポリシーはアクションタイプごとに評価順が決まっています（Service Auth / Bypass が最優先、次に Allow / Block の順序）。Allow と Block の間では UI の並び順が評価順に影響するため、Allow を Block より上に配置しておく必要があります。

developers.cloudflare.com