Pazaudēts VPN autentifikators: aizstāt, neizslēdzot MFA
Pazaudēts faktors ir atjaunošanas uzdevums, nevis dīkstāve. Pārbaudiet ārpus bojātā ceļa, reģistrējiet aizstājēju, atsauciet veco metodi un pēc tam pierādiet, ka pieteikšanās darbojas.
Kāds pazaudē tālruni, un biļete ierodas kā salauzts VPN. Šis ietvars ir nepareizs divreiz: konts joprojām pastāv, un vārteja joprojām uzticas identitātes nodrošinātājam, tāpēc vienīgā salauztā daļa ir viens faktors, kura cilvēkam vairs nav. Uztveriet to kā atjaunošanu, nevis dīkstāvi: pārbaudiet pieprasītāju, reģistrējiet aizstājēju, atsauciet pazaudēto metodi un pēc tam pierādiet, ka konts darbojas. Tas viss pieņem, ka plāns tika uzrakstīts pirms zaudējuma, jo tā izdomāšana zvana laikā ir ceļš, pa kuru MFA galu galā tiek izslēgts visiem.
1. solis: lasiet reģistrētos faktorus no ieraksta, nevis no atmiņas
Pirmais jautājums nav par to, kura ierīce pazuda, bet par to, ko konts vēl var izmantot. Kontam var būt parole ar push, laika kods, aparatūras atslēga un izdrukāti atjaunošanas kodi, un viena no tiem pazaudēšana ir pavisam cits notikums nekā vienīgā pazaudēšana. Lasiet metožu sarakstu no identitātes sistēmas, nevis lūdziet lietotājam to atcerēties, un Microsoft Entra nomniekā vaicājums ir viena rinda:
Get-MgUserAuthenticationMethod -UserId [email protected]
Pēc tam uzrakstiet atjaunošanas ierakstu, kamēr konts vēl darbojas: konta identifikators, reģistrētie faktori, kur dzīvo atjaunošanas kodi, kas var neatkarīgi pārbaudīt pieprasītāju un kuras sistēmas konts sasniedz. Glabājiet to aizsargātajā inventārā, ko komanda jau izmanto, nekad piezīmē, kurā ir arī aktīvi kodi. Šie pieci lauki panikas zvanu pārvērš kontrolsarakstā, un NIST autentifikatora dzīves cikla vadlīnijas atjaunošanu uzskata par akreditācijas daļu, nevis izņēmumu.
Reģistrējiet pārbaudes kanālu kā atsevišķu lauku, jo tieši šo daļu cilvēki izlaiž. Kontam piesaistīts tālruņa numurs nav neatkarīgs kanāls, ja pieprasītājs pats kontrolē tālruni.
2. solis: pārbaudiet pieprasītāju ārpus bojātā ceļa
Veiciet identitātes pārbaudi kanālā, kas nav atkarīgs no VPN, pastkastes vai pazaudētās ierīces. Atzvanīšana uz numuru no personāla ieraksta vai klātienes pārbaude pie vadītāja, kurš jau ir direktorijā, darbojas abi; čata ziņa, kas nosūtīta no atjaunojamā konta, nedarbojas. Pārbaude attiecas uz cilvēku, nevis uz viņa spēju atbildēt uz jautājumiem par kontu, jo konta detaļas noplūst. Reģistrējiet, kas pārbaudīja pieprasījumu un kad, jo nākamajam pārskatītājam vajadzēs abus.
Kad pieprasījums nāk ar steigu un spiedienu izlaist pārbaudi, tas ir brīdis palēnināties. Atjaunošanas krāpšana izskatās tieši kā steidzīgs izpalīdzīgs kolēģis.
3. solis: reģistrējiet aizstājēju un pēc tam atsauciet veco faktoru
Reģistrējiet jauno autentifikatoru parastajā reģistrācijas plūsmā, nekad ar administratīvu apiešanu. Pēc tam skaidri noņemiet pazaudēto metodi, jo aizstājēja reģistrācija atstāj iepriekšējo autentifikatoru pilnvarotu, līdz kāds to atsauc. Ja vecā ierīce var būt cita cilvēka rokās, uzskatiet noņemšanu par steidzamu un sekojiet incidenta procesam, nevis atjaunošanas. Atsauciet esošās sesijas tajā pašā solī, jo sesija, kas izveidota pirms izmaiņām, var tās pārdzīvot:
Revoke-MgUserSignInSession -UserId [email protected]
Faktora noņemšana visiem pārējiem vai vārtejas sertifikātu pārbaužu mīkstināšana apmaina viena cilvēka atjaunošanu pret dīkstāvi, kas skar visu izvietojumu. Turiet izmaiņas vienā kontā un eskalējiet, ja pierādījumi norāda uz plašāku kompromisu. Biļetē atzīmējiet, kurš faktors tika atsaukts un kurš to aizstāja.
4. solis: pierādiet, ka konts darbojas abos virzienos
Piesakieties vienreiz ar jauno faktoru atbalstītā klientā, pēc tam apstipriniet, ka konts joprojām sasniedz resursus, kurus tas sasniedza pirms zaudējuma. Pārbaudiet vienu resursu, kam vajadzīgs tunelis, un vienu, kam nav, lai kļūme norādītu uz pareizo slāni. Mēģiniet pieteikties ar atsaukto faktoru un gaidiet atteikumu, nevis uzvedni, kas pierāda, ka noņemšana ir stājusies spēkā. Izaicinājums, kas neizdodas no esošas reģistrētas ierīces ir uzvednes problēma, nevis iemesls visu reģistrēt no jauna.
Pēc tam lūdziet lietotājam pabeigt to pašu pieteikšanos bez norādēm. Jūsu veiksmīgais tests pierāda konfigurāciju; viņa mēģinājums pierāda nodošanu.
Aizveriet biļeti ar veiksmīgās pieteikšanās laika zīmogu un tagad izmantotā faktora nosaukumu. Atjauniniet atjaunošanas ierakstu tajā pašā solī, lai nākamais zaudējums sāktos no precīza inventāra, nevis novecojuša.
5. solis: noņemiet nosacījumu, kas padarīja to sāpīgu
Ikviens atjaunošanas zvans ir pierādījums par reģistrācijas dizainu. Ja kontam bija tieši viens faktors, pieprasiet otru visiem šajā grupā. Ja atjaunošanas kodi bija pazaudētajā klēpjdatorā, mainiet, kur tie dzīvo. Ja pārbaudei vajadzēja atvaļinājumā esošu vadītāju, ieceliet aizstājēju. Katrs labojums aizņem pēcpusdienu un novērš nākamā incidenta sliktāko stundu.
Pēc tam vēlreiz izlasiet pirmā soļa ierakstu pret realitāti. Vai tas uzskaita faktorus, kas patiešām pastāv, un vai pārbaudes kanāls joprojām sasniedz cilvēku? Rokasgrāmata, ko neviens neatjaunina, pārvēršas dokumentā, ko cilvēki ignorē zvana laikā, kuram tā tika uzrakstīta.