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

Упрощенное развертывание WAF в зонах и приложениях

Границы периметра безопасности стали менее чёткими по сравнению с традиционной моделью «замка и рва», популярной в прошлом. В рамках фиксированного периметра было относительно просто защищать несколько приложений с помощью одного развёртывания Web Application Firewall (WAF) внутри дата-центра. Сегодня этот подход не даёт достаточной гибкости, поскольку приложения и сервисы выходят за пределы традиционного дата-центра. Есть немало веских причин настраивать сети и сервисы по гибридной схеме и переходить на SaaS-платформы, поэтому подход к WAF стоит обновить с учётом этого сценария.

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

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

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

Cloudflare предлагает комплексные решения для безопасности и производительности приложений, включая гибко настраиваемый облачный Web Application Firewall (WAF).

Из этого руководства вы узнаете:

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

Большинство клиентов Cloudflare подключают несколько Cloudflare Zones в рамках одного Account (или Enterprise Organization). Каждая Cloudflare Zone обычно соответствует домену второго уровня (например, example.com), и все ее поддомены затем обрабатываются в этой зоне Cloudflare (web1.example.com, web2.example.com и т. д.).

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

Часто несколько FQDN указывают на одну и ту же общую веб-инфраструктуру, например через IP-адрес или другой FQDN. Также возможно, что часть FQDN указывает на выделенную инфраструктуру источника или на внешнюю конечную точку SaaS.

Во многих случаях клиентам Cloudflare приходится управлять множеством зон Cloudflare (например, example.com,example.org, myappexample.com и так далее) в рамках одной учётной записи Cloudflare, а также множество полных доменных имён (FQDN) в каждой зоне. Зачастую множество FQDN из разных зон указывают на общую веб-инфраструктуру за кулисами.

Например, у вас может быть следующий (или похожий) сценарий:

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

Пример сценария показан на диаграмме ниже:

С точки зрения настройки WAF этот сценарий порождает интересные требования:

• Чтобы получить легко развёртываемую конфигурацию, которая применяет перед большинством приложений стандартный набор правил WAF.
• Чтобы можно было точно настраивать, какие правила применяются перед устаревшими приложениями, которые чаще других дают ложные срабатывания.
• Чтобы включить конфигурацию «catch-all», обеспечивающую применение стандартной настройки WAF от Cloudflare ко всему веб-трафику, не подпадающему под сценарии, описанные выше.
• Чтобы минимизировать время настройки и последующую поддержку по мере добавления и удаления приложений.

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

WAF Cloudflare работает как на уровне зоны, так и на уровне аккаунта. Существуют разные Фазы WAF (http_request_firewall_custom, http_ratelimit и http_request_firewall_managed) которые соответствуют Custom Rules, Rate Limiting Rules и Managed Rules. Эти фазы существуют как на уровне аккаунта, так и на уровне зоны. Подробнее см. подробнее см. в следующей документации. Важно отметить, что наборы правил уровня Account обрабатываются раньше наборов правил уровня zone.

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

Представим, что за шестью FQDN в двух доменах находятся шесть приложений. Для этих приложений требуется применить базовый уровень защиты WAF. Однако двум из этих шести приложений потребуется особый подход:

• Один реализован на устаревшем сервере приложений и склонен к ложным срабатываниям.
• Ещё один реализуется третьей стороной на своей собственной инфраструктуре.

Визуализируем сценарий ниже:

Мы будем использовать Cloudflare Managed Ruleset в качестве примера, учитывая, что этот подход можно применять и к другим Cloudflare Managed Rules, Rate Limiting Rules и Custom Rules.

• Для web1.example.com, web2.example.com, web3.example.com и web5.example.org: вы хотите применить стандартный WAF Managed Ruleset, уже настроенный специалистами Cloudflare.
• Для special4.example.com: вы хотите применить другое подмножество стандартного Managed Ruleset, так как уже выявили несколько правил, вызывающих ложные срабатывания в устаревшем приложении.
• Для special6.example.org: вы хотите применить Managed Ruleset в режиме логирования, так как это недавно подключённое приложение от стороннего поставщика и вам нужно начать оценивать, как его защитить.

После этого можно применить следующий подход:

• Разверните один экземпляр Cloudflare Managed Ruleset на уровне Account. Он реализует общий набор правил для четырёх FQDNS, которым это требуется. Это проще настроить и поддерживать, чем четыре раза повторять одну и ту же конфигурацию на уровне Zone.
• Для special4.example.com и special6.example.org, разверните еще два экземпляра Managed Ruleset с настройками, необходимыми для приложений за этими конкретными FQDN.

На практике, используя Managed Rulesets WAF на уровне аккаунта, можно развернуть три экземпляра нашего Managed Ruleset. У каждого экземпляра будет свой Custom Filter Expression, которое проверяет, принадлежит ли hostname HTTPS-запроса одному из FQDN в списке:

• Для первого списка (web1.example.com, web2.example.com, web3.example.com и web5.example.org), вы примените Cloudflare Managed Ruleset в его Default конфигурации.
• Для special4.example.com, тот же набор правил будет развёрнут в Default режим, отключая при этом конкретные правила, которые вызывают ложные срабатывания. Этого можно добиться с помощью Переопределения правил, используя Dashboard или API. Практические примеры доступны здесь.
• Для special6.example.org, повторите настройку, выполненную для первого списка, но на этот раз измените режим работы экземпляра Managed Ruleset на Log режим вместо Default.

Визуализируем полную конфигурацию на диаграмме ниже:

Эта схема развёртывает три экземпляра Managed Ruleset, настроенных под каждую группу приложений.

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

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

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

• Сначала можно определить, каким приложениям (FQDN) требуется особая обработка, развернув набор правил в Log режим. Например, после тестирования вы обнаруживаете, что special1.example.com требует отключения небольшого набора Managed Rules, и special2.example.org отключение похожего, но другого набора правил.
• Разверните два управляемых исключения (Exceptions) с фильтром, соответствующим каждому FQDN, а затем пропускайте эти правила Managed Ruleset.
• Наконец, разверните версию Default для Managed Ruleset, которая будет соответствовать всему остальному, и примените рекомендованные Cloudflare настройки Managed Ruleset.

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

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

После этого списки можно обновлять напрямую и повторно использовать в нескольких rulesets. Например, один и тот же список можно применить и в Cloudflare Managed Rules, и в OWASP Ruleset, и в Rate Limiting. Ваши фильтры будут напрямую ссылаться на списки, что означает более чистую и удобную для сопровождения конфигурацию.

При использовании списков также гораздо проще внедрить «правило перехвата всего», которое выполняется последним в порядке оценки. Например, с его помощью можно реализовать Default Cloudflare Managed Ruleset, если хост в HTTPS-запросе не включен ни в один из ваших списков. Это гарантирует, что конфигурация WAF Managed Rules по умолчанию применяется всегда, на случай если какие-то из ваших приложений случайно не были добавлены в списки.

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

Например, можно создать базовый файл конфигурации Terraform для определения Rulesets и Lists, а затем поддерживать и применять его по мере необходимости без внесения изменений в Cloudflare Dashboard.

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

На уровне WAF зоны можно развернуть только один экземпляр каждого набора правил (Managed Rules, OWASP Rules и т. д.), поэтому обработка особых сценариев на этом уровне может быть сложнее или вовсе невозможна.

Описанный выше подход для Managed Rules можно применить и к Custom Rulesets и Rate Limiting, распространяя эту гибкость на все инструменты безопасности WAF, доступные вам.

Если ваша конфигурация не привязана к конкретной зоне, Cloudflare рекомендует применять её на уровне Account.

Дополнительные сведения см. в следующих материалах:

• Создание Rate Limiting Rule на уровне аккаунта
• Создание Custom Rulesets на уровне аккаунта

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