Cloudflare Accessのプライベートアプリケーションサポート強化と再利用可能なアクセスポリシー

Cloudflareは長年にわたり、Zero Trustネットワークアクセス（ZTNA）サービスであるCloudflare Accessを通じてID認識型アクセス制御を提供することによって、企業が社内リソースへのアクセスを最新化できるよう支援してきました。当社のお客様は、パブリックホスト名に紐づいたAccessアプリケーションの直感的ワークフローを使って、特にWebベースアプリケーションへのZTNA実装を加速しています。

しかし、当社のアーキテクチャ設計上、プライベートネットワークアプリケーション（プライベートIPアドレスやプライベートホスト名に紐付けられたアプリケーション）のアクセスは、主に当社のセキュアWebゲートウェイ（SWG）サービスのネットワークファイアウォールコンポーネントであるCloudflare Gatewayで処理してきました。当社はAccessで小さなラッパーを提供し、それら2つの体験を結んでいました。この実装は技術的には目的を達していましたが、いくつかの明らかな欠点があり、お客様からは一貫性の欠如をよく指摘されていました。

ですから、Access内のセルフホスト型プライベートアプリケーションの管理を再設計してパブリックホスト名のWebベースアプリの管理体験と一致させたことを本日発表でき、たいへん嬉しく思います。プライベートホスト名とプライベートIPアドレスで定義されたアプリケーションをAccessで直接サポートし、アクセスポリシーも再利用可能にします。これらのアップデートにより、ZTNAをデプロイして継続的なポリシー管理を合理化することがさらに容易になります。

この機能によってAccessの全体的な機能性がどう向上するかをよりよくご理解いただくため、「プライベート」アプリケーションの構成要素、それらへの一般的なアクセス方法、この機能の実現前に可能であったこと、この新機能で可能になることについて考察しましょう。ネットワーキングの専門家や愛好家の方は、振り返り：Cloudflare Zero Trustによるプライベートアプリケーションの保護 - AccessのプライベートIPアドレス・ホスト名サポート機能が登場する前 へお進みください。

この文脈でのプライベートアプリケーションは、プライベートIPアドレスまたはプライベートホスト名を通してのみアクセス可能なアプリケーションです。

プライベートIPアドレス

プライベートIPアドレスはよくRFC 1918 IPアドレスと呼ばれますが、範囲が特定のネットワークに設定されており、そのネットワーク上のユーザーしかアクセスできません。パブリックIPアドレスはインターネット全体で一意でなければなりませんが、プライベートIPアドレスはネットワーク間で再利用できます。すべてのデバイス、仮想マシンにプライベートIPアドレスがあります。例えば、私が自分のWindowsマシンでipconfigを実行すると、192.168.86.172のアドレスが表示されます。

これは、私のネットワーク上の他のすべてのマシンが、参照やこのマシンとの通信に使用できるアドレスです。プライベートIPアドレスは再利用可能で、特定のネットワーク内で一意でありさえすればよいため、アプリケーションや一時的なインフラストラクチャ（動的にスピンアップ・スピンダウンするシステム）に有用です。これは、リソースにパブリックIPv4アドレスを発行するよりも管理がはるかに簡単です。実際、利用可能なパブリックIPv4アドレス空間が不足しています！

私のネットワーク内のマシンでアプリケーションをホストするには、そのアプリケーションをネットワーク内の他のマシンで利用できるようにする必要があります。これは通常、アプリケーションを特定のポートに割り当てることで行われます。すると、そのアプリケーションへのリクエストはhttp://10.128.0.6:443といった感じになります。平易な英語にすると、「ハイパーテキスト転送プロトコルを使って、私のネットワークの10.128.0.6というアドレスのマシンに接触し、443番ポートに接続してください」という意味です。アプリケーションへの接続は、ブラウザ、SSH、RDP、シッククライアントアプリケーションなど、IPアドレスを介してリソースにアクセスする方法がいろいろあります。

ここにApache2のサンプルWebサーバーがあり、そのアドレスとポートの組み合わせで動作しています。

Webサーバーを実行しているこのマシンと同じネットワークの外でこのIPアドレスにアクセスしようとすると、「アクセスできません」になるか、まったく異なるアプリケーションに到達します（他のネットワークでそのIPアドレスとポートのコンビネーションで実行するものが他にある場合）。

プライベートホスト名

このアプリケーションにアクセスするのに10.128.0.6をいちいち覚えておくのは面倒です。インターネットと同様、プライベートネットワークでもDNSを使用することができます。パブリックDNSはインターネット全体の電話帳のような役割を果たしますが、プライベートDNSはキャンパス内の電話番号だけが記載された校内電話帳のようなものです。

プライベートアプリケーションでも、パブリックWebサイトを世界に公開する場合と同様にDNSレコードを設定できます。しかし、そうする代わりに、私のネットワーク内でのみアクセス可能なプライベートIPアドレスにDNSレコードをマッピングします。また、プライベートDNSは、レジストラーにドメインを登録する必要も、決められたトップレベルドメインを使う必要もありません。application.mycompanyでアプリケーションをホストできます。有効な内部DNSレコードです。

この例では、Google CloudでWebサーバーを実行しています。アプリケーションをkennyapache.localと呼ぶことにします。私のローカルDNSで、kennyapache.localには、Google Cloud（GCP）上のプライベートネットワーク内のIPv4アドレスにマッピングするAレコードがあります。

これは、私のネットワーク内のすべてのマシンが、明示的なIPアドレスを覚えていなくてもhttps://kennyapache.localを使えるということを意味します。

プライベートネットワークでは、ターゲットのプライベートIPアドレスまたはプライベートホスト名と同じネットワークに、マシン（物理または仮想）を直接接続する必要があります。これは、無認可のユーザーがアプリケーションにアクセスするのを防ぐのに役立つプロパティですが、使いたいアプリケーションがローカルネットワークの外にある場合は厄介です。

仮想プライベートネットワーク（VPN）、フォワードプロキシ、プロキシプロトコル（別名「PACファイル」）はすべて、プライベートネットワーク外のマシンからプライベートネットワーク内のプライベートIPアドレス/ホスト名に到達できるようにするための方法です。これらのツールは、マシンに別のネットワークインタフェースを追加して、特定のリクエストを、マシンが現在接続されているローカルネットワーク経由やパブリックインターネットへではなく、リモートのプライベートネットワークを介してルーティングするよう指定することで機能します。

私のマシンをフォワードプロキシ（この場合はCloudflareのデバイスクライアントであるWARP）に接続し、ipconfigを実行すると、新しいネットワークインタフェースとIPアドレスがリストに追加されているのが確認できます：

この追加のネットワークインタフェースは特定のネットワークリクエストを制御し、私のローカルネットワークでそのIPアドレスにルーティングするというマシンのデフォルト動作をとらず、外部のプライベートネットワークへルーティングします。

引き続き、GCPプライベートドメインでホストされているApache2サーバーをプライベートアプリケーションの例として使用します。Cloudflare Zero Trustが従来プライベートアプリケーションの保護にどう使われてきたか、そして、この新機能がなぜ大きな前進なのかを簡単に説明します。Cloudflare Zero Trustには、アプリケーショントラフィックの保護に使用される主要コンポーネントが2つあります：Cloudflare AccessとGatewayです。

Cloudflare Access

Cloudflare Accessは、従来型VPNを必要とせずに内部アプリケーションと内部リソースを保護するように設計されています。Accessを使えば、Okta、Azure AD、Google WorkspaceといったIDプロバイダーを通してユーザーの認証と認可を行った上で、内部のシステムやWebベースアプリケーションへのアクセスを認めることが可能になります。

これまでAccessでは、パブリックDNSレコードでアプリケーションを定義する必要がありました。つまり、ユーザーがAccessを活用し、そのきめ細かなセキュリティ機能をすべて使うためには、アプリケーションをインターネットに公開する必要があったのです。ただ、Accessでユーザー、デバイス、ネットワークの強力なセキュリティ制御が適用できるため、さほど怖いことではありません。実際、NISTをはじめ多くの主要なセキュリティ機関がこのモデルを支持しています。

実務は、管理者がアプリコネクタであるCloudflare Tunnelを使って、内部のIPアドレスまたはホスト名をパブリックURLにマッピングします。

次に、管理者はそのパブリックURLに対応するAccessアプリケーションを作成します。すると、そのアプリケーションに対するあらゆるリクエストに対し、Cloudflareがシングルサインオンフローをユーザーに送信します。

しかし、このアプローチは、アプリケーションをパブリックDNSで公開してはならないという厳しい要件がある企業には向きません。また、SSH、RDP、FTP、その他のシッククライアントアプリケーションはすべてプライベートアプリケーションへの接続オプションですが、そのようなブラウザ外のアプリケーションではこのアプローチは機能しません。

Accessで保護されたパブリックホスト名にSSH接続しようとすると、SSHとブラウザでのシングルサインオンを併せて行うのが難しく、認証する方法がないため、エラーメッセージが表示されます。

プライベートネットワークアプリケーションへのアクセス

これまではAccessの運用にパブリックホスト名が使われていたため、お客様のプライベートネットワークアクセスは、Cloudflare Gatewayのネットワークファイアウォール部分で処理してきました。当社は数年前にAccessプライベートネットワークアプリケーションをローンチしました。必要なGatewayブロックポリシーを自動的に生成するものですが、要は2つのGatewayポリシーの前にラッパーを置いただけの限定的なアプローチでした。

Cloudflare Gateway

Cloudflare Gatewayは、DNSとWebトラフィックをフィルタリングし、セキュアにすることによってパブリックインターネット上の脅威からユーザーを保護するセキュアなWebゲートウェイです。Gatewayは、悪意のあるドメインのブロック、危険なサイトカテゴリーへのアクセス制限、データ流出の防止などのセキュリティ制御を適用することにより、エンドユーザーとオンラインリソースの間の保護レイヤーとして機能します。

Gatewayは、ユーザートラフィックをプライベートネットワークにルーティングするためにも使用され、フォワードプロキシとして機能します。プライベートIPアドレスとプライベートホスト名に関するポリシーも作成できます。Gatewayが、ユーザーのマシンからGatewayサービス自体へプロキシされるトラフィックに依存しているからです。これが最も多く行われるのが、Cloudflare WARPクライアントです。WARPでは、どのIPアドレスやホスト名をGatewayに送信してフィルタリングとルーティングを行うかを設定できます。

プライベートネットワークに接続すると、ユーザーはGatewayで、そのネットワーク用に設定されたプライベートIPアドレスやプライベートホスト名に直接接続できます。

次に、特定のネットワークファイアウォールポリシーを設定し、プライベートIPアドレス宛のトラフィックを許可またはブロックすることができます。

良かった！プライベートアプリケーションの保護の問題をGatewayで解決できたようです。と思いたいところですが、残念ながらそうとは言い切れません。実はGatewayには、アプリケーションに焦点を当てたセキュリティモデルとして理想的とはいえないコンポーネントがいくつかあるのです。上では触れませんでしたが、アプリケーションのアクセス制御にGatewayを使用した際、次のような課題が浮かび上がりました：

• プライベートアプリケーションが一般的なGatewayネットワークファイアウォールルールと混在しており、設定と保守が複雑になっていました

• Terraformでは、プライベートアプリケーションの定義と管理ができませんでした

• アプリケーションアクセスログは、ネットワークファイアウォールの一般ログ（全社の全インターネットトラフィックが含まれる場合もあります！）に埋もれていました

• Gateway内の適用は特定のWARPクライアントセッションに依存しており、詳細なID情報が欠けていました

• 管理者は、Accessルールグループなど、アプリケーションのアクセス制御管理用に特別に構築されたAccess機能を使えませんでした

もっとうまいやり方があるはずだと思いました。

当社はこうした限界があることを認識した上で、あらゆるアプリケーションをサポートすべくAccessの拡張を始めました。パブリックかプライベートかは関係ありません。これを指針として、Cloudflare Accessで統一されたアプリケーション定義の作成に取り組みました。セルフホスト型アプリケーションは、パブリックにルーティング可能かプライベートにルーティング可能かにかかわらず、単一のアプリケーションタイプで定義する必要があります。結果は単純明快です：Accessアプリケーションは、プライベートIPアドレスとプライベートホスト名をサポートするようになりました。

しかし、エンジニアの作業は、Cloudflare AccessにプライベートIPアドレスとプライベートホスト名のオプションを追加するだけといった単純なものではありませんでした。当社プラットフォームのアーキテクチャでは、Accessはプライベートリクエストを単独でルーティングする手段を持ちません。そのコンポーネントに関しては、やはりGatewayとWARPクライアントに依存せざるを得ません。

アプリケーション認識型ファイアウォール

つまり、Gatewayのファイアウォールにアプリケーションに特化したフェーズを追加する必要があったのです。この新しいフェーズでは、ユーザーのトラフィックが定義されたアプリケーションと一致するかどうかを検出して、一致する場合はトラフィックをAccessに送り、ユーザーとそのセッションの認証と承認を行います。そのためには、Gatewayのネットワークファイアウォールを拡張して、どのプライベートIPアドレスとプライベートホスト名がアプリケーションとして定義されているかを知る必要がありました。

この新たなファイアウォールフェーズのおかげで、管理者は現在、ネットワークファイアウォール全体のどこでプライベートアプリケーションを評価するかを厳密に設定できるようになっています。

プライベートアプリケーションのセッション

もう1つ解決しなければならないコンポーネントは、アプリケーションごとのセッション管理でした。Accessのパブリックアプリケーションでは、JSON Webトークン（JWT）をCookieとして発行しますが、都合のいいことにCookieには有効期限が設定されています。これがセッションの有効期限として機能します。プライベートアプリケーションの場合、当社が必ずCookieを保存できるとは限りません。リクエストがブラウザを経由しなければ、Cookieを置いておく場所がありません。

ブラウザベースのプライベートアプリケーションの場合は、パブリックアプリケーションとまったく同じパターンに従い、セッションを追跡する手段としてJWTを発行します。アプリ管理者には、これらのアプリについてJWT検証を行えるという追加メリットもあります。ブラウザベースでないアプリケーションの場合は、Gatewayのファイアウォールにアプリケーションごとのセッションを新たに追加する必要がありました。これらのアプリケーションセッションは特定のデバイスにバインドされており、ユーザーがアプリケーションにアクセスする前に認証を行わなければならない次回のタイミングを追跡します。

プライベートアプリケーションへのアクセス

Gatewayのファイアウォールでアプリケーションの認識とセッション管理の問題を解決したら、Accessを拡張して、プライベートIPアドレスとプライベートホスト名で定義されたアプリケーションをサポートすることができました。管理者は、プライベートIPアドレスとプライベートホスト名を使ってAccessアプリケーションを直接定義できるようになりました。

プライベートホスト名とプライベートIPアドレスがAccessアプリケーションを定義する際の設定オプションとなっていることがわかります。

非HTTPSアプリケーション（HTTPでも非ブラウザでも）の場合は、再認証を促すクライアントポップアップが表示されます：

HTTPSアプリケーションの動作は、パブリックホスト名を持つAccessアプリケーションとまったく同じです。ユーザーはシングルサインオンでログインするよう促され、次に、その特定のドメインにJWTが発行されます。

そして、アプリケーション自体にJWTが発行されたことがわかります。

この作業の一環で、Accessの長年の問題に対処することができました。複数のアプリケーションにわたるポリシーの管理は、時間がかかり、エラーが発生しやすいプロセスでした。ポリシーは個々のアプリケーションにネストされたオブジェクトであり、管理者はAccessグループに大きく依存するか、アプリケーションごとに同じ設定を繰り返す必要がありました。

管理者は、Reusable Policies（再利用可能なポリシー）を使って高リスク、中リスク、低リスクなどの標準化されたポリシーを作成し、複数のアプリケーションに割り当てることができるようになりました。再利用可能なポリシーは、1つ変更を加れば関連するすべてのアプリケーションに伝播するため、管理が大幅に簡素化されます。この新機能によって、お客様の多くは管理するアクセスポリシーを数百から一握りに減らすことができるでしょう。また、実際の関数に合わせ、IDプロバイダー（IdP）グループとの混同を防ぐために、名前を「Accessグループ」から「ルールグループ」へ変更しました。

これらの機能アップデートに加え、長年のユーザーフィードバックに基づいてUIの大幅な刷新を行いました。新しいインターフェースでは、より多くの情報が一目でわかり、アプリケーションの定義と管理のワークフローが一貫性のある直感的なものになっています。

本日のリリースは大きな前進ですが、今後もさらなる改善を予定しています。現在、プライベートホスト名のサポートは、TLS検査が有効になっているポート443に限定されています。2025年後半には、あらゆるポートとプロトコルの任意のプライベートホスト名にサポートを拡張し、Accessの機能をさらに広げる予定です。

Accessのこれらの新機能は既に稼働しており、すぐにご利用いただけます。リモートアクセスの最新化をまだ開始されていないなら、無料アカウントを作成してお試しください。プライベートリソースの保護、ポリシー管理の簡素化のいずれの目的でも、これらのアップデートがお客様のゼロトラスト推進につながることを楽しみにしています。これまでと同様にお手伝いしますので、質問やフィードバックがございましたら、担当アカウントチームまでお気軽にお問い合わせください。