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

Доступ к приватным приложениям без развёртывания клиентских агентов

Использование Cloudflare для доступа к приватным ресурсам, например к приложениям, серверам и сетям, не имеющим прямого выхода в интернет, как правило предполагает развертывание (агент) на устройства, а затем с помощью серверного агента (cloudflared, Cloudflare Mesh), чтобы подключить частную сеть или приложение к Cloudflare. В этом документе описан альтернативный подход, который избавляет от необходимости устанавливать программное обеспечение на устройство пользователя и упрощает предоставление доступа сторонним лицам, например подрядчикам и партнерам.

Как правило, для предоставления доступа к внутренним ресурсам вы используете Cloudflare Zero Trust Network Access ZTNA ↗ который поддерживает два способа доступа пользовательского устройства к частному ресурсу.

• Запись CNAME в публичном DNS, которая указывает на имя хоста туннеля Cloudflare, проксирующего запрос ко внутреннему приложению.

• IP-адрес, предоставляемый туннелем Cloudflare, который опять же напрямую проксирует трафик на этот IP-адрес.

Некоторым организациям не нравится идея публичных DNS-записей, указывающих на внутренние сервисы: даже при надёжной защите доступа со стороны сервисов ZTNA само наличие имени сервиса в публичном DNS иногда нежелательно. Раскрывать IP-адреса пользователям напрямую тоже плохая идея: их трудно запомнить, к тому же IP-адреса могут меняться. В отличие от доступа к веб-приложению через публичную DNS-запись и наш прокси, для приложений, доступных по приватным IP-адресам, пользователю также требуется установить на устройство агент, который перехватывает и направляет трафик в Cloudflare, а тот, в свою очередь, направляет его к приложению. Установка такого агента может стать проблемой для сторонних лиц, например партнёров или подрядчиков.

Как же обеспечить доступ к приватным ресурсам, не создавая публичные DNS-записи и не заставляя пользователя устанавливать программное обеспечение на устройство? Cloudflare решает эту задачу с помощью Политики резолвера где можно использовать внутренние DNS-сервисы. В сочетании с безагентным Remote Browser Isolation, можно создать доступ Zero Trust к частным веб-приложениям, используя только современный веб-браузер. Политики контроля доступа к приложениям в этом случае прописываются в нашем сервисе Secure Web Gateway (SWG) в виде сетевой межсетевой экран политики. Этот метод поддерживает приложения на основе HTTP, хотя Cloudflare также предоставляет службу рендеринга в браузере для сервисов SSH и VNC.

Ознакомьтесь с этим руководство для получения сведений о настройке защищённого доступа к приватным веб-ресурсам без развёртывания клиентских агентов.

1. Пользователи начинают доступ с аутентификации в Cloudflare Browser Isolation ↗ сервиса. Обратите внимание, что это браузер, работающий в edge-сети Cloudflare, поэтому по умолчанию все запросы обрабатываются Cloudflare. Содержимое передаётся обратно в браузер пользователя через защищённые зашифрованные векторные потоки по каналам HTTPS и WebRTC.
2. После аутентификации в удаленном браузере пользователь отправляет запрос к внутреннему имени хоста, которое является записью во внутреннем DNS-сервисе, например https://app.company.internal ↗
3. Cloudflare находит внутреннее имя хоста с помощью политики Resolver, и получает частный IP-адрес от внутреннего DNS-сервера. Это разрешение DNS происходит внутри сети Cloudflare и не требует никаких изменений DNS-клиента на устройстве пользователя.
4. Cloudflare проверяет политики сетевого брандмауэра и убеждается, что у пользователя есть права на обращение к адресам назначения.
5. Если запрос проходит политику, он отправляется через защищенное QUIC ↗ туннели к коннекторам cloudflared, которые затем через обратный прокси передают трафик серверам приложений. Все данные безопасно передаются через Cloudflare обратно в браузер пользователя по зашифрованным векторным потокам.

• Руководство: доступ к веб-приложению через его частное имя хоста без Cloudflare One Client