Автор: Дмитрий Квашнин, ведущий инженер-эксперт Innostage

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

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

Преамбула

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

На бумаге подобные проекты обычно выглядят как комбинации best practices: отказоустойчивость, сегментация, NGFW, немного динамической маршрутизации – и кажется, что этого достаточно.

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

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

Исходные данные

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

На старте у нас была следующая существующая инфраструктура:

• две географически разнесённые площадки ЦОД

• геораспределенный кластер ядра корпоративной сети передачи данных (КСПД)

• геораспределенный высокопроизводительный импортный кластер NGFW в режиме Active-Passive

Проектируемая инфраструктура:

• отечественные сертифицированные межсетевые экраны, для защиты трафика, попадающего под требования регулятора РФ

• платформы виртуализации для размещения сервисов

• сетевая фабрика с отдельным ядром на каждой площадке

В проекте участвовали:

• заказчик

• три подрядчика с разными зонами ответственности

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

Цели и задачи проекта

Цель проекта — снижение ущерба при авариях или отказах инфраструктуры, соответствие требованиям законодательства РФ в области защиты информации.

Задача проекта — выполнение работ по проектированию и внедрению защиты частного облака для обеспечения:

• непрерывности функционирования бизнес-приложений;

• прохождение всего трафика через высокопроизводительный импортный NGFW (требование Заказчика);

• трафик, попадающий под требования регулятора (к примеру – трафик ПДн), должен быть защищен сертифицированным МЭ;

• отказоустойчивость и катастрофоустойчивость архитектуры.

Сложности начального этапа

Основная проблема возникла уже на этапе проектирования.

Над архитектурой работали разные команды, и у каждой было своё видение сети:

• одни предлагали использовать статическую маршрутизацию;

• другие настаивали на динамической;

• обсуждалось использование одного VRF или сегментации через несколько VRF;

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

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

Креативное проектирование

В какой-то момент стало понятно, что стандартный подход «как делали раньше» здесь не работает. Пришлось фактически заново пересобирать архитектуру сети. Переломным моментом стало понимание: архитектуру нужно строить не от отдельных компонентов (NGFW, фабрики, платформы виртуализации), а от потоков трафика и сценариев взаимодействия сервисов.

Основные решения, которые были приняты:

• Переход от статической маршрутизации к динамической;

• Статическая схема быстро становилась неуправляемой при масштабировании и добавлении новых сервисов;

• Использование нескольких VRF.

При этом отдельной задачей стало определение количества VRF, в которых допускается взаимодействие.

Мы исходили из нескольких практических принципов:

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

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

• Взаимодействие между сегментами VRF должно быть строго контролируемым.

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

Отдельно встал вопрос масштабирования внутри одного VRF. При укрупнении сегментов возрастает объем трафика east-west, и если он не проходит через средства контроля, то это снижает уровень изоляции.

Поэтому при проектировании приходилось балансировать между:

• Количеством VRF

• Объемом трафика внутри каждого сегмента

• Целесообразностью его контроля

На практике это означало, что VRF – это не только про сегментацию, но и про границы управляемости трафика.

Все это позволило:

• разделить сетевые сегменты

• повысить уровень изоляции сервисов

• определить границы контроля трафика

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

Разбор сценариев прохождения трафика

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

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

Именно на этих примерах лучше всего проявляются последствия принятых архитектурных решений и связанные с ними компромиссы.

Прохождение трафика (одна площадка)

Внутри ЦОД трафик проходит следующим образом:

• Сервис VM1 → фабрика → Ядро → NGFW →

  • либо в КСПД (north-south)

  • либо обратно в Сервис VM2 (east-west через МЭ)

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

Взаимодействие между ЦОД 1 – ЦОД 2

При взаимодействии между ЦОД:

• Сервис VM1 (ЦОД 1) → фабрика → Ядро (ЦОД 1) → NGFW → Ядро (ЦОД 1) →  Ядро (ЦОД 2) → фабрика → сервис VM (ЦОД 2)

Для перехода трафика между ЦОД 1 и ЦОД 2 на проектируемых ядрах используются транспортные линии связи (Core interconnect). Для обеспечения связанности используется растянутые L3-сегменты для каждого VRF, отвечающие за взаимодействие существующего кластера NGFW и проектируемых ядер.

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

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

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

Особенности нормативной безопасности (обработка трафика ПДн)

До этого момента архитектура предполагала использование высокопроизводительного импортного NGFW как основного средства защиты — это было одним из требований заказчика.

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

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

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

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

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

Один из обсуждаемых вариантов выглядел так:

Сервис (ПДн) → фабрика → Ядро → МЭ (сертифицированный) → NGFW → сервис (ПДн)

На первый взгляд схема выглядела логично, но возникает проблема. Таблица маршрутизации на сертифицированном МЭ становится единой, все VRF объединяются на МЭ, поэтому трафик между сервисами ПДн остается только на сертифицированном МЭ.

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

После обсуждения была принята следующая логическая схема в рамках одного ЦОД:

Внутри ЦОД трафик проходит следующим образом:

• Сервис VM1 (ПДн) → фабрика → Ядро → сертифицированный МЭ → NGFW →

  • либо в КСПД (north-south)

  • либо обратно в Сервис VM3-VM4 (east-west)

• Сервис VM3 (ПДн) → фабрика → Ядро → сертифицированный МЭ → Ядро → фабрика → Сервис VM2 (ПДн)

Итоговая архитектура

После серии обсуждений и доработок была сформирована итоговая схема взаимодействия между ЦОД 1 и ЦОД 2.

Ключевые принципы архитектуры:

• симметрия прохождения трафика

• разделение сегментов через VRF

• контроль взаимодействия сервисов через межсетевые экраны

• соблюдение требований законодательства РФ

• быстрая сходимость сети

Отдельно рассматривался вариант построения схемы в режиме active-active между площадками, однако от него было принято решение отказаться.

Основные причины:

• необходимость анонсирования маршрутной информации вплоть до отдельных VM (/32), что существенно увеличивало размер таблиц маршрутизации

• существующий геораспределённый высокопроизводительный импортный NGFW кластер работал в режиме Active-Passive, что делало построение active-active архитектуры нецелесообразным

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

Для реализации схемы Active-Passive площадка использовалась динамическая маршрутизация на базе BGP. Приоритет активной площадки определялся через BGP-атрибуты, в первую очередь local preference. Маршруты с активной площадки получали более высокий приоритет, а резервная площадка рассматривалась только как запасной путь. Дополнительно использовались механизмы управления AS-path, что позволяло сохранить предсказуемость выбора маршрутов и исключить нежелательное перераспределение трафика между площадками при штатной работе инфраструктуры.

С точки зрения отказоустойчивости импортный NGFW работал в режиме Active-Passive.

Сертифицированные МЭ рассматривались как независимые компоненты без построения геораспределённого кластера.

Это решение было принято по одной критичной причине:

• отсутствие полноценной защиты от split-brain в сертифицированных МЭ.

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

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

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

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

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

Сходимость сети при переключениях обеспечивалась за счёт использования протокола BFD, что позволяло минимизировать время обнаружения отказов и перестроения маршрутизации.

Проблемы на этапе внедрения

Когда проект перешёл из стадии проектирования в стадию внедрения, появились новые сложности.

Отдельной задачей стал расчёт и распределение префиксов маршрутной информации между площадками.

Громоздкие настройки маршрутизации (Route-Map), управление local preference, контроль AS-path.

На одном из этапов внедрения была допущена ошибка в расчёте BGP-атрибутов на резервной площадке, что привело к некорректной маршрутизации трафика.

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

Диагностика проблемы строилась по классическому сценарию:

• проверка таблиц маршрутизации;

• трассировка фактического пути прохождения трафика;

• анализ BGP-атрибутов (local preference, AS-path).

Это позволило достаточно быстро локализовать источник проблемы и внести корректировки.

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

Когда NGFW упирается в свои пределы

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

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

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

Вместе с этим увеличивалось:

• количество BGP-сессий;

• объём маршрутной информации;

• количество политик маршрутизации;

• нагрузка на таблицы маршрутизации NGFW.

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

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

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

В результате было принято решение перераспределить роли между компонентами системы. Для работы с BGP и распространением маршрутной информации был выделен отдельный Route Reflector.

 Это позволило:

• сократить количество BGP-сессий на межсетевых экранах;

• упростить сопровождение маршрутизации;

• снизить зависимость архитектуры от ограничений конкретного NGFW;

• оставить межсетевым экранам их основную задачу — контроль и защиту трафика.

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

Что в итоге определило архитектуру

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

Симметрия прохождения трафика

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

VRF стали не просто инструментом сегментации

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

Средства защиты не должны подменять сетевую инфраструктуру

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

Требования регулятора должны встраиваться в архитектуру, а не определять её целиком

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

Отказоустойчивость — это не только резервирование, но и управляемость отказа

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

Вывод

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

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

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