← Справочные архитектуры / reference-architecture / design-guides

Миграция с VPN-концентраторов на Zero Trust Network Access, ориентированная на сеть

В последние несколько лет традиционный подход, при котором для удалённого доступа к частным корпоративным сетям устанавливается и обслуживается оборудование, перестал быть безопасным и экономически оправданным. Из-за роста уязвимости ↗ встречающихся в локальных VPN-продуктах, команды безопасности и ИТ ищут решения, которые не требуют постоянного мониторинга и реагирования на Оповещения о CVE ↗. Кроме того, эти же системы ограничивают пропускную способность пользователя, поскольку весь интернет-трафик направляется через единую инфраструктуру, что приводит к плохому пользовательскому опыту. IT-команды все чаще понимают, что расходы и усилия на установку и обслуживание собственного оборудования можно компенсировать более современными и защищенными облачными сервисами. Ожидания пользователей от производительности приложений выявляют ограничения VPN-решений с недостаточной пропускной способностью и локальным размещением. В итоге содержание собственного VPN обходится дорого, несет высокие риски и не обеспечивает хороший пользовательский опыт.

В связи с этим многие организации стремятся перейти на нулевое доверие ↗ состояние безопасности с помощью Zero Trust Network Access ↗ (ZTNA) в рамках Периферийная служба безопасного доступа ↗ (SASE) для предоставления удалённого доступа к частным ресурсам. Поскольку всё критически важное программное обеспечение работает как облачный сервис, организации избавлены от необходимости поддерживать серверы и ПО в актуальном состоянии. Кроме того, облачные платформы изначально рассчитаны на большой масштаб, что значительно увеличивает доступную пропускную способность для конечных пользователей и улучшает их опыт использования.

В старой модели VPN оборудование имело прямой доступ к сетям, в которых работали приложения, и пользователи обычно получали доступ ко всей сети целиком. Новые методы удалённого доступа SASE создают соединение от облачной платформы к сетям, где живут приложения, но открывают доступ только к конкретному приложению или сетевому адресу. Cloudflare рекомендует устанавливать программных агентов, похожих на те, что стоят на устройствах конечных пользователей, которые создают защищённые туннели от облака к частным сетям. Однако этот путь не всегда прост. Сетевым администраторам, которые хотят быстро заменить устаревшее оборудование удалённого доступа, может не хватить времени на развёртывание новых серверов или прохождение долгого процесса согласования изменений для установки ПО на существующие серверы приложений. Вместо этого им может быть привычнее и удобнее создавать защищённые туннели от облачных платформ SASE к существующему сетевому оборудованию по знакомым протоколам, таким как GRE или IPsec. Иногда для этого используют те же самые аппаратные устройства, что раньше применялись для VPN доступа, просто упрощая их до коннекторов защищённых туннелей и отключая (или убирая лицензии на) дорогие и уязвимые функции удалённого доступа.

Это руководство по проектированию предназначено для организаций, которым требуется быстрый способ заменить или сократить использование самостоятельно размещенного оборудования удаленного доступа и постепенно перейти к рекомендуемому подходу на основе программного агента там, где это уместно.

Это руководство написано для сетевых экспертов и специалистов по безопасности, которые рассматривают замену текущего поставщика VPN и одновременно готовят организацию к переходу на архитектуру zero trust или SASE. Предполагается знакомство с такими сетевыми понятиями, как туннели IPsec, таблицы маршрутизации и раздельное туннелирование (split tunneling).

Чему вы научитесь:

• Как Cloudflare заменяет традиционные решения на основе VPN
• Как получить видимость сетевого трафика VPN
• Что нужно учитывать при внедрении решения Cloudflare в масштабе всей организации
• Шаги для перехода к рекомендуемой реализации Zero Trust Network Access

Решение, описанное в этом руководстве, требует наличия у вас контракта с Cloudflare, включающего:

• Лицензии Cloudflare One на количество пользователей, которых вы планируете подключить
• Cloudflare WAN (ранее Magic WAN)

Чтобы лучше разобраться в Cloudflare, рекомендуем следующие материалы:

1. Что такое Cloudflare? | Сайт ↗ (пять минут на чтение) или видео ↗ (две минуты)
2. Блог: Что такое SASE? | Secure access service edge | Cloudflare ↗ (14 минут на чтение)
3. Эталонная архитектура: Переход к архитектуре SASE с Cloudflare (три часа на чтение)

Традиционные подходы на основе VPN обычно обеспечивают следующие типы доступа.

• Предоставление удалённым пользователям доступа к самостоятельно размещённым частным приложениям, работающим в корпоративной сети
• Маршрутизация всего интернет-трафика пользователей через единую централизованную точку доступа VPN, где применяются политики безопасности

Платформа SASE заменяет традиционное VPN-оборудование, предлагая две ключевые функции. Во-первых, она предоставляет пользователям доступ непосредственно к внутренним приложениям, размещённым в корпоративной сети или облаке, в отличие от собственной VPN-службы, которая обычно открывает широкий доступ ко всей корпоративной сети. Во-вторых, она позволяет фильтровать интернет-трафик как можно ближе к пользователю, благодаря чему пользователи могут безопасно выходить в интернет без маршрутизации всего трафика через корпоративную сеть, что повышает эффективность и сохраняет безопасность.

Удалённые пользователи проходят аутентификацию и подключаются к облачному сервису Zero Trust Network Access (ZTNA), который в свою очередь обеспечивает связь с сетями, где размещены частные приложения. Решение Cloudflare Эталонная архитектура SASE описывает три способа подключения Cloudflare к вашим существующим приложениям и сетям:

1. Программные коннекторы (cloudflared или Cloudflare Mesh)
2. Туннели IPsec или GRE с использованием Cloudflare WAN
3. Прямые сетевые подключения с использованием Cloudflare Network Interconnect

У всех трёх методов есть свои преимущества, однако при построении современной архитектуры Zero Trust обычно предпочтение отдаётся программным коннекторам по трём причинам.

1. Они обеспечивают гибкую модель сетевого подключения, которую легко воспроизвести в разных средах. Приложения и серверы можно переносить практически без изменений конфигурации.
2. Архитектура программного демона упрощает масштабирование при увеличении трафика: нужно лишь установить дополнительные агенты на дополнительные серверы.
3. Поскольку демоны работают в непосредственной близости от ваших приложений, а не на границе сети, вы можете создавать изолированные сетевые или прикладные сегменты, в которых применяется политика, что предотвращает горизонтальное перемещение злоумышленника внутри сети и позволяет в полной мере воспользоваться преимуществами модели zero trust.

Трафик, предназначенный для обычного интернета, направляется через облачный Secure Web Gateway (SWG). Политики настраиваются так, чтобы фильтровать запросы к вредоносным сайтам и разрешать доступ к SaaS-приложениям на основе идентичности пользователя и состояния защищённости устройства.

Cloudflare Эталонная архитектура SASE описывает различные способы подключения пользовательских устройств к Cloudflare: для одних требуется установка агентов на устройство, для других достаточно, чтобы пользователь просто указал URL-адрес в браузере. Поскольку большинство традиционных VPN требуют клиентского ПО на устройстве, в этом документе мы рассмотрим решение на основе Cloudflare агент устройства.

Когда существующее оборудование удалённого доступа уязвимо и его срочно нужно заменить, скорость имеет решающее значение. При этом команда, которой поручена замена существующего VPN-оборудования, может лучше разбираться в сетях, чем в установке ПО на серверы. Попытка реализовать полноценный проект по замене существующего оборудования принципиально иной моделью, то есть развёртыванием программных агентов, может занять недели, а не дни. Это руководство показывает, как быстро убрать или снизить риски существующих VPN-решений, а затем предлагает дальнейшие шаги для использования всех возможностей платформы SASE.

Такой подход позволяет командам сети и безопасности быстро приступить к работе, одновременно приобретая опыт современных развертываний Zero Trust для удаленного доступа к внутренним приложениям. Дополнительная видимость сетевого трафика также помогает командам лучше понимать использование приложений и планировать успешный и безопасный переход на Zero Trust.

В этом руководстве на высоком уровне описаны следующие этапы. Если вам нужна помощь с деталями, относящимися конкретно к вашей среде, обратиться в Cloudflare ↗.

• Этап 1: Быстрая замена существующего традиционного и уязвимого VPN-оборудования облачным удалённым доступом с одновременным получением видимости трафика приложений.
• Этап 2: Масштабирование и разгрузка традиционных туннелей IPsec.
• Этап 3: Повышение уровня защищённости за счёт сегментации доступа к приложениям и внедрения доступа без клиента.

Рассмотрим организацию с глобальной IT-инфраструктурой: три дата-центра в Европе, США и Азии, каждый со своим VPN-сервисом. Для наилучшей производительности такая реализация VPN требует, чтобы сотрудники сами выбирали, к какому VPN-кластеру подключаться, в зависимости от своего местоположения. В этом примере весь интернет-трафик пользователей проходит через VPN-сервис, где межсетевые экраны обеспечивают уровень защиты, ограждающий пользователей от угроз обычного интернета.

На этом первом этапе создаётся сетевое соединение между устройствами пользователей и частными сетями, к которым они сейчас обращаются через существующую сетевую инфраструктуру. Это достигается двумя способами.

• На устройствах сотрудников установите Cloudflare агент устройства. Это заменяет использование существующего клиентского ПО VPN.
• С использованием имеющегося сетевого оборудования в дата-центре создаются IPsec-туннели к Cloudflare, которыми можно управлять через сервис Cloudflare WAN.

И устройства сотрудников, и сети дата центров будут подключаться к ближайшему серверу Cloudflare. Это возможно благодаря Anycast-архитектура Cloudflare ↗, и обеспечивает оптимальный маршрут для пользовательского трафика без каких-либо усилий со стороны сотрудников или ИТ-поддержки. Пользователям больше не нужно выбирать регион VPN-сервиса для подключения: Cloudflare всегда подключает их к ближайшему и наиболее отзывчивому сервису, обеспечивая максимальную производительность доступа к их частным приложениям.

Рисунок 4 показывает трафик от устройств конечных пользователей к Cloudflare и туннели, направляющие трафик в частные дата-центры. Когда пользовательский трафик достигает ближайшей точки доступа Cloudflare, она направляет трафик, предназначенный для частных приложений, напрямую в дата-центры, а трафик, идущий в Интернет, обрабатывает через собственную Secure Web Gateway (SWG). Существующие DNS сервисы можно использовать для разрешения запросов к частным адресам с помощью Cloudflare Политики DNS Gateway. Cloudflare WAN используется для создания туннелей IPsec между Cloudflare и дата-центрами и настраивается со статическими маршрутами, определяющими, как трафик достигает каждой существующей сети и приложений.

Используя существующие сетевые или защитные устройства для терминирования туннелей IPsec, можно организовать безопасные точки выхода в интернет с минимальным влиянием на текущую инфраструктуру. Эти туннели IPsec также позволяют продолжать пропускать исходящий трафик, инициированный сервером. Однако, в зависимости от масштаба развёртывания, существующие устройства могут столкнуться с ограничениями по пропускной способности. Этот первый этап лучше рассматривать как «пилотное» или маломасштабное развёртывание, позволяющее быстро запустить систему и проверить связность между пользователями и приложениями. На следующем этапе конструкция будет улучшена с учётом выводов, полученных на этом этапе.

При такой архитектуре Cloudflare сможет фильтровать трафик на основе идентификационных данных запрашивающего пользователя. Например, пользователям, прошедшим аутентификацию через корпоративного провайдера идентификации и входящим в группу «Engineering», будет разрешен доступ только к внутреннему репозиторию исходного кода. Кроме того, устройству пользователя может потребоваться пройти определённые проверки состояния устройств перед подключением. Существуют примеры сетевых политик в документации по Zero Trust, на которую можно опираться. По сути, это позволит вам определять политики сетевого доступа на основе идентификации пользователей, а не связанных с ними диапазонов IP-адресов. Отказ от традиционных ACL на основе 5-tuple станет первым шагом к модели Zero Trust.

Теперь, когда сети подключены к Cloudflare, нужно направить трафик от устройств сотрудников в сеть Cloudflare, для чего требуется агент устройства. При первоначальной установке агента пользователям предлагается пройти аутентификацию через провайдера идентификации (IdP), настроенного в Cloudflare. IdP обеспечивает аутентификацию с использованием существующей учетной записи, а также может импортировать информацию о членстве в группах, используемую в политиках доступа. Политики регистрации устройств используются для того, чтобы новые устройства могли подключаться к экземпляру Cloudflare Zero Trust вашей организации только после проверки подлинности нужными методами с использованием защищённых устройств, ещё до получения доступа к каким-либо приложениям.

Используйте профили устройств для применения разных конфигураций агента устройства к разным пользователям, или к тем же пользователям в разных местах, с помощью Управляемые сети. Для компаний, которые не направляют интернет-трафик через свой VPN-сервер, профили устройств позволяют настроить агент устройства так, чтобы он исключал интернет-трафик из Cloudflare Tunnel и подключаться к интернету напрямую. Обратите внимание, что в этом руководстве настоятельно рекомендуется направлять трафик, предназначенный для интернета, через Cloudflare, где у вас больше контроля над безопасностью этого трафика. Однако для трафика с высокой нагрузкой на канал, например видеоконференций, Cloudflare можно выборочно обходить.

Трафик сотрудников, использующих агент устройства и направленный к внутренним ресурсам, будет иметь исходный IP-адрес из диапазона 100.96.0.0/12. Это диапазон из Адресное пространство Carrier-grade NAT (RFC 6598) ↗ который следует добавить в качестве маршрута в регионах дата-центров, чтобы обеспечить обратный поток трафика к этим пользователям. Дополнительные сведения см. в Cloudflare WAN с интеграцией WARP документация.

Хотя на этом этапе основное внимание уделяется использованию сервиса Cloudflare WAN и туннелей IPsec для основной части трафика сотрудников, программные коннекторы Cloudflare играют ключевую роль в разрешении внутренних имён хостов через DNS. Опыт работы с этими программными коннекторами также пригодится на следующем этапе, поэтому уже на данном, первом, этапе следует начать определять процессы их развёртывания и управления ими.

Cloudflare предлагает два типа программных коннекторов:

• cloudflared
• Cloudflare Mesh (ранее WARP Connector)

Как говорилось во введении, cloudflared является предпочтительным методом для Zero Trust Network Access, однако поддерживает только входящие соединения с вашими сетями и серверами приложений: любое соединение, инициированное сервером, пойдет не через туннель, а по стандартному сетевому пути сервера. Cloudflare Mesh предназначен для создания туннелей, обеспечивающих как входящие, так и исходящие соединения, но пока не обладает тем же уровнем поддержки отказоустойчивости и простоты настройки. В этом руководстве речь пойдет об использовании cloudflared поскольку он поддерживает описанный сценарий использования внутреннего DNS.

Для крупных сценариев удалённого доступа Cloudflare рекомендует развёртывать коннекторы на выделенных хостах. См. Документация по системным требованиям для получения дополнительных рекомендаций по развёртыванию и расчёту размера серверов. Место развёртывания этих серверов зависит от того, какой доступ им нужен, а также от внутренних правил межсетевого экрана и сегментации сети. Одни клиенты начинают с развёртывания в DMZ, другие устанавливают серверы глубже в сети и постепенно развивают архитектуру.

Установка cloudflared лучше всего выполнять автоматизированно, поэтому мы рекомендуем развертывание с помощью технологий виртуализации, таких как Docker, либо в виде гостевых машин VMware с настройкой через Ansible. Желательно, чтобы трафик, использующий cloudflared туннелей растет, такие системы могут автоматически масштабировать развертывание на основе метрик в реальном времени, собираемых с хостов. cloudflared экземпляры можно отслеживать с помощью Конечная точка метрик Prometheus. Prometheus представляет собой систему мониторинга и оповещений на основе HTTP, по функциональности схожую с SNMP: она предоставляет метрики, которые можно опрашивать у отслеживаемого ресурса. Большинство современных систем мониторинга на рынке поддерживают Prometheus как формат сбора метрик, необходимых для оповещений и автоматического масштабирования развертывания.

Дополнительные сведения о развёртывании cloudflared коннекторов в промышленном масштабе:

• Различные руководства по развертыванию и обновлению коннекторов в таких средах, как Ansible, Terraform и Kubernetes
• Высокая доступность с использованием реплики
• Мониторинг туннелей с помощью Grafana

Как видно на рисунке 4, и DNS-трафик, и обычный сетевой трафик идут с устройства сотрудника в Cloudflare. По умолчанию агент на устройстве направляет все DNS-запросы в Cloudflare для проверки и фильтрации на основе Политики DNS. Это удобно, поскольку позволяет администраторам настраивать DNS-политики для блокировки потенциальных угроз безопасности и сразу же начинает защищать сотрудников, как только они выходят в сеть. Это также применимо в ситуациях, когда интернет-трафик поступает от туннеля к Cloudflare, но клиент по прежнему разрешает запросы к хостам через DNS-сервисы Cloudflare.

Однако для внутренних доменов Cloudflare нужно знать, как их разрешать. Именно здесь пригодится политики Resolver вступают в действие. После применения DNS-политик к входящим DNS-запросам клиенты могут выбрать перенаправление запросов для внутренних DNS-имён хостов на свои внутренние DNS-серверы. Например, домен example.local может размещаться на DNS-сервере с адресом 10.10.10.123. Политика резолвера обеспечит, чтобы запросы к именам хостов в составе этого домена отправлялись на данный IP-адрес.

Необходим туннель, открывающий маршрут к внутреннему DNS-серверу. cloudflared следует развернуть на хосте, который может маршрутизировать DNS-трафик на IP-адрес 10.10.10.123. Запросы к внутренним доменам через DNS-шлюз будут затем перенаправлены на этот DNS-сервер через туннель.

По мере выполнения этого первого этапа и появления первых пользователей, работающих с приложениями, станет очевидна необходимость надлежащего мониторинга и журналирования. Видимость трафика, проходящего через Cloudflare, поможет в следующем:

• Операционная деятельность, например устранение неполадок силами вашей службы поддержки.
• Мониторинг потенциальных угроз силами SOC, возможно, с использованием системы управления информацией и событиями безопасности (SIEM ↗) сервис.
• Видимость трафика приложений, позволяющая определить, где можно улучшить безопасность и производительность (см. также этап 2).

Cloudflare дает видимость на разных уровнях: данные доступны через дашборд или их можно экспортировать с помощью Logpush. Для трафика, проходящего через туннели Cloudflare WAN IPsec, Network Analytics можно найти в дашборде, а также через GraphQL API. Это покажет выборочную статистику трафика, которую можно использовать для анализа тенденций и потоков трафика.

Далее представлены более подробные журналы сетевых сессий которые собирают информацию обо всех сетевых соединениях и сессиях, проходящих через защищённый веб-шлюз Cloudflare, включая неудачные запросы. За ними следуют Журналы активности Gateway, в которых содержится информация о срабатывающих политиках при проверке трафика движком gateway. Совокупность этих логов дает полную видимость всех сетевых потоков, включая идентификацию пользователей. Используя эту информацию, сетевые команды и команды безопасности могут анализировать, какой трафик и куда направляется, и на основе этого планировать дальнейшие действия.

И наконец, для оповещений в режиме реального времени Cloudflare Notifications можно настроить для таких событий, как IPsec и cloudflared состояние туннеля, а также общее состояние инфраструктуры Cloudflare.

В большинстве сред точки терминации IPsec ограничены по пропускной способности, и рано или поздно это может стать проблемой при росте трафика в масштабах всего бизнеса. Заключительный этап первой фазы даст вам представление о потоках трафика приложений. Даже если не удастся полностью описать весь ландшафт приложений, вы, скорее всего, найдёте приложения, создающие значительную нагрузку на текущие IPsec-туннели.

К счастью, большинство таких приложений можно перенести по одному на более масштабируемые туннели на основе программных коннекторов. Для этого типа переноса подходит любое приложение, не зависящее от трафика, инициируемого сервером. Опираясь на опыт, полученный при первоначальном развёртывании cloudflared на этапе 1:

1. Развёртывание двух или более cloudflared экземпляров в соответствующей среде, в примере ниже это дата-центр в США.
2. Добавить Частные сети к туннелю для определения маршрутизации и доступа, более точно ограниченных сетью и приложениями, для которых обрабатывается трафик. Например, можно открыть подсеть 10.20.56.0/24 через программный туннель коннектора вместо более широкой подсети 10.20.0.0/16, открываемой управляемым IPsec-туннелем Cloudflare WAN.
3. Трафик сотрудников теперь будет направляться через туннель программного коннектора для подсети /24 вместо маршрута /16 через IPsec-туннель, что снижает зависимость от устройства терминации IPsec.

В некоторых случаях (как с дата-центром в Азии выше) IPsec-туннели могут больше не понадобиться, и единственным подключением к инфраструктуре останутся программные коннекторы. В этом случае всей подсетью 10.30.0.0/16 можно управлять через cloudflared и вывести из эксплуатации IPsec-туннель (и связанное с ним оборудование). Скорее всего, этот этап станет постоянным процессом: по мере того как всё больше приложений будет картировано, а трафик признан подходящим для туннелей на базе программных коннекторов, они будут поэтапно переноситься по мере необходимости.

Первые два этапа этого руководства привели к архитектуре, очень похожей на традиционные VPN с VPN-концентраторами, где применение политик происходит на периметре. Хотя мы сделали это по причинам, изложенным во введении, суть архитектуры zero trust в том, чтобы повысить уровень защиты за счёт выделения более мелких сегментов приложений и сети, к которым политики безопасности применяются максимально близко к самому ресурсу.

Цель этого этапа: сделать ресурсы, открытые за туннелями, меньше и более изолированными, чтобы предотвратить горизонтальное перемещение внутри внутренних сетей. Видимость, полученная на предыдущих этапах, позволит выбрать приложение (или набор приложений) и связанные с ним IP-адреса, а затем развернуть отдельный экземпляр программного коннектора. См. документацию о развёртывании коннекторов и предоставлении доступа к частным сетям а на шаге 3 настройте IP адреса приложения.

Поскольку каждый экземпляр software connector выделяется под конкретное приложение, его можно настроить как единственную точку входа. Трафик, входящий в сетевой сегмент с этим приложением и выходящий из него, можно полностью заблокировать, что предотвращает любое внутреннее горизонтальное перемещение. Для этого достаточно, чтобы у software connector был исходящий маршрут в Интернет для создания туннеля, а сеть или приложение могли обращаться к серверу, на котором он развёрнут. Управление доступом происходит не только на уровне маршрутизации IP, но и на уровне протокола. Поэтому с помощью такого подхода можно разрешить доступ только к HTTPS на этом сервере, даже если на нём также работают SSH и другие сервисы: доступ можно ограничить именно портом нужного приложения.

В примере выше подсети X и Y полностью изолированы от остальной части дата-центра. Трафик к приложениям, работающим в этих подсетях (10.10.45.1 и 10.20.56.1 соответственно), может проходить только через Cloudflare с применением соответствующих политик аутентификации и авторизации. Развёртывание программных коннекторов по принципу «один к одному» подходит не всегда. У вас может быть несколько приложений в одной частной сети, и тогда разворачивают несколько серверов с cloudflared для обработки трафика приложений.

Помимо маршрутизации трафика для частных IP-адресов, cloudflared может предоставлять доступ к внутренним приложениям через публично разрешаемые имена хостов. Благодаря этому можно подключаться к таким приложениям без установки какого-либо ПО на устройство. Это может быть очень полезно в сценариях, когда установка ПО на устройство невозможна, например при предоставлении доступа к приложению подрядчикам или партнёрам.

В примере ниже erp.example.com добавляется в качестве Public Hostname к туннелю, направляя трафик на порт 80 и (или) 443 на определенный IP-адрес во внутренней подсети Y. Доступ к этому ресурсу из интернета затем защищается с помощью Политики безопасности Cloudflare Access которые также используют подключение IdP, настроенное вами для адаптации сотрудников.

Не все приложения подходят для этого типа доступа. Только HTTP(S)-приложения или приложения, которые можно отобразить в браузере такие как SSH и VNC. Подробнее о таком развёртывании и дополнительных расширенных настройках, таких как параметры cookie, изоляция браузера и использование токена Access для аутентификации в вашем приложении, см. в документация по self-hosted приложениям.

Это руководство по проектированию начиналось с достаточно традиционной среды VPN с ее типичными возможностями, ограничениями и рисками. Используя сочетание Cloudflare на устройствах пользователей и Cloudflare WAN в направлении сетей дата-центра, первый и второй этапы описывали низкорисковый подход к миграции с использованием существующих технологий и знаний. Это уже принесло пользу: вывод из эксплуатации концентраторов VPN, улучшенную видимость сети и повышение производительности при доступе пользователей к внутренним ресурсам.

Третий этап усовершенствовал архитектуру за счёт внедрения сетевых политик на основе идентификации и уменьшения сегментов сети с помощью программных коннекторов. Это открыло возможность предлагать другие модели доступа zero trust, например доступ без клиента для веб-приложений и сеансы VNC или SSH, отображаемые прямо в браузере.

Гибкость Cloudflare connectivity cloud, способной подключать любые устройства, приложения и сети, позволяет проводить переход к zero trust поэтапно. Это снижает риски и даёт сетевым и защитным командам возможность адаптировать свои знания и архитектуры в темпе, необходимом их организациям.

• Интеграция Cloudflare WAN: WARP как точка входа в Cloudflare WAN
• Настройка политик: Сетевые политики Gateway