Принципы работы Windows Hello для бизнеса

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

Примечание.

Два из этих этапов требуются только для определенных сценариев развертывания.

Сценарии развертывания описаны в статье Планирование развертывания Windows Hello для бизнеса.

Значок, представляющий этап регистрации устройства.

Этап регистрации устройства

На этом этапе устройство регистрирует свое удостоверение в поставщике удостоверений (IdP), чтобы его можно было связать с поставщиком удостоверений и выполнить проверку подлинности с поставщиком удостоверений.

Значок, представляющий этап подготовки.

Этап подготовки

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

Значок, представляющий этап синхронизации.

Этап синхронизации ключей

На этом этапе, который требуется для некоторых гибридных развертываний, открытый ключ пользователя синхронизируется из Microsoft Entra ID в Active Directory.

Значок, представляющий этап регистрации сертификата.

Этап регистрации сертификатов

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

Значок, представляющий этап проверки подлинности.

Этап проверки подлинности

На последнем этапе пользователь может войти в Windows с помощью биометрии или ПИН-кода. Независимо от используемого жеста проверка подлинности выполняется с использованием частной части учетных данных Windows Hello для бизнеса. Поставщик удостоверений проверяет удостоверение пользователя, сопоставляя учетную запись пользователя с открытым ключом, зарегистрированным на этапе подготовки.

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

Регистрация устройств

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

  • Для облачных и гибридных развертываний поставщик удостоверений Microsoft Entra ID, а устройство регистрируется в службе регистрации устройств.
  • Для локальных развертываний поставщик удостоверений службы федерации Active Directory (AD FS) (AD FS), а устройство регистрируется в службе регистрации корпоративных устройств, размещенной в AD FS.

Когда устройство зарегистрировано, поставщик удостоверений предоставляет устройству удостоверение, которое используется для проверки подлинности устройства при входе пользователя.

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

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

Подготовка

Windows Hello подготовка активируется после завершения регистрации устройства и после того, как устройство получит политику, которая включает Windows Hello. Если выполнены все предварительные требования, запускается окно CXperience Host (CXH), чтобы провести пользователя через поток подготовки.

Снимок экрана: узел с облачным интерфейсом, предлагающий пользователю подготовить Windows Hello.

Примечание.

В зависимости от типа развертывания подготовка Windows Hello для бизнеса запускается только в следующих случаях:

  • Устройство соответствует требованиям к оборудованию Windows Hello
  • Устройство присоединено к Active Directory или Microsoft Entra ID
  • Пользователь входит с помощью учетной записи, определенной в Active Directory или Microsoft Entra ID
  • Политика Windows Hello для бизнеса включена
  • Пользователь не подключен к компьютеру через удаленный рабочий стол

Дополнительные предварительные требования для конкретных типов развертывания описаны в статье Планирование развертывания Windows Hello для бизнеса.

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

Примечание.

Физические контейнеры на диске, в реестре или в другом месте отсутствуют. Контейнеры являются логическими единицами, где группируются связанные элементы. Ключи, сертификаты и учетные данные, которые Windows Hello хранятся, защищены без создания фактических контейнеров или папок.

Ниже приведены шаги, связанные с этапом подготовки.

  1. В окне CXH пользователю предлагается пройти проверку подлинности в поставщике удостоверений с помощью MFA.
  2. После успешного выполнения MFA пользователь должен предоставить жест биография (если он доступен) и ПИН-код.
  3. После подтверждения ПИН-кода создается контейнер Windows Hello.
  4. Создается пара открытого и закрытого ключей. Пара ключей привязана к доверенному платформенным модулю (TPM), если он доступен, или в программном обеспечении.
  5. Закрытый ключ хранится локально и защищен TPM и не может быть экспортирован.
  6. Открытый ключ регистрируется в поставщике удостоверений, сопоставленный с учетной записью пользователя.
    1. Служба регистрации устройств записывает ключ в объект пользователя в Microsoft Entra ID
    2. Для локальных сценариев AD FS записывает ключ в Active Directory.

В следующем видео показано, как Windows Hello для бизнеса шаги регистрации после входа с помощью пароля:

Дополнительные сведения и подробные схемы последовательностей см. в статье о том, как работает подготовка.

сведения о контейнере Windows Hello

На этапе подготовки Windows Hello создает на устройстве новую пару открытого и закрытого ключей. TPM создает и защищает закрытый ключ. Если на устройстве нет доверенного платформенного модуля, закрытый ключ шифруется и сохраняется в программном обеспечении. Этот начальный ключ называется ключом предохранителя. Ключ защиты связан с одним жестом: если пользователь регистрирует ПИН-код, отпечаток пальца и лицо на одном устройстве, каждый из этих жестов имеет уникальный ключ защиты.

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

Схема контейнера Windows Hello.

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

Важно.

Ключи можно создавать в оборудовании (TPM 1.2 или 2.0) или программном обеспечении на основе настроенного параметра политики. Чтобы гарантировать, что ключи создаются на оборудовании, необходимо настроить параметр политики. Дополнительные сведения см. в разделе Использование аппаратного устройства безопасности.

Личные учетные записи (учетная запись Майкрософт) и рабочая или учебная (Active Directory или Microsoft Entra ID) используют один контейнер для ключей. Все ключи разделены по доменам поставщиков удостоверений в целях обеспечения конфиденциальности пользователя.

Windows Hello также создает административный ключ. Административный ключ можно использовать для сброса учетных данных при необходимости. Например, при использовании службы сброса ПИН-кода. В дополнение к защитному ключу на устройствах с поддержкой TPM создается блок данных, содержащих аттестации из TPM.

Доступ к материалу ключа, хранящемуся в контейнере, осуществляется только с помощью ПИН-кода или биометрического жеста. Двухфакторная проверка, которая выполняется во время подготовки, создает доверительное отношение между поставщиком удостоверений и пользователем. Это происходит, когда открытая часть пары открытого и закрытого ключей отправляется поставщику удостоверений и связана с учетной записью пользователя. Когда пользователь вводит жест на устройстве, поставщик удостоверений знает, что это проверенное удостоверение из-за сочетания Windows Hello клавиш и жестов. Затем он предоставляет маркер проверки подлинности, который позволяет Windows получать доступ к ресурсам и службам.

Контейнер может содержать несколько типов материалов ключей:

  • Ключ проверки подлинности, который всегда является асимметричной парой открытого и закрытого ключей. Эта пара ключей генерируется при регистрации. Он должен быть разблокирован при каждом доступе к нему с помощью ПИН-кода пользователя или биометрического жеста. Ключ проверки подлинности существует до тех пор, пока пользователь не сбросит ПИН-код, после чего создается новый ключ. При создании нового ключа все материалы ключа, которые ранее защищал старый ключ, должны быть расшифрованы и повторно зашифрованы с помощью нового ключа.
  • Один или несколько ключей идентификатора пользователя. Эти ключи могут быть симметричными или асимметричными в зависимости от используемого поставщика удостоверений. Для Windows Hello на основе сертификатов for Work, когда контейнер разблокирован, приложения, которым требуется доступ к ключу или паре ключей пользователя, могут запрашивать доступ. Ключи идентификатора пользователя используются для подписывания или шифрования запросов или маркеров проверки подлинности, отправляемых с этого устройства в поставщика удостоверений. Ключи идентификатора пользователя обычно являются длительными, но могут иметь более короткий срок существования, чем ключ проверки подлинности. Учетные записи Майкрософт, учетные записи Active Directory и Microsoft Entra учетные записи требуют использования асимметричных пар ключей. Устройство создает открытый и закрытый ключи, регистрирует открытый ключ в поставщике удостоверений (который сохраняет его для последующей проверки) и безопасно сохраняет закрытый ключ. Для organizatrons ключи идентификатора пользователя можно создать двумя способами:
    • Пара ключей идентификатора пользователя может быть связана с центром сертификации (ЦС) организации. Этот параметр позволяет организациям, у которых уже есть PKI, продолжать при необходимости использовать его. Учитывая, что во многих приложениях, таких как решения VPN, требуется использование сертификатов, при развертывании Windows Hello в этом режиме это позволяет быстрее переходить от паролей пользователей, сохраняя при этом функциональные возможности на основе сертификатов. Этот параметр также позволяет организации хранить другие сертификаты в защищенном контейнере. Например, сертификаты, позволяющие пользователю проходить проверку подлинности по протоколу RDP.
    • Поставщик удостоверений может создавать пару ключей идентификатора пользователя напрямую, что позволяет быстро и с меньшими затратами развертывать Windows Hello в средах, в которых нет или требуется PKI.

Ключи идентификатора пользователя используются для проверки подлинности пользователя в службе. Например, подписав nonce, чтобы доказать владение закрытым ключом, который соответствует зарегистрированным открытым ключом. У пользователей с active Directory, Microsoft Entra ID или учетной записью Майкрософт есть ключ, связанный с учетной записью. Ключ можно использовать для входа на устройство Windows путем проверки подлинности в контроллере домена (сценарий Active Directory) или в облаке (сценарии Microsoft Entra ID и MSA).

Windows Hello также можно использовать в качестве средства проверки подлинности FIDO2 для проверки подлинности на любом веб-сайте, поддерживающем WebAuthn. Веб-сайты или приложения могут создавать ключ идентификатора пользователя FIDO в контейнере Windows Hello пользователя с помощью API. При последующих посещениях пользователь может пройти проверку подлинности на веб-сайте или в приложении с помощью Windows Hello ПИН-кода или биометрического жеста.

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

Биометрическое хранилище данных

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

Каждый датчик имеет собственный файл биометрической базы данных, в котором хранятся данные шаблона (путь C:\WINDOWS\System32\WinBioDatabase). Каждый файл базы данных имеет уникальный случайный ключ, зашифрованный в системе. Данные шаблона для датчика шифруются с помощью ключа для каждой базы данных с помощью AES с режимом цепочки CBC. Хэш — SHA256.

Примечание.

Некоторые датчики отпечатков пальцев могут завершить сопоставление в модуле датчика отпечатков пальцев, а не в ОС. Эти датчики хранят биометрические данные в модуле отпечатков пальцев, а не в файле базы данных. Дополнительные сведения см. в разделе Windows Hello вход с усиленной безопасностью (ESS).

Синхронизация ключей

Синхронизация ключей требуется в гибридных средах. После того как пользователь подготовит учетные данные Windows Hello для бизнеса, ключ должен синхронизироваться из Microsoft Entra ID в Active Directory.

Открытый ключ пользователя записывается в msDS-KeyCredentialLink атрибут объекта пользователя в Active Directory. Синхронизация обрабатывается Microsoft Entra Connect Sync.

Регистрация сертификата

Для развертываний сертификатов после регистрации ключа клиент создает запрос на сертификат. Запрос отправляется в центр регистрации сертификатов (CRA). CRA находится на сервере службы федерации Active Directory (AD FS) (AD FS), который проверяет запрос на сертификат и выполняет его с помощью корпоративного PKI.

Сертификат регистрируется в контейнере Hello пользователя, который используется для проверки подлинности в локальных ресурсах.

Authentication

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

Проверка подлинности — это двухфакторная проверка подлинности с сочетанием:

  • Ключ или сертификат, привязанный к устройству и
    • то, что пользователь знает (ПИН-код) или
    • то, что человек (биометрия)

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

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

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

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

Важно.

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

Дополнительные сведения и подробные схемы последовательностей см. в статье Принцип работы проверки подлинности.

Основной маркер обновления

Единый вход (SSO) использует специальные маркеры, полученные для доступа к определенным приложениям. В традиционном случае встроенной проверки подлинности Windows с использованием Kerberos маркером является TGT Kerberos (билет на предоставление билета). Для приложений Microsoft Entra ID и AD FS этот маркер является основным маркером обновления (PRT). Это веб-токен JSON , содержащий утверждения о пользователе и устройстве.

PRT изначально получается во время входа или разблокировки аналогичным образом получается TGT Kerberos. Это верно как для Microsoft Entra присоединенных устройств, так и Microsoft Entra гибридных устройств. Для личных устройств, зарегистрированных с помощью Microsoft Entra ID, PRT изначально получается при добавлении рабочей или учебной учетной записи. Для личного устройства учетная запись для разблокировки устройства не является рабочей учетной записью, а учетной записью потребителя (учетная запись Майкрософт).

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

Совет

Ключ Windows Hello для бизнеса соответствует Microsoft Entra требованиям многофакторной проверки подлинности (MFA) и сокращает количество запросов MFA, которые пользователи увидят при доступе к ресурсам.

Дополнительные сведения см. в разделе Что такое основной маркер обновления.

изменение Windows Hello для бизнеса и паролей

Изменение пароля учетной записи пользователя не влияет на вход или разблокировку, так как Windows Hello для бизнеса использует ключ или сертификат.

Дальнейшие действия

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

Планирование развертывания Windows Hello для бизнеса