cloudflare-one-migrations

Cloudflare One Migrations — это скилл для подготовки миграций с Zscaler ZIA или ZPA, Palo Alto NGFW, Prisma, GlobalProtect, классического VPN, SWG, SD-WAN и других SASE-стеков в Cloudflare One. Его задача — не обещать автоматическое преобразование конфигурации, а помочь собрать исходные данные, разобрать зависимости и подготовить проверяемый план перехода. Перед составлением точной конфигурации workflow требует обратиться к актуальной документации Cloudflare, схемам Cloudflare API и документации экспорта исходного поставщика. Работа начинается с определения исходного стека и границ миграции. Затем запрашиваются структурированные экспорты и журналы: они предпочтительнее скриншотов и пересказов, потому что по ним можно проверить объекты и связи. В инвентаризацию входят идентичности и группы, приложения, назначения, коннекторы и туннели, DNS-, URL-, firewall-, DLP- и TLS-политики, списки и объекты, локации и сайты, исключения, счётчики срабатываний и требования к журналированию. Для каждого правила план должен показывать исходный объект, целевой ресурс Cloudflare One, степень уверенности, предварительные условия, неподдержанные или частично переносимые части и решения, которые должен принять человек. Зависимости рекомендуется создавать до политик. В план входят IdP и синхронизация групп через SCIM, коннекторы и on-ramp-компоненты, маршруты и DNS, списки и объекты, исключения TLS, приложения и политики Access, правила Gateway, DLP/CASB и журналирование. После этого миграцию следует проводить поэтапно: использовать отдельный префикс миграции, по умолчанию создавать выключенные или работающие в audit-режиме правила, провести пилот на небольшой группе пользователей или сайтов, сравнить журналы и только затем расширять охват. Для каждой исходной записи нужно либо указать объект Cloudflare, в который она переходит, либо добавить строку Not Migrated с причиной и описанием влияния на безопасность. Для Zscaler ZIA в экспорте полезны фильтрация URL и firewall, SSL inspection, DLP, пользовательские URL-категории, IP-группы, сетевые сервисы и группы сервисов, пользователи, группы, отделы, локации, GRE-туннели и статические IP. Для ZPA нужны сегменты приложений, их группы, серверные группы, app connectors и connector groups, политики доступа, связь IdP с группами, частные DNS-домены, порты и протоколы. Для Palo Alto и Prisma учитываются security-, NAT- и decryption-правила, address/service-объекты и группы, URL-категории, HIP-профили, GlobalProtect, Prisma Access, зоны, теги, журналы и hit counts. Пропущенные файлы объектов могут скрыть зависимости, поэтому ссылки между экспортами нужно разрешать до вывода о том, что правило невозможно перенести. Скилл предлагает ориентиры, но не подменяет проверку конфигурации. Политики ZIA/SWG обычно сопоставляются с traffic policies Gateway и Gateway Lists. Доступ ZPA к частным приложениям обычно раскладывается на Access application, Cloudflare Tunnel, private-network routing, DNS и Access policies; эти сущности не считаются взаимозаменяемыми один к одному. Правила Palo Alto требуют анализа направления трафика, зон, объектов, пользователей, приложений, расшифровки и hit counts: зоны нельзя бездумно сворачивать в списки. Для замены классического VPN могут потребоваться Access, Cloudflare One Client или WARP, Tunnel либо Mesh; Cloudflare WAN следует рассматривать, когда нужен site-to-site-трафик, с проверкой актуальных design guide и материалов Replace your VPN. Отдельные проверки нужны для идентичности, TLS/DLP и связности. Если SCIM недоступен, правила, зависящие от групп, могут стать слишком широкими; требуется проверяемая альтернатива и поддерживаемые identity selectors. Исключения CAUTION или warn в Zscaler не имеют точного эквивалента Gateway и должны оставаться явным решением заказчика, а не превращаться молча в allow или block. DLP-движки и пользовательские regex обычно требуют ручного воссоздания профиля Cloudflare; заготовку нельзя включать как будто DLP уже перенесён. Сегменты ZPA, connector groups, туннели, частные DNS и Access-приложения нужно сопоставлять отдельно, а установка cloudflared и достижимость origin остаются самостоятельными этапами. Для Palo Alto App-ID, URL-категорий, зон, HIP, расписаний и decryption-поведения следует отмечать частичное соответствие, а не создавать ложную эквивалентность. Приёмка выполняется после каждого этапа. Нужно сравнивать количество объектов Cloudflare с количеством разобранных объектов источника и останавливать работу при расхождениях. Все элементы с пометками unsupported, partial, unmapped, needs_identity, needs_posture и manual_review должны быть просмотрены до включения политик. На реальных пилотных пользователях проверяются совпадение групп после SCIM и повторной аутентификации, TLS inspection и Do Not Inspect до массового включения HTTP- или DLP-блокировок. План отката должен быть явным: отключение перенесённых правил по префиксу, возврат исходной маршрутизации или откат пилотной группы/сайта. Финальный результат — таблица учёта исходных правил с перенесённым объектом, частичным соответствием или причиной Not Migrated, влиянием на безопасность и владельцем ручного действия. Так карточка описывает проверяемый процесс оценки и поэтапного перехода, а не гарантирует автоматическую миграцию или готовую конфигурацию без экспортов и решений владельца инфраструктуры.