Регламент защиты среды виртуализации

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

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

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

• какие виртуальные машины входят в контур ИСПДн;
• какие сетевые правила разрешают взаимодействие между ними и внешними системами;
• кто согласовывает изменение этих правил;
• как проверяется, что фактическая настройка изоляции соответствует утверждённой схеме.

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

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

Если компания администрирует гипервизор самостоятельно, регламент должен ограничивать круг лиц с доступом к консоли управления виртуализацией минимальным числом сотрудников, требовать отдельную, более строгую аутентификацию для этого доступа и вести отдельный журнал действий на уровне гипервизора. Если инфраструктура арендуется у облачного провайдера, управление гипервизором обычно остаётся на его стороне, и регламенту достаточно зафиксировать, какие гарантии изоляции даёт провайдер по договору и как это подтверждается.

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

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

Забытый старый снапшот на общем хранилище — типичная находка при анализе защищённости.

Отдельно стоит прописать, что происходит со снапшотом после его использования: если он создавался ради разовой задачи — тестирования обновления, диагностики сбоя, — регламент должен требовать удаления копии сразу после того, как задача выполнена, а не оставлять решение на усмотрение исполнителя.

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

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

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