Введение
Ранее я писал цикл статей: первая, вторая, третья, четвертая. В этой я бы хотел порассуждать на тему безопасности сети SD-WAN в рамках услуги «сеть по подписке».
Подписочная модель предоставления сети подразумевает нулевые затраты (CAPEX) на оборудование. Сеть предоставляется «под ключ» как сервис (или, другими словами, 100% OPEX), все необходимое оборудование доставляется на площадку заказчика в рабочем и настроенном состоянии в «аренду». Бизнес получает рабочую транспортную сеть на удаленных площадках с заданным SLA без необходимости капитальных затрат, найма персонала и прочего.
Когда заходит речь о выборе варианта внедрения решения SD-WAN: как сервис (SaaS) или «все у себя» (On-prem), я иногда слышу фразу: «сервис – это не безопасно». В данной статье я хотел бы порассуждать на тему безопасности сервисной модели SD-WAN в целом и решения от Касперского 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, кластер
База данных MariaDB, кластер
Конфигурация СРЕ
Конфигурация оркестратора (например, файлы сертификатов и ключей)
Конфигурация хостовых виртуальных машин
Конфигурация машины со скриптами и ключами автоматической установки (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 «полностью у себя», надо быть готовыми включаться в этот процесс и нести дополнительные расходы. Наоборот, сервисный провайдер может решить вопросы безопасности более эффективно, но это только в том случае, если вопрос «доверия» уже решен.
