За последний год Cloudflare Gateway превратился из решения для фильтрации DNS в Secure Web Gateway. Такой рост позволил клиентам защитить свои организации с помощью детализированных политик HTTP на основе идентификации и защиты от вредоносных программ, где бы ни находились их пользователи. Но как насчет другого интернет-трафика, не связанного с HTTP, который пользователи генерируют каждый день, например SSH?
Сегодня мы рады объявить о возможности для администраторов настраивать сетевые политики в Cloudflare Gateway. Подобно применению политик DNS и HTTP, организации могут использовать сетевые селекторы, такие как IP-адрес и порт, для управления доступом к любому источнику сети.
Поскольку Cloudflare for Teams интегрируется с вашим поставщиком удостоверений, он также дает вам возможность создавать на основе идентичности сетевые политики. Это означает, что теперь вы можете контролировать доступ к ресурсам, отличным от HTTP, для каждого пользователя независимо от того, где они находятся или с какого устройства они обращаются к этому ресурсу.
Основная цель Cloudflare One — увеличить количество переходов к Cloudflare — просто отправьте свой трафик на нашу границу, как хотите, и мы позаботимся о том, чтобы он доставлялся в пункт назначения как можно быстрее и безопаснее. Мы выпустили Magic WAN и Magic Firewall, чтобы позволить администраторам заменять соединения MPLS, определять решения о маршрутизации и применять правила фильтрации на основе пакетов к сетевому трафику со всех сайтов. В сочетании с Magic WAN, Gateway позволяет клиентам определять сетевые правила, которые применяются к трафику между целыми сайтами, центрами обработки данных и тем, что связано с Интернетом.
Решение сетевых проблем с нулевым доверием
До сегодняшнего дня администраторы могли создавать только политики, фильтрующие трафик на уровнях DNS и HTTP. Однако мы знаем, что организациям необходимо контролировать трафик сетевого уровня, покидающий их конечные точки. Мы постоянно слышим от наших пользователей две категории проблем, и мы очень рады, что сегодняшнее объявление решает обе проблемы.
Во-первых, организации хотят заменить устаревшие сетевые брандмауэры. Эти устройства сложны в управлении, дороги в обслуживании и заставляют пользователей передавать трафик. Группы безопасности развертывают эти устройства частично для управления портами и IP-адресами, которые устройства могут использовать для отправки трафика. Такой уровень безопасности помогает предотвратить отправку трафика устройствами через нестандартные порты или на известные вредоносные IP-адреса, но клиентам приходилось сталкиваться с недостатками локальных ящиков безопасности.
Во-вторых, перехода к модели нулевого доверия для именованных ресурсов недостаточно. Cloudflare Access предоставляет вашей команде элементы управления Zero Trust для определенных приложений, включая приложения, не поддерживающие HTTP, но мы знаем, что клиенты, которые переходят на эту модель, хотят обеспечить такой уровень управления Zero Trust для всего своего сетевого трафика.
Как это работает
Cloudflare Gateway, входящий в состав Cloudflare One, помогает организациям заменить устаревшие межсетевые экраны и перейти на сеть с нулевым доверием, начав с самой конечной точки. Где бы ваши пользователи ни выполняли свою работу, они могут подключаться к частной сети, работающей на Cloudflare, или общедоступному Интернету без обратного трафика.
Во-первых, администраторы развертывают агент Cloudflare WARP на пользовательских устройствах, будь то MacOS, Windows, iOS, Android и (скоро) Linux. Агент WARP может работать в двух режимах:
- Фильтрация DNS: WARP становится клиентом DNS-over-HTTPS (DoH) и отправляет все DNS-запросы в ближайший центр обработки данных Cloudflare, где Cloudflare Gateway может фильтровать эти запросы на наличие угроз, таких как веб-сайты, на которых размещаются вредоносные программы или фишинговые кампании.
- Режим прокси: WARP создает туннель WireGuard от устройства до границы Cloudflare и отправляет весь сетевой трафик через туннель. Затем Cloudflare Gateway может проверять HTTP-трафик и применять политики, такие как правила на основе URL-адресов и сканирование на вирусы.
Сегодняшнее объявление основывается на втором режиме. Агент WARP отправит все TCP трафик, покидающий устройство в Cloudflare, а также идентификационные данные пользователя на устройстве и организации, в которой устройство зарегистрировано. Служба Cloudflare Gateway принимает идентификационные данные, а затем проверяет TCP-трафик по четырем критериям:
- Исходный IP-адрес или сеть
- Исходный порт
- IP-адрес назначения или сеть
- Порт назначения
Прежде чем разрешить пакетам перейти к месту назначения, Cloudflare Gateway проверяет правила организации, чтобы определить, следует ли их блокировать. Правила могут применяться ко всему трафику организации или только к определенным пользователям и группам каталогов. Если трафик разрешен, Cloudflare Gateway по-прежнему регистрирует идентификатор и критерии, указанные выше.
Cloudflare Gateway делает это, не замедляя работу вашей команды. Служба шлюза работает в каждом центре обработки данных Cloudflare в более чем 200 городах по всему миру, предоставляя членам вашей команды возможность выхода в Интернет без транзитных маршрутов или фиксированного трафика. Мы обеспечиваем соблюдение правил, используя основанный на Rust механизм выполнения Wirefilter от Cloudflare, взяв то, что мы узнали из масштабного применения правил на основе IP в нашем брандмауэре обратного прокси, и давая вашей команде преимущества в производительности.
Построение сетевого правила нулевого доверия
SSH — это универсальный протокол, который позволяет пользователям подключаться к удаленным машинам и даже туннелировать трафик с локальной машины на удаленную до того, как достигнет намеченного пункта назначения. Это здорово, но это также оставляет у организаций зияющую брешь в их позиции по обеспечению безопасности. Сначала администратор может настроить правило, которое блокирует весь исходящий трафик SSH в организации.
Как только вы сохраните эту политику, телефон звонит, и инженер спрашивает, почему они не могут использовать многие свои инструменты разработки. Верно, инженеры часто используют SSH, поэтому мы должны использовать группу инженерных IdP, чтобы позволить только нашим инженерам использовать SSH.
Вы пользуетесь преимуществом приоритета правила и размещаете это правило над существующим правилом, которое влияет на всех пользователей, чтобы разрешить инженерам исходящий SSH-трафик, но не другим пользователям в организации.
Неважно, какие корпоративные устройства используют инженеры или где они находятся, им будет разрешено использовать SSH, а все остальные пользователи будут заблокированы.
Еще кое-что
В прошлом месяце мы объявили о возможности для клиентов создавать частные сети на Cloudflare. Используя Cloudflare Tunnel, организации могут соединять среды, которые они контролируют, используя частное IP-пространство, и маршрутизировать трафик между сайтами; лучше, пользователи WARP могут подключаться к этим частным сетям, где бы они ни находились. Нет необходимости в централизованных концентраторах VPN и сложных конфигурациях — подключите свою среду к Cloudflare и настройте маршрутизацию.
Сегодняшнее объявление дает администраторам возможность настроить политики доступа к сети для управления трафиком в этих частных сетях. Что, если указанный выше инженер пытался подключиться по SSH не к доступному в Интернете ресурсу, а к чему-то, что организация намеренно хочет сохранить во внутренней частной сети (например, к серверу разработки)? Опять же, не все в организации должны иметь к этому доступ. Теперь администраторы могут настраивать правила на основе идентификации, которые применяются к частным сетям, построенным на Cloudflare.
Что дальше?
Мы сосредоточены на достижении нашей цели Cloudflare One по защите организаций независимо от того, как их трафик попадает в Cloudflare. Частью этого видения является применение сетевых политик как к пользователям WARP, так и к маршрутизации между частными сетями.
Мы рады выпустить эти строительные блоки для политик Zero Trust Network Access, чтобы защитить пользователей и данные организации. Нам не терпится копнуть глубже, чтобы помочь организациям защищать приложения, использующие частные имена хостов и IP-адреса, как они это делают сегодня в своих общедоступных приложениях.
Мы только начинаем — перейдите по этой ссылке, и вы тоже сможете.
