Хабрахабр

Как безопасно объединить сетевые сегменты трех крупных банков: делимся хитростями

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

Сложности взаимодействия разрозненных инфраструктур

Деятельность ВТБ на текущий момент обеспечивается тремя унаследованными инфраструктурами:  экс-Банк Москвы, экс-ВТБ24 и сам ВТБ. Инфраструктуры каждого из них обладают своим набором сетевых периметров, на границе которых стоят средства защиты. Одно из условий для интеграции инфраструктур на уровне сети — это наличие согласованной структуры IP-адресации.

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

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

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

Независимо от географического местоположения самих серверов, если трафик выходит за периметр зоны безопасности, он пройдет через цепочку средств защиты, которые могут находиться в других локациях. Проблема мультипликации трафика возникает, в основном, из-за множества зон безопасности, взаимодействующих между собой через межсетевые экраны на разных сайтах. Трафик между ними идет не напрямую, а проходит через 3-4 межсетевых экрана, которые могут быть активны в других дата-центрах, и трафик будет доставлен до файрвола и обратно несколько раз через магистральную сеть. Например, у нас есть два сервера в одном дата-центре, но один – в периметре ВТБ, а другой – в периметре сети экс-ВТБ24.

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

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

Общий подход к интеграции

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

  • Исходя из их потребностей, мы проектируем целевую структуру зон безопасности и принципы межсетевого взаимодействия между этими зонами.
  • Эту структуру зон мы накладываем на географию наших основных потребителей — ЦОД и крупных офисов.
  • Далее формируем транспортную MPLS-сеть.
  • Под неё уже подводим первичную сеть, обеспечивающую услуги физического уровня.
  • Выбираем локации размещения edge-модулей и модулей межсетевого экранирования.
  • После того как целевая картина прояснится, прорабатываем и утверждаем методику миграции с существующей инфраструктуры на целевую — так, чтобы процесс был прозрачным для работающих систем.


Целевая концепция сети

Также в ней может использоваться подсистема оптического уплотнения каналов xWDM и, возможно, SDH-сеть. У нас будет первичная магистральная сеть — это транспортная телекоммуникационная инфраструктура на основе волоконно-оптических линий связи (ВОЛС), пассивного и активного каналообразующего оборудования.

Она будет иметь единый адресный план и единый набор протоколов маршрутизации. На базе первичной сети мы строим так называемую опорную сеть. В опорную сеть входит:

  • MPLS — мультисервисная сеть;
  • DCI — линки между дата-центрами;
  • EDGE-модули — различные модули подключения: межсетевого экранирования, партнерских организаций, интернет-каналов, ЦОД, ЛВС, региональной сети.

Мультисервисную сеть мы создаем по иерархическому принципу с выделением транзитных (P) и конечных (PE) узлов. В ходе предварительного анализа оборудования, имеющегося сегодня на рынке, стало ясно, что вынести уровень P-узлов на отдельное оборудование будет экономически более целесообразно, чем совмещать функционал P/PE в одном устройстве.

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

Но при этом не хотим создавать «винегрет» из оборудования различных вендоров. В ходе построения магистральной сети мы намерены отказаться от проприетарных технологий (там, где это возможно без ухудшения качества), так как стремимся, чтобы решение было гибким и не завязанным на конкретного вендора. Это позволит в том числе организовать сопровождение сетевой инфраструктуры, задействуя ограниченное количество персонала. Наш основополагающий принцип проектирования — предоставлять  максимальное количество сервисов при использовании оборудования, минимально достаточного для этого количества вендоров. Также важно, чтобы новое оборудование было совместимо с существующим оборудованием для обеспечения процесса бесшовной миграции.

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

Административный доступ ко всему сетевому оборудованию будет осуществляться через единый сервис аутентификации, авторизации и аккаунтинга (AAA). Управление оборудованием опорной сети мы организуем через отдельную физическую сеть (out-of-band).

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

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

От теории к практике

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

Ресурсный лес: подробности

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

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

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

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

В каждом из них своя маршрутизация: default  gateway смотрит в сторону «своего» банка. Таким образом, два сегмента ресурсного леса представляют собой единую шлюзовую зону безопасности, если проводить границу по файрволам. Если мы размещаем ресурс в каком-то сегменте ресурсного леса, то пользователи соответствующего банка могут взаимодействовать с ним без NAT.

Также безNAT-взаимодействия требуют такие системы, как Skype for Business, АБС «MBANK» и множество других разнообразных приложений, где от сервера идет обратное обращение на адрес клиента. Взаимодействие без NAT очень важно для многих систем и, в первую очередь, для доменных взаимодействий Microsoft — ведь в ресурсном лесу у нас располагаются сервера Active Directory для нового общего домена, трасты с которым устанавливаются со стороны обеих организаций. И если клиент находится за PAT, обратное соединение уже не установится.

Последний тип серверов мы называем «Витрины данных». Сервера, которые мы устанавливаем в сегментах ресурсного леса, делятся на две категории: инфраструктурные (например, сервера MS AD) и предоставляющие доступ к каким-либо информационным системам. Витрины — это, как правило, web-сервера, бэкэнд которых уже находится за файрволом в продакшн-сети организации, создавшей данную «витрину»  в ресурсном лесу.

 Если мы просто предоставляем доступ к каким-либо приложениям для одного-двух пользователей в другом домене, то можем завести для них в нашем домене отдельные учетные записи для аутентификации. А как осуществляется аутентификация пользователей при доступе к опубликованным ресурсам? Создание непосредственных трастов между лесами разных организаций также не всегда возможно как по соображениям безопасности, так и из-за необходимости делать PAT пользователей в условиях пересекающихся адресных пространств. Но когда мы говорим о массовом слиянии инфраструктур — скажем, 50 тысяч пользователей — заводить и сопровождать для них отдельные перекрестные учетки совершенно нереально. В этом новом домене пользователи аутентифицируются при доступе к сервисам. Поэтому для решения задачи единой аутентификации пользователей  в периметре ресурсного леса создается новый лес MS AD, состоящий из одного домена. Таким образом, пользователь любой из организаций может аутентифицироваться на любом опубликованном ресурсе. Чтобы это было возможно, организовываются двусторонние доверительные отношения уровня леса между новым лесом и доменными лесами каждой организации.

Начинаем интеграцию сетей

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

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

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

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

Упразднение NAT

Здесь наша цель — обеспечение работы систем в едином адресном пространстве  для проведения дальнейших интеграций как инфраструктурных сервисов (MS AD, DNS), так и прикладных (Skype for Business, MBANK). К сожалению, поскольку часть прикладных систем уже завязана между собой по транслированным адресам, требуется индивидуальная работа с каждой прикладной системой по ликвидации NAT для конкретных взаимодействий.  

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

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

Межсетевой файрволинг

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

У нас есть два сайта: сайт 1 и сайт 2. Попробуем сформулировать проблему резервирования файрволов в общем. Требуется этот файрвол зарезервировать локально и географически. Есть несколько (например, три) MPLS IP VPN, взаимодействующие между собой через stateful файрвол.

Что касается географического резервирования файрволов, практически ни у одного вендора эта задача «из коробки» не решена. Проблему локального резервирования файрволов мы рассматривать не будем, почти любой производитель предоставляет возможность собрать файрволы в локальный HA-кластер.

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

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

В противном случае мы сразу сталкиваемся с проблемами ассиметричной маршрутизации, которая трудно решается при большом количестве L3 VPN. Решено было придерживаться модели георезервирования Active/Standby, когда активный кластер у нас находится на одной площадке.  

В качестве метода сигнализации мы выбрали анонсирование по OSPF с файрвола в сеть тестового (флагового) маршрута с маской /32. Активный файрвольный кластер как-то должен сигнализировать о своей корректной работе. 0. Сетевое оборудование на сайте 1 отслеживает наличие данного маршрута от файрвола и при его наличии активизирует статическую маршрутизацию (например, 0. 0 /0), в сторону данного файрвольного кластера. 0. Когда основной файрвольный кластер живой, он исправно вещает по OSPF флаговый маршрут, роутеры следят за ним, вся маршрутизация обращена именно к этому файрволу и весь трафик стекается на него по всем IP VPN. Этот статический дефолт-маршрут далее помещается (через редистрибьюцию) в таблицу протокола MP BGP и распространяется по всей магистральной сети.

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

И через некоторое время, зависящее от сходимости протоколов, весь обмен трафика между VPN’ами переходит на другой сайт. Если с файрволом на сайте 1 что-то случается, то флаговый маршрут пропадает, роутеры на сайте 1 удаляют соответствующие маршруты из таблицы маршрутизации, а роутеры на сайте 2 наоборот — поднимают статические маршруты в сторону резервного файрвола. Например,  если один сайт оказывается обесточен, дефолтные маршруты автоматически меняются так, чтобы задействовать файрвол на рабочем сайте.

Все изменения вносятся только в active-файрвол. Как мы описали выше, файрвольные кластеры у нас зарезервированы на между сайтами по схеме active/standby. Софт забирает настройки, удаляет из них специфичные для конкретной площадки параметры конфигурации (например, IP-адреса интерфейсов и таблицы маршрутизации). Для синхронизации настроек между основной и резервной площадками у нас используется отдельный сервер, на котором работает самописный софт. Эта процедура проводится автоматически с определенной частотой. А затем загружает обработанную конфигурацию в файрволы на других сайтах. Такая схема работы файрволов позволяет добиться полной независимости площадок.

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

Одноногий файрвол

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

Для подачи трафика на этот файрвол мы используем частично связанные MPLS VPN. Для таких случаев мы используем отдельное решение для организации сервисной цепочки через файрвол, в котором файрвол подключен в сеть всего одним IP-интерфейсом. Оба этих VPN являются хабами в топологии HUB-and-spoke VPN. У нас есть один MPLS VPN «IN»  и один VPN «OUT». В качестве Spoke у этих HUB’ов выступает один и тот же набор VPN, между которыми и нужно отфильтровать трафик.

Хаб «OUT» только импортирует маршруты из подключенных к нему Spoke VPN’ы и не экспортирует ничего. Хаб «IN» только экспортирует дефолт-маршрут в подключенные к нему Spoke VPN’ы и не импортирует никаких маршрутов из других VPN.

 Дефолт в этом VPN смотрит в сторону файрвола. Файрвол включен своим единственным интерфейсом в MPLS VPN «IN». На файрволе осуществляется фильтрация трафика в соответствии с глобальными политиками. Таким образом весь трафик стекается по дефолту из множества VPN в HUB-VPN «IN» и направляется на файрвол. Они помещают этот трафик в VPN «OUT», откуда он уже растекается в соответствии с полной таблицей маршрутизации VPN «OUT» в нужные Spoke-VPN. Далее файрвол отдает отфильтрованный трафик обратно в тот же единственный интерфейс, на котором возвратный трафик перехватывается политиками Policy Based  Routing.

Фактически для подключения сегмента к файрволу достаточно только добавить записи MPLS import / export  в соответствующие HUB VPN. Эта схема позволяет быстро объединять большое число VPN, которые работают через один файрвол.

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

Заключение

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть