cloudflare-one-migrations

Cloudflare One の移行

正確な設定を生成する前に、最新の Cloudflare ドキュメント、Cloudflare API スキーマ、移行元ベンダーのエクスポートに関するドキュメントを取得してください。

ワークフロー

1. 移行元のスタックを特定します：Zscaler ZIA、Zscaler ZPA、Palo Alto NGFW/Prisma/GlobalProtect、従来型 VPN/SWG/SD-WAN、その他。
2. マッピングの前に、エクスポートとログをリクエストします。スクリーンショットや文章による要約より、構造化されたエクスポートを優先してください。
3. インベントリを作成します：ID、グループ、アプリ、宛先、コネクター／トンネル、DNS／URL／ファイアウォール／DLP／TLS ポリシー、オブジェクト／リスト、ロケーション／サイト、例外、ヒット数、コンプライアンスログ。
4. マッピング計画を作成します：移行元のオブジェクト、Cloudflare One の対象リソース、確度、前提条件、未対応／部分的なマッピング、手動での判断事項。
5. 依存関係を先に作成します：ID／SCIM、コネクター／オンランプ、ルート／DNS、リスト／オブジェクト、TLS バイパス、Access アプリ／ポリシー、Gateway ポリシー、DLP／CASB、ログ。
6. 安全に段階導入します：移行用プレフィックスを使用し、デフォルトではルールを無効または監査モードで作成し、小規模なグループ／サイトで試験運用してログを比較してから、段階的に展開します。
7. 移行元のすべてのルールを考慮してください。各ルールは Cloudflare オブジェクトにマッピングするか、理由とセキュリティへの影響を記載した「移行対象外」の行を明示する必要があります。

依頼するエクスポート

• ZIA：URL フィルタリング、ファイアウォールフィルタリング、SSL インスペクション、DLP、カスタム URL カテゴリー、IP グループ、ネットワークサービス／サービスグループ、ユーザー／グループ／部門、ロケーション、GRE トンネル、静的 IP。
• ZPA：アプリセグメント、セグメントグループ、サーバーグループ、アプリコネクター／コネクターグループ、アクセス ポリシー、IdP／グループのマッピング、プライベート DNS ドメイン、ポート、プロトコル。
• Palo Alto/Prisma：セキュリティ／NAT／復号ルール、アドレス／サービスオブジェクトとグループ、URL カテゴリー、HIP プロファイル、GlobalProtect 設定、Prisma Access のリモートネットワーク／サービス接続設定、ゾーン、タグ、ログ、ヒット数。

マッピングのヒューリスティクス

• ZIA/SWG ポリシーは通常、Gateway トラフィックポリシーと Gateway リストにマッピングします。
• ZPA のプライベートアプリへのアクセスは通常、Access アプリケーションの種類、Cloudflare Tunnel、プライベートネットワークのルーティング／DNS、Access ポリシーにマッピングします。
• Palo Alto のルールは、トラフィックの方向、ゾーン、オブジェクト、ユーザー、アプリ、復号、ヒット数を把握してからマッピングします。ゾーンを安易にリストへ単純化しないでください。
• 従来型 VPN の置き換えでは通常、アプリへのアクセスに Access と Cloudflare One Client / WARP、および Tunnel または Mesh を使用します。サイト間トラフィックが必要な場合に限り、Cloudflare WAN を使用してください。最新のパターンについては、ネットワーク VPN 移行設計ガイドとVPN の置き換えのドキュメントを参照してください。

移行評価プロンプト

• ソースの網羅性：対象となる製品、利用可能なエクスポート、スクリーンショットや文章による要約によってオブジェクトファイルの不足が隠れていないかを確認します。
• ルール数とヒットデータ：ルールの種類ごとの件数、無効化されたルールや古いルール、ヒットのないルール、ヒット数の多いルール、ビジネス上重要な例外を確認します。
• オブジェクトの依存関係：アドレスオブジェクト、サービスオブジェクト、グループ、カスタムカテゴリ、ネットワークサービス、アプリ ID、ゾーン、タグ、コネクター、サーバーグループを確認します。
• ID 管理の準備状況：IdP、SCIM／グループ同期、グループ名の正規化、個別ユーザーのルール、ローカルグループ、サービスアカウント、請負業者の ID を確認します。
• TLS／DLP の準備状況：ソースの復号ルール、証明書ピンニングによるバイパス、DLP エンジン／プロファイル、カスタム正規表現、完全一致データ、ペイロードのログ記録要件を確認します。
• 接続性の準備状況：ソースのトンネル／コネクター、プライベート DNS、スプリットトンネルまたはバイパスの動作、ソース IP の保持、送信元 IP の許可リスト、拠点間接続の要件を確認します。
• ロールアウトの準備状況：パイロットグループ／拠点、並行稼働期間、ロールバックの担当者、ソーススタックの廃止基準、監視／ログ比較計画を確認します。

ソース固有の注意点

Zscaler ZIA / SWG

• カスタム URL カテゴリは、多くの場合、IP、ドメイン、URL の各リストに分割されます。ソースカテゴリだけでなく、生成されるリストの数を数えてください。
• IP を含む ZIA ロケーションは、ソース IP リストとして有用ですが、DNS ポリシーのスコープ設定に使用するゲートウェイ DNS ロケーションとして自動的に扱われるわけではありません。
• GRE トンネルのソース IP はポリシー条件の参考になりますが、トランスポートの移行は Cloudflare Mesh（旧 WARP Connector）または Cloudflare WAN の別の作業項目です。
• CAUTION／警告の動作には、Gateway に完全に一致する機能がありません。暗黙の許可／ブロックの選択ではなく、顧客が明示的に判断する事項として扱ってください。
• DLP エンジンとカスタム正規表現は、通常、Cloudflare DLP プロファイルを手動で再作成する必要があります。DLP が完了したかのように、プレースホルダーポリシーを有効にしてはいけません。
• ネットワークアプリケーショングループと非対応プロトコルは、部分的なマッピングになります。有効化する前に確認してください。
• SCIM を利用できない場合、ユーザーをスコープとするソースルールは、ユーザー／メールアドレスのリストなど、強制可能な代替手段を追加しないと対象範囲が広くなりすぎます。これらのルールを作成する前に、Gateway の ID セレクターを確認してください。

Zscaler ZPA / Private Access

• ZPA のアプリセグメント、サーバーグループ、コネクターグループは 1 対 1 でマッピングされるわけではありません。Cloudflare は Access アプリ、トンネルルート、DNS、ポリシーを分離しています。
• API 経由でトンネルを作成しても、コネクターのデプロイは完了しません。cloudflared のインストール、認証、オリジンへの到達性を別途計画してください。
• ZPA コネクターグループごとに 1 つの Cloudflare Tunnel を作成します。コネクターの実行ステータス (AUTHENTICATED、DISCONNECTED、無効) に関係なく作成してください。ステータスは運用上のものであり、アーキテクチャ上のものではありません。切断されたグループやレガシーグループにはトンネルの説明でタグを付け、検証後に何を廃止するかはお客様に判断していただきます。
• グループ内の各 ZPA コネクターインスタンスは、そのトンネルのトークンに対して実行される 1 つの cloudflared レプリカにマッピングされます。同じトポロジーを維持するため、グループごとにコネクターインスタンス数に合わせてレプリカ数を設定してください。1 つのトンネルトークンで複数の cloudflared プロセスを同時にサポートできます。レプリカは同じデータセンター内の、異なるホストまたはサブネットにインストールすることをお勧めします。
• 各コネクターグループについて、それにリンクされたすべてのサーバーグループと、それらのサーバーグループに割り当てられたすべてのアプリセグメントを特定します。それらのアプリセグメント内の IP アドレスと CIDR は、対応するトンネル上の CIDR ルートになります。ドメイン名は同じトンネル上のホスト名ルートになります。広いサブネットがすべてのアプリセグメント IP をカバーする場合は、ホスト単位の /32 ルートよりもサブネットごとに 1 つの CIDR ルートを使用することをお勧めします。
• ZPA のバイパスは、Cloudflare ではスプリットトンネルのバイパスを意味し、Access の bypass 決定ではありません。バイパスルールは Cloudflare One Client の Split Tunnel の除外エントリにマッピングされます。これは API 自動化のない手動設定手順です。お客様は、バイパスするドメインと IP をダッシュボードからデバイスプロファイルのスプリットトンネル除外リストに追加する必要があります。
• エージェントレス/ブラウザアプリは、ドメインごとに個別のパブリックホスト名 Access アプリになる場合があります。WARP プライベートアプリはプライベート宛先アプリのままです。
• Cloudflare Access アプリケーションのデフォルトの宛先上限は、アプリあたり 5 ホスト名です。大規模なアプリセグメントを伴う ZPA 移行では、実装前に Cloudflare アカウントチームに連絡して上限の引き上げ (最大 50) を依頼してください。アプリを作成する前に、その上限がアカウントで有効になっていることを確認してください。上限がない場合、大規模なセグメントは同一ポリシーを持つ複数のアプリに分割する必要があり、オブジェクト数が大幅に増加します。
• IP に紐づくアプリは、移行前に明示的な egress の決定が必要です。お客様の egress を通じて送信元 IP を保持する、利用可能な場合は Cloudflare の専用 egress を使用する、または新しい送信元 IP を許可するようにターゲットサービスを更新する必要があることを受け入れる、のいずれかです。これはお客様の決定であり、未解決の場合は実装がブロックされます。
• リゾルバーポリシーはアカウント全体に適用できます。サイト間または仮想ネットワーク間でプライベート DNS 名前空間が重複する場合は注意してください。DNS を変更する前に、リゾルバーポリシーのドキュメントを確認してください。
• 各 ZPA アクセスポリシールールは、Cloudflare の再利用可能な Access ポリシーにマッピングされます。Access アプリにアタッチする前に、すべての再利用可能なポリシーを作成してください。デフォルト拒否の Gateway Network 環境では、さらにセレクター「Self-hosted Access App with Private Address is Present」(wirefilter: any(access.private_app[*] in {"*"})) を持つ Network 許可ルールを、広範な L4 ブロックルールよりも高い優先順位で作成してください。これがないと、Access ポリシーの評価が行われる前に Gateway がプライベートアプリのトラフィックをブロックします。
• ZIA と ZPA の統合移行では、Gateway Network ルールが誤って Access プライベートアプリのトラフィックをブロックする可能性があります。上記の Gateway Network 許可ルールがその解決策です。ZIA から移行したブロックルールよりも高い優先順位 (小さい番号) に配置してください。広範な L4 ブロックを有効にする前に、このルールを追加して検証してください。

Palo Alto / Prisma / NGFW

• Palo Alto の 1 つのルールから、複数の Cloudflare リソースが生成される場合があります。ルール数ではなく、ルールの意図を維持してください。
• App-ID、URL カテゴリー、ゾーン、HIP、スケジュール、復号動作は、正確に対応付けられないことがほとんどです。無理に同等とみなさず、部分的なマッピングとして記録してください。
• ルールとともに、アドレス／サービスオブジェクトとグループもエクスポートしてください。オブジェクトのエクスポート漏れは、明示的に検出しないと、見た目では分からないままルールが欠落する原因になります。
• 宛先／サービスが広範な any のルールや、範囲が非常に広い CIDR は、手動で確認する必要があります。広範なキャッチオールルールを自動作成しないでください。
• HIP／デバイスチェックを適用する前に、Cloudflare のデバイスポスチャとの連携が必要です。

注意点

• ソースのエクスポートでは、ファイル間で参照が分割されていることがよくあります。ルールをマッピング不可と判断する前に、オブジェクト、サービス、グループの各ファイルを参照して ID を解決してください。
• 個々のユーザー、ローカルグループ、部署、動的なアプリケーション ID では、ID の正規化が必要になることがよくあります。グループセレクターを使用するには、SCIM／グループ同期が前提条件となります。
• Zscaler の注意／警告動作、Palo Alto の App-ID 動作、TLS／復号の例外には、正確な対応機能がない場合があります。1 対 1 のマッピングを無理に行わず、判断が必要な項目として記録してください。
• 可能な場合は、ソースのルール順序とヒット数を維持してください。ユーザーの承認なしに、古いルールやヒットのないルールを無効化または削除しないでください。
• 明示的に依頼され、期間が限定されている場合を除き、接続を維持するための広範な全許可キャッチオールルールを作成しないでください。

検証ゲート

• 各移行段階の後に、Cloudflare のオブジェクト数と解析済みソースの数を比較してください。不一致があれば作業を中止してください。
• ポリシーを有効にする前に、すべての unsupported、partial、unmapped、needs_identity、needs_posture、manual_review 項目を確認してください。
• SCIM 同期と再認証の後、実際のパイロットユーザーを使ってグループの照合を検証してください。
• HTTP／DLP ブロックを広範に有効にする前に、TLS インスペクションと「検査しない」動作をテストしてください。
• ロールバック手順を明確にしてください。移行したルールをプレフィックスで無効化する、ソースのルーティングを復元する、またはパイロットグループ／サイトを元に戻す方法を記載します。
• 完了を宣言する前に、移行したオブジェクト、部分的なマッピング、未移行の理由、セキュリティへの影響、各手動作業の担当者を記載したソースルールの対応表を作成してください。

評価テンプレート

## Migration Assessment

Source stack:
Artifacts reviewed:
Assumptions / missing exports:
Recommended Cloudflare One target:
Mapping summary:
Risks / partial mappings:
Not migrated:
Pilot plan:
Validation:
Rollback: