
Только за прошлый год, по данным АНО «ЦКИТ», российский рынок виртуализации вырос на 40 % — до 19,4 млрд рублей. Вместе с тем растёт и необходимость защиты такой инфраструктуры. Рассказываем, в каком состоянии рынок средств безопасности для сред виртуализации и что его ожидает в ближайшие годы.
- 1. Введение
- 2. О важности микросегментации
- 3. Как построить сетевую безопасность, готовую к новой реальности
- 4. Выводы
Введение
Всего за четыре года с момента ухода западных вендоров из России отечественный рынок виртуализации заметно изменился и нарастил объёмы. В первую очередь значительно увеличилось количество российских разработчиков платформ виртуализации, и сейчас сегмент подходит к определённому этапу зрелости: сформировался пул лидеров, чьи продукты прошли уже несколько циклов эксплуатации, обратной связи и доработки, определились нишевые игроки, которые специализируются на отдельных сегментах виртуализации, плюс окончательно прекратили существование вендоры, чьи продукты не выдержали конкуренции и не нашли своего потребителя.
Однако надо признать, что на данный момент виртуализация не так популярна среди российских компаний, поэтому возможности российских вендоров пока что ограничены, по крайней мере в сравнении с глобальными производителями. В связи с этим имеющиеся ресурсы вкладываются непосредственно в развитие сред виртуализации, а смежные направления, в том числе кибербезопасность, разработчики вынуждены отдавать профильным ИБ-компаниям.
На этом фоне важную роль играет возрастающая производительность серверов, на которых размещается всё большее число виртуальных машин. А чем плотнее виртуальная инфраструктура, тем больше трафика, а значит, и другой требуемый уровень безопасности. Потянуть такой уровень могут только вендоры с большим опытом.
Посмотрим, что происходит на рынке и чего можно ожидать в будущем.
О важности микросегментации
Весной этого года в силу вступил приказ ФСТЭК России № 117, который существенно обновил требования к безопасности. Среди прочих нововведений важная роль отводится необходимости сегментации сети, а для первого класса защищённости – и микросегментации, которая постепенно становится своего рода правилом хорошего тона для кибербезопасности.
Почему? Во-первых, это один из самых эффективных способов превентивной защиты, ведь логично, что чем больше изолированных друг от друга сегментов сети, тем сложнее злоумышленнику продвигаться по инфраструктуре — на входе в каждый новый сегмент нужен отдельный доступ. Во-вторых, микросегментация даёт гибкость. С её помощью можно сделать сегменты любого размера в зависимости от особенностей инфраструктуры и требований к безопасности, например изолировать конкретные серверы, отдельную виртуальную машину или группу пользователей.
Несмотря на то что преимущества микросегментации очевидны, да и регулятор прямо заявляет о необходимости её использования, пока эту модель нельзя реализовать во всех инфраструктурах. Причин тому несколько:
- Производительность. Это ахиллесова пята для многих ИБ-решений, и в организации микросегментации пропускная способность тоже становится проблемой. Да, можно выводить трафик каждого отдельного сегмента на свой межсетевой экран, но это не слишком рационально, поскольку превращает NGFW в критическую точку, плюс высокопроизводительных NGFW не так много на рынке и цена их довольно высока.
- Скорость изменений. Физическая инфраструктура строится годами, а циклы закупки нужного оборудования длятся месяцами, при этом ИБ- и ИТ-специалисты чётко понимают, какие продукты у них будут и для чего они нужны. Поменять всё в одночасье на виртуализированную среду и соответствующие ИБ-средства крайне сложно.
- Усложнение политики безопасности. Большое количество сегментов = сложная политика фильтрации, то есть увеличение числа правил повышает трудозатраты на их сопровождение либо вероятность ошибок, которые ведут к простою систем или открывают дополнительные двери для злоумышленников.
Таким образом, мы видим, что на данном этапе первоначальные сложности, которые неизбежны при внедрении модели, больше отпугивают, хотя и польза от микросегментации весьма заманчива.
Впрочем, сейчас ИБ-вендоры работают над тем, чтобы внедрение микросегментации было прозрачным для инфраструктуры. Один из возможных способов решения — интегрировать средство безопасности непосредственно в среду виртуализации, то есть трафик перехватывается именно на уровне виртуальных машин, не требуя дополнительных устройств.
Важный плюс такого решения — ИБ-средство «знает» виртуальную среду, и если та мигрирует с одного сервера на другой, то правила фильтрации не нужно переназначать: они просто переезжают вместе со средой. Для небольших компаний это, может быть, не очень важно, зато совершенно по-другому звучит для тех организаций, чей серверный парк насчитывает сотни единиц и регулярно пополняется.
В любом случае детальная сегментация и усиление контроля за разными узлами ИТ-инфраструктуры – это тот общий вектор, к которому движутся регуляторные требования и который становится новой нормой.
Как построить сетевую безопасность, готовую к новой реальности
Современная инфраструктура постепенно разъезжается по разным средам: физической, виртуальной, контейнерной, публичным облакам. Чтобы выстроить всё на должном уровне безопасности, необходимо заранее озаботиться определёнными принципами, с помощью которых мы будем всем управлять. Технологии и архитектурные подходы определяются уже после того, как мы поймём, каким образом управляется наша инфраструктура. Поэтому необходимо придерживаться следующего алгоритма.
Чётко определить и разграничить полномочия и ответственность за проект в области сетевой безопасности. В первую очередь это касается сегментации, потому что, например, в случае с виртуализацией и контейнеризацией эта ответственность «плавает» между «безопасниками», «сетевиками» и администраторами сред виртуализации. Важно определить конкретные сферы ответственности и иерархию между командами.
Отделить процесс дизайна и проектирования зон безопасности от процесса выбора и внедрения средств сегментации. Сначала требуется определить принцип, согласно которому сегментируется сеть. Это может быть территориальное деление, критическая значимость сегментов, соответствие организационно-штатной структуре и так далее. После этого идёт выбор инструментов для реализации принципов. В таком случае у нас хвост не будет вилять собакой.
Предусмотреть интеграцию дополнительных контролей для закрытия актуальных рисков. Когда мы говорим про сетевую безопасность, то понимаем, что её ключевой элемент — сегментация, но при этом ИБ-рисков у нас существенно больше. И для каждого из них нужны дополнительные механизмы.
Таблица 1. Механизмы защиты и риски, ими покрываемые
|
Механизм защиты |
Покрываемый риск |
|
Мониторинг безопасности для многовекторных атак: SIEM, XDR |
Реализация сложных атак |
|
Централизованное управление для больших политик: NSPM |
Ошибки в настройках политики |
|
DLP для конфиденциальных данных |
Утечка информации |
|
IDS / IPS, IoC-шлюзы, NTA, песочница для сегментов, близких к Интернету |
Сетевая вредоносная активность |
|
DPI для любого уровня трафика выше 4-го |
Использование «хитрых» приложений |
|
Шифрование трафика, выходящего за пределы контролируемых зон |
Подслушивание и перехват трафика |
Унифицировать управление политикой безопасности. При добавлении новых инструментов необходимо заранее продумать возможность их интеграции без изменений в политиках. Здесь нужно учитывать несколько моментов:
- перспективные СЗИ должны интегрироваться в существующий конвейер изменений — бизнес-процесс, в который входят согласование, применение и проверка применения политик безопасности;
- требуется автоматизировать инвентаризацию и обнаружение новых активов, а также их добавление в группы безопасности. Нельзя защитить то, о чём ты не знаешь, например новый компьютер в инфраструктуре. Поэтому нужно автоматизировать процесс актуализации новых элементов инфраструктуры, чтобы дополнительные сетевые активы сразу появлялись в базе;
- проверка автоматически сформированной политики и её установка в средства защиты должна контролироваться человеком — это обязательное условие хорошей системы кибербезопасности;
- процесс управления изменениями требует особого внимания. Для этого необходимо определить, кто имеет право подавать запросы на изменение политики безопасности, кто отвечает за их проверку и имплементацию, как будет осуществляться контроль соглашения о качестве (Service Level Agreement, SLA), то есть сколько времени будут занимать действия по изменениям. Сюда же входит работа с обработкой запросов на экстренное изменение, которая также требует тщательного подхода.
Эти пункты крайне важны, потому что без них попытки разбить инфраструктуру на микросегменты, внедрить принципы сетевого доступа с «нулевым доверием» (ZTNA) и правильно разграничить доступ будут сопровождаться ошибками. Поэтому крупные корпоративные заказчики в первую очередь должны чётко выработать принципы, согласно которым будет эксплуатироваться ИТ-инфраструктура, и только потом можно приступать к отбору соответствующих механизмов.
Выводы
Виртуальная инфраструктура всё ещё находится в стадии формирования, и её конечный вид остаётся неясным. К 2030 году у заказчиков может быть реализована комбинация из трёх вариантов:
- Массовая миграция с зарубежного оборудования на российское, при этом будет сохранена «классическая» аппаратная архитектура.
- Акцент на программно определяемой инфраструктуре, когда сетевые функции переносятся на серверы общего назначения, а поверх них работает программный слой, управляющий потоками трафика.
- Инфраструктура переезжает в публичные облака либо в рамках некой гибридной модели, либо полностью.
Горизонт до 2030 года выбран неслучайно. Дело в том, что сейчас инфраструктурные решения отечественного производства внедряются не очень активно. Во-первых, с технической точки зрения продукты порой не соответствуют всем требованиям заказчиков. Во-вторых, глобальные перестройки требуют длительной подготовки, чёткого плана и кропотливых пилотных проектов по выбору продуктов, что заставляет заказчиков осмотрительно относиться к масштабным переменам. Так что вопрос с переформатированием архитектуры всей ИТ-инфраструктуры будет откладываться на максимальный возможный срок.
Эта неопределённость в конечной форме ИТ-инфраструктуры оставляет ИБ-вендоров в несколько подвешенном состоянии, поскольку им нужно учитывать все варианты развития, а значит, искать общие принципы обеспечения безопасности инфраструктуры.


