Entra ID: pregled poti obnovitve okoli MFA

Izgubljen telefon, nedosegljiv passkey ali skrbnik, ki ga po spremembi pravilnika Conditional Access zaklene iz lastnega okolja, niso samo helpdesk težave. Gre za dogodek identitetne varnosti. Vprašanje ni, ali ima organizacija MFA. Vprašanje je, ali lahko dostop povrne pravi osebi, ne da bi ustvarila lažjo pot za napadalca.

Microsoft Entra ID ima več poti za obnovitev ali dostop: samopostrežno ponastavitev gesla, obnovitev računa po izgubi vseh registriranih metod, začasne metode za uvajanje uporabnika, privilegirano skrbništvo in račune za nujni dostop. Te poti ne rešujejo iste težave. Če jih organizacija obravnava kot en sam »postopek ponastavitve MFA«, nastanejo slepe pege. Dober pregled preslika vsako pot, ki lahko spremeni metode avtentikacije, ponastavi poverilnice ali znova pridobi skrbništvo nad tenantom.

Začnite z odločitvijo o obnovitvi, ne z imenom kontrole

Samopostrežna ponastavitev gesla predpostavlja, da uporabnik še obvladuje vsaj eno registrirano metodo. Obnovitev računa je namenjena popolni izgubi registriranih metod in z dokazovanjem identitete ponovno vzpostavi zaupanje. Microsoft ti poti opisuje kot ločena scenarija z različnimi predpostavkami in obsegom. Microsoftov pregled obnovitve računa je zato dobro izhodišče, vendar sam po sebi ne dokazuje, da je dejanski postopek organizacije varen.

Pregled mora ločiti vsaj štiri dogodke:

Namen testa ni stalno ponastavljanje dostopa dejanskim uporabnikom. Uporabite dogovorjene testne račune, časovno okno sprememb in jasen načrt povrnitve. Test ustavite, če bi poseg spremenil produkcijski dostop nepovezane osebe, obšel dogovorjen varnostni pogoj ali ustvaril nezabeleženo privilegirano sejo.

Poiščite vsako pot za registracijo ali ponastavitev metode

Najpogostejša slabost ni manjkajoče potrditveno polje MFA. Gre za vrzel med želeno metodo in metodami, ki so v praksi še vedno dovoljene. Microsoft opozarja, da se lahko prekrivajo pravilnik metod avtentikacije, stare nastavitve MFA in stare nastavitve SSPR; uporabnik, ki je omogočen v katerem koli veljavnem pravilniku, lahko metodo registrira in uporabi. Za preprečitev uporabe mora biti metoda onemogočena povsod, kjer velja. Preglejte delovanje pravilnika metod avtentikacije, ne le najnovejše nastavitve v portalu.

Za vsako skupino uporabnikov dokumentirajte:

• katere metode je mogoče registrirati, uporabiti za prijavo in uporabiti za ponastavitev gesla;
• kdo lahko spreminja metode, ponastavlja gesla, izda Temporary Access Pass ali spremeni Conditional Access;
• ali ima podporno osebje ločen in zabeležen postopek preverjanja identitete;
• kateri dnevniki pokažejo registracijo, ponastavitev, spremembo vloge ali spremembo pravilnika; ter
• ali lahko privilegirani uporabnik uporabi šibkejšo metodo od metode, zahtevane pri običajni prijavi.

Authentication strengths lahko omejijo, katere metode zadostijo za dostop do zaščitenega vira ali registracijo varnostnih podatkov. Koristne so le, če so preverjeni ciljna skupina, izjeme in dejanska uporabniška izkušnja. Microsoftova navodila za authentication strengths pojasnjujejo povezavo; pregled pa mora dokazati, da nastavitev tenanta doseže želeni rezultat.

Nujni dostop mora biti dosegljiv in izjemen

Računi za nujni dostop niso običajni skrbniški računi z geslom, ki si ga nekdo zapomni. Namenjeni so ohranitvi upravljanja tenanta, ko odpovejo običajne identitetne odvisnosti. Microsoft priporoča vsaj dva računa, ki sta samo v oblaku, ter poverilnice in močno avtentikacijo, ki niso odvisne od istih oseb, naprav, federacije ali metod kot običajni skrbniški dostop. Navodila zahtevajo tudi nadzor, varno hrambo poverilnic in redno preverjanje. Glejte Microsoftova navodila za račune za nujni dostop.

Tu nastane potrebna napetost. Račun za nujni dostop, ki ga blokira Conditional Access, je lahko neuporaben ravno ob izpadu. Račun, ki je široko izvzet iz kontrol, vendar ga nihče ne nadzira, postane stalna visokovredna izjema. Rešitev ni odstranitev računa. Rešitev je dokumentirana izjema, ločena metoda, odporna proti phishingu, opozorilo ob vsaki uporabi, omejen krog pooblaščenih oseb in redna vaja.

Izvedite nadzorovano vajo pregleda

Dobra vaja ima štiri kratke faze.

1. Preslikava. Zapišite poti obnovitve, skrbnike, metode, odvisnosti storitev, pravilnike, podporne vloge in račune za nujni dostop. Vključite stare nastavitve in izjeme »break-glass«.
2. Dokaz. S testnimi identitetami preverite dovoljeno pot obnovitve in potrdite, da šibkejše ali neodobrene poti niso dostopne. Zajamite pomembne dokaze prijave, revizije in pravilnikov.
3. Odločitev. Pri vsaki vrzeli določite, ali gre za konflikt pravilnikov, preširoka dovoljenja, šibko dokazovanje identitete, nedokumentirano delo podpore ali manjkajoč nadzor.
4. Odprava in retest. Določite lastnika in rok, posodobite proces in konfiguracijo ter ponovite isti scenarij. Zaprt zahtevek ne dokazuje, da je pot obnovitve varna.

To je pregled identitetne odpornosti, ne poskus spreminjanja obnovitve računov v novo napadalno pot. V poročila ne vključujte občutljivih identifikatorjev tenanta, imen nujnih računov ali odgovorov za preverjanje pri helpdesku. Dokazila omejite na nujno potrebno in jih hranite kot drugo gradivo o privilegiranem dostopu.

Kako izgleda uporabna ugotovitev

»Vključite močnejši MFA« je redko dovolj. Uporabna ugotovitev navede prizadeto skupino, dosegljivo pot registracije ali obnovitve, zahtevani pogoj, realen vpliv, lastnika in korak preverjanja. Primer: stari pravilnik privilegirani skupini še vedno omogoča rezervno metodo, čeprav jo sodobni pravilnik izključuje; odprava uskladi vse pravilnike, preveri testni račun in ohrani nastale revizijske dokaze.

Enako razmišljanje uporabite pri privilegiranih identitetah. Varnost Active Directory preglejte skupaj z identiteto v oblaku, kadar hibridno skrbništvo ali federacija ustvarjata skupne odvisnosti. S kratkim varnostnim kontrolnim seznamom nato pretvorite rezultat v dodeljene naloge, ne v enkratno presojo.

Omejitve in naslednji korak

Ta članek ne nadomešča pravnih, kadrovskih, incidentnih ali pogodbenih zahtev organizacije za preverjanje identitete. Funkcionalnosti in licenciranje se lahko spremenijo, zato pred spremembo pravilnikov preverite natančno Microsoftovo dokumentacijo za svoj tenant. Naslednji korak je preprost: načrtujte nadzorovano vajo obnove za testnega uporabnika in ločeno urejeno preverjanje računa za nujni dostop, nato zapišite, kaj je dejansko delovalo.

Pogosta vprašanja

Ali je SSPR enak obnovitvi računa?

Ne. SSPR predpostavlja, da uporabnik še vedno obvladuje vsaj eno registrirano metodo. Obnovitev računa je namenjena popolni izgubi metod in z dokazovanjem identitete ponovno vzpostavi zaupanje.

Ali morajo biti nujni računi izvzeti iz Conditional Access?

Morda morajo biti izvzeti iz pravilnikov, ki bi dostop blokirali prav v scenariju izpada. Izjema potrebuje izravnalne kontrole: ločeno močno avtentikacijo, varno hrambo, opozorila, odobritev in redno testiranje.

Kako pogosto izvajati vajo z nujnim dostopom?

Microsoft priporoča redno preverjanje in najmanj vsakih 90 dni ter po pomembnih kadrovskih ali naročniških spremembah. Uporabite dogovorjen postopek testiranja in ohranite dokazila.