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

Мультивендорная эталонная архитектура безопасности и производительности приложений

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

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

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

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

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

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

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

• Как возможности Cloudflare в области безопасности приложений и производительности работают вместе с существующими технологическими поставщиками
• Какие решения нужно принять при использовании множества поставщиков

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

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

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

При использовании обратного прокси клиент по прежнему отправляет DNS-запрос своему резолверу, это первый этап DNS-разрешения. В этом случае DNS-резолвер возвращает клиенту IP-адрес обратного прокси поставщика, и клиент отправляет запрос на этот обратный прокси. Облачное прокси-решение теперь может предоставлять дополнительные сервисы безопасности, производительности и надёжности, такие как CDN ↗, WAF ↗, DDoS ↗, API Shield ↗, Bot Management ↗ возможности и так далее, прежде чем принять решение, на основе политики безопасности, о том, направлять ли клиентский запрос на соответствующий origin-сервер (или серверы). Это показано на рисунке 2.

В некоторых случаях поставщик обратного прокси также предоставляет DNS-услуги; это показано на рисунке 3 ниже. Это удобно для управления всеми сервисами из единого дашборда и упрощает эксплуатацию.

Cloudflare реализует архитектуру обратного прокси на основе своей глобальной anycast-сеть ↗ за соответствующие услуги безопасности, производительности и надёжности. Anycast представляет собой метод сетевой адресации и маршрутизации, при котором входящие запросы могут направляться в разные точки, или ‘узлы’, анонсирующие одно и то же адресное пространство IP. Благодаря anycast, а также глобальному присутствию в сотни городов по всему миру ↗. Cloudflare также напрямую подключена к 12,000 сетей, включая всех крупных интернет-провайдеров, облачных провайдеров и корпоративных клиентов, и находится на расстоянии не более ~50 ms от 95% населения мира, подключенного к интернету.

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

Глобальная anycast-сеть Cloudflare ↗ предоставляет следующие преимущества:

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

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

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

Основное требование: трафик должен проксироваться через Cloudflare, это также называют «orange-clouded», поскольку трафик к сайту проходит через прокси Cloudflare. В дашборде для конкретной DNS-записи будет отображаться статус «Proxied» и значок оранжевого облака, как показано на рисунке 5 ниже.

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

1. Полная настройка DNS: Cloudflare в роли основного DNS-провайдера

Cloudflare настраивается как основной DNS-провайдер, а записи A настраиваются так, чтобы направлять трафик через Cloudflare по прокси. Когда для DNS-записи включено проксирование, в ответ возвращаются anycast-адреса Cloudflare, что и позволяет Cloudflare выступать прокси.

2. Настройка Secondary DNS с переопределением Secondary DNS

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

3. Частичная настройка / настройка CNAME

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

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

Если текущий поставщик DNS клиента не поддерживает CNAME в корне зоны (иногда называемом «корневым доменом» или «голым доменом»), как это делает Cloudflare с помощью CNAME Flattening, необходимо приобрести Static IP у Cloudflare и создать A-запись на эти Static IP в DNS провайдера. После этого в Cloudflare можно создать A-запись, указывающую apex зоны на источник.

Многие клиенты, использующие сервисы Cloudflare, пользуются преимуществами интеграции между продуктами и нововведениями, а также простотой единого интерфейса для управления и эксплуатации, применяя несколько сервисов Cloudflare совместно, например CDN и WAF. Хотя это не рекомендуется, сервисы безопасности, такие как WAF, можно использовать и с другими поставщиками CDN, настроив DNS так, чтобы трафик направлялся через Cloudflare с помощью CNAME, и отключив кэширование Cloudflare через Cache Rules.

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

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

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

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

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

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

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

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

Избегайте «многослойного» подхода. Это означает, что Cloudflare не должен располагаться в цепочке запросов позади другого поставщика. Компании нередко рассматривают такое наслоение поставщиков, рассчитывая на эшелонированную защиту: один и тот же трафик последовательно проходит через каждый слой. В теории это позволяет применять политики обоих поставщиков, и вредоносный трафик, пропущенный одним из них, будет перехвачен следующим. На практике результат оказывается совсем другим. Главный недостаток такой схемы: при работе позади другого поставщика теряется полная видимость трафика, что мешает работе многих сервисов Cloudflare, использующих анализ угроз, таких как Bot Management, Rate Limiting, защита от DDoS и база данных репутации IP адресов. Это также крайне негативно сказывается на производительности, поскольку трафик проходит через две сети, каждая со своими издержками на обработку и установление соединений, прежде чем вернуться к источнику. Кроме того, такая схема без необходимости усложняет эксплуатацию, управление и поддержку.

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

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

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

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

Здесь можно использовать балансировку нагрузки на основе DNS и проверки работоспособности, чтобы запросы клиентов к домену или сайту распределялись между исправными исходными серверами. Провайдер DNS отслеживает состояние серверов, а DNS отвечает на запрос клиента по круговому принципу (round-robin), используя соответствующие IP-адреса.

Если для повышения отказоустойчивости на уровне DNS также нужен подход с несколькими поставщиками, возможны разные конфигурации с несколькими авторитативными серверами имен от разных поставщиков. Подробнее об этом см. раздел «Варианты настройки DNS с несколькими поставщиками» в этом документе. Здесь важнее всего обеспечить согласованность конфигураций у разных поставщиков. В зависимости от настройки DNS эта согласованность может достигаться разными способами: с помощью передачи зон, автоматизации через такие инструменты, как Terraform или OctoDNS, мониторинга и автоматизации посредством скриптов или даже вручную.

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

Здесь особенно важна поддержка API для всей функциональности продукта поставщика. Согласованность настроек важна не только для маршрутизации в некоторых схемах DNS с несколькими поставщиками, но и для поддержания единообразия между всеми соответствующими сервисами, такими как WAF, API security и другими, поскольку трафик может направляться к любому из поставщиков. Такие инструменты автоматизации, как Terraform, или собственные скрипты автоматизации используют API для поддержания этой согласованности между поставщиками.

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

Клиенты отправляют запросы через интернет, и эти запросы маршрутизируются к прокси-сервису соответствующего поставщика в его облаке. В самом простом сценарии прокси просто передаёт трафик через интернет на источник; это конфигурация по умолчанию.

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

Cloudflare предлагает все эти варианты подключения вместе со Smart Routing, чтобы трафик всегда шел к исходному серверу самым быстрым путем. Подробнее эти варианты подключения рассматриваются в разделе «Варианты подключения Cloudflare» этого документа.

Эксплуатация и устранение неполадок

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

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

Кроме того, Cloudflare предоставляет логирование, аналитику и дашборды Security Analytics. Логи с дополнительными сведениями также доступны в UI. Клиенты получают детализированные данные, которые можно использовать для анализа и устранения неполадок.

На рисунке 7 ниже показан вид Cloudflare Security Analytics, который объединяет все возможности обнаружения Cloudflare в одном месте. Это даёт инженерам по безопасности и администраторам быстрый обзор текущего трафика и данных о безопасности своего сайта.

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

На рисунке 8 ниже показана настройка Logpush для автоматической выгрузки логов на внешний ресурс.

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

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

Диаграмма ниже описывает типичную конфигурацию с несколькими поставщиками, в которой оба поставщика «активны», то есть оба обслуживают трафик для одного и того же ресурса (www.example.com) и трафик распределяется между ними.

Что касается маршрутизации, в этом примере авторитетный DNS расположен отдельно от обоих провайдеров и распределяет нагрузку между ними. Этот DNS-провайдер может быть развернут самостоятельно или размещен у другого стороннего провайдера. Трафик направляется к каждому провайдеру в ответ на запросы к www.example.com с записью CNAME конкретного провайдера или статическим IP-адресом для трафика apex-домена. Чтобы обеспечить такое разделение трафика, сторонний DNS-провайдер должен обладать некоторой возможностью балансировки нагрузки. У большинства крупных DNS-провайдеров есть тот или иной механизм балансировки нагрузки на основе DNS с разной степенью сложности и настраиваемости. В простейшем случае это может быть round robin между записями, а в более сложном случае: изменение ответа в зависимости от местоположения клиента, данных проверки работоспособности и других факторов.

В зависимости от авторитативного DNS-провайдера трафик можно равномерно распределять между двумя провайдерами или динамически перенаправлять. Часто клиенты используют данные о производительности и доступности от сторонних сервисов мониторинга, таких как Thousandeyes или Catchpoint, чтобы на их основе корректировать DNS-маршрутизацию и ответы DNS. Сторонние сервисы мониторинга часто применяются для сбора полных метрик HTTP-запросов и ответов, чтобы маршрутизировать трафик с учётом производительности в реальном времени. Перенаправить трафик от одного провайдера легко: достаточно обновить авторитативный DNS и дождаться истечения TTL записи.

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

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

Если используется только один внешний поставщик DNS, это создает единую точку отказа на случай сбоя у этого поставщика. Снизить этот риск можно за счет внедрения решения DNS с несколькими поставщиками; подробнее об этом рассказано в Варианты мультивендорного DNS раздел этого документа.

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

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

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

Между разными поставщиками DNS возможны разные варианты настройки: они подробно рассматриваются в разделе «Настройка DNS у нескольких поставщиков» этого документа, с указанием преимуществ и недостатков каждого варианта.

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

Чтобы в этой модели направлять запросы обоим поставщикам (для одних и тех же хостов), поставщик, настроенный как вторичный, должен иметь возможность переопределять записи, предназначенные для прохождения через прокси. Без такой возможности переопределения записей на вторичном сервере адрес назначения для всех основных записей оставался бы статичным, что снижало бы гибкость и отказоустойчивость всей схемы. Cloudflare предоставляет эту возможность с помощью Переопределение вторичного DNS. Например, если провайдер вроде Cloudflare настроен как вторичный, DNS автоматически синхронизируется в Cloudflare с первичного сервера через zone transfer, и с помощью Secondary DNS override можно обновить A-запись так, чтобы она указывала на собственные прокси или сервисы Cloudflare.

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

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

Здесь важно отметить, что DNS-резолверы, как правило, уже сталкивались с запросами и ответами, связанными с используемыми серверами имён. Например, сервер имён, который поставщик присваивает клиенту, может уже использоваться другими сайтами в качестве авторитетного DNS, и у резолверов уже накоплены обширные исторические данные о производительности, которые можно сразу начать использовать.

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

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

Некоторые DNS-провайдеры, такие как Cloudflare предоставляют возможность перезаписи записей A и AAAA вторичным DNS. Это позволяет поставщику при необходимости переписать запись A/AAAA, чтобы направить трафик через другого поставщика. В этом случае вторичный поставщик DNS выдаст для того же хоста иной ответ, чем основной. Это означает, что в зависимости от того, к какому серверу имён обращается резолвер клиента, запрос будет направлен в сеть соответствующего поставщика. Такой подход даёт гибкость и снижает сложность, поскольку за выбор маршрута и переключение при отказе отвечает резолвер клиента, если серверы имён работают медленно или недоступны. Платой за это становится потеря прямого контроля и предсказуемости в отношении того, какого поставщика выберет клиент.

Ещё один вариант: разместить конкретные приложения и имена хостов у конкретных провайдеров. В приведённом выше примере это может означать, что и основной, и резервный DNS-серверы имеют www.example.com сопоставленный с адресом Cloudflare, независимо от того, какой провайдер разрешает первоначальный DNS-запрос.

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

1. Два авторитетных сервера: один основной и один вторичный

В этой схеме один провайдер назначается основным, а второй вторичным. Назначение вторичного DNS: поддержка многодоменных DNS-решений, в которых синхронизация конфигураций основного и вторичного провайдеров происходит автоматически.

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

Преимущество и основной сценарий использования этой модели развёртывания в том, что она опирается на стандарт синхронизации DNS между несколькими провайдерами, созданный именно для этой цели, а за передачу зон отвечает сам DNS-провайдер. Такой вариант упрощает поддержание синхронизации DNS между провайдерами.

Иногда клиенты выбирают другой вариант по следующим причинам:

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

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

Преимущества:

• Использует стандартные механизмы (AXFR, IXFR) для синхронизации DNS, выполняемой автоматически через Zone Transfers.
• Простота, поскольку за синхронизацию DNS отвечает сам DNS-провайдер.

Недостатки:

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

2. Два авторитетных сервера: оба основные

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

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

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

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

Преимущества:

• Если плоскость управления у одного поставщика недоступна, записи DNS все равно можно обновить у другого.
• Больше контроля и отсутствие зависимости от поставщика DNS для синхронизации DNS.

Недостатки:

• Более высокая сложность синхронизации DNS между поставщиками.
• За синхронизацию DNS отвечает клиент: её можно выполнять с помощью инструментов автоматизации, через API поставщика или вручную.

3. Один или несколько авторитетных серверов: скрытый основной и несколько вторичных

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

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

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

Преимущества:

• Позволяет заказчикам управлять DNS-записями на своей инфраструктуре и использовать стандартные средства для автоматической синхронизации DNS с помощью Zone Transfers.
• Основной сервер служит исключительно источником достоверных данных и используется для ведения записей DNS, поэтому его можно отключать для технического обслуживания и администрирования.

Недостатки:

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

Рисунок 11 показывает типичную схему управления конфигурациями одновременно в Cloudflare и у других провайдеров. В этом примере предполагается, что одна и та же нагрузка распределяется между двумя провайдерами, а администраторы обновляют обе конфигурации через API с помощью Terraform. Этот процесс можно также встроить во внутренний CI/CD конвейер, чтобы он соответствовал вашему обычному процессу разработки. Все функции Cloudflare можно настроить через API, и именно через API они становятся доступны в первую очередь. Диаграмма также показывает, как журналы отправляются в общий SIEM, а встроенные функции оповещения могут доставлять уведомления по электронной почте, через webhook или PagerDuty при срабатывании оповещений по критериям производительности, безопасности или администрирования.

Благодаря широкому набору возможностей настройки, которые предоставляет Cloudflare (Ruleset Engine, встроенные функции, настройки Worker), Cloudflare способна обеспечить функциональный паритет с большинством крупных вендоров на рынке, однако нет гарантии, что нужные функции будут настраиваться так же. Именно поэтому тесная работа с командой Cloudflare, отвечающей за ваш аккаунт, становится критически важной: она помогает разобраться в ключевых отличиях в работе сервиса и в лучших практиках, чтобы выстроить процесс работы под Cloudflare.

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

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

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

При желании клиенты также могут использовать Dedicated CDN Egress IPs, который выделяет клиенту уникальные IP-адреса, используемые Cloudflare для подключения к вашим источникам (origin). Рекомендуем разрешать трафик только с этих сетей, чтобы избежать прямого доступа. Помимо блокировки по IP на файрволе источника, настоятельно рекомендуем дополнительно проверять трафик с помощью режима SSL "Full (Strict)" или аутентификации mTLS, чтобы гарантировать, что весь трафик проходит через настроенные клиентом зоны.

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

Ещё один вариант: использовать частный туннель или соединение через интернет для дополнительной защиты. Некоторые поставщики предлагают частную связность через туннели или 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 обеспечивает простое подключение независимо от того, где находится ваша инфраструктура и сотрудники.

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

Cloudflare предлагает Argo Smart Routing для поиска и использования оптимальных маршрутов в сети Cloudflare, чтобы быстрее доставлять ответы пользователям, а также Authenticated Origin Pulls (mTLS), чтобы гарантировать, что запросы к вашему origin-серверу поступают именно из сети Cloudflare

Сервис Argo Smart Routing находит оптимальные маршруты в сети Cloudflare, чтобы ответы доставлялись пользователям быстрее.

Argo Smart Routing ускоряет трафик, используя данные в реальном времени и аналитику сети, полученную при маршрутизации более 28 миллионов HTTP-запросов в секунду. Это гарантирует прохождение трафика по самым быстрым и надёжным маршрутам сети Cloudflare до исходного сервера. В среднем Argo Smart Routing обеспечивает прирост производительности веб-ресурсов на 30%.

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

Authenticated Origin Pulls помогает удостовериться, что запросы к вашему исходному серверу поступают из сети Cloudflare, что добавляет дополнительный уровень защиты поверх Full или Full (strict) Режимы шифрования SSL/TLS, которые предлагает Cloudflare.

Эта аутентификация приобретает особое значение с Cloudflare Web Application Firewall (WAF). В сочетании с WAF это позволяет проверять весь трафик до получения ответа от исходного сервера.

Если вы хотите, чтобы ваш домен был FIPS ↗ соответствовать требованиям, вам нужно загрузить собственный сертификат. Этот вариант доступен для обоих на уровне зоны и для каждого имени хоста authenticated origin pulls.

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