Ispravno osiguravanje Microsoft 365: Conditional Access, iznimke za MFA i Break-Glass računi u praksi

Tko želi ispravno osigurati Microsoft 365, ne može zaobići Conditional Access (pravila pristupa ovisna o kontekstu u Entra ID, ranije Azure AD) i multi-faktorsku autentikaciju (MFA, dakle prijava s najmanje dva faktora). U mnogim tvrtkama MFA i prve Conditional Access politike brzo se uključe – i tek tada počinje posao: iznimke se moraju opravdati, izvanredni pristupi uredno organizirati i operativni procesi oblikovati tako da sigurnost ne preraste u lavinu zahtjeva za podrškom.

U praksi „osiguravanje M365“ rijetko pada na temeljnu tehnološku razinu, već na svakodnevne probleme: servisni nalozi za sučelja, legacy-protokoli, terenski rad bez pouzdane mobilne mreže, administratori s preširokim pravima ili incident u kojem upravo mjera zaštite blokira pristup IT-u. Ovaj članak pojašnjava kako Conditional Access, iznimke za MFA i Break-Glass-Accounts međusobno djeluju – i kako to sve operativno voditi da ostane pouzdano i nakon Go-live.

Zašto je Conditional Access poluga – i zašto sama MFA nije dovoljna

MFA značajno smanjuje rizik od ukradenih lozinki, ali MFA nije cjeloviti koncept pristupa. Conditional Access (CA) kontekstno odlučuje pod kojim uvjetima je pristup dopušten: npr. samo s upravljanih uređaja, samo iz određenih zemalja, samo s procjenom rizika ili samo s određenim klijentskim aplikacijama. To je ključni korak prema Zero Trust (sigurnosnom modelu pri kojem se pristup po defaultu ne vjeruje, već se kontinuirano provjerava).

Tipični razlozi zašto sama MFA u Microsoft 365 nije dovoljna:

• Token umjesto lozinke: Moderna autentikacija radi s tokenima (vremenski ograničene ulaznice za pristup). Ukradeni token može zaobići MFA ako CA ne zahtijeva dodatne uvjete (npr. stanje uređaja ili upravljanje sesijom).
• Rizik administratora: Administrativni nalozi su posebno atraktivni. Bez CA pravila za administrativne pristupe (npr. samo s administratorskih radnih stanica ili samo s phishing-otpornom MFA) najveća površina napada ostaje otvorena.
• „Dopušteno“ je preširoko: Ako CA ne razlikuje aplikacije, klase podataka i vrste pristupa, sigurnost će brzo postati ili previše labava ili previše RESTriktivna – oboje stvara probleme.

Operativna srž je stoga: CA kao sloj politika, MFA kao njegov sastavni dio, plus uredno upravljanje iznimkama i pouzdani izvanredni putovi.

Pregled arhitekture: što Conditional Access u Entra ID zapravo kontrolira

Za IT-upravljanje i operacije važno je ne gledati na CA kao na „jednu politiku“, već kao na lanac odluka. Entra ID pri svakoj prijavi evaluira signale i primjenjuje politike. Važni signali su:

• Identitet: korisnici, grupe, uloge (npr. privilegirane uloge poput Global Administrator).
• Ciljni resurs: Cloud-aplikacija (Exchange Online, SharePoint/OneDrive, Teams, ali i treće strane preko Enterprise App).
• Tip klijenta: preglednik, moderni klijenti, mobilne aplikacije, kao i „Legacy Authentication“ (stariji protokoli bez modernih tokena, npr. starije IMAP/POP/SMTP autentikacijske varijante).
• Stanje uređaja: „Compliant“ ili „hybrid joined“ (upravljački uređaj, tipično preko Intune ili pridruživanja domeni sa statusom uređaja).
• Mreža/lociranje: Named Locations (definirane IP-rangove), zemlje/regioni, indikatori rizika.
• Uvjeti sesije: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (kontinuirana re-evaluacija pri događajima rizika).

Iz operativnog gledišta kvaliteta vaše CA‑konfiguracije uvelike ovisi o tome jesu li ti signali pouzdani. Ein Named Location je dobar onoliko koliko je dobra higijena vaših IP‑adresa. „Compliant“ je vrijedan onoliko koliko je upravljanje vašim uređajima i definicija compliance. A procjena rizika korisna je samo ako i radite s događajima (Events) koji iz nje proizlaze.

Microsoft 365 pravilno osigurati s Conditional Access: praktičan skup politika

Umjesto jedne „velike“ politike u praksi bolje funkcionira set od nekoliko jasno ograničenih politika. To smanjuje nuspojave i olakšava otklanjanje pogrešaka u incidentu. Dokazani osnovni obrazac sastoji se od:

1) Osnovna politika za sve korisnike: MFA nametnuti, Legacy blokirati

Za uobičajene korisničke račune osnovna politika je: obvezni MFA, a Legacy Authentication se blokira. „Legacy“ ovdje nije „zastarjelo“, već tehnički problematično: ti protokoli često ne podržavaju moderni MFA‑challenge i zbog toga predstavljaju klasičnu ulaznu točku za password spraying.

Važno: ne blokirajte Legacy tek „nekad“, već planirajte prijelaznu fazu s mjerenjem. Provjerite putem Sign‑in Logs koji klijenti još koriste Legacy. U poduzećima se na to često oslanjaju multifunkcijski pisači, Scan‑to‑Mail ili stariji mail‑klijenti u specijalnim okruženjima.

2) Administratorska politika: znatno stroža od osnovne

Privilegirane uloge trebaju vlastitu politiku: pristup samo s definiranih admin‑uređaja (npr. „compliant“ i eventualno zasebna strategija Admin‑Workstation), MFA s visokom razinom sigurnosti (otporna na phishing, npr. FIDO2/Passkey ili certifikatom bazirana), te po mogućnosti ograničenja za rizične zemlje/lokacije. Čak i ako tvrtka odmah ne uvodi potpunu Privileged‑Access‑arhitekturu (PAM, tj. upravljanje privilegiranim pristupom), ta razlika se odmah isplati: kompromitiran administratorski račun stvara drugačiji prostor štete nego kompromitiran korisnički račun.

3) Politika za vanjsku suradnju i goste

Pristupi gostiju (B2B Collaboration) često stvaraju neočekivane tokove podataka: gosti preuzimaju datoteke iz SharePointa, rade u Teamsu ili pristupaju projektnih portalima. Jasno definirajte dopuštate li gostima pristup samo uz MFA, jesu li određene aplikacije isključene i koliko dugo sesije vrijede. Za rad na projektima često je primjerenije kraće trajanje sesija kako bi se smanjio rizik „zaboravljenih prijava“.

4) Politika za osjetljive tokove podataka: osigurajte uređaj ili sesiju

U praksi postoje različite potrebe za zaštitom: prodajni predstavnik možda smije čitati e‑poštu s bilo kojeg uređaja, ali ne smije bez upravljanog uređaja preuzimati velike količine podataka iz SharePointa. Takve razlike ne modelirate općim „dozvoljeno/zabranjeno“, već kroz kombinacije CA: „pristup dozvoljen ako je uređaj compliant“ ili „pristup samo putem preglednika s ograničenom sesijom“. To je manje rigidno od potpunog blokiranja — a ipak učinkovito.

Izuzeci za MFA: gdje su realistični – i kako ih kontrolirati

Izuzeci za MFA nisu znak slabosti sve dok su svjesno osmišljeni i operativno kontrolirani. Bez kontroliranih izuzetaka nastaju sjenovita rješenja: korisnici zaobilaze procese, administratori panično isključuju pravila, i s vremenom skup politika postane nepregledan.

Važna je distinkcija: izuzetak od MFA rijetko znači „MFA isključeno“, već često „MFA drugačije“ ili „pristup samo pod drugim uvjetima“. Tipične kategorije izuzetaka:

Izuzetak 1: Neinteraktivni pristupi i sučelja

Mnoge softverske solucije bliske procesima integriraju M365 usluge: slanje e-pošte, pristup kalendaru, pohrana datoteka u SharePoint, obavijesti u Teams ili pristupi Graph-API-ju. Takve integracije ne bi trebale koristiti korisničke račune s onemogućenim MFA. Bolji je tehnički pristup preko App-Registrierungen (Aplikacija u Entra ID) s jasno definiranim dopuštenjima i životnim ciklusom Secret-/Zertifikatslebenszyklus. To nije „MFA-Ausnahme“, već druga vrsta autentikacije koja je podložnija reviziji.

Posljedice za rad: Secrets se moraju rotirati, certifikati istječu, i dopuštenja se moraju recertificirati. Ako planirate integracije, definirajte Ownership (tko obnavlja Zertifikate/Secrets) i Monitoring (npr. upozorenja pred istekom). Inače od „sigurne“ App-Auth nastat će neplanirani prekid.

Ausnahmefall 2: Geräte ohne modernen Login (z. B. Scanner, Drucker, Raum-Systeme)

Ovdje nastaju klasične rasprave o SMTP-Relayu, Scan-to-Mail ili Raum-Postfächern. Pogrešno rješenje je gotovo uvijek „ein Benutzerkonto ohne MFA“. Bolji su tehnički putevi koji nisu vezani uz interaktivnu prijavu: zentraler Mail-Relay s IP-RESTriktion, Zertifikats- oder Connector-Ansätze, ili odvojeni Systempostfächer s uskim dopuštenjima. Presudno je: sam uređaj ne može rukovati MFA, pa se dizajn mora osigurati na transportnom i mrežnom putu.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Terenski rad, proizvodnja ili rad u smjenama imaju situacije bez mobitelnog signala ili bez privatnih mobilnih uređaja. Ovdje se isplati rano razmotriti alternativne MFA metode: hardverski tokeni, FIDO2-Sicherheitsschlüssel, oder Windows Hello for Business (gerätegebundene Anmeldung). „Temporär MFA aus“ je operativno primamljivo, ali loše se skalira i teško je podložno reviziji.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Neki Altsysteme pokreću poslove „als Benutzer“, npr. za SharePoint-Uploads ili Reports. Iz današnje perspektive to je rizično jer miješa uloge i prava pristupa. Ako zamjena nije odmah moguća, radite s međufazama: ograničeni Servicekonten, jasne Named Locations, stroge Passwort-/Secret-Policies i dosljedno evidentiranje. I: planirajte migraciju na App-Identitäten kao zaseban radni paket, ne kao „später mal“.

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

Izuzeci su u radu prihvatljivi samo ako imaju životni ciklus. U praksi se pokazao lagani pristup koji zaobilazi birokraciju, ali je ipak auditfest:

1. Begründung in einem Satz: Koja poslovna ili operativna funkcija ovisi o tome (npr. „Scan-to-Mail an Standort X“)?
2. Technische Einordnung: Koja App/Protokolle, koji računi, koji putovi podataka?
3. Kompensierende Kontrollen: Što ograničava rizik (IP-RESTriktion, minimal notwendige Rechte, Monitoring)?
4. Ablaufdatum: Svaki izuzetak dobiva datum pregleda. Bez pregleda bit će uklonjen ili ponovno odobren.
5. Owner: Tko je odgovoran, ako dođe do zastoja ili ako izuzetak istekne?

Tako izuzeci neće postati „gut“, ali postaju upravljivi. I upravo je to u praksi razlika između robusne M365-Sicherheitsbasis i jednog Richtlinien-Wildwuchs.

Break-Glass-Accounts: Pristup u nuždi bez sigurnosne rupe

Break-Glass-Accounts su računi za hitne slučajeve koji omogućuju pristup Tenantu kada regularni administratorski pristupi ne funkcioniraju – primjerice zbog pogrešne konfiguracije u Conditional Access, pada MFA-providera ili identity-incidenta. Svrha je jasna, ali provedba skriva tipične zamke: Break-Glass račun koji nikad nije testiran u stvarnom incidentu neće pomoći. Break-Glass račun koji je previše lako dostupan predstavlja atraktivan cilj za napadače.

Što Break-Glass nije

• Nije dnevni administratorski račun: Ne smije se koristiti u redovnom radu.
• Nije spremnik za iznimke: Ne zamjenjuje uredan CA-dizajn.
• Nije „imamo ga, to je dovoljno“: Bez procesa, testiranja i alarmiranja to ostaje samo teorijski plan.

Temeljna načela za Break-Glass u radu

Praktično rješenje treba se držati triju ciljeva: dostupno u hitnom slučaju, teško izloživo napadu u normalnom radu i jasno provjerljivo.

• Najmanje dva računa: Redundancija protiv zaključavanja, pogrešne upotrebe ili kompromitiranih vjerodajnica.
• Jako osigurano: Duge, slučajne lozinke; bez prosljeđivanja e-pošte; bez korištenja za aplikacije/integracije.
• Namjenski izuzeto iz CA – ali usko: Uobičajeno je izuzeti određene CA-policyje kako biste se u hitnom slučaju ne zaključali vlastitim pravilima. Istovremeno moraju djelovati drugi sigurnosni mehanizmi: alarmi pri korištenju, RESTriktivna dodjela uloga i odvojeno čuvanje vjerodajnica.
• Logiranje i alarmiranje: Svaka prijava mora odmah generirati signal (SIEM/SOC ili barem e‑mail/Teams alarm na inbox za incidente). Korištenje Break-Glass-a je po definiciji sigurnosni događaj.

Ključna točka: svjesno odlučite hoće li Break-Glass raditi s ili bez MFA. Mnoge organizacije ga ostavljaju bez MFA kako bi ostale operativne pri padu MFA. U tom slučaju kompenzacijske kontrole moraju biti posebno rigorozne (čuvanje, pristup lozinci, alarmiranje, redovita izmjena). Alternativno, Break-Glass se može opremiti hardware‑based MFA (npr. FIDO2) koja je neovisna o mobilnoj mreži. Važno nije slijepo slijediti neku ideologiju, nego imati put postupanja u nuždi koji u vašem kontekstu stvarno funkcionira.

Realnost rollouta: Kako izbjeći zaključavanja i vrhove podrške

Mnogi CA-/MFA-rollouti ne ne uspijevaju iz tehničkih razloga, nego organizacijskih: prebrzo, preširoko, bez telemetrije i bez jasnog procesa podrške. Stabilan rollout radi u valovima i s kontrolnim točkama.

Korak 1: Stvorite vidljivost (prije nego što blokirate)

Iskoristite sign-in logove i analitiku da utvrdite: koje aplikacije se koriste? Koji klijenti su „legacy“? Koje lokacije/IP-opsezi su realni? Koji korisnici imaju posebno mnogo problema s prijavom? Bez tih podataka svaka politika je slijepi let.

Korak 2: Pilotne grupe s pravim iznimnim slučajevima

Pilotne grupe ne bi trebale biti samo „IT i nekoliko volontera“. Svjesno uključite rubne slučajeve: terenski radnici, proizvodne lokacije, projektni suradnici s gostujućim pristupom i najmanje jedno odjeljenje koje koristi tipične alate trećih strana. Cilj nije harmonija, nego rano otkrivanje stvarnih zapreka.

Korak 3: Definirajte helpdesk playbookove

Kada se MFA zahtijeva, broj tiketa raste: promjene uređaja, izgubljeni telefoni, novi zaposlenici, račun zaključan nakon previše pokušaja. Odredite što First-Level smije riješiti (npr. MFA-reset nakon provjere identiteta) i kada se eskalira. Bez playbookova sve se eskalira – a administratori postaju usko grlo.

Korak 4: Tehničke naknadne radnje kao zaseban backlog

CA otkriva skrivene tehničke dugove: zastarjeli mail-klijenti, nedokumentirani skeneri, skripte s lozinkom u Task Scheduleru ili integracije koje i dalje koriste Basic Auth. Planirajte te naknadne radnje kao vidljive radne pakete. Inače ostaju kao „trajni izuzetak“.

Tipični problemi iz pogona – i kako ih brže klasificirati

U praksi vrijede brze pretpostavke. Neki obrasci se stalno ponavljaju:

„Iznenada Outlook više ne radi“

Česti uzroci: legacy-klijent, stari profil ili CA-blok zbog nedostatka stanja uređaja. Provjerite: tip klijenta u zapisu prijave, primijenjeno CA-pravilo i je li uređaj označen kao compliant. Operativno rješenje rijetko je „isključiti pravilo“, već „modernizirati klijenta“ ili „srediti upravljanje uređajima“.

„Servis XY više ne može slati e‑poštu“

Često je u pitanju promjena u SMTP-autentikaciji, promijenjena relay-politika ili novo CA-pravilo koje nenamjerno obuhvaća i tehnička računa. Ovdje pomaže jasan arhitektonski zaključak: slanje preko relay/connectora umjesto korisničkog prijavljivanja, uz IP-ograničenje i logiranje (mogućnost praćenja u incidentu).

„Administrator više ne može u tenant“

To je trenutak za koji je Break-Glass zamišljen. Ako Break-Glass pristup također ne radi, obično nedostaje testirani put za nuždu ili je izuzetak pogrešno konfiguriran. Stoga: redovito vježbajte korištenje (s dokumentacijom tko kada testira i kako izgleda alarm).

„Previše izuzetaka – nitko se ne snalazi“

To je problem upravljanja. Konsolidirajte pravila, definirajte ritual pregleda (npr. mjesečno 30 minuta) i uklonite izuzetke koji više nemaju ownera/ili svrhu. Tehnički to nije glamurozno, ali čini razliku između kontrolirane sigurnosti i povijesno nastalih posebnih prava.

Nadzor i mogućnost praćenja: što vam stvarno treba

CA i MFA generiraju puno događaja. Ako sve skupljate, utopit ćete se; ako ništa ne analizirate, probleme ćete primijetiti prekasno. Praktično su korisne tri razine:

• Upozorenja na kritične događaje: Break-Glass prijava, admin-prijava iz neobičnih zemalja, blok-događaji na kritičnim aplikacijama.
• Redoviti pregledi: top razlozi blokiranja, korisnici s problemima MFA, pokušaji legacy-autentikacije, nove aplikacije/Enterprise aplikacije.
• Auditni trag za izuzetke: tko je odobrio koji izuzetak, s kojim datumom isteka i kada je pregledan?

Ako već imate centralne procese za logiranje i incidente (SIEM, ticketing, change-management), ugradite promjene CA-a tamo. Conditional Access nije „mala postavka“, nego proizvodno-kritični sloj pristupa.

Opseg i odgovornosti: tko što mora isporučiti?

CA-/MFA-projekte se podcjenjuje jer djeluju kao čista konfiguracija. U stvarnosti su to projekti sučelja između identiteta, endpointa, mreže i poslovnih procesa. Jasno odgovorno modeliranje smanjuje trenje:

• Identity-Team / Entra Admins: dizajn pravila, model uloga, Break-Glass, registracije aplikacija.
• Client-Management (z. B. Intune): Definition usklađenosti, status uređaja, uvođenje Authenticator/Passkeys, životni ciklus uređaja.
• Netzwerk: IP-opsezi za Named Locations, izuzeci za Proxy/TLS-Inspection, promjena lokacije.
• Service Owner von Business-Anwendungen: integracijski putovi (Graph/SMTP/SharePoint), prelazak s Legacy-Auth, rotacija tajni.
• Helpdesk: standardni procesi za MFA-reset, zamjenu uređaja, onboarding/offboarding.

Najvažnija upravljačka odluka često nije „MFA da/ne“, već: imamo li vremena i resurse za naknadne radove (uklanjanje legacy komponenti, modernizaciju integracija, stabilizaciju upravljanja uređajima)? Bez tih radova sigurnosni dobitak ostaje ispod očekivanja – ili rad postane nepotrebno težak.

Zaključak: sigurnost jača kad hitni slučajevi i izuzeci postanu dio sustava

Ispravno osiguravanje Microsoft 365 znači upravljati Conditional Access kao centralnim slojem kontrole – ne kao jednokratnom konfiguracijom. MFA je pritom obavezna, ali stvarna kvaliteta operacija nastaje kroz uredne izuzetke (s datumom isteka, vlasnikom i kompenzacijskim kontrolama) i kroz račune za hitni pristup koji su testirani, nadzirani i organizacijski utemeljeni. Tko ta tri elementa promišlja zajedno, smanjuje rizike računa, dobiva sposobnost provođenja audita bez dodatnog opterećenja i sprječava da sigurnosna pravila tijekom incidenta postanu vlastiti neprijatelj.

Razgovarajte o projektu ili planu modernizacije s Net-Base.