В конце прошлого года, после сделки с «Ростелекомом», мы получили в свое распоряжение облачную SD-WAN/SDN-платформу для предоставления заказчикам ИБ-сервисов. Мы подключили к проекту вендоров, поставляющих свои решения в виртуализованном виде, и получилась огромная махина, которую мы назвали Единой платформой сервисов кибербезопасности, или ЕПСК. Ее ключевая особенность — поставка из облака технологий защиты с возможностью централизованного управления: развертывание и изменение отдельной сетевой функции или глобальная трансформация во всех обслуживаемых офисах занимают считанные минуты. Сегодня расскажем подробнее о ее архитектуре и «начинке».
Но прежде чем залезть под капот, пара слов о том, что собственно умеет ЕПСК. В состав платформы входят сервисы: по защите электронной почты (Secure Email Gateway, SEG) и веб-приложений (Web Application Firewall, WAF), по предотвращению сетевых вторжений (Unified Threat Management, UTM) и Anti-DDoS. Все они могут использоваться как одновременно, так и по отдельности — тут каждому по потребностям.
Заверните мне трафик, пожалуйста. Принципы работы ЕПСК
В общих чертах: на всех площадках заказчика устанавливаются маршрутизирующие CPE-устройства (Customer Premises Equipment). CPE обеспечивает защищенный туннель до наших ЦОДов — на платформу ЕПСК. Таким образом, к заказчику попадает только тот трафик, который был очищен на наших периметральных средствах защиты. При этом благодаря SD-WAN и туннелированию процесс доставки трафика на нашу платформу не зависит от того, сетями какого провайдера пользуется заказчик.
Архитектура платформы
Физическая инфраструктура ЕПСК — это обычные x86-серверы с развернутыми на них виртуальными машинами, коммутаторы и маршрутизаторы. Соль в том, что управлять этим богатством можно гибко и централизованно. И тут нам на помощь приходят два магических слова – VNF и MANO.
VNF (Virtualized Network Function) — это собственно сетевые функции, которые предоставляются конечным пользователям (UTM, SEG и WAF). MANO (Management and Orchestration) — набор средств по управлению жизненным циклом виртуализированных функций. Эти средства как раз и дают ту централизацию и гибкую оркестрацию, которая позволяет вносить изменения на принципиально иной скорости.
А теперь подробнее.
На границе каждого ЦОД стоит маршрутизатор Nokia 7750 SR-12 с пропускной способностью 400 Гбит/с — он обеспечивает маршрутизацию на периметре и внутри облака. Уровнем ниже располагаются Spine-коммутаторы Juniper 5100 с портами 40 Гбит/с, агрегирующие все сетевые компоненты с более низких уровней.
Виртуальная сеть включает два сегмента: SD-WAN, соединяющий облачную среду с площадками заказчиков, и SDN DC — программно-определяемая сеть внутри самого облака, посредством которой настраиваются порты, IP-адресация и т.д. при создании сервисной цепочки.
Серверная часть состоит из серверов управления облачной платформой CloudBand, серверов управления SDN, серверов управления SD-WAN (VSD, VSC) и NSG-BR (виртуальные роутеры, на которых терминируются IPsec over VXLAN туннели заказчиков) или VXLAN — в зависимости от того, используется ли IPsec-шифрование.
Белая IP-адресация для трафика заказчиков реализована на базе 2 подсетей с маской /22 (по 1018 адресов в каждой подсети): одна из них маршрутизируется в Интернет, другая – в RSNet.
Отказоустойчивость
Вся облачная инфраструктура зарезервирована на базе двух территориально удаленных ЦОД в Москве, которые работают в режиме Active–Standby. При этом любая сервисная цепочка (набор функций для конкретного клиента) разворачивается в каждом из них как кластер. В случае нештатной ситуации при переключении с одного узла на другой теряется всего около 10 пакетов. Так как TCP придумали неглупые люди, потери будут незаметны.
В дальнейшем мы планируем географическое расширение за Урал, чтобы снизить задержки передачи данных для регионов. Впрочем, на сегодня даже для Хабаровска задержки составляют всего около 200 мс — заказчики вполне успешно играют на Steam и смотрят видео с YouTube (из реального отзыва об услуге ).
В ближайшее время будет реализована возможность подключения одной CPE к двум независимым WAN. Канал может быть MPLS, Ethernet (медь или оптика в зависимости от используемой CPE), USB LTE модем и т.д. Например, основной канал может быть оптоволоконный, а резервный — беспроводной (ибо никто не застрахован от экскаватора судьбы и поврежденных проводов). В настоящее время есть возможность задействовать два WAN, но только при использовании двух CPE в HA-кластере.
Сервисные цепочки
Заказчик через ЛК выбирает базовые параметры и запускает формирование сервисной цепочки: автоматически поднимаются сетевые интерфейсы, назначаются IP-адреса и подкачиваются образы VNF в зависимости от выбранной пропускной способности. Например, если вы заказали FortiGate Firewall на 300 Мбит, для вас автоматически будет выделено 4 ядра, 8 ГБ RAM, какое-то количество дискового пространства и автоматически будет развернут образ в 0-day конфигурации.
Производительность нашей платформы сейчас рассчитана на 160 сервисных цепочек по 1 Гбит каждая, и планируется масштабирование до 1000 сервисных цепочек по 50 Мбит каждая (т.к. цепочки по 1 Гбиту будут востребованы куда реже, исходя из нашей оценки рынка).
CPE – лучше тоньше, да больше?
Собственно, для нашей услуги мы выбрали «тонкие» CPE на базе Nokia NSG-C и NSG-E200. Тонкие они только тем, что на них нельзя запустить стороннюю VNF, а в остальном имеют весь функционал, необходимый для построения связи между площадками, туннелирования (IPsec и VPN), однако для этой задачи можно использовать решения и других производителей. Также имеются Access Control Lists (ACL) для фильтрации: часть трафика можно выпускать локально, а часть — отправлять на тонкую очистку в ЦОД ЕПСК, где реализованы виртуальные функции WAF, UTM и SEG.
Также устройство умеет делать Application Aware Routing (AAR), т.е. приоритизировать полосу пропускания в зависимости от типа трафика при помощи механизмов Deep Packet Inspection (DPI). При этом в качестве каналов связи можно использовать как фиксированную, так и мобильную сеть или их комбинацию для разного трафика.
Активация CPE происходит по принципу zero touch provisioning. То есть все элементарно: подключаем CPE к интернету, с внутреннего Ethernet-интерфейса подсоединяем ноутбук, проходим по ссылке активации, далее вместо ноута включаем свою LAN — и всё работает. При этом в нашем облаке по умолчанию поднимается IPsec-туннель over VХLAN (то есть адресное пространство сначала изолируется, потом туннелируется).
В целом вариант с тонкой СРЕ кажется нам более удобным. При таком подходе заказчик избавлен от возможного вендор-лока и может в любой момент масштабировать решение, не упираясь в толщину CPE (50 Мбит/с).
В случае же с толстой CPE на ней, помимо прочего, реализованы и выбранные клиентом виртуальные функции, а в ЦОД ЕПСК находится только управление сервисной цепочкой. Плюс этого подхода в том, что весь траффик обрабатывается локально. В то же время стоимость такого устройства куда выше, а больше одного конкретного сервиса на нем не сделать – требуется закупать дополнительные CPE. Да и о мультивендорности тут можно забыть.
Но если у заказчика есть достаточно крупная площадка (офис, филиал), пропускающая через себя много трафика (больше 200 Мбит/с), и он хочет все фильтровать локально, то есть смысл обратить внимание на CPE Nokia серии NSG E300 (и выше) c пропускной способностью от 1 до 10 Гбит, которые поддерживают виртуализацию (VNF).
По умолчанию SD-WAN заводит все площадки заказчика в full mesh сеть, то есть связывает их между собой по принципу «каждая с каждой» без дополнительной фильтрации. Это позволяет снизить задержки во внутреннем периметре. Однако есть возможность строить и более сложные топологии (звезду, сложную звезду, многоранговые сетки и т.п.).
Эксплуатация
Все VNF, которые есть в облаке, на данный момент доступны в классической доктрине MSSP, то есть находятся под нашим управлением. В дальнейшем у заказчиков появится возможность управлять этими сервисами самостоятельно, но тут важно здраво оценивать свои компетенции.
Некоторые простые функции уже сейчас частично автоматизированы. Например, в Secure Mail Gateway по умолчанию настроена политика, при которой пользователь раз в сутки получает список писем, потенциально относящихся к спаму, и может самостоятельно решать их дальнейшую судьбу.
Какие-то глобальные проблемы и уязвимости, которые отслеживаются нашим JSOC, будут оперативно закрываться в том числе и для клиентов ЕПСК. И тут возможность централизованного управления политиками и сигнатурами как нельзя кстати — это позволит защитить заказчиков от заражений типа Petya, NotPetya и прочих.
Честные ответы на неловкие вопросы
На самом деле, хотя мы и очень верим в преимущества сервисной модели, понятно, что для многих сама концепция ЕПСК слишком непривычна. Что у нас спрашивают чаще всего:
— В вашем ЦОД стоит FortiGate, то есть вы будете видеть наш трафик?
— Нет, трафик мы не видим. FortiGate получает его в зашифрованном виде, расшифровывает ключом от заказчика, проверяет и обрабатывает поточным антивирусом, зашифровывает обратно тем же ключом и только после этого выдает в вашу сеть. Вариантов вклиниться в этот процесс у нас нет (разве что заняться реверс-инжинирингом суровых инфобезных решений, но это уж слишком дорого).
— Можно ли сохранить нашу сегментацию сети при переходе в облако?
— А вот тут есть ограничение. Сегментация внутри сети — не облачная история. UTM — это граничный файервол сети заказчика, на котором нельзя сделать сегментирование, то есть ваши данные идут вовне в едином канале. В каком-то смысле можно сегментировать сеть внутри ACL на CPE, настроив для разных площадок разные ограничения. Но если у вас есть бизнес-приложения, которые должны по-разному взаимодействовать друг с другом через межсетевой экран, то вам по-прежнему нужно будет использовать отдельный FW для внутренней сегментации.
— Что станет с нашими IP-адресами при переходе в облако?
— В большинстве случаев придется поменять свои белые IP-адреса на наши. Исключение возможно в том случае, если у вас есть провайдеронезависимая автономная система (PI AS), аллоцированная за вами, которую можно переанонсировать от нас.
Иногда логичнее выбрать комплексный вариант — например, пользовательский трафик пустить через UTM, а другие сегменты сети выпускать в интернет напрямую.
— А если надо защитить сайт, который у внешнего провайдера?
— CPE туда не поставить. Можно подключить WAF через смену ADNS записи: поменять IP сайта на IP сервисной цепочки, и тогда трафик пойдет через наше облако без помощи CPE.
Если у вас есть другие вопросы, пишите в комментариях, а мы постараемся на них ответить
Автор: SolarSecurity
