Windows Hello uzņēmumiem (WHfB) Tā ir kļuvusi par galveno Microsoft identitātes stratēģijas sastāvdaļu uzņēmumiem: atvadāmies no tradicionālajām parolēm un sveicam autentifikācijas modeli, kas balstīts uz kriptogrāfiskām atslēgām, biometriju, PIN kodiem un uzticamām ierīcēm. Apvienojumā ar Microsoft pieteikšanās ID un vienreizējā pierakstīšanās (SSO)Tas ļauj lietotājiem piekļūt mākoņa un lokālajiem resursiem ar vienu žestu, vienlaikus saglabājot uzņēmuma līmeņa drošības kontroli.
Šajā rakstā mēs mierīgi, bet tieši apspriedīsim, Kā darbojas Windows Hello darbam autentifikācija, ja ir iesaistītas aparatūras atslēgas, TPM iespējotas ierīces un SSO scenāriji? Salīdzinot ar Microsoft Entra ID un Active Directory, mēs aplūkosim iekšējās fāzes (ierīču reģistrēšanu, nodrošināšanu, atslēgu sinhronizāciju, sertifikātus un autentifikāciju), PRT lomu SSO, to, kā tā integrējas ar Kerberos hibrīdvidē, un infrastruktūras prasības, lai viss darbotos nevainojami.
Windows Hello for Business vispārīgā arhitektūra un tās bezparoles modelis
Windows Hello uzņēmumiem nav tikai PIN koda ievadīšana vai sejas parādīšana. Lai pieteiktos, tā ir izkliedēta sistēma, kas apvieno lietotāja identitāti, ierīces identitāti un ar aparatūru aizsargātas kriptogrāfiskās atslēgas. Autentifikācija balstās uz publisku/privātu atslēgu pāri vai sertifikātiem, kas ir piesaistīti ierīcei (TPM) un tiek atbloķēti ar kaut ko, ko lietotājs zina (PIN kodu), vai kaut ko, kas viņš ir (biometriskie dati).
Lielā atšķirība salīdzinājumā ar klasiskajām parolēm Iemesls ir tāds, ka vairs nepastāv "koplietota noslēpuma" atslēga, kas pārvietojas pa tīklu vai tiek glabāta centralizēti: serveris (Microsoft Entra ID vai Active Directory) glabā tikai atslēgas publisko daļu, savukārt privātā daļa nekad nepamet ierīci. Kad lietotājs vēlas autentificēties, Windows paraksta vienreizēju autentifikāciju ar privāto atslēgu, un identitātes nodrošinātājs validē šo parakstu ar reģistrēto publisko atslēgu.
Šī pieeja padara WHfB izturīgu pret pikšķerēšanuPat ja uzbrucējs apmānītu lietotāju, lai tas ievadītu savu lietotājvārdu ļaunprātīgā vietnē, viņš nevarētu atkārtot autentifikāciju bez privātās atslēgas, kas saistīta ar ierīces TPM. Rezultāts ir divfaktoru autentifikācijas sistēma (atslēga + PIN/biometriskie dati), kas atbilst stingriem MFA kritērijiem, bet ar daudz vienmērīgāku lietotāja pieredzi un uzlabotu drošību. Windows 11.
WHfB integrējas ar Microsoft Entra ID un Active DirectoryTas ļauj izmantot dažādus izvietošanas modeļus: tikai mākonī, hibrīdu vai pilnībā lokālu. Turklāt to var izmantot līdzās viedkartēm un FIDO2 atslēgām, un, izvēloties uz sertifikātiem balstītus modeļus, tas pat var atkārtoti izmantot organizācijas esošo PKI.
Windows Hello for Business darbības fāzes
Lai pilnībā izprastu, kas notiek "zem pārsega"Vispraktiskākā pieeja ir sadalīt Windows Hello for Business dzīves ciklu vairākās saistītās fāzēs: ierīces reģistrēšana, nodrošināšana, atslēgu sinhronizācija (hibrīdrežīmā), sertifikātu reģistrācija (ja tāda tiek izmantota) un visbeidzot autentifikācija un vienreizēja pierakstīšanās (SSO).
1. Ierīces reģistrācija
Pirms WHfB akreditācijas datu izsniegšanas lietotājam, ierīcei ir jābūt savai identitātei.Šo procesu sauc par ierīces reģistrēšanu, un tas saista ierīci ar organizācijas identitātes pakalpojumu sniedzēju (IdP).
Atkarībā no izvietošanas veida mainās IdP un reģistrācijas pakalpojums.:
- Mākoņa vai hibrīda ieviešana: IdP ir Microsoft Enter ID. Ierīce reģistrējas pakalpojumā Ierīču reģistrācijas pakalpojums no Entra ID un kļūst par “Microsoft Entra savienotu ierīci” vai “Microsoft Entra savienotu hibrīdu”.
- Tīri lokālas ieviešanas: IdP ir AD FS, un ierīce ir reģistrēta uzņēmuma ierīču reģistrācijas pakalpojums kas atklāj AD FS.
Reģistrācijas rezultātā IdP piešķir ierīcei savu identitāti.Tas tiks izmantots turpmākajās lietotāju autentifikācijas apmaiņās un marķiera izgūšanā. Pastāv dažādi "kombināciju veidi" jeb pievienošanās stāvokļi (tikai pieteikšanās, hibrīds, klasisks domēnam pievienots + reģistrēts utt.), kas nosaka, kā ierīce darbojas jauktā vidē.
2. Windows Hello nodrošināšana uzņēmumiem
Nodrošināšanas fāze ir tad, kad ierīcē konkrētam lietotājam faktiski tiek izveidoti Hello akreditācijas dati.Šeit parādās galvenais jēdziens: Windows Hello konteiners, kas ir loģiska struktūra, kurā tiek glabāti visi "atslēgas materiāli", kas saistīti ar lietotāja identitātēm šajā datorā.
Tipiska iepirkumu plūsma ietver vairākus saistītus soļus:
- Lietotājs piesakās ar saviem tradicionālajiem akreditācijas datiem (parasti lietotājvārdu un paroli), un sistēma palaiž WHfB iestatīšanas procesu, pieprasot IdP (Microsoft Entra ID vai AD FS) daudzfaktoru autentifikāciju.
- Pēc sekmīgas MFA pabeigšanas, Lietotājam tiek lūgts definēt PIN kodu un, ja aparatūra to atļauj, reģistrēt biometriskos datus. (pēdas nospiedums, seja, varavīksnene).
- Kad PIN kods ir apstiprināts, Windows ierīcē izveido Windows Hello konteineru.
- A tiek ģenerēts publiskās un privātās autentifikācijas atslēgu pāris, saistīts ar TPM (ja tāds ir) vai, ja tāda nav, aizsargāts ar programmatūru.
- Privātā atslēga tiek glabāta lokāli un ir aizzīmogota TPM, to nevar eksportēt.
- Publiskā atslēga ir reģistrēta IdP un saistīta ar lietotāja kontu:
- Mākoņa vai hibrīdas vides scenārijos ierīces reģistrācijas pakalpojums to ieraksta Microsoft Entra ID lietotāja objektā.
- Lokālos scenārijos ar AD FS tas tiek glabāts pakalpojumā Active Directory.
Konteinera ietvaros katrs “aizsargs” (PIN, biometriskais žests utt.) uztur savu šifrētu autentifikācijas atslēgas kopiju.Ja ir pieejams TPM, PIN kods tiek izmantots kā entropija aizzīmogošanas darbībā; pretējā gadījumā materiāla šifrēšanai tiek atvasināta simetriska atslēga. Tas ļauj lietotājam atbloķēt vienu un to pašu atslēgu pāri ar dažādiem žestiem, neapdraudot drošību.
Papildus primārajai autentifikācijas atslēgai konteiners var ietvert arī citus elementus, piemēram, administratora atslēga PIN atiestatīšanas scenārijiem, blobi ar TPM sertifikātiem un, galvenokārt, dažāda veida lietotāja identifikatora atslēgas, kas tiek izmantotas konkrētiem protokoliem (WebAuthn/FIDO2, Entra ID, lietotāja sertifikāti VPN vai RDP utt.).
Autentifikācijas atslēgu un lietotāja identifikatora informācija
Windows Hello autentifikācijas atslēga vienmēr ir asimetrisks pāris. (publisks/privāts) ģenerēts reģistrācijas laikā. Katru reizi, kad tas ir jāizmanto, tas ir jāatbloķē ar PIN kodu vai biometriju. Ja lietotājs atiestata savu PIN kodu, tiek ģenerēts jauns autentifikācijas atslēgu pāris un viss materiāls, ko aizsargāja iepriekšējais pāris, tiek atkārtoti šifrēts.
Lietotāja identifikatora atslēgas var būt simetriskas vai asimetriskas.Atkarībā no IdP un scenārija. Mūsdienu biznesa vidē (Microsoft Entra ID, Active Directory, personīgie Microsoft konti) tie parasti ir arī asimetriski atslēgu pāri, kas tiek ģenerēti un glabāti ierīcē, un publiskā daļa ir reģistrēta pie identitātes pakalpojumu sniedzēja.
Lietotāja identifikatora atslēgu ģenerēšanai ir divi galvenie veidi. organizācijās:
- Saistīt tos ar Korporatīvā PKIlai atslēga būtu saistīta ar uzņēmuma sertifikācijas iestādes izsniegtu sertifikātu. Tas atvieglo pāreju no uz sertifikātiem balstītām infrastruktūrām (VPN, RDP ar lietotāju sertifikātiem utt.) uz WHfB.
- Ļaujiet tam būt tieši IdP (Entra ID vai AD FS) — tas, kas pārvalda atslēgu pāri. saistīts ar identitāti, samazinot PKI sarežģītību, ja tā nav būtiska.
Šīs atslēgas tiek izmantotas, lai pierādītu īpašumtiesības, parakstot nonces. vai autentifikācijas žetonus gan pret domēna kontrolleriem (Kerberos), gan pret tīmekļa pakalpojumiem, kas izmanto WebAuthn (FIDO2). Viena ierīce var mitināt vairākus FIDO akreditācijas datus, kas saistīti ar dažādām tīmekļa vietnēm vai lietojumprogrammām, un tie visi tiek pārvaldīti Windows Hello konteinerā.
Biometrisko datu lokāla glabāšana
Viens jautājums, kas bieži vien satrauc daudzus lietotājus un auditoriem, ir tas, kas notiek ar viņu biometriskajiem elementiem.Sistēmā Windows Hello for Business biometriskās veidnes Tie tiek glabāti tikai ierīcē, lokālā datubāzē, kurai Microsoft nepiekļūst un kura nav sinhronizēta ar mākoni.
Katrs biometriskais sensors uztur savu veidņu datubāzi (piemēram, C:\WINDOWS\System32\WinBioDatabase), šifrēti ar unikālu nejaušu atslēgu katrai datubāzei, aizsargāti ar AES CBC režīmā un ar SHA-256 hešēšanu. Pat ja uzbrucējs iegūtu šo datubāzi, viņš nevarētu rekonstruēt sejas vai pirkstu nospiedumu "neapstrādātus" attēlus; tie ir neatgriezeniski veidnes dati.
3. Atslēgu sinhronizācija hibrīdvidē
Hibrīda izvietojumos Microsoft Entra ID reģistrētajai publiskajai atslēgai ir jānonāk arī Active Directory. lai lietotājs varētu autentificēties bez paroles gan mākoņpakalpojumos, gan lokālajos resursos.
Šo procesu pārvalda Microsoft. Ievadiet Connect Sync., kas sinhronizē lietotāja publisko atslēgu no Enter ID uz atribūtu msDS-KeyCredentialLink lietotāja objekta Active Directory. Tādā veidā domēna kontrolleri var validēt uz atslēgām balstītas autentifikācijas (atslēgu uzticamības scenārijs) vai izmantot saistīto informāciju Kerberos mākoņa uzticamības modeļiem.
4. Sertifikātu reģistrācija (izmantojot uz sertifikātiem balstītu modeli)
Ja jūsu organizācijā jau ir ieviesta PKI sistēma un vēlaties to izmantot ar WHfBVarat arī izvēlēties uz sertifikātiem balstītu uzticamības modeli. Šajā gadījumā pēc atslēgas reģistrēšanas IdP klients ģenerē sertifikāta pieprasījumu un nosūta to sertifikātu izdevējai iestādei (CRA), kas parasti atrodas AD FS serverī.
Sertifikācijas sertifikācijas iestāde (CRA) apstiprina pieprasījumu un pārsūta to korporatīvajai sertificēšanas iestādei (CA).kas izsniedz lietotāja sertifikātu. Šis sertifikāts tiek glabāts Windows Hello konteinerā un tiks izmantots autentifikācijai lokālajos resursos, kuriem nepieciešami klienta sertifikāti (piemēram, Kerberos autentifikācija ar sertifikātiem vai IPsec VPN).
5. Autentifikācijas fāze: kā atslēga tiek “atbrīvota”
Kad iepriekšējās fāzes ir pabeigtas, lietotāja ikdienas pieredze ir ļoti vienkārša.Lai pieteiktos vai atbloķētu ierīci, izmantojiet PIN kodu vai biometriskos datus. Tehniski šis žests "atbloķē" piekļuvi jūsu WHfB akreditācijas datu privātajai daļai, kas tiek glabāta TPM.
Ne PIN kods, ne privātā atslēga neatstāj ierīci un netiek nosūtīti IdP.PIN darbojas kā entropija privātās atslēgas parakstīšanas operācijās; citiem vārdiem sakot, tas ir lokāls aktivizētājs, kas autorizē atslēgas izmantošanu. Kad lietojumprogrammai vai pašai sistēmai ir jāveic autentifikācija pret identitātes pakalpojumu sniedzēju (IdP), Windows paraksta datu bloku ar privāto atslēgu un nosūta parakstu serverim, kas pārbauda tā derīgumu, salīdzinot to ar reģistrēto publisko atslēgu.
Šis modelis tiek atkārtots gan tiešajai autentifikācijai, gan ID ievadīšanai. (izmantojot tīmekļa protokolus un mākoņa piekļuves punkta pakalpojumu sniedzēju) piemēram, Kerberos autentifikācijām pret Active Directory (izmantojot atslēgu, sertifikātu vai Kerberos uzticamību mākonī).
Primārā atsvaidzināšanas pilnvara (PRT) un vienreizējā pierakstīšanās (SSO)
Mūsdienu SSO Microsoft vidē pamatā ir primārā atjaunināšanas pilnvara jeb PRT.Lai gan klasiskajā Kerberos "galvenais marķieris" ir TGT, Entra ID scenārijos PRT ir JWT marķieris, kas satur lietotāja un ierīces informāciju un ļauj iegūt piekļuves marķierus dažādām lietojumprogrammām bez nepieciešamības lietotājam atkārtoti autentificēties.
PRT parasti tiek izstarots ierīces pieteikšanās vai atbloķēšanas laikā. Kad lietotājs autentificējas ar WHfB Microsoft Entra pievienotā vai Entra pievienotā hibrīddatorā. Tikai reģistrētām personīgajām ierīcēm PRT tiek iegūts, pievienojot darba vai mācību iestādes kontu sistēmai Windows.
Bez PRT nav īstas SSO lietojumprogrammām, ko aizsargā Entra ID vai AD FS.Ja kāda iemesla dēļ ierīcei nav derīga PRT, lietotājiem tiks atkārtoti pieprasīti akreditācijas dati, un nosacītās piekļuves politikas, kurām nepieciešama ierīces informācija (piemēram, "tikai ierīces, kas atzīmētas kā atbilstošas"), neizdosies.
Attālās piekļuves scenārijos ar VPN un SAML SSOKad lietotājs operētājsistēmā ir autentificējies ar WHfB, PRT ļauj Entra ID "atcerēties", ka pikšķerēšanas novēršanas MFA jau ir izpildīta. Tādēļ VPN pieteikšanās laikā, izmantojot SAML, Entra ID var atzīmēt sesiju kā atbilstošu MFA, nepieprasot otru autentifikācijas faktoru, kas bieži izraisa diskusijas ar apdrošinātājiem un auditoriem.
Microsoft pievienotās ierīces autentifikācijas plūsma: Ievadiet, lai ievadītu ID
Ierīcē, kas savienota ar Entra, notikumu ķēde WHfB pieteikšanās laikā Vienkāršoti sakot, tas ir šādi:
- Lietotājs aizver bloķēšanas ekrānu un ievada savu PIN kodu vai biometriskos datus WHfB akreditācijas datu sniedzējā.
- Winlogon nodod šos akreditācijas datus LSASS, kas savukārt tos nogādā mākoņa autentifikācijas drošības nodrošinātājam (Cloud AP).
- Mākoņa piekļuves punkts pieprasa pāvesta nuncijs Microsoft Enter ID; Enter ID atbild ar šo vērtību.
- Klients paraksta vienreizēju eksemplāru ar lietotāja privāto atslēgu un nosūta rezultātu uz Entra ID.
- Entra ID pārbauda parakstu ar iepriekš reģistrēto publisko atslēgu, un, ja viss ir pareizi, tas ģenerē PRT, kas ir šifrēts ar ierīces transporta atslēgu.
- Mākoņa piekļuves punkts atšifrē PRT sesijas atslēgu, izmantojot privāto transporta atslēgu (aizsargāta ar TPM), un saglabā PRT aizsargātā kešatmiņā.
- LSASS informē Winlogon, ka autentifikācija ir bijusi veiksmīga un ir izveidota lietotāja sesija.
No šī brīža PRT tiks izmantota piekļuves un jaunināšanas žetonu iegūšanai. dažādām lietojumprogrammām (Microsoft 365, trešo pušu SaaS, SAML lietojumprogrammām utt.), lietotājam neko atkārtoti neievadot, vienmēr ievērojot konfigurētās nosacītās piekļuves politikas.
Windows Hello darbam — autentifikācija salīdzinājumā ar Active Directory
Kad ierīce ir tikai “pievienota Entra”, bet tai ir nepieciešama piekļuve lokālajiem resursiemŠeit tiek izmantota integrācija ar Active Directory, izmantojot dažādus modeļus: Kerberos mākoņa uzticamību, atslēgu uzticamību un sertifikātu uzticamību. Visi šie modeļi ļauj WHfB akreditācijas datiem ģenerēt Kerberos biļetes, nepieprasot paroles.
Uzticieties Kerberos mākonī kopā ar Microsoft. Sāciet darbu.
Mākoņa Kerberos uzticamības modelīMicrosoft Entra ID izsniedz daļēju TGT, kas ir saistīts ar lietotāja identitāti un ko parakstījis Kerberos mākoņpakalpojums. Kad ierīcei ir nepieciešams pilns TGT no lokālā domēna kontrollera, tā nosūta šo daļējo TGT uz lokālo KDC, kas to validē un izsniedz lietotājam “īstu” TGT.
Šī pieeja ievērojami vienkāršo infrastruktūrujo tas deleģē daļu autentifikācijas loģikas Entra ID, bet prasa, lai domēna kontrolleri tiktu atjaunināti un pareizi konfigurēti, lai atpazītu un validētu šos daļējos TGT, kas nāk no mākoņa.
Galvenais uzticamības modelis
Atslēgas uzticamības modelī domēna kontrolieris tieši validē parakstu, kas izveidots ar lietotāja privāto atslēgu. reģistrēts pakalpojumā Active Directory. Augsta līmeņa plūsma ir šāda:
- Klienta Kerberos pakalpojumu sniedzējs paraksta iepriekšējas autentifikācijas datus ar privāto atslēgu un nosūta parakstu kopā ar publisko atslēgu (pašparakstītā sertifikātā) uz KDC.
- KDC pārbauda, vai sertifikāts ir pašparakstīts, atrodot šo publisko atslēgu atribūtā
msDS-KeyCredentialLinkno lietotāja un apstiprina parakstu. - Ja viss sakrīt (UPN, atslēgas, paraksts), KDC atgriež klientam TGT.
Pēc tam klients validē KDC sertifikātu. (ķēdē līdz uzticamības saknei, KDC autentifikācijas EKU, domēnam atbilstošam alternatīvajam nosaukumam, drošiem algoritmiem, piemēram, SHA-256 un RSA 2048 utt.) pirms TGT pieņemšanas un kešatmiņā saglabāšanas turpmākajiem pakalpojumu biļešu pieprasījumiem.
Sertifikātu uzticamība
Sertifikātu modelī lietotājs iesniedz KDC klienta sertifikātu, ko izdevusi organizācijas sertificēšanas iestāde (CA).Kerberos izmanto sertifikāta informāciju (subjekta DN vai UPN SAN) kā pavedienu, lai atrastu kontu pakalpojumā Active Directory.
Domēna kontrolieris validē sertifikātu ķēdi līdz uzticamības saknei.Tas pārbauda, vai sertifikāts ir derīgs un nav atsaukts, un izmanto sertifikāta publisko atslēgu, lai verificētu parakstītos iepriekšējas autentifikācijas datus. Ja viss ir pareizi, tas izsniedz TGT, ko klients akceptē pēc KDC sertifikāta verifikācijas.
Infrastruktūras prasības drošām hibrīdvidēm
Lai nodrošinātu, ka ierīce, kas pievienota Microsoft Entra, veiksmīgi autentificējas pakalpojumā Active Directory Tas ietver rūpīgas uzmanības pievēršanu korporatīvās PKI konfigurācijai, CRL izplatīšanas punktiem un domēna kontrollera sertifikātu uzticamībai.
Atsaukšanas saraksta izplatīšanas punkti (CDP/CRL)
Ļoti izplatīta kļūda ir CDP atstāšana tikai LDAP serverī domēna ietvaros.Ierīces, kas pievienotas Entra ID un nav daļa no domēna, nevar nolasīt šo LDAP ceļu pirms autentifikācijas, radot cilpu: tām ir jāapstiprina DC sertifikāts autentifikācijai, bet tās nevar nolasīt CRL bez autentifikācijas.
Ieteicamais risinājums ir publicēt CRL vietā, kas ir pieejama, izmantojot HTTP, bez autentifikācijas.Parasti šī ir iekšēja tīmekļa vietne, un šis URL tiek pievienots kā CDP sertifikācijas izdevēja un domēna kontrollera sertifikātiem. Process ietver:
- Konfigurējiet tīmekļa serveri (IIS) ar virtuālu direktoriju (piemēram,
cdp) un iespējojiet direktoriju pārlūkošanu. - Pielāgojiet NTFS un koplietošanas atļaujas, lai sertifikāts varētu automātiski publicēt CRL failus šajā direktorijā.
- Atjauniniet CA konfigurāciju, lai iekļautu jauno HTTP URL kā CDP un kā CRL un delta CRL publicēšanas atrašanās vietu.
- Atkārtoti izsniedziet domēna kontrollera sertifikātus, lai iekļautu jauno HTTP CDP.
Pēc šīm darbībām ierīces, kas pievienotas Entra, var validēt DC sertifikātu bez autentifikācijas.novēršot apļveida problēmu un ļaujot uz sertifikātiem vai atslēgām balstītai autentifikācijai darboties pareizi.
Domēna kontrollera sertifikāta prasības
Lai Windows Hello for Business ieviestu "stingru KDC validāciju" Veicot autentifikāciju no ierīces, kas pievienota Entra, domēna kontrollera sertifikātiem ir jāatbilst vairākiem kritērijiem:
- Izdevējai saknes sertificēšanas iestādei ir jāatrodas noliktavā uzticamas saknes sertifikācijas iestādes no ierīces.
- Sertifikātam jābūt balstītam uz Kerberos autentifikācijas veidne pietiekama.
- Tajā jāiekļauj EKU KDC autentifikācija.
- Subjekta alternatīvajam nosaukumam (SAN) ir jāietver DNS nosaukums, kas atbilst domēnam.
- Paraksta algoritmam ir jābūt SHA-256 un publiskajai atslēgai ir jābūt RSA vismaz 2048 biti.
Ja kaut kas no šī neizdodas, Entra pievienotās ierīces var noraidīt DC sertifikātu. Un autentifikācija ar WHfB uz Active Directory nedarbosies, lai gan ar klasiskajām parolēm viss šķietami darbojas labi.
CA saknes sertifikāta izplatīšana ierīcēs, kas savienotas ar Entra
Lai viņi uzticētos domēna kontrollera sertifikātiemIerīcēm, kas pievienotas pakalpojumam Microsoft Entra, jābūt instalētam uzņēmuma sertifikāta saknes sertifikātam. Šis sertifikāts parasti tiek eksportēts no domēna kontrollera un izvietots datoros, izmantojot Microsoft Intune ar "uzticama sertifikāta" politiku.
Direktīvai jānorāda uz komandas sertifikātu krātuvi (uzticamības sakni). un tiks piešķirti atbilstošajām lietotāju vai ierīču grupām. Pēc lietošanas sistēmas uzskatīs attiecīgās sertifikācijas iestādes izsniegtos sertifikātus, tostarp KDC sertifikātu, par “uzticamiem”, un stingro validāciju varēs veiksmīgi pabeigt.
Izvietošanas modeļi, izaicinājumi un labākā prakse
Windows Hello darbam atbalsta tikai mākonī, hibrīdos vai pilnībā lokālos izvietojumusun katram modelim ir atšķirīgas praktiskas sekas sarežģītības, saderības un izmaksu ziņā.
Mākoņpakalpojumos balstītās organizācijās bez lokālā Active DirectoryVienkāršākais risinājums ir tikai mākonī balstīts modelis, kurā visu atslēgu pārvaldību un autentifikāciju veic Microsoft Entra ID, neprasot lokālu PKI vai AD FS. Lietotāji piekļūst Microsoft 365 un SaaS lietojumprogrammām, izmantojot SSO un WHfB kā bezparoles autentifikatoru.
Vairumā vidējo un lielo uzņēmumu reālākais scenārijs joprojām ir hibrīdmodelis.Kritiski resursi paliek lokāli, pastāv tīras Kerberos lietojumprogrammas, un mākoņpakalpojumi tiek patērēti vienlaicīgi. Šeit ir jāpieņem lēmumi starp Kerberos mākoņa uzticēšanos, atslēgu uzticēšanos un sertifikātu uzticēšanos; ir jāizvērtē saderība ar mantotajām lietojumprogrammām; un daudzos gadījumos uz paroli vai viedkarti balstītas metodes ir jāturpina kādu laiku.
Stingri regulētās nozarēs vai nozarēs ar augstām datu suverenitātes prasībām (valdības, noteiktām finanšu vai veselības aprūpes iestādēm) pilnībā lokāls modelis ar AD FS un savu PKI varētu būt lietderīgs, kur WHfB tiek izmantots kā paroles aizstājējs, bet nepaļaujoties uz mākoņpakalpojumiem. Tomēr tas nozīmē lielāku darbības un uzturēšanas sarežģītību.
Visos gadījumos pastāv kopīgas problēmas: saderīga aparatūra, koplietotas darbstacijas, lietotāju pretestība izmaiņām un nepieciešamība apdrošinātājiem un auditoriem pamatot, ka mājas mājas pārvaldīšana (WhfB) faktiski tiek uzskatīta par MFA.Svarīgākais ir apvienot WHfB ar nosacītas piekļuves politikām, kas pieprasa pret pikšķerēšanu izturīgus autentifikatorus, iespējot atkārtotu autentifikāciju vai pastiprināt MFA, ja tas ir saprātīgi (piemēram, ļoti sensitīvās darbībās vai kritiskos VPN savienojumos), un rūpīgi dokumentēt apdraudējuma modeli.
To papildina laba apmācība, skaidras PIN politikas, pieteikšanās uzraudzība un pakāpeniska ieviešana, ko atbalsta Intune vai GPO.Windows Hello for Business ļauj organizācijām veikt kvalitatīvu lēcienu virzienā uz identitātes modeli bez paroles, samazinot uzbrukuma virsmu, uzlabojot atbilstību normatīvajiem aktiem un piedāvājot lietotājiem daudz dabiskāku un ātrāku pieteikšanās pieredzi.
