Windows Hello для бизнеса, аппаратные ключи и единый вход

Если вы управляете удостоверениями в средах Microsoft, вы, вероятно, слышали о Windows Hello, Windows Hello для бизнеса, ключи аппаратные средства и ССОНо легко запутаться среди множества аббревиатур, типов доверия и требований. Более того, в гибридных развертываниях с устаревшей службой Active Directory понимание того, что именно предлагает WHfB по сравнению с простым PIN-кодом или биометрическим входом, может стать решающим фактором между гладким проектом и постоянной головной болью.

В этой статье мы подробно объясним, как это работает. Windows Hello для бизнеса (WHfB), какую роль играют аппаратные ключи, как реализуется единый вход (SSO)? и чем он отличается от «обычного» Windows Hello для домашних пользователей. Мы рассмотрим внутренние этапы (регистрация устройств, подготовка, синхронизация ключей, сертификаты и аутентификация), модели развертывания (облачное, гибридное и локальное), типы доверия, требования PKI, лицензирование, реальные проблемы развертывания и то, как всё это сочетается с современными подходами, такими как FIDO2 и безопасность без паролей.

Windows Hello против Windows Hello для бизнеса: что действительно меняется

Windows Hello (простой и понятный) — это пользовательский интерфейс для входа в систему с помощью PIN-кода или биометрических данных. на устройстве Windows, разработанном как для домашней, так и для профессиональной среды. Windows Hello для бизнеса (WHfB), с другой стороны, — это корпоративное расширение, которое добавляет мощные возможности идентификации, интегрированные с Active Directory и Microsoft Entra ID.

С обоими методами вы можете использовать PIN-код, отпечаток пальца или распознавание лица, поддерживаемые ТРМ для входа в систему. Вы даже можете пройти аутентификацию в классическом локальном домене. Главное отличие в том, что WHfB создаёт и управляет криптографические учетные данные корпоративного уровняПары ключей или сертификаты, связанные с пользователем и устройством, управляемые политиками и используемые для единого входа на локальных и облачных ресурсах.

В то время как «обычный» Windows Hello по сути ограничен заменить пароль удобным жестом на этом устройствеWHfB генерирует надежные учетные данные, которые поставщик удостоверений (AD, Microsoft Entra ID или AD FS) распознает, хранит и использует для выдачи токенов доступа и обеспечения безопасности. Условный доступ, строгая проверка KDC, PRT, Kerberos в облаке и другие расширенные элементы управления.

Логичный вопрос: если у меня уже есть устройства, подключенные к домену, управляемые с помощью Intune, с TPM и биометрией, а также единый вход в облако через синхронизацию хэшей паролей, Что именно я получу, добавив WHfB? Ответ кроется в том, как создаются и проверяются ключи, как подключается устройство и в возможности распространить эту безопасность на всю экосистему, а не только на локальный вход в систему.

Базовая архитектура: этапы Windows Hello для бизнеса

WHfB — это распределенная система, состоящая из нескольких компонентов: устройство, TPM, поставщик удостоверений, PKI, синхронизация каталогов и механизмы единого входаЧтобы понять его и не запутаться, полезно разделить его действие на пять хронологических фаз внедрения.

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

Первая часть пазла – это регистрация устройства у поставщика удостоверений (IdP)Этот шаг позволяет связать устройство с идентификатором в каталоге и включить автоматическую аутентификацию при входе пользователя в систему.

В облачных или гибридных средах IdP — это Microsoft Enter ID и устройство регистрируется в своей службе регистрации устройств (присоединённой к Microsoft Entra, гибридной или зарегистрированной). В чисто локальных сценариях поставщик удостоверений обычно AD FS со службой регистрации корпоративных устройств.

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

2. Подготовка: создание контейнера Windows Hello

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

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

• Пользователь проходит аутентификацию с помощью MFA в IdP (Microsoft Enter MFA или другой совместимый метод, или адаптер MFA в AD FS в локальных средах).
• После преодоления этого второго фактора вам будет предложено настроить PIN-код и, если доступно совместимое оборудование, биометрический жест (отпечаток ноги, лицо, радужная оболочка глаза).
• После подтверждения PIN-кода Windows генерирует Контейнер Windows Hello для этого аккаунта в этой команде.
• Внутри этого контейнера находится Пара криптографических ключей (открытый и закрытый), связанный с TPM, если он существует, или, в случае его отсутствия, защищенный программным обеспечением.
• La Закрытый ключ остается на устройстве и не может быть экспортирован., оставаясь защищенным TPM и защитниками PIN-кода/биометрических данных.
• La открытый ключ зарегистрирован в IdP и он связан с объектом пользователя: в Microsoft Login ID он записывается для пользователя, а в федеративных локальных сценариях AD FS передает его в Active Directory.

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

3. Ключи внутри контейнера: аутентификация и идентификатор пользователя

В контейнере Windows Hello мы находим несколько типов ключей с разными ролями, все зашифровано с помощью PIN-кода или биометрической защиты:

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

Эти ключи идентификатора пользователя можно получить двумя основными способами: связанный с корпоративной PKI для выдачи сертификатов (например, для VPN, RDP или аутентификация Kerberos на основе сертификатов) или генерируется непосредственно IdP в сценариях без PKI (модель чистого ключа).

Та же инфраструктура позволяет использовать Windows Hello как аутентификатор FIDO2/WebAuthn в совместимых приложениях и веб-сайтах. Сайты могут создавать учётные данные FIDO в контейнере Windows Hello; при последующих посещениях пользователь проходит аутентификацию с помощью своего PIN-кода или биометрических данных, не раскрывая пароли.

4. Синхронизация ключей в гибридных средах

В гибридных архитектурах, где сосуществуют Идентификатор входа Microsoft и Active DirectoryПростой регистрации ключа в облаке недостаточно. После подготовки открытый ключ WHfB необходимо синхронизировать с локальным каталогом, чтобы включить аутентификация и единый вход в систему для локальных ресурсов.

В этих сценариях Microsoft Entra Connect Sync заботится о скопировать открытый ключ в атрибут msDS-KeyCredentialLink объекта пользователя в Active Directory. Эта синхронизация имеет ключевое значение для того, чтобы контроллер домена мог проверить подписи, сгенерированные устройством, с помощью закрытого ключа, хранящегося в TPM.

5. Регистрация сертификатов (только при необходимости)

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

После регистрации открытого ключа клиент генерирует запрос сертификата который отправляет запрос в центр регистрации сертификатов, обычно интегрированный в AD FS в федеративных развертываниях. Этот центр регистрации сертификатов проверяет запрос, используя корпоративную инфраструктуру открытых ключей (PKI) и Выдает сертификат, который хранится в контейнере Hello., который можно повторно использовать для аутентификации на локальных ресурсах, которые по-прежнему полагаются на сертификаты.

Аутентификация, закрытый ключ и единый вход: как все это сочетается

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

Когда пользователь разблокирует компьютер, Windows использует закрытую часть учетных данных WHfB для криптографически подписывать данные, отправленные в IdPПодпись проверяется с помощью открытого ключа, хранящегося в объекте пользователя. Поскольку PIN-код, как и закрытый ключ, никогда не покидает устройство, этот процесс устойчив к фишингу и традиционной краже учётных данных.

В сценариях Microsoft Enter ID завершение этой аутентификации приводит к Первичный токен обновления (PRT)Веб-токен JSON, содержащий информацию о пользователе и устройстве. Он является основой единого входа (SSO) в облачные приложения, а в сочетании с Microsoft Kerberos или синхронизацией ключей — также и в локальные ресурсы.

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

Для Active Directory при использовании доверия ключа или сертификата WHfB действует как виртуальная смарт-картаПользователь подписывает одноразовый код или вызов от KDC, контроллер домена проверяет сертификат или ключ и выдает билет Kerberos TGT, тем самым обеспечивая единый вход в локальные службы, интегрированные с Kerberos.

Внутренняя безопасность: биометрия, TPM и защита от атак

Одним из столпов WHfB является то, что Биометрические данные никогда не покидают устройствоШаблоны, созданные датчиками, хранятся локально в базы данных зашифровано (например, по пути C:\WINDOWS\System32\WinBioDatabase) с использованием уникальных ключей для каждой базы данных, защищено с помощью AES в режиме CBC и SHA-256 в качестве хэш-функции.

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

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

Столкнувшись с современными угрозами (Как определить, является ли электронное письмо фишинговым(повторное использование паролей, массовая кража учетных данных), WHfB полагается на Криптография с открытым ключом, связанная с устройствомЭто позволяет избежать раскрытия общих секретов. Это полностью соответствует стандартам и рекомендациям таких нормативных актов, как NIST 800-63B, а также моделям безопасности с нулевым доверием.

Модели развертывания: облачные, гибридные и локальные

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

Модель «только облако»

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

• Все пользователи и устройства находятся в Идентификатор Майкрософт Энтра.
• Регистрация устройств и ключей осуществляется непосредственно в облаке.
• Корпоративная PKI не требуется ни сертификаты контроллера домена.
• Единый вход основан на токенах PRT и Microsoft Entra для приложений.

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

Гибридная модель: наиболее распространенный случай

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

В гибридной среде удостоверения синхронизируются с помощью Microsoft Entra Connect Sync, и существует несколько возможных комбинаций модель развертывания (гибридная) и тип доверия (облачный Kerberos, ключ или сертификат)Целью обычно является предложение:

• SSO для облачных сервисов (SharePoint Онлайн, Teams, приложения OIDC/SAML).
• Прозрачный доступ к местным ресурсам (акции, Программы Kerberos, VPN, RDP).
• Поэтапный отказ от паролей с сохранением устаревших приложений.

Основными типами доверия в гибридных сценариях являются:

• Kerberos в облакеMicrosoft Entra Kerberos выпускает TGT для Active Directory без необходимости использования дополнительной инфраструктуры открытых ключей (PKI). Это самая современная и простая гибридная модель, поскольку она использует существующую инфраструктуру FIDO2 и не требует синхронизации открытых ключей с Active Directory.
• Ключевой трастПользователи аутентифицируются в Active Directory с помощью ключа, привязанного к устройству; контроллерам домена требуются специальные сертификаты. Инфраструктура открытых ключей (PKI) требуется для контроллеров домена, но не для сертификатов пользователей.
• Сертификат доверияСертификаты аутентификации пользователей выдаются и используются для получения TGT Kerberos. Для этого требуется полная инфраструктура PKI, AD FS в качестве CRA и более сложная настройка.

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

Чисто локальная модель

Организации со строгими нормативными ограничениями или с незначительным или нулевым внедрением облачных технологий могут выбрать развертывание WHfB. 100% локальный, поддерживается Active Directory и AD FSВ этой модели:

• Регистрация устройства управляется AD ФС.
• Аутентификация может быть основана на ключах или сертификатах, но она всегда подкреплена корпоративная PKI.
• Варианты MFA включают адаптеры для AD FS или решения, такие как Azure MFA Server (уже устаревший), интегрированные локально.

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

Доступные PKI, сертификаты контроллеров домена и списки отзыва сертификатов

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

На практике это означает, что сертификат контроллера домена должен соответствовать ряду технических условий: Выдан доверенным корневым центром сертификации (CA) для устройства на основе шаблона аутентификации Kerberos с EKU «KDC authentication», корректным именем DNS, RSA 2048 и SHA-256 в качестве алгоритма подписи, среди других требований.

Кроме того, важно, чтобы устройство могло проверить отзыв сертификатовВ этом и заключается классическая проблема с CRL: устройство, подключенное только к Microsoft Entra, не может читать пути LDAP в Active Directory, если оно еще не прошло аутентификацию, поэтому необходимо опубликовать точку распространения CRL в HTTP URL, доступный без аутентификации.

Это включает в себя подготовку веб-сервера (например, IIS), создание виртуального каталога (cdp) и настройку прав доступа. NTFS и из общих ресурсов, отключить хранение При автономном кэшировании настройте центр сертификации на публикацию списка отзыва сертификатов на этом общем ресурсе и его предоставление по HTTP. После этого вам необходимо Обновить сертификаты контроллера домена для включения нового CDP и обеспечения развертывания корпоративного корневого сертификата на устройствах, подключенных к Microsoft Entra (например, с помощью Intune и профиля «доверенного сертификата»).

Синхронизация каталогов, MFA и настройка устройств

Опыт конечного пользователя в использовании Windows Hello для бизнеса во многом зависит от Как интегрированы синхронизация каталогов, MFA и настройка политик.

В гибридных развертываниях Microsoft Entra Connect Sync не только синхронизирует учетные записи; он также может синхронизировать критические атрибуты, такие как msDS-KeyCredentialLinkкоторый содержит открытый ключ WHfB, необходимый для аутентификации в AD. В локальных средах с сервером Azure MFA синхронизация используется для импорта пользователей на сервер MFA, который затем отправляет запрос облачному сервису для проверки.

Что касается многофакторной аутентификации, у организаций есть несколько вариантов: Microsoft Entra MFA для облачных или гибридных сценариевВнешние методы, интегрированные через внешнюю аутентификацию в Entra ID или через федерацию, а также сторонние адаптеры MFA для AD FS в локальных средах. Флаг FederatedIdpMfaBehavior в федеративных доменах определяет, принимает ли Entra ID, требует или игнорирует MFA, выполняемую федеративным поставщиком удостоверений, что может иметь решающее значение для корректной работы WHfB.

Конфигурацию WHfB на оборудовании можно выполнить с помощью групповая политика (GPO) или CSP через MDM (например, Intune). В современных организациях принято включать автоматическую регистрацию WHfB, принудительно применять многофакторную аутентификацию (MFA) при первом входе в систему, определять политики сложности PIN-кода и контролировать, какие биометрические методы принимаются (только сертифицированные датчики, ИК-камеры и т. д.).

Параллельно с этим важно учитывать опыт восстановления: самостоятельный сброс PIN-кода, альтернативные методы, такие как ключи FIDO2 и Шифрование BitLocker для защиты хранящихся данных в случае утери или кражи устройства.

Лицензии, системные требования и практические ограничения

Один из распространенных мифов заключается в том, что всегда нужно использовать WHfB. Microsoft Enter ID P1 или P2На самом деле основные функции WHfB доступны на бесплатном уровне Entra ID, а многофакторная аутентификация, необходимая для предоставления доступа без пароля, может быть включена и без премиум-лицензий, хотя такие функции, как автоматическая регистрация MDM, расширенный условный доступ или отложенная запись на устройство, требуют более высоких уровней.

Что касается операционной системы, то практически все современные клиентские версии Windows поддерживают WHfB, но Доверие к Kerberos в облаке требует конкретных минимальных требований (например, Windows 10 21H2 с определенными исправлениями или определенными версиями Windows 11На стороне сервера любая поддерживаемая версия Windows Server может, как правило, выступать в качестве контроллера домена, хотя часть Kerberos в облаке требует определенных версий и обновлений на контроллерах домена.

Помимо технических аспектов, существуют и весьма практические проблемы: совместное использование оборудования, где WHfB, будучи специфичным для устройства и пользователя, регулярно подходит; оборудование без TPM 2.0 или биометрических датчиков; или среды, где стоимость обновления старого парка, развертывания PKI и модернизации центров обработки данных 2012 года делает полное внедрение WHfB непривлекательным в краткосрочной перспективе.

В случаях, когда разумный путь включает в себя объединить WHfB с другими факторами без пароля (ключи FIDO2, смарт-карты, телефонная аутентификация) для охвата общих рабочих станций, платформ, отличных от Windows, или высокомобильных пользователей, оставляя WHfB в качестве основного аутентификатора в портативный корпорации, связанные с Entra или гибридами.

Если взглянуть на общую картину, Windows Hello для бизнеса предлагает гораздо больше, чем просто «красивый PIN-код»: он представляет Асимметричные учетные данные, привязанные к оборудованию, строгая проверка KDC, глубокая интеграция с Microsoft Entra ID и Active Directory, а также надежная структура для безопасного единого входа (SSO) как в облаке, так и локально. Однако его реальная ценность по сравнению с базовым Windows Hello зависит от вашей отправной точки: в современных облачных или гибридных средах с обновлёнными PKI и DC скачок в безопасности и управлении явно перевешивает затраченные усилия; в очень старых доменах с недостаточно подготовленной инфраструктурой и отсутствием планов модернизации может быть разумнее сначала усовершенствовать оборудование, PKI и контроль доступа, прежде чем использовать весь потенциал WHfB.

Теме статьи:

Как узнать, какие приложения имеют доступ к вашей камере, микрофону или местоположению в Windows 11

Исаак

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