ИБ из облака: как устроена Единая платформа сервисов кибербезопасности

    image
    В конце прошлого года, после сделки с «Ростелекомом», мы получили в свое распоряжение облачную SD-WAN/SDN-платформу для предоставления заказчикам ИБ-сервисов. Мы подключили к проекту вендоров, поставляющих свои решения в виртуализованном виде, и получилась огромная махина, которую мы назвали Единой платформой сервисов кибербезопасности, или ЕПСК. Ее ключевая особенность — поставка из облака технологий защиты с возможностью централизованного управления: развертывание и изменение отдельной сетевой функции или глобальная трансформация во всех обслуживаемых офисах занимают считанные минуты. Сегодня расскажем подробнее о ее архитектуре и «начинке».

    Но прежде чем залезть под капот, пара слов о том, что собственно умеет ЕПСК. В состав платформы входят сервисы: по защите электронной почты (Secure Email Gateway, SEG) и веб-приложений (Web Application Firewall, WAF), по предотвращению сетевых вторжений (Unified Threat Management, UTM) и Anti-DDoS. Все они могут использоваться как одновременно, так и по отдельности — тут каждому по потребностям.

    Заверните мне трафик, пожалуйста. Принципы работы ЕПСК


    В общих чертах: на всех площадках заказчика устанавливаются маршрутизирующие CPE-устройства (Customer Premises Equipment). CPE обеспечивает защищенный туннель до наших ЦОДов — на платформу ЕПСК. Таким образом, к заказчику попадает только тот трафик, который был очищен на наших периметральных средствах защиты. При этом благодаря SD-WAN и туннелированию процесс доставки трафика на нашу платформу не зависит от того, сетями какого провайдера пользуется заказчик.

    image

    Архитектура платформы


    Физическая инфраструктура ЕПСК — это обычные 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 придумали неглупые люди, потери будут незаметны.

    image

    В дальнейшем мы планируем географическое расширение за Урал, чтобы снизить задержки передачи данных для регионов. Впрочем, на сегодня даже для Хабаровска задержки составляют всего около 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.

    Если у вас есть другие вопросы, пишите в комментариях, а мы постараемся на них ответить
    • +20
    • 3.3k
    • 2
    Ростелеком-Солар
    379.80
    Безопасность по имени Солнце
    Share post

    Comments 2

      0
      Таким образом, к заказчику попадает только тот трафик, который был очищен на наших периметральных средствах защиты.


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

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

      Only users with full accounts can post comments. Log in, please.