Cloudflare Access

Cloudflare Access を使うと、アプリケーションへのアクセスを許可する人を制限できます。承認する対象を決め、Worker が実行される前にすべてのリクエストを確認します。承認された訪問者は通過し、それ以外はログインページを表示するかブロックします。

次を保護できます。

• 1 つのアプリケーション: プレビュー URL、本番 URL、またはその両方でサインインを必須にします。
• アカウント内のすべての Worker: 既存の Worker と、これから作成する Worker をデフォルトで保護します。
• 特定のカスタムドメインとホスト名: ホスト名またはルート単位でアクセスを制限します。

Workers で Access を使うには、次が必要です。

• アカウントで Zero Trust が有効であること。Zero Trust がオンになっていない場合は、先に Zero Trust のセットアップ を完了してから、Workers ダッシュボードに戻ります。
• Workers と Access アプリケーションを管理する権限。

アカウント内のすべての Worker（今後デプロイする Worker を含む）でサインインを必須にします。プレビューデプロイだけ、または本番とプレビューの両方でサインインを必須にできます。

ダッシュボードのパス: Workers & Pages の概要ページ > Protect all Workers。

1. Cloudflare ダッシュボードで、Workers & Pages ページを開きます。

   Workers & Pages を開く ↗

2. Protect all Workers カードを探します。

3. カードに Not enabled と表示されている場合は、Enable Access を選びます。

4. Previews only または All traffic を選びます。

5. Authentication policy で、既存のポリシーを選ぶか、ポリシーの選択肢 のいずれかを設定します。

6. Enable Access を選びます。

7. （任意）セッション期間を確認します。

   

8. Apply Access を選びます。

すべての Worker のプレビューデプロイだけを保護するには、all_preview_workers destination を使って self-hosted Access アプリケーションを作成します。

"destinations": [
  {
    "type": "all_preview_workers"
  }
]

すべての Worker の本番デプロイとプレビューデプロイを保護するには、代わりに all_workers を使います。

"destinations": [
  {
    "type": "all_workers"
  }
]

これらの destinations を POST /accounts/{account_id}/access/apps リクエストで送ります。完全なリクエストスキーマ（ポリシーの選択肢、セッション設定、高度な Access オプションを含む）は、Access applications API を参照してください。

1 つの Worker でサインインを必須にします。その Worker に関連するすべてのドメイン（ルート、カスタムドメイン、workers.dev ホスト名、プレビュー）が自動で保護されます。プレビューデプロイだけ、または本番とプレビューの両方でサインインを必須にできます。

ダッシュボードのパス: Workers & Pages > Worker を選択 > Access。

1. Cloudflare ダッシュボードで、Workers & Pages ページを開きます。

   Workers & Pages を開く ↗

2. アプリケーション一覧から Worker を選びます。

3. Access タブを選びます。

4. Protect this Worker behind Access を選びます。

5. Previews only または All traffic を選びます。

6. Authentication policy で、既存のポリシーを選ぶか、ポリシーの選択肢 のいずれかを設定します。

7. （任意）セッション期間を確認します。

   

8. Apply Access を選びます。

1 つの Worker のプレビューデプロイだけを保護するには、preview_worker destination を使って self-hosted Access アプリケーションを作成します。worker_id に Worker の ID を設定します。

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{
    "type": "self_hosted",
    "name": "Access for my-worker",
    "destinations": [
      {
        "type": "preview_worker",
        "worker_id": "c81a2d22c29840ed9d61681a3270dbff"
      }
    ],
    "policies": [
      {
        "decision": "allow",
        "include": [
          {
            "email_domain": {
              "domain": "example.com"
            }
          }
        ]
      }
    ]
  }'

Worker の本番デプロイとプレビューデプロイを保護するには、代わりに worker を使います。

"destinations": [
  {
    "type": "worker",
    "worker_id": "c81a2d22c29840ed9d61681a3270dbff"
  }
]

完全なリクエストスキーマ（ポリシーの選択肢 とセッション設定を含む）は、Access applications API を参照してください。

Worker にルーティングする特定の URL だけサインインを必須にしたい場合は、ホスト名ベースの Access を使います。対象は workers.dev ホスト名、カスタムドメイン、サブドメイン、パスなどです。ホスト名ベースの Access はその URL だけを保護します。Worker を保護する 場合は、アクセス方法に関係なく Worker 全体が保護されます。たとえばホスト名ベースの Access では、my-worker.example.workers.dev、admin.example.com、または example.com/login のような 1 つのパスだけを保護し、Worker の一部だけを非公開にできます。

ダッシュボードでも API でも、self-hosted アプリケーション を作成し、ホスト名またはパスをアプリケーションドメインとして指定して保護します。

アカウントレベルの Access ですべての Worker を保護している場合、Worker レベルのバイパスを追加して特定の Worker を公開できます。バイパスすると、その Worker では Access がサインインを求めません。

ダッシュボードのパス: Workers & Pages > Worker を選択 > Access。

1. Cloudflare ダッシュボードで、Workers & Pages ページを開きます。

   Workers & Pages を開く ↗

2. アプリケーション一覧から Worker を選びます。

3. Access タブを選びます。

4. Worker を公開する、またはアカウントレベルの Access をバイパスする選択肢を選びます。

5. 変更を確定します。

バイパスポリシー付きの Worker レベル Access アプリケーションを作成します。worker destination を使い、worker_id に Worker の ID を設定し、ポリシーの decision を bypass にして、全員に一致する include ルールを指定します。

"policies": [
  {
    "decision": "bypass",
    "include": [
      {
        "everyone": {}
      }
    ]
  }
]

Access をオンにするとき、サインインできる人を選びます。すべての Worker を保護する場合も、1 つの Worker を保護する場合も、同じポリシーの選択肢を使えます。

ポリシーは 1 つ以上追加できます。選んだいずれかのポリシーに一致する訪問者がサインインできます。

複数の ID プロバイダー、デバイスポスチャールール、サービストークン、複雑なポリシー順序、カスタムのログインページやブロックページなど、高度なポリシー設定は、作成後に Zero Trust で Access アプリケーションを編集します。選択肢の全体は Access policies を参照してください。

Cloudflare Access が Worker を直接呼び出すリクエストを認証すると、Worker は ctx.access からサインイン中のユーザーの識別情報（メール、グループ、デバイスポスチャ、その他の識別情報フィールド）を読めます。追加の設定や JWT のパースは不要です。

レスポンスのパーソナライズ、細かい権限の適用、ユーザー単位のアクティビティ記録に使います。

Access がリクエストを認証していない場合、ctx.access は undefined です。

export default {
	async fetch(request, env, ctx) {
		if (!ctx.access) {
			return new Response("Access required", { status: 403 });
		}

		const identity = await ctx.access.getIdentity();
		const email = identity?.email ?? "unknown";

		return new Response(`Hello, ${email}`);
	},
};

export default {
	async fetch(request, env, ctx) {
		if (!ctx.access) {
			return new Response("Access required", { status: 403 });
		}

		const identity = await ctx.access.getIdentity();
		const email = identity?.email ?? "unknown";

		return new Response(`Hello, ${email}`);
	},
};

wrangler dev または Cloudflare Vite Plugin でローカル開発するとき、デプロイや Access のログインフローなしで、認証済みの Cloudflare Access 識別情報をシミュレートできます。

wrangler.jsonc の access 設定内に dev ブロックを追加します。

{
	"access": {
		"dev": {
			"aud": "my-app",
			"identity": { "email": "[email protected]" }
		}
	}
}

[access.dev]
aud = "my-app"

  [access.dev.identity]
  email = "[email protected]"

• aud（必須） — Access アプリケーションの audience タグです。ctx.access.aud として利用できます。これがないと Wrangler は起動しません。
• identity（任意） — ctx.access.getIdentity() が返す、認証済みユーザーの識別情報クレーム（メール、名前、グループなど）をシミュレートします。Worker がユーザー識別情報を読む場合は含めます。Access が有効かどうかだけを確認する場合は省略します。

別のユーザーとしてテストするには、識別情報フィールドを変えて再起動します。未認証のリクエストをテストするには、dev ブロックを削除します。ctx.access は undefined になり、本番で Access を経由しなかったリクエストと同じになります。

export default {
	async fetch(request, env, ctx) {
		if (!ctx.access) {
			return new Response("Not authenticated", { status: 403 });
		}

		const identity = await ctx.access.getIdentity();
		const email = identity?.email ?? "unknown";

		return new Response(`Hello, ${email}`);
	},
};

export default {
	async fetch(request, env, ctx) {
		if (!ctx.access) {
			return new Response("Not authenticated", { status: 403 });
		}

		const identity = await ctx.access.getIdentity();
		const email = identity?.email ?? "unknown";

		return new Response(`Hello, ${email}`);
	},
};

この設定では、localhost:8787 にアクセスすると Hello, [email protected] が返ります。

識別情報オブジェクトには、本番の Access 識別情報の形に一致する任意のフィールドを指定できます。一覧は Application token — User identity を参照してください。

1 つの Worker を複数の Access ルールが保護することがあります。同じリクエストに複数のルールが当てはまる場合、より具体的なルールが先に適用されます。

1. ホスト名またはパスベースの Access: リクエストがそのホスト名またはパス（admin.example.com や example.com/login など）に一致する場合、最初に適用されます。
2. Worker レベルの Access: 次に、選んだ Worker のルート、カスタムドメイン、workers.dev ホスト名、プレビュー全体に適用されます。
3. アカウントレベルの Worker Access: 最後に、アカウント上のすべての Worker、またはすべての Worker プレビュー向けのフォールバックとして適用されます。

たとえば、Worker にアカウントレベルの Access と Worker レベルのルールの両方がある場合、その Worker は Worker レベルのルールが制御します。一致するホスト名またはパスベースの Access アプリもある場合は、そのホスト名またはパスのルールが一致する URL を制御します。

より具体的なルールを削除すると、より広いルールがその Worker を保護したままになることがあります。たとえば Worker レベルの Access を削除すると、その下にあるアカウントレベルの Access が表面化します。

• Access applications API
• Access policies
• Self-hosted Access applications
• Routes and domains
• Preview URLs