Cloudflare Accessではじめるアクセス制御 認証ゲートでサイトを守る
CloudflareのZero Trustサービスの一機能「Cloudflare Access」を使って、WebサイトやアプリケーションにメールやIDプロバイダーを使った認証ゲートを設置する方法を紹介します。ゼロトラストの考え方から導入手順、ソーシャルログインの設定、ログや料金の確認まで解説します。
- カテゴリー
- Webサービス >
- Cloudflare
発行
はじめに
Cloudflare Accessは、Cloudflareが提供するアクセス制御の仕組みです。
管理画面から設定するだけで、Webサイトやアプリケーションに認証ゲートを設置できます。ここでの認証は「アカウント認証」に分類されるもので、メールアドレスやソーシャルログインなどを使ってユーザーを識別し、許可されたユーザーだけがサイトにアクセスできるようになります。
たとえばピクセルグリッドでは、クライアントと共有する管理画面や、社内のツールを操作する画面などにはCloudflare Accessを使っています。
サイトの保護というとBasic認証も候補に挙がると思いますが、これらのサイトには会社や商品に関する秘密情報が含まれていたり、有料サービスの内容を管理していたりします。そうなると、Basic認証のようにパスワードを共有する方式では不安です。別の認証サービスを組み合わせるという選択肢もありますが、Cloudflare Accessであれば、アプリケーション側の変更は不要なので、導入も簡単です。
補足：そのほかのアクセス制限の手法
次の記事で、そのほかのアクセス制限の手法を解説しています。今回紹介しているCloudflare Accessも、アカウント認証を提供するサービスの一つとして取り上げています。
この記事では、Cloudflare Accessでできることや、導入の手順、注意点などを紹介していきます。
Cloudflare Accessとゼロトラスト
Cloudflare Accessは、Cloudflareが提供するゼロトラスト（Zero Trust Network Access）の一機能です。ゼロトラストとは、直訳すると「信頼ゼロ」ということですが、ここではリクエストごとに「誰であるか」や「通してよいか」を毎回確かめる、という考え方を表しています。アクセス元のIPアドレスが何であるか、といった前提は考慮せず、次の3項目を毎回確認します。
- Application（守る対象）：保護したいサイトや画面
- Policy（誰を通すか）：許可ルール。たとえば特定のメールアドレスやメールドメイン
- Identity Provider/IdP（誰であるかの判定）：メールアドレス認証やGoogleアカウント認証など
アクセスがあるごとに、これは保護対象のサイトで、許可されているのはどのメールアドレスで、アクセスしてきたのは誰か、結果として通してよいか、ということを判断してくれるサービスというわけです。
どこに認証ゲートがあるか
冒頭で、アプリケーションにコードを足す必要がないと書きましたが、ではどこでこの3項目の確認をしているのでしょうか。Cloudflare Accessは、Cloudflareのエッジで動作しています。Cloudflare Accessを有効にすると、サイトに到達する前にCloudflareのエッジで認証ゲートがかかり、許可されたユーザーだけがサイトに到達できるようになります。
補足：保護したいサイトがCloudflareで配信されていない場合
Cloudflareの外部にあるサイトにもCloudflare Accessをかけることはできますが、設定には少々工夫が必要になります。サイトへのアクセスの窓口をCloudflare経由にする必要があるため、Cloudflare Tunnelというサービスを使って、Cloudflareのエッジを常に経由する構成にします。次の記事でも取り上げています。
導入の手順
それでは、具体的にサイト保護を導入してみましょう。ここでは、Cloudflare Workers上にあるWebサイトを守る例を紹介します。大まかに2つの設定が必要です。1つ目はポリシーの設定で、誰を通すか、どうやって個人を識別するか、というルールを決めます。2つ目は、そのルールをサイトに適用することです。
サイトの登録より先にポリシーを作るの？と思われるかもしれませんが、ポリシーは特定のサイト専用のものではなく、複数のサイトから共有して使う部品という位置付けになっています。
1. Cloudflare Accessの設定
まずはCloudflareのダッシュボードにログインし、左メニューから「Zero Trust」を選びます。そうすると、「Cloudflare One」というページに遷移します。……どういうことなのでしょうか。現在、Cloudflare AccessはCloudflare Oneという広範なセキュリティサービス群のひとつとして提供されています。
注意：Cloudflareのサービス名やUI
Cloudflare Accessは以前は「Cloudflare for Teams」というサービスの一部でしたが、現在はCloudflare Oneの中にあるZero Trust Network Accessの機能のひとつとして提供されています。Cloudflareは、よくこういったリブランディングやサービスの再編を行いますし、それにともなってダッシュボードのUIも変わることがあります。この記事は2026年6月時点のUIをもとに説明していきますが、今後変更される可能性もありますので、ご留意ください。
初めてOneの機能にアクセスした場合は、まずチーム名を決める画面が出てきます。ここで決めた名前がチーム全体の識別子となり、認証ダイアログ画面のURLにも使われますので、適当と思われる名前をつけてください。
Cloudflare Oneのダッシュボードに入ったら、左メニューから「Access コントロール > ポリシー」を選び、ポリシーを追加します。ここで、許可するユーザーのメールアドレスやドメインを指定します。
たとえば、自社のメールドメインを持っている場合は「末尾が次のメール（Emails ending in）」で@example.comのように指定すると、そのドメインのメールアドレスを持つユーザーだけがアクセスできるようになります。個別のメールアドレスを指定したい場合は「メール（Emails）」でリストを作成します。そして右側の「アクション」でそれらのアドレスを「許可」に設定します。
補足：アクションの種類
「許可」のほかには、まず「ブロック」があり、これは想像できるとおり許可の反対です。「バイパス」は、サイト内の特定のパスにはアクセス制限をかけない場合などに使用します。「サービス認証」は、証明書やHTTPヘッダーなどで認証を行う場合に選択するもので、ブラウザUIを使わずに認証ができる方法です。なんらかのシステムから自動でアクセスさせたい場合には便利ですね。この「サービス認証」を選択すると、ポリシールールに「メール」は選べなくなります。
「ポリシーセッション期間」という項目もありますが、これはログイン状態をどのくらい保持するかを決めるものです。メールアドレス認証の場合、セッションが切れるとワンタイムコードをメールで送り、そのコードを入力する必要が出てきます。筆者はよほど重要な情報を扱うサイトでなければ、1週間くらいにしておくのが便利だと思っています。
多要素認証の設定もここで行えますが、こちらについては後述します。
2. アプリケーションの登録
続いて、このポリシーを保護したいサイトに適用します。今度は左メニューの「Access コントロール > アプリケーション」から、新しいアプリケーションを作成します。「セルフホストとプライベート」が表示されますので、Cloudflare PagesやWorkersでホスティングするサイトであれば「Workers」を選択して、そのまま続行します。
ここで、保護したいサイトのドメインを選び、必要に応じてサブドメインを入力します。Cloudflare Workersで、プレビューURLを使っている場合は、両方入力することになります。画面下の「Accessポリシー」では「既存のポリシーを追加」のプルダウンメニューから、すでに設定されているポリシーを選択できます。独自ドメインのサイトを丸ごとアクセス制限したいといった場合には、サブドメインフィールドは空欄のままになります。
補足：サブドメインが空欄の場合の挙動
空欄の場合、https://example.comにはアクセス制限が効きますが、https://www.example.comなどのサブドメインつきのアクセスには制限はかかりませんので注意が必要です。www.example.comや*.example.comを併記する必要があります。
今度は、それなら*.example.comだけ指定すればよいのでは？と思われるかもしれませんが（筆者は最初そう思っていました）、今度はhttps://example.comへのアクセスに制限がかからなくなりますので気をつけてください。どちらも必要なのです。よくよく見ると気づけるのですが、*.example.comの2文字目の.がある以上、https://example.comはマッチしないというわけです。
補足：パスごとにルールを変えたい場合
ポリシーはアプリケーション単位で適用されるため、「サイト全体は保護しつつ、/public以下だけは認証なしで公開したい」といった指定は、1つのアプリケーション内ではできません。この場合は、/publicを宛先に含めた別アプリケーションを作成し、そちらに「バイパス」アクションのポリシーを適用します。複数のアプリケーションにマッチする場合は、より詳細な宛先を指定したアプリケーションのルールが適用されます。
実際にアクセスすると、サイトの代わりにCloudflare Accessのログイン画面が表示されるはずです。
また、Cloudflare Workers側で、「ドメイン」メニューを確認すると、アクセス制限が有効になっていることがわかります。これで、Cloudflare Accessの設定は完了です。
Webサイト以外のものも保護できる
この節で取り上げたアプリケーションの設定画面には、Workers以外にも「プライベート宛先」や「インフラストラクチャ」など、いろいろな項目があったと思います。実はCloudflare Accessで保護できるのはインターネット上に公開されているWebサイトだけではありません。ローカルやイントラネット上のサーバーや、HTTP以外のSSHなどのプロトコルも保護対象として設定できます。
CloudflareはもともとセキュリティやCDNから始まった会社で、ネットワークインフラ全般に向けたサービスを提供していますので、アクセス制限においても対象範囲は非常に広いです。セキュリティに関することですので、詳しくない領域に軽率に導入するのはリスクを伴いますが、Web以外にもいろいろできるらしい、という点を頭の片隅に置いておくと、何かの際には役立つかもしれません。
Googleなどのソーシャルログインを使う
ここまでで「許可した人だけが通れる」状態ができました。メールアドレス宛に毎回コードが送られる認証は、パスワードのみの認証に比べると安全ですが、毎回コードを入力する手間があります。
そこで代替となるのが、Googleなどのソーシャルログインです。Cloudflare Accessでは、GoogleやGitHubなどをIDプロバイダー（IdP）として利用し、ソーシャルログインを使ってユーザーを識別する機能も提供しています。
ソーシャルログインの設定
Cloudflare Oneの画面で、今度はメニューから「インテグレーション > IDプロバイダー」を選択します。「IDプロバイダーを追加する」ボタンをクリックしてみると、さまざまなサービスと連携できることがわかります。すでに有効になっている「One-time PIN」は、先ほどのメールアドレス認証のことですね。
試しに「Google」を選択してみると、Google側で発行するIDやトークンを入力する画面が出てきます。ここでは詳細は省きますが、Google Cloud PlatformでOAuthクライアントを作成してIDなどを発行・入力することで連携ができます。ユーザー認証画面は次のようになります。
2要素認証とIndependent MFA
近年はログインといえば、パスワードだけでなく、スマートフォンの認証アプリやセキュリティキーなどを使った2FAが当たり前になってきました。せっかくアクセス制限をしっかりかけようというのであれば、2FAができればさらに安心です。
実は、Cloudflare Accessは、IdP側での2FA判定を利用することもできます。GoogleなどのIdPが、ログイン時に2FAが使われたかどうかを返すAMR（Authentication Method Reference）という情報をAccessが読み取り、ポリシーで「MFA（Multi-Factor Authentication）が使われたログインでないと通さない」といったルールを設定できます。
ただし、プロバイダーによっては、AMRが返されない場合もありますし、返されても正しく判定できない可能性もあります。そこで、Cloudflare AccessにはIndependent MFAという独自の仕組みも用意されています。これはIdPとは独立して、ログイン後にAccessが追加の認証を求める仕組みです。こちらは確実に2FAを要求できますが、ユーザー体験としては少し面倒になります。
ログや料金のこと
最後に、運用面で知っておきたいポイントをお伝えします。
料金
Cloudflare Zero Trustには無料プランがあり、50ユーザー（シート）まで利用できます。小〜中規模の管理画面なら十分まかなえそうですが、関係者が増えてきたら有料プランへの移行を検討する必要があります。料金の詳細は次のページで確認できます。
料金については、OneではなくZero Trustの範囲で設定されているようです。
アクセスログ
ログイン履歴（Accessの認証ログ）は、ダッシュボードの「インサイト > Logs」で確認できます。無料プランでも見られますが、ダッシュボードで遡れるのは24時間までですので、長期間保持したい場合は、ログを外部に転送して保存するか、有料プランに切り替える必要があります。
おわりに
Cloudflare Accessを使ってサイトに認証を設定する方法を紹介しました。Basic認証よりは強固で、自前で認証を実装するよりは簡単に導入できる、というのが筆者の印象です。特にCloudflareで配信しているサイトであれば、ちょうどよく使える場面があるのではないでしょうか。用語や設定など、最初は少しとっつきにくい部分もあるかもしれませんが、本記事が導入の参考になればうれしく思います。