Pravilno osiguravanje Microsoft 365: Conditional Access, izuzeci za MFA i Break-Glass nalozi u praksi

Ko želi ispravno osigurati Microsoft 365, ne može zaobići Conditional Access (pristupno-ovisne politike u Entra ID, ranije Azure AD) i Multi-Faktor-Authentifizierung (MFA, odnosno prijava s najmanje dva faktora). U mnogim preduzećima MFA i prve Conditional-Access-regule se brzo aktiviraju – i tek tada počinje pravi posao: izuzeci moraju biti obrazloženi, hitni pristupi uredno organizovani, a operativni procesi dizajnirani tako da sigurnost ne postane lavina zahtjeva za podršku.

U praksi „osiguravanje M365“ rijetko obstane na osnovnoj tehnologiji, već na svakodnevnim temama: servisni nalogi za interfejse, legacy protokoli, terenski rad bez pouzdane mobilne mreže, administratori s preširokim pravima, ili incident pri kojem upravo mjera zaštite blokira pristup IT-u. Ovaj članak razjašnjava kako Conditional Access, MFA-izuzeci i Break-Glass-Accounts međusobno djeluju – i kako to postaviti tako da ostane pouzdano i nakon Go-live.

Warum Conditional Access der Hebel ist – und MFA allein nicht reicht

MFA značajno smanjuje rizik od ukradenih lozinki, ali MFA nije kompletan koncept kontrole pristupa. Conditional Access (CA) donosi kontekstualnu odluku o tome pod kojim uslovima je pristup dozvoljen: npr. samo s upravljanih uređaja, samo iz određenih zemalja, samo uz procjenu rizika ili samo s određenim klijentskim aplikacijama. To je ključni korak prema Zero Trust (sigurnosnom modelu u kojem se pristupi po defaultu ne smatraju pouzdanim, već se kontinuirano provjeravaju).

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

• Token umjesto lozinke: Moderna autentifikacija radi s tokenima (vremenski ograničene dozvole pristupa). Ukradeni token može zaobići MFA ako CA ne zahtijeva dodatne uvjete (npr. stanje uređaja ili kontrolu sesije).
• Rizik kod administratora: Administratorski nalozi su posebno atraktivni za napadače. Bez CA-regula za admin pristupe (npr. samo s radnih stanica administratora ili samo s MFA-om otpornim na phishing) najveća površina napada ostaje otvorena.
• „Dozvoljeno“ je preširoko: Ako CA ne razlikuje između aplikacija, klasa podataka i vrsta pristupa, sigurnost vrlo brzo postane ili previše popustljiva ili suviše RESTriktivna – oboje stvara probleme.

Operativna suština je stoga: CA kao sloj politika, MFA kao jedan građevni blok u njemu, uz uredno upravljanje izuzecima i pouzdane hitne puteve.

Architekturüberblick: Was Conditional Access in Entra ID tatsächlich steuert

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

• Identität: Korisnik, grupe, uloge (npr. privilegovane uloge kao Global Administrator).
• Zielressource: Cloud-aplikacija (Exchange Online, SharePoint/OneDrive, Teams, ali i treće strane preko Enterprise App).
• Client-Typ: Browser, moderni klijenti, mobilne aplikacije, kao i „Legacy Authentication“ (stariji protokoli bez modernih tokena, npr. starije varijante IMAP/POP/SMTP-auth).
• Gerätezustand: „Compliant“ ili „hybrid joined“ (upravljani uređaj, tipično preko Intune ili priključenosti domeni s informacijom o stanju uređaja).
• Netzwerk/Standort: Named Locations (definisani IP-rangeovi), zemlje/regioni, indikatori rizika.
• Sitzungsbedingungen: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (kontinuirana reprocjena pri događajima koji ukazuju na rizik).

Sa stanovišta operacija, kvaliteta vaše CA-konfiguracije uveliko zavisi od toga koliko su ti signali pouzdani. Ein Named Location je dobar onoliko koliko je dobra higijena IP-adresa. „Usklađenost“ vrijedi onoliko koliko je vaša uprava uređajima i definicija compliance. A procjena rizika korisna je samo ako radite s događajima koji iz toga proizlaze.

Microsoft 365 pravilno zaštititi s Conditional Accessom: praktičan set politika

Umjesto jedne „velike“ odluke, u svakodnevnom radu bolje funkcionira set od nekoliko jasno ograničenih politika. To smanjuje neželjene nuspojave i olakšava otklanjanje grešaka tijekom incidenta. Provjereni osnovni obrazac sastoji se od:

1) Osnovna politika za sve korisnike: MFA zahtijevati, naslijeđenu autentifikaciju blokirati

Za uobičajene korisničke račune osnovno pravilo je: MFA obvezno, a naslijeđena autentifikacija se blokira. „Legacy“ ovdje nije „zastarjelo“, nego tehnički problematično: ti protokoli često ne podržavaju modernu MFA-provjeru i zato predstavljaju klasičnu ulaznu točku za password spraying.

Važno: nemojte naslijeđenu autentifikaciju blokirati „nekad kasnije“, nego planirajte prijelaznu fazu s mjerenjem. Provjerite kroz Sign-in-Logs koji klijenti još koriste naslijeđenu autentifikaciju. U poduzećima su često povezani multifunkcijski pisači, funkcije 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. uređaji u statusu usklađenosti i po potrebi odvojena strategija admin-radnih stanica), MFA s visokom razinom sigurnosti (otpornom na phishing, npr. FIDO2/Passkey ili zasnovano na certifikatima) te, gdje je moguće, ograničenja za rizične države/lokacije. Čak i ako svako poduzeće ne uvede odmah potpunu Privileged-Access arhitekturu (PAM, tj. upravljanje privilegiranim pristupom), ta razlika se odmah isplati: kompromitirani admin račun je drugi domet štete od kompromitiranog korisničkog računa.

3) Politika za vanjsku suradnju i goste

Pristupi gostiju (B2B Collaboration) često stvaraju neočekivane putove podataka: gosti preuzimaju datoteke iz SharePointa, rade u Teamsu ili pristupaju projekt-portalu. Jasno definirajte smije li pristup biti moguć samo uz MFA, hoće li određene aplikacije biti isključene i koliko dugo sesije traju. Za projektni rad često je prikladnija kraća trajnost sesije kako bi se smanjio rizik „zaboravljenih prijava“.

4) Politika za osjetljive puteve podataka: osigurati uređaj ili sesiju

U praksi postoje različiti zahtjevi za zaštitu: primjerice, prodajni predstavnik može smjeti čitati e-poštu s bilo kojeg uređaja, ali ne i preuzimati velike količine podataka iz SharePointa bez upravljanog uređaja. Takve razlike ne rješavate općim „dozvoljeno/zabranjeno“, nego kombinacijama CA: „pristup dopušten ako je uređaj usklađen“ ili „pristup samo putem preglednika s ograničenom sesijom“. To je manje rigidno od potpunog blokiranja — a ipak učinkovito.

Iznimke za MFA: gdje su realne – i kako ih kontrolirati

Iznimke za MFA nisu znak slabosti, pod uvjetom da su svjesno dizajnirane i operativno kontrolirane. Bez kontroliranih iznimki nastaju sjenovita rješenja: korisnici zaobilaze procese, administratori naglo gase pravila, i prije ili kasnije skup politika postane nepregledan.

Važno je razlikovati: MFA-iznimka rijetko znači „MFA isključeno“, često je to „MFA drugačije“ ili „pristup samo pod drugim uvjetima“. Tipične kategorije iznimaka:

Primjer iznimke 1: Neinteraktivni pristupi i sučelja

Mnoge procesno-povezane softverske solucije integrišu M365-servise: slanje e‑pošte, pristup kalendaru, SharePoint‑skladištenje fajlova, Teams‑obavještenja ili pristupi Graph‑API. Takve integracije ne bi trebale koristiti korisničke naloge sa onemogućenim MFA. Bolje je tehnički pristup preko App‑Registrierungen (Anwendung in Entra ID) sa jasno definisanim dozvolama i životnim ciklusom Secrets/sertifikata. To nije „MFA‑izuzetak“, već drugačiji način autentifikacije koji je bolje auditabilan.

Operativne posljedice: Secrets se moraju rotirati, sertifikati ističu, i dozvole se moraju recertificirati. Ako planirate integracije, definirajte Ownership (ko obnavlja sertifikate/Secrets) i Monitoring (npr. upozorenja prije isteka). U protivnom će iz „sigurne“ autentifikacije aplikacije nastati neplanirani prekid.

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

Ovdje nastaju klasične diskusije oko SMTP‑Relay, Scan‑to‑Mail ili sobnih poštanskih sandučića. Pogrešno rješenje je gotovo uvijek „korisnički nalog bez MFA“. Bolji su tehnički putovi koji ne ovise o interaktivnoj prijavi: centralni mail‑relay sa IP‑RESTrikcijom, pristupi zasnovani na sertifikatima ili connector‑rješenja, ili odvojena sistemska poštanska sandučića sa strogo ograničenim pravima. Ključno je: uređaj sam ne može rukovati MFA, pa dizajn mora osigurati zaštitu na transportnom i mrežnom putu.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Terenski rad, proizvodnja ili rad u smjenama imaju situacije bez mobilnog signala ili bez privatnih mobilnih uređaja. Ovdje se isplati rano razmotriti alternativne MFA‑metode: hardverski tokeni, FIDO2 sigurnosni ključevi, ili Windows Hello for Business (gerätegebundene Anmeldung). „Temporär MFA aus“ je operativno privlačno, ali loše skalira i teško se može auditirati.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Neki legacy sistemi pokreću poslove „kao korisnik“, npr. za SharePoint‑upload ili izvještaje. To je iz današnje perspektive rizično jer miješa uloge i pristupne privilegije. Ako zamjena nije odmah moguća, radite s međukoracima: ograničeni servisni nalozi, jasno definirane Named Locations, stroge password/Secret‑politike i dosljedno logiranje. I: planirajte migraciju na app‑identitete kao zaseban radni paket, ne kao „neko drugi put“.

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

Izuzeci su u produkciji prihvatljivi samo ako imaju životni ciklus. U praksi se pokazao lagan pristup koji izbjegava birokraciju, a ipak je auditabilan:

1. Obrazloženje u jednoj rečenici: Koja poslovna ili operativna funkcija ovisi o tome (npr. „Scan‑to‑Mail za lokaciju X“)?
2. Tehnička klasifikacija: Koja aplikacija/protokoli, koji nalozi, koji tokovi podataka?
3. Kompenzacijske kontrole: Šta ograničava rizik (IP‑RESTrikcija, minimalno neophodna prava, monitoring)?
4. Datum isteka: Svaki izuzetak dobije datum pregleda. Bez pregleda biće uklonjen ili ponovo odobren.
5. Owner: Ko je odgovoran ako nešto zakaže ili kada izuzetak istekne?

Tako izuzeci neće postati „dobri“, ali postaju upravljivi. I upravo to u praksi razlikuje robusnu M365‑sigurnosnu osnovu od nereda u politikama.

Break-Glass-Accounts: Notfallzugang ohne Sicherheitsloch

Break-Glass računi su hitni nalozi za pristup Tenantu kada uobičajeni administratorski pristupi ne funkcionišu – na primjer zbog pogrešne konfiguracije u Conditional Access, pada MFA-provajdera ili identity incidenta. Svrha je jasna, ali implementacija nosi tipične zamke: Break-Glass nalog koji se nikad ne testira neće pomoći u stvarnom slučaju. Break-Glass nalog koji je previše lako dostupan predstavlja atraktivnu metu za napadače.

Šta Break-Glass nije

• Nije svakodnevni administratorski nalog: Ne smije se koristiti u normalnom radu.
• Nije kolektor izuzetaka: Ne zamjenjuje uredan CA-dizajn.
• Nije „imamo jedan, to je dovoljno“: Bez procesa, testiranja i alarmiranja to je samo teoretski plan.

Osnovna načela za Break-Glass u radu

Praktično rješenje usmjereno je na tri cilja: dostupno u hitnom slučaju, teško za napad u normalnom radu i jasno pratljivo.

• Najmanje dva naloga: Redundancija protiv zaključavanja, pogrešne upotrebe ili kompromitovanih vjerodajnica.
• Jako zaštićeno: Duge, nasumične lozinke; bez preusmjeravanja e-pošte; bez upotrebe za aplikacije/integracije.
• Ciljano izuzeto iz CA – ali strogo: Uobičajeno je izuzeti određene CA-polise kako se u hitnom slučaju ne biste zaključali vlastitim pravilima. Istovremeno trebaju djelovati drugi sigurnosni mehanizmi: alarmi pri korištenju, RESTriktivna dodjela uloga, odvojeno čuvanje vjerodajnica.
• Logovanje i alarmiranje: Svaka prijava mora izazvati neposredan signal (SIEM/SOC ili barem e-mail/Teams alarm na poštanski sandučić za incidente). Upotreba Break-Glass-a je per definicijom sigurnosni događaj.

Ključna stvar: odlučite svjesno da li će Break-Glass raditi s ili bez MFA. Mnoge organizacije ga ostave bez MFA kako bi ostale operativne u slučaju pada MFA. Tada moraju kompenzirajuće kontrole biti posebno uredne (čuvanje, pristup lozinki, alarmiranje, redovna promjena). Alternativno se Break-Glass može opremiti hardverskim MFA (npr. FIDO2) koji ne ovisi o mobilnoj mreži. Važno nije „ispravna“ ideologija, nego put za hitne slučajeve koji stvarno funkcioniše u vašem kontekstu.

Realnost rollout-a: Kako izbjeći zaključavanja i nagle opterećenja podrške

Mnogi CA-/MFA-rollouti ne propadaju tehnički, nego organizacijski: prebrzo, preširoko, bez telemetrije i bez jasnog procesa podrške. Stabilan rollout radi u talasima i s kontrolnim tačkama.

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

Koristite Sign-in Logs i analize da utvrdite: koje aplikacije se koriste? Koji klijenti su „legacy“? Koje lokacije/IP-opsezi su stvarni? Koji korisnici imaju naročito puno problema s prijavom? Bez ovih podataka svaka politika je letenje na slijepo.

Korak 2: Pilot-grupe s pravim izuzecima

Piloti ne bi trebali biti samo „IT i nekoliko volontera“. Svjesno uključite rubne slučajeve: terenski timovi, proizvodne lokacije, projektni saradnici s gostujućim pristupom i najmanje jedno odjeljenje s tipičnim alatima trećih strana. Cilj nije harmonija, nego rano otkrivanje stvarnih prepreka.

Korak 3: Definirajte Helpdesk-Playbooks

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

Schritt 4: Technische Nacharbeiten als eigenes Backlog

CA otkriva skrivene tehničke dugove: zastarjeli mail-klijenti, nedokumentirani skeneri, skripte s lozinkom u Task Scheduler, ili integracije koje još koriste Basic Auth. Planirajte te naknadne radove kao vidljive radne pakete. Inače će ostati zapeti kao „dauerhafte Ausnahme“.

Typische Fehlerbilder aus dem Betrieb – und wie man sie schneller einordnet

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

„Plötzlich geht Outlook nicht mehr“

Česti uzroci: legacy-client, stari profil ili CA-blok zbog nedovoljnog stanja uređaja. Provjerite: tip klijenta u Sign-in Log, primijenjena CA-Policy i da li se uređaj vodi kao compliant. Operativni popravak rijetko je „Policy aus“, češće je to „modernizirati klijenta“ ili „uredno uspostaviti upravljanje uređajima“.

„Service XY kann keine E-Mails mehr senden“

Često se radi o promjeni SMTP-autentikacije, izmijenjenoj relay-policy ili novoj CA-smeri koja nenamjerno obuhvati i tehničke naloge. Ovdje pomaže jasan arhitektonski izbor: slanje preko Relay/Connector umjesto korisničke prijave, s IP-ograničenjem i loggingom (mogućnost rekonstruiranja u incidentu).

„Admin kommt nicht mehr in den Tenant“

To je trenutak za koji je Break-Glass predviđen. Ako i Break-Glass pristup ne funkcioniše, obično nedostaje testirani hitni put ili je iznimka pogrešno konfigurirana. Zato: redovno vježbajte korištenje (s dokumentacijom ko kada testira i kako izgleda alarm).

„Zu viele Ausnahmen – niemand blickt durch“

To je governance-problem. Konsolidirajte politike, definirajte ritual pregleda (npr. mjesečno 30 minuta) i uklonite iznimke koje više nemaju Owner-a ili svrhu. Tehnički nije glamurozno, ali to je razlika između kontrolirane sigurnosti i povlastica nastalih kroz historiju.

Monitoring und Nachvollziehbarkeit: Was Sie wirklich brauchen

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

• Alarmierung auf harte Ereignisse: Break-Glass-Login, Admin-Login iz neuobičajenih zemalja, Block-Events na kritičnim aplikacijama.
• Regelmäßige Reviews: najčešći razlozi blokiranja, korisnici s najviše MFA-problema, pokušaji Legacy-Auth, nove Apps/Enterprise Apps.
• Audit-Spur für Ausnahmen: tko je koju iznimku odobrio, s kojim rokom isteka i kada je pregledano?

Ako već imate centralne procese za logging i incidenti (SIEM, Ticketing, Change-Management), ukotvljite CA-izmjene tamo. Conditional Access nije „mala postavka“, već pristupni sloj kritičan za produkciju.

Aufwand und Verantwortlichkeiten: Wer muss was liefern?

CA-/MFA-projekte se podcjenjuju zato što izgledaju kao čista konfiguracija. U stvarnosti su to projekti interfejsa između identiteta, krajnjih uređaja, mreže i poslovnih procesa. Jasno model odgovornosti smanjuje trenje:

• Identity-Team / Entra Admins: dizajn politika, model uloga, Break-Glass, registracije aplikacija.

Najvažnija menadžerska odluka često nije „MFA da/ne“, već: Imamo li vrijeme i resurse za naknadne radove (uklanjanje legacy-a, modernizaciju integracija, stabilizaciju upravljanja uređajima)? Bez tog rada dobitak u sigurnosti ostaje ispod očekivanja – ili operativni rad postane nepotrebno težak.

Zaključak: Sigurnost pobjeđuje, kada hitne situacije i izuzeci postanu dio sistema

Ispravno osiguranje Microsoft 365 znači upravljanje Conditional Access kao centralnim slojem kontrole – ne kao jednokratnu konfiguraciju. MFA je obavezna, ali stvarni kvalitet operacija nastaje kroz uredne izuzetke (s rokom isteka, Owner i kompenzirajućim kontrolama) i kroz Break-Glass-Accounts koji su testirani, nadzirani i organizacijski ugrađeni. Oni koji ta tri elementa povežu smanjuju rizike računa, dobiju revizijsku sposobnost bez preopterećenja i sprječavaju da sigurnosna pravila u Incidentu postanu njihov protivnik.

Razgovarajte o projektu ili modernizacijskom projektu s Net-Base.