Microsoft 365 in Entra ID: zmanjšanje izpostavljenosti prevzemu računov

Pregled virov: 13. september 2026. Spodnji postopki in tabele so predlogi za pooblaščen pregled. Sklici utemeljujejo tehnične lastnosti in priporočila virov; ne pomenijo, da vir predpisuje točno ta obseg ali obliko evidence.

Pri pregledu identitet v Microsoft 365 skupaj preverite avtentikacijo, zaščito sej, obnovitev dostopa in privilegirane račune. Pri Conditional Access preglejte obseg, izjeme in skupne zahteve vseh vključenih pravil, ki veljajo za prijavo. Izpolnjeno mora biti vsako veljavno pravilo; ime ali prikazani vrstni red pravil ne pomeni, da prvo ujemanje odobri dostop. 7 6

Cilj ni otežiti vsake prijave. Organizacija mora nepooblaščeni dostop dovolj omejiti, zmanjšati doseg morebitne prevzete seje in zbrati zapise, s katerimi lahko varnostna ekipa hitro ukrepa. Prispevek je namenjen obrambnemu pregledu in ne opisuje postopkov za obhod zaščit. 7 6

Politike potrebujejo dejanski popis

Najprej popišite uporabnike, račune, aplikacije in načine avtentikacije. Ločite zaposlene, skrbnike, gostujoče uporabnike, storitvene račune, račune za nujni dostop, skupne ali terenske račune in neinteraktivne delovne obremenitve. Za vsako skupino določite lastnika, pričakovane lokacije prijav, dostop do pomembnih aplikacij, dovoljene načine avtentikacije, obnovitvene poti ter skrbniške pravice v najemniku, naročninah, sodelovalnih storitvah ali imeniku. 4

Samo posnetek pravil pogojnega dostopa ne zadošča. Izvoziti je treba pravila Conditional Access in pregledati dodelitve, izjeme, kontrole za dovolitev ali blokiranje dostopa (grant controls), kontrole sej, način »report-only« in imenovane lokacije. V obseg sodijo tudi pravila metod avtentikacije, kampanje za registracijo, samopostrežna ponastavitev gesel, dodeljene privilegirane vloge, poslovne aplikacije, pravila privolitve, dostop med najemniki in odvisnosti od skladnosti naprav. Vsaka izjema naj ima lastnika in datum ponovnega pregleda. 4

Tak popis razkrije neskladja. Storitveni račun, ki se obravnava kot interaktivni uporabnik, skrbnik, ki bere e-pošto s privilegiranim računom, ali gostujoči uporabnik z vlogo v imeniku povečujejo tveganje, čeprav je delež uporabnikov z MFA visok. Delež vpisov je uporaben podatek, pomembnejša pa je dejanska pokritost pomembnih računov in aplikacij. 4

Za privilegirane račune uporabite metode, odporne na lažno predstavljanje

MFA zmanjša tveganje kompromisa samo z geslom, vendar niso vsi faktorji enako odporni na sodobno lažno predstavljanje. Pri skrbnikih najemnika, vlogah z dostopom do finančnih ali kadrovskih podatkov in računih, ki lahko spreminjajo varnostne nastavitve, uporabite metode, ki zmanjšajo možnost ponovne uporabe poverilnic in zlorabe potrditvenih pozivov, če jih okolje podpira. Postopek vpisa, zamenjave in izgube naprave mora biti jasen. Sicer bodo uporabniki dostop reševali z neuradnimi izjemami. 2

Preglejte celotno politiko metod avtentikacije, ne samo privzeto zahtevo MFA. Odstranite metode brez upravičene skupine uporabnikov, zaščitite registracijo in spremembo varnostnih podatkov s ponovno avtentikacijo, kjer je na voljo, ter začasne načine dostopa omejite na nadzorovan postopek službe za pomoč uporabnikom. Obnovitvena pot ne sme neopazno znižati ravni preverjanja, ki velja za skrbnika. 2

Računi za nujni dostop so potrebni zaradi neprekinjenega delovanja, niso pa priročna izjema. Njihovo število naj bo majhno, poverilnice in načini avtentikacije naj bodo zaščiteni ločeno, izjeme pa omejene na pravila, ki bi sicer preprečila obnovitev najemnika. Vsako prijavo in spremembo nastavitev je treba spremljati. Dokumentiran postopek obnovitve je smiselno redno preverjati v nadzorovanih pogojih. 3

Conditional Access naj bo razumljiv in uporaben

Conditional Access mora v majhnem in preglednem naboru pravil izraziti odločitve o dostopu. Običajne odločitve so zahteva po močnejši avtentikaciji za privilegirane vloge, blokiranje zastarele avtentikacije, kjer ni potrebna, zahteva po skladni ali upravljani napravi pri občutljivih aplikacijah in omejevanje sej pri dostopu z večjim tveganjem. Kjer je primerno, začnite v načinu »report-only«, vpliv preverite na dejanskih prijavah, nato pravilo uveljavite z dokumentirano možnostjo povrnitve. Način »report-only« oceni vpliv, vendar dostopa ne blokira. 4

Ne ustvarjajte širokih izjem zaradi posamezne težave pri uporabi. Če aplikacija potrebuje poseben vzorec, ji dodelite ozko pravilo z lastnikom in datumom pregleda. Izjema za celo skupino zaradi nedelujoče storitve spremeni zaščito za vse člane. Imenovana lokacija pomeni znano omrežje; sama po sebi ne dokazuje, da je povezava varna. 4

Pravila morajo upoštevati tudi operativne odpovedi. Zahteva po skladni napravi lahko blokira zaposlenega, ki vpisuje nadomestno napravo. Pravilo lokacije lahko vpliva na oddaljene sodelavce. Postopke za vpis naprave, potovanja, podporo in nujni dostop pripravite pred uveljavitvijo ter jih preverite z reprezentativnimi računi. Pravilo, ki ga ni mogoče dosledno uporabljati, bo sčasoma dobilo preveč izjem. 4

Omejite vrednost prevzete seje

Geslo in MFA varujeta začetek prijave, kontrole seje pa omejujejo nadaljnji dostop. Preverite pogostost prijave, trajne seje brskalnika, zaščito žetonov, kjer jo okolje podpira, privolitve aplikacij, registracijo naprav in dostop z neupravljanih končnih naprav. Pri skrbniških portalih in storitvah z več podatki je smiselno uporabiti krajše seje, če to upravičuje občutljivost. Trajanje je poslovna odločitev: krajša seja lahko zmanjša izpostavljenost, vendar lahko prekine delo. 2 4

Privolitev uporabnikov v aplikacije omejite z določenim postopkom odobritve. Preglejte obstoječe poslovne aplikacije, preverjenost izdajatelja, zahtevana dovoljenja, lastnike in neuporabljene storitvene principale. Aplikacija z dano privolitvijo lahko dostop ohrani tudi po tem, ko je uporabnik pozabil na prvotno dejanje. Upravljanje aplikacij je zato del programa za zaščito računov. 6

Privileged Identity Management lahko zmanjša trajne skrbniške pravice, saj upravičeni uporabnik vlogo aktivira samo, ko jo potrebuje. Aktivacijo povežite z močnim načinom avtentikacije, obrazložitvijo, po potrebi odobritvijo, časovno omejitvijo in opozorilom. Postopek mora delovati tudi pri redni podpori, sicer bodo skrbniki iskali trajnejše obvode. 5

Zaznajte spremembe avtoritete

V osrednje okolje za beleženje pošljite dnevnike prijav, revizij, oskrbe računov in Microsoft 365 ter določite obdobje hrambe glede na preiskovalne potrebe. Opozorila naj zaznajo nova sredstva avtentikacije, spremembe ponastavitve gesla, dodelitev privilegiranih vlog, spremembe Conditional Access, nove privolitve aplikacij, spremembe federacije ali nastavitev med najemniki ter dejavnost računov za nujni dostop. 7 6

Pri prijavah presojajte kombinacijo okoliščin. Neznana lokacija je lahko posledica potovanja, neznana lokacija skupaj z registracijo varnostnih podatkov in dodelitvijo vloge pa zahteva hiter pregled. Postopek odziva naj določa preverjanje suma prevzema, preklic sej, zamenjavo poverilnic, odstranitev neodobrenih metod ali aplikacij in ohranitev dokazov. Vnaprej določite, kdo lahko to opravi tudi zunaj delovnega časa. 7 6

Redni pregledi dostopov sodijo med zaznavanje. Preglejte gostujoče uporabnike, neaktivne račune, lastnike aplikacij, privilegirane dodelitve in članstvo v skupinah. Cilj je odstraniti pravice, ki nimajo več poslovnega razloga, preden postanejo uporabne pri napadu. 7 6

Vrstni red ukrepov

Najprej zaščitite vloge na ravni najemnika in druge pomembne račune z MFA, odporno na lažno predstavljanje, ter omejenim in nadzorovanim postopkom nujnega dostopa. Nato po preverjanju v načinu »report-only« uveljavite Conditional Access za zastarelo avtentikacijo in občutljive vire. Omejite spremembe metod avtentikacije, določite nadzorovano obnovitev dostopa, zmanjšajte trajne pravice, uredite privolitve aplikacij in pri občutljivih podatkih zahtevajte upravljane naprave. 4

Na koncu preverite odzivno pot. Namizna vaja naj zajame uporabnika, ki prijavi sumljiv poziv, potrjeno nepooblaščeno prijavo, kompromis privilegiranega računa in izgubljeno napravo za avtentikacijo. Rezultat vaje naj bodo določeni lastniki in spremembe konfiguracije, ne samo splošne ugotovitve. 4

Kontrolni seznam za preverljivo obnovitev dostopa

Ta kontrolni seznam uporabite pri izmišljeni vaji izgubljene naprave ali zaklenjenega računa. Gre za seznam zasnove in dokazil; pred uporabo je treba v najemniku preveriti dejanske funkcije Entra, vloge in pogoje licenciranja. 4

Pogosta vprašanja

Ali MFA zadošča za preprečitev prevzema računa?

MFA je nujna, vendar ne odpravi kraje seje, zlonamerne privolitve, šibke obnovitve dostopa ali preširokih pravic. Skupaj morajo delovati močni faktorji, pravila dostopa, upravljanje sej in beleženje. 2 6

Ali naj blokiramo vse zasebne naprave?

Odgovor je odvisen od aplikacij in podatkov. Pravilnik naj določi, do česa je dostop z neupravljane naprave dovoljen, za skrbniške in občutljive storitve pa uporabi strožje pogoje. 4

Kaj je treba pregledati po prevzemu računa?

Preglejte aktivne seje, registrirane načine avtentikacije, spremembe nabiralnika ali sodelovalnih storitev, privolitve aplikacij, dodeljene vloge, pravila posredovanja in izjemo ali politiko, zaradi katere je dogodek trajal. 7 6

Notranje povezave: Strokovno področje varnosti oblaka · Uvod v identitete Azure · Ozadje OAuth

Sources / Viri

1. Microsoft Entra: Security defaults — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
2. Microsoft Entra: Deploy phishing-resistant passwordless authentication — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
3. Microsoft Entra: Emergency access accounts — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
4. Microsoft: Build a Conditional Access policy — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
5. Microsoft: Activate Microsoft Entra roles in PIM — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
6. Microsoft: Compromised and malicious applications investigation — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.
7. Microsoft: Respond to a compromised email account — Access/review date / datum dostopa oziroma pregleda: 2026-09-13.