Administratorius nebegali prisijungti prie „Microsoft 365“. Ar įmonė turi atsarginį prieigos planą?

Paštas veikia, bet niekas negali jo administruoti

Įsivaizduokime situaciją: įmonės administratorius išvykęs, o jo telefonas su autentifikavimo programa sugenda. Tuo metu reikia skubiai užblokuoti įtartiną paskyrą. Darbuotojai gali toliau naudotis paslaugomis, tačiau žmogus, turintis reikiamas teises, nebegali patvirtinti prisijungimo. Tai iliustracinis pavyzdys, o ne konkretaus kliento incidentas.

Verslui svarbus labai konkretus klausimas: kas šiandien galėtų atkurti administravimą ir kokiomis priemonėmis? Atsakymas „paskambinsime mūsų IT žmogui“ nepaaiškina, ką daryti, jeigu būtent jo prieiga ir neveikia.

Ką rekomenduoja „Microsoft“?

„Microsoft“ rekomenduoja bent dvi avarinės prieigos, dar vadinamos „break-glass“, paskyras. Jos kuriamos tik debesijoje, naudojant organizacijos onmicrosoft.com domeną, be priklausomybės nuo vietinio katalogo sinchronizavimo ar federacijos. Šios paskyros skirtos išimtinėms situacijoms, kai įprastas administravimas nepasiekiamas.

Rekomenduojamas sukčiavimui atsparus autentifikavimas, pavyzdžiui, FIDO2 saugos raktas, su kitokiomis priklausomybėmis nei kasdienės administratoriaus paskyros. Avarinėms paskyroms suteikiamas „Global Administrator“ vaidmuo; naudojant PIM jis turi būti nuolat aktyvus, kad nereikėtų neveikiančio aktyvavimo ar tvirtinimo proceso.

Gairėse taip pat numatytas saugus prisijungimo priemonių laikymas atskirose vietose, paskirtos saugios darbo vietos naudojimas, prisijungimų ir veiksmų stebėjimas bei funkcionalumo patikra bent kas 90 dienų. Oficialios avarinės prieigos gairės.

Kaip prieigos taisyklės gali užrakinti ir administratorių?

„Conditional Access“ leidžia nustatyti prisijungimo sąlygas pagal naudotoją, įrenginį ar kitus signalus. Netinkamai pritaikyta taisyklė gali užblokuoti teisėtą prieigą. „Microsoft“ numato avarinių paskyrų išimtis iš prisijungimą blokuojančių ar ribojančių politikų ir rekomenduoja prieš įjungiant taisykles įvertinti jų poveikį. „Report-only“ režimas padeda stebėti rezultatą nepritaikant blokavimo. „Conditional Access“ diegimo planavimas.

Išimtis iš tokios politikos nereiškia, kad pakanka slaptažodžio. Avarinei prieigai vis tiek reikia stipraus autentifikavimo. Konkretus sprendimas derinamas su organizacijos nustatymais, turimomis licencijomis ir naudojamais prisijungimo metodais.

INsec siūlomas pasirengimo lapas

Techninę konfigūraciją siūlome papildyti trumpu, įmonėje suderintu veiksmų planu. Jį turėtų suprasti ir pavaduojantis specialistas, kuriam nereikėtų spėlioti, ką turėjo omenyje pirminis administratorius.

• Sprendimo teisė. Įvardyti, kas gali pradėti avarinį atkūrimą ir kokios aplinkybės tai pateisina. Atskirti techninio vykdytojo ir veiksmus peržiūrinčio asmens atsakomybes.
• Priemonių pasiekiamumas. Aprašyti, kaip įgaliotas pavaduotojas gaus reikiamas priemones, jeigu pagrindinis atsakingas žmogus atostogauja ar nepasiekiamas.
• Nepriklausoma instrukcija. Pasirūpinti, kad vienintelė atkūrimo aprašo kopija nebūtų sistemoje, prie kurios būtent ir nepavyksta prisijungti. Pačioje instrukcijoje neskelbti prisijungimo paslapčių.
• Ryšio kanalas. Iš anksto sutarti, kaip žmonės susisieks, jeigu įmonės paštas ar „Teams“ bus nepasiekiami.
• Veiksmų ribos. Numatyti, kad atliekami tik prieigai atkurti reikalingi pakeitimai. Platesnius pertvarkymus planuoti atskirai.

Bandymas turi baigtis aiškiu rezultatu

Praktiniam bandymui siūlome iš anksto paskirti laiką ir atsakingus žmones. Nereikia tyčia užblokuoti visų administratorių, kad patikrintumėte atsarginį kelią. Užduotis – patvirtinti, kad įgaliotas žmogus pagal turimą instrukciją gali pasiekti priemones, saugiai prisijungti ir atlikti iš anksto sutartą nepavojingą administravimo patikrą.

Atskirai užfiksuokite, kam atėjo perspėjimas, kas jį pastebėjo ir kaip buvo nustatyta, kad tai suplanuotas bandymas. Jei pranešimas liko neperskaitytoje pašto dėžutėje, vien jo išsiuntimas dar neparodo, kad organizacija būtų sureagavusi.

Bandymo protokole užtenka datos, dalyvių, rezultato ir konkrečių trūkumų su jų sutvarkymo terminais. Nerašykite jame raktų PIN kodų ar kitų prisijungimo paslapčių. Po tikro panaudojimo papildomai įvertinkite atliktus pakeitimus ir ar prieigos priemonės liko patikimos.

Avarinė paskyra negarantuoja prieigos bendro paslaugos sutrikimo metu ir nepakeičia duomenų atsarginių kopijų. Jos paskirtis – suteikti suplanuotą kelią atkurti administravimą tada, kai neveikia įprastas prisijungimas, o pati paslauga leidžia prisijungti.