外部認可とサーバーレスコンピューティングで ZTNA を拡張する

はじめに

Zero Trust Network Access（ZTNA）サービスを使う企業は、社内ホストの Wiki サーバーやソースコードリポジトリなど、保護対象リソースへユーザーがアクセスできるかを決めるポリシーを作ります。ポリシーでは通常、グループメンバーシップ、認証方式、デバイスのセキュリティポスチャを使い、どのユーザーがどのリソースにアクセスできるかを決めます。

安全なアクセスには、ポリシーエンジンが評価できる属性が幅広く必要です。Cloudflare の ZTNA サービスである Access では、アクセス判定に必要なデータの一部を提供する別 API への外部リクエストを、ポリシーに含められます。

たとえば、「Engineers」グループのメンバーで、ハードトークンが必要な資格情報で認証したユーザーだけが、セルフホストのソースコードリポジトリにアクセスできる、というポリシーがあるとします。さらに、セキュリティ研修を修了したエンジニアだけに限定したい場合もあります。そのデータは別システムにあることがあります。そのため Cloudflare では、ポリシーチェックの一部として Workers ↗ から研修システムへ呼び出し、そのユーザーがセキュリティ研修に合格しているかを確認できます。

加えて、認証とポリシーチェックが成功すると、Cloudflare は保護対象オリジンへトラフィックを渡します。不正なアクセスを避けるため、オリジン側でも、受信リクエストが Cloudflare によって認証済みであることを検証してください。Cloudflare は、認証が成功したことを暗号的に証明する JWT トークンを、オリジン向けトラフィックに挿入します。オリジンはこのデータを、自前の認可ロジックの一部として使えます。

こうしたユースケースの統合を助けるため、Cloudflare には自前のビジネスロジックを設計して実行できる開発プラットフォームがあります。部品を組み合わせる時間を減らし、統合そのものに時間を使えます。

このドキュメントでは、両方のソリューションを組み合わせて、Cloudflare Access の認可と認証 ↗ の能力を強化する方法を説明します。

紹介する製品

Workers

サーバーレスアプリケーションを構築し、すぐ世界中へデプロイできます。性能、信頼性、スケールに優れています。

Access

Cloudflare Zero Trust は、従来のセキュリティ境界を Cloudflare のグローバルネットワークへ置き換え、世界中のチームにとってインターネットをより速く、より安全にします

ユースケース

カスタム認可ロジック: Workers をバックエンドにした Access の External evaluation（例: 自前の Open Policy Agent（OPA） ↗ 実装）
拡張した JSON Web Token（JWT）: Cloudflare 自身の認証 JWT を使い、受信リクエストにポスチャ情報を追加するなど。
Zero Trust で保護したサーバーレス拡張アプリ: サーバーレスアプリケーションを作るだれもが、ネイティブの ZTNA 機能を使えるようにします

図 1: プライベートリソースへのリクエストと、認可（AuthZ）と認証（AuthN）向けに Access をカスタマイズできる箇所

始める

組織は自前のビジネスロジックを実行し、ほぼあらゆる要件に合わせて認証と認可を調整できます。次の各ユースケースは、上の図のステップに対応します。

1. 独自ルールによるカスタム認可

ポリシー評価中、external evaluation ルールを使うと、アクセスポリシー評価のあいだに自前のコードを実行できます。この例では、Cloudflare Workers が公開する API が、リクエストを出しているユーザーのデータ（特にユーザー名）を受け取ります。

コードは通常、データベースまたは別 API を呼び出し、渡されたユーザー名がそのアプリケーションへアクセスできるかを評価します。external evaluation ルールでは、呼び出しが True または False を返す必要があります。この結果をポリシーと組み合わせて、アクセスを判定します。

詳細

Cloudflare の external evaluation 機能による外部認可

2. 認証情報（JWT）を分析して検証する

ユーザーが認証に成功し、保護対象アプリケーションへのアクセスが認可されると、Cloudflare はオリジンへ送る HTTP トラフィックに JSON Web Token（JWT）を挿入します。このトークンは、安全な処理を通じてカスタムビジネスロジックを広げるための材料になります。JWT の形式は決まっており、オリジンへのリクエストを不必要に大きくしないよう軽量です。

オリジンへ送られる JWT の例です（JWT の内容を読むには JWT.io ↗ を使います）

JWT contentjson

{
	"aud": ["264063895705477af73bfbaed1bf401981f4812eefcdb9fea33f5e10e666e282"],
	"email": "john.doe@cloudflare.com",
	"exp": 1728551137,
	"iat": 1728464737,
	"nbf": 1728464737,
	"iss": "https://myorg.cloudflareaccess.com",
	"type": "app",
	"identity_nonce": "IA0hPRvwILtbUXSQ",
	"sub": "ce40d564-c72f-475f-a9b8-f395f19ad986",
	"device_id": "8469d7c4-83a9-11ee-b559-76e6e80876db",
	"country": "FR"
}

Cloudflare は、Cloudflare が署名した JWT を検証して展開できる専用のエンドポイントを公開しています。

Cloudflare の Workers は、受信した JSON Web Token（JWT）を扱うのに適しています。サーバーレスプラットフォーム内で追加処理ができ、遅延も増えません。

詳細

Cloudflare Access の JWT を検証し、内容を確認する方法

3. 認証情報（JWT）に追加の認証詳細を加える

保護対象の宛先アプリケーションで追加処理を行うため、この JWT を拡張するとよい場合があります（例: 受信リクエストにデバイスのポスチャ情報を追加する）。

次の例では、公開しているアプリケーションが、デバイスのファイアウォールとディスク暗号化の状態を把握できるようにします（これらのシグナルを収集するには、クライアント機に Cloudflare One Client をインストールする必要があります）。

JSON Web Token（JWT）を展開すると、紐づく認証イベントの詳細が見えます。展開すると、JWT 本体にデフォルトで含まれる情報より多くの情報が分かります。例は次のとおりです。

Expanded JWTjson

{
  "id": "P51Tuu01fWHMBjIBvrCK1lK-eUDWs2aQMv03WDqT5oY",
  "name": "John Doe",
  "email": "john.doe@cloudflare.com",
  "amr": [
    "pwd"
  ],
  "oidc_fields": {
    "principalName": "john.doe_cloudflare.com#EXT#@XXXXXXcloudflare.onmicrosoft.com"
  },
  "groups": [
    {
      "id": "fdaedb59-e9be-4ab7-8001-3e069da54185",
      "name": "Security Team"
    }
  ],
  "idp": {
    "id": "b9f4d68e-dac1-48b0-b728-ae05a5f0d4b2",
    "type": "azureAD"
  },
  "geo": {
    "country": "FR"
  },
  "user_uuid": "ce40d564-c72f-475f-a9b8-f395f19ad986",
  "account_id": "121287a0c6e6260ec930655e6b39a3a8",
  "iat": 1724056537,
  "devicePosture": {
    "f6f9391e-6776-4878-9c60-0cc807dc7dc8": {
      "id": "f6f9391e-6776-4878-9c60-0cc807dc7dc8",
      "schedule": "5m",
      "timestamp": "2024-08-19T08:31:59.274Z",
      "description": "",
      "type": "disk_encryption",
      "check": {
        "drives": {
          "C": {
            "encrypted": true
          }
        }
      },
      "success": false,
      "rule_name": "Disk Encryption - Windows",
      "input": {
        "requireAll": true,
        "checkDisks": []
    },
    "a0a8e83d-be75-4aa6-bfa0-5791da6e9186": {
      "id": "a0a8e83d-be75-4aa6-bfa0-5791da6e9186",
      "schedule": "5m",
      "timestamp": "2024-08-19T08:31:59.274Z",
      "description": "",
      "type": "firewall",
      "check": {
        "firewall": false
      },
      "success": false,
      "rule_name": "Local Firewall Check - Windows",
      "input": {
        "enabled": true
      }
    }
    ...
  }

JWT 内の詳細を使い、Worker でデバイスポスチャの情報を取り出し、アプリケーションが自前の認可ロジックに使う HTTP ヘッダーへ再挿入できます。このリクエスト変更を Cloudflare Developer Platform で行う手順は、次のチュートリアルを参照してください。

チュートリアル

Cloudflare Workers で Cloudflare Access の JWT を拡張する方法