Správné zabezpečení Microsoft 365: Conditional Access, výjimky MFA a Break-Glass účty v praxi

Kdo chce Microsoft 365 správně zabezpečit, neobejde se bez Conditional Access (politiky závislé na přístupu v Entra ID, dříve Azure AD) a vícefaktorové autentizace (MFA, tedy přihlášení pomocí minimálně dvou faktorů). V mnoha společnostech jsou MFA a první pravidla Conditional Access rychle zapnuta – a teprve potom práce začíná: výjimky je třeba odůvodnit, nouzové přístupy uspořádat přehledně a provozní procesy navrhnout tak, aby bezpečnost nepřerostla v lavinu servisních požadavků.

V praxi selhává „zabezpečení M365“ zřídka kvůli zásadní technologii, častěji kvůli každodenním problémům: servisní účty pro rozhraní, legacy protokoly, terénní pracovníci bez spolehlivé mobilní sítě, administrátoři s příliš širokými právy, nebo incident, při kterém právě bezpečnostní opatření zablokuje IT přístup. Tento článek vysvětluje, jak Conditional Access, výjimky MFA a break-glass účty spolupracují – a jak to provozovat tak, aby to po Go-live zůstalo spolehlivé.

Proč je Conditional Access páka — a proč samotné MFA nestačí

MFA výrazně snižuje riziko odcizených hesel, ale MFA není kompletní koncepce přístupu. Conditional Access (CA) rozhoduje kontextově, za jakých podmínek je přístup povolen: např. pouze z řízených zařízení, pouze z určitých zemí, pouze na základě hodnocení rizika nebo pouze s určitými klientskými aplikacemi. To je rozhodující krok směrem k Zero Trust (bezpečnostnímu modelu, ve kterém se přístupu implicitně nedůvěřuje, ale průběžně se ověřuje).

Typické důvody, proč samotné MFA v Microsoft 365 nestačí:

• Token místo hesla: Moderní autentizace pracuje s tokeny (časově omezená přístupová oprávnění). Ukradený token může obejít MFA, pokud CA nepožaduje další podmínky (např. stav zařízení nebo řízení relace).
• Riziko u adminů: Administrativní účty jsou obzvlášť atraktivní. Bez CA pravidel pro administrativní přístupy (např. pouze z administrátorských pracovních stanic nebo pouze s MFA odolným proti phishingu) zůstává největší útočná plocha otevřená.
• „Povolené“ je příliš široké: Když CA nerozlišuje mezi aplikacemi, třídami dat a typy přístupu, bezpečnost se rychle stane buď příliš laxní, nebo příliš RESTriktivní — obojí způsobí problémy.

Operační jádro je tedy: CA jako vrstva politik, MFA jako součást této vrstvy, plus čisté řízení výjimek a odolné nouzové cesty.

Přehled architektury: Co Conditional Access v Entra ID skutečně řídí

Pro vedení IT a provoz je důležité nepochopit CA jako „jednu politiku“, ale jako řetězec rozhodnutí. Entra ID při každém přihlášení vyhodnocuje signály a aplikuje politiky. Důležité signály jsou:

• Identita: uživatelé, skupiny, role (např. privilegované role jako Global Administrator).
• Cílový zdroj: cloudová aplikace (Exchange Online, SharePoint/OneDrive, Teams, ale také třetí strany přes Enterprise App).
• Typ klienta: prohlížeč, moderní klienti, mobilní aplikace, stejně jako „Legacy Authentication“ (starší protokoly bez moderních tokenů, např. starší varianty IMAP/POP/SMTP autentizace).
• Stav zařízení: „Compliant“ nebo „hybrid joined“ (spravované zařízení, typicky přes Intune nebo připojení do domény s informací o stavu zařízení).
• Síť/Lokalita: Named Locations (definované rozsahy IP), země/regiony, indikátory rizika.
• Podmínky relace: Session Lifetime, App-Enforced RESTrictions, Continuous Access Evaluation (průběžné přehodnocování při rizikových událostech).

Z provozního hlediska závisí kvalita vaší konfigurace CA výrazně na tom, zda jsou tyto signály spolehlivé. Pojmenované umístění je tak dobré, jak dobrá je vaše hygiena IP adres. „Compliant“ je tak dobré, jak dobrá je správa zařízení a definice shody. A hodnocení rizik je užitečné jen tehdy, když s vyvolanými událostmi skutečně pracujete.

Microsoft 365 správně zabezpečit pomocí Conditional Access: Prakticky použitelná sada zásad

Místo jedné „velké“ zásady funguje v praxi lépe sada několika jasně ohraničených politik. To snižuje vedlejší účinky a usnadňuje vyhledávání chyb při incidentech. Osvědčený základní vzor se skládá z:

1) Základní politika pro všechny uživatele: vynutit MFA, blokovat legacy

Pro běžné uživatelské účty platí základ: vyžadovat MFA a blokovat Legacy Authentication. „Legacy“ zde není „zastaralé“ v logickém smyslu, ale technicky problematické: tyto protokoly často nepodporují moderní MFA výzvu a jsou proto klasickým vstupním bodem pro password spraying.

Důležité: Legacy neblokujte „někdy“, ale naplánujte přechodné období s měřením. Kontrolujte v záznamech přihlášení (Sign-in Logs), které klienty stále používají legacy. V podnicích jsou na to často napojené multifunkční tiskárny, skenování do mailu nebo starší mailoví klienti ve speciálních prostředích.

2) Admin-Policy: výrazně přísnější než základ

Privilegované role by měly mít vlastní politiku: přístup pouze z definovaných administračních koncových zařízení (např. „compliant“ a případně samostatná strategie admin-workstation), MFA s vysokou úrovní bezpečnosti (odolné proti phishingu, např. FIDO2/Passkey nebo certifikátově založené), a pokud možno omezení pro rizikové země/lokace. I když ne každá organizace zavádí okamžitě plnou Privileged-Access-architekturu (PAM, tedy řízení privilegovaného přístupu), tento rozdíl se vyplatí hned: kompromitovaný administrátorský účet znamená odlišný rozsah škody než kompromitovaný uživatelský účet.

3) Politika pro externí spolupráci a hosty

Hostovské přístupy (B2B Collaboration) často vytvářejí neočekávané datové cesty: hosté stahují soubory ze SharePoint, pracují v Teams nebo přistupují k projektovým portálům. Rozhodně určete, zda smí hosté vstoupit jen s MFA, které aplikace jsou vyloučené a jak dlouho jsou platné relace. Pro projektovou práci je často rozumná kratší délka relace, aby se snížilo riziko „zapomenutých přihlášení“.

4) Politika pro citlivé datové toky: zabezpečit zařízení nebo relaci

Praktický provoz má různé potřeby ochrany: obchodní zástupce si možná může z libovolného zařízení číst e-maily, ale bez spravovaného zařízení by neměl stahovat velké objemy dat ze SharePoint. Takové rozdíly nezachytíte paušálním „povoleno/zakázáno“, ale kombinacemi CA: „přístup povolen, pokud je zařízení compliant“ nebo „přístup pouze přes prohlížeč se zúženou relací“. To je méně tvrdé než úplné zablokování – a přesto efektivní.

Výjimky z MFA: Kde jsou realistické – a jak je kontrolovat

Výjimky z MFA nejsou známkou slabosti, pokud jsou navrženy vědomě a provozně kontrolovány. Bez kontrolovaných výjimek vznikají stínová řešení: uživatelé obcházejí procesy, administrátoři hekticky vypínají pravidla a časem už není soubor politik dohledatelný.

Důležité je rozlišení: Výjimka z MFA zřídkakdy znamená „bez MFA“, častěji jde o „MFA jinak“ nebo „přístup pouze za jiných podmínek“. Typické kategorie výjimek:

Případ výjimky 1: Neinteraktivní přístupy a rozhraní

Mnoho procesně blízkých softwarových řešení integruje služby M365: odesílání e-mailů, přístup ke kalendáři, ukládání souborů ve SharePointu, notifikace v Teams nebo přístupy přes Graph API. Takové integrace by neměly běžet přes uživatelské účty s deaktivovaným MFA. Výhodnější je technický přístup přes registrace aplikací (aplikace v Entra ID) s jasně definovanými oprávněními a životním cyklem secretů/certifikátů. Nejedná se o „MFA-výjimku“, ale o jiný způsob autentizace, který je lépe auditovatelný.

Provozní důsledky: secrety je třeba rotovat, certifikáty vyprší a oprávnění je nutné recertifikovat. Pokud plánujete integrace, definujte vlastníka (kdo obnovuje certifikáty/secrety) a monitoring (např. varování před vypršením). Jinak se z „bezpečné“ autentizace aplikace stane neplánovaný výpadek.

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

Řeší se zde klasické diskuse kolem SMTP‑relaye, Scan‑to‑Mail nebo schránek místností. Špatné řešení je téměř vždy „uživatelský účet bez MFA“. Lepší jsou technické cesty, které nezávisí na interaktivním přihlášení: centrální mail‑relay s IP‑RESTrikcí, přístupy založené na certifikátech nebo konektorech, nebo oddělené systémové schránky s úzkými oprávněními. Rozhodující je: zařízení samo o sobě MFA nemůže obsloužit, proto musí být návrh zabezpečen na transportní a síťové úrovni.

Ausnahmefall 3: Notbetrieb und eingeschränkte Erreichbarkeit

Terénní servis, výroba nebo směnný provoz mají situace bez signálu mobilní sítě nebo bez soukromých mobilních zařízení. Stojí za to včas přemýšlet o alternativních MFA metodách: hardwarové tokeny, FIDO2 bezpečnostní klíče nebo Windows Hello for Business (zařízenívázané přihlášení). „Dočasné vypnutí MFA“ je provozně lákavé, ale špatně škáluje a těžko se audituje.

Ausnahmefall 4: Automatisierte Jobs mit Benutzerkontext

Některé legacy systémy spouštějí joby „jako uživatel“, např. pro nahrávání do SharePointu nebo generování reportů. Z dnešního pohledu je to rizikové, protože to míchá role a přístupová práva. Pokud není okamžitá náhrada možná, pracujte s mezistupni: omezená service‑konta, jasné Named Locations, přísné politiky hesel/secrety a důsledné protokolování. A: naplánujte migraci na identitu aplikace jako samostatný pracovní balík, ne jako „později“.

Wie man Ausnahmen dokumentiert, genehmigt und wieder loswird

Výjimky jsou v provozu přijatelné jen pokud mají životní cyklus. V praxi se osvědčil lehký postup, který nevyžaduje byrokracii, ale přesto je auditovatelný:

1. Begründung in einem Satz: Která obchodní nebo provozní funkce na tom závisí (např. „Scan-to-Mail an Standort X“)?
2. Technische Einordnung: Která aplikace/protokoly, které účty, jaké datové toky?
3. Kompensierende Kontrollen: Co omezuje riziko (IP‑RESTrikce, minimální nutná práva, monitoring)?
4. Ablaufdatum: Každá výjimka dostane datum přezkoumání. Bez přezkoumání bude odstraněna nebo znovu schválena.
5. Owner: Kdo je odpovědný, pokud něco zadrhne nebo pokud výjimka vyprší?

Tím se výjimky nestanou „dobrými“, ale stanou se řiditelnými. A právě to je v praxi rozdíl mezi robustní základnou zabezpečení M365 a neřízeným množstvím výjimek v pravidlech.

Break-Glass-Accounts: Notfallzugang ohne Sicherheitsloch

Break-Glass účty jsou nouzové účty pro přístup k tenantovi, když běžné administrátorské přístupy nefungují – například kvůli chybné konfiguraci v Conditional Access, výpadku poskytovatele MFA nebo incidentu v oblasti identity. Účel je jasný, ale realizace skrývá typické nástrahy: Break-Glass účet, který nikdy není testován, v nouzi nepomůže. Break-Glass účet, který je příliš snadno dostupný, je atraktivním cílem útoku.

Co Break-Glass není

• Nejde o běžný administrátorský účet: Nesmí být používán v normálním provozu.
• Ne zásobník výjimek: Ne nahrazuje čistý CA-Design.
• Ne „máme jeden, to stačí“: Bez procesu, testu a upozornění je to jen teoretický plán.

Základní principy Break-Glass v provozu

Funkční nastavení se řídí třemi cíli: dostupné v nouzi, v normálním provozu těžko napadnutelné a jasně dohledatelné.

• Minimálně dva účty: Redundance proti zablokování, chybné obsluze nebo kompromitovaným přihlašovacím údajům.
• Silně zabezpečeno: Dlouhá, náhodná hesla; žádné přesměrování e-mailů; žádné použití pro aplikace/integrace.
• Úmyslně vyjmuté z CA – ale úzce: Typicky jde o výjimku z určitých CA-politik, aby vás v nouzi nevyřadila vlastní pravidla. Současně by měly fungovat další bezpečnostní mechanismy: upozornění při použití, RESTriktivní přidělení rolí, oddělené uložení přihlašovacích údajů.
• Logování a upozornění: Každé přihlášení musí vyvolat okamžitý signál (SIEM/SOC nebo alespoň e-mail/Teams upozornění na incidentní schránku). Použití Break-Glass je ze své podstaty bezpečnostní událost.

Centrální bod: Rozhodněte se vědomě, zda provozovat Break-Glass s MFA nebo bez MFA. Mnoho organizací jej nechává bez MFA, aby při výpadku MFA zůstaly schopné jednat. Pak ale musí být kompenzační kontroly zvlášť důkladné (uložení, přístup k heslu, upozornění, pravidelná výměna). Alternativně lze Break-Glass vybavit hardwarovým MFA (např. FIDO2), které je nezávislé na mobilních sítích. Důležité není „správné“ ideologické přesvědčení, ale nouzová cesta, která ve vašem kontextu skutečně funguje.

Realita nasazení: Jak se vyhnout uzamknutí účtů a špičkám v podpoře

Mnoho CA-/MFA-nasazení nezkrachuje technicky, ale organizačně: příliš rychle, příliš široce, bez telemetrie a bez jasného podpůrného procesu. Stabilní nasazení pracuje ve vlnách a s měřicími body.

Krok 1: Vytvořit přehled (před tím, než začnete blokovat)

Využijte Sign-in-Logs a vyhodnocení, abyste zjistili: Které aplikace se používají? Kteří klienti jsou „Legacy“? Která umístění/IP rozsahy jsou reálná? Kteří uživatelé mají zvlášť mnoho problémů s přihlášením? Bez těchto dat je každá politika naslepo.

Krok 2: Pilotní skupiny se skutečnými okrajovými případy

Pilotní skupiny by neměly být jen „IT a pár dobrovolníků“. Zahrňte cíleně okrajové případy: terénní pracovníci, výrobní provozy, projektoví pracovníci s hostovským přístupem a alespoň jedno oddělení používající typické nástroje třetích stran. Cílem není harmonie, ale včasné nalezení skutečných úskalí.

Krok 3: Stanovte playbooky helpdesku

Když je vyžadováno MFA, počet ticketů roste: výměny zařízení, ztracená telefony, noví zaměstnanci, účet zablokovaný po příliš mnoha pokusech. Stanovte, co může vyřešit první úroveň podpory (např. MFA reset po ověření identity) a kdy se má eskalovat. Bez playbooků eskaluje všechno – a administrátoři se stanou úzkým hrdlem.

Krok 4: Technické následné práce jako samostatný backlog

CA odhaluje skrytý technický dluh: zastaralé mailové klienty, nedokumentované skenery, skripty s heslem v Task Scheduler, nebo integrace, které stále používají Basic Auth. Naplánujte tyto následné práce jako viditelné pracovní balíky. Jinak zůstanou jako „trvalá výjimka“.

Typické chybové scénáře z provozu – a jak je rychleji zařadit

V každodenním provozu platí rychlé hypotézy. Některé vzory se opakují:

„Najednou Outlook přestal fungovat“

Časté příčiny: legacy klient, starý profil, nebo blok CA kvůli chybějícímu stavu zařízení. Zkontrolujte: typ klienta v Sign-in Logu, uplatněná CA‑policy a zda je zařízení vedeno jako compliant. Operační oprava málokdy znamená „politiku vypnout“, spíše „modernizovat klienta“ nebo „udělat pořádek v řízení zařízení“.

„Služba XY už nemůže odesílat e-maily“

Často za tím stojí změna SMTP autentizace, upravená relay‑policy nebo nová CA pravidla, která omylem zasáhnou i technické účty. Pomůže jasné architektonické rozhodnutí: odesílání přes Relay/Connector místo přihlášení uživatele, s IP omezením a loggingem (sledovatelnost v incidentu).

„Admin se už nedostane do Tenantu“

To je moment, pro který je určen Break-Glass. Pokud Break-Glass přístup také nefunguje, obvykle chybí otestovaná nouzová cesta nebo byla výjimka chybně nastavena. Proto: pravidelně cvičit použití (s dokumentací, kdo kdy testuje a jak vypadá alarm).

„Příliš mnoho výjimek – nikdo se v tom nevyzná“

To je governance problém. Konsolidujte politiky, definujte review‑rituál (např. měsíčně 30 minut) a odstraňte výjimky, které už nemají vlastníka nebo účel. Technicky to není efektní, ale je to rozdíl mezi kontrolovatelnou bezpečností a historicky vzniklými zvláštními právy.

Monitoring a sledovatelnost: co skutečně potřebujete

CA a MFA generují mnoho událostí. Když budete sbírat vše, zadusíte se; když nebudete nic vyhodnocovat, problémy si všimnete pozdě. Prakticky smysluplné jsou tři úrovně:

• Upozornění na kritické události: Break-Glass‑login, admin‑login z neobvyklých zemí, block‑události na kritických aplikacích.
• Pravidelné revize: hlavní důvody blokací, uživatelé s nejvíce MFA problémy, pokusy o legacy‑auth, nové aplikace/Enterprise Apps.
• Auditní stopa pro výjimky: kdo jakou výjimku schválil, s jakým datem vypršení a kdy byla revidována?

Pokud již máte centralizované logování a incidentní procesy (SIEM, ticketing, change‑management), ukotvěte tam změny CA. Conditional Access není „malé nastavení“, ale provozně kritická přístupová vrstva.

Náklady a odpovědnosti: kdo má co dodat?

Projekty CA/MFA se podceňují, protože působí jako čistá konfigurace. Ve skutečnosti jsou to integrační projekty mezi identitou, koncovými zařízeními, sítí a business procesy. Čistý model odpovědností snižuje tření:

• Identity‑Team / Entra Admins: návrh politik, model rolí, Break‑Glass, registrace aplikací.
• Správa klientů (např. Intune): definice compliance, stav zařízení, nasazení Authenticator/Passkeys, životní cyklus zařízení.
• Síť: IP rozsahy pro Named Locations, výjimky pro Proxy/TLS inspekci, změny umístění.
• Service Owner podnikových aplikací: integrační cesty (Graph/SMTP/SharePoint), přechod z Legacy-Auth, rotace secretů.
• Helpdesk: standardní procesy pro reset MFA, změnu zařízení, onboarding/offboarding.

Nejdůležitější rozhodnutí managementu často není „MFA ano/ne“, ale: Máme čas a zdroje na následné práce (odstranění legacy, modernizace integrací, stabilizace správy zařízení)? Bez této práce zůstane bezpečnostní přínos za očekáváním – nebo bude provoz zbytečně náročný.

Závěr: Bezpečnost se posiluje, když jsou nouzové postupy a výjimky součástí systému

Správné zabezpečení Microsoft 365 znamená provozovat Conditional Access jako centrální řídicí vrstvu – ne jako jednorázovou konfiguraci. MFA je přitom povinná, ale skutečná kvalita provozu vzniká díky přesným výjimkám (s datem expirace, Ownerem a kompenzačními kontrolami) a díky Break-Glass-Accounts, které jsou testovány, monitorovány a organizačně začleněny. Kdo tyto tři prvky pojme souborně, snižuje rizika účtů, získá auditovatelnost bez nadbytečné režie a zabrání tomu, aby se bezpečnostní pravidla během incidentu stala vlastním protivníkem.

Projednat projekt nebo modernizační záměr s Net-Base.