SD-WAN и трудности миграции: безопасна ли облачная модель

Иногда слово «безопасность» подменяют недоверием: «Мы всем не верим, поэтому будем размещать оборудование у себя». Я понимаю, что в этих словах есть своя обоснованная правда, но в данной статье я встану на защиту сервисной модели. Не буду касаться «веры» и необъективных фактов, только рассуждения на тему безопасности в SD-WAN.

Риски действительно есть:

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

• — Законодательство РФ запрещает хранить определенные типы данных за рубежом, а, например, даже события аудита могут содержать «запреты».

• —Некоторые высокие классы защиты требуют очень жестких организационных мер работы с СКЗИ, которые просто невозможно выполнить в рамках сервиса SD-WAN.

А нужен ли SD-WAN

Если для вашей компании можно определить SLA для работы инфраструктуры и сетевой связности, то эта статья для вас, и скорее всего SD-WAN вам предоставит реальные инструменты и выгоду. Осталось подобрать оптимальную модель.

Если же в вашей инфраструктуре нет четкого понимания стоимости простоя филиала, и решение инцидента может занимать 4-8-24 часа, и «никто не пострадает» либо «никто не заметит», то вы скорее всего не оцените и не поймете необходимость реализации мер, описанных в этой статье. Они покажутся вам чрезмерно избыточными и дорогими.

Работать 24х7, без перерывов и быстро вернуться к работе в случае сбоев – это преимущество «настоящих» современных SD-WAN решений. Но за этой «облачностью» стоят вполне реальные «объекты», которые необходимо поддерживать и защищать.

Центральный компонент настоящего SD-WAN – система управления. При «падении» центральной системы управления выходит из строя вся сеть. Централизация – это и благо, и новый «вызов»: за новый функционал и качество (SLA) приходится платить.

Децентрализованные сети, где каждый узел принимает решение «сам» постепенно становятся более дорогими по сравнению с программно-управляемыми.

Не хочу сказать, что современные сети SD-WAN работают стабильно на 100%. Чем моложе технология, тем более вероятны ошибки и некорректное поведение центрального компонента. Тем не менее, управление в центре позволяет объективно предложить лучший интеллектуальный путь для данных нежели традиционные сети.

Архитектура на примере Kaspersky SD-WAN

Рассмотрим архитектуру решения, представленного на российском рынке имеющему возможность работы в мульти-тенантном режиме. Мы в команде часто пользуемся данным решением для предоставления SD-WAN по подписочной модели, а также разворачиваем его по модели on-prem, для тех, кто выбрал именно этот вариант. За несколько лет эксплуатации удалось «набить шишек» и накопить определенный опыт.

Частично решение от Kaspersky SD-WAN описывал ранее в разделе «теория» в этой статье.

Решения SD-WAN от Касперского многослойное и «многокомпонентное», где каждый компонент вносит свой вклад в общий уровень безопасности. Решение выделяет несколько независимых абстракций:

• — Data plane (передающий уровень)

Каждый тенант имеет независимый слой передачи данных. Каждый заказчик полностью изолирован, нет пересечений потоков данных. Контролеры, занимающиеся вычислением путей для каждого заказчика независимые. Сбой и «взлом» слоя «данных» у одного заказчика не может отразиться на других. Более того, даже сам сервисный провайдер не имеет доступа в сеть данных заказчика. Все «линки» зашифрованы регулярно сменяемыми ключами, вычисляемыми на стороне СРЕ, в центральной базе данных и у сервисного провайдера ключей нет.

• — Control plane (управляющий уровень)

Программная сеть управляется контролером. Для каждого заказчика сервисным провайдером выделяются независимые виртуальные машины-контролеры, с уникальными IP адресами, расположенными в разных ЦОДах. Таким образом управляющий трафик «ходит» по независимому каналу и собирается в «центре», не используя канал данных и не пересекаясь с различными заказчиками (тенантами).

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

• — Management plane (уровень конфигурирования)

Отдельный канал для конфигурирования устройств, снятия диагностической информации и функций управления. Используется протокол HTTPS для доступа к системе управления сервисного провайдера. Система управления единая для всех тенантов. Учетные записи заказчиков имеют жесткую привязку к тенанту. Ролевая модель позволяет гибко ограничить доступы внутри каждого тенанта.

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

• —Monitoring plane (уровень мониторинга)
• 
  
• Выделяется отдельный канал для передачи метрик работы оборудования. Техническая точка сбора метрик размещается на стороне сервисного провайдера и делится между всеми заказчиками. Доступ к метрикам мониторинга осуществляется через систему управления. Так как в основе мониторинга лежит оптимизированный Zabbix, возможна интеграция с корпоративными системами заказчика в виде экспорта событий.

Схематично слои показаны на следующем рисунке:

Остальные компоненты целиком лежат на стороне «экслуатанта» SD-WAN. Работа с ЦОД, облачными провайдерами, системой каталогов, балансировками, мониторингом, аудитом, средствами защиты и др. – все это необходимые части для функционирования решения.

Далее я попытаюсь раскрыть детали наиболее важных на мой взгляд компонентов.

Составные части «безопасности»

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

Люди

Человеческий капитал – основная ценность и фактор влияющий на информационную безопасность. Когда речь идет о внедрении новой технологии, потребуется обучение или переобучение сотрудников. SD-WAN традиционно относится к инфраструктурной (сетевой) технологии, поэтому основную нагрузку по «дообучению» получают именно сетевые инженеры.

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

Для «самообучения» по SD-WAN тоже есть препятствие, так как нельзя просто взять и включить две виртуальные СРЕ на локальном гипервизоре, как в случае с традиционной сетью. Лабораторный стенд требует наличия не только системы управления, но и нескольких СРЕ подключенных к разным реальным провайдерам, на реальных каналах связи. Сделать адекватную «лабу» в домашних условиях на одном гипервизоре просто невозможно крайне сложно – получится познакомится только с интерфейсом, но вот увидеть реальные случаи «проблем» и отработать варианты решения без настоящей сети никак.

Большая нагрузка и большое количество СРЕ тоже приносит свои «вызовы». Под нагрузкой и под атаками сеть другая.

Если важна стабильность и бизнесу заметен каждый простой длительностью более 15 минут, то тут некогда читать «мануалы» и обращаться в поддержку вендора по стандартным каналам за советами – требуется прийти и починить.

Если решение «молодое», как Kaspersky SD-WAN, то неизбежно будут появляться инциденты, которых еще «не было ни у кого». Нужно отлично понимать техническую составляющую чтобы найти обходной путь пока выпускается патч или обновления.

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

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

Тренировки

Система SD-WAN позволяет обеспечивать крайне высокий уровень отказоустойчивости центра управления, «резервируясь» по схеме 3 и 5 улов. Это позволяет не зависеть от проблем одного-двух ЦОДов. Если речь идет о более масштабной катастрофе, когда выведена из строя вся инфраструктура SD-WAN, восстановление не является простой задачей. Цепочка зависимостей начинается с системы имен и включает в себя много компонентов, таких как контейнеры, базы данных разных типов, дисков, операционных систем, конфигураций СРЕ.

Недостаточно просто «переподнять» оркестратор на новом IP-адресе. Потребуется переконфигурирование СРЕ, которые в свою очередь еще не знают о новом центре управления и используют «старые» сертификаты, восстановить рассинхронизированные и/или потерянные базы данных и др. Цепочку можно «отмотать» обратно, но надо понимать четкий алгоритм действий, так как права на ошибку уже не будет.

Для определения способности команды поддержки вовремя среагировать и всё починить в установленные сроки нужны тренировки. Имитация полного сбоя (катастрофы) позволяет провести полную ревизию всех знаний, резервных копий и слаженности всей команды. Для небольших проектов это зачастую непозволительная роскошь. Для сервисных компаний – это рутина и обязанность. Каждый член команды должен не только понимать оперативную ежедневную работу, но и быть готовым восстановить и построить систему с нуля (или из резервных копий).

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

Бэкапы

Важно не только делать резервные копии, но иногда их проверять. Важный факт для Kaspersky SD-WAN: резервные копии машин не помогут быстро восстановить систему, так как основные данные хранятся в распределённых базах данных. Одной кнопкой нельзя снять абсолютно полный слепок системы, надо понимать, как работает и восстанавливается каждый компонент.

Следующие компоненты Kaspersky SD-WAN требуется «бэкапировать»:

• — База данный MongoDB, кластер

• — База данных PostgreSQL, кластер

• — Конфигурация СРЕ

• — Конфигурация оркестратора (например, файлы сертификатов и ключей)

• — Конфигурация хостовых виртуальных машин

• — Конфигурация машины со скриптами и ключами автоматической установки (ansible)

• —База данных контролера (не обязательно, так как в случае сбоя будет пересчитана с нуля)
• 
  

Мониторинг

Системы сбора и хранения логов со всех компонентов. Важная составляющая, позволяющая зафиксировать инцидент, как только он появился, и не ждать жалоб пользователей. Kaspersky SD-WAN поставляется с системой мониторинга, настроенной по «умолчанию».

Можно сказать, что система собирает только метрики и без дополнительных настроек и не оповещает инженеров о проблеме. А метрик и событий очень много, так как в сеть сама борется с проблемами и часто успешно решает их. Требуется настройка системы мониторинга «под себя» с учетом архитектуры конечной сети, иначе в потоке событий легко пропустить самые важные. Большая часть настроек требует компетенций на стороне Zabbix и/или интеграции со своей корпоративной системой.

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

Межсетевое экранирование, защита от вторжений, анти DDoS и WAF

Важные элементы защиты любой системы, «смотрящей» в интернет:

• — NFGW

• — Anti DDoS

• —WAF

Систему управления SD-WAN невозможно изолировать в закрытый сегмент, она должна быть открыта со стороны всех СРЕ. По это причине к ней предъявляются особенно сильные требования с точки зрения безопасности.

Без работающей защиты невозможно быстро отбиться от атак, а «срочный» перенос системы управления в другое место неминуемо приведет к простоям. Систему невозможно настроить один раз и навсегда, требуется постоянный тюнинг и поддержка со стороны профильных инженеров. Для сервисных провайдеров это часть своей экосистемы, для небольших сетей SD-WAN это ощутимая нагрузка на бюджет.

Антивирусная защита конечных точек

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

События и SIEM

Централизованный сбор событий со всех источников очень важен для траблшутинга и расследования инцидентов. В многокомпонентных системах события приходят в различном формате с виртуальных машин, с контейнеров и СРЕ Kaspersky SD-WAN, от EDR агентов и межсетевых экранов. Каждый тип контейнера передает события в своем, не адаптированном формате.

Парсинг и создание корреляционных правил — это то, что не входит в стандартную поставку. По умолчанию генерируются только сырые логи в файлах и контейнерах. Научить систему определять и приоритизировать инциденты ИБ — это задача для профильного специалиста.

Управление уязвимостями

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

Управление учетными записями администраторов

В больших компаниях процесс выстроен на уровне Active Directory. Есть федерации и многофакторная аутентификация. Для небольших компаний придется внедрять процессы и дополнительные решения для обеспечения хотя бы минимального уровня безопасности. Много факторная аутентификация и политики работы с учетными записями требуют специально настроенных инструментов.

Выводы

Статья не претендует на полный и счерпывающий список мер безопасности в целом, а показывает важные детали обеспечения безопасности именно решений SD-WAN и в частности решения от «Лаборатории Касперского».

Нельзя сказать, что сервисная модель SD-WAN (SaaS) является «по определению» менее безопасной. Безопасность — это комплексный процесс с множеством компонентов. Разворачивая сеть SD-WAN «полностью у себя», надо быть готовыми включаться в этот процесс и нести дополнительные расходы. Наоборот, сервисный провайдер может решить вопросы безопасности более эффективно, но это только в том случае, если вопрос «доверия» уже решен.