Cloudflareが、ウェブトラフィックを検査するセキュリティゲートウェイに顧客作成のコードを接続する。セキュリティチームは許可・ブロックのルールを選ぶだけでなく、リクエストを直接加工したり、機密情報が実際に有効か確認するロジックを組み込んだりできる。組織固有の要件を満たすために別途プロキシを運用していた負担を減らす変化だ。
1. トラフィック加工と検知検証では公開時期が異なる
2026年10月15日の発表で、トラフィックをコードに送るForwardアクションが公開ベータとしてリリースされた。ポリシー条件を計算するCustom Functionは2026年末までに提供する予定だ。両機能は正式リリース時にすべての料金プランで提供する計画だ。
これとは別に、データ損失防止であるDLPのカスタム検証関数は発表当日から提供される。ポリシー条件を作る機能と検知結果を検証する機能では、提供時期を区別する必要がある。
2. リクエストを変更するか判断材料を作るかを選ぶ
Forwardはウェブリクエストポリシーで許可されたトラフィックに適用され、最初に一致した転送ルールがリクエストを接続先のWorkerに送る。Workerはリクエストのヘッダーと本文を受け取って変更し、オリジンサーバーのレスポンスも変更できる。リクエストを変更せず、通知などの非同期処理だけを実行する用途にも使える。
一方、Custom Functionはポリシー評価中に実行され、文字列・数値・論理値を返す。リクエストを修正する作業台ではなく、判断に使う値を作る計算機のようなものだ。戻り値はポリシーエディターでほかの条件とともに比較する。
関数が受け取る情報はポリシーの段階によって異なる。ユーザーの身元や端末のセキュリティ状態、接続情報を活用するため、HTTPに限らず、ネットワークポリシーの任意のポートやプロトコルにも適用できる。
3. ロール情報をポリシー条件として返す
以下は原文で示されたカスタム関数だ。リクエストの認証ヘッダーからトークンをデコードし、最初のグループ値を返す。この値を許可ルールの条件に使えるが、この例ではトークンの署名検証手順は示されていない。
export class GatewayCustomSelector extends WorkerEntrypoint {
async compute(ctx: GatewayContext): Promise<string> {
const authHeader = ctx.request.headers.get("Authorization");
if (!authHeader) return "anonymous";
const token = authHeader.replace("Bearer ", "");
const payload = JSON.parse(atob(token.split(".")[1]));
return payload.groups?.[0] ?? "unknown";
}
}別の活用例は、機密性の高い接続先にアクセスする際に理由の入力画面を表示することだ。入力の有無を有効期限付きのストレージに記録し、設定した期間ごとに一度だけ尋ねる。ユーザーと理由はデータベースに残し、監査記録として活用する。
4. パターン一致後に実際の有効性を確認する
DLPの正規表現・単語リストによる検知は機密情報に似たパターンを見つけるが、そのデータが実際の漏えいや悪用に関係するかまでは分からない。完全一致するデータを探す方式にも、顧客が基準データセットを準備・維持・転送する負担がある。
カスタム検証関数は、検知項目が一致した後、ポリシーを適用する前に顧客の検証ロジックを実行する。例えばGitHubのシークレットを検知した場合、そのキーの状態を照会し、有効なキーかどうかに応じて検知の一致を判断できる。パターン検査の後に、実際に使える鍵かを確認する段階を追加する方式だ。
5. インフラの負担は減り、コード設計の責任は残る
Gatewayが接続・暗号化・証明書管理を担うため、顧客のコードは変換ロジックに集中できる。一方、リアルタイムのリクエストを加工するコードは、ユーザー体験を損なわないよう対象を絞って設計する必要がある。カスタムポリシー関数は高速で範囲を限定したステートレス評価に適しており、失敗時の代替動作を関数ごとに定め、デフォルトの戻り値を指定する必要がある。
Cloudflareは、ゲートウェイとコード実行サービスが同じ機器で動作するため、呼び出しに追加のネットワーク区間はなく、性能への影響はコードの実行時間に限られると説明している。具体的な遅延の測定値は示されていない。
転送されたトラフィックは標準のWorkersリクエストとして課金される。無料プランも使えるが、実行時間と日次のリクエスト数に上限があるため、処理量を増やす際には考慮する必要がある。
今回の変化の価値は、別途運用するプロキシを減らしつつ組織固有の判断をセキュリティポリシーに組み込める点にあり、その代償は顧客コードの設計と実行コストだ。
