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

Безопасная доставка приложений с помощью Cloudflare

Cloudflare предоставляет полный набор сервисов для производительности, безопасности, надежности и разработки приложений, а также для Zero Trust. Глобальная сеть Cloudflare находится на расстоянии около 50 мс от примерно 95% пользователей интернета, и все сервисы в ней работают на каждом сервере каждого дата-центра. Глобальный масштаб Cloudflare также дает надежный источник данных об угрозах, которые постоянно возвращаются в продукты безопасности Cloudflare, еще больше улучшая модели машинного обучения и сами сервисы.

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

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

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

Этот документ демонстрирует, насколько легко использовать совокупность служб Cloudflare независимо от того, где выполняются рабочие нагрузки. В примере из этого документа рабочая нагрузка приложения использует Cloudflare DNS, CDN, WAF и Access, а также Cloudflare Tunnel для безопасного подключения к сети Cloudflare. Немногие поставщики способны предложить такой всесторонний уровень защиты, реализованный настолько операционно простым и последовательным образом.

Дополнительные сведения и эталонные архитектуры по конкретным сервисам см. в документы эталонной архитектуры.

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

При обычном трафике без reverse proxy клиент отправляет DNS-запрос, получает IP-адрес origin-сервера и обращается напрямую к origin-сервер(ы) ↗.

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

В этом примере сайт работает у одного из крупных облачных провайдеров, и мы хотим использовать Cloudflare DNS, CDN, WAF и Access. Для демонстрации мы начнём именно с этих сервисов, а клиенты при желании могут добавить и другие сервисы Cloudflare. Преимущество Cloudflare в том, что все сервисы отделены от облачного провайдера: если позже понадобится сменить провайдера или защитить другие приложения, работающие в других облаках, дашборд и все операции останутся неизменными.

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

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

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

Источник подключён к интернету напрямую, и трафик маршрутизируется к нему на основе IP адреса, определённого через Cloudflare DNS. Запись DNS A связывает доменное имя с IP адресом исходного сервера (серверов) или, как правило, с балансировщиком нагрузки, за которым находятся источники.

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

Кроме того, в этой модели клиенту приходится открывать правила межсетевого экрана для origin или веб-сервера, чтобы он был доступен по соответствующим портам http/https. Однако клиенты могут использовать Dedicated CDN Egress IPs, который выделяет клиенту уникальные IP-адреса, используемые Cloudflare для подключения к вашим источникам (origin). Рекомендуем разрешать трафик только с этих сетей, чтобы избежать прямого доступа.

Помимо блокировки IP-адресов на файрволе со стороны сервера источника, мы настоятельно рекомендуем дополнительно проверять трафик с помощью настройка SSL «Full (Strict)» или аутентификация mTLS чтобы гарантировать, что весь трафик исходит из запросов, проходящих через настроенные клиентом зоны.

Cloudflare также поддерживает Использование собственного IP (BYOIP). После настройки BYOIP глобальная сеть Cloudflare анонсирует собственные IP-префиксы клиента, и эти префиксы можно использовать с соответствующими сервисами Cloudflare уровня 7. Это позволяет клиентам проксировать трафик через Cloudflare, при этом в DNS-разрешении по-прежнему возвращается IP-адрес клиента. Это можно полезно ↗ для случаев, когда префиксы IP клиента уже внесены в список разрешённых, а обновление правил межсетевого экрана нежелательно или сопряжено с административными сложностями.

При подключении источника (источников) через интернет рекомендуется использовать частный туннель или соединение через интернет для дополнительной безопасности.

Традиционная схема VPN не оптимальна, поскольку трафик приходится перенаправлять в централизованное расположение VPN-шлюза, которое затем подключается обратно к источнику, а это негативно сказывается на сквозной пропускной способности и задержке. Cloudflare предлагает Cloudflare Tunnel ПО, которое создаёт зашифрованный туннель между вашим origin-сервером (или серверами) и сетью Cloudflare. Кроме того, поскольку Cloudflare использует anycast в своей глобальной сети, origin-сервер, как и клиенты, подключается к ближайшему дата-центру Cloudflare, что оптимизирует сквозную задержку и пропускную способность.

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

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

Уровень защиты повышается за счёт блокировки всех портов и протоколов сервера источника на вашем межсетевом экране. После настройки Cloudflare Tunnel и применения соответствующих защитных мер все запросы на портах HTTP/S отклоняются, включая волюметрические DDoS-атаки. Попытки утечки данных, такие как перехват данных при передаче или перебор паролей, блокируются полностью.

На приведённой выше диаграмме показана модель подключения через Cloudflare Tunnel. Этот вариант позволяет безопасно подключать ваши ресурсы к Cloudflare без публично маршрутизируемого IP-адреса. Cloudflare Tunnel умеет безопасно подключать к Cloudflare веб-серверы HTTP, серверы SSH, удалённые рабочие столы и другие протоколы.

Большинство поставщиков также предлагают возможность прямого подключения к своей сети. Прямые подключения дают преимущества в безопасности, надёжности и производительности по сравнению с использованием публичного интернета. Такие подключения устанавливаются на пиринговых площадках, интернет-биржах (IX), где интернет-провайдеры (ISP) и другие сети могут соединяться друг с другом, либо через партнёров поставщика.

На приведённой выше диаграмме показано подключение к источнику через Cloudflare Network Interconnect (CNI) ↗ что позволяет подключить вашу сетевую инфраструктуру напрямую к Cloudflare и обмениваться данными только по этим прямым каналам. CNI позволяет клиентам напрямую соединять филиалы и головные офисы с Cloudflare. Подключиться к Cloudflare клиенты могут одним из трех способов: через прямое сетевое соединение (private network interconnect, PNI), доступное в Точки пиринга Cloudflare ↗, через IX в любом из многочисленные глобальные точки обмена трафиком, в которых участвует Cloudflare ↗, или через один из партнёры по платформам межсетевого соединения ↗.

Глобальная сеть Cloudflare обеспечивает простое подключение независимо от того, где находится ваша инфраструктура и сотрудники.

Независимо от используемой модели подключения, разрешение DNS выполняется первым и сообщает Cloudflare, куда направлять трафик. Cloudflare может выступать в качестве авторитетного DNS-провайдера, вторичного DNS-провайдера или поддерживать настройку зоны через сторонний DNS (CNAME). Чтобы к трафику применялись сервисы производительности и безопасности Cloudflare, он должен маршрутизироваться через сеть Cloudflare.

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

В этом примере мы безопасно подключим наш исходный сервер к Cloudflare через Cloudflare Tunnel. Настроить DNS можно в дашборде, указав сайт, который нужно подключить. Вы получите пару неймсерверов Cloudflare, которые нужно будет указать на сайте вашего регистратора домена. После этого Cloudflare станет основным авторитетным DNS провайдером.

Если Cloudflare настроен только для маршрутизации через интернет, конфигурация DNS будет выглядеть примерно так, как показано ниже, где A-запись указывает на IP-адрес исходного сервера или соответствующего балансировщика нагрузки. Поскольку Cloudflare работает как обратный прокси, статус отображается как Proxied. Cloudflare в этом случае по-прежнему выступает в роли обратного прокси, поэтому доступны все сервисы Cloudflare, такие как CDN, WAF и Access.

Cloudflare Tunnel также можно использовать через интернет для повышения безопасности и чтобы не открывать входящие правила брандмауэра для источника (origin). В этом случае вместо A-записи в DNS будет использоваться CNAME-запись, указывающая на развернутый туннель. Здесь туннель разворачивается от источника до сети Cloudflare, а DNS настраивается автоматически. Создается CNAME-запись, указывающая на туннель, что обеспечивает маршрутизацию всего трафика к источнику (источникам) через Cloudflare Tunnel.

Для создания и управления туннелями на сервере-источнике нужно установить cloudflared и пройти авторизацию. Именно cloudflared соединяет ваш сервер с глобальной сетью Cloudflare.

Существует два варианта создания туннеля: через панель управления или через командную строку. Рекомендуется начать работу с Dashboard, так как это позволит управлять туннелем с любого устройства.

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

В дашборде Cloudflare перейдите в Zero Trust > Networks > Connectors. Нажмите кнопку "Create a tunnel", задайте имя туннеля и сохраните изменения.

Далее откроется экран, на котором нужно выбрать операционную систему (OS) вашего origin-сервера. После этого вы получите команду CLI, которую можно выполнить на вашем origin-сервере: она автоматически скачает и установит программное обеспечение Cloudflare Tunnel.

Ниже показана CLI команда, выполненная для загрузки и установки программного обеспечения Cloudflare Tunnel.

Теперь коннектор будет автоматически отображаться как подключённый.

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

Теперь в дашборде видно, что туннель создан и работает исправно.

Если посмотреть на настройки DNS, видно, что автоматически была создана DNS-запись, указывающая на идентификатор туннеля. При создании туннеля Cloudflare генерирует поддомен cfargotunnel.com с UUID созданного туннеля. В отличие от общедоступных маршрутизируемых IP-адресов, этот поддомен проксирует трафик только для DNS-записи в той же учетной записи Cloudflare. Другой пользователь не может создать DNS-запись в другой учетной записи или системе, чтобы проксировать трафик через этот туннель.

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

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

Вам будет предложено выбрать зону, к которой нужно добавить туннель, как показано ниже.

Далее вы авторизуете туннель для зоны.

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

Текущая конфигурация, описанная ранее в этом документе, показана ниже: сервер (или серверы) источника подключены к сети Cloudflare через Tunnel. Теперь можно начать использовать сервисы Cloudflare.

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

Ниже видно, что для cftestsite3.com создано приложение.

Судя по конфигурации политики ниже, для доступа требуется, чтобы пользователь входил в группу Access «Secure Employees».

Если внимательнее посмотреть на группу Access «Secure Employees», можно увидеть, что ее участники входят в группу «Employees» поставщика идентификации (IdP) Okta, используемого компанией. Кроме того, для этой группы Access включена обязательная многофакторная аутентификация (MFA).

На примере приложения «Image and Video Gallery» видно, что в разделе Authentication клиенты также могут вручную выбрать провайдеров идентификации, с помощью которых пользователи смогут подключаться к этому приложению.

Теперь у нас есть защищенный доступ к источнику (источникам) приложения через Tunnel, а также политики аутентификации и доступа к приложению через Access. Когда пользователи пытаются получить доступ к сайту, им показывается страница Cloudflare Access с предложением пройти аутентификацию через настроенный IdP; эту страницу можно настроить по своему усмотрению, как показано ниже.

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

Поскольку Cloudflare уже настроен и работает как обратный прокси для сайта, весь трафик проходит через Cloudflare, а значит, можно без труда задействовать любые сервисы Cloudflare, включая CDN, Security Analytics, WAF, API Shield, Bot Management, защиту на стороне клиента и другие.

Когда клиент отправляет DNS-запрос для соответствующего веб-сайта, в данном случае «cftestsite3.com», Cloudflare возвращает anycast-адрес IP, благодаря чему весь трафик направляется в ближайший дата-центр, где применяются все необходимые сервисы, после чего запрос передаётся через Cloudflare Tunnel на исходный сервер (или серверы).

Cloudflare CDN использует глобальную anycast-сеть периферийных серверов Cloudflare. Помимо anycast для повышения производительности и отказоустойчивости сети, Cloudflare CDN также использует Argo Tiered Cache для получения оптимизированных результатов при экономии затрат клиентов. Клиенты также могут включить Argo Smart Routing чтобы находить самый быстрый сетевой маршрут для запросов к серверу-источнику. Как показано ниже, Cloudflare CDN теперь кеширует контент по всему миру, а для изменения поведения по умолчанию можно применять детализированные политики CDN.

Существуют доступны различные топологии и конфигурации кеширования. Ниже показано, как настроено Cache Rule для кеширования запросов к домену с переопределением TTL источника.

Cloudflare Cache Reserve также была включена нажатием кнопки "Enable storage sync" в разделе "Caching > Cache Reserve" в дашборде. Cache Reserve использует постоянное объектное хранилище Cloudflare, R2, чтобы исключить расходы на исходящий трафик у других публичных облачных провайдеров. Это повышает коэффициент попаданий в кэш, позволяя клиентам постоянно кэшировать данные нажатием одной кнопки.

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

Правила Cloudflare WAF можно применять для встроенного контроля политик в отношении трафика. Ниже настроена политика файрвола, которая регистрирует весь трафик с bot score < 30 и WAF attack score < 50. Bot score < 30 означает, что трафик классифицирован как автоматизированный или, вероятно, автоматизированный, а WAF attack score < 50 означает, что трафик классифицирован как вредоносный или, вероятно, вредоносный.

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

С помощью WAF клиенты могут внедрять и использовать custom rules, rate limiting rules и managed rules. Краткое описание каждого из них приведено ниже.

• WAF Custom Rules: позволяет создавать пользовательские правила на основе различных атрибутов запроса и заголовков для блокировки любых угроз
• WAF Rate Limiting Rules: предотвращает злоупотребления, DDoS-атаки, попытки подбора паролей методом перебора и обеспечивает контроль, ориентированный на API.
• WAF Managed Rules
  • Cloudflare Managed Ruleset: обеспечивает расширенную защиту от уязвимостей нулевого дня
  • Cloudflare OWASP Core Ruleset: блокировка распространённых уязвимостей веб-приложений, часть которых входит в OWASP Top 10
  • Cloudflare Leaked Credential Check: проверяет базу скомпрометированных учётных данных для популярных приложений на основе систем управления контентом (CMS)

Та же методология применяется и для всех остальных продуктов Cloudflare Application Performance and Security (API Shield, Bot Management и других): после настройки маршрутизации трафика через сеть Cloudflare клиенты могут начать использовать сервисы Cloudflare. На рисунке 31 показана Bot Analytics Cloudflare, которая классифицирует трафик по показателю bot score, отображает распределение bot score и другую аналитику по ботам. Все данные запросов собираются inline, и всё применение политик также выполняется inline.

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