Межсетевой экран в среде виртуализации - Форум по вопросам информационной безопасности

Добрый день!
Подскажите пожалуйста.
Есть информационная система в которой я устанавливаю на отдельный АРМ Astra linux 1.6, на котором настраиваю виртуальную среду(например QEMU) и устанавливаю на эту виртуальную среду программный межсетевой экран (например тип/класс Б2). Получается есть информационная система, в которой есть контур в котором циркулирует ДСП и есть остальная сеть и это все разграничивает АРМ с Astr'ой на виртуалке в которой МЭ.
Такой вопрос: есть ли какие-либо нюансы или требования для такого типа установки и использования МЭ(на виртуалке)?

В Требованиях я нашёл только то, что должны отсутствовать возможности обхода МЭ, то есть в моем случае через ОС.

Спасибо.

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

Требования к МЭ 2016 года ФСТЭК. В этом документе требования к функционалу самого МЭ. Подобно как в Профилях защиты.

АРМы, объединённые в сеть, без выхода в сеть Интернет. В этой сети выделен контур, в котором будет информация ограниченного доступа(не ГТ).

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

Задаю такой вопрос просто потому что ранее с таким не сталкивался и что бы не было каких-то вопросов при проверке/аттестации и пр.

to Алексей
Епты, ИС-то по какой линии и требованиям защищать/аттестовать собираетесь? Замшелая АС (которая комм.тайна), ГИС/МИС, КИИ?
Кстати, без выхода в Интернет, это "физически отключенные" или "логически отделенные"?
imho, вам бы начать с оценки базовых требований, предъявляемых действующей нормативкой к вашей классифицированной системе. Далее рассмотреть нарушителей, их возможности и реализуемые угрозы безопасности...
Может статься, что МЭ вам в такой схеме вообще не нужен. Тем более по принципу "лепим сертифицированный программный МЭ поверх ОС с пробросом трафика в bridge из гипервизора в виртуалку и обратно" (пусть даже с использованием флагмана отечественного "кораблестроения" - AstraLinuxSE, ага)...

okо, спасибо за ответ.
ИС-замшелая АС (комм.тайна), физически нет доступа в сеть Интернет.
Модель угроз/нарушителя существует, согласована, утверждена. МЭ в системе должен быть. Просто есть необходимость установить его в виртуалку.

to Алексей
Тогда основной "затык" кроется в результатах Моделирования, ТЗ и в Техпроекте системы защиты этой АС. Ибо, если руководствуетесь СТР-К и РД АС НСД, то как определите - так и будет. Всяческие "требования по умолчанию" аля "АС с ИОД должна быть отделена от других сетей связи межсетевым экраном" - это сказки венского леса, пока не будут официально закреплены в документации по созданию (модернизации) оной АС...
Кстати, приведенные вами документы 2016 г. касаются сертификации МЭ, но никак не его применения. Есть, конечно, "правила пользования", "задания безопасности", "технические условия" и проч. особенности внедрения и эксплуатации конкретного МЭ, но это уже частности для каждого конкретного случая...
Собственно, влепить сертиф.МЭ в вирт.машину на базе 1 АРМ, где гипервизором является AstraLinux, конечно, можно. Можно это даже превратить в более-менее вменяемый вариант фильтрации. Можно даже аттестовать (тем более при аттестации замшелых АС не нужно регулятора беспокоить, ага). Но назвать это все корректным и вменяемым вариантом язык не поворачивается...
С технической стороны вопроса: первоочередно рассмотрите проблематику обработки пакетов вначале сетевыми подсистемами самого гипервизора, затем - ОС внутри виртуалки и уже в последнюю очередь драйвером установленного МЭ типа "Б". И посчитайте нагрузки / вероятность сбоев и "узких мест" при такой схеме работы...
С организационной же - еще раз рассмотрите защищаемый ресурс (инф.огр.доступа). Может статься, что упомянутое "ДСП" - это реально государственный ресурс. И тогда pro bono commune стоит переориентироваться на 17 Приказ ФСТЭК со всеми вытекающими (и забыть уже про связку СТР-К + РД как страшный сон, когда дело не касается защиты коммерческой тайны, ага)...