Управление работоспособностью устройств Windows

• Применяется к:

  ✅ Windows 11, ✅ Windows 10

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

Введение

В сценариях с использованием собственного устройства (BYOD) сотрудники предоставляют коммерчески доступные устройства для доступа как к рабочим ресурсам, так и к личным данным. Пользователи хотят использовать устройство по своему выбору для доступа к приложениям, данным и ресурсам организации не только из внутренней сети, но и из любого места. Это явление также известно как потребителизация ИТ.

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

С увеличением использования BYOD все больше неуправляемых и потенциально неработоспособных систем, обращаются к корпоративным службам, внутренним ресурсам и облачным приложениям.

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

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

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

Описание надежного комплексного решения для обеспечения безопасности

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

В последние годы стала распространенной одна конкретная категория угроз: расширенные постоянные угрозы (APT). Термин APT обычно используется для описания любой атаки, которая, по-видимому, нацелена на отдельные организации на постоянной основе. На самом деле, этот тип атаки обычно включает в себя определенных злоумышленников, которые могут использовать любые необходимые методы или методы.

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

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

Другой подход

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

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

Устройства, используемые для доступа к корпоративным ресурсам, должны быть доверенными. Эффективный комплексный подход к безопасности позволяет оценить работоспособности устройств и использовать текущее состояние безопасности при предоставлении доступа к ресурсу с высокой стоимостью.

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

На следующем рисунке показано решение, созданное для оценки работоспособности устройств из облака. Устройство проверяет подлинность пользователя через подключение к поставщику удостоверений в облаке. Если управляемый ресурс содержит строго конфиденциальные сведения, подсистема условного доступа поставщика удостоверений может проверить соответствие безопасности мобильного устройства перед предоставлением доступа. Устройство пользователя может подтвердить состояние работоспособности, которое может быть отправлено в любое время или когда управление мобильными устройствами (MDM) запрашивает его.

Устройства Windows можно защитить от низкоуровневых руткитов и буткитов с помощью низкоуровневых аппаратных технологий, таких как безопасная загрузка унифицированного интерфейса расширяемого встроенного ПО (UEFI).

Безопасная загрузка — это процесс проверки встроенного ПО, который помогает предотвратить атаки rootkit. это часть спецификации UEFI. Цель UEFI заключается в определении стандартного способа взаимодействия операционной системы с современным оборудованием, которое может выполнять более быстрые и эффективные функции ввода-вывода (I/O) по сравнению с более старыми системами BIOS, управляемыми прерываниями программного обеспечения.

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

Служба удаленной аттестации работоспособности выполняет ряд проверок измерений. Он проверяет точки данных, связанные с безопасностью, включая состояние загрузки (безопасная загрузка, режим отладки и т. д.), а также состояние компонентов, управляющий безопасностью (BitLocker, Device Guard и т. д.). Затем он передает состояние работоспособности устройства, отправляя на устройство зашифрованный blob-объект.

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

Решение MDM просит устройство отправить сведения о работоспособности устройства и перенаправить зашифрованный blob-объект работоспособности в службу удаленной аттестации работоспособности. Служба удаленной аттестации работоспособности проверяет данные о работоспособности устройства, проверяет, что MDM взаимодействует с тем же устройством, а затем выдает отчет о работоспособности устройства в решение MDM.

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

Затем доступ к содержимому авторизован на соответствующий уровень доверия для любого состояния работоспособности и других условных элементов.

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

Инвестиции Корпорации Майкрософт в безопасность в Windows

В Windows существует три основных принципа инвестиций:

• Защита удостоверений. Корпорация Майкрософт является частью альянса FIDO, который стремится обеспечить совместимый метод безопасной проверки подлинности, отключаясь от использования паролей для проверки подлинности, как в локальной системе, так и для таких служб, как локальные ресурсы и облачные ресурсы.
• Защита информации. Корпорация Майкрософт делает инвестиции, чтобы организации могли лучше контролировать, кто имеет доступ к важным данным и что они могут делать с ними. С помощью Windows организации могут воспользоваться преимуществами политик, которые определяют, какие приложения считаются корпоративными и могут быть доверенными для доступа к защищенным данным.
• Устойчивость к угрозам. Корпорация Майкрософт помогает организациям улучшить защиту корпоративных ресурсов от угроз вредоносных программ и атак, используя средства защиты, основанные на оборудовании.

Защита устройств под управлением Windows, управление и отчетность о состоянии безопасности устройств под управлением Windows

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

Число	Часть решения	Описание
1	Устройство под управлением Windows	При первом включении устройства под управлением Windows отображается экран встроенного интерфейса (OOBE). Во время настройки устройство может быть автоматически зарегистрировано в Microsoft Entra ID и зарегистрировано в MDM. Устройство под управлением Windows с TPM может сообщать о состоянии работоспособности в любое время с помощью службы аттестации работоспособности, доступной для всех поддерживаемых выпусков Windows.
2	Поставщик удостоверений	Microsoft Entra ID содержит пользователей, зарегистрированные устройства и зарегистрированное приложение клиента организации. Устройство всегда принадлежит пользователю, и у пользователя может быть несколько устройств. Устройство представляется как объект с разными атрибутами, такими как состояние соответствия устройства. Доверенный MDM может обновить состояние соответствия. Microsoft Entra ID — это не просто репозиторий. Microsoft Entra ID может проверять подлинность пользователей и устройств, а также авторизовать доступ к управляемым ресурсам. Microsoft Entra ID имеет подсистему управления условным доступом, которая использует удостоверение пользователя, расположение устройства, а также состояние соответствия устройства при принятии решения о доверенном доступе.
3	Управление мобильными устройствами	Windows поддерживает MDM, что позволяет управлять устройством без развертывания агента. MDM может быть Microsoft Intune или любым сторонним решением MDM, совместимым с Windows.
4	Удаленная аттестация работоспособности	Служба аттестации работоспособности — это надежная облачная служба корпорации Майкрософт, которая выполняет ряд проверок работоспособности и сообщает MDM о том, какие функции безопасности Windows включены на устройстве. Проверка безопасности включает состояние загрузки (WinPE, безопасный режим, режимы отладки и тестирования) и компоненты, управляющие безопасностью и целостностью операций среды выполнения (BitLocker, Device Guard).
5	Корпоративный управляемый ресурс	Корпоративный управляемый ресурс — это ресурс для защиты. Например, ресурс может быть Office 365, другие облачные приложения, локальные веб-ресурсы, опубликованные Microsoft Entra ID, или даже VPN-доступ.

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

Защита устройств и корпоративных учетных данных от угроз

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

Средства защиты на основе оборудования Windows

Наиболее агрессивные формы вредоносных программ пытаются как можно раньше вставить себя в процесс загрузки, чтобы они могли взять под контроль операционную систему на ранних этапах и предотвратить работу механизмов защиты и антивредоносного ПО. Этот тип вредоносного кода часто называется rootkit или bootkit. Лучший способ избежать проблем с низкоуровневыми вредоносными программами — защитить процесс загрузки, чтобы устройство было защищено с самого начала. Windows поддерживает несколько уровней защиты от загрузки. Некоторые из этих функций доступны, только если установлены определенные типы оборудования. Дополнительные сведения см. в разделе Требования к оборудованию .

Windows поддерживает функции, помогающие предотвратить загрузку сложных низкоуровневых вредоносных программ, таких как rootkit и bootkits во время запуска:

• Доверенный модуль платформы. Доверенный платформенный модуль (TPM) — это аппаратный компонент, предоставляющий уникальные функции безопасности.

  Windows использует характеристики безопасности доверенного платформенного модуля для измерения последовательности целостности загрузки (и на основе этого— автоматической разблокировки дисков, защищенных BitLocker), для защиты учетных данных или для аттестации работоспособности.

  TPM реализует элементы управления, которые соответствуют спецификации, описанной группой доверенных вычислений (TCG). На момент написания этой статьи существует две версии спецификации доверенного платформенного модуля, созданные TCG, которые несовместимы друг с другом:

  • Первая спецификация TPM версии 1.2 была опубликована в феврале 2005 года TCG и стандартизована в соответствии со стандартом ISO/IEC 11889.
  • Последняя спецификация TPM, называемая TPM 2.0, была выпущена в апреле 2014 года и утверждена Совместным техническим комитетом ISO/IEC (JTC) как ISO/IEC 11889:2015.

  Windows использует TPM для криптографических вычислений в рамках аттестации работоспособности и защиты ключей для BitLocker, Windows Hello, виртуальных смарт-карт и других сертификатов открытого ключа. Дополнительные сведения см. в разделе Требования доверенного платформенного модуля в Windows.

  Windows распознает спецификации TPM версий 1.2 и 2.0, созданные TCG. Для последних и современных функций безопасности Windows поддерживает только TPM 2.0.

  TPM 2.0 предоставляет основную редакцию возможностей доверенного платформенного модуля 1.2:

  • Обновление надежности шифрования в соответствии с современными требованиями к безопасности

    • Поддержка SHA-256 для PCR
    • Поддержка команды HMAC

  • Гибкость криптографических алгоритмов для поддержки государственных потребностей

    • TPM 1.2 строго ограничен с точки зрения того, какие алгоритмы он может поддерживать
    • TPM 2.0 может поддерживать произвольные алгоритмы с незначительными обновлениями в документах спецификации TCG.

  • Согласованность между реализациями

    • Спецификация TPM 1.2 предоставляет поставщикам широкие возможности при выборе сведений о реализации.
    • TPM 2.0 стандартизирует большую часть этого поведения

• Безопасная загрузка. Устройства с встроенным ПО UEFI можно настроить для загрузки только доверенных загрузчиков операционной системы. Для безопасной загрузки не требуется TPM.

  Самой базовой защитой является функция безопасной загрузки, которая является стандартной частью архитектуры UEFI 2.2+. На компьютере с обычной BIOS любой пользователь, который может управлять процессом загрузки, может загрузиться с помощью альтернативного загрузчика ОС и, возможно, получить доступ к системным ресурсам. Если включена безопасная загрузка, вы можете выполнить загрузку только с помощью загрузчика ОС, подписанного с помощью сертификата, хранящегося в базе данных безопасной загрузки UEFI. Естественно, сертификат Майкрософт, используемый для цифровой подписи загрузчиков ОС Windows, есть в этом хранилище, что позволяет UEFI проверить сертификат в рамках политики безопасности. Безопасная загрузка должна быть включена по умолчанию на всех компьютерах, сертифицированных для Windows в рамках программы совместимости оборудования Windows.

  Безопасная загрузка — это функция на основе встроенного ПО UEFI, которая позволяет подписывать и проверять критически важные загрузочные файлы и драйверы во время загрузки. Безопасная загрузка проверяет значения подписей диспетчера загрузки Windows, хранилища BCD, файла загрузчика ОС Windows и других критически важных библиотек DLL во время загрузки, прежде чем система сможет полностью загрузиться в пригодную для использования операционную систему с помощью политик, определенных изготовителем оборудования во время сборки. Безопасная загрузка предотвращает множество типов программ rootkit, вредоносных программ и других атак, связанных с безопасностью, на платформе Windows. Безопасная загрузка защищает процесс загрузки операционной системы, независимо от загрузки с локального жесткого диска, USB, PXE или DVD-диска, либо в полную среду windows или среду восстановления Windows (RE). Безопасная загрузка защищает среду загрузки установки Windows, проверяя сигнатуры критически важных загрузочных компонентов, чтобы убедиться, что вредоносные действия не скомпрометировать их. Защита от безопасной загрузки завершается после загрузки файла ядра Windows (ntoskrnl.exe).

  Примечание.

  Безопасная загрузка защищает платформу до загрузки ядра Windows. Затем защита, как ELAM, берет на себя.

• Политика конфигурации безопасной загрузки. Расширяет функциональность безопасной загрузки до критически важной конфигурации Windows.

  Примеры защищенных сведений о конфигурации включают в себя защиту параметра Отключить выполнение (параметр NX) или обеспечение того, что политика подписывания тестов (целостность кода) не может быть включена. Это действие защиты гарантирует, что двоичные файлы и конфигурация компьютера могут быть доверенными после завершения процесса загрузки. Политика конфигурации безопасной загрузки выполняет это защитное действие с помощью политики UEFI. Эти сигнатуры для этих политик подписываются так же, как и двоичные файлы операционной системы для использования с безопасной загрузкой.

  Политика конфигурации безопасной загрузки должна быть подписана закрытым ключом, соответствующим одному из открытых ключей, хранящимся в списке Ключ обмена ключами (KEK). Центр сертификации Майкрософт (ЦС) будет присутствовать в списке KEK всех сертифицированных систем безопасной загрузки Windows. По умолчанию политика, подписанная Microsoft KEK, должна работать во всех системах безопасной загрузки. Перед применением подписанной политики BootMgr необходимо проверить подпись на соответствие списку KEK. В Windows политика конфигурации безопасной загрузки по умолчанию внедрена в bootmgr.

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

• Ранний запуск вредоносной программы (ELAM). ELAM проверяет все драйверы перед их загрузкой и блокирует загрузку неутвержденных драйверов.

  Традиционные антивредоносные приложения запускаются только после загрузки драйверов загрузки, что дает возможность работать rootkit, который замаскирован под драйвер. ELAM — это механизм Windows, представленный в предыдущей версии Windows, который позволяет выполнять антивредоносное ПО на ранних этапах загрузки. Таким образом, компонент защиты от вредоносных программ является первым сторонним компонентом, который запускает и контролирует инициализацию других драйверов загрузки до тех пор, пока операционная система Windows не будет работать. При запуске системы в полной среде выполнения (сетевой доступ, хранилище и т. д.) загружается полнофункциональное антивредоносное ПО.

  ELAM может загрузить драйвер защиты от вредоносных программ Майкрософт или сторонних производителей перед всеми загрузочными драйверами и приложениями сторонних производителей, продолжая таким образом цепочку доверия, установленную безопасной загрузкой и доверенной загрузкой. Так как операционная система еще не запущена, а Windows необходимо загрузить как можно быстрее, ELAM выполняет простую задачу: проверьте каждый драйвер загрузки и определите, входит ли он в список доверенных драйверов. Если он не является доверенным, Windows не будет загружать его.

  Примечание.

  Защитник Windows, антивредоносное ПО Майкрософт, включенное по умолчанию в Windows, поддерживает ELAM; его можно заменить сторонним решением для защиты от вредоносных программ. Имя драйвера Защитник Windows ELAM — WdBoot.sys. Защитник Windows использует свой драйвер ELAM для отката всех вредоносных изменений, внесенных в драйвер Защитник Windows при следующей перезагрузке. Это предотвращает внесение вредоносных программ в режиме ядра длительных изменений в драйвер мини-фильтра Защитник Windows перед завершением работы или перезагрузкой.

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

  Драйвер ELAM — это небольшой драйвер с небольшой базой данных политик, которая имеет узкую область, ориентированную на драйверы, которые загружаются на ранних этапах запуска системы. База данных политики хранится в кусте реестра, который также измеряется доверенным платформенным модульом для записи рабочих параметров драйвера ELAM. Драйвер ELAM должен быть подписан корпорацией Майкрософт, а связанный сертификат должен содержать дополнительный EKU (1.3.6.1.4.1.311.61.4.1).

• Безопасность на основе виртуализации (Hyper-V + безопасное ядро). Безопасность на основе виртуализации — это новая принудительно применяемая граница безопасности, которая позволяет защищать критически важные части Windows.

  Безопасность на основе виртуализации изолирует конфиденциальный код, например целостность кода в режиме ядра или конфиденциальные учетные данные корпоративного домена, от остальной части операционной системы Windows. Дополнительные сведения см. в разделе Безопасность на основе виртуализации .

• Защищенная гипервизором целостность кода (HVCI). Целостность кода, защищенная гипервизором, — это функция Device Guard, которая обеспечивает запуск только драйверов, исполняемых файлов и библиотек DLL, соответствующих политике целостности кода Device Guard.

  После включения и настройки Windows может запустить службы безопасности на основе виртуализации Hyper-V. HVCI помогает защитить ядро системы (ядро), привилегированные драйверы и системные средства защиты, такие как антивредоносные решения, предотвращая запуск вредоносных программ в начале процесса загрузки или после запуска.

  HVCI использует безопасность на основе виртуализации для изоляции целостности кода. Единственный способ стать исполняемой памятью ядра — это проверка целостности кода. Эта зависимость от проверки означает, что страницы памяти ядра никогда не могут быть записываемыми и исполняемыми (W+X), а исполняемый код нельзя изменить напрямую.

  Примечание.

  Устройства Device Guard, на которых выполняется целостность кода в режиме ядра с безопасностью на основе виртуализации, должны иметь совместимые драйверы. Дополнительные сведения см. в записи блога Совместимость драйверов с Device Guard в Windows .

  Функция целостности кода Device Guard позволяет организациям контролировать, какой код является доверенным для запуска в ядре Windows и какие приложения утверждены для запуска в пользовательском режиме. Его можно настроить с помощью политики. Политика целостности кода Device Guard — это двоичный файл, который корпорация Майкрософт рекомендует подписать. Подписывание политики целостности кода помогает защитить злоумышленника с правами администратора, пытающегося изменить или удалить текущую политику целостности кода.

• Credential Guard. Credential Guard защищает корпоративные учетные данные с помощью аппаратной изоляции учетных данных.

  В Windows Credential Guard предназначена для защиты корпоративных учетных данных домена от кражи и повторного использования вредоносными программами. С помощью Credential Guard в Windows реализовано изменение архитектуры, которое принципиально предотвращает текущие формы атаки с передачей хэша (PtH).

  Это состояние без атак достигается с помощью Hyper-V и новой функции безопасности на основе виртуализации для создания защищенного контейнера, в котором доверенный код и секреты изолированы от ядра Windows. Это означает, что даже если ядро Windows скомпрометировано, злоумышленник не может считывать и извлекать данные, необходимые для инициации PtH-атаки. Credential Guard предотвращает этот несанкционированный доступ, так как память, в которой хранятся секреты, больше не доступна из обычной ОС, даже в режиме ядра. Гипервизор определяет, кто может получить доступ к памяти.

• Аттестация работоспособности. Встроенное ПО устройства регистрирует процесс загрузки, и Windows может отправить его на доверенный сервер, который может проверка и оценить работоспособности устройства.

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

  Дополнительные сведения см. в разделе Безопасная загрузка и измеряемая загрузка: защита компонентов ранней загрузки от вредоносных программ.

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

  Хотя безопасная загрузка — это упреждающая форма защиты, аттестация работоспособности — это реактивная форма защиты от загрузки. Аттестация работоспособности отключена в Windows и включена антивредоносным ПО или поставщиком MDM. В отличие от безопасной загрузки аттестация работоспособности не останавливает процесс загрузки и не вводит исправление, если измерение не работает. Но при управлении условным доступом аттестация работоспособности поможет предотвратить доступ к высокоценным ресурсам.

Обеспечение безопасности на основе виртуализации

Безопасность на основе виртуализации предоставляет новую границу доверия для Windows и использует технологию гипервизора Hyper-V для повышения безопасности платформы. Безопасность на основе виртуализации обеспечивает безопасную среду выполнения для выполнения определенного доверенного кода Windows (trustlet) и защиты конфиденциальных данных.

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

Следующие службы Windows защищены с помощью безопасности на основе виртуализации:

• Credential Guard (изоляция учетных данных LSA): предотвращает сквозные хэш-атаки и кражу корпоративных учетных данных, которая происходит путем считывания и дампа содержимого памяти lsass
• Device Guard (Целостность кода Hyper-V). Device Guard использует новую систему безопасности на основе виртуализации в Windows, чтобы изолировать службу целостности кода от самого ядра Windows, что позволяет службе использовать подписи, определенные политикой, управляемой предприятием, чтобы определить, что является надежным. Фактически служба целостности кода работает вместе с ядром в контейнере, защищенном гипервизором Windows.
• Другие изолированные службы: например, на Windows Server 2016 есть функция vTPM, которая позволяет иметь зашифрованные виртуальные машины на серверах.

Примечание.

Безопасность на основе виртуализации доступна только в выпуске Enterprise. Для обеспечения безопасности на основе виртуализации требуются устройства с UEFI (2.3.1 или более поздней версии) с включенной безопасной загрузкой, процессором x64 с расширениями виртуализации и SLAT. IOMMU, TPM 2.0. И поддержка безопасной перезаписи памяти являются необязательными, но рекомендуется.

Схема ниже представляет собой высокоуровневое представление Windows с безопасностью на основе виртуализации.

Credential Guard

В Windows при включении Credential Guard служба подсистемы локального центра безопасности (lsass.exe) выполняет конфиденциальный код в изолированном пользовательском режиме, чтобы защитить данные от вредоносных программ, которые могут работать в обычном пользовательском режиме. Такое выполнение кода помогает гарантировать, что защищенные данные не будут украдены и повторно не будут использоваться на удаленных компьютерах, что устраняет многие атаки в стиле PtH.

Credential Guard помогает защитить учетные данные, шифруя их с помощью загрузочного или постоянного ключа:

• Ключ для каждой загрузки используется для любых учетных данных в памяти, для которых не требуется сохраняемость. Примером таких учетных данных может быть ключ сеанса для предоставления билета (TGT). Этот ключ согласовывается с центром распространения ключей (KDC) каждый раз при проверке подлинности и защищен с помощью ключа для каждой загрузки.
• Постоянный ключ или некоторые производные используются для защиты элементов, которые хранятся и перезагружаются после перезагрузки. Такая защита предназначена для долгосрочного хранения и должна быть защищена согласованным ключом. Credential Guard активируется разделом реестра, а затем включается с помощью переменной UEFI. Эта активация выполняется для защиты от удаленных изменений конфигурации. Использование переменной UEFI подразумевает, что для изменения конфигурации требуется физический доступ. Когда lsass.exe обнаруживает, что изоляция учетных данных включена, она создает LsaIso.exe как изолированный процесс, который гарантирует, что он выполняется в изолированном режиме пользователя. Запуск LsaIso.exe выполняется перед инициализацией поставщика поддержки безопасности, что гарантирует, что подпрограммы поддержки безопасного режима будут готовы до начала проверки подлинности.

Device Guard

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

Решение о доверии для выполнения кода выполняется с помощью целостности кода Hyper-V, которая выполняется в системе безопасности на основе виртуализации, защищенном контейнере Hyper-V, который работает вместе с обычной Windows.

Целостность кода Hyper-V — это функция, которая проверяет целостность драйвера или системного файла при каждой загрузке в память. Целостность кода определяет, загружается ли неподписанный драйвер или системный файл в ядро или системный файл был изменен вредоносным программным обеспечением, запущенным учетной записью пользователя с правами администратора. В 64-разрядных версиях Windows драйверы режима ядра должны иметь цифровую подпись.

Примечание.

Независимо от активации политики Device Guard драйверы Windows должны быть подписаны корпорацией Майкрософт и, в частности, порталом WHQL (Лаборатории качества оборудования Windows). Кроме того, начиная с октября 2015 г. портал WHQL будет принимать только отправки драйверов, включая отправки драйверов в ядре и в пользовательском режиме, которые имеют действительный сертификат подписи кода расширенной проверки (EV).

С помощью Device Guard организации теперь могут определять собственную политику целостности кода для использования в системах x64 под управлением Windows Enterprise. Организации могут настроить политику, которая определяет, что является доверенным для запуска. К ним относятся драйверы и системные файлы, а также традиционные классические приложения и скрипты. Затем система блокируется для запуска только приложений, которым доверяет организация.

Device Guard — это встроенная функция Windows Enterprise, которая предотвращает выполнение нежелательного кода и приложений. Device Guard можно настроить с помощью двух действий правила: разрешить и запретить:

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

На момент написания этой статьи, согласно последним исследованиям Майкрософт, более 90 процентов вредоносных программ полностью не подписаны. Таким образом, реализация базовой политики Device Guard может просто и эффективно помочь блокировать вредоносные программы. На самом деле Device Guard может пойти дальше, а также может помочь блокировать подписанные вредоносные программы.

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

Решение Device Guard в Windows состоит из трех различных частей:

• Первая часть представляет собой базовый набор функций безопасности оборудования , представленных в предыдущей версии Windows. TPM для аппаратных криптографических операций и UEFI с современным встроенным ПО, наряду с безопасной загрузкой, позволяет контролировать работу устройства при запуске систем.
• После аппаратной безопасности появляется подсистема целостности кода. В Windows целостность кода теперь полностью настраивается и теперь находится в изолированном пользовательском режиме— части памяти, защищенной безопасностью на основе виртуализации.
• Последняя часть Device Guard — управляемость. Конфигурация целостности кода предоставляется с помощью определенных объектов групповая политика, командлетов PowerShell и поставщиков служб конфигурации MDM .

Дополнительные сведения о развертывании Device Guard на предприятии см. в руководстве по развертыванию Device Guard.

Сценарии Device Guard

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

Device Guard полезна и применима к системам фиксированных рабочих нагрузок, таким как кассовые аппараты, киоски, рабочие станции безопасности Администратор (SAW) или хорошо управляемые рабочие столы. Device Guard имеет высокую актуальность в системах с четко определенным программным обеспечением, которое, как ожидается, будет работать и не изменяется слишком часто. Это также может помочь защитить информационных работников (IW) помимо только SAW, если то, что им нужно запустить, известно и набор приложений не будет меняться ежедневно.

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

Чтобы защитить ценные ресурсы, SAW используются для создания безопасных подключений к этим ресурсам.

Аналогичным образом, на корпоративных полностью управляемых рабочих станциях, где приложения устанавливаются с помощью средства распространения, например Microsoft Configuration Manager, Intune или любого стороннего управления устройствами, применяется Device Guard. В этом сценарии организация имеет хорошее представление о программном обеспечении, которое выполняет средний пользователь.

Использование Device Guard на корпоративных, легко управляемых рабочих станциях, где пользователю обычно разрешено устанавливать программное обеспечение самостоятельно. Когда организация предлагает большую гибкость, трудно запустить Device Guard в режиме принудительного применения. Тем не менее Device Guard можно запустить в режиме аудита, и в этом случае журнал событий будет содержать запись всех двоичных файлов, нарушивших политику Device Guard. Если Device Guard используется в режиме аудита, организации могут получать обширные данные о драйверах и приложениях, которые пользователи устанавливают и запускают.

Прежде чем вы сможете воспользоваться защитой, включенной в Device Guard, необходимо создать политику целостности кода с помощью средств, предоставляемых корпорацией Майкрософт, но эту политику можно развернуть с помощью общих средств управления, таких как групповая политика. Политика целостности кода — это xml-документ в двоичном коде, который включает параметры конфигурации для режимов пользователя и ядра Windows, а также ограничения на узлы сценариев Windows. Политика целостности кода Device Guard ограничивает, какой код может выполняться на устройстве.

Примечание.

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

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

При подписании политики GUID политики сохраняется в защищенной переменной UEFI до ОС, которая обеспечивает защиту от незаконного изменения. Единственный способ обновить политику Device Guard позже — предоставить новую версию политики, подписанной тем же подписывателем или подписывателем, указанным в рамках политики Device Guard, в разделе UpdateSigner.

Важность подписывания приложений

На компьютерах с Device Guard корпорация Майкрософт предлагает перейти из мира, где неподписанные приложения можно запускать без ограничений, в мир, в котором в Windows разрешено запускать только подписанный и доверенный код.

С помощью Windows организации сделают бизнес-приложения доступными для участников организации через инфраструктуру Microsoft Store. В частности, бизнес-приложения будут доступны в частном магазине в общедоступном Microsoft Store. Microsoft Store подписывает и распространяет универсальные приложения для Windows и классические приложения для Windows. Все приложения, скачанные из Microsoft Store, подписываются.

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

Windows включает средства, позволяющие ИТ-специалистам принимать уже упакованные приложения и запускать их в процессе создания дополнительных подписей, которые можно распространять вместе с существующими приложениями.

Почему по-прежнему необходимы решения для защиты от вредоносных программ и устройств?

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

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

Злоумышленники часто распространяют специально созданное содержимое, пытаясь использовать известные уязвимости в программном обеспечении пользовательского режима, например в веб-браузерах (и подключаемых модулях), виртуальных машинах Java, программах чтения PDF или редакторах документов. На сегодняшний день 90 процентов обнаруженных уязвимостей влияют на приложения пользовательского режима по сравнению с драйверами операционной системы и режима ядра, в которых они размещаются.

Для борьбы с этими угрозами исправление является единственным наиболее эффективным средством управления, при этом антивредоносное программное обеспечение формирует взаимодополняющие уровни защиты.

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

Решения MDM становятся популярными в качестве легкой технологии управления устройствами. Windows расширяет возможности управления, которые стали доступны для MDM. Одной из ключевых функций, добавленных корпорацией Майкрософт в Windows, является возможность MDM получать надежные сведения о работоспособности устройств от управляемых и зарегистрированных устройств.

Аттестация работоспособности устройства

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

Для устройств под управлением Windows корпорация Майкрософт представляет новый общедоступный API, который позволит программному обеспечению MDM получать доступ к службе удаленной аттестации под названием Служба аттестации работоспособности Windows. Результат аттестации работоспособности в дополнение к другим элементам можно использовать для разрешения или запрета доступа к сетям, приложениям или службам в зависимости от того, будут ли устройства работоспособными.

Дополнительные сведения об аттестации работоспособности устройств см. в разделе Обнаружение неработоспособного устройства под управлением Windows .

Требования к выпуску и лицензированию Windows

В следующей таблице перечислены выпуски Windows, поддерживающие службу аттестации работоспособности устройств.

Windows Pro	Windows Корпоративная	Windows Pro для образовательных учреждений/SE	Windows для образовательных учреждений
Да	Да	Да	Да

Права на лицензию службы аттестации работоспособности устройств предоставляются следующими лицензиями:

Windows Pro/Pro для образовательных учреждений/SE	Windows Корпоративная E3	Windows Корпоративная E5	Windows для образовательных учреждений A3	Windows для образовательных учреждений A5
Да	Да	Да	Да	Да

Дополнительные сведения о лицензировании Windows см. в статье Обзор лицензирования Windows.

Требования к оборудованию

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

Оборудование	Мотивации
Встроенное ПО UEFI 2.3.1 или более поздней версии с включенной безопасной загрузкой	Требуется для поддержки безопасной загрузки UEFI. Безопасная загрузка UEFI гарантирует, что устройство загружает только авторизованный код. Кроме того, целостность загрузки (безопасная загрузка платформы) должна поддерживаться в соответствии с требованиями в спецификации совместимости оборудования для систем windows в подразделе "System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby".
Необходимо включить расширения виртуализации, такие как Intel VT-x, AMD-V и SLAT.	Требуется для поддержки безопасности на основе виртуализации. Примечание: Device Guard можно включить без использования безопасности на основе виртуализации.
Процессор X64	Требуется для поддержки безопасности на основе виртуализации, использующего гипервизор Windows. Hyper-V поддерживается только на процессоре x64 (но не на x86). Защита прямого доступа к памяти (DMA) может быть включена, чтобы обеспечить дополнительную защиту памяти, но требуется, чтобы процессоры включали технологии защиты DMA.
IOMMU, например Intel VT-d, AMD-Vi	Поддержка IOMMU в Windows повышает устойчивость системы к атакам DMA.
Доверенный платформенный модуль (TPM)	Требуется для поддержки аттестации работоспособности и требуется для защиты других ключей для обеспечения безопасности на основе виртуализации. TPM 2.0 поддерживается. Поддержка TPM 1.2 была добавлена начиная с Windows 10 версии 1607 (RS1)

В этом разделе представлены сведения о нескольких тесно связанных элементах управления в Windows . Многоуровневая защита и глубокий подход помогают искоренить низкоуровневые вредоносные программы во время загрузки. Безопасность на основе виртуализации — это фундаментальное изменение архитектуры операционной системы, которое добавляет новую границу безопасности. Device Guard и Credential Guard соответственно помогают блокировать ненадежный код и защищать учетные данные корпоративного домена от кражи и повторного использования. В этом разделе также кратко говорилось о важности управления устройствами и исправлений уязвимостей. Все эти технологии можно использовать для защиты и блокировки устройств, одновременно ограничивая риск компрометации злоумышленников.

Обнаружение неработоспособного устройства под управлением Windows

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

Самая большая проблема с rootkit заключается в том, что их можно не обнаружить для клиента. Так как они запускаются до защиты от вредоносных программ и имеют привилегии системного уровня, они могут полностью замаскироваться, продолжая получать доступ к системным ресурсам. В результате традиционные компьютеры, зараженные rootkits, кажутся работоспособными, даже если запущено антивредоносное ПО.

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

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

Какова концепция работоспособности устройства?

Чтобы понять концепцию работоспособности устройств, важно знать традиционные меры, принятые ИТ-специалистами для предотвращения нарушения вредоносных программ. Технологии управления вредоносными программами ориентированы на предотвращение установки и распространения.

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

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

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

Но аттестация работоспособности предоставляет только информацию, поэтому для принятия и выполнения решения требуется решение MDM.

Аттестация работоспособности удаленного устройства

В Windows аттестация работоспособности относится к функции, при которой данные измеряемой загрузки, созданные во время загрузки, отправляются в службу аттестации работоспособности удаленного устройства, обслуживаемую корпорацией Майкрософт.

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

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

Примечание.

Чтобы использовать функцию аттестации работоспособности Windows, устройство должно быть оснащено дискретным доверенным модулем или доверенным модулем встроенного ПО. Не существует ограничений на какой-либо конкретный выпуск Windows.

Windows поддерживает сценарии аттестации работоспособности, предоставляя приложениям доступ к базовому поставщику службы конфигурации аттестации работоспособности (CSP), чтобы приложения могли запрашивать маркер аттестации работоспособности. Измерение последовательности загрузки может быть проверено в любое время локально с помощью антивредоносного ПО или агента MDM.

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

В случае, если на устройстве выполняется вредоносный код, требуется использовать удаленный сервер. Если на устройстве присутствует rootkit, антивредоносное ПО больше не является надежным, и его поведение может быть захвачено вредоносным кодом, запущенным в начале последовательности запуска. Именно по этой причине важно использовать безопасную загрузку и Device Guard, чтобы контролировать, какой код загружается во время последовательности загрузки.

Антивредоносное программное обеспечение может выполнять поиск, чтобы определить, содержит ли последовательность загрузки какие-либо признаки вредоносных программ, например rootkit. Он также может отправлять журнал TCG и PCR на удаленный сервер аттестации работоспособности, чтобы обеспечить разделение между компонентом измерения и компонентом проверки.

Аттестация работоспособности регистрирует измерения в различных регистрах конфигурации платформы TPM (PCR) и журналах TCG во время загрузки.

При запуске устройства, оснащенного TPM, выполняется измерение различных компонентов. К этим компонентам относятся встроенное ПО, драйверы UEFI, микрокод ЦП, а также все драйверы Windows, тип которых — Boot Start. Необработанные измерения хранятся в регистрах PCR доверенного платформенного модуля, а сведения обо всех событиях (путь к исполняемому файлу, сертификация центра и т. д.) доступны в журнале TCG.

Процесс аттестации работоспособности работает следующим образом:

1. Измеряются компоненты загрузки оборудования.
2. Измеряются компоненты загрузки операционной системы.
3. Если функция Device Guard включена, измеряется текущая политика Device Guard.
4. Измеряется ядро Windows.
5. Антивирусная программа запускается как первый драйвер режима ядра.
6. Загрузочные драйверы запуска измеряются.
7. Сервер MDM через агент MDM выдает команду проверка работоспособности с помощью CSP аттестации работоспособности.
8. Измерения загрузки проверяются службой аттестации работоспособности.

Примечание.

По умолчанию последние 100 журналов загрузки системы и все связанные журналы возобновления архивируются в папке %SystemRoot%\logs\measuredboot. Количество сохраненных журналов можно задать с помощью реестра REG_DWORD значение PlatformLogRetention в разделе HKLM\SYSTEM\CurrentControlSet\Services\TPM . Значение 0 отключает архивацию журналов, а значение 0xffffffff будет хранить все журналы.

В следующем процессе описывается, как измерения загрузки работоспособности отправляются в службу аттестации работоспособности.

1. Клиент (устройство под управлением Windows с TPM) инициирует запрос с помощью службы аттестации работоспособности удаленного устройства. Так как сервер аттестации работоспособности должен быть облачной службой Майкрософт, URI уже предварительно подготовлен в клиенте.

2. Затем клиент отправляет журнал TCG, данные, подписанные AIK (значения PCR, счетчик загрузки) и сведения о сертификате AIK.

3. Затем служба аттестации тепла удаленного устройства:

   1. Проверяет, выдан ли сертификат AIK известным и доверенным ЦС, а сертификат действителен и не отозван.
   2. Проверяет правильность подписи в кавычках PCR и соответствие значению журнала TCG.
   3. Анализирует свойства в журнале TCG.
   4. Выдает маркер работоспособности устройства, содержащий сведения о работоспособности, сведения об AIK и сведения счетчика загрузки. Маркер работоспособности также содержит допустимое время выдачи. Маркер работоспособности устройства шифруется и подписывается. Это означает, что информация защищена и доступна только для службы аттестации работоспособности.

4. Клиент сохраняет зашифрованный большой двоичный объект работоспособности в локальном хранилище. Маркер работоспособности устройства содержит состояние работоспособности устройства, идентификатор устройства (Windows AIK) и счетчик загрузки.

Компоненты аттестации работоспособности устройств

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

Доверенный платформенный модуль

В этом разделе описывается, как pcr (которые содержат данные конфигурации системы), ключ подтверждения (EK) (который выступает в качестве удостоверения карта для доверенного платформенного модуля), SRK (защищающие ключи) и пакеты AI (которые могут сообщать о состоянии платформы) используются для отчетов об аттестации работоспособности.

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

TPM включает в себя один компонент:

• Генератор ключей RSA 2048 бит
• Генератор случайных чисел
• Неизменяемая память для хранения ключей EK, SRK и AIK
• Подсистема шифрования для шифрования, расшифровки и подписывания
• Энергонезависимая память для хранения pcr и ключей RSA

Ключ подтверждения

TPM имеет внедренный уникальный криптографический ключ, который называется ключом подтверждения. Ключ подтверждения доверенного платформенного модуля — это пара асимметричных ключей (размер RSA 2048 бит).

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

Ключ подтверждения выступает в качестве карта удостоверения для доверенного платформенного модуля. Дополнительные сведения см. в разделе Общие сведения о ключе подтверждения доверенного платформенного модуля.

Ключ подтверждения часто сопровождается одним или двумя цифровыми сертификатами:

• Один сертификат создается производителем доверенного платформенного модуля и называется сертификатом подтверждения. Сертификат подтверждения используется для подтверждения подлинности доверенного платформенного модуля (например, что это реальный TPM, изготовленный конкретным производителем микросхем) для локальных процессов, приложений или облачных служб. Сертификат подтверждения создается во время производства или при первом инициализации доверенного платформенного модуля путем взаимодействия с веб-службой.
• Другой сертификат создается построителем платформы и называется сертификатом платформы , чтобы указать, что определенный TPM интегрирован с определенным устройством. Для некоторых устройств, использующих TPM на основе встроенного ПО, созданных корпорацией Intel или Qualcomm, сертификат подтверждения создается при инициализации доверенного платформенного модуля во время запуска windows.

Примечание.

Безопасная загрузка защищает платформу до загрузки ядра Windows. Затем наберутся такие меры защиты, как доверенная загрузка, целостность кода Hyper-V и ELAM. Устройство, использующее TPM Intel или Qualcomm TPM, получает подписанный сертификат через Интернет от производителя, создавшего микросхему, а затем хранит подписанный сертификат в хранилище доверенного платформенного модуля. Для успешного выполнения операции при фильтрации доступа к Интернету с клиентских устройств необходимо авторизовать следующие URL-адреса:

• Для TPM встроенного ПО Intel: https://ekop.intel.com/ekcertservice
• Для доверенного модуля встроенного ПО Qualcomm: https://ekcert.spserv.microsoft.com/

Ключи удостоверения аттестации

Так как сертификат подтверждения уникален для каждого устройства и не меняется, его использование может привести к проблемам конфиденциальности, так как теоретически можно отслеживать конкретное устройство. Чтобы избежать этой проблемы конфиденциальности, Windows выдает производную привязку аттестации на основе сертификата подтверждения. Этот промежуточный ключ, который можно заверять на ключ подтверждения, является ключом удостоверения аттестации (AIK), а соответствующий сертификат называется сертификатом AIK. Этот сертификат AIK выдается облачной службой Майкрософт.

Примечание.

Прежде чем устройство сможет сообщить о своей работоспособности с помощью функций аттестации доверенного платформенного модуля, необходимо подготовить сертификат AIK вместе со сторонней службой, такой как служба ЦС Microsoft Cloud. После подготовки закрытый ключ AIK можно использовать для создания отчетов о конфигурации платформы. Windows создает сигнатуру для состояния журнала платформы (и монотонное значение счетчика) при каждой загрузке с помощью AIK.

AIK — это асимметричная пара ключей (открытый и закрытый), которая используется в качестве замены EK в качестве удостоверения доверенного платформенного модуля в целях конфиденциальности. Частная часть AIK никогда не отображается и не используется за пределами доверенного платформенного модуля и может использоваться только внутри доверенного платформенного модуля для ограниченного набора операций. Кроме того, его можно использовать только для подписывания и только для ограниченных операций, определяемых TPM.

Windows создает пакеты АИ, защищенные доверенным платформенный модуль (если они доступны) и представляют собой 2048-разрядные ключи подписывания RSA. Корпорация Майкрософт размещает облачную службу под названием Microsoft Cloud CA, чтобы установить криптографически, что он взаимодействует с реальным TPM и что TPM обладает представленным AIK. После того как служба ЦС Microsoft Cloud установит эти факты, она выдаст сертификат AIK устройству под управлением Windows.

Многие существующие устройства, которые будут обновлены до Windows 10, не будут иметь TPM или TPM не будет содержать сертификат подтверждения. Для размещения этих устройств Windows 10 позволяет выдавать сертификаты AIK без наличия сертификата подтверждения. Такие сертификаты AIK не выдаются облачным центром сертификации Майкрософт. Эти сертификаты не так надежны, как сертификат подтверждения, который сжигается на устройстве во время производства, но он обеспечит совместимость для сложных сценариев, таких как Windows Hello для бизнеса без доверенного платформенного модуля.

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

Корневой ключ хранилища

Корневой ключ хранилища (SRK) также является асимметричной парой ключей (RSA с длиной не менее 2048 бит). SRK имеет основную роль и используется для защиты ключей доверенного платформенного модуля, поэтому эти ключи нельзя использовать без доверенного платформенного модуля. Ключ SRK создается, когда владелец доверенного платформенного модуля становится владельцем.

Регистры конфигурации платформы

TPM содержит набор регистров, предназначенных для предоставления криптографического представления программного обеспечения и состояния системы, которая была загружена. Эти регистры называются регистрами конфигурации платформы (PCR).

Измерение последовательности загрузки основано на журнале PCR и TCG. Чтобы установить статический корень доверия, когда устройство запускается, устройство должно иметь возможность измерять код встроенного ПО перед выполнением. В этом случае основной корень доверия для измерения (CRTM) выполняется из загрузки, вычисляет хэш встроенного ПО, а затем сохраняет его путем развертывания регистра PCR[0] и передает выполнение встроенному ПО.

PcR устанавливаются в нулевое значение при загрузке платформы, и это работа встроенного ПО, которая загружает платформу, чтобы измерять компоненты в цепочке загрузки и записывать измерения в PCR. Как правило, компоненты загрузки принимают хэш следующего компонента, который должен быть запущен, и записывают измерения в PCR. Начальный компонент, запускающий цепочку измерений, неявно является доверенным. Этим компонентом является CRTM. Производители платформы должны иметь безопасный процесс обновления для CRTM или не разрешать обновления для него. PcR записывают совокупный хэш измеряемых компонентов.

Значение PCR само по себе трудно интерпретировать (это просто хэш-значение), но платформы обычно хранят журнал с подробными сведениями о том, что было измерено, и PCR просто гарантируют, что журнал не был изменен. Журналы называются журналом TCG. При каждом продлении регистра PCR в журнал TCG добавляется запись. Таким образом, на протяжении всего процесса загрузки в журнале TCG создается трассировка исполняемого кода и данных конфигурации.

Подготовка доверенного платформенного модуля

Чтобы доверенный платформенный модуль устройства под управлением Windows был пригодным для использования, его сначала необходимо подготовить. Процесс подготовки зависит от версий доверенного платформенного модуля, но при успешном выполнении он приводит к тому, что TPM будет использоваться, а данные авторизации владельца (ownerAuth) для доверенного платформенного модуля хранятся локально в реестре.

При подготовке доверенного платформенного модуля Windows сначала попытается определить значения EK и локально сохраненных значений ownerAuth , выполнив поиск в реестре в следующем расположении: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

В процессе подготовки устройство может потребоваться перезапустить.

Командлет PowerShell Get-TpmEndorsementKeyInfo можно использовать с правами администратора для получения сведений о ключе подтверждения и сертификатах доверенного платформенного модуля.

Если владение TPM неизвестно, но существует EK, клиентская библиотека подготовит TPM и сохранит полученное значение ownerAuth в реестре, если политика позволяет хранить общедоступную часть SRK в следующем расположении: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Администратор\SRKPub

В рамках процесса подготовки Windows создаст AIK с доверенным платформенный платформенный модуль. При выполнении этой операции результирующая общедоступная часть AIK сохраняется в реестре в следующем расположении: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

Примечание.

Для подготовки сертификатов AIK и фильтрации доступа к Интернету необходимо авторизовать следующий URL-адрес с подстановочными знаками: https://\*.microsoftaik.azure.net

CSP аттестации работоспособности Windows

Windows содержит поставщик служб конфигурации (CSP), специализированный для взаимодействия с функцией аттестации работоспособности. CSP — это компонент, который подключается к клиенту Windows MDM и предоставляет опубликованный протокол, позволяющий серверам MDM настраивать параметры и управлять устройствами Под управлением Windows. Протокол управления представлен в виде древовидной структуры, которую можно указать в виде URI с функциями для выполнения в URI, такими как "get", "set", "delete" и т. д.

Ниже приведен список функций, выполняемых поставщиком служб аттестации работоспособности Windows:

• Собирает данные, используемые для проверки состояния работоспособности устройства
• Пересылает данные в службу аттестации работоспособности.
• Подготавливает сертификат аттестации работоспособности, полученный от службы аттестации работоспособности
• По запросу пересылает сертификат аттестации работоспособности (полученный от службы аттестации работоспособности) и связанные сведения о среде выполнения на сервер MDM для проверки.

Во время сеанса аттестации работоспособности поставщик услуг по аттестации работоспособности пересылает журналы TCG и значения PCR, измеряемые во время загрузки, с помощью безопасного канала связи в службу аттестации работоспособности.

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

Служба аттестации работоспособности Windows

Роль службы аттестации работоспособности Windows состоит в том, чтобы оценить набор данных о работоспособности (журнал TCG и значения PCR), выполнить ряд обнаружений (на основе доступных данных о работоспособности) и создать зашифрованный BLOB-объект работоспособности или создать отчет на серверах MDM.

Примечание.

Как устройства, так и серверы MDM должны иметь доступ к has.spserv.microsoft.com по протоколу TCP через порт 443 (HTTPS).

Проверка допустимости аттестации доверенного платформенного модуля и связанного журнала выполняется в нескольких шагах:

1. Во-первых, сервер должен проверка, что отчеты подписаны надежными пакетами AIK. Эта проверка может быть выполнена путем проверки того, что общедоступная часть AIK указана в базе данных ресурсов, или, возможно, что сертификат был проверен.
2. После проверки ключа необходимо проверить подписанную аттестацию (структуру кавычек), чтобы проверить, является ли она допустимой сигнатурой по значениям PCR.
3. Затем необходимо проверить журналы, чтобы убедиться, что они соответствуют указанным значениям PCR.
4. Наконец, сами журналы должны быть проверены решением MDM, чтобы узнать, представляют ли они известные или допустимые конфигурации безопасности. Например, простой проверка может заключаться в том, чтобы узнать, являются ли измеренные ранние компоненты ОС хорошими, что драйвер ELAM соответствует ожиданиям и что файл политики драйвера ELAM обновлен. Если все эти проверки успешно выполняются, можно вывести инструкцию аттестации, которую позже можно будет использовать для определения того, следует ли предоставить клиенту доступ к ресурсу.

Служба аттестации работоспособности предоставляет решению MDM следующие сведения о работоспособности устройства:

• Включение безопасной загрузки
• Включение загрузки и отладки ядра
• Включение BitLocker
• VSM включен
• Измерение политики целостности кода Device Guard со знаком или без знака
• ELAM загружено
• Загрузка в безопасном режиме, включение DEP, включение тестового подписывания
• TPM устройства подготовлен с доверенным сертификатом подтверждения

Сведения о полноте измерений см. в разделе CSP аттестации работоспособности.

В следующем списке показаны некоторые ключевые элементы, которые можно отправить в MDM для устройств под управлением Windows:

• Измерение PCR0
• Безопасная загрузка включена
• Безопасная загрузка базы данных соответствует ожидаемому
• Безопасная загрузка dbx обновлена
• Идентификатор GUID политики безопасной загрузки соответствует ожидаемому
• BitLocker включен
• Включена безопасность на основе виртуализации
• Был загружен ELAM
• Обновлена версия целостности кода
• Ожидаемые хэш-совпадения политики целостности кода

Использование MDM и службы аттестации работоспособности

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

Решение, использующее MDM и службу аттестации работоспособности, состоит из трех main частей:

1. Устройство с включенной аттестацией работоспособности. Это включение будет выполняться в рамках регистрации с помощью поставщика MDM (аттестация работоспособности будет отключена по умолчанию).

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

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

   

Взаимодействие между устройством под управлением Windows, службой аттестации работоспособности и MDM может выполняться следующим образом:

1. Клиент инициирует сеанс с сервером MDM. URI для сервера MDM будет частью клиентского приложения, которое инициирует запрос. Сервер MDM в это время может запросить данные аттестации работоспособности с помощью соответствующего URI CSP.

2. Сервер MDM указывает nonce вместе с запросом.

3. Затем клиент отправляет кавычки AIK nonce + счетчик загрузки и сведения о blob-объекте работоспособности. Этот blob-объект работоспособности шифруется с помощью открытого ключа службы аттестации работоспособности, который может расшифровать только служба аттестации работоспособности.

4. Сервер MDM:

   1. Проверяет, соответствует ли значение nonce ожидаемому.
   2. Передает цитируемые данные, nonce и зашифрованный blob-объект работоспособности на сервер службы аттестации работоспособности.

5. Служба аттестации работоспособности:

   1. Расшифровывает большой двоичный объект работоспособности.
   2. Проверяет правильность счетчика загрузки в кавычках с помощью AIK в blob-объекте работоспособности и соответствует значению в blob-объекте работоспособности.
   3. Проверяет, совпадает ли значение nonce в кавычках и передается из MDM.
   4. Так как счетчик загрузки и nonce указаны в AIK из большого двоичного объекта работоспособности, это также доказывает, что устройство совпадает с устройством, для которого был создан blob-объект работоспособности.
   5. Отправляет данные обратно на сервер MDM, включая параметры работоспособности, актуальность и т. д.

Примечание.

Сервер MDM (проверяющая сторона) никогда не выполняет проверку счетчика кавычек или загрузки. Он получает цитируемые данные и большой двоичный объект работоспособности (который зашифрован) и отправляет данные в службу аттестации работоспособности для проверки. Таким образом, AIK никогда не будет виден MDM, который тем самым решает проблемы конфиденциальности.

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

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

Управление безопасностью устройства под управлением Windows до предоставления доступа

Современная технология управления доступом в большинстве случаев ориентирована на обеспечение доступа нужных людей к нужным ресурсам. Если пользователи могут пройти проверку подлинности, они получают доступ к ресурсам с помощью устройства, о чем ИТ-сотрудники и системы организации мало знают. Возможно, есть некоторые проверка, такие как обеспечение шифрования устройства перед предоставлением доступа к электронной почте, но что делать, если устройство заражено вредоносными программами?

Процесс аттестации работоспособности удаленного устройства использует измеряемые данные загрузки для проверки состояния работоспособности устройства. Затем работоспособность устройства будет доступна для решения MDM, например Intune.

Примечание.

Последние сведения о поддержке функций Intune и Windows см. в статье Новые возможности Microsoft Intune.

На рисунке ниже показано, как служба аттестации работоспособности должна работать с облачной службой microsoft Intune MDM.

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

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

Встроенная поддержка MDM в Windows

Windows имеет клиент MDM, который поставляется как часть операционной системы. Этот клиент MDM позволяет серверам MDM управлять устройствами под управлением Windows, не требуя отдельного агента.

Поддержка сервера MDM сторонних служб

Серверы MDM сторонних версий могут управлять Windows с помощью протокола MDM. Встроенный клиент управления может взаимодействовать с совместимым сервером, поддерживающим протокол OMA-DM для выполнения задач корпоративного управления. Дополнительные сведения см. в разделе Microsoft Entra интеграции с MDM.

Примечание.

Серверам MDM не нужно создавать или скачивать клиент для управления Windows. Дополнительные сведения см. в разделе Управление мобильными устройствами.

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

Управление Защитник Windows сторонним MDM

Эта инфраструктура управления позволяет ИТ-специалистам использовать продукты с поддержкой MDM, такие как Intune, для управления аттестацией работоспособности, Device Guard или Защитник Windows на устройствах под управлением Windows, включая идентификаторы BYOD, которые не присоединены к домену. ИТ-специалисты смогут управлять и настраивать все действия и параметры, с которыми они знакомы, используя Intune с Intune Endpoint Protection в операционных системах нижнего уровня. Администраторам, которые в настоящее время управляют только устройствами, присоединенными к домену, через групповая политика, будет легко перейти на управление устройствами под управлением Windows с помощью MDM, так как многие параметры и действия совместно используются в обоих механизмах.

Дополнительные сведения о том, как управлять параметрами безопасности и системы Windows с помощью решения MDM, см. в статье Пользовательские параметры URI для устройств Windows.

Управление условным доступом

На большинстве платформ регистрация устройства Microsoft Entra происходит автоматически во время регистрации. Состояния устройства записываются решением MDM в Microsoft Entra ID, а затем считываются Office 365 (или любым авторизованным приложением Windows, взаимодействующим с Microsoft Entra ID) при следующей попытке клиента получить доступ к рабочей нагрузке, совместимой с Office 365.

Если устройство не зарегистрировано, пользователь получит сообщение с инструкциями по регистрации (также называемое регистрацией). Если устройство не соответствует требованиям, пользователь получит другое сообщение, которое перенаправляет его на веб-портал MDM, где он может получить дополнительные сведения о проблеме соответствия требованиям и способах ее устранения.

Microsoft Entra ID проверяет подлинность пользователя и устройства, MDM управляет политиками соответствия требованиям и условного доступа, а служба аттестации работоспособности сообщает о работоспособности устройства проверенным способом.

управление условным доступом Office 365

Microsoft Entra ID применяет политики условного доступа для защиты доступа к службам Office 365. Администратор клиента может создать политику условного доступа, которая блокирует доступ пользователя на несоответствующем устройству к службе Office 365. Пользователь должен соответствовать политикам устройств компании, прежде чем получить доступ к службе. Кроме того, администратор также может создать политику, которая требует, чтобы пользователи просто регистрили свои устройства, чтобы получить доступ к Office 365 службе. Политики могут применяться ко всем пользователям организации или ограничиваться несколькими целевыми группами и со временем расширены для включения большего числа целевых групп.

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

Когда пользователь регистрируется, устройство регистрируется в Microsoft Entra ID и регистрируется с помощью совместимого решения MDM, например Intune.

Примечание.

Корпорация Майкрософт работает со сторонними поставщиками ПРОГРАММНОго обеспечения MDM для поддержки автоматической регистрации MDM и проверок доступа на основе политик. Инструкции по включению автоматической регистрации MDM с помощью Microsoft Entra ID и Intune описаны в записи блога Windows, Microsoft Entra ID и Microsoft Intune: Автоматическая регистрация MDM на платформе облака!

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

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

В зависимости от типа почтового приложения, используемого сотрудниками для доступа к Exchange Online, путь к защищенному доступу к электронной почте может немного отличаться. Однако ключевые компоненты: Microsoft Entra ID, Office 365/Exchange Online и Intune, совпадают. Ит-интерфейс и взаимодействие с конечными пользователями также похожи.

Клиенты, которые пытаются получить доступ к Office 365, будут оцениваться по следующим свойствам:

• Управляется ли устройство с помощью MDM?
• Зарегистрировано ли устройство в Microsoft Entra ID?
• Соответствует ли устройство требованиям?

Чтобы добраться до соответствующего состояния, устройству под управлением Windows необходимо:

• Зарегистрируйтесь в решении MDM.
• Зарегистрируйтесь с помощью Microsoft Entra ID.
• Соответствие политикам устройств, заданным решением MDM.

Примечание.

В настоящее время политики условного доступа выборочно применяются к пользователям на устройствах iOS и Android. Дополнительные сведения см. в записи блога Microsoft Entra ID, Microsoft Intune и Windows — использование облака для модернизации корпоративной мобильности!.

Управление условным доступом для облачных и локальных приложений

Управление условным доступом — это мощный модуль оценки политик, встроенный в Microsoft Entra ID. Это дает ИТ-специалистам простой способ создания правил доступа за пределами Office 365, которые оценивают контекст входа пользователя, чтобы в режиме реального времени принимать решения о том, к каким приложениям они должны иметь доступ.

ИТ-специалисты могут настраивать политики управления условным доступом для облачных приложений SaaS, защищенных Microsoft Entra ID и даже локальными приложениями. Правила доступа в Microsoft Entra ID используют подсистему условного доступа для проверка состояния работоспособности и соответствия устройств, сообщаемого совместимым решением MDM, таким как Intune, чтобы определить, следует ли разрешать доступ.

Дополнительные сведения об условном доступе см. в статье Условный Access (предварительная версия) Azure для приложений SaaS.

Примечание.

Управление условным доступом — это функция Microsoft Entra ID P1 или P2, которая также доступна в EMS. Если у вас нет подписки на Microsoft Entra ID P1 или P2, вы можете получить пробную версию на сайте Microsoft Azure.

Для локальных приложений существует два варианта включения управления условным доступом на основе состояния соответствия устройства:

• Для локальных приложений, опубликованных через прокси-сервер приложения Microsoft Entra, можно настроить политики управления условным доступом так же, как и для облачных приложений. Дополнительные сведения см. в статье Использование Microsoft Entra прокси приложения для публикации локальных приложений для удаленных пользователей.
• Кроме того, Microsoft Entra Connect синхронизирует сведения о соответствии устройств из Microsoft Entra ID в локальную службу AD. ADFS на Windows Server 2016 будет поддерживать управление условным доступом на основе состояния соответствия устройств. ИТ-специалисты настроят политики управления условным доступом в ADFS, которые используют состояние соответствия устройства, сообщаемое совместимым решением MDM, для защиты локальных приложений.

В следующем процессе описывается, как работает условный доступ Microsoft Entra.

1. Пользователь уже зарегистрировался в MDM с помощью рабочего доступа или Azure AD присоединения, который регистрирует устройство с помощью Microsoft Entra ID.
2. Когда устройство загружается или возобновляется из режима гибернации, активируется задача "Tpm-HASCertRetr" для запроса в фоновом режиме большого двоичного объекта аттестации работоспособности. Устройство отправляет измерения загрузки доверенного платформенного модуля в службу аттестации работоспособности.
3. Служба аттестации работоспособности проверяет состояние устройства и выдает устройству зашифрованный BLOB-объект на основе состояния работоспособности с подробными сведениями о неудачных проверках (если таковые есть).
4. Пользователь входит в систему, а агент MDM связывается с сервером Intune/MDM.
5. Сервер MDM отправляет новые политики, если они доступны, и запрашивает состояние blob-объекта работоспособности и другое состояние инвентаризации.
6. Устройство отправляет ранее полученный большой двоичный объект аттестации работоспособности, а также значение другого инвентаризации состояния, запрошенное сервером Intune/MDM.
7. сервер Intune/MDM отправляет большой двоичный объект аттестации работоспособности в службу аттестации работоспособности для проверки.
8. Служба аттестации работоспособности проверяет работоспособность устройства, отправляющего большой двоичный объект аттестации работоспособности, и возвращает этот результат на сервер Intune/MDM.
9. сервер Intune/MDM оценивает соответствие на основе соответствия требованиям и запрошенного состояния инвентаризации или аттестации работоспособности с устройства.
10. сервер Intune/MDM обновляет состояние соответствия объекту устройства в Microsoft Entra ID.
11. Пользователь открывает приложение и пытается получить доступ к корпоративному управляемому ресурсу.
12. Доступ, ограниченный утверждением соответствия в Microsoft Entra ID.
13. Если устройство соответствует требованиям и пользователь авторизован, создается маркер доступа.
14. Пользователь может получить доступ к корпоративному управляемому ресурсу.

Дополнительные сведения о Microsoft Entra присоединении см. в техническом документе Microsoft Entra ID & Windows: Better Together for Work or School.

Управление условным доступом — это тема, которую многие организации и ИТ-специалисты могут не знать и должны. Различные атрибуты, описывающие пользователя, устройство, соответствие требованиям и контекст доступа, являются эффективными при использовании с подсистемой условного доступа. Управление условным доступом — это важный шаг, который помогает организациям защитить свою среду.

Выводы и сводка

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

• Поймите, что ни решение не является 100-процентным безопасным

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

• Использование аттестации работоспособности с решением MDM

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

• Использование Credential Guard

  Credential Guard — это функция, которая значительно помогает защитить учетные данные корпоративного домена от сквозных хэш-атак.

• Использование Device Guard

  Device Guard — это реальный шаг вперед в области безопасности и эффективный способ защиты от вредоносных программ. Функция Device Guard в Windows блокирует ненадежные приложения (приложения, не авторизованные вашей организацией).

• Политика подписи Device Guard

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

• Использование безопасности на основе виртуализации

  При наличии целостности кода в режиме ядра, защищенной безопасностью на основе виртуализации, правила целостности кода по-прежнему применяются, даже если уязвимость обеспечивает несанкционированный доступ к памяти в режиме ядра. Помните, что устройства Device Guard, на которых выполняется целостность кода ядра с безопасностью на основе виртуализации, должны иметь совместимые драйверы.

• Начало развертывания Device Guard в режиме аудита

  Развертывание политики Device Guard на целевых компьютерах и устройствах в режиме аудита. Отслеживайте журнал событий целостности кода, который указывает, что программа или драйвер были бы заблокированы, если Device Guard был настроен в режиме принудительного применения. Настройте правила Device Guard, пока не будет достигнут высокий уровень достоверности. После завершения этапа тестирования политику Device Guard можно переключить в режим принудительного применения.

• Создание изолированного эталонного компьютера при развертывании Device Guard

  Так как корпоративная сеть может содержать вредоносные программы, следует начать настройку эталонной среды, изолированной от main корпоративной сети. После этого можно создать политику целостности кода, включающую доверенные приложения, которые вы хотите запустить на защищенных устройствах.

• Использование AppLocker, когда это имеет смысл

  Хотя AppLocker не считается новой функцией Device Guard, он дополняет функциональные возможности Device Guard для некоторых сценариев, таких как возможность запретить определенное универсальное приложение Windows для определенного пользователя или группы пользователей.

• Блокировка встроенного ПО и конфигурации

  После установки Windows заблокируйте доступ к параметрам загрузки встроенного ПО. Эта блокировка не позволяет пользователю с физическим доступом изменять параметры UEFI, отключает безопасную загрузку или загружает другие операционные системы. Кроме того, чтобы защититься от попытки администратора отключить Device Guard, добавьте в текущую политику Device Guard правило, которое будет запрещать и блокировать выполнение средства C:\Windows\System32\SecConfig.efi .

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

Связанные темы

• Защита извлеченных учетных данных домена с помощью Credential Guard
• Руководство по развертыванию Device Guard
• Общие сведения о технологии доверенного платформенного модуля