作った本人が忘れても閉じている 社内アプリを既定で私有にする仕組み

3行まとめ

• 誰でもアプリを作れるようになり、社内向けのつもりが公開されたまま置かれる事故が増えた
• Cloudflare が、アプリ単位とアカウント単位で会社のログインを強制できるようにした
• 認証済み利用者の情報がコードから直接取れる。トークン検証を自分で書かなくてよい

何が起きたか

Workers で動くアプリに、Cloudflare AccessCloudflare Accessアプリの手前に置く関所。会社のIDでログインした人だけを通します。 を直接かけられるようになりました。Access は会社のログインを通っていない人をアプリの手前で止める仕組みです。有効にすると、リクエストはアプリのコードに届く前に認証を求められます。

経路は問いません。カスタムドメイン、ルート、workers.dev のサブドメイン、プレビューURLプレビューURL本番に出す前の確認用に発行されるURL。作業中のものが外から見える経路になりがちです。 のどれから来ても同じ扱いです。

アカウント単位でポリシーを1つ置けば、いま動いているものも、これから作られるものも既定で私有になります。公開したい1本だけは、そのポリシーの対象から外せます。すでに誰でも使える状態で提供されています。

なぜ難しい・何がすごいか

守る対象が、ホスト名からアプリ本体に変わりました。これまでは Worker にたどり着けるドメインごとにポリシーを作る必要がありました。カスタムドメインを1つ足すたび、先にポリシーを更新しないと、その入口だけ認証なしで開いてしまいます。

設定漏れがそのまま穴になる形でした。ここが厄介でした。

いまはポリシーがアプリそのものに紐づきます。あとから増えたドメインやURLも、何もしなくても同じ守りの下に入ります。開発者ひとりひとりの記憶に頼る部分が減りました。

たとえ話

鍵の掛け方が入れ替わった、と考えると分かりやすくなります。

古いやり方は、部屋を増やすたびに扉へ鍵を付けて回る運用でした。付け忘れた部屋には誰でも入れます。

新しいやり方は、建物の入口を最初から施錠しておくものです。部屋がいくつ増えても、入口を通らずに中へは行けません。

用語ミニ辞典

• Cloudflare Access: アプリの手前に置く関所。会社のIDでログインした人だけを通します。
• Workers: Cloudflare 上でプログラムを動かす仕組み。自前のサーバーを持たずにアプリを公開できます。
• プレビューURL: 本番に出す前の確認用に発行されるURL。作業中のものが外から見える経路になりがちです。
• JWT: 認証済みであることを示す署名付きの文字列。受け取った側が署名を確かめて中身を信用します。
• サービストークン: 人ではないプログラムに通行許可を与える鍵。エージェントからの利用に使えます。

技術者向けの深掘り

ポリシーが重なったときは、細かいほうが勝ちます。ホスト名に付けたものが最優先で、次がアプリ、最後がアカウントです。

守る範囲も選べます。プレビューURLだけにすれば、本番は公開のまま作業中のデプロイだけを閉じられます。全ホスト名にすれば、カスタムドメインもルートも workers.dev も含めて閉じます。

利用者の情報の取り方も変わりました。Access が有効なら、リクエストごとの ctx に認証済み利用者が乗ります。

if (!ctx.access) return new Response("Access required", { status: 403 });
const identity = await ctx.access.getIdentity();

トークンを自分で解析して署名を確かめる手順は要りません。ローカルでは wrangler.jsonc に access.dev を書き、擬似の利用者として動作を確認できます。

土台には FL2 があります。Cloudflare のエッジを動かす Rust 製のモジュラープロキシです。対象のアプリを特定するために、WorkersWorkersCloudflare 上でプログラムを動かす仕組み。自前のサーバーを持たずにアプリを公開できます。 のルーティングと実行を分ける改修が入りました。

これは自分に関係ある？

• 社内向けのツールを作って配っている人: URLが社外から見えていないかの確認が、アプリ1つ分で済みます。
• 情報システムやセキュリティの担当: 開発者それぞれの設定に頼らず、アカウント側で既定を決められます。
• Cloudflare を使っていない人: 直接の影響はありません。既定を閉じる側に寄せる考え方は、どの基盤でも使えます。