Всё по ГОСТу. Защита информации при использовании технологий виртуализации


    01.06.2017 был введен в действие ГОСТ Р 56938-2016 «Защита информации. Защита информации при использовании технологий виртуализации. Общие положения». Как-то так вышло, что обзор данного ГОСТ во множестве нововведений законодательства затерялся и сейчас хотелось бы восполнить данный пробел.

    Данный ГОСТ был разработан Федеральным автономным учреждением «Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю» (ФАУ «ГНИИИ ПТЗИ ФСТЭК России») и внесен техническим комитетом по стандартизации «Защита информации» (ТК 362).

    До выхода ГОСТ Р 56938-2016 для обеспечения защиты виртуализованных сред применялись рекомендации приказов ФСТЭК №17 и №21. В данных приказах есть раздел, в котором описываются требования к защите среды виртуализации. Ниже приведена таблица из приложения к приказам, перечисляющая данные требования.

    XI. Защита среды виртуализации (ЗСВ)


    ЗСВ.1


    Идентификация и аутентификация субъектов доступа и объектов доступа в виртуальной инфраструктуре, в том числе администраторов управления средствами виртуализации


    ЗСВ.2


    Управление доступом субъектов доступа к объектам доступа в виртуальной инфраструктуре, в том числе внутри виртуальных машин


    ЗСВ.3


    Регистрация событий безопасности в виртуальной инфраструктуре


    ЗСВ.4


    Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по периметру виртуальной инфраструктуры


    ЗСВ.5


    Доверенная загрузка серверов виртуализации, виртуальной машины (контейнера), серверов управления виртуализацией


    ЗСВ.6


    Управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных


    ЗСВ.7


    Контроль целостности виртуальной инфраструктуры и ее конфигураций


    ЗСВ.8


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


    ЗСВ.9


    Реализация и управление антивирусной защитой в виртуальной инфраструктуре


    ЗСВ.10


    Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки информации отдельным пользователем и (или) группой пользователей


    Не смотря на наличие требований к мерам по защите, в приказах не были определены термины по виртуализации, ГОСТ Р 56938-2016 закрывает данный пробел и определяет терминологическую базу.

    Термины


    ГОСТ Р 56938-2016 определяет 2 типа гипервизоров:

    • Гипервизор 1 типа – устанавливается непосредственно на аппаратную платформу, к таким гипервизорам по ГОСТ относятся VMware vSphere, Hyper-V, Citrix XenServer и пр.
    • Гипервизор 2 типа – устанавливается в хостовую операционную систему. К таким гипервизорам можно отнести VirtualBox, VMWare Workstation и пр.

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

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

    Так, согласно ГОСТ,
    Виртуальная инфраструктура — это композиция иерархически взаимосвязанных групп виртуальных устройств обработки, хранения и/или передачи данных, а также группы необходимых для их работы аппаратных и/или программных средств.
    ГОСТ определяет три уровня иерархии в виртуальной инфраструктуре:

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


    Три уровня иерархии в виртуальной инфраструктуре на примере стека технологий VMware

    Объекты защиты


    ГОСТ выделяет следующие основные объекты защиты при использовании технологий виртуализации:

    • средства создания и управления виртуальной инфраструктурой (гипервизор I типа, гипервизор II типа, гипервизор системы хранения данных, консоль управления виртуальной инфраструктурой и др.);
    • виртуальные вычислительные системы (виртуальные машины, виртуальные сервера и др.);
    • виртуальные системы хранения данных;
    • виртуальные каналы передачи данных;
    • отдельные виртуальные устройства обработки, хранения и передачи данных (виртуальные процессоры, виртуальные диски, виртуальную память, виртуальное активное и пассивное сетевое оборудование и др.);
    • виртуальные средства защиты информации (ЗИ) и средства ЗИ, предназначенные для использования в среде виртуализации;
    • периметр виртуальной инфраструктуры (задействованные при реализации технологий виртуализации центральные процессоры и их ядра, адресное пространство памяти, сетевые интерфейсы, порты подключения внешних устройств и др.).

    Угрозы безопасности


    ГОСТ акцентирует внимание на том, что использование технологий виртуализации создает предпосылки для появления угроз безопасности, не характерных для информационных систем, построенных без использования технологий виртуализации. Угрозы, дополнительно могущие возникать при использовании технологий виртуализации, перечислены далее.

    ГОСТ выделяет 18 таких угроз:

    • угрозы атаки на активное и/или пассивное виртуальное и/или физическое сетевое оборудование из физической и/или виртуальной сети;
    • угрозы атаки на виртуальные каналы передачи;
    • угрозы атаки на гипервизор из виртуальной машины и/или физической сети;
    • угрозы атаки на защищаемые виртуальные устройства из виртуальной и/или физической сети;
    • угрозы атаки на защищаемые виртуальные машины из виртуальной и/или физической сети;
    • угрозы атаки на защищаемые виртуальные машины из виртуальной и/или физической сети; (здесь в найденных опубликованных экземплярах ГОСТа идёт задублированный пункт, возможно, допустили ошибку при наборе текста)
    • угрозы атаки на систему хранения данных из виртуальной и/или физической сети;
    • угрозы выхода процесса за пределы виртуальной машины;
    • угрозы несанкционированного доступа к данным за пределами зарезервированного адресного пространства, в том числе выделенного под виртуальное аппаратное обеспечение;
    • угрозы нарушения изоляции пользовательских данных внутри виртуальной машины;
    • угрозы нарушения процедуры аутентификации субъектов виртуального информационного взаимодействия;
    • угрозы перехвата управления гипервизором;
    • угрозы перехвата управления средой виртуализации;
    • угрозы неконтролируемого роста числа виртуальных машин;
    • угрозы неконтролируемого роста числа зарезервированных вычислительных ресурсов;
    • угрозы нарушения технологии обработки информации путем несанкционированного внесения изменений в образы виртуальных машин;
    • угрозы несанкционированного доступа к хранимой в виртуальном пространстве защищаемой информации;
    • угрозы ошибок обновления гипервизора.

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

    Меры защиты


    В ГОСТ представлен только перечень мер защиты. Меры ЗИ разделены на несколько групп в зависимости от объекта защиты. Выделяются следующие группы:

    • защита средств создания и управления виртуальной инфраструктурой;
    • защита виртуальных вычислительных систем;
    • защита виртуальных систем хранения данных;
    • защита виртуальных каналов передачи данных;
    • защита отдельных виртуальных устройств обработки, хранения и передачи данных;
    • защита виртуальных средств защиты информации и средств защиты информации, предназначенных для использования в среде виртуализации.

    Сводные данные об угрозах и мерах защиты информации, обрабатываемой с помощью технологий виртуализации сведены в таблицу и приведены в приложении В данного ГОСТа.

    Помимо традиционных мер защиты, встречаются и новые, пока неясно чем реализуемые. Например, шифрование передаваемых файлов-образов виртуальных машин. На сегодняшний день нет средств шифрования, для передаваемых с облака и загружаемых на облако (например, при «переезде»), образов виртуальных машин. Вполне возможно, что данным функционалом обзаведутся существующие средства защиты седы виртуализации, такие как vGate или Dallas Lock.

    Так же стоит заметить, что ни в ГОСТ ни в приказах не рассмотрено понятие снимков виртуальных машин (snapshots), и как следствие, не рассмотрены угрозы относящиеся к снимкам. Например, в американском NIST снимок виртуальной машины рассматривается, как отдельный объект защиты.

    В заключение


    Системы защиты информации, создаваемые во исполнение законодательства, например, согласно 17-му Приказу, рассмотренному в предыдущей статье, требуют рассмотрения всего перечня возможных угроз. Опираясь на данный ГОСТ, мы можем не изобретать велосипед при использовании технологий виртуализации в своих решениях. Как прописано в 17-м Приказе, выбор мер защиты состоит из нескольких этапов:

    • определение базового набора мер защиты;
    • адаптация базового набора мер защиты;
    • уточнение адаптированного базового набора мер защиты;
    • дополнение уточненного адаптированного базового набора мер защиты.



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

    При использовании данного ГОСТа, необходимо иметь ввиду, что существует проект, пока не утвержденный, но уже вполне обсуждаемый, «Защита информации. Защита информации при использовании облачных технологий. Общие положения». В проекте сделан упор именно на защиту информации, при взаимодействии с облачными провайдерами. Поэтому необходимо понимать разницу между использованием технологий виртуализации и потреблением и/или предоставлением облачных услуг. Проект ГОСТа довольно интересный, и, наверное, мы рассмотрим его положения в следующих статьях.

    Протестировать нашу виртуальную инфраструктуру можно бесплатно, оставив заявку. Cloud4Y предоставляет облако, соответствующее требованиям по обеспечению безопасности информации согласно 17 и 21 Приказам ФСТЭК.
    Cloud4Y 169,97
    #1 Корпоративный облачный провайдер
    Поделиться публикацией
    Комментарии 19
    • +1

      И сразу вопрос знатокам: это всё с Docker как-то совместимо? Или в зоне действия данного закона про современные средства развёртывания можно забыть?

      • 0
        Про Docker в ГОСТ ни слова, как и про средства развертывания. ГОСТ не закон, нет требований к обязательному соответствию.
        • 0
          Маловероятно, что связано, по крайней мере если речь о линукс-контейнерах на линукс-хосте. Докер в контексте защиты информации сам по себе является интерфейсом к средствам ОС изоляции пользовательских процессов друг от друга.
          • 0

            Вот то-то и оно. В результате может получиться конфликт между требованиями ГОСТ и потребностями Docker. Но найти достаточно компетентного человека, который мог бы дать развёрнутый ответ, никак не удаётся.

        • 0
          Hyper-V разве не хостовая?
          • 0
            Есть роль, а есть Hyper-V Server. Но сути этом в целом не меняет.
            • 0
              Microsoft Hyper-V Server 2008 — бесплатная операционная система с единственной ролью — сервером виртуализации. Все равно хостовая система с ролью.
              • 0
                Именно это я и имел ввиду.
                • 0
                  ГОСТ Р 56938-2016 определяет 2 типа гипервизоров:

                  •Гипервизор 1 типа – устанавливается непосредственно на аппаратную платформу, к таким гипервизорам по ГОСТ относятся VMware vSphere, Hyper-V, Citrix XenServer и пр.
                  •Гипервизор 2 типа – устанавливается в хостовую операционную систему. К таким гипервизорам можно отнести VirtualBox, VMWare Workstation и пр.

                  Я понял в чём дело: «трудности перевода» ( хотя перевести run как инсталлируется(!)... )

                  Type-1, native or bare-metal hypervisors

                  These hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems.

                  Type-2 or hosted hypervisors

                  These hypervisors run on a conventional operating system (OS) just as other computer programs do.

                  Если хотя бы заменить одно слово install-руется на правильный термин:

                  •Гипервизор 1 типа – выполняется непосредственно на аппаратной платформе, к таким гипервизорам по ГОСТ относятся VMware vSphere, Hyper-V, Citrix XenServer и пр.
                  •Гипервизор 2 типа – выполняется поверх хостовой операционной системы. К таким гипервизорам можно отнести VirtualBox, VMWare Workstation и пр.

                  уже многое становится понятным
                  • 0
                    Решил посмотреть как в оригинале. Там видим:
                    3.13 гипервизор I типа: Гипервизор, устанавливаемый непосредственно на аппаратное обеспечение в качестве системного программного обеспечения.

                    3.14 гипервизор II типа: Гипервизор, устанавливаемый в среде хостовой операционной системы в качестве прикладного программного обеспечения.
              • +1
                Мне довелось подискутировать начальником одного из отделов ФСТЭК в Новосибирске.

                С его слов, деление на 1-й и 2-й уровень очень условно и нет четкой границы между ними. Эти уровни придуманы были чисто для удобства и не более
                • 0
                  Дискутировать о виртуализации с представителем шарашкиной госконторы, которая давит конкуренцию на рынке, выдавая сертификаты дерьмовым решениям, которые стоят не дешевле лидеров мирового рынка? Знаете толк. Всякие там vExpert`ы (Ник Маршалл, например) тоже подразделяют гипервизоры на типы, например, по признаку того, «творится» ли виртуализация посредством ядра/модуля ядра или софтом (ну, там отдельный application layer часто рассматривается), как обслуживается vm i/o стэк — через «parent partition» или каким другим способом и т.д. Есть мнение, что эти вот vExpert`ы и прочие VCDX`ы чуть лучше знают.
                  • +2
                    Сейчас вся виртуализация «ядерная». Оставим вне обсуждения всякие эмуляторы вроде Bochs и ему подобные. Остановимся только на гипервизорах, которые могут запускать на себе разные ОС (Windows, Linux, FreeBSD, OS/2 и т.д.)

                    Лично я не вижу принципиальной разницы между типами гипервизоров, хотя и админил entrprise (два кластера VMWare, СХД Celerra и VNX, блейд 7000 навскидку — что вспомнил) до июля 2017, пока не сменил место работы. Все деление, фактически, сводится к одному пункту: является ли роль гипервизора основной и единственной данного сервера и ОС, которая на нем установлена.

                    К примеру, гипервизор QEMU в связке с libvirt (плюс всякие стеки) и модулем KVM. Если это главная роль, то это первый тип. Если нет — второй.

                    BHyVe априори невозможно отнести к какому-либо типу, пока неизвестно окружение. Поставь я на систему всякие bind, nginx, db и т.д., я получу второй тип. А прикрути я к системе тот же libvirt плюс еще некоторые «обвязки» для работы гипервизора, плюс ZFS Raid и ZVOL, не ставя помимо этого еще какой софт, я получу первый тип. Различие будет только в том, что система будет полноценная, а не порезаная, как в том же ESXi

                    P.S. На 100% истинность не претендую. Тем не менее, поработав в enterprise, я для себя сделал такой вывод
                    • 0
                      Как я отметил выше, одной из важнейших черт является обслуживание vm i/o стека, ESXi тут вообще в отдельную категорию вываливается, но и Hyper-V с Xen`ами отличаются от виртуалбоксов.
                      P.S. Выделяя жирным это «админил entrprise» вы меня напугать хотите? Мидл-рэндж массивами и шассями c7000? Их есть у меня и были всякие.
                      • +1
                        Я лишь обозначил, что я смыслю в том, что говорю. Про I/O соглашусь.
                        То, что ESXi отдельная песня, это и ежу понятно. Но тем не менее его относят к первому типу. Я бы отнес его к отдельной категории внутри 1-го типа.

                        P.S. На правах юмора. Я не зеркало, чтобы пугать
                        • 0
                          То, что ESXi отдельная песня, это и ежу понятно. Но тем не менее его относят к первому типу. Я бы отнес его к отдельной категории внутри 1-го типа.
                          Да, есть и такое подразделение:
                          monolithic(VMSphere) and microkernalized(Hyper-V) Hypervisors
                          См. superuser.com Q 836116 — неплохая подборка информации и URLs
                        • 0
                          Выделяя жирным это «админил entrprise» вы меня напугать хотите?

                          во-во, я тоже хотел спросить: если уж два HA-кластера — это кровавый энтерпрайз, то у меня тогда что ))
                        • 0
                          ГОСТ Р 56938-2016 определяет 2 типа гипервизоров:

                          •Гипервизор 1 типа – устанавливается непосредственно на аппаратную платформу, к таким гипервизорам по ГОСТ относятся VMware vSphere, Hyper-V, Citrix XenServer и пр.
                          •Гипервизор 2 типа – устанавливается в хостовую операционную систему. К таким гипервизорам можно отнести VirtualBox, VMWare Workstation и пр.

                          Все деление, фактически, сводится к одному пункту: является ли роль гипервизора основной и единственной данного сервера

                          По мнению авторов деления — вовсе нет Ж-)

                          Лично я в 2008 задумался над похожей ситуацией:
                          Q: на этом хосте есть виртуальная машина с 8-ю виртуальными процессорами.
                          Виртуальная машина иногда заметно грузит свои виртуальные процессоры, но в taskmgr на хосте не вижу значительной нагрузки на процессоры

                          A: из-за особенностей архитектуры Hyper-V этот самый Task Manager покажет... всего-лишь навсего загрузку процессора хостовой ОС. Виртуальные машины при этом учитываться не будут – поскольку хостовая ОС, точно так же, как и все виртуальные машины – работает в своем изолированном разделе

                          Так я узнал, что «Virtual PC Server» ( оффициально у него др.название) — это был 2-ой тип, а вот Hyper-V — прогрессивный Ж-) 1-ый
                  • 0
                    --

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое