Cloudflare Access はアプリケーションの手前に配置され、ユーザーを通す前に、すべてのリクエストを Access ポリシーと照合します。用途ごとに複数のアプリケーションタイプがあります。選ぶ基準は、アプリケーションのホスト場所、ユーザーの接続方法、セッションと認可の制御レベルです。
多くのチームはセルフホストアプリケーションから始め、その後 SaaS アプリケーション、インフラストラクチャターゲット、またはそれらを組み合わせて拡張します。
次の表は、各アプリケーションタイプの主な違いです。詳細な設定手順は、各タイプのセクションを参照してください。
| セルフホストアプリケーション | SaaS アプリケーション | インフラストラクチャアプリケーション | Bookmark | |
|---|---|---|---|---|
| 保護対象 | 自社で所有・管理するリソース。公開 Web アプリ、プライベートネットワーク上の宛先、Cloudflare Workers | チームが使うサードパーティ SaaS ツール（Salesforce、Atlassian、Workday） | 公開ネットワークまたはプライベートネットワークから到達できる個々のサーバーとインフラストラクチャターゲット | App Launcher に表示する外部 URL（Access 認証では保護しない） |
| Cloudflare One Client が必要 | 宛先の種類と ポリシー要件 による | 不要 | 必要 | 不要 |
| クライアントレスアクセス | 可能（パブリックホスト名、Browser Isolation、cloudflared access CLI） |
該当なし。ユーザーは SaaS アプリに直接アクセスする | 不可 | 該当なし |
| 認証と認可 | セッション管理と、アプリケーションへ署名付きで渡すアプリケーショントークンを含む Access ポリシー | SAML / OIDC アサーション付きの Access ポリシー | ポートやユーザー名など、プロトコルを意識した認可を行うインフラストラクチャポリシー | App Launcher 向けの表示専用ポリシー |
| プライベートネットワークルーティング | プライベート宛先の場合のみ | 不要 | 必要 | 不要 |
| セッションとトークンの管理 | あり（アプリケーショントークン、セッション期間、強制再認証） | あり | あり | なし |
| 監査ログ | 認証イベントとリクエスト単位の Access ログ | 認証イベント | 認証イベント、SSH コマンドログ | App Launcher の認証のみ |
| こんなときに使う | ほとんどの用途。Web アプリ、プライベートアプリ、Zero Trust ネットワーキング、Workers | SaaS アプリのコンプライアンス徹底、SSO 向けの複数 IdP 対応 | プロトコルレベルの認可による細かいサーバーアクセス制御 | 1 つのポータルにリンクをまとめる |
セルフホストアプリケーションは、最も汎用的なアプリケーションタイプです。Access 導入の大半を占めます。セルフホストアプリケーションは、トラフィックの行き先を自分で制御できるリソースを表します。Cloudflare DNS 上の公開サイト、Cloudflare Tunnel で接続したプライベートネットワーク上の非 Web サービス、Cloudflare 上で動く Worker などが対象です。
セルフホストアプリケーションでは、セッション管理、アプリケーショントークン、強制再認証、デバイスポスチャチェック、IdP グループを含む、Access ポリシーエンジンをすべて使えます。
アプリケーションがすでに公開インターネット上にあり、DNS を Cloudflare で管理している場合（または部分的な CNAME 構成で、DNS は他社ホストだが Cloudflare がトラフィックをプロキシする場合）、アプリケーションのホスト名を一致させて Access を手前に置けます。Cloudflare がリクエストをプロキシし、ログイン画面を表示します。ユーザーが Access ポリシーを通過したあとだけ、オリジンへトラフィックを転送します。
これが最も一般的な出発点です。ユーザーのデバイスに何もインストールする必要はありません。認証はすべてブラウザー内で行われます。
設定手順は セルフホストの公開アプリケーションを追加する を参照してください。
セルフホストアプリケーションは、特定のプライベート IP、ホスト名、CIDR 範囲（例: 10.0.0.0/8 のような IP アドレスブロック）にポートまたはポート範囲を付けて、プライベートネットワーク上のリソースも保護できます。これが Cloudflare 上で Zero Trust ネットワークアクセスを構築する主な方法です。
プライベートネットワークアプリケーションでは、ユーザーのトラフィックを Cloudflare 経由でルーティングする必要があります。通常は、デバイス上で Cloudflare One Client を実行します。プライベートネットワークは、Cloudflare Tunnel または Cloudflare Mesh で Cloudflare に接続する必要もあります。
プライベートネットワークアプリケーションでは、公開アプリケーションと同じ種類の Access ポリシーを定義し、プライベート宛先に適用します。ネットワーク上の「誰が何に到達できるか」を、ID を意識した細かい制御で決められます。VPN レベルの広いアクセスを、アプリケーション単位またはサービス単位のポリシーに置き換えます。Access ポリシーは再利用できるので、同じポリシーを複数のアプリケーションに適用できます。
設定手順は セルフホストのプライベートアプリケーションを追加する を参照してください。
セルフホストアプリケーションは、ホスト名や IP ではなく、名前で Cloudflare Worker を直接保護することもできます。Worker を宛先に選ぶと、その Worker とすべてのプレビューデプロイをまとめて対象にするか、プレビューデプロイだけを対象にするかを選べます。
これが Worker の手前に認証を置く、最も安全でわかりやすい方法です。Worker 上の個別ルートを設定し、ルート単位で認証を管理する代わりに、Worker 全体（必要に応じてプレビューデプロイも含む）を Access アプリケーションに紐付けます。どのルートへのリクエストも、先に Access を通過します。
Workers 向けの設定手順は Cloudflare Access for Workers を参照してください。
セルフホストアプリケーションは、クライアント側の cloudflared 認証に対応しています。ユーザーはデバイスに cloudflared をインストールし、コマンドラインから cloudflared access login <hostname> を実行して、Cloudflare One Client なしで Access ポリシーによる認証ができます。ブラウザーのログインフローが使いにくい SSH セッション、API 呼び出し、その他のコマンドライン作業に向きます。
詳細は cloudflared 認証 を参照してください。
SaaS アプリケーションは、組織が使うが自前ではホストしないサードパーティツール向けです。Salesforce、Atlassian、Slack、Workday などが該当します。SaaS アプリケーションでは、一般的な ID 連携プロトコルである SAML または OIDC を使い、Cloudflare Access をサードパーティサービスのシングルサインオン（SSO）プロバイダーとして設定します。
ユーザーが SaaS アプリケーションにサインインすると、Cloudflare へリダイレクトされます。Cloudflare は設定済みの IdP へ認証をリダイレクトし、認証済みユーザーに対して Access ポリシーを評価します。両方のチェックを通過すると、Cloudflare はユーザーの ID を確認する署名付き資格情報（SAML アサーションまたは OIDC トークン）を SaaS アプリケーションへ返します。
次のような場合に SaaS アプリケーションを使います。
- サードパーティツールに一貫した Access ポリシーを適用する。 内部アプリケーションと同じ ID、デバイスポスチャ、ロケーション要件を、外部 SaaS ツールにも適用します。
- 複数の IdP を集約する。 Cloudflare は複数の IdP にわたって認証をフェデレーションできます。各 SaaS アプリケーションを個別に再設定せずに、IdP の入れ替えや追加ができます。直接の SSO 連携では通常できません。
- Cloudflare 固有の制御を適用する。 SaaS プロバイダー単体では確認できない要件を強制します。たとえば、Cloudflare One Client の必須化や、SaaS ツールへのアクセス前のデバイスポスチャチェックです。
SaaS アプリケーションは、サードパーティツールが SAML または OIDC フェデレーションに対応している必要があります。対応していない SaaS ツールもあります。SSO 連携の数や、フェデレーション認証で使える機能に制限がある場合もあります。SSO の互換性は、SaaS ベンダーのドキュメントで確認してください。
設定手順は SaaS アプリケーション を参照してください。
インフラストラクチャアプリケーションは、公開ホスト名またはプライベートネットワークから到達できるサーバーとインフラストラクチャターゲットに対して、プロトコルを意識したアクセス制御を提供します。宛先に到達できるかどうかだけを評価するセルフホストアプリケーションと違い、インフラストラクチャアプリケーションは接続後にユーザーができることも制御します。認証に使えるユーザー名、アクセスできるポート、実行できるコマンドです。
インフラストラクチャアプリケーションには Cloudflare One Client が必要です。プライベートネットワーク上のターゲットでは、Cloudflare Tunnel または Cloudflare Mesh でネットワークを Cloudflare に接続する必要もあります。
次のような場合にインフラストラクチャアプリケーションを使います。
- プロトコルレベルの認可。 特定ユーザーに、ターゲットサーバー上の特定ポートとユーザー名へのアクセスを許可するポリシーを定義します。
- コマンドログ。 コンプライアンスと監査のため、すべての SSH セッションとコマンドを記録します。Logpush でストレージサービスまたは SIEM にログをエクスポートできます。
- 短命証明書。 すぐに期限切れになる証明書でユーザーを認証し、長期間有効な SSH 鍵をなくします。盗まれた鍵や忘れられた鍵が、サーバーへの永続的なアクセスを与えるリスクを取り除きます。
インフラストラクチャアプリケーションは SSH に対応しています。他のプロトコル（SSH を含む）でのサーバーアクセス保護には、引き続き セルフホストアプリケーション を使えます。ただし、ユーザー認可を追加で制御できるのはインフラストラクチャアプリケーションだけです。
設定手順は インフラストラクチャアプリケーションを追加する を参照してください。
Bookmark は Access では保護されません。Bookmark は、App Launcher に他のアプリケーションと並べて表示したい任意の URL へのリンクです。Bookmark に Access ポリシーを割り当てられますが、そのポリシーは App Launcher でのタイル表示だけを制御します。宛先 URL は保護しません。
Bookmark は、Cloudflare と連携していない外部アプリケーションも含め、ユーザーが使うすべてのツールを 1 つのポータルで見つけられるようにするために使います。
設定手順は Bookmark を追加する を参照してください。
レガシーのプライベートネットワークアプリケーションタイプは、プライベート IP アドレスへのアクセスを制御する Gateway Network ポリシーを作成します。レガシーのプライベートネットワークアプリケーションを追加すると、Cloudflare は Allow ルールと Block ルールの 2 つを生成します。Gateway Network ポリシーはデフォルト拒否ではないためです（Access ポリシーとは異なり、保護対象アプリケーションにユーザーが到達するには明示的な Allow ルールが必要です）。
レガシーのプライベートネットワークアプリケーションは、セッション単位の管理、アプリケーショントークン、Access ポリシーで使える機能一式には対応していません。このアプリケーションタイプは新規顧客向けには非推奨です。既存顧客には引き続き提供されます。
レガシーのプライベートネットワークアプリケーションを使っている場合は、より包括的なポリシー制御とセッション管理のため、セルフホストのプライベートネットワークアプリケーション への移行を強く推奨します。
詳細は プライベートネットワークアプリケーション（レガシー） を参照してください。