Cloudflare Zero Trustとは？一般的な構成と基本設計

Cloudflare Zero Trustとは

Cloudflare Zero Trustは、ユーザーや端末から社内アプリケーション、SaaS、インターネットへのアクセスを、クラウド上のポリシーで制御するための仕組みです。

従来の「社内ネットワークに接続していれば一定程度信頼する」という考え方ではなく、アクセスのたびにユーザーや端末の条件を確認し、必要なリソースだけへ接続させる設計を取りやすくなります。

POINT 01Identityを確認

IdPと連携し、誰がアクセスしているのかを確認します。

POINT 02Deviceを確認

管理端末、OS、暗号化、セキュリティ状態などを条件にできます。

POINT 03通信先を制御

社内アプリだけでなく、インターネット向け通信にもポリシーを適用できます。

従来のVPN・ファイアウォールとの違い

項目	従来型VPN / Firewall	Zero Trust構成
信頼の基準	接続元ネットワークやVPN接続を重視	Identity、Device、Applicationなど複数条件
社内アプリへの接続	VPNで社内ネットワークへ接続後にアクセス	対象アプリ単位で認証・認可
端末条件	VPN装置や別製品で確認する場合がある	Device Postureをアクセス条件へ組み込み可能
Internet制御	拠点FirewallやProxyを経由	Secure Web Gatewayでユーザー単位の制御が可能

考え方のポイント：Zero TrustはVPNやFirewallを単純に「置き換える製品名」ではありません。ユーザー、端末、アプリケーション、通信を継続的に確認し、必要最小限のアクセスにするための設計思想です。

一般的な企業向け構成

一般的な構成では、企業端末へCloudflare One Clientを導入し、ユーザー認証にはMicrosoft Entra ID、Okta、Google WorkspaceなどのIdentity Providerを利用します。社内WebアプリはCloudflare Accessで保護し、インターネット向け通信はGatewayで制御します。

USER / DEVICEUser
Managed Device

CLOUDFLAREOne Client / Access
Posture / Gateway

RESOURCEPrivate App
SaaS / Internet

IDENTITYIdentity Provider

ユーザー認証とグループ情報をAccessやGatewayのポリシー条件に利用します。

DEVICECloudflare One Client

端末からCloudflareへ通信を送り、WARP / Gateway接続やDevice Postureの判定に利用します。

APPLICATIONCloudflare Access

社内Webアプリなどに対して、ユーザーと端末条件を満たすアクセスだけを許可します。

INTERNETCloudflare Gateway

DNS、HTTP、Network Policyを使ってインターネット向け通信を制御します。

Identity Providerによるユーザー認証

最初に重要になるのが「誰がアクセスしているか」を確認する仕組みです。Cloudflare Accessでは、既存のIdentity Providerと連携してユーザーを認証し、メールアドレス、グループ、認証方式などをアクセス条件に利用できます。

POLICY EXAMPLE — IDENTITY

Action: Allow

Include:
  Email domain = @example.com

Require:
  Identity Provider = Corporate IdP

企業で既にMicrosoft Entra IDなどを利用している場合は、新しいユーザー管理基盤を別に作るのではなく、既存のIdentity Providerと連携する構成が一般的です。

Cloudflare One ClientとWARP

管理端末へCloudflare One Clientを導入すると、端末からの通信をCloudflare Zero Trustへ送ることができます。これにより、ユーザー単位のGateway PolicyやDevice Postureを利用しやすくなります。

Cloudflareのポリシーでは、WARPに接続しているか、組織のGateway経由で接続しているかといった条件もAccess Policyへ組み込めます。

POLICY EXAMPLE — CLIENT REQUIREMENT

Action: Allow

Include:
  Group = Employees

Require:
  Gateway = Connected
  Device Posture = Corporate Device

Device Postureで端末状態を確認する

ユーザー認証だけでは、同じアカウントを使って私物端末からアクセスされる可能性があります。Device Postureを利用すると、端末が企業のセキュリティ要件を満たしているかをAccess PolicyやGateway Policyの条件にできます。

対応OS・OSバージョン
Disk Encryptionの状態
Antivirus / Endpoint Securityの状態
Cloudflare One Client / Gateway接続状態
端末証明書やSerial Numberなどの管理端末判定

設計上のポイント：最初から多数のPosture条件を必須にすると、端末側の判定失敗で業務へ影響することがあります。まず1〜2項目から検証し、許可・拒否双方の動作を確認してから条件を追加する方が安全です。

Cloudflare Accessで社内アプリを保護する

Cloudflare Accessは、社内Webアプリケーションなどへのアクセスを認証・認可するZTNAの機能です。Access PolicyではAction、Include、Require、Excludeなどを組み合わせて条件を作ります。

POLICY EXAMPLE — PRIVATE APPLICATION

Application:
  internal.example.com

Action:
  Allow

Include:
  Group = Employees

Require:
  Gateway = Connected
  Device Posture = Managed Windows

All other access:
  Block

この例では、社員グループに所属し、かつ企業のGatewayへ接続しており、管理端末のPosture条件を満たすユーザーだけが社内アプリへアクセスできます。

Gatewayでインターネット通信を制御する

Cloudflare GatewayはSecure Web Gatewayとして、ユーザーや端末からインターネットへ向かう通信へポリシーを適用します。DNS、HTTP、Network Policyを用途に応じて使い分けます。

DNS Policy

DNS Policyは名前解決の段階でドメインを評価します。Security CategoriesやContent Categoriesを使い、マルウェア、フィッシング、不適切なカテゴリなどをブロックする構成が考えられます。

POLICY EXAMPLE — DNS SECURITY

Action: Block

Selector:
  Security Categories

Categories:
  Malware
  Phishing
  Command and Control

HTTP / Network Policy

より細かい制御が必要な場合はHTTP PolicyやNetwork Policyを利用します。URL、Application、Destination IP、Port、Protocol、User Identity、Device Postureなどを条件にできます。

Split Tunnelを設計する

Cloudflare One Clientを導入したからといって、すべての通信を必ず同じ経路へ流す必要はありません。通信特性や既存ネットワークとの関係から、Cloudflare経由にする通信と除外する通信をSplit Tunnelで設計できます。

Cloudflare経由にする通信の範囲を明確にする
除外が必要なSaaSやリアルタイム通信を確認する
除外理由を記録し、不要な例外を増やさない
変更後は名前解決・Web・Private Accessを個別に確認する

Split Tunnelは「通信できないから除外する」という運用にすると例外が増え続けます。サービス要件とセキュリティ要件を確認した上で設計することが重要です。

Default Denyの考え方

社内アプリやプライベートネットワークへのアクセスでは、「必要なアクセスだけ許可し、それ以外は拒否する」考え方が基本になります。

POLICY MODEL — DEFAULT DENY

01 Allow
   Employees
   + Managed Device
   + Gateway Connected
   -> Internal Application

99 Block
   All other access

ただし、GatewayのDNS / HTTP / Network Policyはそれぞれ評価方法や目的が異なります。単純にすべての通信を一括でDefault Denyにするのではなく、保護対象と通信要件を整理し、段階的に適用します。

ログと監視

Zero Trustでは、許可できたことだけでなく「なぜ拒否されたか」を確認できることも重要です。AccessやGatewayのログを確認することで、Identity、Device Posture、Destination、Actionなどの観点から通信を追跡できます。

ACCESS認証・認可ログ

誰がどのアプリへアクセスし、ポリシーで許可・拒否されたかを確認します。

GATEWAY通信ログ

DNS、HTTP、Network通信がどのPolicyにマッチしたかを確認します。

DEVICEPosture状態

どの端末条件がPass / Failになっているかを確認します。

OPERATIONS変更後の検証

Allowケースだけでなく、意図したBlockが機能していることも確認します。

導入は小さな範囲から始める

Zero Trustは機能を一度にすべて導入する必要はありません。最初は影響範囲が明確な社内Webアプリなどから開始し、認証、端末条件、ログ確認の一連の流れを検証する方法が現実的です。

Identity Providerを接続する
検証用の社内Webアプリを1つAccessで保護する
少数端末へCloudflare One Clientを導入する
WARP / Gateway接続を条件に追加する
Device Postureを1〜2項目から追加する
DNS Security Policyを追加する
Allow / Block / Logを確認して対象を広げる

まとめ

Cloudflare Zero Trustでは、Identity Provider、Cloudflare One Client、Access、Device Posture、Gatewayなどを組み合わせ、ユーザーと端末の状態に応じてアクセスを制御できます。

重要なのは、単に製品機能を有効化することではなく、「誰が、どの端末から、どのリソースへ、どの条件でアクセスできるか」を先に設計することです。

ネットワーク基礎シリーズで扱ったSwitch、Router、Firewallの境界制御に加えて、ユーザーと端末を中心にアクセス制御を考えることで、クラウド利用やリモートアクセスを前提としたネットワーク設計へ発展させることができます。

参考情報

本記事は、Cloudflareの公式ドキュメントおよびReference Architectureを参照し、一般的な企業向け構成として整理しています。画面名称、機能、対応条件は変更される可能性があるため、実際の導入時は最新の公式ドキュメントを確認してください。