前のページで見た「2つの流れ」のうち、流れ①（社内アプリへのアクセスを守る）の検問所にあたるのがCloudflare Access（クラウドフレア・アクセス）です。VPNの置き換えとしてZero Trustの入口になる製品で、Cloudflare Oneの中でも最初に触れる人が多い機能です。
一言でいえば、Accessは「アプリの前に立つ警備員」です。社内アプリ・NASの管理画面・ステージング環境など、限られた人だけに使わせたいものの手前に立ち、アクセスのたびに身元を確認します。このページでは、その認証の流れと、誰を通すかを決めるポリシーの仕組みを見ていきます。
このページで分かること
- Cloudflare Accessの役割と、VPNとの違い
- ログインからアプリ表示までの認証フロー
- ポリシーの組み立て方（アクション・ルール・条件）
- 対応する認証プロバイダー（IdP）とOne-time PIN
- 無料で使える範囲と注意点
Cloudflare Accessとは
アプリごとに立つ認証の門番
Accessは、ZTNA（Zero Trust Network Access）と呼ばれる分野の製品です。保護したいアプリをAccessに登録すると、そのアプリのURLへのアクセスはすべてCloudflareのネットワークで横取りされ、先にAccessの認証画面へ誘導されます。認証とポリシーの検証を通過した人だけが、アプリ本体にたどり着けます。
VPNとの違いは、守る単位です。VPNは「ネットワークへの入口」を1つ守り、入った後は比較的自由でした。Accessは「アプリ1つずつ」の前に門番を立てます。経理システムと開発サーバーで別のポリシーを設定できるため、前々ページで学んだ最小権限をそのまま実装できます。利用者側の体験も変わります。専用クライアントの起動や接続の待ち時間はなく、ブラウザーでURLを開くと自然にログイン画面が現れるだけです。
認証フロー：4つのステップ
- アクセス：利用者が保護されたアプリのURLを開くと、Cloudflareが要求を受け止め、認証画面（チーム名.cloudflareaccess.com）へリダイレクトします
- ログイン：利用者は、設定された認証プロバイダー（後述）でログインします
- ポリシー評価：Accessが「この人を通してよいか」をポリシーと照合します。メールアドレスだけでなく、国・IPアドレス・端末の状態（デバイスポスチャ）も条件にできます
- 転送：許可された場合のみ、Cloudflareがアプリへリクエストを転送します。以降しばらくは発行されたトークン（ブラウザーのクッキー）で再認証なしに使えます。有効期間はアプリごとに設定できます
重要なのは、アプリのサーバー自体には認証前のリクエストが一切届かないことです。ログイン画面の存在すら、権限のない人には見えません。
ポリシーの組み立て方
Accessの核心は「誰を通すか」を定義するポリシーです。ポリシーは次の部品で組み立てます。
- アクション：Allow（許可）/ Block（拒否）/ Bypass（検査なしで素通し）/ Service Auth（プログラム向けの認証。後述）
- ルールの型：Include（いずれかを満たせば候補：OR条件）/ Require(すべて満たすことを要求：AND条件）/ Exclude（除外：NOT条件）
- 条件（セレクター）：メールアドレス・メールドメイン（@example.com全員など）・IdPのグループ・国・IPレンジ・デバイスポスチャ・多要素認証の方式など
たとえば「Include：メールドメイン @example.com、Require：日本国内から、Exclude：退職者リスト」のように組み合わせます。人間ではなくプログラムやスクリプトからのアクセスには、サービストークン（IDとシークレットの組）を使うService Authを使います。
対応する認証プロバイダー（IdP）
Accessは自前のパスワード基盤を持たず、既存の認証プロバイダー（IdP：Identity Provider）に相乗りします。対応は幅広く、Google（個人のGoogleアカウント・Google Workspace）、GitHub、Microsoft Entra ID、Oktaのほか、SAMLまたはOIDCという標準規格に対応した汎用のIdPを登録できます。複数のIdPを同時に有効にして、利用者に選ばせることも可能です。
IdPを何も用意できない場合のために、One-time PIN（ワンタイムピン）という仕組みも標準で使えます。メールアドレスに使い捨てのコードが届き、それを入力してログインする方式です。「自分と家族のメールアドレスだけ許可」といった個人利用なら、IdPの設定なしにOne-time PINだけで十分に始められます。
具体例：NASの管理画面を守る
自宅のNASの管理画面を例にすると、Accessの典型的な使い方はこうなります。
- NASを次ページで学ぶTunnelでCloudflareに接続し、nas.example.com のようなサブドメインを割り当てる（ポート開放なし・非公開）
- Accessでこのドメインをアプリとして登録し、「自分のメールアドレスのみAllow」のポリシーを設定
- 外出先からURLを開くと、One-time PINまたはGoogleログインを求められ、通過するとNASのログイン画面が表示される
攻撃者から見ると、そもそもNASのログイン画面に到達できないため、パスワード総当たりや脆弱性スキャンの対象になりません。この手順は第8章の実践ページで詳しく扱います。
初心者が注意するポイント
- アプリ自体のログインは残す：Accessを通過した後に表示されるNASやアプリのログインは、そのまま使います。Access＋アプリ認証の二段構えが基本です（Accessの認証情報が漏れた場合の保険になります）
- 裏口を塞いでこそ意味がある：Accessで正面を固めても、アプリのサーバーがインターネットから直接アクセスできる状態では素通りされます。Tunnelで接続してオリジンを非公開にするのが定石です
- Bypassは慎重に：Bypassアクションは検査なしの素通しです。恒久的な設定にせず、限定的な用途にとどめてください
- SaaSアプリにも使える：自社ホストのアプリだけでなく、SaaSへのログインをAccess経由に集約する使い方（アイデンティティプロキシ）もあります。ただし初心者はまず自分のアプリの保護から始めるのがおすすめです
- 無料枠は50ユーザー：Cloudflare OneのFreeプランの範囲で、Accessの基本機能は一通り使えます（2026年8月時点）
関連サービス
- Cloudflare Tunnel：Accessとセットで使う、サーバー側の接続部品（次ページ）
- WARP（Cloudflare One Client）：デバイスポスチャを条件に使う場合に端末へ導入
- Turnstile：Webフォームのボット対策。Accessが「人を選ぶ」のに対し、Turnstileは「人間かどうかを確かめる」機能です
- mTLS：API Securityのページで学んだクライアント証明書認証。Accessの条件としても使えます
まとめ
- Accessはアプリ1つずつの前に立つ認証の門番で、VPNに代わるZTNAを実現する
- 認証フローは「横取り→IdPでログイン→ポリシー評価→許可のみ転送」の4段階。認証前のリクエストはサーバーに届かない
- ポリシーはAllow/Block等のアクションと、Include/Require/Excludeのルール、メール・国・端末状態などの条件で組み立てる
- IdPはGoogle・GitHub・Microsoft Entra IDなど。IdPなしでもOne-time PINで始められる
- オリジンを直接公開しないこと（Tunnel併用）が効果の前提
次に読む
※本記事の情報は 2026年8月時点のものです。