ライセンスプレートからバッジへの移行：Gateway Authorization Proxy

2026-03-04
Ankur Aggarwal Alex Holland
4分で読める

私たちはよく「理想的な」状態について話します。すべてのデバイスにCloudflare One Clientのような管理されたクライアントがインストールされ、深い可視性とシームレスな保護を提供する状態です。しかし、現実はしばしば邪魔をします。企業買収を扱っている場合、仮想デスクトップを管理している場合、または高度に規制された環境でエンドポイントにソフトウェアをインストールできない場合があります。デバイスを完全に管理していなくても、そのトラフィックを保護する必要があります。

このギャップを埋めるには、アイデンティティチャレンジをデバイスからネットワーク自体に移す必要があります。ブラウザのネイティブプロキシ機能とグローバルネットワークを組み合わせることで、ユーザーを検証し、インターネットにアクセスできる任意のデバイスで詳細なポリシーを実行できます。

Gateway Authorization ProxyとProxy Auto-Configuration（PAC）File Hostingを構築して、この認証を自動化し、管理されていないデバイスがCloudflareに接続する方法を簡素化しました。

問題：IPアドレスだけでは十分でない場合がある

2022年に、トラフィックをCloudflare経由でルーティングしてフィルタリングルールを適用できるプロキシエンドポイントをリリースしました。アクセスの即座のニーズは解決しましたが、重大な「アイデンティティクライシス」がありました。

そのシステムは静的IPアドレスに依存してユーザーを識別していたため、車だけを認識し、中の人を認識しないセキュリティガードのようなものでした。特定のIPの車が現れれば通されましたが、運転手が車を変えたり、別の場所から作業したりすると、ガードは混乱しました。

これにより、いくつかの大きな問題が発生しました：

• 匿名ログ：IPアドレスは分かりましたが、人物は分かりませんでした。
• 脆弱なポリシー：ユーザーが新しい自宅やオフィスに移動すると、エンドポイントが壊れるか更新が必要でした。
• 手動メンテナンス：独自のPACファイル（ブラウザにプロキシの場所を教える「GPS」）をホストする必要があり、チームが管理すべきもう一つの項目でした。

解決策：Authorization Proxy

新しいGateway Authorization Proxyは入り口に「バッジリーダー」を追加します。トラフィックがどこから来ているかを見るだけでなく、Cloudflare Accessスタイルのログインを使用してユーザーが誰であるかを検証してから、Gatewayフィルタリングを実行します。

これは、ライセンスプレートに基づくゲストリストから、全員が独自のバッジを持つシステムへの移行と考えてください。

これにより、いくつかの大きなメリットがもたらされます：

• 真のアイデンティティ統合：プロキシエンドポイントに関連するログに、どのユーザーがどのサイトにアクセスしているかが正確に表示されます。デバイスにクライアントがインストールされていなくても、「財務チームのみがこの会計ツールにアクセスできる」などの具体的なルールを書くことができます。

• 複数のアイデンティティプロバイダー：これは大企業やM&Aを行っている企業にとってのスーパーパワーです。ユーザーに表示するアイデンティティプロバイダーを選択できます。一つまたは複数のログイン方法（OktaやAzure ADなど）を同時に表示できます。これは競合他社が現在提供していない柔軟性のレベルです。

• 簡素化された請求：各ユーザーは、Cloudflare One Clientと全く同じように「シート」を占有するだけです。追跡すべき複雑な新しいメトリクスはありません。

これを可能にするために、デバイスクライアントなしで、ユーザーのアイデンティティを各リクエストに関連付けるという技術的なハードルを克服する必要がありました。どのように機能するかを読み続けてください。

Authorization Proxyがアイデンティティを追跡する方法

Authorization Proxyは署名されたJWT Cookieを使用してアイデンティティを維持しますが、落とし穴があります：プロキシ経由で新しいドメインに初めてアクセスするとき、まだCookieがありません。入る新しい建物ごとにバッジを見せるようなものです。

上のフローチャートは、この認証プロセスがどのように機能するかを正確に示しています：

ドメインへの初回アクセス：新しいドメインにナビゲートすると、Gateway Authorization Proxyはドメインアイデンティティクookieが存在するかチェックします。存在しない場合、Cloudflare Accessにリダイレクトされ、既存のCloudflare AccessアイデンティティCookieをチェックします。Cloudflare Accessで既に認証されている場合、そのドメイン専用のセキュアトークンを生成します。認証されていない場合、アイデンティティプロバイダーでのログインにリダイレクトします。

ユーザーには見えない：このプロセス全体は、Cloudflareのグローバルエッジネットワークのおかげでミリ秒で発生します。リダイレクトは非常に高速で、ユーザーは気づきません。ページが正常に読み込まれるのを見るだけです。

再訪問は即座：Cookieが設定されると、そのドメイン（およびサブドメイン）への後続のリクエストはすべて即座に認証されます。もうリダイレクトは必要ありません。

このアプローチにより、アクセスするすべてのドメインでユーザーごとにトラフィックをログ記録およびフィルタリングでき、必要に応じて即座にアクセスを取り消すことができます。すべてユーザーのデバイスにソフトウェアをインストールする必要がありません。

独自のPACファイルをホストする必要がなくなりました

セットアッププロセスから「宿題」も取り除いています。Proxy Auto-Configuration（PAC）File Hostingを使用して、PACファイルを直接Cloudflareでホストできるようになりました。

簡単にするために、数分で稼働できるスターターテンプレートを含めました。また、AIアシスタントのCloudyを統合して、コード行を読まなくても、PACファイルが何をしているかを正確に理解するのに役立つ要約を提供します。

これはあなたのチームに適していますか？

より大きな制御と最高のユーザーエクスペリエンスのためにCloudflare One Clientを引き続き推奨しますが、Auth Proxyは特定のシナリオに最適です：

• 仮想デスクトップ（VDI）：ユーザーが仮想マシンにログインし、ブラウザを使用してインターネットにアクセスする環境。
• 合併・買収：2つの異なる会社を迅速に1つのセキュリティ傘下に置く必要がある場合。
• コンプライアンス制約：エンドポイントにソフトウェアをインストールすることが法的または技術的に禁止されている場合。

次は何ですか？

これにより、Cloudflare Oneに接続するクライアントレスセキュリティオプションが拡張され、Authorization Endpointsに関連するサポートされるアイデンティティ方法の拡張にすでに取り組んでいます。Kerberos、mTLS、従来のユーザー名/パスワード認証にご注目ください。ユーザーの認証方法においてさらなる柔軟性を提供します。

Gateway Authorization ProxyとPAC File Hostingは、すべてのアカウントタイプで本日オープンベータとして利用可能です。Cloudflareダッシュボードの「Resolvers and Proxies」セクションにアクセスして開始できます。

Cloudflareのconnectivity cloudは企業ネットワーク全体を保護し、顧客がインターネット規模のアプリケーションを効率的に構築し、任意のWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃を防御し、ハッカーを寄せ付けないようにし、Zero Trustへの道のりを支援します。任意のデバイスから1.1.1.1にアクセスして、インターネットをより高速で安全にする無料アプリを開始してください。より良いインターネットの構築を支援するという私たちの使命について詳しく学ぶには、こちらから始めてください。新しいキャリアの方向性をお探しの場合は、求人情報をご確認ください。