Cloudflare 16：Access ― 社内ツールの前に立つ受付

一言でいうと：アプリの前に立つ受付

Cloudflare Access は、社内ツール（アプリ）の手前に立ち、リクエストのたびに「誰か」を確かめて、決めた人だけを通す受付です。

ビルの入り口の受付を思い浮かべてください。社員証を見せた人だけがゲートを通れます。Access は、それを Web のリクエストでやります。

このように、「網の中だから信用する」をやめ、毎回確かめる考え方をゼロトラストと呼びます。Access は、Cloudflare のゼロトラスト製品群（管理画面では Cloudflare One と呼ばれます）の中心です。

社内ツールは、ふつう15号の Tunnel で Cloudflare とつなぎます。Tunnel が「届くようにし」、Access が「誰を通すか決める」という分担です。

仕組み①：まだなら、いつものアカウントでログイン

社員が初めて app.example.com を開いたときの流れです。

ここで大事なのは、Access 自身はパスワードを持たないことです。本人確認は、Google や Microsoft のような IdP（Identity Provider：本人確認を受け持つサービス）に任せます。図の左下の箱が IdP です。

こうすると、パスワードの管理や多要素認証は、会社がすでに使っているアカウントの仕組みにまとまります。社員が辞めたら、会社のアカウントを止めるだけで、Access で守っているすべてのツールに入れなくなります。ツールごとにアカウントを消して回る必要はありません。

仕組み②：ポリシーで「この人を通すか」を決める

ログインで「誰か」が分かったら、次は「この人を、このアプリに通してよいか」です。これを決めるのがポリシーです。図では、小包（tanaka@ さんのリクエスト）がポリシーの段で審査されています。

ポリシーには、次のような条件を組み合わせて書けます。

たとえば「@example.com のメールで、かつ会社の管理する端末から」なら許可、のように書きます。

当てはまらなければ、リクエストはエッジで止まり、社内ツールには1バイトも届きません。ツールにまだ見つかっていない脆弱性があっても、許可されていない人は、そこまでたどり着けないのです。

一度通った人には、しばらく有効な「通行証」が発行されます。有効な時間（セッションの長さ）はアプリごとに決められます。

仕組み③：通すときは、身分証（JWT）を付けて送る

ポリシーを通ったリクエストは、社内ツールに送られます。このとき Access は、リクエストに身分証を付けます。それが JWT（JSON Web Token）です。

社内ツールは、このヘッダーを読めば「今来たのは [email protected] さんだ」と分かります。ツールの中で「誰が操作したか」を記録したり、画面に名前を出したりするのに使えます。ツール側でログイン画面を作らなくてよくなるのです。

JWT は、中身（誰か・いつまで有効か）に署名が付いたデータです。署名は Cloudflare だけが作れる鍵で付けられているので、誰かが中身を書き換えると、署名が合わなくなります。

ただし、この仕組みが意味を持つのは、社内ツールの側で署名を確かめたときだけです。次のページで、その方法を見ます。

オリジンで JWT を検証する

「Cf-Access-Jwt-Assertion ヘッダーがあるから、Access を通ってきたのだろう」と信じてはいけません。もし誰かが Access を迂回して社内ツールに直接リクエストを送れるなら、そのヘッダーを自分で書いて送れてしまうからです。

そこで、社内ツールの側で JWT の署名を検証します。たとえば jose というライブラリを使うと、次のように書けます。

import { createRemoteJWKSet, jwtVerify } from "jose";

const TEAM = "https://your-team.cloudflareaccess.com";
const JWKS = createRemoteJWKSet(new URL(`${TEAM}/cdn-cgi/access/certs`));

export async function whoIs(req: Request): Promise<string> {
  const token = req.headers.get("cf-access-jwt-assertion");
  if (!token) throw new Error("Access を通っていない");
  const { payload } = await jwtVerify(token, JWKS, {
    issuer: TEAM,
    audience: "アプリの AUD タグ",
  });
  return String(payload.email);
}

宛先を確かめないと、別のアプリ用の JWT を使い回されるおそれがあります。

ログインの方法（IdP）を選ぶ

Access は、たくさんの IdP とつなげます。会社の状況に合わせて選びます。

複数の IdP を同時に使うこともできます。たとえば「社員は Entra ID、外部の協力会社の人はワンタイム PIN」とし、ポリシーで「協力会社の人はこのアプリだけ」と絞ります。

ワンタイム PIN は便利ですが、「そのメールアドレスを受け取れる人」を確かめているだけです。会社のアカウントと違い、退職の管理や多要素認証とはつながりません。社員向けには、会社の IdP をつなぐのが基本です。

導入：チームを作り、アプリとポリシーを登録する

Access の設定は、Cloudflare One（Zero Trust）の管理画面で行います。

前提として、守るホスト名の DNS が Cloudflare にあり、プロキシ（オレンジの雲）を通っている必要があります（01号）。社内のサーバーなら、15号の Tunnel の公開ルートとして作っておきます。

アプリの設定画面には、前のページで使う AUD タグが表示されます。オリジンで JWT を検証するときに使うので、控えておきましょう。設定は Terraform でコードとして管理することもできます（34号）。

ポリシーの書き方：含める・必須・除く

ポリシーの条件は、3つの枠に分けて書きます。

図の例を読むと、「@example.com のメールの人、または GitHub の example-org のメンバー」のうち、「日本から、かつ管理された端末で」アクセスしていて、「[email protected] ではない」人を許可する、という意味になります。

ポリシーの動作には、次の4つがあります。

1つのアプリに複数のポリシーを付けることもできます。

機械からのアクセス：サービストークン

Access で守ったアプリに、人ではないものがアクセスしたい場合があります。CI から社内の API を叩く、夜間のバッチが社内のサーバーからデータを取る、といった場面です。機械は、ブラウザで Google にログインできません。

そのために使うのがサービストークンです。管理画面で作ると、Client ID と Client Secret の組が発行されます。機械は、これを2つのヘッダーに入れて送ります。

curl https://api.example.com/report \
  -H "CF-Access-Client-Id: xxxx.access" \
  -H "CF-Access-Client-Secret: yyyy"

アプリの側では、動作を Service Auth にしたポリシーで「このサービストークンなら通す」と書きます。

サービストークンで通ったリクエストにも JWT が付くので、オリジンで同じように検証できます。

料金と制限：少人数なら無料で始められる

Access を含む Cloudflare の Zero Trust は、使う人の数（シート）で料金が決まります。

小さな会社やチーム、個人の開発なら、無料の枠で本格的に使えます。自宅のサーバーを Tunnel で出し、自分だけが入れるように Access で守る、という使い方も無料でできます。

注意したいのは、シートの数え方です。一度ログインした人は、一定期間シートを使っている扱いになります。外部の人をワンタイム PIN で招くと、その人も数に入ります。人数が上限に近い場合は、使わなくなった人のシートを外す操作が要ることがあります。

アプリの数やポリシーの数などにも上限があります。数字は公式の Limits のページで確かめてください。

2026年9月時点の情報です。料金・上限は変わるので、公式で確かめてください。

よくある落とし穴

いちばん大事なのは1つ目です。Access は「エッジを通るリクエスト」だけを審査します。エッジを通らない道が1本でも残っていれば、そこが裏口になります。 Tunnel と組み合わせ、社内ツールの受け口を閉じることで、初めて Access が唯一の入り口になります。

ほかの号とのつながり

Zero Trust の3つの号は、1つの形になります。Tunnel がつなぎ、Access が確かめ、Gateway が端末の側を守る。次の17号では、社員の端末から出ていく通信を守る Gateway と WARP を見ます。