System Guard: как аппаратный корень доверия помогает защитить Windows
Чтобы защитить критически важные ресурсы, такие как стек проверки подлинности Windows, маркеры единого входа, биометрический стек Windows Hello и виртуальный доверенный платформенный модуль, встроенное ПО и оборудование системы должны быть надежными.
System Guard реорганизует существующие функции целостности системы Windows под одной крышей и настраивает следующий набор инвестиций в безопасность Windows. Он предназначен для обеспечения следующих гарантий безопасности:
- Защита и поддержание целостности системы при запуске
- Убедитесь, что целостность системы действительно поддерживается с помощью локальной и удаленной аттестации
Поддержание целостности системы при запуске
Статический корень доверия для измерения (SRTM)
В Windows 7 одним из средств, которые злоумышленники будут использовать для сохранения и уклонения от обнаружения, было установить в системе то, что часто называют bootkit или rootkit. Эта вредоносная программа запускается до запуска Windows или во время самого процесса загрузки, что позволяет ему запускаться с наивысшим уровнем привилегий.
В Windows 10, работающей на современном оборудовании, аппаратный корень доверия помогает гарантировать, что несанкционированное встроенное ПО или программное обеспечение (например, загрузчик) не может запуститься перед загрузчиком Windows. Этот аппаратный корень доверия поступает из функции безопасной загрузки устройства, которая является частью единого расширяемого интерфейса встроенного ПО (UEFI). Этот метод измерения статических компонентов UEFI при ранней загрузке называется статическим корнем доверия для измерения (SRTM).
Поскольку существуют тысячи поставщиков КОМПЬЮТЕРов, которые производят множество моделей с различными версиями UEFI BIOS, при загрузке становится невероятно большое количество измерений SRTM. Для установления доверия здесь существуют два метода: ведение списка известных "плохих" измерений SRTM (также известного как список блокировок) или список известных "хороших" измерений SRTM (также известный как список разрешений).
У каждого варианта есть недостаток:
- Список известных "плохих" измерений SRTM позволяет хакеру изменить только 1 бит в компоненте, чтобы создать совершенно новый хэш SRTM, который должен быть указан в списке. Это означает, что поток SRTM по своей сути является хрупким — незначительное изменение может привести к аннулированию всей цепочки доверия.
- Список известных "хороших" измерений SRTM требует тщательного добавления каждого нового комбинированного измерения BIOS/PC, что происходит медленно. Кроме того, исправление ошибок для кода UEFI может занять много времени для разработки, сборки, повторного тестирования, проверки и повторного развертывания.
Безопасный запуск — динамический корень доверия для измерения (DRTM)
System Guard Secure Launch, впервые появившиеся в Windows 10 версии 1809, призваны устранить эти проблемы с помощью технологии, известной как динамический корень доверия для измерения (DRTM). DRTM позволяет системе свободно загружаться в ненадежный код, но вскоре после запуска системы в доверенное состояние, принимая под контроль все ЦП и заставляя их сбой хорошо известного и измеряемого пути кода. Это позволяет ненадежный ранний код UEFI загружать систему, но затем безопасно переходить в доверенное и измеряемое состояние.
Безопасный запуск упрощает управление измерениями SRTM, так как код запуска теперь не связан с определенной конфигурацией оборудования. Это означает, что количество допустимых измерений кода невелико, и будущие обновления могут развертываться более широко и быстро.
Защита в режиме управления системой (СММ)
Режим управления системой (СММ) — это специальный режим ЦП в микроконтроллерах x86, который обрабатывает управление питанием, конфигурацию оборудования, тепловой мониторинг и все остальное, что производитель считает полезным. При каждом запросе одной из этих системных операций во время выполнения вызывается немаскируемое прерывание (SMI), которое выполняет код SMM, установленный BIOS. Код СММ выполняется на самом высоком уровне привилегий и невидим для ОС, что делает его привлекательным объектом для вредоносных действий. Даже если system Guard Secure Launch используется для позднего запуска, код СММ может потенциально получить доступ к памяти гипервизора и изменить гипервизор.
Для защиты от этого используются два метода:
- Защита от разбиения на разбиение для предотвращения неуместного доступа к коду и данным
- Контроль и аттестация оборудования СММ
Защита от разбиения по страницам может быть реализована для блокировки определенных таблиц кода, которые должны быть доступны только для чтения, чтобы предотвратить незаконное изменение. Это предотвращает доступ к памяти, которая не была назначена.
Функция аппаратного процессора, известная как обработчик SMI руководителя, может отслеживать СММ и убедиться, что она не обращается к какой-либо части адресного пространства, в которую он не должен.
Защита СММ основана на технологии Secure Launch и требует, чтобы она функционировала. В будущем Windows 10 также будет измерять поведение обработчика SMI и удостоверять, что память, принадлежающая ОС, не была изменена.
Проверка целостности платформы после запуска Windows (время выполнения)
Хотя System Guard обеспечивает расширенную защиту, которая поможет защитить и сохранить целостность платформы во время загрузки и во время выполнения, реальность такова, что мы должны применить менталитет "предполагать нарушение" даже к нашим самым сложным технологиям безопасности. Мы можем верить, что технологии успешно выполняют свою работу, но нам также нужна способность убедиться, что они были успешными в достижении своих целей. Для обеспечения целостности платформы мы не можем просто доверять платформе, которая потенциально может быть скомпрометирована, чтобы подтвердить состояние ее безопасности. Таким образом, System Guard включает ряд технологий, которые обеспечивают удаленный анализ целостности устройства.
По мере загрузки Windows System Guard выполняет ряд измерений целостности с помощью доверенного платформенного модуля 2.0 устройства (TPM 2.0). System Guard Secure Launch не поддерживает более ранние версии доверенного платформенного модуля, например TPM 1.2. Этот процесс и данные изолированы аппаратно от Windows, чтобы гарантировать, что данные измерений не подвержены типу незаконного изменения, которое может произойти в случае компрометации платформы. Здесь измерения можно использовать для определения целостности встроенного ПО устройства, состояния конфигурации оборудования и компонентов, связанных с загрузкой Windows.
После загрузки системы System Guard подписывает и запечатывает эти измерения с помощью доверенного платформенного модуля. По запросу система управления, например Intune или Microsoft Configuration Manager, может получить их для удаленного анализа. Если System Guard указывает на отсутствие целостности устройства, система управления может выполнить ряд действий, например запретить устройству доступ к ресурсам.
Требования к выпуску и лицензированию Windows
В следующей таблице перечислены выпуски Windows, поддерживающие System Guard:
Windows Pro | Windows Корпоративная | Windows Pro для образовательных учреждений/SE | Windows для образовательных учреждений |
---|---|---|---|
Да | Да | Да | Да |
Права на лицензии System Guard предоставляются следующими лицензиями:
Windows Pro/Pro для образовательных учреждений/SE | Windows Корпоративная E3 | Windows Корпоративная E5 | Windows для образовательных учреждений A3 | Windows для образовательных учреждений A5 |
---|---|---|---|---|
Да | Да | Да | Да | Да |
Дополнительные сведения о лицензировании Windows см. в статье Обзор лицензирования Windows.
Требования к системе для System Guard
Эта функция доступна для следующих процессоров:
- Процессоры Intel® vPro™, начиная с Intel® Coffeelake, Whiskeylake или более поздней версии
- Процессоры AMD®, начиная с кремния Zen2 или более поздней версии
- Процессоры Qualcomm с набором® микросхем SD850 или более поздней версии
Требования к процессорам Intel® vPro™, начиная с Intel® Coffeelake, Whiskeylake или более поздней версии
Имя | Описание |
---|---|
64-разрядный ЦП | 64-разрядный компьютер с не менее чем четырьмя ядрами (логическими процессорами) требуется для гипервизора и безопасности на основе виртуализации (VBS). Дополнительные сведения о Hyper-V см. в статьях Hyper-V в Windows Server 2016 или Общие сведения о Hyper-V в Windows 10. Дополнительные сведения о низкоуровневой оболочке см. в разделе Спецификации гипервизора. |
Доверенный платформенный модуль (TPM) 2.0 | Платформы должны поддерживать дискретный TPM 2.0. Интегрированные и встроенные TPM не поддерживаются, за исключением микросхем Intel, поддерживающих технологию Platform Trust Technology (PTT), которая является типом интегрированного аппаратного доверенного платформенного модуля, соответствующего спецификации TPM 2.0. |
Защита Windows DMA | Платформы должны соответствовать спецификации защиты DMA Windows (все внешние порты DMA должны быть отключены по умолчанию до тех пор, пока ОС явно не заключит их). |
Буферы связи СММ | Все буферы связи SMM должны быть реализованы в типах памяти EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS или EfiReservedMemoryType. |
Таблицы страниц СММ | Не должен содержать никаких сопоставлений с EfiConventionalMemory (например, отсутствие памяти, принадлежащей ОС или VMM). Не должен содержать сопоставлений с разделами кода в EfiRuntimeServicesCode. НЕ должны иметь разрешения на выполнение и запись для одной и той же страницы Должен разрешать только то, что страницы TSEG могут быть помечены исполняемыми, а карта памяти должна сообщать О TSEG EfiReservedMemoryType. Обработчик SMI BIOS должен быть реализован таким образом, чтобы таблицы страниц SMM блокировались в каждой записи SMM. |
Современный и подключенный резервный режим | Платформы должны поддерживать современный и подключенный резервный режим. |
Индекс AUX доверенного платформенного модуля | Платформа должна настроить индекс AUX с индексом, атрибутами и политикой, которые точно соответствуют индексу AUX, указанному в группе DG TXT с размером данных, равным ровно 104 байтам (для данных AUX SHA256). (NameAlg = SHA256) Платформы должны настроить индекс PS (поставщик платформы) с помощью:
|
Политика AUX | Требуемая политика AUX должна быть следующей:
|
Индекс NV доверенного платформенного модуля | Встроенное ПО платформы должно настроить индекс NV доверенного платформенного модуля для использования операционной системой с:
|
Встроенное ПО платформы | Встроенное ПО платформы должно содержать весь код, необходимый для безопасного запуска технологии intel® Trusted Execution Technology:
|
Обновление встроенного ПО платформы | Рекомендуется обновить встроенное ПО системы с помощью UpdateCapsule в Центре обновления Windows. |
Требования к процессорам AMD®, начиная с Zen2 или более поздней версии
Имя | Описание |
---|---|
64-разрядный ЦП | 64-разрядный компьютер с не менее чем четырьмя ядрами (логическими процессорами) требуется для гипервизора и безопасности на основе виртуализации (VBS). Дополнительные сведения о Hyper-V см. в статьях Hyper-V в Windows Server 2016 или Общие сведения о Hyper-V в Windows 10. Дополнительные сведения о низкоуровневой оболочке см. в разделе Спецификации гипервизора. |
Доверенный платформенный модуль (TPM) 2.0 | Платформы должны поддерживать дискретный TPM 2.0 или TPM Microsoft Pluton. |
Защита Windows DMA | Платформы должны соответствовать спецификации защиты DMA Windows (все внешние порты DMA должны быть отключены по умолчанию до тех пор, пока ОС явно не заключит их). |
Буферы связи СММ | Все буферы связи SMM должны быть реализованы в типах памяти EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS или EfiReservedMemoryType. |
Таблицы страниц СММ | Не должен содержать никаких сопоставлений с EfiConventionalMemory (например, отсутствие памяти, принадлежащей ОС или VMM). Не должен содержать сопоставлений с разделами кода в EfiRuntimeServicesCode. НЕ должны иметь разрешения на выполнение и запись для одной и той же страницы Обработчик SMI BIOS должен быть реализован таким образом, чтобы таблицы страниц SMM блокировались в каждой записи SMM. |
Современный и подключенный резервный режим | Платформы должны поддерживать современный и подключенный резервный режим. |
Индекс NV доверенного платформенного модуля | Встроенное ПО платформы должно настроить индекс NV доверенного платформенного модуля для использования операционной системой с:
|
Встроенное ПО платформы | Встроенное ПО платформы должно содержать весь код, необходимый для выполнения безопасного запуска:
На платформе должна быть включена защита от отката встроенного ПО безопасного процессора AMD® На платформе должна быть включена функция AMD® Memory Guard. |
Обновление встроенного ПО платформы | Рекомендуется обновить встроенное ПО системы с помощью UpdateCapsule в Центре обновления Windows. |
Требования к процессорам Qualcomm с наборами® микросхем SD850 или более поздней версии
Имя | Описание |
---|---|
Мониторинг обмена данными в режиме | Все буферы связи в режиме монитора должны быть реализованы в EfiRuntimeServicesData (рекомендуется), разделах данных EfiRuntimeServicesCode, как описано в таблице атрибутов памяти, EfiACPIMemoryNVS или EfiReservedMemoryType. |
Таблицы страниц режима мониторинга | Все таблицы страниц в режиме монитора должны:
|
Современный и подключенный резервный режим | Платформы должны поддерживать современный и подключенный резервный режим. |
Встроенное ПО платформы | Встроенное ПО платформы должно содержать весь код, необходимый для запуска. |
Обновление встроенного ПО платформы | Рекомендуется обновить встроенное ПО системы с помощью UpdateCapsule в Центре обновления Windows. |