Защищенные виртуальные машины в Windows Server 2016

Автор статьи - Александр Шейдаков, Эксперт по прикладным решениям Microsoft Россия

Одной из множества новых функций Windows Server 2016, связанных с безопасностью, стала возможность создания защищенных виртуальных машин -  Shielded VMs. Данная технология позволяет создать надежный барьер между владельцем бизнес-приложения и администратором среды виртуализации. Эта технология – одна из тех, после появления которых ты не понимаешь, как вообще жил до этого.

Давайте посмотрим, почему стоит обратить на нее внимание, рассмотрев какие сценарии атак на виртуальные машины возможны в современном частном облаке или в облаке сервис-провайдера.

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

Я делаю снимок виртуальной машины с контроллером домена, а затем копирую ее в другое место – на общий файловый сервер или сразу на свой личный флеш-накопитель. И самое приятное, что никто этого не почувствует: сервисы внутри ВМ не останавливаются ни на секунду, а я получил копию контроллера домена. После этого я копирую файлы ВМ на свой личный ноутбук, монтирую VHDX, захожу в папку Windows\NTDS внутри виртуального диска и копирую находящийся там файл NTDS.dat (база данных Active Directory). После этого с помощью любой существующей утилиты для извлечения паролей из NTDS.dat я получаю пароли пользователей в домене в виде обычного текста. Для этого в зависимости от длины и сложности пароля могут потребоваться дни, недели или даже месяцы, но я ведь никуда не тороплюсь, лишь бы успеть до даты следующей смены пароля пользователя в домене (по умолчанию это 42 дня).

Предположим, что я узнал пароль администратора SQL Server, где работает HR-система. Я захожу на виртуальную машину с SQL Server и оставляю в секции реестра HKLM\Software\Microsoft\Windows\CurrentVersion\Run ссылку на запуск атакующего скрипта, который запустится в тот момент, когда DBA залогинится на сервер. Что этот скрипт сделает – решать мне.

Возможны и другие сценарии. Например, администратор сервис-провайдера с целью заработка получает доступ к серверу, где работает база данных CRM-системы крупного заказчика, и выгружает данные по всем клиентам в Excel, после чего продает эти данные конкурентам.

Таким образом, если у меня имеются права администратора виртуализованной среды, то я могу получить доступ к содержимому всех виртуальных машин на управляемых хостах. Я могу легко сбросить пароль локального администратора или root, абсолютно незаметно для владельца сервиса внутри этой ВМ, ведь у нас есть консольный доступ.

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

Рассмотрим также очень распространенный способ защиты от атак подобного рода – шифрование виртуальных дисков. Многие заказчики думают, что это хорошая мера защиты от подобных угроз. Но если использовать шифрование на уровне хоста, то тот же администратор виртуализованной среды при желании сможет отключить шифрование на время и расшифровать диск. Если использовать шифрование диска изнутри ВМ, то это может быть неудобно (чаще всего в подобных системах требуется вводить специальный код при запуске ВМ). Плюс это не защищает от того, что администратор гипервизора не скопирует ВМ на свой флеш-накопитель и не будет атаковать копию виртуальной машины по сети, запустив ее на своем личном компьютере. По очень быстрой виртуальной сети, за пределами корпоративных брандмауэров и систем мониторинга ИБ.

Данный способ атак актуален для всех современных гипервизоров – будь то Hyper-V 2012 R2 или система виртуализации последнего поколения от других лидеров рынка. Но в Windows Server 2016 данная проблема была решена на корню.

Windows Server 2016 и обновленный Hyper-V 2016 предоставляют возможности защиты ваших виртуальных машин от просмотра содержимого, кражи, вредоносного вмешательства (в том числе со стороны системного администратора) в процессе работы виртуальной машины или в остановленном состоянии. Данная технология получила название Shielded VM и с ее помощью вы можете защищать виртуальные машины, размещенные как в фабрике, которой вы не в полной мере доверяете (например, у сервис-провайдера), так и внутри вашего ЦОД (когда одни сотрудники управляют частным облаком, а другие отвечают за сервисы, работающие внутри ВМ).Давайте сравним использование защищенной виртуальной машины Shielded VM с обычной виртуальной машиной Hyper-V и физической машиной в ЦОД (красным показан потенциально опасный доступ):

В рамках технологии существует два типа защиты виртуальных машин – режим Shielded и режим Encryption Supported. В обоих режимах в виртуальной машине зашифровано не только содержимое, но и трафик Live Migration, причем миграция такой машины будет происходить только на доверенный хост, а VHDX будет зашифрован при помощи vTPM (virtual Trusted Platform Module) средствами BitLocker в гостевой ОС. Кроме того, в режиме Shielded реализована дополнительная защита в виде отключения некоторых виртуальных устройств внутри самой ВМ, что не позволит подключиться ни к консоли виртуальной машины, ни тем более получить содержимое ее дампа памяти. Режим Encryption Supported подходит для сценариев, когда владелец приложения доверяет администраторам среды виртуализации, а также для сценариев, когда требуется соответствие требованиям некоторых регуляторов. В остальных случаях мы рекомендуем использовать наиболее защищенный режим Shielded.

Аттестация хоста происходит с использованием новой службы, появившейся в Windows Server 2016, - Host Guardian Service. Эта служба находится отдельно от гипервизора, и подразумевается, что доступ к ней имеют только выделенные сотрудники организации, а у администратора Hyper-V к ней доступа нет (иначе теряется весь смысл). Host Guardian Service хранит ключ зашифрованной виртуальной машины, и, когда аттестованный хост обращается к службе, та проверяет, может ли данная виртуальная машина запускаться на данном конкретном хосте Hyper-V (то есть входит ли хост в нашу доверенную фабрику и не является ли личным ноутбуком злоумышленника), затем проверяет состояние хоста (например, установлены ли все необходимые обновления и нет ли предупреждений от системы антивирусной защиты), и если все в порядке, передает ключ для запуска ВМ.

Технология Shielded VMs не усложняет администрирование облака – защищенные виртуальные машины все так же можно «бэкапить», перемещать на другие хосты с помощью Live Migration или даже мигрировать на другие площадки с помощью Hyper-V Replica (при условии, что хосты входят в доверенную среду и управляются той же службой Host Guardian Service).

Компоненты System Center 2016 поддерживают управление компонентами механизма Shielded VMs, а Windows Azure Pack теперь умеет создавать защищенные виртуальные машины наряду с обычными.

 Давайте посмотрим, как технология Shielded VMs защищает от типовых атак со стороны администратора среды виртуализации в современном облаке:

Какие сценарии использования данного типа виртуальных машин могут быть?

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

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

     - Собственное частное облако: вы хотите отделить задачи администрирования рабочих нагрузок от задач по администрированию фабрики Hyper-V.

Дополнительно рассмотрим сценарий использования механизма Shielded VMs для защиты информационной системы в связке с технологией Always Encrypted, которая появилась в SQL Server 2016. Напомню, эта технология позволяет хранить конфиденциальные данные (номера кредитных карт, персональные данные и т. д.) в столбцах таблицы базы в зашифрованном виде. Расшифровка таких данных происходит на стороне клиентского приложения, которое обращается к доверенному хранилищу ключей, недоступному администратору базы данных. Таким образом Always Encrypted позволяет разделить пользователей базы на тех, кто владеет данными и имеет право их просматривать, и тех, кто выполняет задачи по администрированию и не должен иметь доступа к таким данным. При этом организация может спокойно хранить свои базы в облаке, использовать аутсорсеров в качестве администраторов базы данных или повысить требования безопасности внутри компании для собственных сотрудников.

Always Encrypted выполняет шифрование прозрачно для приложения: на уровне клиентского приложения устанавливается драйвер, который шифрует данные в базе с помощью ключей, хранящихся в клиентском приложении. Шифрование осуществляется при выполнении операций INSERT или UPDATE перед их передачей в БД. Аналогичным образом выполняется операция SELECT, при которой данные из соответствующих столбцов прозрачно дешифруются драйвером. При этом структура таблицы никак не меняется, что позволяет сохранить семантику приложения, использующего SQL Server.  Если приложение отправляет параметризованный запрос, драйвер получает информацию от Database Engine, какие параметры относятся к зашифрованным столбцам и соответственно должны быть зашифрованы или расшифрованы. Для параноиков может быть важно, что при этом можно реализовать и свой собственный поставщик хранилища ключей столбцов.

Сценарии использования технологии Always Encrypted могут быть такими же как при использовании Shielded VM: хостинг-провайдеры; обеспечение требований законодательства по защите данных, размещенных в облаке; разграничение доступа к конфиденциальным данным внутри ИТ-подразделения компании между администратором сервера баз данных и администратором приложения.

Технологии Shielded VMs и Always Encrypted отлично работают в связке. Например, я являюсь владельцем сервиса, который состоит из Front-end части (веб-приложение) и Back-end (база данных SQL Server). Моя база работает в большой ферме SQL Server 2016 Enterprise, которой управляют администраторы СУБД. Я хочу обезопасить данные своего приложения от кражи и использую технологию SQL Server 2016 Always Encrypted для шифрования данных в базе. Но при этом ключи для шифрования находятся внутри виртуальной машины, где работает Front-end, и их тоже нужно обезопасить от кражи. Для этого я перевожу виртуальную машину с Front-end в режим Shielded, и теперь доступ внутрь нее имею только я. Получилась защита приложения с обоих фронтов.

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

Если вы хотите узнать больше про то, как работает технология Shielded VMs в Windows Server 2016, мы рекомендуем вам прочитать официальную документацию и посмотреть презентацию с конференции Microsoft Ignite.

Соответственно, если вы хотите узнать больше про то, как работает технология Always Encrypted в SQL Server 2016, то вы можете прочитать официальную документацию по данной технологии.