«До свидааания, черт с тобой!»: как мы спасали наши сервисы ИБ после ухода зарубежных вендоров
Окончен бой, зачах огонь и не осталось ничего,
А мы живём, а нам с тобою повезло назло.
Агата Кристи, «Как на войне»
м/ф «Мадагаскар»
Для многих российских компаний уход иностранных вендоров ПО и железа стал, мягко говоря, ударом под дых. Сервис-провайдерам пришлось вдвойне тяжело: им надо было обеспечить кислородной маской необходимым софтом не только себя, но и своих заказчиков. Немалая часть наших сервисов ИБ базировалась на западных решениях. Что-то стало работать с урезанным набором функций, а что-то из-за отзыва лицензий просто превратилось в кирпич. На долгие поиски альтернативы времени не было, часть компаний уже находилась под атаками. С чем мы столкнулись, когда зарубежные вендоры стали отзывать лицензии и сворачивать техподдержку, как искали им замену и что делали, когда остались без оркестратора — расскажем в этом посте.
Больно, но терпимо
С частью описанных проблем столкнулись, наверное, почти все, кто сейчас читает этот пост. Первая и самая очевидная была связана со сворачиванием локальных офисов зарубежных вендоров и прекращением полноценной техподдержки. Поэтому мы решили начать с людей: усилили свои технические команды развития и эксплуатации. Так мы избавились от острой потребности в сторонней экспертизе и сейчас можем закрывать эти задачи собственными силами.
С аппаратными платформами было сложнее. Здесь нам помог архитектурный подход с многократным резервированием каждого из компонентов (в «обычной жизни» это позволяет распределить нагрузку на платформу и сделать работу сервисов более стабильной). Кроме того, мы изначально проектировали сервисы с солидным запасом аппаратных ресурсов, чтобы гарантировать их высокую производительность. Благодаря этому используемые нами платформы могут «жить автономно» года три.
С лицензиями на ПО тоже, естественно, возникли сложности. Как и в случае с аппаратными мощностями, лицензии мы закупали с большим запасом и планами на будущее. Часть решений внутри платформ основаны на лицензировании по принципу Right-to-Use, то есть технической возможности отзыва там просто нет. Так что пока держимся и ищем альтернативное ПО.
Зато можно обновиться… Ну, как можно? Даже если удалось скачать апдейт окольными путями, доверия к новым версиям скорее нет. В нынешних условиях появление в них недекларированных возможностей кажется весьма вероятным. Поэтому сейчас стоит 100 раз подумать прежде, чем загрузить то или иное обновление. Конечно, если установить обновление просто необходимо, мы проводим функциональные и нагрузочные тесты, чтобы минимизировать риски, но исключить их полностью, увы, невозможно.
Дальше возник вопрос железа. Как закупить оборудование на замену (ЗИП) и для расширения вычислительных и сетевых мощностей? Вариантов тут немного: найти альтернативные подходы к выстраиванию логистических цепочек или проработать паритетные замены по серверному и сетевому оборудованию. Пока спасает имеющийся запас прочности: большой ресурс оборудования позволит проводить замену каждого из компонентов примерно три года.
Как конкретно это было
А теперь разберемся на конкретных примерах. Два наших сервиса базировались на решениях американской Fortinet: для защиты электронной почты (SEG) использовался FortiMail, а для защиты от сетевых угроз (UTM) — FortiGate. Компания стремительно отозвала свои лицензии в начале марта, хоть до последнего и утверждала, что не планирует ходить с российского рынка.
UTM превратился в кирпич
Сервис защиты от сетевых угроз в один миг превратился в тыкву из-за особенностей лицензирования (один из немногих, он не был реализован по принципу Right-to-Use). Мы работали с вендором по схеме, предусмотренной для MSS-провайдеров, — облачное лицензирование. К этой лицензии привязывались поинты для использования виртуальными машинами FortiGate наших клиентов. В качестве сервера лицензий использовался локально развернутый FortiManager в HA-конфигурации, который на постоянной основе общался с облаком FortiGuard для валидации лицензии и списывания использованного баланса поинтов. Это позволяло более гибко конфигурировать сервис для каждого клиента и платить только за тот набор функций, который востребован. Дополнительные опции по необходимости можно было подключить и отключить в онлайн-режиме. Кроме того, такой тип лицензии позволял не расходовать лишние ресурсы — ни наши, ни клиента. В общем, все это было очень удобно до поры, до времени. При невозможности проверить валидность лицензии межсетевой экран вообще перестал маршрутизировать трафик, делая информационные системы заказчиков недоступными.
К счастью, Fortinet, хоть и был самым востребованным, но не единственным нашим вендором для сервиса UTM. В частности, мы находились на финальном этапе тестирования отечественного UserGate. Экстренное переключение на российского вендора мы в итоге реализовали в течение одного-двух дней. Нам помог тот факт, что мы уже имели паритетные решения под замену. Также у нас в арсенале был (и пока остается) израильский Check Point.
Почти без SEG
Сервису защиты электронной почты повезло чуть больше — письма продолжали проходить. Но из-за отзыва лицензий решение лишилось возможности обновлять свои сигнатуры и правила в онлайн-режиме. А значит, мы не могли гарантировать клиентам качественную защиту электронной почты. Да, у нас была техническая возможность обновлять часть функциональных модулей защиты офлайн, что полностью обесценило бы преимущества облачного сервиса.
Но все-таки SEG не превратился в кирпич, дав нам возможность проработать замену базового решения. Мы постепенно занимались этим вопросом, но такого готового ответа, как с UTM, не было. На данный момент прорабатываются варианты подключения от российских вендоров.
VM остался без облака
Еще один сервис, который оказался недоступен после отзыва лицензий, это сервис контроля уязвимостей (VM). Для него мы использовали облачный американский сканер Qualys. Тут все было относительно просто: нет лицензии, нет доступа к сканеру. Было очевидно, что в новых условиях заменить решение можно только отечественным облаком. Мы уже работаем с одним из российских вендоров, так что без сканирования периметра заказчики не остались. Пока сервис ориентирован скорее на массовый средний и крупный бизнес. Однако в ближайших планах — расширение облака под нужды крупного Enterprise-сегмента.
Как мы остались без оркестратора
Итак, мы были готовы к миграции клиентов, но в этот момент словили аварию с нашим высокоуровневым оркестратором, через который обеспечивается развертывание сервисов для клиентов и изменение параметров сервиса, включая замену одного решения на другое. Наверное, аварии в таких условиях мы бы не избежали, как бы ни старались.
Во-первых, на нас обрушился резкий приток клиентов, которым срочно нужна была защита от всего и сразу. Кроме того, для их подключения нам пришлось выделить дополнительные серверные мощности, которые обычно резервируются под менеджмент компонентов облака. Вдобавок у нас шла миграция сервисов на обновленную платформу, а на это нужны были дополнительные мощности. Ну, и до кучи — новые решения требовали больше мощностей, чем, например, тот же FortiGate.
Словом, мы остались без инструмента по управлению сервисами внутри сервисной платформы, возможности ждать его восстановления не было: обязательства перед клиентами никто не отменял. Поэтому команда наших инженеров оперативно переработала существующие дескрипторы по автоматизации, которые дергаются с внешнего оркестратора платформы во внешние по отношению к платформе плейбуки. Это позволило развернуть сервис с тем же уровнем автоматизации, но в обход оркестратора. Короче, подготовили плейбуки, согласовали график и вручную провели работы по замене на альтернативные решения.
Вообще развертывание сервиса у нас полностью автоматизировано. По нажатию кнопки разворачиваются выделенные тенанты на всех уровнях платформы, создается выделенная логическая сетевая и вычислительная инфраструктура, разворачивается необходимый набор сетевых функций VNF, организуются взаимосвязи между компонентами в рамках SDN/SD-WAN частей платформы в соответствии с дизайном нужного сервиса, настраиваются сами VNF, создаются отказоустойчивые конфигурации и т.д. А это тысячи строк кода.
Давайте без старых граблей
Опыт экстремального перехода на новых вендоров был, конечно, незабываемым, но повторять его совсем не хочется. Поэтому сейчас очевидно, что, выбирая технологии для наших сервисов, мы будем отдавать предпочтение отечественным решениям.
Также мы еще раз убедились, что все решения надо интегрировать в собственную инфраструктуру и разворачивать исключительно на своем облаке, чтобы у нас всегда был доступ ко всем технологиям, которые мы используем. Так у нас всегда будет полный контроль над инфраструктурой сервисов. Однако, как мы писали выше, всегда есть риск различных НДВ — этот риск сокращает сертификация ФСТЭК.
И, конечно, надо отдать должное нашим клиентам, которые, понимая ситуацию, так же шли нам навстречу, не сильно ругались и давали необходимую обратную связь. Сейчас задача доступности сервисов и защищенности клиентов решена. Импортозаместились %@&#, как говорится!
