Несегментирование виртуализации

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

Привожу конкретное требование из 21 Приказа ФСТЭК:

№	Содержание	УЗ-4	УЗ-3	УЗ-2	УЗ-1
ЗСВ.10	Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей		+	+	+

Получается, что начиная с УЗ-3 уже необходимо морочиться с сегментацией. Однако в требовании ничего не говорится о сегментировании в зависимости от УЗ.

Теперь привожу другое требование о сегментировании систем вообще:

№	Содержание	УЗ-4	УЗ-3	УЗ-2	УЗ-1
ЗИС.17	Разбиение информационной системы на сегменты (сегментирование информационной системы) и обеспечение защиты периметров сегментов информационной системы			+	+

Здесь уже сегментирование начинается с УЗ-2. Также ничего не говорится о зависимости от УЗ.Смотрю Приказ выше и привожу общее требование по виртуализации:

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

Спрашивается, почему не нужно сегментировать железо и нужно сегментировать виртуализацию? Понятно, что в этом случае риски выше (сбои, отказы, кражи), но и непрерывность бизнеса (доступность, восстановление) осуществить гораздо легче. Сопоставив одно, второе и третье можно сделать вывод о том, что сегментирование в понимании ФСТЭК это лишь подсистема доступа. А разграничить и контролировать доступ к ПДн, находящихся в виртуальной инфраструктуре, можно любыми способами:

• политики доступа
• правила на МСЭ
• логирование доступа

Другие точки зрения на то, чтобы не использовать vGate и другие СЗИ приветствуются.

Про RISSPA о виртуализации

Попался мне документ по защите виртуальной инфраструктуры, который разработали Мария Сидорова и Евгений Родыгин при участии нескольких рецензентов. Красной нитью всего документа проходит мысль о том, что нужно использовать правильные СЗИ.

Приводятся актуальные угрозы виртуальной инфраструктуры:

·         НСД к ВМ через гипервизор;

·         НСД к ВМ через управление;

·         прямой доступ к файлам ВМ;

·         изменение конфигураций ВМ;

·         модификация команд управления;

·         модификация гипервизора в т.м. вирусом;

·         потеря производительности, отказ в обслуживании гипервизора.

Угрозы правильные, на их основе и должна строиться защита. А вот и нет!

Далее приводится стандартный список требований из 21 Приказа ФСТЭК, и сразу возникают вопросы, как это многочисленные МСЭ могут парировать чуть ли не все угрозы:

	Требование	МСЭ
1	Идентификация и аутентификация субъектов доступа и объектов доступа в виртуализированной инфраструктуре, в том числе администраторов управления средствами виртуализации	Х
2	Управление доступом субъектов доступа к объектам доступа в виртуализированной инфраструктуре, в том числе внутри виртуальных машин	Х
3	Регистрация событий безопасности в виртуализированной инфраструктуре	Х
4	Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуализированной инфраструктуры, а также по периметру виртуализированной инфраструктуры	Х
5	Доверенная загрузка серверов виртуализации, виртуальной машины (контейнера), серверов управления виртуализацией
6	Управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных	Х
7	Контроль целостности виртуализированной инфраструктуры и ее конфигураций	Х
8	Резервное копирование данных, резервирование технических средств, программного обеспечения виртуализированной инфраструктуры, а также каналов связи внутри виртуализированной инфраструктуры	Х
9	Реализация и управление антивирусной защитой в виртуализированной инфраструктуре
10	Разбиение виртуализированной инфраструктуры на сегменты (сегментирование виртуализированной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей	Х

Понятно, что МСЭ будет располагаться перед входом в виртуальную инфраструктуру, но совершенно не понятно как его использование будет выполнять выделенные мною требования.

Было бы куда интереснее, если авторы прошлись по этим требованиям и рассмотрели возможность их реализации штатными средствами или же доказали невозможность этого подхода в принципе.

А теперь, берем Уровень защищенности 3, к которому придут большинство операторов ПДн, размышлением и последующим написанием правильной Модели угроз. Сертифицированные СЗИ также учитываться не будут в виду постоянной размытости формулировок «в том числе посредством», «в случаях, когда применение таких средств необходимо».

Требований по защите получается всего пять и с ними прекрасно справляются штатные средства:

	Требование	Штатные средства
1	Идентификация и аутентификация субъектов доступа и объектов доступа в виртуализированной инфраструктуре, в том числе администраторов управления средствами виртуализации	VMware/Hyper-V
2	Управление доступом субъектов доступа к объектам доступа в виртуализированной инфраструктуре, в том числе внутри виртуальных машин	VMware/Hyper-V
3	Регистрация событий безопасности в виртуализированной инфраструктуре	VMware/Hyper-V
9	Реализация и управление антивирусной защитой в виртуализированной инфраструктуре	Любой антивирус
10	Разбиение виртуализированной инфраструктуры на сегменты (сегментирование виртуализированной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей	Любой МСЭ

Коллеги, если кто-то считает, что высказанная точка зрения не имеет право на существование, прошу закидать меня комментариями.

Облачная политика

На рынке уже присутствуют  следующие облачные сервисы ИБ (раньше подумать об этом было даже страшно): антивирус/антиспам, DLP, оценка рисков/самооценка, управление инцидентами, DDoS и даже антифрод! Их количество продолжает расти, поэтому необходимость такой политики существенно возрастает.

1.       Общее

1.1. Виды облаков:

-        корпоративное (собственное)

-        коммерческое (чужая компания)

-        общественное (социальные сети)

1.2. Виды инфраструктур

-        инфраструктура как услуга;

-        платформа как услуга;

-        ПО как услуга.

2.       Поставщики услуг

2.1. Проведение анализа рисков

2.2. Виды рисков

-        операционный;

-        правовой;

-        репутационный;

-        стратегический;

-        риск ликвидности.

2.3. Выбор поставщика услуг

3.       Передаваемые сервисы

3.1. Критерии по типам информации:

-        общедоступная;

-         внутренняя;

-        конфиденциальная;

3.2. Критерии по уровням ущербов:

-        потеря конфиденциальности;

-        потеря доступности;

-        потеря целостности.

3.3. По экономике процесса:

-        стоимость  развертывания;

-        стоимость эксплуатации;

-        стоимость модернизации;

-        стоимость уничтожения.

3.4. Выбор подходящего вида сервиса и облака.

4.       Информационная безопасность

4.1. «Обычные» меры:

-        аутентификация;

-        группы доступа;

-        шифрование канала;

-        логирование;

4.2. Непрерывность бизнеса

-        резервное копирование;

-        резервирование канала;

-        резервирование сервиса.

5.       Заключение договора

5.1. Сроки

5.2. Конфиденциальность

5.3. Информационная безопасность

5.4. Ответственность

6.       Контроль работы сервиса

6.1. Метрики

-        доступность;

-        загрузка канала.

6.2. Ответственность.

Виртуальная безопасность

Виртуальная безопасность

До виртуализации

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

Применение виртуализации

Теоретически технологии виртуализации призваны отделить задачи друг от друга, в том числе задачи бизнес уровня от уровня инфраструктуры. Более того, хорошим тоном в части обеспечения высоких показателей надежности является выполнение (размещение) лишь единственной задачи на каждом виртуальном сервере. Именно так и рекомендует поступать компания Microsoft. Недостатком такого подхода является большое количество необходимых дополнительных лицензий на серверные операционные системы.

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

Плюсы и минусы виртуализации

Плюсы виртуализации	Минусы виртуализации
Большее количество ВМ на том же количестве физических серверов	Выход из строя физического сервера делает недоступным сразу несколько ВМ
Простое разворачивание ВМ из шаблонов	Общее падение быстродействия при загрузке дисковой подсистемы какой-либо ВМ
Возможность клонирования ВМ
Возможность миграции ВМ между физическими серверами и/или эвакуации ВМ на другие сервера
Быстрое восстановление ВМ после сбоев оборудования
Возможность централизованного управления ВМ
Возможность резервного копирования на уровне ВМ
Экономия места в коммутационных шкафах и стойках серверной
Снижение уровня потребления электроэнергии, уровня шума, тепловыделения оборудования и т.д.

Изменение рисков при использовании виртуализации

Уменьшение рисков	Увеличение рисков
Риск зависимости программной части сервера от работоспособности физического сервера	Риск потери доступности при выходе из строя физического сервера
Риск простоя переведенных на ВМ серверов	Риск уничтожения всех ВМ при выходе из строя дисковой подсистемы
	Риск утечки данных вместе с ВМ
	Риски хранения конфиденциальных данных вместе с обычными данными
	Риски сетевого взаимодействия ВМ, не выходящие за пределы физического сервера

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

Методы защиты физических и виртуальных машин

Методы защиты физического сервера

Бесперебойное обеспечение электропитанием

Защита хостовой ОС

Защита гипервизора

Защита сервера управления

Защита консоли управления

Разграничение доступа к каждой ВМ

Разграничение ресурсов для каждой ВМ

Защита ВМ друг от друга

Обеспечение безопасности трафика между компонентами среды виртуализации

Общие методы защиты

Доверенная загрузка ОС

Разграничение доступа

Регистрация и учет

Антивирусная безопасность

Межсетевое экранирование

Анализ защищенности

Предотвращение вторжений

Контроль портов и интерфейсов

Криптозащита (при необходимости, как функциональная и обеспечивающая составляющие)

Методы защиты виртуальной машины следуют из общих методов защиты, а также:

Контроль целостности каждой ВМ

Защита от возможных целевых атак на гипервизор, хостовую ОС, сервер управления, консоль управления.