Захист віртуальних машин, розміщених в дата центрі


У століття хмарних технологій, коли у кожного користувача є власна облік для зберігання фотографій, а компанії орендують сервера для хмарних обчислень, постає питання про конфіденційність інформації, що зберігається. І якщо користувачі для захисту збережених даних можуть обійтися довірою до хмари або використанням крипто контейнерів, то у компаній справи йдуть гірше. Так як в хмари переноситься не тільки сховище даних, але і самі обчислення.
Особливо страждає захист віртуальних машин, так як у випадку компрометації хоста, не складе труднощів отримати доступ до ВМ. До недавнього часу жоден з гіпервізора будь то VMware, Xen, Hyper-V не надавали будь-яких значущих технологій по захисту ВМ.

А якщо зловмисник отримає фізичний доступ до сервера, то врятувати може тільки шифрування дисків, і то не у всіх випадках. Звичайно орендуючи сервер, частина захисних заходів бере на себе дата центр. Але в такому випадку необхідно довіряти адміністраторам дата центру.

З релізом Windows Server 2016, в Microsoft вирішили приділити більше уваги безпеці хоста і віртуальної інфраструктури. З'явилася можливість ізолювати ВМ від адміністратора хоста Hyper-V. А використовуючи віртуальний TPM стало можливим шифрування даних ВМ з допомогою bitlocker.

Таким чином використовуючи нові технології можна розміщувати віртуальні машини на непідконтрольних серверах або в корпоративних дата центрах, але з підвищеним рівнем безпеки, розмежовуючи ролі фізичного і віртуального доступу.

Використовувані технології

Shielded VM – ізолююча технологія віртуальну машину від хоста. Захищає ВМ від випадкових або навмисних дій адміністратора хоста і від шкідливого програмного забезпечення.
Для роботи Shielded VM необхідно наявність сервера Host Guardian Service(HGS), який видає ключі доступу до ВМ і перевіряє здоров'я хоста Hyper-V.

HGS підтримує два види атестації:

  1. TPM-trusted атестація – перевірка проходить на основі ідентифікатора TPM, послідовності завантаження ОС і політики цілісності коду. Таким чином можна бути впевненим, що на хості працює тільки схвалений код.
  2. Admin-trusted атестація – перевірка відбувається на основі приналежності до групи безпеки Active Directory.
Схема роботи HGS

При запуску віртуальної машини захищений хост проходить атестацію у HGS сервера, який приймає рішення щодо передачі ключів доступу до віртуальної машини.

Admin-trusted атестацію доцільно використовувати всередині підприємства, коли потрібно ізолювати доступ до ВМ від адміністраторів.

TPM-trusted атестацію краще використовувати при розміщенні ВМ на орендованому сервері, щоб забезпечити ізоляцію даних і ВМ від працівників Дата Центру.

Зв'язок сервера HGS і захищеного вузла здійснюється за http (https) протоколу. HTTPS не потрібно, для забезпечення безпечного зв'язку, але, якщо ви захочете включити HTTPS, вам буде потрібно додатковий сертифікат. У разі AD атестації необхідно додатково налаштувати односторонній доменний траст.

Secure Virtual Mode (VSM) – технологія працює на основі віртуалізації, яка дозволяє ізолювати критичні для безпеки операції в міні ОС.

На VSM працюють дві інші технології:

  1. Device Guard – перевірка даних UEFI прошивки і драйверів режиму ядра (контроль цілісності коду).
  2. Credential Guard – ізоляція процесу аутентифікації користувачів (LSA).
Принцип роботи VSM


Основна ОС запускається в віртуальному оточенні. А гіпервізор виступає в ролі хостовой ОС, тим самим обмежуючи доступ до оперативної пам'яті. У підсумку шкідливе ПО запущене на хості навіть з адміністраторськими правами не зможе отримати доступ до пам'яті VSM. Також така структура повинна захищати від атаки на DMA порти.

Про організацію Shielded VM

Замовляючи Shielded VM мається на увазі, що хост Hyper-V і сервер HGS знаходяться на стороні дата центру (так організовано в Microsoft Azure). У такому разі створювати екрановану віртуальну машину можна самостійно або використовуючи наданий шаблон.

Створюючи Shielded VM самостійно замовник у себе на ПК розгортає і налаштовує ВМ, а потім шифрує ключем виданими Дата Центром. Після переносить ВМ Дата Центр.

У другому випадку, замовник створює тільки PDK файл, що захищає ВМ створену з шаблону. PDK файл пов'язує файл шаблону з HGS сервером. Але необхідно переконатися, що в шаблоні немає шкідливого ПО.

Перший спосіб виглядає більш безпечним, так як файл даних ВМ потрапляє на хост вже в шифрованому вигляді. У будь-якому випадку ключі доступу до ВМ не потрапляють до адміністраторам Дата Центру у відкритому вигляді.

Єдиним місцем піддаються атакам залишився HGS сервер. Так як:

  • Адміністратор HGS може знизити вимоги до політики безпеки.
  • Зловмисник отримав адміністраторські права може спробувати отримати ключі доступу.
  • Для роботи HGS потрібно AD і немає вимоги до обов'язкової наявності TPM, отже, ключі найвірогідніше будуть зберігатися у відкритому вигляді.
Виходячи з цього з'явилася ідея перевірити можливість роботи Shielded VM в умовах, коли сервер HGS розміщується у своїй інфраструктурі. Це ще більше убезпечить віртуальні машини. Також такий спосіб можна використовувати якщо Дата Центр не надає послугу Shielded VM. Мінус цього підходу в тому, що доведеться самостійно адмініструвати цю структуру.

Може виникнути питання про підміну сервера HGS адміністратором гіпервізора — адже для цього необхідно просто вказати адресу. Захист від цього реалізовано досить просто, створена ВМ зашифровано за допомогою відкритого ключа HGS сервера, тому інший HGS сервер не зможе видати ключі для її запуску.

Також варто розуміти, що технологія Shielded VM шифрує тільки файли конфігурації віртуальної машини. VHDX файл залишається незашифрованим. Для його шифрування потрібно включити vTPM, та зашифрувати диск битлокером.

Поєднання нових технологій надає надійний захист:

  • людський фактор усунутий;
  • ключі передаються в зашифрованому вигляді;
  • сервери захищені новими технологіями, що передбачають перевірку цілісності коду;
  • білий список дозволених програм;
  • ізоляція ВМ від хоста.
Це все дуже добре захищає від шкідливого ПО націленого на хост Hyper-V і надає доступ до ВМ тільки власнику, захищаючи від дій адміністраторів або кого-небудь отримав адміністраторські права.

Вимоги до серверів Hyper-V і HGS
Вимоги вказані для використання TPM атестації. AD атестація менш вимоглива, але при цьому забезпечує набагато меншу захист.

HGS:
  • Windows Server 2016
Hyper-V:
  • Windows Server 2016 Datacenter Edition
  • UEFI Secure Boot
  • TPM v2
  • IOMMU (VT-d)

налаштувати

Для прикладу буде розглянутий варіант: ви орендували виділений сервер і хочете його забезпечити. Буде використана TPM атестація. З'єднання між хостом і HGS буде проходити по http протоколу. Якщо HGS сервер не має білого IP необхідно буде прокинути 80 порт або використовувати реверс проксі.

Додавання та налаштування HGS ролі на сервері

Установка HGS сервера і створення домену
Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

HGS для роботи необхідний домен. Його можна підключити до вже існуючого домену, але рекомендується створення окремого домену для підвищення безпеки. Перед виконанням наступної команди необхідно переконатися, що комп'ютер не підключено до домену.

$adminPassword = ConvertTo-SecureString -AsPlainText '<password>' -Force

Install-HgsServer -HgsDomainName 'relecloud.com' -SafeModeAdministratorPassword $adminPassword -Restart



Створення самоподписаных сертифікатів
Для тесту були створені самоподписанные сертифікати, але для реального середовища краще використовувати PKI.

$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force

$signingCert = New-SelfSignedCertificate -DnsName "signing.relecloud.com"

Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:\signingCert.pfx'

$encryptionCert = New-SelfSignedCertificate -DnsName "encryption.relecloud.com"

Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:\encryptionCert.pfx'



Ініціалізація HGS сервера
Вказуємо сертифікати шифрування і підпису. Вибираємо метод атестації.

$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force

Initialize-HgsServer -HgsServiceName '<HgsServiceName>' -SigningCertificatePath 'C:\signingCert.pfx' -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath 'C:\encryptionCert.pfx' -EncryptionCertificatePassword $certificatePassword [-TrustActiveDirectory | -TrustTPM]




Додавання охороняється хоста Hyper-V

Отримуємо ідентифікатор TPM
Дану процедуру необхідно виконати для кожного захищеного вузла.

(Get-PlatformIdentifier -Name '<HostName>').InnerXml | Out-file <Path><HostName>.xml -Encoding UTF8


Додаємо отриманий файл на сервер HGS

Add-HgsAttestationTpmHost -Path <Path><Filename>.xml -Name <HostName> -Force



Створюємо та використовуємо Integrity Code Policy
При створенні політики відбувається сканування всіх встановлених програм і додавання їх в білий список. Перед створенням політики необхідно переконатися, що в системі:

  • Відсутні віруси та шкідливе ПЗ
  • Встановлено необхідне для роботи ЗА і воно є благонадійним
Рекомендується спочатку перевірити роботу політики у режимі аудиту. У такому разі виконуваний файл, заборонений політикою буде відображено в протоколі.

Сканування займе деякий час.

New-CIPolicy -Level FilePublisher -Fallback Hash -FilePath 'C:\temp\HW1CodeIntegrity.xml' -UserPEs

ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'



Файл .p7b необхідно перейменувати SIPolicy.p7b і скопіювати в папку C:\Windows\System32\CodeIntegrity\SIPolicy.p7b

Перезавантажуємо комп'ютер і перевіряємо роботу системи під планованої типовою навантаженням. Після успішної перевірки роботи системи відключаємо режим аудиту

Set-RuleOption -FilePath 'C:\temp\HW1CodeIntegrity.xml' -Option 3 -Delete

ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'

Copy-Item -Path '<Path to HW1CodeIntegrity\_enforced.p7b>' -Destination 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'

Restart-Computer

Якщо захищатися буде кілька ідентичних хостів, політику можна створити тільки один раз.

Рекомендується залишити вихідний XML файл, щоб у разі необхідності зміни політики не проводити повторне сканування.

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

Реєструємо політику на HGS сервері
Add-HgsAttestationCIPolicy -Path <Path> -Name '<PolicyName>'



Створення TPM baseline політики
Ця політика ґрунтується на PCR регістрах (Platform Configuration Registers), що знаходяться в модулі TPM. В них зберігаються цілісності показників системи, починаючи з завантаження BIOS до завершення роботи системи. Якщо порядок завантаження буде змінено, наприклад, руткітам, це відображатися в регістрах PCR.

Політика створюється для класу однакових апаратних хостів. Перед її створенням необхідно мати встановлений Hyper-V.

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'

Для цієї команди необхідно включити Secure Boot, IOMMU (VT-d), Virtualization Based Security.

Можна використовувати прапор -SkipValidation який дозволити здійснитися команді, але він не виправить помилки.



Додаємо TCGlog файл на HGS сервері
Add-HgsAttestationTpmPolicy -Path <Filename>.tcglog -Name '<PolicyName>'



Перевіряємо статус HGS сервера

На цьому моменті налаштування HGS сервера закінчується. Для перевірки виконаної роботи проведемо діагностику.

Get-HgsTrace -RunDiagnostics




Підключаємо хост Hyper-V до HGS сервера

Для підключення захищається хоста до сервера HGS достатньо вказати URL-адресу сервера.

Set-HgsClientConfiguration -AttestationServerUrl 'http://<FQDN>/Attestation' -KeyProtectionServerUrl 'http://<FQDN>/KeyProtection'



При правильному налаштуванні повинно бути:

  • IsHostGuarded: true
  • AttestationStatus: passed
Якщо що-то налаштований не вірно в AttestationStatus буде вказана причина.

Створення екранованої віртуальної машини

Отримуємо файл опису HGS сервера, який знадобитися для прив'язки ВМ до сервера.

Invoke-WebRequest http://<"HGSServer">FQDN>/KeyProtection/service/metadata/2014-07/metadata.xml -OutFile C:\HGSGuardian.xml


Створювати ВМ потрібно на окремій машині під управлінням Windows Server 2016, не налаштованої на використання HGS.

Створюємо нову ВМ другого покоління, встановлюємо на неї ОС, налаштовуємо RDP і перевіряємо його працездатність, шифруємо битлокером.



Екранування ВМ
Задаємо назву ВМ

$VMName = 'SVM'

Вимикаємо ВМ

Stop-VM –VMName $VMName

Створюємо сертифікат власника

$Owner = New-HgsGuardian –Name 'Owner' –GenerateCertificates

Імпортуємо сертифікат сервера

$Guardian = Import-HgsGuardian -Path 'C:\HGSGuardian.xml' -Name 'TestFabric' –AllowUntrustedRoot

Створюємо Key Protector

$KP = New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot

Включаємо екранування
Set-VMKeyProtector –VMName $VMName –KeyProtector $KP.RawData

Set-VMSecurityPolicy -VMName $VMName -Shielded $true

Включаємо vTPM віртуальної машини

Enable-VMTPM -VMName $VMName


Після настройки і включення захисту у ВМ її необхідно перемістити на охоронюваний хост. Для цього експортуємо машину, переносимо отримані файли на хост, і імпортуємо її в консоль Hyper-V.

На цьому етапі налаштування завершено, ВМ екранована.

Перевіряємо роботу Shielded VM
При спробі підключитися до ВМ через консоль Hyper-V побачимо повідомлення:


Так само у налаштуваннях ВМ побачимо попередження про неможливість змінювати налаштування захисту:


Розділ віртуальної машини захищений BitLocker-ом:


Таким чином була зроблена настройка Shielded VM, яка забезпечує більш високий рівень захисту віртуальних машин. Якщо у вас залишилися питання, ласкаво просимо в коментарі.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.