Windows Hello за бизнеса, хардуерни ключове и SSO

Ако управлявате самоличности в среди на Microsoft, вероятно сте чували за Windows Hello, Windows Hello за бизнеса, клавиши железария и SSOНо е лесно да се изгубите сред толкова много акроними, типове доверие и изисквания. Освен това, при хибридни внедрявания със стари Active Directory, разбирането какво наистина предлага WHfB в сравнение с обикновен ПИН или биометрично влизане може да бъде разликата между гладък проект... или постоянно главоболие.

В тази статия ще разгледаме подробно как работи Windows Hello за бизнеса (WHfB), каква роля играят хардуерните ключове, как се постига еднократно влизане (SSO)? и как се различава от „нормалния“ Windows Hello за домашни потребители. Ще разгледаме вътрешните фази (регистрация на устройства, осигуряване, синхронизация на ключове, сертификати и удостоверяване), моделите на внедряване (само в облак, хибридни и локални), типовете доверие, изискванията за PKI, лицензирането, предизвикателствата при внедряването в реалния свят и как всичко това се вписва в съвременни подходи като FIDO2 и сигурност без парола.

Windows Hello срещу Windows Hello за бизнеса: Какво наистина се променя

Windows Hello (обикновено и просто) е потребителското изживяване за влизане с ПИН или биометрични данни на устройство с Windows, предназначено както за домашна, така и за професионална среда. Windows Hello for Business (WHfB), от друга страна, е разширението за предприятия, което добавя силни възможности за идентификация, интегрирани с Active Directory и Microsoft Entra ID.

И с двата метода можете да използвате Поддържа се ПИН, пръстов отпечатък или разпознаване на лице TPM за да влезете в компютъра. Можете дори да се удостоверите срещу класически локален домейн. Голямата разлика е, че WHfB създава и управлява криптографски идентификационни данни на корпоративно нивоДвойки ключове или сертификати, свързани с потребителя и устройството, управлявани от политики и използваеми за SSO върху локални и облачни ресурси.

Докато „нормалният“ Windows Hello е по същество ограничен до заменете паролата с удобен жест на това устройствоWHfB генерира надеждни идентификационни данни, които доставчикът на самоличност (AD, Microsoft Entra ID или AD FS) разпознава, съхранява и използва за издаване на токени за достъп и прилагане на сигурност. Условен достъп, стриктна KDC валидация, PRT, Kerberos в облака и други разширени контроли.

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

Основна архитектура: фази на Windows Hello за бизнеса

WHfB е разпределена система, която разчита на няколко компонента: устройство, TPM, доставчик на идентичност, PKI, синхронизация на директории и механизми за SSOЗа да го разберем, без да се изгубим, е полезно да разделим действието му на пет хронологични фази на внедряване.

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

Първото парче от пъзела е регистрация на устройството при доставчика на самоличност (IdP)Тази стъпка ви позволява да свържете устройството с идентичност в директорията и да му разрешите автоматично удостоверяване, когато потребител влезе в системата.

В облачни или хибридни среди, IdP е Microsoft Enter ID и устройството се регистрира в услугата си за регистрация на устройства (присъединено към Microsoft Entra, хибридно присъединено или регистрирано). В чисто локални сценарии, IdP обикновено е AD FS с неговата услуга за регистрация на корпоративни устройства.

След завършване на тази регистрация, IdP назначава екипа уникална идентификация, която ще се използва за установяване на доверие между устройството и директорията при последователни удостоверявания. Този запис се класифицира по „тип на присъединяване на устройството“, който определя дали устройството е присъединено към локален домейн, към Entra ID, хибридно или просто регистрирано като лично.

2. Осигуряване: създаване на контейнера Windows Hello

След като устройството е регистрирано, започва фазата Предоставяне на идентификационни данни за Windows Hello за фирмиТук се създава така нареченият контейнер Windows Hello, който логически групира целия криптографски материал на потребителя на този компютър.

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

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

Контейнерът включва също така административен ключТова е полезно за сценарии като нулиране на ПИН; на устройства с TPM се съхранява и блок от данни, съдържащ TPM сертификати. Всички материали се отключват само когато потребителят извърши жеста (ПИН или биометрични данни), и тази първоначална MFA комбинация установява доверие между потребителя, устройството и IdP.

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

В контейнера на Windows Hello откриваме няколко вида клавиши с различни роли, всички криптирана с ПИН-базирана или биометрична защита:

• Ключ за удостоверяванеДвойка асиметрични ключове, генерирани по време на регистрация, които винаги трябва да се отключват с ПИН или биометричен жест. Това е основата, върху която се рециклират други материали при промяна на ПИН кода.
• Ключове за идентификация на потребителяКлючовете за идентичност могат да бъдат симетрични или асиметрични в зависимост от доставчика на идентичност (IdP) и модела (ключ или сертификат). Те се използват за подписване или криптиране на заявки и токени, насочени към доставчика на идентичност. В корпоративни среди те обикновено се генерират като асиметрични двойки ключове, като публичният ключ е регистриран при IdP.

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

Същата инфраструктура позволява използването на Windows Hello като FIDO2/WebAuthn удостоверител в съвместими приложения и уебсайтове. Сайтовете могат да създават FIDO идентификационни данни в контейнера на Windows Hello; при последващи посещения потребителят се удостоверява с ПИН код или биометрични данни, без да разкрива пароли.

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

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

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

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

В някои модели (като например доверие на сертификатаВ допълнение към ключовете, организацията трябва да издаде сертификати за удостоверяване на потребителите. В този случай се активира допълнителна фаза. регистрация на сертификати.

След регистриране на публичния ключ, клиентът генерира заявка за сертификат който изпраща заявката до органа за регистрация на сертификати, обикновено интегриран в AD FS във федеративни внедрявания. Този CRA валидира заявката, използвайки корпоративната PKI и Издава сертификат, който се съхранява в контейнера Hello., използваеми многократно за удостоверяване на локални ресурси, които все още разчитат на сертификати.

Удостоверяване, частен ключ и SSO: как всичко се вписва заедно

След като фазите на регистрация и осигуряване са завършени, ежедневието на потребителя се свежда до нещо много просто: жест (ПИН или биометрия), който „освобождава“ частния ключ на устройствотоИнтересното е какво се случва зад кулисите.

Когато потребителят отключи компютъра, Windows използва поверителната част от идентификационните данни на WHfB, за да криптографски подписва данни, изпратени до IdPТова проверява подписа, използвайки публичния ключ, съхранен в потребителския обект. Тъй като ПИН кодът никога не напуска устройството, както и частният ключ, процесът е устойчив на фишинг и традиционна кражба на идентификационни данни.

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

Без PRT, дори ако потребителят има валиден WHfB сертификат, Бих загубил еднократното влизане. и ще бъде принуден да удостоверява автентичността си непрекъснато във всяко приложение. Ето защо политиките за условен достъп, независимо дали са базирани на устройство или на риск, обикновено отчитат наличието и валидността на този PRT.

За Active Directory, когато се използва доверие на ключ или сертификат, WHfB действа като виртуална смарт картаПотребителят подписва еднократен код или предизвикателство от KDC, домейн контролерът валидира сертификата или ключа и издава Kerberos TGT билет, като по този начин активира SSO към локални услуги, интегрирани с Kerberos.

Вътрешна сигурност: биометрия, TPM и защита срещу атаки

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

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

ПИН кодът за Windows Hello for Business е по-добре защитен от традиционната парола. Той не се разпространява по мрежата, валидира се локално и TPM модулът прилага мерките за сигурност. блокове поради твърде много неправилни опитиТова прави грубата сила или речниковите атаки безполезни. И ако някой открадне ПИН кода, това ще работи само на това конкретно устройство, тъй като идентификационните данни са обвързани с хардуера.

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

Модели на внедряване: облачни, хибридни и локални

WHfB е гъвкав по отношение на топологията, но тази гъвкавост носи със себе си известна сложност. Най-общо казано, можем да говорим за три модела на внедряване, които се комбинират по различни начини. Microsoft Entra ID, Active Directory, PKI и федерация.

Модел само за облак

В организации, които живеят почти 100% в Microsoft 365 и други SaaS услуги, без съответната локална инфраструктура, най-простият модел е този на Само в облака с устройства, свързани с Microsoft. ВходВ този сценарий:

• Всички потребители и устройства се намират в Microsoft Access ID.
• Регистрацията на устройства и ключове се извършва директно в облака.
• Не е необходима корпоративна PKI нито сертификати за домейн контролер.
• SSO е базирано на PRT и Microsoft Entra токени за приложения.

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

Хибриден модел: най-често срещаният случай

По-голямата част от компаниите са някъде по средата: Исторически данни в Active Directory, комбинирани със синхронизирани идентификатори за вход в MicrosoftWHfB блести тук, но това е и мястото, където проблемите с конфигурацията са най-често срещани, ако не са добре планирани.

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

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

Основните видове доверие в хибридните сценарии са:

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

Изборът на правилния вид доверие е от решаващо значение: никой по своята същност не е „по-безопасен“Те обаче се различават по цена, сложност и изисквания към инфраструктурата. Разчитането на Kerberos в облака често е най-добрият вариант за нови внедрявания, при условие че клиентските и сървърните версии на Windows отговарят на минималните изисквания.

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

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

• Регистрацията на устройството се управлява AD FS.
• Удостоверяването може да бъде базирано на ключ или сертификат, но винаги е подкрепено от корпоративна PKI.
• Опциите за MFA включват адаптери за AD FS или решения като Azure MFA Server (вече наследен), интегриран локално.

Този подход дава пълен контрол върху данните за удостоверяванеТова обаче изисква значителни усилия за поддръжка (PKI, AD FS, публикуване на CRL, достъпни за компютри, които не са присъединени към домейн, и др.), нещо, което не всички организации са склонни да поемат в дългосрочен план.

Достъпна PKI, сертификати за домейн контролер и CRL

В модели, които разчитат на сертификати (независимо дали за потребители, домейн контролери или и двете), 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 и от споделени ресурси, деактивирайте съхранение При офлайн кеширане конфигурирайте CA да публикува CRL на този споделен ресурс и да го изложи чрез HTTP. След като сте готови, трябва Подновяване на сертификати за домейн контролер да се включи новият CDP и да се гарантира, че коренният сертификат на предприятието е разположен на устройства, свързани с Microsoft Entra (напр. с Intune и профил за „доверен сертификат“).

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

Практическата работа на крайния потребител с Windows Hello for Business зависи до голяма степен от Как са интегрирани синхронизирането на директории, MFA и конфигурирането на правила.

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

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

Конфигурацията на WHfB на оборудването може да се извърши с групови правила (GPO) или CSP чрез MDM (например Intune). В съвременните организации е обичайно да се активира автоматична регистрация на WHfB, да се наложи MFA при първото влизане, да се дефинират политики за сложност на ПИН кода и да се контролира кои биометрични методи се приемат (само сертифицирани сензори, IR камери и др.).

Успоредно с това е важно да се вземе предвид и опитът от възстановяването: самостоятелно нулиране на ПИН кода, алтернативни методи като 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 за бизнеса предлага много повече от „хубав ПИН код“: той въвежда хардуерно обвързани асиметрични идентификационни данни, стриктна KDC проверка, дълбока интеграция с Microsoft Entra ID и Active Directory и надеждна рамка за защитено SSO както в облака, така и локално. Реалната му стойност в сравнение с основния Windows Hello обаче зависи от вашата отправна точка: в съвременни облачни или хибридни среди с актуализирана PKI и DC, скокът в сигурността и управлението очевидно надвишава усилията; в много стари домейни, с малко подготвена инфраструктура и без планове за модернизация, може да е по-разумно първо да се усъвършенства хардуерът, PKI и контролът на достъпа, преди да се използва пълният потенциал на WHfB.

Свързана статия:

Как да разберете кои приложения имат достъп до вашата камера, микрофон или местоположение в Windows 11

Isaac

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