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

Расширение преимуществ Cloudflare на конечных клиентов поставщиков SaaS

Один из ключевых аспектов разработки приложения Software-as-a-Service (SaaS) состоит в том, чтобы защитить его от широкого спектра атак, с которыми оно сталкивается в интернете. Сетевые и защитные службы Cloudflare можно использовать для защиты клиентов, работающих с вашим SaaS-приложением, переложив риск на поставщика с опытом в защита приложений ↗.

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

На следующих схемах показано использование следующих сервисов:

• Data Localization Suite (в частности, Regional Services)
• Cloudflare for SaaS
• Cloudflare Tunnels для безопасной публикации веб-приложений (с общедоступные имена хостов и частные сети)
• Load Balancers для управления трафиком и обеспечения надёжности и производительности, реализуя Global Traffic Management (GTM) и Private Network Load Balancing.

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

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

Это решение поддерживает поддомены в вашей собственной зоне и одновременно позволяет клиентам использовать собственные доменные имена (vanity-домены или пользовательские домены) с вашими сервисами. Например, для каждого клиента можно создать пользовательское имя хоста mycustomer.myappexample.com но также хотите разрешить им использовать собственный домен, app.mycustomerexample.com чтобы указывать на своего арендатора в вашем сервисе. Каждый субдомен (mycustomer.myappexample.com) можно создать в основном домене (myappexample.com) через Cloudflare API, что позволяет легко автоматизировать создание DNS-записей при регистрации ваших клиентов в вашем сервисе.

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

Для реализации этого решения используются следующие продукты.

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

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

Эта стандартная схема Cloudflare for SaaS наиболее распространена и проще всего внедряется для большинства провайдеров. Обычно это SaaS-компании, разрабатывающие и предоставляющие решения по модели software as a service. Для этой схемы достаточно одной DNS-записи, направляющей запросы в Cloudflare, который затем проксирует трафик к вашему приложению через A-запись.

1. Пользовательское имя хоста (custom.example.com) настроена как CNAME-запись, указывающая на резервный источник (fallback origin) провайдера. Резервный источник представляет собой сервер или серверы, на которые Cloudflare по умолчанию направляет трафик при запросе к пользовательскому имени хоста. Управлять этой DNS-записью в Cloudflare не обязательно: достаточно, чтобы она указывала на размещенную в Cloudflare запись провайдера (fallback.myappexample.com).
2. Fallback Origin настраивается как запись A, указывающая на публичный IP-адрес сервера источника. По умолчанию Cloudflare будет направлять трафик, отправленный на настраиваемые имена хостов, на этот сервер источника.

Исходный сервер получает сведения о пользовательском домене либо через заголовок Host или SNI. Это позволяет исходному серверу определить, в какое приложение направить запрос. Такой метод применим как для custom hostnames (например, app.mycustomerexample.com) и vanity-домены (например, customer1.myappexample.com). Поскольку теперь все запросы к вашему приложению проходят через сеть Cloudflare, вы можете использовать для каждого запроса ряд сервисов безопасности и производительности, в том числе:

• Web Application Firewall
• Политики контроля доступа
• Кэширование содержимого приложения
• Поддержка Early Hints в браузере
• Преобразования изображений
• Waiting Room
• Workers for Platform

Чтобы узнать подробности реализации для начала работы, ознакомьтесь с документация для разработчиков.

Этот подход предполагает использование Regional Services решение для регионализации терминации TLS и обработки HTTP в соответствии с требованиями комплаенса, предписывающими обработку данных вашего сервиса в определённых географических регионах. Это гарантирует, что трафик, предназначенный для origin-сервера, обрабатывается исключительно в выбранном регионе.

1. Пользовательское имя хоста (custom.example.com) настроена как CNAME-запись, указывающая на регионализированное имя хоста SaaS (eu-customers.myappexample.com). Эта конфигурация гарантирует, что вся обработка, включая завершение TLS, происходит исключительно в пределах указанного географического региона.
2. Региональное имя хоста SaaS настроено как запись CNAME, направляющая трафик на стандартный Резервный исходный сервер поставщика SaaS (fallback.myappexample.com).
3. Резервный источник настраивается как A-запись, указывающая на публичный IP-адрес сервера источника. По умолчанию Cloudflare направляет на этот сервер источника трафик, отправляемый на пользовательские имена хостов.

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

1. Пользовательское имя хоста (custom.example.com) настроена как CNAME-запись, указывающая на регионализированное имя хоста SaaS (eu-customers.myappexample.com). Эта конфигурация гарантирует, что вся обработка, включая завершение TLS, происходит исключительно в пределах указанного географического региона.
2. Региональное имя хоста SaaS настроено как запись CNAME, направляющая трафик на стандартный Резервный исходный сервер поставщика SaaS (fallback.myappexample.com).
3. Резервный источник (fallback origin) представляет собой CNAME-запись DNS, которая указывает на публичное имя хоста публикуемый через Cloudflare Tunnel. Этот публичный хост должен быть настроен на маршрутизацию трафика к вашему приложению, например, localhost:8080.

Эта схема идеально подходит для поставщиков SaaS, которым не требуется детальная балансировка нагрузки, например управление трафиком на основе геолокации, между несколькими исходными серверами. Это также хорошо подходит для простых тестовых сред и сред разработки, где защита исходного сервера путём разрешения запросов только через Cloudflare Tunnel обычно достаточно. Однако для распределённых приложений, которым требуется балансировка нагрузки как на глобальном, так и на локальном уровне, мы рекомендуем использовать Load Balancer от Cloudflare с возможностями балансировки нагрузки как в глобальной, так и в частной сети.

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

1. Пользовательское имя хоста (custom.example.com) настроена как CNAME-запись, указывающая на регионализированный Load Balancer (eu-lb.myappexample.com). Это гарантирует, что вся обработка, включая завершение TLS, происходит в пределах указанного географического региона. Кроме того, провайдеру SaaS необходимо настроить балансировщик нагрузки как пользовательский источник для пользовательского хоста.
2. Региональный балансировщик нагрузки настроен с origin pools для распределения запросов между несколькими последующими серверами. Каждый пул можно настроить на использование либо общедоступные имена хостов с Global Traffic Management (GTM) или частная сеть адресов с помощью Private Network Load Balancing. На диаграмме выше используются оба варианта:
   • Пул источников 1 использует Имя хоста Cloudflare Tunnel (<UUID>.cfargotunnel.com) в качестве конечной точки или исходного сервера для обработки этих запросов. При использовании публичного имени хоста необходимо задать Значение заголовка HTTP Host чтобы оно соответствовало публичному имени хоста, настроенному и опубликованному Cloudflare Tunnel. Это гарантирует, что исходный сервер сможет корректно маршрутизировать входящие запросы.
   • Пул источников 2 использует приватный IP-адрес или частную сеть (то есть 10.0.0.5) во внутренней сети провайдера SaaS, где расположено SaaS-приложение. Этот пул должен быть настроен на работу в пределах указанного виртуальная сеть для обеспечения правильной маршрутизации запросов.
3. Cloudflare Tunnel предоставляет доступ как к общедоступные имена хостов с GTM и частные сети (частные IP-адреса) с Private Network Load Balancing.

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

Обратите внимание на Zero Trust Ограничения туннеля, Cloudflare for SaaS сведения о запросе на подключение, и Custom Origin Спецификация SNI. Дополнительную информацию о Cloudflare Load Balancer можно найти в эталонная архитектура.

Если вы являетесь поставщиком SaaS, рекомендуется автоматизировать большинство, если не все, из этих процессов с помощью API, SDK, скрипты, Terraform, или других инструментов автоматизации.

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

Настоятельно рекомендуется переходить на Cloudflare for SaaS поэтапно и устранять проблемы по мере их появления, особенно в отношении Проверка контроля над доменом (DCV). Обязательно ознакомьтесь с статус проверки и соответствующие документация в ходе этого процесса.

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

Ряд клиентов Cloudflare уже используют решение Cloudflare for SaaS (ранее известное как SSL for SaaS). Среди известных публичных примеров использования:

• Shopify ↗
• Porsche Informatik ↗
• Divio ↗
• mogenius ↗
• Quickbutik ↗

Кроме того, при переходе на Cloudflare for SaaS важно иметь runbook и понятную публичную документацию, чтобы донести до конечных клиентов нужные сведения. Отличными публичными примерами этого служат Salesforce CDN ↗ и Shopify ↗ документация.