Cloudflare Zero Trustへの移行は、2026年に古くなった企業VPNの置き換えを目指すエンタープライズにとって、不可欠なセキュリティ近代化のステップです。従来のVPNネットワークは、最初のログイン壁を通過すると企業サブネット全体への広範なアクセスをユーザーに許可してしまうため、従業員の認証情報が1つ盗まれるだけで、攻撃者は機密性の高いデータベースサーバーに直接アクセスできるようになります。対照的に、Zero Trustアーキテクチャはすべてのアプリケーション要求に対して認可チェックを評価し、未検証のトラフィックをデフォルトでブロックします。このガイドでは、Zero Trust環境を構築するために使用される設定ステージ、セキュアトンネルの設定、およびポリシーの定義について解説します。

[!WARNING] VPNの脆弱性に関する警告： レガシーなVPN設定は、内部ネットワークを横方向の移動攻撃（ラテラルムーブメント）にさらします。エッジで検証されたアクセスルートにアップグレードすることで、従業員のローカルPCが侵害された場合でも、データベースを隔離された状態に維持できます。

主なポイント：

  • Cloudflare Zero Trustは、エッジアクセスポリシーを使用してユーザーIDとデバイスの健全性チェックを評価します。
  • 軽量なCloudflare Tunnelsは、インバウンドのファイアウォール設定を開くことなくサーバーポートを保護します。
  • 標準ポリシーは、IDプロバイダー統合（Google WorkspaceやOktaなど）をサポートしています。
  • ポスチャー検証は、データベースへのアクセスを認可する前に、デバイスの暗号化とウイルス対策の状態をチェックします。

Cloudflare Zero Trust設定のコアとなる3つの柱

プロフェッショナルなセキュリティアーキテクチャは、ユーザーとデバイスを継続的に検証することに依存しています。Cloudflare Oneの技術文書 が説明しているように、アクセスポリシーは中央のVPNコンセントレーターではなく、ユーザーに近いエッジで、リクエストごとに評価されます。この設定はデータベースへのアクセスを保護するために、3つの異なるセキュリティの柱に依存しています。

1. Cloudflare Access（ID検証）

Cloudflare Accessは、エッジネイティブなIDブローカーとして機能します。その結果、次の3つの主要なルールを設定する必要があります。

  • IDプロバイダーの同期： 会社のディレクトリ（Okta、Microsoft Entra ID、Google Workspaceなど）をエッジに直接接続します。
  • アクセスポリシー： メール ドメイン、地理的場所、および多要素認証（MFA）ステータスに基づいて、きめ細かなルールを構築します。これにより、不正な要求を効果的にフィルタリングできます。
  • 即時取り消し： 中央ディレクトリでユーザープロファイルを無効にすると、世界中のエッジセッションが即座に終了し、システムの入り口が安全に保たれます。

2. Cloudflare Tunnel（cloudflaredコネクタ）

従来のインフラでは、サーバーポート80または443をパブリックインターネットに公開する必要があり、サービスがポートスキャンのボットネットにさらされていました。

  • アウトバウンド接続： オリジンサーバーで軽量なデーモン（cloudflared）を実行し、Cloudflareエッジへの送信専用の接続を確立します。
  • インバウンドの開放ポートなし： その結果、ローカルファイアウォールのすべての受信ポートを閉じることができ、パブリックインターネットのスキャンからサーバーを不可視にできます。

3. デバイスポスチャー検証（WARPクライアント）

機密性の高いデータベースをマルウェア感染から保護するために、エッジはデバイスの安全性を検証する必要があります。そのため、WARPエージェントは3つのポスチャー検証チェックを実行します。

  • ウイルス対策の検証： アクセスを許可する前に、ユーザーのPCでアクティブなエンドポイントセキュリティソフトウェアが実行されていることを確認します。これにより、マルウェアの実行を防ぎます。
  • OSアップデートのチェック： 従業員のデバイスが、重要なセキュリティアップデートを欠いた古いOSを実行している場合、アクセスを制限します。これにより、ファームウェアの脆弱性のリスクを軽減します。
  • ディスク暗号化のチェック： クライアントマシンでFileVaultまたはBitLocker暗号化がアクティブであることを検証します。これにより、デバイスの紛失によるデータ漏洩を防ぎます。

エンタープライズ向けの導入手順

日常の業務フローを妨げることなく、スムーズに移行を進めるには、以下の手順に従います。

  1. ID統合の確立： 会社のメールディレクトリをCloudflareダッシュボードに同期します。
  2. Cloudflare Tunnelsの展開： ターゲットとなるステージングおよび本番サーバーにcloudflaredコネクタをインストールします。
  3. 詳細なアクセスポリシーの策定： 管理コンソールを特定の開発者のメールアドレスのみに制限するアクセスルールを設定します。
  4. WARPクライアントの配布： デバイス管理ツールを使用して、すべての社用PCにエッジクライアントをインストールし、ポスチャーチェックを有効にします。

技術的な比較：従来のVPN vs. Zero Trust

運用の指標を評価すると、なぜ企業がエッジネイティブなセキュリティアーキテクチャに移行しているのかが明確になります。

セキュリティ指標従来の企業VPNCloudflare Zero Trust
アクセス権限ネットワークサブネット全体への広範なアクセス。ポリシーによって制限されたアプリケーション特定のアクセス。
ファイアウォール設定受信ポートを開く必要があり、攻撃対象領域を作ります。送信専用のトンネルにより、サーバーポートを閉じたままにします。
ユーザー体験ルーティング遅延が大きく、手動ログインが必要です。シングルサインオン（SSO）統合とエッジルーティング。
デバイス検証自動化されたデバイスポスチャー検証はありません。ディスク暗号化やOSパッチの継続的なチェック。

開始する前の前提条件

設定を始める前に、以下の項目が揃っていることを確認してください。前提条件の不足は、導入が途中でストップする最も一般的な原因です。

  • Zero Trustが有効化されたCloudflareアカウント。 無料プランは最大50シートをカバーしており、パイロット運用には十分です。チームドメイン（例：your-org.cloudflareaccess.com）をメモしておきます。
  • Cloudflareに登録済みのドメイン。 保護する予定の各パブリックホスト名（例：app.example.com）は、Cloudflareのネームサーバーを使用するゾーンに配置されている必要があります。これにより、DNSレコードが自動的に作成されます。
  • IDプロバイダー（IdP）の管理権限。 Okta、Microsoft Entra ID、またはGoogle Workspaceで、CloudflareをSAMLまたはOIDCアプリケーションとして登録します。
  • Originサーバーのrootまたはsudo権限。 cloudflared コネクタを実行するすべてのサーバーで必要になります。
  • アプリケーション一覧の作成。 各内部サービス、そのローカルアドレスとポート、およびアクセスすべき対象者をリストアップします。この一覧がポリシーの設計図になります。

ステップバイステップ：Cloudflare AccessとTunnelの設定

ダッシュボードのみの手順では、本番環境で重要となる詳細が見えにくくなります。以下の手順では、設定を再現可能にし、バージョン管理にコミットできるようにコマンドラインを使用します。

1. cloudflaredのインストールと認証

オリジンサーバーにコネクタをインストールし、アカウントに対して認証します。ログインコマンドを実行するとブラウザウィンドウが開き、そこでゾーンを承認します。

1# Debian / Ubuntu
2curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
3sudo dpkg -i cloudflared.deb
4
5# Authenticate — writes a cert.pem to ~/.cloudflared/
6cloudflared tunnel login

2. トンネルとその認証情報の作成

トンネルを作成すると、UUIDが出力され、対応する認証情報ファイルが ~/.cloudflared/ に書き込まれます。このファイルはコネクタのIDとなるため、厳重に保管してください。

1cloudflared tunnel create enterprise-apps
2# Created tunnel enterprise-apps with id 6ff42ae2-765d-4adf-8112-31c55c1551ef

3. config.ymlでのイングレスルールの定義

このイングレスリストは、各パブリックホスト名をファイアウォール背後のプライベートサービスにマッピングします。

 1tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
 2credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
 3
 4ingress:
 5  # Internal admin console
 6  - hostname: db-admin.example.com
 7    service: http://localhost:9000
 8  # Internal web app
 9  - hostname: app.example.com
10    service: http://localhost:8080
11  # Catch-all — required as the final rule
12  - service: http_status:404

末尾のキャッチオールルールは必須です。これがないと、cloudflared は起動しません。

4. DNSのルーティングとサービスとしてのトンネルの実行

1# Create a proxied CNAME for each hostname
2cloudflared tunnel route dns enterprise-apps db-admin.example.com
3cloudflared tunnel route dns enterprise-apps app.example.com
4
5# Install as a persistent system service so it survives reboots
6sudo cloudflared service install
7sudo systemctl enable --now cloudflared

これでオリジンにはインバウンドポートが開いていませんが、両方のホスト名はエッジを通じて安全に解決されます。

5. 自己ホスト型Accessアプリケーションとポリシーの作成

トンネルが有効になったら、各ホスト名の前にAccessポリシーを配置します。以下のTerraformコード例は、管理コンソールを特定のディレクトリグループに制限し、健全なデバイスポスチャーを要求します。

 1resource "cloudflare_zero_trust_access_application" "db_admin" {
 2  zone_id          = var.zone_id
 3  name             = "Database Admin Console"
 4  domain           = "db-admin.example.com"
 5  session_duration = "30m"
 6}
 7
 8resource "cloudflare_zero_trust_access_policy" "db_admin_engineers" {
 9  application_id = cloudflare_zero_trust_access_application.db_admin.id
10  zone_id        = var.zone_id
11  name           = "Engineers with healthy devices"
12  precedence     = 1
13  decision       = "allow"
14
15  include {
16    group = [var.engineering_group_id]
17  }
18
19  require {
20    device_posture = [cloudflare_zero_trust_device_posture_rule.disk_encryption.id]
21  }
22}

include ブロックは誰がアクセスを試行できるかを決定し、require ブロックは全員が満たすべき条件を追加します。そのため、許可されたエンジニアであっても、暗号化されていないPCからはアクセスが拒否されます。

6. WARPへのデバイス登録とポスチャールールの追加

デバイスポスチャーチェックは、WARPクライアントがチームに登録されている場合にのみ機能します。上記のルールは、エッジがアクセスを許可する前にディスク暗号化が有効であることを確認します。

 1resource "cloudflare_zero_trust_device_posture_rule" "disk_encryption" {
 2  account_id = var.account_id
 3  name       = "Disk encryption required"
 4  type       = "disk_encryption"
 5
 6  match {
 7    platform = "windows"
 8  }
 9
10  input {
11    require_all = true
12  }
13}

組織名を事前に入力した状態でMDM（Intune、Jamf、Kandjiなど）を介してWARPを配布し、ユーザーにプロンプトを表示することなく、社用PCがバックグラウンドで自動登録されるようにします。

VPNからZero Trustへの移行チェックリスト

並行運用による移行では、アプリケーションを1つずつ移行する間も、レガシーVPNを利用可能な状態に維持します。これにより影響を最小限に抑え、各ステップでロールバックパスを確保できます。

フェーズアクション完了条件
1. アプリ棚卸しVPN経由でアクセス可能なすべてのアプリ、ポート、ユーザーグループをカタログ化完全なアプリケーション宛先マップの完成
2. パイロット運用リスクの低い内部アプリを1つ、AccessとTunnelの保護下に移行パイロットグループがVPNなしでそのアプリに到達可能
3. ID同期IdPを接続し、MFAを強制し、ディレクトリグループをポリシーにマッピングSSOが動作し、グループベースのルールが適用
4. デバイス状態確認パイロットデバイスにWARPを展開。暗号化とOSチェックを「レポートのみ」で有効化ユーザーをブロックすることなくポスチャーデータが収集されること
5. 移行拡大残りのアプリを優先度順に移行し、アクセスポリシーを厳格化すべてのアプリがエッジ経由で応答
6. 旧設備廃止VPNルートの削除、ファイアウォール受信ポートの閉鎖、VPN証明書の失効VPNコンセントレータの電源を安全にオフにできる状態

よくある落とし穴とトラブルシューティング

  • エラー 1033 (トンネルエラー)： ホスト名は解決されますが、コネクタが実行されていないか、DNSレコードが間違ったトンネルを指しています。systemctl status cloudflared をチェックし、CNAMEのターゲットがトンネルのUUIDと一致していることを確認します。
  • コネクタが起動しない： すべての ingress リストは、service: http_status:404 のような末尾のキャッチオールルールで終わる必要があります。これがないと、デーモンが起動する前に設定の検証が失敗します。
  • ユーザーがAccessをバイパスしてオリジンに直接アクセスする： Accessは生のIPアドレスではなく、ホスト名を保護します。トンネルは受信ポートを閉じたままにするため、古いパブリックDNSレコードや開放ポートがオリジンを露出させていないことを確認してください。
  • 管理者自身が管理アプリからロックアウトされる： ポリシーをレポートのみから強制（Enforced）に変更する前に、必ず緊急アクセス用（Break-glass）のアカウントに対して許可ポリシーを作成しておいてください。
  • ポスチャーチェックがパスしない： ポスチャーチェックには、WARPクライアントがDNS専用モードではなく、Zero Trustモードで実行されている必要があります。各デバイスが正しいチーム名で登録されていることを確認してください。

テストと段階的な展開

実際のトラフィックをブロックする前に、各ポリシーを検証します。

  • ポリシーテスターの使用： Accessポリシーテスターは、特定のユーザーをシミュレートし、実際のアクセス要求を待つことなく、許可または拒否の判定ロジックを表示します。
  • レポートのみモードからの開始： 新しいポリシーやポスチャールールは、実際のブロックを行うことなく結果をログに記録できるため、ユーザーがロックアウトされる前に誤検知を特定できます。
  • 意思決定ログの確認： Zero Trustダッシュボードは、ID、デバイス、および適用されたポリシーとともにすべてのAccess決定を記録します。これは「なぜブロックされたのか」を突き止める最速の方法です。
  • ロールバックパスの確保： アクセス障害なしで通常の1週間が経過するまでは、パイロットグループに対してVPNを利用可能な状態にしておき、その後上記のチェックリストに従って廃止します。

セキュリティコンサルタントとの連携

計画的な導入が、会社のデジタル資産を保護します。Mecanikは、プロフェッショナルなサーバーセキュリティ監査 サービス、および当社のペネトレーションテストサービス ページを通じた高度なネットワーク要塞化を提供しています。当社は、Cloudflare Tunnelsのセットアップ、Zero Trustアクセスポリシー、およびエンタープライズSSO統合を専門としています。詳細な技術検討のためのワークショップについて、ぜひお問い合わせください。

よくある質問(FAQ)

Cloudflare Zero Trustとは何ですか？ Cloudflare Zero Trustは、従来の企業VPNを置き換えるエンタープライズ向けのセキュリティプラットフォームです。内部アプリケーションへのアクセスを要求するすべてのユーザーのIDとデバイスの健全性を検証し、デフォルトで信頼されるユーザーやデバイスが存在しない状態を保証します。

Cloudflare Tunnelsはどのようにプライベートサーバーを保護しますか？ Cloudflare Tunnelsは、プライベートサーバーとCloudflareエッジネットワークとの間に、安全な送信専用の接続を確立します。その結果、すべての受信ファイアウォールポートを閉じることができ、悪意のあるポートスキャンからサーバーリソースを隠すことができます。

既存のIDプロバイダーとZero Trustを統合できますか？ はい、Google Workspace、Okta、Microsoft Entra ID（旧Azure AD）などの標準的なIDプロバイダーと統合できます。この設定により、シングルサインオン（SSO）を強制し、中央のダッシュボードからユーザー権限を一元管理できます。

Cloudflare Accessのデバイスポスチャーチェックとは何ですか？ デバイスポスチャーチェックとは、ユーザーのデバイスがアプリケーションにアクセスする前に満たす必要があるセキュリティ要件です。たとえば、システムはアクティブなウイルス対策ソフトウェアの有無、ディスク暗号化の有効化、OSバージョンの更新状況などを確認します。

エンタープライズ向けの料金はどのようになっていますか？ Cloudflareは最大50ユーザーまで利用できる無料ティアを提供しており、これには基本的なAccessポリシーとトンネル機能が含まれています。より大規模な環境や高度なポスチャーチェックルールが必要な場合は、ユーザーあたりの月額サブスクリプション料金が適用されます。