準備中のサイトを、URLでは共有したい。でも、検索や一般ユーザーにはまだ見せたくない。
Hugoで作っているサイトの公開前チェック、WordPressのリニューアル確認、ローカルで動かしている検証アプリの共有では、この状態がよくあります。自分だけで見るならlocalhostで足りますが、確認相手に見てもらうには外から開けるURLが必要です。
そこで使いやすいのが、Cloudflare Zero TrustのAccessです。
この記事では、preview.araisun.comのような確認用ホスト名にCloudflare Accessをかけ、許可したメールアドレスだけOne-time PINで通す流れを整理します。Cloudflare Tunnelは「previewを外へ出す道」として短く扱い、Tunnel自体の作り方はローカルで立ち上げたサーバーをSSL経由で外部URL公開できるCloudflare Tunnel
に任せます。
主役は、Cloudflare Accessのapplication、policy、One-time PIN、動作確認です。
先に結論
Cloudflare配下のドメインで準備中サイトを共有するなら、Basic認証だけでなくCloudflare Accessも候補になります。
Accessを使うと、originへリクエストを通す前にCloudflare側で認証できます。確認してほしい人のメールアドレスをAccess policyに入れ、その人だけOne-time PINでログインできるようにします。共有するのは共通パスワードではなくURLとメール認証の案内です。
今回の例では、preview.araisun.comを準備中サイトの確認用URLにします。Access applicationでこのホスト名を保護し、policyで許可メールを指定し、許可メール、未許可メール、別ブラウザ、スマホ回線、Access logsを順番に確認します。
Tunnelを使う場合でも、この記事ではTunnelの細かい手順には入りません。Tunnelは公開URLへつなぐ道、Accessはその手前で誰を通すかを決める関門、と分けて考えます。
Cloudflare Accessで守れるもの
Cloudflare Accessは、Cloudflareを通るリクエストの前段に認証レイヤーを置く機能です。self-hosted applicationとしてpreview.araisun.comのような公開ホスト名を登録し、Access policyに一致したユーザーだけをoriginへ通します。
準備中サイトで使うなら、守る対象は次のような入口です。
preview.araisun.comのホスト名全体/adminのような特定path- stagingやpreview用のサブドメイン
この記事では、準備中サイト全体を見せるか見せないかを制御したいので、preview.araisun.com全体を保護対象にします。/adminだけを守る設定にはしません。
Access applicationは、作っただけで全員を通すものではありません。基本は「許可条件に一致した人だけ通す」という考え方です。だから、applicationを作ったあとに、誰を通すかをAccess policyで決めるところが重要になります。
ただし、Accessが守れるのはCloudflare経由の入口です。VPSやnginxのorigin IP、別ホスト名、直アクセス用の経路が残っている場合は、そこから迂回される可能性があります。この点は後半で分けて確認します。
Basic認証とAccessの使い分け
Basic認証は、origin側でIDとパスワードを確認する方法です。nginxやApacheで設定でき、Cloudflareを使わない環境でも動きます。短期間の簡単な保護や、自分だけが見るページなら今でも選択肢になります。
一方で、確認相手へ見せる運用になると、Basic認証には少し面倒なところがあります。
- IDとパスワードを相手へ送る必要がある
- 複数人へ同じパスワードを共有しがち
- 確認が終わった人だけ外す運用がやりにくい
- ブラウザ標準の認証ダイアログが確認用として少し硬い
Cloudflare Accessなら、確認してほしい人のメールアドレスをpolicyに追加します。確認が終わったら、そのメールアドレスを外します。共通パスワードを配って後から変更するよりも、人単位の出し入れがしやすくなります。
もちろん、AccessがBasic認証を常に置き換えるわけではありません。Cloudflareを使っていない環境、サーバー内だけで完結したい環境、単純な一時保護ならBasic認証の方が早いこともあります。
すでにCloudflareをCDN / proxyとして使っていて、メールアドレス単位で少人数に見せたい。そういう準備中サイトでは、Accessの方が自然に扱える場面があります。
Tunnelは道、Accessは認証の関門
Cloudflare TunnelとCloudflare Accessは、役割を分けて考えると混乱しにくくなります。
Cloudflare Tunnelは、ローカルサーバーやprivateなoriginをCloudflareへつなぐ道です。たとえばローカルでHugo previewを動かしているなら、Tunnel側では次のような対応を作ります。
preview.araisun.com -> http://localhost:1313
この設定を作ると、preview.araisun.comからローカルのHugo previewへ届く道ができます。Tunnelの作成、public hostname、DNS、cloudflaredの常駐化などはCloudflare Tunnelの記事
で扱っているので、ここでは広げません。
Accessは、その道の手前に置く認証の関門です。preview.araisun.comに来た人をCloudflare側で止め、メールアドレスとOne-time PINで確認します。許可した人だけをTunnelの先へ通し、Hugo previewを見せます。
今回の主な構成は、次のような流れです。
訪問者
|
v
Cloudflare Access
| 許可メールだけ通す
v
Cloudflare Tunnel
| Cloudflareからローカルへつなぐ
v
cloudflared
|
v
http://localhost:1313
|
v
Hugo preview
役割を短くまとめると、こうです。
- Basic認証: origin側でID / パスワードを確認する
- Cloudflare Tunnel: originとCloudflareをつなぐ道を作る
- Cloudflare Access: その道に入る前に、誰を通すか確認する
次は、Cloudflare Zero Trust側でAccess applicationを作り、preview.araisun.comにメール認証をかけます。
Cloudflare Access applicationを作る
ここからは、preview.araisun.comにCloudflare Accessをかける流れです。Cloudflareの管理画面は変わることがありますが、現時点の公式ドキュメントでは、Cloudflare OneでAccess controls > Applicationsを開き、Add an applicationからSelf-hostedを選ぶ流れです。
Access applicationは、Tunnelのpublic hostnameを作る前に用意しておく方が安心です。認証なしのrouteだけを先に作ると、意図せずURLへ到達できる時間ができるためです。
設定値は、まずこのくらいにします。
| 項目 | 例 | メモ |
|---|---|---|
| Application type | Self-hosted | 公開ホスト名の前にAccessを置く |
| Application name | araisun preview | 管理画面で分かる名前にする |
| Session Duration | 1 day | 短期確認なら短めでよい |
| Public hostname | preview.araisun.com | 自分のpreview用ホスト名に置き換える |
| Path | 空欄 | ホスト名全体を守る |
| Identity provider | One-time PIN | 少人数の外部確認で使いやすい |
Public hostnameには、確認用に使うホスト名を指定します。この記事ではpreview.araisun.comです。Pathは空欄にして、準備中サイト全体をAccessの前に置きます。/adminだけを守るような設定ではなく、サイト全体を「許可した人だけ見られる」状態にします。
Session Durationは、ログイン状態をどれくらい維持するかの設定です。確認期間が短いなら、まずは1 day程度で十分です。長くしすぎると、検証後にセッションが残る時間も長くなります。
Identity providerは、今回はOne-time PINにします。Google WorkspaceやGitHubなどのIdPと連携する方法もありますが、少人数に一時的に見せるだけなら、メールでコードを受け取る方式が分かりやすいです。
Allow policyで許可メールを指定する
次に、Access policyで誰を通すかを決めます。
準備中サイトを数人へ見せるだけなら、Allow + Include + Emailsを基本にします。
| 項目 | 例 |
|---|---|
| Policy action | Allow |
| Rule type | Include |
| Selector | Emails |
| Value | 許可するメールアドレス |
確認してほしい相手が[email protected]なら、そのメールアドレスをEmailsに追加します。複数人に見せるなら、必要なメールアドレスを追加します。確認が終わった人はpolicyから外します。
社内ドメインや固定チームだけに見せるなら、Emails ending inでexample.comのようなドメイン単位にする選択肢もあります。ただ、最初の検証では個別のEmailsの方が挙動を確認しやすいです。
ここで避けたいのは、EveryoneをAllowに入れることです。公式ドキュメントでも、Allow policyでInclude Everyoneにすると全員がapplicationへアクセスできる代表的な誤設定として扱われています。One-time PINを使っていても、Everyoneや広すぎるlogin method条件を許可すると、意図より広く開く可能性があります。
保存したら、Applications一覧で対象applicationとpolicyを確認します。Tunnelでローカルpreviewを出す場合でも、Access側の保護対象ホスト名とTunnel側のpublic hostnameが同じpreview.araisun.comになっているかを見ます。
Tunnel側の作成やpreview.araisun.com -> http://localhost:1313の割り当ては、Cloudflare Tunnelの記事
の範囲です。この記事では、Accessがその入口を守るところに絞ります。
One-time PINでログインを確認する
設定できたら、通常ブラウザでhttps://preview.araisun.com/を開きます。
最初に確認するべきなのは、Hugoやstagingのページが見えることではありません。Cloudflare Accessのログイン画面で止まることです。
Accessのメール入力画面が出れば、少なくともpreview.araisun.comにAccessがかかっています。ここでいきなりサイト本体が表示される場合は、Access applicationのhostname、policy、Tunnel route、DNSのどこかがずれている可能性があります。
次に、許可済みのメールアドレスでログインします。
メールアドレスを入力し、CloudflareからOne-time PINを受け取ります。現行の公式ドキュメントでは、PINは最初のリクエストから10分で期限切れになります。細かい制限は変わる可能性がありますが、届いたらその場で入力する運用にしておくと迷いにくいです。
コードを入力して、Hugo previewやstagingページが表示されれば成功です。トップページだけでなく、記事ページや画像を含むページもいくつか開き、CSSや画像が崩れていないか確認します。
未許可メール、別ブラウザ、ログを確認する
許可済みメールで入れたら、次は未許可メールで試します。
Access policyに入れていないメールアドレスを入力し、先へ進めないことを確認します。画面上ではPINを送ったように見える場合でも、許可されていないメールには実際のコードが届かないことがあります。ここで「未許可メールでは入れない」ことまで確認しておくと安心です。
続けて、シークレットウィンドウや別ブラウザでも確認します。
通常ブラウザでログイン済みだと、Accessのセッションが残っていて認証画面が出ないことがあります。シークレットウィンドウなら未ログイン状態を確認しやすく、別ブラウザなら普段使いのCookieや拡張機能の影響も避けやすいです。
スマホ回線でも一度開きます。
Wi-Fiを切ってモバイル回線からpreview.araisun.comを開き、Accessのメール入力画面とサイト本体の表示を確認します。確認相手はスマホで開くことも多いので、メール入力画面と本文の見え方を先に見ておく価値があります。
最後に、Cloudflare Zero Trustのlogs / Access eventsを確認します。
許可済みメールでの成功、未許可メールでの拒否がどう記録されるかを見ます。スクリーンショットや記事用メモに使う場合は、メールアドレス、IP、team domain、account IDなどを伏せます。
Access logsの保持期間はプランで変わります。Free planでは短いため、長期監査用として期待しすぎず、検証した当日に確認するくらいに考えるのが現実的です。
origin直アクセスの注意点
Cloudflare Accessを設定したら終わり、と考えたくなりますが、originへ直接届く経路が残っている構成では注意が必要です。
今回のように、ローカルのHugoサーバーをTunnelで出す構成なら、originはlocalhost:1313です。外部から直接localhost:1313を叩くことはできないので、origin bypassは起きにくい構成です。
一方で、既存のVPSやnginxにある検証サイトへCloudflare Accessをかける場合は別です。
Cloudflare経由のpreview.araisun.comにはAccessがかかっていても、originのIPアドレスや別ホスト名から同じサイトへ直接アクセスできるなら、Accessを迂回される可能性があります。
この場合は、Cloudflare Accessだけで終わらせず、origin側の保護も考えます。
たとえば、origin firewallやsecurity groupでCloudflare IP rangesだけを許可する、nginx側でCloudflare以外からの80 / 443を閉じる、Authenticated Origin Pullsを使う、origin側でCloudflare Accessのapplication tokenを検証する、といった対策があります。
VPS / nginx側の基本構成はUbuntuでnginxを導入して最初の公開設定をする手順 も参考になります。
短期間のローカルpreviewなら、TunnelとAccessの組み合わせで扱いやすくなります。既存の本番寄りoriginを守るなら、Accessのpolicyだけでなく、originへ直接届く経路がないかも確認します。
使いどころ
この構成が便利なのは、公開前のサイトを少人数に見せたいときです。
たとえば、Hugoや静的サイトの公開前プレビュー。ローカルでhugo serverを動かし、Tunnelでpreview.araisun.comに出し、Accessで自分と確認相手のメールアドレスだけ通す。これなら、記事本文やデザインを公開URLで確認してもらえます。
WordPressのリニューアル確認にも使えます。
staging用のホスト名にAccessをかければ、クライアントやチームメンバーだけに見せられます。ただし、VPSやnginxのoriginが直接見えている場合は、origin IP直アクセス対策も合わせて考えます。
ローカルで動かしている検証アプリの一時共有にも向いています。
Vite、Next.js、Rails、Laravelなど、手元のlocalhostで動いているアプリを一時的に外から見せたい場面があります。Tunnelで外に出し、Accessでメール認証をかければ、URLを渡すだけで確認してもらえます。
共有するときは、こんな文面で十分です。
確認用URLです。
https://preview.araisun.com/
メールアドレスを入力すると、Cloudflareから確認コードが届きます。
届いたコードを入力すると、準備中のページを確認できます。
このURLは一般公開前の確認用です。
SNSや外部への共有はしないでください。
まとめ
準備中のサイトを一時的に非公開で共有するなら、Basic認証だけでなくCloudflare Accessもかなり便利です。
サイト側にIDとパスワードを持たせるのではなく、Cloudflareを受付にする。許可したメールアドレスの人だけを通す。確認相手が増えたらメールアドレスを追加し、終わったら外す。少人数の確認共有では、この運用がわかりやすいです。
Cloudflare Tunnelと組み合わせれば、ローカルのHugoサーバーや検証アプリも公開URLで見せられます。
Tunnelは道を作るもの。Accessはその道の手前で誰を通すかを見るもの。そう分けて考えると、役割が整理しやすくなります。
ただし、既存のVPSやnginx originにAccessをかける場合は、originを直接叩ける経路が残っていないか確認が必要です。サクッと非公開共有する話と、originを本気で隠す話は分けて考えた方が安全です。
Tunnelの詳しい作り方は、Cloudflare Tunnelの記事 に分けています。Cloudflareを前段に置いて静的サイトへ機能を足す例として、Cloudflare Workerを使うと静的サイトにサーバーレスな受付口を作れて便利 もあります。
まずはpreview.araisun.comのような確認用サブドメインを1つ作り、Cloudflare TunnelとAccessを組み合わせて試すのがわかりやすいと思います。
関連記事
- ローカルで立ち上げたサーバーをSSL経由で外部URL公開できるCloudflare Tunnel
- Cloudflare Workerを使うと静的サイトにサーバーレスな受付口を作れて便利
- Ubuntuでnginxを導入して最初の公開設定をする手順
参考
- Cloudflare Docs: Self-hosted public applications
- Cloudflare Docs: One-time PIN login
- Cloudflare Docs: Access policies
- Cloudflare Docs: Cloudflare Tunnel
- Cloudflare Docs: Zero Trust logs
- Cloudflare Docs: Application token
- Cloudflare Docs: Authenticated Origin Pulls