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

Переход к архитектуре SASE с Cloudflare

Скачать PDF-версия данной референсной архитектуры.

Cloudflare One представляет собой платформу Secure Access Service Edge (SASE), которая защищает корпоративные приложения, пользователей, устройства и сети. Постепенно переходя на Cloudflare One, организации могут отказаться от разрозненного набора аппаратных устройств и прочих точечных решений в пользу единой консолидированной платформы управления безопасностью и сетью. Такая трансформация сети и безопасности помогает решить ключевые задачи, с которыми сталкивается современный бизнес, в том числе:

• Защита доступа любого пользователя к любому ресурсу с помощью практик Zero Trust
• Защита от киберугроз, включая многоканальный фишинг и атаки программ-вымогателей
• Защита данных для соблюдения нормативных требований и предотвращения утечек
• Упрощение связности между офисами, дата-центрами и облачными средами

Cloudflare One построен на connectivity cloud ↗, единая интеллектуальная платформа программируемых облачных сервисов, обеспечивающих связность по принципу «любой с любым» между всеми сетями (корпоративными и интернетом), облачными средами, приложениями и пользователями. Это одна из крупнейшие глобальные сети ↗, с дата-центрами, охватывающими сотни городов по всему миру ↗ и взаимодействие более чем с 13 000 сетевых партнёров. Кроме того, у неё более широкое присутствие в ключевые точки обмена интернет-трафиком ↗ чем у многих других крупных технологических компаний.

В результате Cloudflare работает в пределах ~50 ms от ~95% населения мира, подключённого к интернету. А поскольку все сервисы Cloudflare рассчитаны на работу в каждой точке присутствия сети, весь трафик подключается, проверяется и фильтруется как можно ближе к источнику, что обеспечивает наилучшую производительность и стабильный пользовательский опыт.

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

Эта эталонная архитектура предназначена для ИТ-специалистов и специалистов по безопасности, которые отвечают за существующую инфраструктуру организации или знакомы с ней. Полезно иметь опыт работы с технологиями, важными для защиты гибридной работы: поставщиками удостоверений (IdP), каталогами пользователей, единым входом (SSO), защитой или управлением конечными точками (EPP, XDR, UEM, MDM), межсетевыми экранами, маршрутизаторами, а также точечными решениями вроде оборудования для проверки пакетов или содержимого, средствами предотвращения угроз и технологиями предотвращения утечки данных.

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

• Что такое Cloudflare? | Сайт ↗ (5 минут на чтение) или видео ↗ (2 минуты)

• Обзор решения: Cloudflare One ↗ (3 минуты на чтение)
• Технический документ: Обзор Internet-native архитектуры SASE ↗ (10 минут на чтение)
• Блог: Zero Trust, SASE и SSE: базовые концепции для сети нового поколения ↗ (14 минут на чтение)

Прочитав эту эталонную архитектуру, вы узнаете:

• Как Cloudflare One защищает сотрудников, устройства, приложения, данные и сети организации
• Как Cloudflare One вписывается в существующую инфраструктуру и как подойти к переходу на архитектуру SASE
• Как спланировать развертывание Cloudflare One

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

Раньше большинство сотрудников работали в офисе и подключались к корпоративной сети локально через Ethernet или Wi-Fi. Большинство корпоративных систем (например, файловые серверы, принтеры, приложения) находились в этой внутренней сети и были доступны только из неё. После подключения пользователи обычно получали широкий доступ к локальным ресурсам. Вокруг сети создавался периметр безопасности для защиты от внешних угроз, большинство из которых исходило из публичного интернета. Основная часть корпоративных рабочих нагрузок размещалась локально и была доступна только внутри сети, а данные и приложения компании почти или совсем не выходили в интернет.

Однако три важные тенденции создали проблемы для подхода к ИТ-безопасности по принципу «замка и рва»:

1. Сотрудники стали более мобильными. Организации все чаще переходят на удаленную и гибридную работу и разрешают использование личных устройств (то есть не принадлежащих компании).
2. Ускоренная облачная миграция. Организации переносят приложения, данные и инфраструктуру из дорогостоящих локальных дата-центров в публичные или частные облачные среды, чтобы повысить гибкость, масштабируемость и экономическую эффективность.
3. Киберугрозы изменились. Перечисленные выше тенденции расширяют поверхность атаки организации. Например, кампании атак становятся все более изощренными и настойчивыми, используя сразу несколько каналов проникновения в организации, а порог входа для киберпреступников снижается благодаря популярности теневого рынка "cybercrime-as-a-service".

Традиционная защита на основе периметра плохо справляется с этими изменениями. В частности, расширение «рва» наружу усложняет работу администраторов, ухудшает опыт пользователей и приводит к тому, что средства защиты применяются к пользователям и приложениям непоследовательно.

На диаграмме выше показан пример такого адаптированного периметрового подхода, в котором межсетевые экраны, WAN-маршрутизаторы и VPN-концентраторы соединены выделенными WAN-каналами на базе MPLS-каналов и (или) арендованных линий. Диаграмма также демонстрирует типичные проблемные места. Стремясь централизовать политику, организации иногда направляют весь интернет-трафик сотрудников через свою VPN-инфраструктуру, из-за чего просмотр страниц замедляется и пользователи жалуются. В ответ сотрудники ищут обходные пути, например используют неутверждённые устройства, что повышает их уязвимость перед атаками из интернета при работе из дома или через публичный Wi-Fi. Кроме того, из-за сложности сетевой инфраструктуры ИТ-команды не успевают быстро реагировать на меняющиеся потребности бизнеса.

Такие сложности заставляют многие организации ставить в приоритет такие цели, как:

• Повышение гибкости бизнеса за счёт поддержки удалённой и гибридной работы с безопасным доступом любого типа
• Повышение продуктивности за счёт упрощения управления политиками и удобства работы пользователей
• Снижение киберрисков за счет защиты пользователей и данных от фишинга, программ-вымогателей и других угроз по всем каналам
• Объединение видимости и контроля в области сети и безопасности
• Снижение затрат за счет замены дорогостоящих устройств и инфраструктуры (например, VPN, аппаратных межсетевых экранов и MPLS-соединений)

В последние годы secure access service edge ↗, или SASE, стала желаемой архитектурой, помогающей достичь этих целей. В архитектуре SASE сетевое подключение и безопасность объединены в единой облачной платформе с единой панелью управления, что обеспечивает согласованную видимость, контроль и опыт для любого пользователя и любого приложения.

Платформы SASE состоят из сетевых служб и служб безопасности, которые опираются на вспомогательные операционные службы и движок политик:

• Сетевые сервисы передают трафик из множества сетей в единую глобальную корпоративную сеть. Эти сервисы предоставляют такие возможности, как экранирование трафика, маршрутизация и балансировка нагрузки.
• Службы безопасности применяются к трафику, проходящему через сеть, что позволяет фильтровать определённые типы трафика и контролировать, кто и к чему получает доступ.
• Операционные сервисы предоставляют общеплатформенные возможности: журналирование, доступ к API и полноценную поддержку Infrastructure-as-Code через провайдеры, такие как Terraform.
• Механизм политик интегрирован со всеми службами и позволяет администраторам задавать политики, которые затем применяются ко всем подключённым службам.

Большинство организаций переходят к архитектуре SASE постепенно, а не сразу: сначала закрывают ключевые задачи безопасности и подключения, внедряя такие сервисы, как Zero Trust Network Access ↗ (ZTNA) или Secure Web Gateway ↗ (SWG). Некоторые организации предпочитают использовать сервисы SASE от нескольких поставщиков. Однако для большинства организаций цель состоит в том, чтобы консолидировать безопасность у одного поставщика и добиться упрощённого управления, полной прозрачности и единообразного опыта.

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

Connectivity cloud от Cloudflare также предлагает множество других сервисов, повышающих производительность и безопасность приложений, например API Gateway ↗, Web Application Firewall ↗, Доставка контента ↗, или Подавление DDoS-атак ↗, каждый из которых может дополнить SASE-архитектуру организации. Например, возможности нашей сети доставки контента (CDN) можно использовать для повышения производительности корпоративного интранета, размещенного самостоятельно. Полный спектр сервисов Cloudflare показан ниже.

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

Anycast обеспечивает сбалансированную работу сети Cloudflare. При резком росте трафика нагрузка распределяется между несколькими дата-центрами, что помогает поддерживать стабильное и надежное соединение для пользователей. Кроме того, за счёт того, что Cloudflare располагает большой пропускная способность сети ↗ и Умная маршрутизация с оптимизацией для ИИ и МО ↗ также помогают обеспечивать постоянную оптимизацию производительности.

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

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

В верхней части диаграммы показаны различные интернет-ресурсы (например, Facebook), SaaS приложения (например, ServiceNow) и приложения, работающие в инфраструктура как услуга (IaaS) ↗ платформе (например, AWS). Эта организация в примере уже развернула облачные поставщики идентификации ↗ (IdP), единое управление конечными точками ↗ (UEM) и платформы защиты конечных точек (EPP) в рамках инициативы Zero Trust.

В нижней части показаны различные пользователи, устройства, сети и локации. Пользователи работают из самых разных мест: из дома, из головного офиса и филиалов, из аэропортов и так далее. Используемые ими устройства могут находиться под управлением организации, а могут быть личными. Помимо облака, приложения работают в дата-центре головного офиса организации, а также в колокейшн-объекте оператора дата-центра (Equinix ↗, в этом примере).

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

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

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

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

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

• В операционной системе, установленной на физическом сервере
• В операционной системе, работающей в виртуализированной среде
• В контейнер ↗ работающих в среде Docker или Kubernetes

cloudflared работает в операционных системах Windows, Linux и macOS и создаёт зашифрованный туннель с использованием QUIC, современного протокола, который применяет UDP (вместо TCP) для высокой производительности туннеля и соответствия современным стандартам шифрования. В целом существует два подхода к развёртыванию cloudflared в своей среде:

1. На том же сервере и в той же операционной системе, где работает приложение или сервис. Обычно это применяется во внедрениях с высоким уровнем риска или строгими требованиями к соответствию, где организациям нужны отдельные туннели для каждого приложения. cloudflared потребляет незначительный объём CPU и RAM, поэтому влияние на производительность сервера минимально.
2. На выделенном сервере (или серверах) в той же сети, где работают приложения. Часто это реализуется в виде нескольких контейнеров в среде Docker или Kubernetes.

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

Для более точного контроля над трафиком, направляемым через каждое туннельное соединение, пользователи могут интегрироваться с Cloudflare балансировка нагрузки сервиса. Для обеспечения надёжного локального подключения организациям следует развернуть более одного экземпляра cloudflared в инфраструктуре своих приложений. Например, при десяти веб-серверах на фронтенде, работающих в кластере Kubernetes, вы могли бы развернуть три сервиса kubernetes запуск cloudflared реплики.

После установления туннелей есть два способа направить пользовательский трафик к вашему приложению или сервису. Каждый из них защищен политиками сервиса ZTNA, который обеспечивает аутентификацию и контроль доступа (подробнее об этом далее в этом документе).

Каждое публичное имя хоста привязано к конкретному адресу, протоколу и порту приватного приложения, что позволяет ограничить доступ до одного конкретного сервиса, даже если на одном хосте работает несколько приложений.

Например, организации могут определить публичный хост (mywebapp.domain.com) чтобы предоставить доступ к веб-серверу, работающему на https://localhost:8080, не допуская при этом доступа к локальным сервисам Kubernetes.

Основные возможности:

• Имя хоста создаётся в публичной зоне DNS, и все запросы к этому имени хоста сначала направляются в сеть Cloudflare, где проверяются на соответствие настроенным политикам безопасности и доступа, а затем направляются через туннель к защищённому приватному ресурсу
• Для одного туннеля можно задать несколько имён хостов, и каждое из них соответствует одному приложению (адрес и порт сервиса)
• Поддержка протоколов HTTP/HTTPS
• Для доступа к ресурсам достаточно браузера
• Когда клиент устройства Cloudflare развёрнут на пользовательском устройстве, политики могут использовать дополнительные контекстные сигналы (например, определение того, управляется ли устройство или используется ли на нём последняя версия ОС) при применении политик
• Для доступа к сервисам SSH/VNC Cloudflare отображает терминал SSH/VNC в браузере с помощью WebAssembly

Приложения, опубликованные таким способом, получают все преимущества ведущих на рынке сервисов Cloudflare DNS, CDN и защиты от DDoS, а также межсетевого экрана веб-приложений (WAF), API и сервисов защиты от ботов, при этом серверы приложений не выставляются напрямую в интернет.

В некоторых случаях пользователям может понадобиться применять политики ZTNA для доступа сразу ко многим приложениям во всей частной сети. Это даёт больше гибкости в способах подключения клиентов и предоставления доступа к сервисам, а также позволяет обмениваться данными по протоколам, отличным от HTTP. В этом случае пользователи указывают подсеть частной сети, к которой нужен доступ через Cloudflare.

Основные возможности:

• cloudflared, в сочетании с агентом на устройстве Cloudflare предоставляет доступ к частным сетям, позволяя устанавливать произвольные соединения L4 по TCP, UDP или ICMP
• Можно настроить одну или несколько сетей с помощью нотации CIDR (например, 172.21.0.16/28)
• Для доступа к ресурсам приватной сети на клиентских устройствах должен быть установлен агент устройства Cloudflare, а в подключаемой сети, хотя бы один сервер Cloudflare Tunnel

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

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

Если пользователям нужно, чтобы соединения, исходящие от сервера или сети, маршрутизировались через Cloudflare, для этого есть несколько способов подключения; подробнее об этом рассказано в разделе «Connecting Networks».

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

SWG включает политики, которые проверяют исходящие запросы трафика и входящие ответы с контентом, чтобы определить, имеет ли пользователь, устройство или сетевое расположение доступ к ресурсам интернета. С помощью этих политик организации могут контролировать доступ к одобренным SaaS-приложениям, а также обнаруживать и блокировать использование неодобренных приложений (также известных как теневой ИТ ↗).

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

Ещё один способ защитить доступ к SaaS-приложениям: настроить единый вход (SSO) так, чтобы Cloudflare выступал в роли прокси идентификации, то есть в роли поставщика идентификации (IDP), в процессе аутентификации и авторизации.

Основные возможности:

• Применяйте единые политики доступа как к самостоятельно размещённым, так и к SaaS-приложениям
• Встраивать оценку состояния безопасности устройства в процесс аутентификации (например, чтобы к SaaS-приложениям могли получить доступ только управляемые устройства с последней версией операционной системы, прошедшие все проверки безопасности конечных точек)
• Обеспечение использования определенных сетевых маршрутов для доступа (например, можно требовать, чтобы устройства подключались к Cloudflare через агент устройства, что позволяет фильтровать трафик к SaaS-приложению и предотвращать скачивание защищенных данных)
• Централизуйте SSO-приложения в Cloudflare и создайте единую SSO-интеграцию между Cloudflare и своим IdP: это делает инфраструктуру и политики доступа независимыми от конкретного SSO (например, можно разрешить доступ к критически важным приложениям только при использовании MFA, независимо от того, какой IdP применяется для аутентификации)

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

Последний способ подключения SaaS приложений к архитектуре SASE Cloudflare основан на брокер безопасного доступа в облако ↗ (CASB). CASB Cloudflare интегрируется через API с популярные SaaS-пакеты (включая Google Workspace, Microsoft 365, Salesforce и другие) и непрерывно проверяет эти приложения на предмет ошибок конфигурации, несанкционированной активности пользователей и других угроз безопасности.

Встроенная интеграция с Cloudflare предотвращение потери данных ↗ (DLP) позволяет CASB сканировать конфиденциальные или регулируемые данные, которые могут храниться в файлах с неверными правами доступа, что создаёт дополнительный риск утечки или несанкционированного доступа. CASB формирует отчёты, уведомляя ИТ-команды о таких проблемах, как:

• Административные учётные записи без надлежащей MFA
• Конфиденциальные данные компании в файлах с публичными правами доступа
• Отсутствующие настройки приложений (например, домены без записей SPF/DMARC)

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

• Все самостоятельно размещённые приложения и сервисы доступны только через Cloudflare и контролируются политиками, определёнными в Cloudflare ZTNA
• Трафик SaaS-приложений фильтруется и защищается через Cloudflare SWG
• Cloudflare CASB сканирует SaaS-сервисы, проверяя настройки и права доступа к хранящимся данным

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

Когда весь трафик проходит через Cloudflare, сервисы SASE выполняют следующие действия:

• Предоставление доступа к приложению
• Фильтрация общего трафика, направленного в Интернет (например, блокировка доступа к сайтам, распространяющим вредоносное ПО)
• Изоляция сайтов для защиты пользователей от вредоносного контента нулевого дня или ещё неизвестных угроз в интернете
• Фильтрация трафика для выявления данных, определённых политиками DLP, с последующей блокировкой скачивания и загрузки этих данных на незащищённые устройства или в приложения
• Обеспечение видимости использования неодобренных приложений и предоставление администраторам возможности блокировать их или применять к ним политики

Существует несколько подходов к подключению сетей к Cloudflare, которые дают организации дополнительную гибкость в предоставлении доступа к ресурсам, защищенным SASE:

1. Используйте программные агенты для создания туннелей от хост-машин к Cloudflare. Обычно этот метод предпочитают пользователи, владеющие собственными серверами и приложениями.
2. Настройте туннели IPsec или GRE от сетевых маршрутизаторов и брандмауэров для подключения к сервису Cloudflare WAN. Такой подход используют сетевые администраторы, когда нужно перенаправлять трафик к целым сетям и от них.
3. Прямое подключение сети к Cloudflare. Этот метод лучше всего работает, когда сеть организации размещена в поддерживаемом дата-центре, как правило, в режиме колокации с дата-центром Cloudflare.

Эти методы подробнее рассматриваются в следующих разделах.

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

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

Использование cloudflared, Cloudflare Tunnel поддерживает соединения от клиента к серверу через туннель. Любой сервис или приложение, работающее за туннелем, будет использовать таблицу маршрутизации по умолчанию при инициировании исходящих соединений.

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

Для двунаправленного или ячеистого подключения организациям следует использовать Cloudflare Mesh.

Cloudflare Mesh (ранее WARP Connector) представляет собой лёгкое решение для site-to-site, двунаправленного и mesh сетевого взаимодействия, не требующее изменений в существующей инфраструктуре маршрутизации сети. Cloudflare Mesh устанавливается на Linux сервер в сети организации, который затем становится шлюзом для других локальных сетей, которым нужно направлять трафик в Cloudflare.

Это лёгкое решение для поддержки таких служб, как Microsoft System Center Configuration Manager (SCCM), обновления серверов Active Directory, трафик VOIP и SIP, а также рабочие процессы разработчиков со сложным взаимодействием CI/CD. Его можно запускать в дополнение к cloudflared и Cloudflare WAN (ранее Magic WAN), либо может выступать в роли отдельного коннектора удалённого доступа и соединения сайт к сайту с сетью Cloudflare.

Cloudflare Mesh может проксировать как соединения между пользователем и сетью, так и между сетями, а также использоваться для создания оверлейной сети Carrier Grade NAT (CGNAT ↗) конечных точек для обеспечения безопасного прямого подключения к существующим ресурсам с использованием диапазонов IP-адресов CGNAT. Это помогает решить проблемы пересечения диапазонов IP-адресов в сети, проблемы точечных решений доступа или задачу изменения сетевой архитектуры без влияния на более крупную базовую систему.

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

Cloudflare Tunnel через cloudflared это основной метод подключения пользователей к приложениям и сервисам в частных сетях, поскольку для многих владельцев приложений это более простое, детализированное и гибкое решение (в отличие от технологий подключения на основе IP-туннелей, таких как IPsec ↗ и GRE ↗). Cloudflare Mesh является предпочтительным способом организации ячеистых и других программно определяемых сетей (большинство из них требуют двусторонней связности), когда организации не хотят изменять базовую маршрутизацию сети или граничную инфраструктуру.

Там, где установка программных агентов нежелательна или невозможна, сети также можно подключать к Cloudflare с помощью существующего сетевого оборудования, например маршрутизаторов и сетевых межсетевых экранов. Для этого организации создают туннели IPsec или GRE, подключаемые к облачному Cloudflare WAN ↗ сервиса. С Cloudflare WAN существующее сетевое оборудование может подключаться и направлять трафик из своих сетевых узлов в Cloudflare через a) защищённые туннели на основе IPsec через интернет или b) через Cloudflare Network Interconnect ↗ (CNI): прямые частные соединения, связывающие существующие сетевые площадки с ближайшим дата-центром Cloudflare.

WAN-сервис Cloudflare использует архитектуру «light-branch, heavy-cloud», которая представляет собой следующий этап развития программно-определяемых WAN-сетей (SD-WAN). Как показано на диаграмме сетевой архитектуры ниже, глобальная сеть Cloudflare в случае Cloudflare WAN выступает в роли централизованно управляемого узла подключения, который безопасно и эффективно маршрутизирует трафик между всеми существующими сетевыми локациями:

Как уже говорилось, Cloudflare использует технику маршрутизации под названием anycast ↗ чтобы анонсировать по всему миру все службы и конечные точки в сети Cloudflare, включая конечные точки для туннелей WAN IP.

С anycast IPsec ↗ или anycast GRE туннели: каждый туннель, настроенный на сетевом устройстве организации (например, граничном маршрутизаторе, межсетевом экране и так далее), подключается к сотням глобальных центров обработки данных Cloudflare. Трафик из сетевой локации организации отправляется напрямую через эти туннели и всегда направляется в ближайший активный центр обработки данных Cloudflare. Если ближайший центр обработки данных Cloudflare недоступен, трафик автоматически перенаправляется в следующий по близости центр обработки данных.

Для повышения отказоустойчивости сети Cloudflare WAN также поддерживает маршрутизацию Equal Cost Multi-Path (ECMP) между сетью Cloudflare и локацией (локациями) сети организации. Благодаря ECMP трафик можно балансировать между несколькими anycast IP-туннелями, что увеличивает пропускную способность и повышает надёжность сети. При сбое одного или нескольких туннелей трафик автоматически переключается на оставшиеся исправные туннели.

Самый простой способ подключить существующие сетевые площадки к сервису Cloudflare WAN заключается в развертывании Cloudflare One Appliance. Это лёгкое устройство, которое можно установить на площадках корпоративной сети для автоматического подключения, управления и формирования любого IP трафика через защищённые туннели IPsec. После установки WAN Connector в сети он автоматически устанавливает связь с сетью Cloudflare, загружает и применяет соответствующие конфигурации, устанавливает устойчивые туннели IPsec и направляет трафик сети подключённой площадки в Cloudflare.

WAN Connector можно развернуть как аппаратное или виртуальное устройство, поэтому он подходит для самых разных сетевых сред: локальных, виртуальных или облачных. Управление, настройка, мониторинг и обновление ПО для WAN Connector выполняются централизованно из Cloudflare через дашборд или Cloudflare API. По состоянию на 2023 год WAN Connector лучше всего подходит для подключения небольших и средних сетей к Cloudflare, например небольших офисов и розничных магазинов.

В ситуациях, когда развёртывание Cloudflare One Appliance невозможно или нежелательно, организации могут безопасно подключить свои сети площадок к Cloudflare, настроив IPsec-туннели на существующих сетевых устройствах с поддержкой IPsec, включая маршрутизаторы WAN или SD-WAN, файрволы и облачные VPN-шлюзы. См. документацию Cloudflare документация актуальные примеры проверенных устройств IPsec.

Также возможны ситуации, когда шифрование на сетевом уровне не требуется, например, если WAN-трафик площадки уже зашифрован на уровне приложений (через TLS) либо если сетевое устройство IPsec обеспечивает очень ограниченную пропускную способность при шифровании и расшифровке трафика IPsec. В таких случаях организации могут подключаться к сети Cloudflare с помощью Туннели GRE.

Организации также могут подключать свои сетевые локации напрямую к сети Cloudflare через Cloudflare Network Interconnect ↗ (CNI). Cloudflare поддерживает широкий спектр вариантов для подключения вашей сети к Cloudflare:

• Прямое подключение CNI для Cloudflare WAN и Magic Transit
• Classic CNI для Magic Transit
• Cloud CNI для Cloudflare WAN и Magic Transit
• Пиринг через точку обмена интернет-трафиком или частный сетевой интерконнект (PNI).

В следующей таблице приведены различные способы подключения сетей к Cloudflare:

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

Обратите внимание на следующие потоки трафика:

• Весь трафик, подключённый через узел Cloudflare Mesh или агент устройства, может взаимодействовать друг с другом через ячеистую сеть
  • Разработчики, работающие из дома, могут взаимодействовать с продуктивными и staging-серверами в облаке
  • Сотрудник в розничной точке, как и разработчик дома, может принимать VOIP-звонки на ноутбуке
• Кластер HPC в AWS представляет собой закрытое решение, в котором нельзя установить сторонние программные агенты, поэтому он использует соединение IPsec с Cloudflare WAN
• В розничной точке Cloudflare One Appliance направляет весь трафик в Cloudflare через IPsec туннель
  • Ноутбук сотрудника с запущенным агентом устройства создаёт собственное защищённое соединение с Cloudflare, которое маршрутизируется через туннель IPsec
• Владелец приложения системы отчётности поддерживает соединение с Cloudflare с помощью cloudflared и не требует какой либо сетевой настройки, чтобы предоставить сотрудникам доступ к приложению

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

Примечание: всем узлам, подключённым через Cloudflare Mesh или device agent, автоматически назначаются IP-адреса из диапазона 100.96.0.0/12, тогда как узлы, подключённые через Cloudflare WAN, сохраняют назначенные им частные IP-адреса RFC1918. cloudflared можно развернуть в любом из расположений владельцем приложения, чтобы обеспечить подключение к приложению по имени хоста.

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

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

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

В предыдущих разделах рассматривалось использование ZTNA для защиты доступа к самостоятельно размещаемым приложениям и SWG для проверки и фильтрации трафика, направленного в интернет. Когда пользователь работает на устройстве в любой из сетей компании, подключённой к connectivity cloud Cloudflare, весь этот трафик проверяется, а политики применяются без нарушения рабочего процесса пользователя. Однако пользователи не всегда (а иногда и никогда) находятся в офисе: они работают из дома, в пути или из других публичных сетей. Как обеспечить надёжный доступ к внутренним приложениям в этом случае? Как обеспечить безопасность работы в интернете независимо от места работы?

Существует несколько подходов, позволяющих направлять через Cloudflare и защищать трафик с устройств пользователей, не подключенных к сети, уже защищенной Cloudflare.

• Установите агент на устройство
• Изменение настроек прокси браузера
• Направление пользователя на экземпляр удалённого браузера
• Изменение настроек DNS

Предпочтительный способ обеспечить перенаправление трафика устройства в Cloudflare заключается в установке агента устройства (также называемого Cloudflare One Client). Агент работает на Windows, macOS, Linux, iOS и Android/ChromeOS и создает защищенное соединение с Cloudflare, через которое отправляется весь нелокальный трафик. Благодаря использованию Cloudflare anycast-сети агент устройства всегда подключается к ближайшему серверу Cloudflare, обеспечивая пользователю наилучшую производительность. Агент устройства также собирает информацию о локальном компьютере и сети, которая передается в запросе для обогащения политики в Cloudflare.

Для гибкости в том, как подключаются разные устройства и пользователи, предусмотрено несколько режимы развёртывания:

• Полноценный прокси трафика уровня L4
• L7 DNS-прокси
• L7 HTTP-прокси
• Возможность собирать только данные о состоянии устройства

Например, в организации может быть офис, который продолжает использовать существующий Фильтрация DNS ↗ сервиса, чтобы настроить агент только на проксирование сетевого и HTTP-трафика.

Агент также можно настроить с гибкими правилами маршрутизации, которые позволяют, например, не отправлять в сеть Cloudflare трафик, предназначенный для офисных принтеров, а направлять его в локальную сеть. Такие конфигурации раздельного туннелирования можно применять к конкретным группам пользователей, типам операционных систем устройств или сетям, при этом по умолчанию трафик, направленный на все частные Диапазоны IPv4 и IPv6 ↗ отправляется на шлюз устройства по умолчанию. Если приложение, к которому пытается обратиться пользователь, отсутствует в публичном DNS, вы можете настроить разрешение имени хоста и домена с помощью локальные DNS-сервисы, чтобы агент на устройстве не пытался разрешать их через Cloudflare DNS.

Функции агента не ограничиваются сетевым прокси: он умеет проверять состояние безопасности устройства, например актуальность операционной системы или наличие шифрования диска. Интеграции Cloudflare с CrowdStrike ↗, SentinelOne ↗, и другие сторонние сервисы также предоставляют дополнительные данные о состоянии безопасности устройства. Вся эта информация связывается с каждым запросом и, соответственно, доступна для использования в политиках компании: подробнее об этом рассказано в разделе "Unified Management".

Агент можно развёрнут на устройство вручную или с помощью существующих технологий управления конечными точками (UEM). С помощью агента пользователи регистрируют и аутентифицируют своё устройство в Cloudflare через интегрированных поставщиков удостоверений. Информация об идентификации в сочетании с информацией о локальном устройстве затем используется в ваших политиках SWG и ZTNA (включая встроенные возможности CASB, общие для этих сервисов Cloudflare).

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

Один из вариантов заключается в том, чтобы настроить браузер на пересылку HTTP-запросов в Cloudflare с помощью параметров прокси-сервера в браузере или ОС. Хотя это можно сделать вручную, чаще организации автоматизируют настройку прокси браузера с помощью размещенных в интернете Автоматическая настройка прокси-сервера (PAC) файлов. Браузер определяет расположение PAC файла несколькими способами:

• MDM-ПО, настраивающее параметр в браузере
• В доменах Windows объекты групповой политики (GPO) могут настраивать PAC-файл браузера
• Браузеры могут использовать Web Proxy Auto-Discovery ↗ (WPAD)

Затем настройте конечную точку прокси, на которую браузер будет отправлять все HTTP-запросы. При использовании этого метода учтите следующее:

• Фильтрация трафика HTTPS также потребует установка корневых сертификатов Cloudflare и добавление их в число доверенных на устройствах.
• Прокси-эндпоинт проксирует только трафик, поступающий с набора известных IP-адресов, например из пула публичных IP-адресов, используемых NAT-шлюзом площадки, которые должен указать администратор.

Ещё один способ гарантировать отправку трафика устройства в Cloudflare: использовать удалённая изоляция браузера ↗ (RBI). Когда удалённый пользователь пытается открыть веб-сайт, соответствующие запросы и ответы обрабатывает headless удалённый браузер, работающий в сети Cloudflare и выступающий «клоном» локального браузера устройства пользователя. Это защищает устройство пользователя от потенциально вредоносного содержимого и выполнения кода, которые могут быть загружены с посещаемого сайта.

RBI отображает полученный контент в изолированной и защищенной облачной среде. Вместо выполнения веб-контента локально устройство пользователя получает команды о том, как «отрисовать» итоговую веб-страницу, по высокооптимизированному протоколу, который поддерживают все браузеры, совместимые с HTML5, на любых операционных системах. Поскольку удаленный браузер работает на серверах Cloudflare, политики SWG автоматически применяются ко всем запросам браузера.

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

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

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

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

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

Ещё один способ защитить трафик через сеть Cloudflare: настроить устройство так, чтобы оно перенаправляло DNS-трафик в Cloudflare для проверки и фильтрации. Сначала Локации DNS создаются, что позволяет применять политики в зависимости от расположения сети. Их можно определить либо по IP-адресу источника запроса, либо с помощью "DNS поверх TLS ↗" или "DNS поверх HTTPS ↗".

При использовании исходных IP-адресов устройству нужно указать, какие DNS-серверы использовать, либо локальный DNS-сервер в сети, к которой подключено устройство, должен перенаправлять все DNS-запросы в Cloudflare. Для поддержки DNS через TLS или HTTPS устройства нужно настраивать, и уровень поддержки может отличаться. Мы рекомендуем использовать DNS через HTTPS, поскольку эта технология поддерживается более широким кругом операционных систем.

Все перечисленные выше методы обеспечивают отправку в Cloudflare только DNS-запросов, а не всего трафика. Затем на этом уровне применяются DNS-политики SWG для управления доступом к ресурсам корпоративной сети.

В следующей таблице приведены возможности SWG для различных способов перенаправления трафика в Cloudflare (по состоянию на октябрь 2023 года):

Примечания:

1. Запуск агента на устройстве в режиме DNS over HTTP даёт информацию о личности пользователя в дополнение к тем же возможностям, что и при подключении через DNS.
2. Для фильтрации HTTPS-трафика Cloudflare сертификат необходимо установить на каждом устройстве. Это можно автоматизировать при использовании агента устройства.
3. При настройке DNS через HTTPS можно внедрить токен службы в запрос, что связывает его с аутентифицированным пользователем.

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

Когда трафик со всех пользовательских устройств направлен в сеть Cloudflare, организациям стоит пересмотреть архитектуру SASE верхнего уровня:

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

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

Однако, прежде чем определять политики для управления таким доступом, организациям необходимо знать, кто именно делает запрос, и оценить состояние безопасности устройства.

Первый шаг в любом решении о доступе: определить, кто делает запрос, то есть аутентифицировать пользователя.

Cloudflare интегрируется с провайдерами идентификации, которые управляют защищенным доступом к ресурсам для сотрудников, подрядчиков, партнеров и других пользователей организации. В том числе поддерживается интеграция с любым SAML - или OpenID Connect (OIDC)-совместимый сервис; Cloudflare One также включает готовые интеграции с Okta, Microsoft Entra ID (ранее Azure Active Directory), Google Workspace, а также потребительских IdP, таких как Facebook, GitHub и LinkedIn.

Можно подключить несколько IdP, что позволяет организациям применять политики к широкому кругу внутренних и внешних пользователей. Когда пользователь пытается получить доступ к приложению или сервису, защищённому Cloudflare, его перенаправляют на аутентификацию через один из подключённых IdP. При использовании device agent пользователи также должны пройти аутентификацию через один из настроенных IdP своей организации.

После аутентификации пользователя Cloudflare получает его данные: имя пользователя, членство в группах, метод аутентификации (пароль, использовалась ли MFA и какого типа) и другие атрибуты, например роль, отдел или местоположение офиса. Эти данные от IdP затем становятся доступны движку политик.

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

Cloudflare также поддерживает аутентификацию устройств, которые обычно не связаны с конкретным пользователем, например IoT-устройства, отслеживающего погодные условия на заводе. Для таких защищённых подключений организации могут создавать токены службы или создать Mutual TLS ↗ (mTLS) сертификаты, которые можно развернуть на таких устройствах или в машинных приложениях.

Важно не только подтвердить личность пользователя, но и оценить состояние безопасности его устройства. Device agent может предоставить широкий набор данных об устройстве, которые Cloudflare использует для формирования комплексных политик безопасности.

Доступны следующие встроенные проверки состояния устройства:

• Проверка приложения: Проверяет, что определённый процесс приложения запущен
• Проверка файлов: Проверяет наличие файла
• Firewall: Проверяет, запущен ли брандмауэр
• Шифрование диска: Проверяет, зашифрованы ли диски и сколько именно
• Domain Joined: Проверяет, подключено ли устройство к домену Microsoft Active Directory
• Версия ОС: Проверяет, какая версия ОС используется
• Уникальный Client ID: При использовании MDM организации также могут присваивать проверяемый UUID мобильному устройству, настольному компьютеру или ноутбуку
• Серийный номер устройства: Проверяет, совпадает ли серийный номер устройства со списком корпоративных настольных и портативных компьютеров

Cloudflare One также может интегрироваться с любым развёрнутым решением для защиты конечных точек, например с Microsoft Endpoint Manager, Tanium, Carbon Black, CrowdStrike, SentinelOne, и не только. Данные из этих продуктов можно передавать в Cloudflare для использования при принятии решений о доступе.

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

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

Электронная почта, инструмент коммуникации #1 для многих организаций и самый распространённый канал фишинговых атак, представляет собой ещё один важный корпоративный ресурс, который нужно защищать в рамках архитектуры SASE. Фишинг лежит в основе более 90% утечек, приводящих к финансовым потерям и ущербу для репутации бренда.

Сервис безопасности почты Cloudflare проверяет письма на признаки вредоносного содержимого или вложений ещё до того, как они попадут во входящие, а также проактивно сканирует интернет на предмет инфраструктуры злоумышленников и механизмов доставки атак, выявляя автоматически созданные домены, которые используются для размещения контента в рамках спланированной атаки. Используя все эти данные, наш сервис также защищает от компрометации деловой переписки и переписки с поставщиками (BEC ↗ / VEC ↗), которые трудно обнаружить из-за отсутствия вредоносной нагрузки и способности выглядеть как легитимная почтовая переписка.

Вместо развёртывания туннелей для управления трафиком к почтовым серверам и контроля над ним Cloudflare предлагает два метода защиты почты настройка:

• Inline: Перенаправление всей входящей почты через Cloudflare до попадания во входящие пользователя путём изменения записей MX
• API: Прямая интеграция Cloudflare с почтовым провайдером, например Microsoft 365 или Gmail

Изменение записей MX (развёртывание inline) направляет весь входящий почтовый трафик через наш облачный сервис безопасности почты, где он сканируется и, если признан вредоносным, блокируется и не попадает в почтовый ящик пользователя. Поскольку сервис работает на уровне записей MX, его можно использовать с любым Совместимый со стандартом SMTP ↗ почтовый сервис.

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

Описанные выше шаги дают полное представление о переходе к архитектуре SASE с помощью Cloudflare One. Как показано на схеме ниже, безопасный доступ ко всем частным приложениям, сервисам и сетям, а также обеспечение безопасности общего доступа пользователей в интернет теперь применяются ко всем пользователям организации, как внутренним, так и внешним.

Примечание: подписи на этом изображении могут отражать предыдущее название продукта.

Для удобства всю платформу Cloudflare One можно настроить через API; а также с помощью Cloudflare Провайдер Terraform ↗, организации могут управлять глобальной сетью Cloudflare с помощью тех же инструментов, которыми они автоматизируют остальную инфраструктуру. Это позволяет ИТ-командам полностью управлять своей инфраструктурой Cloudflare One, включая все политики, описанные в следующем разделе, с помощью кода. Кроме того, по состоянию на октябрь 2023 года существует более 500 GitHub ↗ репозитории, многие из которых позволяют ИТ командам использовать и создавать инструменты для управления своим развёртыванием Cloudflare.

Теперь, когда все пользователи, устройства, приложения, сети и другие компоненты полностью интегрированы в архитектуру SASE, Cloudflare One предоставляет единую платформу для комплексного управления. Благодаря видимости, которой Cloudflare обладает во всей IT-инфраструктуре, он может собирать сигналы из разных источников, включая устройства, пользователей и сети. Эти сигналы используются при формировании политик, регулирующих доступ к ресурсам организации.

Прежде чем углубляться в то, как пишутся политики для управления доступом к приложениям, сервисам и сетям, подключённым к Cloudflare, стоит рассмотреть две основные точки применения политик в платформе SASE от Cloudflare, которые контролируют доступ: SWG и сервисы ZTNA. Эти сервисы настраиваются через единую административную панель, что упрощает управление политиками во всём развёртывании SASE.

Следующая диаграмма показывает путь запроса через эти сервисы, включая применение политик и источник данных для них. На диаграмме ниже запрос пользователя может поступать либо через SWG, либо через ZTNA, в зависимости от типа запрашиваемого сервиса. Также можно комбинировать оба сервиса, например настроить HTTP-политику SWG, которая использует сервис DLP для проверки трафика, связанного с приватно размещённым приложением за Cloudflare Tunnel ZTNA. Такая конфигурация позволяет организациям блокировать загрузку конфиденциальных данных из внутренних приложений, к которым организации разрешили внешний доступ.

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

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

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

Кроме того, SWG от Cloudflare даёт гибкость для создания и поддержания настраиваемых списки данных. Такие списки можно загружать через CSV-файлы, вести вручную или интегрировать с другими процессами и приложениями через Cloudflare API. Список может содержать следующие данные:

• URL-адреса
• Имена хостов
• Серийные номера (macOS, Windows, Linux)
• Письма
• IP-адреса
• Идентификаторы устройств (iOS, Android)

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

Cloudflare анализирует разные аспекты запроса: исходный IP-адрес, запрашиваемый домен и личность аутентифицированного пользователя, который инициировал запрос. Кроме того, Cloudflare предлагает сервис DLP, который умеет обнаруживать и блокировать запросы по наличию чувствительного содержимого. В сервисе есть встроенные профили DLP для распространенных типов данных, таких как финансовая информация, персональные данные (PII) и ключи API.

Существует даже профиль для исходного кода, позволяющий пользователям обнаруживать и блокировать передачу файлов C++ или Python. Организации могут создавать собственные профили DLP и использовать регулярные выражения для определения шаблонов искомых данных. Для данных, шаблон которых сложно определить, можно использовать наборы данных, сопоставляемые с точными значениями. Такие наборы позволяют массово загружать любые данные для сопоставления, например списки идентификаторов учетных записей клиентов или названия конфиденциальных проектов. Эти профили и наборы данных можно включать в политики, чтобы не допустить загрузки пользователями крупных файлов с конфиденциальными данными клиентов.

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

Организации могут дополнительно повысить точность профиля DLP, включив контекстный анализ. Эта функция требует наличия определенных ключевых слов рядом с совпадением, в пределах примерно 1000 символов. Например, строка «123-45-6789» будет засчитана как обнаружение, только если рядом с ней есть такие ключевые слова, как «ssn». Это контекстное условие повышает точность процесса обнаружения.

Сервис DLP интегрируется как со SWG Cloudflare, так и с сервисами API CASB. В случае API CASB для сканирования каждой интеграции с каждым SaaS-приложением выбираются профили DLP. Такая настройка позволяет задавать критерии обнаружения индивидуально, в зависимости от типа данных, которые вы хотите защитить в каждом приложении.

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

Access Groups представляют собой мощный инструмент сервиса ZTNA для объединения пользователей или устройств в единую сущность, на которую можно ссылаться в политике. В Cloudflare несколько единиц информации можно объединить в одну Access Group, что позволяет эффективно повторно использовать данные в разных политиках, храня их в одном централизованном месте.

Рассмотрим Access Group, созданную для управления доступом к критически важной серверной инфраструктуре. Ту же Access Group можно использовать в политике агента устройства, которая не позволяет администраторам отключать соединение с Cloudflare. Такой подход упрощает управление политиками и обеспечивает их согласованность в разных реализациях.

Ниже приведена диаграмма с Access Group под названием «Secure Administrators», который использует ряд атрибутов для описания характеристик привилегированных администраторов. На диаграмме показано добавление ещё двух Access Group внутри «Secure Administrators». В эти группы входят устройства под управлением последней версии Windows или macOS, а также требование, чтобы на устройстве был включён File Vault или Bitlocker.

В соответствии с общей гибкостью подхода Cloudflare группы Access Group можно создавать, изменять и применять к политикам через Cloudflare API или с помощью Terraform. Это позволяет без проблем интегрировать их с существующими IT-системами и процессами и обеспечивает целостный подход к управлению доступом.

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

Одна из распространенных причин перехода на архитектуру SASE заключается в замене существующего VPN-подключения более гибким и безопасным решением. Архитектура Cloudflare One SASE обеспечивает высокую производительность и безопасный доступ к самостоятельно размещенным приложениям из любой точки мира. Следующий шаг заключается в определении политик, которые контролируют доступ к ресурсам.

В этом примере рассмотрим два сервиса: приложение для администрирования базы данных (pgadmin ↗ например) и демоном SSH, запущенным на сервере базы данных. На диаграмме ниже показан поток трафика и выделена служба ZTNA. Важно отметить, что все остальные службы по-прежнему могут проверять запрос. Например, подрядчик, использующий личный мобильный телефон в Германии, должен иметь доступ только к инструменту администрирования БД, тогда как сотрудник на управляемом устройстве может использовать и инструмент администрирования БД, и SSH-подключение к серверу базы данных.

Политики, разрешающие доступ, основаны на двух Access Groups.

• Подрядчики
  • Пользователи, которые проходят аутентификацию через Okta и входят в группу Okta "Contractors"
  • Для аутентификации требуется использование аппаратного токена
• Администраторы баз данных и IT
  • Пользователи, которые проходят аутентификацию через Okta и входят в группы Okta "IT administrators" или "Database administrators"
  • Для аутентификации требуется использование аппаратного токена
  • Пользователи должны использовать устройство, серийный номер которого указан в списке "Managed Devices"

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

• Доступ к инструментам администрирования баз данных
  • Администраторам баз данных и IT разрешён доступ
  • Участникам группы доступа «Contractor» разрешён доступ, но для каждой аутентифицированной сессии пользователю необходимо заполнить запрос с обоснованием
  • Административный инструмент отображается в изолированном браузере в периферийной сети Cloudflare, а загрузка файлов отключена
• SSH-доступ к серверу базы данных
  • группе «Database and IT administrators» разрешен доступ
  • Их устройство должно пройти проверку по оценке риска Crowdstrike не ниже 80
  • Доступ должен осуществляться с устройства, на котором запущен наш агент устройства и которое подключено к Cloudflare

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

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

Ещё одна причина использовать решение SASE: последовательное применение корпоративных политик безопасности ко всем пользователям организации (будь то сотрудники или подрядчики) независимо от того, где они работают. Архитектура Cloudflare One SASE показывает, что весь пользовательский трафик, маршрутизируемый напрямую с устройства или через подключённую сеть, проходит через Cloudflare. Затем Cloudflare SWG выполняет проверку этого трафика. В зависимости от способа подключения политики могут применяться либо к HTTP-, либо к DNS-запросу. Например:

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

При такой настройке каждый запрос к сайту социальной сети проходит через следующие меры безопасности:

• Любой контент на сайте социальной сети, содержащий вредоносный код, не может быть выполнен на локальном устройстве
• Внешним пользователям запрещено скачивать с сайта содержимое, которое потенциально может быть заражено вредоносным или шпионским ПО

Поскольку Cloudflare One обеспечивает видимость каждого сетевого запроса, Cloudflare может создавать политики, применимые к данным в запросе. Это значит, что сервисы DLP можно использовать для обнаружения загрузки контента из приложения и блокировки её для определённых групп пользователей. Рассмотрим следующую политику.

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

Политики DLP также можно применять в обратном направлении, чтобы конфиденциальные документы компании не загружались в неутверждённые облачные хранилища или социальные сети.

На этом этапе пути к SASE пользователи уже перестроили ИТ-сеть и инфраструктуру безопасности, чтобы полностью использовать возможности платформы Cloudflare One SASE. Важнейший элемент долгосрочного внедрения заключается в обеспечении полной видимости организации и способности быстро диагностировать и устранять проблемы.

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

Однако многие организации полагаются на уже имеющиеся специализированные инструменты для долгосрочного контроля производительности своей инфраструктуры. Чтобы это поддержать, Cloudflare позволяет экспортировать все данные журналов в такие инструменты. Каждый аспект работы Cloudflare One фиксируется в журналах и может быть экспортирован. Cloudflare предлагает встроенные интеграции для непрерывной передачи небольших пакетов данных на различные платформы, включая AWS, Google Cloud Storage, SumoLogic, Azure, Splunk, Datadog и любые сервисы, совместимые с S3. Такая гибкость позволяет организациям выборочно выбирать поля, чтобы контролировать тип и объем данных, передаваемых в существующие инструменты.

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

У Cloudflare есть подробная аналитика ↗ в производительность интернета, а также подключенных сетей и устройств. Эти данные дают ИТ-администраторам возможность поминутно отслеживать, как работу воспринимают конечные пользователи, и быстро устранять проблемы, влияющие на продуктивность.

Сервис Digital Experience Monitoring (DEM) позволяет ИТ-отделу постоянно тестировать устройства пользователей, чтобы оценивать качество соединения с ресурсами компании. Результаты этих тестов доступны на дашборде Cloudflare One, что позволяет ИТ-администраторам анализировать их и находить корневые причины проблем, когда конкретный пользователь испытывает трудности с доступом к приложению. Причиной таких проблем может быть как местный интернет-провайдер пользователя, так и конкретный SaaS-провайдер с низкой производительностью. Эти данные незаменимы для администраторов при диагностике и устранении проблем с пользовательским опытом, что ускоряет решение проблем.

Дашборд показывает общую сводку по всему парку устройств, отображая текущие и исторические метрики подключения для всех устройств организации. Администраторы ИТ могут затем углубиться в данные по конкретным устройствам для дальнейшего анализа.

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

Обратите внимание, что многие возможности, описанные в этом документе, можно бесплатно и без ограничений по времени использовать при числе пользователей до 50. Регистрация ↗ для аккаунта и перейдите в Cloudflare One ↗ раздел. Этот документ дал общее представление о платформе в целом, но тем, кто хочет глубже изучить отдельные области, мы рекомендуем ознакомиться со следующими ресурсами.

Если вы хотите подробнее обсудить свои требования к SASE и связаться с одним из наших архитекторов, перейдите на https://www.cloudflare.com/cloudflare-one/ ↗ и запросить консультацию.