統合 SSO を使うアプリケーション

近年、多くの組織が信頼できるアイデンティティ（source of truth）の重要性を認識し、SSO プロバイダーを社内アプリケーションと直接連携しています。SSO プロバイダーは、設定した ACS URL を通じて、アプリケーションが存在する内部ドメインだけを把握します。そのため、ユーザーはアプリケーションにアクセスするにはローカルネットワークに接続している必要があります。このセキュリティ構成は、従来のネットワーク境界では理にかなっていますが、Zero Trust の導入では課題になります。クライアントレスアクセスモデルでは、ユーザーのデバイスは社内ネットワークという概念を持ちません。アクセスできる、範囲が限定されたアプリケーションだけを認識します。この問題を次の図にまとめます。

flowchart LR
accTitle: 統合 SSO を使う認可フロー
A("ユーザーが
app.public.com にアクセス")-->B("Cloudflare Tunnel が
公開ホスト名（app.public.com）を
内部ドメイン（app.internal.com）へルーティング")-->C("app.internal.com が
統合 SSO へリダイレクト")-->D("SSO の ACS URL が
app.internal.com を返す")-->E("404 エラー
デバイスは app.internal.com を
解決できない")

アプリケーションが統合 SSO を使っている場合、Cloudflare Access へのオンボードにはいくつかの方法があります。

SSO プロバイダーを設定できる場合は、社内の Web サービスをすべて Cloudflare ドメイン上だけで公開することを推奨します。これは Cloudflare が社内の Web アプリケーションアクセスに採用しているモデルであり、この状況のお客様が最もよく選ぶ解決方法です。

この方法では、既存の DNS インフラを変更する必要はありません。ネットワーク内の Cloudflare Tunnel が、外部（Cloudflare 公開）DNS から内部 DNS への変換を担います。システムはこの動きを前提に設計されています。SSO プロバイダーの ACS URL を Cloudflare の公開ホスト名に更新すると、結果は次のようになります。

flowchart LR
accTitle: SSO の ACS URL を更新した認可フロー
A("ユーザーが
app.public.com にアクセス")-->B("Cloudflare Tunnel が
公開ホスト名（app.public.com）を
内部ドメイン（app.internal.com）へルーティング")-->C("app.internal.com が
統合 SSO へリダイレクト")-->D("SSO の ACS URL が
app.public.com を返す")-->E("ブラウザーが app.public.com を表示")

オフィス内かリモートか、VPN クライアントを使うかどうかにかかわらず、すべてのユーザーはプライベートアプリケーションへアクセスするとき、常に app.public.com の Cloudflare Access 認証フローを経由します。ポリシー適用とセキュリティ監査の管理面が 1 つになり、追加のユーザー研修も不要です。