Како правилно обезбедити Microsoft 365: Conditional Access, MFA-изузеци и Break-Glass налози у пракси

Ко жели правилно да осигура Microsoft 365, не може да заобиђе Conditional Access (политике приступа у Entra ID, раније Azure AD) и Multi-Faktor-Authentifizierung (MFA, односно пријава са најмање два фактора). У многим предузећима MFA и прве Conditional-Access-правиле се брзо активирају – и тек тада посао почиње: изузеци морају бити образложени, хитни приступи уредно организовани и оперативни процеси дизајнирани тако да безбедност не постане лавина захтева служби за подршку.

У пракси „осигуравање M365“ ретко застане на основној технологији, већ на свакодневним темама: сервисни налози за интерфејсе, Legacy-протоколи, теренски рад без поуздане мобилне везе, админи са прекомерним правима или инцидент у ком управо мера заштите блокира приступ ИТ-у. Овај текст разјашњава како Conditional Access, MFA-изузеци и Break-Glass-Accounts међусобно делују – и како то све оперативно водити тако да остане поуздано и након Go-live.

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

MFA значајно смањује ризик од украдених лозинки, али MFA није потпун концепт приступа. Conditional Access (CA) одлучује контекстуално, под којим условима је приступ дозволен: нпр. само са управљаних уређаја, само из одређених земаља, само уз ризичну процену или само са одређеним клијент апликацијама. То је кључни корак ка Zero Trust (модел безбедности у коме се приступ по подразумеваној вредности не верује, већ се континуирано проверава).

Типични разлози зашто MFA само по себи у Microsoft 365 није довољан:

• Token statt Passwort: Модерна аутентификација ради са токенима (временски ограничени приступни тикети). Украдени токен може заобићи MFA ако CA не захтева додатне услове (нпр. стање уређаја или контрола сесије).
• Admin-Risiko: Администраторски налози су посебно атрактивни. Без CA-правила за админ приступе (нпр. само са Admin-Workstations или само уз phishing-резистентно MFA) највећа површина напада остаје отворена.
• „Erlaubt“ ist zu breit: Ако CA не разликује између апликација, класа података и врста приступа, безбедност ће брзо бити или превише опуштена или превише рестриктивна – обе крајности стварају проблеме.

Оперативна суштина је стога: CA као слој политика, MFA као саставни елемент унутар њега, плус уредно управљање изузецима и поуздани путеви за хитне случајеве.

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

За IT-руководство и оперативу важно је не схватати CA као „једну политику“, већ као ланац одлука. Entra ID при свакој пријави вреднује сигнале и примењује политике. Важни сигнали су:

• Identität: корисници, групе, улоге (нпр. привилеговане улоге као Global Administrator).
• Zielressource: Cloud-App (Exchange Online, SharePoint/OneDrive, Teams, али и треће стране преко Enterprise App).
• Client-Typ: прегледачи, модерни клијенти, мобилне апликације, као и „Legacy Authentication“ (старији протоколи без модерних токена, нпр. старије варијанте IMAP/POP/SMTP аутентификације).
• Gerätezustand: „Compliant“ или „hybrid joined“ (управљан уређај, типично преко Intune или придруживањем домени са статусом уређаја).
• Netzwerk/Standort: Named Locations (дефинисани IP-опсези), државе/региони, индикатори ризика.
• Sitzungsbedingungen: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (континуирана преоценa при догађајима ризика).

Са аспектa рада, квалитет Ваше CA-конфигурације у великој мери зависи од тога да ли су ти сигнали поуздани. Named Location је добар колико и ваша хигијена IP-адреса. „Compliant“ је добар колико и управљање уређајима и дефиниција комплајанса. А процена ризика је корисна само ако радите са догађајима који из ње проистичу.

Microsoft 365 richtig absichern mit Conditional Access: Ein praxistaugliches Policy-Set

Уместо једне „велике“ правила, у свакодневној пракси боље функционише скуп од неколико јасно одвојених политика. То смањује секундарне ефекте и олакшава проналажење грешки приликом инцидента. Устали основни образац обухвата:

1) Baseline für alle Nutzer: MFA erzwingen, Legacy blocken

За уобичајене корисничке налоге основни ниво је: обавезно MFA, и Legacy Authentication се блокира. Овде „Legacy“ није „старомодно“, већ технички проблематично: ти протоколи често не подржавају модерни MFA-изазов и стога представљају класичан улазни пут за password spraying.

Важно: не блокирајте Legacy „негде у будућности“, већ планирајте фазу транзиције уз мерење. Проверавајте преко Sign-in Logs који клијенти још користе Legacy. У предузећима често су на то повезани мултифункционални штампачи, опције Scan-to-Mail или старији мејл клијенти у специјалним окружењима.

2) Admin-Policy: deutlich strenger als die Baseline

Привилегованим улогама треба доделити засебну политику: приступ само са дефинисаних админ-уредјаја (нпр. „compliant“ и евентуално посебна стратегија за администраторске радне станице), MFA са високим нивоом сигурности (отпорно на phishing, нпр. FIDO2/Passkey или сертификатима засновано), и по могућности ограничавања за ризична земљишта/локације. Чак и ако предузеће не уведе одмах потпуну Privileged-Access-архитектуру (PAM, тј. управљање привилегованим приступом), ова разлика се исплати одмах: компромитован админ налог представља друге размере штете него компромитован кориснички налог.

3) Policy für externe Zusammenarbeit und Gäste

Приступи гостију (B2B Collaboration) често стварају неочекиване токове података: гости преузимају датотеке из SharePoint, раде у Teams или приступају порталима пројеката. Јасно дефинишите да ли гости могу ући само уз MFA, да ли су одређене апликације искључене и колико дуго су сесије важеће. За рад на пројектима често је пожељнија краћа дужина сесије како би се смањио ризик „заборављених логовања“.

4) Policy für sensible Datenpfade: Gerät oder Sitzung absichern

У пракси постоје различите потребе за заштитом: продајни представник можда може да чита мејлове са било ког уређаја, али не и да без управљаног уређаја преузме велике количине података из SharePoint-а. Такве разлике не решавате општим „дозвољено/забрањено“, већ комбинацијама CA: „приступ дозвољен ако је уређај compliant“ или „приступ само преко прегледача са ограниченом сесијом“. То је мање рестриктивно од потпуног блокирања — и ипак ефикасно.

MFA-Ausnahmen: Wo sie realistisch sind – und wie man sie kontrolliert

Изузеци од MFA нису знак слабости, док год су свесно дефинисани и оперативно контролисани. Без контролисаних изузетака настају сенчана решења: корисници заобилазе процесе, админи брзоплето искључују правила, и у неком тренутку више се не може пратити збирка политика.

Важна је разлика: изузетак од MFA ретко значи „MFA искључено“, већ често „MFA на други начин“ или „приступ само под другим условима“. Типичне категорије изузетака:

Ausnahmefall 1: Nicht-interaktive Zugriffe und Schnittstellen

Многе процесно повезане софтверске солуције интегришу M365 сервисе: слање е-поште, приступ календару, складиштење фајлова у SharePoint, обавештења у Teams или позиви Graph-API. Такве интеграције не би требало да се одвијају преко корисничких налога са онемогућеним MFA. Боље је техничко приступање преко регистрација апликација (апликација у Entra ID) са јасним привилегијама и животним циклусом тајни и сертификата. То није „MFA-изузетак“, већ друга врста аутентификације која је ревизорски уочљивија.

Последице у операцијама: тајне морају да се ротирају, сертификати истичу, и привилегије морају да се ресертификују. Ако планирате интеграције, дефинишите Ownership (ко обнавља сертификате/тајне) и Monitoring (нпр. упозорења пре истека). Иначе ће из „сигурне“ аутентификације апликације настати непланирани прекид.

Изузетак 2: Уређаји без модерног пријављивања (нпр. скенери, штампачи, системи за просторије)

Овде настају класичне дискусије око SMTP-Relay, Scan-to-Mail или поштанских сандучића за просторије. Погрешно решење је готово увек „кориснички налог без MFA“. Бољи су технички путеви који не зависе од интерактивног пријављивања: централни mail relay са IP-ограничењем, приступи засновани на сертификатима или конекторима, или одвојена системска поштанска сандучад са уским привилегијама. Кључно је: сам уређај не може да користи MFA, па дизајн мора бити обезбеђен на транспортном и мрежном путу.

Изузетак 3: Рад у ванредним условима и ограничена доступност

Теренски рад, производња или рад у сменама имају ситуације без мобилног сигнала или без приватних мобилних уређаја. Овде вреди рано размотрити алтернативне MFA методе: хардверски токени, FIDO2 сигурносни кључеви, или Windows Hello for Business (пријава везана за уређај). „Привремено искључивање MFA“ је оперативно привлачно, али се лоше скалира и тешко је ревизорски документовати.

Изузетак 4: Аутоматизовани послови са корисничким контекстом

Неки наслеђени системи покрећу послове „као корисник“, нпр. за SharePoint-аплоадове или извештаје. Из данашње перспективе то је ризично, јер меша улоге и приступна права. Ако замена није одмах могућа, примените прелазне мере: ограничени сервисни налози, јасне Named Locations, строге политике за лозинке и тајне (Secrets) и доследно евидентирање. И: планирајте миграцију на идентитете апликација као посебан радни пакет, не као „касније“.

Како документовати, одобрити и уклонити изузетке

Изузеци су у раду прихватљиви само ако имају животни циклус. Практично се показао лаган приступ који избегава бирократију, а ипак је ревизорски валидан:

1. Објашњење у једној реченици: Која пословна или оперативна функција зависи од тога (нпр. „Scan-to-Mail за локацију X“)?
2. Техничка класификација: Која апликација/протоколи, који налози, који путеви података?
3. Компензујуће контроле: Шта ограничава ризик (IP-ограничење, минимално неопходна права, monitoring)?
4. Датум истека: Сваки изузетак добија датум ревизије. Без ревизије биће уклоњен или поново одобрен.
5. Owner: Ко је одговоран ако нешто закаже или када изузетак истекне?

Тиме изузеци не постају „прави“, али постају управљиви. И управо то је у пракси разлика између робусне M365 безбедносне основе и хаотичне праксе правила.

Break-Glass-Accounts: Приступ у хитним случајевима без безбедносне рупе

Break-Glass налози су хитни налози за приступ Tenant-у када редовни администраторски приступи не функционишу — на пример због погрешне конфигурације у Conditional Access, прекида рада MFA-провајдера или Identity-Incident-а. Сврха је јасна, али имплементација има типичне замке: Break-Glass налог који никад није тестиран неће помоћи у стварној ситуацији. Break-Glass налог који је превише лако доступан је атрактивна мета напада.

Шта Break-Glass није

• Не редован администраторски налог: Не сме се користити у нормалном раду.
• Не складиште изузетака: Не замењује чист CA-дизајн.
• Не „имамо један, то је у реду“: Без процеса, тестирања и алармирања то је само теоретски план.

Основна начела за Break-Glass у раду

Практично решење се руководи трима циљевима: доступно у ванредним ситуацијама, тешко нападљиво током нормалног рада и јасно проверљиво.

• Најмање два налога: Редунданција против закључавања, погрешне употребе или компромитованих података за пријаву.
• Снажно заштићено: Дуге, случајне лозинке; без прослеђивања имејлова; без коришћења за апликације/интеграције.
• Искључено из CA по потреби — али строго: Уобичајено је изузеће од одређених CA-политика да у ванредном случају не бисте били закључани сопственим правилима. Истовремено треба да функционишу други безбедносни механизми: аларми при употреби, рестриктивно додељивање улога, одвојено чување приступних података.
• Евиденција и алармирање: Свака пријава мора одмах да покрене сигнал (SIEM/SOC или најмање E-Mail/Teams-аларм ка инцидентном поштанском сандучету). Коришћење Break-Glass-а је по дефиницији безбедносни догађај.

Кључно: Одлучите свесно да ли ће Break-Glass бити у функцији са или без MFA. Многе организације га остављају без MFA како би остале оперативне у случају пада MFA-а. У том случају компензационе контроле морају бити посебно строге (чување, приступ лозинци, алармирање, редовна промена). Алтернативно, Break-Glass се може опремити хардверским MFA-ом (нпр. FIDO2) који не зависи од мобилне мреже. Важно није „исправна“ идеологија, већ пут за ванредне ситуације који у вашем контексту заиста функционише.

Реалност имплементације: Како спречити закључавања и врхове у подршци

Многи CA-/MFA-увођења не пропадају због технике, већ због организације: прерано, прешироко, без телеметрије и без јасног процеса подршке. Стабилно увођење ради у таласима и са мерним тачкама.

Корак 1: Створите видљивост (пре него што блокирате)

Користите записе пријава (Sign-in Logs) и анализе да откријете: које апликације се користе? Који клијенти су „Legacy“? Које локације/IP-опсези су стварни? Који корисници имају посебно много проблема са пријавом? Без тих података је свака политика увођење наслепо.

Корак 2: Пилот-групе са стварним изузетним случајевима

Пилоти не би требали бити само „IT и неколико волонтера“. Свесно укључите и ивичне случајеве: теренске службе, производне локације, пројектни сарадници са гост приступом и бар један одељак са типичним алатима трећих страна. Циљ није хармонија, већ рано откривање правих препрека.

Корак 3: Helpdesk-Playbooks festlegen

Када се MFA захтева, број тикета расте: промена уређаја, изгубљени телефони, нови запослени, налог закључан након превише покушаја. Утврдите шта First-Level може да реши (нпр. ресет MFA након провере идентитета) и када се ради ескалација. Без playbookova све ескалира — и админи постају уски грло.

Schritt 4: Technische Nacharbeiten als eigenes Backlog

CA чини видљивим скривени технички дуг: застарели e-mail клијенти, недокументовани скенери, скрипте са лозинком у Task Scheduler, или интеграције које и даље користе Basic Auth. Планирајте те накнадне радове као видљиве радне пакете. У супротном ће остати као „трајни изузетак“.

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

У свакодневици вреде брзе хипотезе. Неки обрасци се понављају:

„Plötzlich geht Outlook nicht mehr“

Чести узроци: legacy-клијент, стари профил, или CA-блок због недостатка статуса уређаја. Проверите: тип клијента у Sign-in Log, примењена CA-политика и да ли се уређај води као usaglašen/compliant. Оперативни фикс ретко је „искључи политику“, већ „модернизуј клијента“ или „среди управљање уређајима“.

„Service XY kann keine E-Mails mehr senden“

Често је у позадини промена SMTP-аутентификације, промењена relay-политика или ново CA-правило које ненамерно погађа и техничке налоге. Овде помаже јасна архитектонска одлука: слање преко relay/connector-а уместо пријаве корисника, уз IP-рестракцију и логовање (што омогућава реконструкцију у incident-у).

„Admin kommt nicht mehr in den Tenant“

То је тренутак за који је Break-Glass предвиђен. Ако и Break-Glass приступ не функционише, обично недостаје тестиран пут за хитне случајеве или је изузетак погрешно конфигурисан. Зато: редовно увежбавајте коришћење (са документацијом ко када тестира и како изгледа аларм).

„Zu viele Ausnahmen – niemand blickt durch“

То је governance-проблем. Консолидујте политике, дефинишите ритуал прегледа (нпр. месечно 30 минута) и уклоните изузетке који више немају owner/сврху. Технички то није гламурозно, али је разлика између контролисане безбедности и историјски нарастајућих посебних права.

Monitoring und Nachvollziehbarkeit: Was Sie wirklich brauchen

CA и MFA генеришу много догађаја. Ако све сакупљате, нећете моћи да се снађете; ако ништа не анализирате, проблеме ћете уочити прекасно. Практично корисне су три нивое:

• Alarmierung auf harte Ereignisse: Break-Glass-prijava, admin-prijava из необичних земаља, блок-евенти на критичним апликацијама.
• Regelmäßige Reviews: најчешћи разлози блокада, корисници са највише проблема са MFA, покушаји legacy-аутентификације, нове апликације/enterprise апликације.
• Audit-Spur für Ausnahmen: ко је који изузетак одобрио, са којим датумом истека и када је то прегледано?

Ако већ имате централне процесе за логовање и инциденте (SIEM, Ticketing, Change-Management), укључите измене CA у те процесе. Conditional Access није „мало подешавање“, већ продукцијски критичан слој приступа.

Aufwand und Verantwortlichkeiten: Wer muss was liefern?

CA-/MFA-пројекти се потцењују јер делују као чиста конфигурација. У стварности су то пројекти интеграције између идентитета, крајњих уређаја, мреже и пословних процеса. Јасан модел одговорности смањује трење:

• Identity-Team / Entra Admins: дизајн политика, модел улога, Break-Glass, регистрације апликација.
• Client-Management (npr. Intune): definicija usklađenosti, status uređaja, uvođenje Authenticator/Passkeys, životni ciklus uređaja.
• Mreža: IP-opsezi za Named Locations, izuzeci za proxy/TLS-inspekciju, promena lokacije.
• Service Owner poslovnih aplikacija: putanje integracije (Graph/SMTP/SharePoint), prelazak sa legacy autentifikacije, rotacija tajni.
• Хелпдеск: standardni procesi za MFA-reset, zamenu uređaja, onboarding/offboarding.

Najvažnija menadžerska odluka često nije „MFA da/ne“, već: imamo li vreme i resurse za naknadne radove (uklanjanje legacy-a, modernizaciju integracija, stabilizaciju upravljanja uređajima)? Bez tih radova bezbednosni dobitak ostaje ispod očekivanja — ili operativni rad postaje nepotrebno otežan.

Zaključak: Bezbednost jača kada hitni slučaj i izuzetak postanu deo sistema

Ispravno osiguravanje Microsoft 365 znači koristiti Conditional Access kao centralni sloj upravljanja — ne kao jednokratnu konfiguraciju. MFA je pritom obavezna, ali prava operativna kvaliteta nastaje kroz uredne izuzetke (sa datumom isteka, vlasnikom i kompenzacionim kontrolama) i kroz Break-Glass naloge koji se testiraju, nadgledaju i organizaciono uklope. Ko poveže ova tri elementa, smanjuje rizike naloga, postiže revizijsku sposobnost bez dodatnog opterećenja i sprečava da bezbednosna pravila u incidentu postanu sopstveni protivnik.

Razgovarajte o projektu ili modernizacionom poduhvatu sa Net-Base.