Повышение безопасности с помощью Credential Guard (часть 2)

Если вы хотите прочитать первую часть этой серии статей, перейдите по ссылке:

• Повышение безопасности с помощью Credential Guard (часть 1)

В своей предыдущей статье я объяснил, как работает атака pass the hash, и упомянул, что новая функция Windows под названием Credential Guard предназначена для защиты от этого и других подобных типов атак. В этой статье я хочу объяснить, что такое Credential Guard и как он работает.

Прежде чем я начну, мне нужно объяснить, что, хотя Credential Guard может значительно улучшить безопасность организации, его нельзя использовать во всех ситуациях. Credential Guard работает путем перемещения секретов Kerberos, NTLM и Credential Manager из локального центра безопасности в новый репозиторий, называемый изолированным процессом LSA. Проблема в том, что на машине могут быть запущены процессы, которые ожидают, что секреты аутентификации будут храниться в локальном органе безопасности. Если эти процессы не смогут найти секреты аутентификации в ожидаемом месте, то приложения, зависящие от этих процессов, перестанут работать. Другими словами, не каждое приложение совместимо с Credential Guard, поэтому перед развертыванием Credential Guard в производственной среде важно протестировать приложение на совместимость.

К сожалению, я не могу точно сказать, какие именно приложения Credential Guard сломается, но могу сказать, что согласно TechNet (https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential- Guard), факторы, которые могут привести к сбою приложений в Credential Guard, включают:

• Поддержка шифрования Kerberos DES
• Неограниченное делегирование Kerberos
• Извлечение Kerberos TGT
• НТЛМ версии 1

В статье TechNet также отмечается, что Credential Guard не должен быть включен на контроллерах домена, поскольку Credential Guard изолирует тот самый процесс, от которого зависят службы проверки подлинности, тем самым вызывая сбой контроллера домена.

Итак, после сказанного давайте поговорим о том, как работает Credential Guard. Как упоминалось ранее, Credential Guard берет секреты, которые обычно хранятся в локальном органе безопасности, и вместо этого помещает их в изолированный процесс LSA. Для всех, кто может быть не знаком с локальным органом безопасности, он, среди прочего, является хранилищем, в котором обычно хранятся учетные данные пользователя и системы.

При изоляции локального органа безопасности Windows использует то, что называется виртуальным безопасным режимом. Виртуальный безопасный режим является новым для Windows 10 и Windows Server 2016 и используется Credential Guard и несколько похожей функцией безопасности под названием Device Guard.

Ключом к пониманию виртуального безопасного режима является понимание (с высокого уровня) виртуализации серверов. Гипервизоры, такие как Hyper-V от Microsoft или ESXi от VMware, используют расширения виртуализации, встроенные в ЦП. Эта аппаратная виртуализация делает несколько разных вещей. Во-первых, он позволяет узлу виртуализации размещать виртуальные машины без использования аппаратной эмуляции. Хотя ранние решения виртуализации действительно использовали аппаратную эмуляцию, уровень эмуляции негативно влиял на производительность виртуальных машин, а иногда также вызывал проблемы со стабильностью.

Еще одна вещь, которую делает аппаратная виртуализация, — это изоляция виртуальных машин. Виртуальная машина не может видеть параллельную виртуальную машину или родительскую операционную систему, потому что аппаратное обеспечение (с помощью гипервизора) изолирует виртуальные машины друг от друга.

Важно понимать, что аппаратное обеспечение играет важную роль в процессе виртуализации и что современные гипервизоры не могут функционировать, если возможности виртуализации не существуют и не включены на аппаратном уровне. На самом деле, Microsoft даже предоставляет средство обнаружения аппаратной виртуализации (https://www.microsoft.com/en-us/download/details.aspx?id=592).

Виртуальный безопасный режим во многом похож на такие гипервизоры, как Hyper-V или ESXi. Одно из ключевых сходств заключается в том, что «настоящий» гипервизор работает независимо от операционной системы сервера. Да, Hyper-V можно установить как роль Windows Server, но Microsoft также предлагает версию Hyper-V server, которая устанавливается на «голое железо». VMware ESXi работает аналогичным образом, поскольку он также устанавливается на уровне «голого железа». Таким образом, гипервизор находится между оборудованием и виртуальными машинами.

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

Преимущество этого подхода заключается в том, что, поскольку Virtual Secure Mode существует как «виртуальная машина», его содержимое полностью изолировано от операционной системы сервера.

Как обсуждалось ранее, Credential Guard работает, перемещая содержимое локального администратора безопасности в изолированный процесс LSA (который иногда называют LSAIso). Это поднимает два вопроса. Во-первых, если локальный орган безопасности теперь пуст, что произойдет, если процесс выполнит вызов LSA? Во-вторых, как Windows получает доступ к изолированному процессу LSA, если он действительно изолирован?

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

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

Хотя Credential Guard зависит от использования виртуального безопасного режима, важно отметить, что виртуальный безопасный режим не принадлежит исключительно Credential Guard. Device Guard также использует виртуальный безопасный режим, и Device Guard и Credential Guard могут совместно использовать пространство виртуального безопасного режима.

Теперь, когда я объяснил основы работы Credential Guard, пришло время взглянуть на процесс реализации. В части 3 этой серии я покажу вам, как настроить виртуальный безопасный режим и Credential Guard.