Cloudflare、Workersアプリを社内認証で一括保護する「Access」新機能を発表

要点

• 米Cloudflareは、サーバーレス実行基盤「Cloudflare Workers」にゼロトラスト認証機能「Cloudflare Access」を直接適用できる新機能を発表した。
• アカウント全体または個別のWorker単位で設定でき、プレビュー環境や本番環境をデフォルトで社内ログイン必須の状態にできる。
• リクエストがアプリケーションコードに到達する前に認証が行われ、関連するあらゆるドメインやサブドメイン経由のアクセスが自動で保護される。
• 従来必要だったJWT（JSON Web Token）の検証処理が不要になり、Workerのコード内からユーザーのメールアドレスや所属グループなどの属性を直接取得可能になった。
• ローカル開発ツール「Wrangler」での認証シミュレーションに対応したほか、デフォルトで非公開となる社内静的サイト向けのテンプレートもオープンソースで公開された。

リード文

米Cloudflareは2026年8月14日、サーバーレスコンピューティングサービス「Cloudflare Workers」において、同社のゼロトラスト認証機能「Cloudflare Access」を直接適用できる新機能を発表した。

アカウント全体または個別のWorkerに対してポリシーを設定することで、開発者が個別に設定しなくても、アプリケーションをデフォルトで社内ログインの保護下に置くことが可能になる。社内向けに作成されたアプリケーションやデータが、誤ってパブリックなインターネット上に公開されるリスクを防止する狙いだという。

背景：開発の高速化と社内アプリの誤公開リスク

近年、AI技術の活用によって社内の多様なチームの従業員がアプリケーションを迅速に構築できるようになっている。一方で、作成されたアプリケーションがパブリックなインターネットへ不用意にデプロイされ、社内業務や企業データが外部に露出してしまうリスクがセキュリティ上の課題として浮上していた。

従来のCloudflare Access（社内リソースへのアクセスを制御するゼロトラスト認証機能）では、保護対象の設定をホスト名（ドメイン）単位で行う必要があった。そのため、Workerがアクセス可能なドメインごとに個別のポリシーを設定しなければならず、新しいカスタムドメインを追加する際にポリシー更新を忘れると、認証なしでアクセス可能になってしまうという運用の難しさがあった。

アカウント全体およびWorker単位での認証保護

今回発表された新機能により、認証ポリシーをホスト名ではなくWorker自体、あるいはアカウント全体に直接関連付けることが可能になった。

アカウント単位での一括設定

アカウントレベルで一度ポリシーを設定すると、アカウント内に存在する既存のWorkerだけでなく、将来新しく作成されるWorkerも含めて、作成された瞬間から自動的に非公開として保護される。

管理者はポリシーの適用範囲として以下のいずれかを選択できる。

• プレビューURLへのトラフィックのみを保護する
• 本番環境の全トラフィックを保護する
• プレビューと本番環境の両方を保護する

本番環境のWorkerを意図的に一般公開しつつ、開発途中のプレビュー環境が外部へ露出するのを防ぎたい場合には、プレビュー限定の保護設定が有効だとしている。また、アカウント全体に保護ポリシーを適用している場合でも、公開が必要な特定のWorkerについては個別にバイパス（除外）設定を行える。

単一Workerへのポリシー適用と優先順位

アカウント全体への適用を行わず、特定のWorkerのみを保護したい場合は、個別に対象のWorkerへAccessを適用できる。

WorkerにAccessを有効化すると、カスタムドメイン、ルーティング設定、workers.devサブドメイン、プレビューURLなど、どのような経路を経由したリクエストであっても、アプリケーションコードに到達する前の段階でCloudflareによって認証が強制される。

管理画面のWorkerビューには新設された「Access」タブが用意され、適用されているポリシーを確認できる。複数のポリシーが存在する場合の優先順位は、ホスト名レベルのポリシーが最優先され、次いでWorkerレベルのポリシー、最後にアカウントレベルのポリシーが適用される仕組みとなっている。

認証方式の柔軟性

認証には、企業が既に導入しているIdP（Identity Provider：ユーザーの認証情報を一元管理するシステム）を連携させることができる。これにより、従業員は既存の社内アカウントでそのままサインイン可能となる。特定のメールアドレス、メールドメイン、グループにアクセスを制限することもできるほか、自動化エージェント等に対してはサービストークンによるアクセス許可にも対応している。

コード側でのユーザー情報取得が容易に

AccessによってWorkerが保護されている場合、リクエストを行ったユーザーの情報をWorkerコード側で容易に取得できる仕組みも導入された。

従来、認証ユーザーの情報を取得するためには、開発者自身がJWT（署名付きでユーザー情報を安全にやり取りするためのデータ形式）のパース、署名検証、クレームの抽出を行う必要があった。

今回の機能追加により、認証済みのリクエストにはWorkerのコンテキストオブジェクト（ctx）にctx.accessが自動的に付与されるようになった。コード内からctx.access.getIdentity()を呼び出すだけで、認証されたユーザーのメールアドレス、名前、所属グループなどの情報を取得できる。これにより、ユーザーに応じた表示のパーソナライズ、細かな権限管理、ユーザー単位のアクティビティログ記録などを、自前でJWT検証を実装することなく実現できるとしている。

ローカル開発環境でのテストとテンプレート提供

ローカル開発ツール「Wrangler」を使用した開発時にも、このユーザー情報取得機能をテストできる環境が整えられた。設定ファイル（wrangler.jsonc）の開発用ブロックにAccessの設定を記述することで、認証済みユーザーのID情報をシミュレーションできる。本番環境と同様のオブジェクトがctx.access.getIdentity()から返されるため、設定内のメールアドレス等を切り替えることで、異なるユーザーとしての動作確認をデプロイ前にローカルで行えるという。

さらにCloudflareは、デプロイされるすべてのWorkerがデフォルトで非公開となる社内静的サイトプラットフォームのオープンソーステンプレートをGitHub上で公開したと案内している。