Cloudflare、認証管理ツール Cloudflare Access for Workers を公開──Worker 単位やアカウント全体での一括保護を実現
Cloudflare Workers のデプロイ時に Cloudflare Access を直接適用し、プレースホルダや本番環境を社内ログイン必須にデフォルト化する。
リリース: 2026-08-14 · 読了 3 分記事の要約
1. 核心（What）
- Cloudflare Access を単一の Worker またはアカウント全体の全 Worker に直接適用可能になった。
- JWT の手動検証なしで、ctx.access.getIdentity() を通じてユーザー情報（メール、名前、グループ）をコードから直接取得できる。
- wrangler.jsonc の設定により、ローカル開発環境（wrangler dev）での認証済みユーザーのシミュレーションが可能になった。
- 新世代の Rust 製モジュラープロキシ「FL2」を採用し、ルーティング処理をアクセス制御の前に実行するアーキテクチャに変更された。
2. 影響（Why）
- ホスト名依存からの脱却による運用コスト削減: 従来はホスト名ごとに Access ポリシーを設定する必要があったが、Worker 自体にポリシーが紐づくため、カスタムドメインやプレースホルダ URL が追加されても認証が自動継承される。
- 国内開発チームにおけるセキュリティガバナンスの徹底: 社内アプリを乱立させる現場において、デベロッパー依存の属人的な認証実装を排除し、アカウント全体でデフォルト非公開のポリシーを強制できる。
3. 根拠・詳細（How）
- FL2 プロキシによるルーティングと実行の分離: Rust ベースの FL2 により、アクセス制御（Access）が実行される前にどの Worker 宛てのトラフィックかを特定するルーティング処理が優先実行される設計に刷新された。
- コンテキストオブジェクトを介したアイデンティティ取得: リクエスト時の ctx.access.getIdentity() メソッド呼び出しにより、パースや署名検証を伴う従来の複雑な JWT 検証処理を実装不要にした。
4. 展望・課題（Next）
- オープンソースによるディスパッチプラットフォームの展開: 公開されたディスパッチ Worker のオープンソース例をベースに、各社が独自の安全な内部デプロイメントプラットフォームを構築・拡張していく見込み。