Один банк, российский филиал крупной европейской банковской группы, поставил перед нами задачу сегментировать сеть. Его серверы были расположены в наших дата-центрах. На момент начала работ у заказчика была отдельная инфраструктура для собственно финансовых операций и физически отделённая от неё большая одноранговая сеть пользователей на пару крупных узлов и множество филиалов. Первая работала как часы, а со второй были сложности. Кроме того, как раз начиналась внутренняя реорганизация под требования 152-ФЗ о персональных данных.
Чтобы понять, как лучше организовать новую сеть, мы запросили соответствие IP-адресов и сервисов на них. Точнее, в конечном итоге нам нужна была карта с тем, что и куда гоняет трафик, чтобы было понятно, что разрешать, а что запрещать.
В этом месте ИБ сказали, что такие документы они представить не могут. И предложили собрать карту трафика самим, так как их, во-первых, самих интересует действительная картина происходящего в сети, а во-вторых, описание трафика и приложений в сети у них пока только в планах. Проще говоря, наше появление для них было отличной возможностью актуализовать картину обмена трафиком в сети — похоже, часто случалось, что ИТ что-то подключала и забывала об этом поставить в известность ИБ.
Так мы начали разбирать весь трафик сети.
Первый этап: «свой-чужой»
Оборудование для обеспечения отсечки «хорошего» трафика от «левого» мы привезли чуть раньше и подключили в режиме зеркалирования. Это штатная функция, позволяющая заранее на полной копии трафика определить, правильно ли работают настройки. В этом режиме видно, что отсекается, а что нет. В нашем же случае отсекать пока было нечего, нужно было сначала идентифицировать приложения, собрать статистику и промаркировать транзакции.
О внедрении мы договорились на тот момент, когда 95% трафика за две недели попадут под правила. Остальные (это, как правило, мелкие разовые транзакции по несколько килобайт) измерялись тысячами и типизации поддавались с трудом. Можно было бы потратить всю жизнь на изучение этого трафика: он вёл себя как бесконечная непериодическая дробь — менялся постоянно. Предполагалось, что если что-то пойдёт не так с этими мелочами (напомню, в пользовательской подсети), то просто потребуется новое правило для файрволла. Весь описанный трафик добавлялся в разрешения для файрволла. Если бы возникло что-то новое, оно бы по умолчанию отсекалось и предлагалось бы для анализа ИТ-команде и ИБ-специалистам.
Начали собирать информацию — кто и куда ходит и по каким протоколам. По итогам первой недели у нас была таблица с IP-адресами и объёмами трафика на них. Начали отслеживать типовые соединения, в общем, строить полный профиль сети. Каждое соединение, которое мы определяли как поведение какого-то приложения, обозначалось потом (по нашему запросу) как какой-то известный сервис сотрудниками ИТ-команды. В 99% случаев — успешно и правильно.
Сюрпризов в зоопарке нашлось много. Что ещё важнее — даже крупные объёмы трафика вели себя непериодически, причём некоторые сервисы показывали себя далеко не сразу. Только через 4 недели мы вышли на покрытие 95% в таблице по итогам недели, и через три месяца добились того, что в новых неделях не «всплывало» ничего неожиданного.
За неделю через файрволл проносился примерно терабит трафика. Характер менялся достаточно часто, и по мере определения трафика постоянно требовались новые наборы правил. Например, несколько недель у нас не было трафика до одной из групп IP-адресов, а потом он неожиданно пошёл. Как выяснилось, это были сервера с данными видеонаблюдения: скорее всего, кто-то где-то в нашей необъятной стране накосорезил, и потребовалось перерыть несколько недель видеозаписей из центрального офиса. Естественно, это создало довольно незнакомую для нас нагрузку на сеть. Или был один филиал, который скидывал свою файлопомойку в бекап раз в несколько недель, например, и поэтому за недельный период можно было не поймать эту важную для него операцию.
Безопасники разделили сервисы на критичные и не очень, то есть разметили приоритеты рисков.
Второй этап: как делить
Получалась большая матрица, которая, по сути, содержала правила для файрволла. Кстати, мы написали очень удобный скрипт, который из XLS-файла для ИБ и ИТ-команд, после того как они подписывали, что есть что, делал набор правил прямо для имплеметнации на файрволл. Ставят плюс в Excel-таблице — разрешили трафик, ставят минус — режем.
Когда прогнозируемый режим работы по покрытию 95% трафика начал совпадать с фактическим (в рамках зеркального подключения), стало ясно, что работы по определению трафика окончены. Безопасники получили набор документации, что и куда ходит (и, кажется, были очень рады, что кто-то разобрал это всё за них). ИТ-служба также очень радовалась, что получилось добиться показателя в разумные сроки.
Теперь нужно было разделить сеть. Базовых подходов в таких случаях несколько:
- Классический, по географии: у каждого офиса своя подсеть, они объединяются в региональные подсети, а затем попадают в общую сеть компании.
- Legacy-подход, он же «по имеющемуся сетевому проекту». Иногда это рационально, но, как правило, для крупных компаний грозит морем костылей. Дело в том, что исторически, например, может оказаться, что этажи с первого по четвёртый офиса в Москве и Петербург — это одна сеть, а пятый этаж и Екатеринбург — другая. И третий этаж имеет право пользоваться принтерами пятого.
- Упрощённая сегментация: топы и всё критичное в одну подсеть, пользователи — в другую.
- Атомарная сегментация — это когда на каждую проектную группу назначается своя подсеть. Например, сидят 2–3 человека в комнате, занимаются только обслуживанием чего-то одного — раз подсетка. Их соседи — два подсетка, и так далее. Это, на самом деле, рай для безопасников — им так удобнее всего контролировать людей, но ад для тех, кто должен это поддерживать.
- Функциональная сегментация: пользователи объединяются по тому, что они могут делать, а что не могут (независимо от географии), то есть, по сути, даётся 6–10 основных ролей.
От legacy-подхода и географии отказались почти сразу, благо сеть, естественно, позволяла поставить адресацию независимо от города так, чтобы устройства «видели» друг друга как находящиеся рядом. Упрощённая сегментация была слишком уж упрощена. Оставалась функциональная (ролевая) и её критический случай — атомарная. Естественно, безопасники выбрали максимальное деление на подсети. Мы поставили опыт и показали, во сколько сотен раз вырастает конфиг и как им это поддерживать. Они ушли подумать и вернулись с разрешением делать ролевую систему.
Привлекли HR-отдел, который предоставил штатное расписание. Вместе с ИТ и ИБ определили роли каждому сотруднику, назначили ему его подсеть — и снова добавили в правила на «большую железку». Опять же в течение пары недель смотрели на зеркальном трафике, правильно ли всё обрабатывается.
Кроме «человеческих» ролей у нас были и другие — например, принтеры в группу «принтеры», сервера в группу «серверы» и так далее. Каждый ресурс оценивался по критичности для бизнес-процессов ещё. Например, файлшара, DNS и Radius-сервера были признаны обычными, а сервера, выход из строя которых «клал» бухгалтерию, например, критичными.
Третий этап: внедрение
Поскольку каждый раз, получая новую информацию, мы просто заносили её своим чудо-скриптом из «человекочитаемого» XLS в правила для файрволла, у нас постоянно была самая актуальная версия сетевых политик. Межсетевой экран всё так же стоял в режиме зеркала, то есть спокойно пропускал весь трафик через себя, но показывал на копии для нас, ИТ и ИБ, что бы он отсёк в боевом режиме. В момент, когда всех причастных всё начало устраивать, ИТ-команда обозначила нам окно для работы на выходных. Почему на выходных — чтобы в случае сюрприза потом не получился пресс-релиз.
Сюрприза не произошло, переключение прошло ожидаемо штатно. Мы написали исполнительную документацию с настройками и сдали систему в эксплуатацию.
Возвращаясь чуть назад, на этой стадии была только одна небольшая сложность: ИТ-команда считала, что файрволл — это их сетевой узел, и рулят им они. Безопасники же видели это как узел обеспечения доступа (что-то вроде СКУД для данных) и считали, что это полностью их устройство. К счастью, мы настроили и тем и другим необходимые роли на железке: безопасники не трогают конфиги сети, а ИТ-команда не может прописать новые разрешения неожиданно для ИБ (собственно, такие случаи и стали причиной того, что безопасникам нужна была актуальная карта трафика — много чего делалось «на горячую бету» мимо них и навсегда оставалось в продакшне).
Итоговый график такой:
|
Название этапа
|
Продолжительность
|
Комментарий
|
|
Подготовка технико-коммерческого предложения
|
1 неделя
|
Это очень быстро для интегратора
|
|
Подписание договора
|
1 неделя
|
Это очень быстро для банка
|
|
Разработка проектной документации
|
1 месяц
|
+ время на согласование с заказчиком (это 2–3 недели), включая корректировку документов. Здесь мы параллельно проводили мониторинг сети, который длился 4 недели. Изменения сразу заносились в документацию
|
|
Монтаж и пуско-наладка оборудования
|
3 недели
|
Так как работы выполнялись на 4 площадках заказчика в согласованные «окна», процесс занял такое время
|
|
Опытная эксплуатация
|
3 месяца
|
Для достижения целевых показателей было необходимо провести итерационный процесс по настройке правил на МСЭ
|
|
Итоговые испытания, ввод в промышленную эксплуатацию
|
1 день
|
Переключение
|
Итоговая архитектура:
Основная железка — Palo Alto 3020. Их 6 штук на 4 объектах. Две штуки на большие офисы (подключённые отказоустойчивым кластером), по одному — на дата-центры (это два наших ЦОД, где расположена ИТ-инфраструктура банка). В ЦОДах файрволлы подключены в прозрачном режиме, а не кластером, поскольку сама по себе архитектура двух дата-центров и является большим кластером по сути.
Ссылки:
- Рефакторинг сети «Аэроэкспресса» (хороший пример для быстрорастущих компаний)
- Байки нашей команды
- Моя почта — AVrublevsky@croc.ru
Наш код скрипта преобразования требований заказчика в сетевые правила пошёл между нашими же инженерами по руками — прикольная штука, экономит время.
Автор: КРОК
