Conditional Access: kdo potřebuje licenci

Správce přidá jednu licenci Business Premium, otevře nastavení Conditional Access a vytvoří pravidlo pro všechny zaměstnance. V administraci to jde. Znamená to, že je celé prostředí správně licencované? Ne. Technická dostupnost pravidla a právo uživatelů využívat jeho funkce se posuzují odděleně.

Conditional Access rozhoduje o přístupu podle podmínek přihlášení. Firma může například vyžadovat další ověření nebo určité vlastnosti zařízení. Běžné uživatelské scénáře vyžadují Microsoft Entra ID P1; pravidla založená na riziku potřebují odpovídající oprávnění P2. Základním rozcestníkem je aktuální licencování Microsoft Entra.

Začněte účelem pravidla

Podmíněný přístup není jedna univerzální bezpečnostní volba. Před návrhem si napište větu: „Tato skupina lidí může přistupovat k této službě pouze za těchto podmínek.“ Pokud větu neumíte dokončit, budete obtížně posuzovat licenci i dopad změny.

Rozlišujte přihlášení běžného zaměstnance, správce, externího hosta a aplikace. Nejde o zaměnitelné identity. Tento článek se zaměřuje na interní uživatele; externí identity a workload identity mají vlastní licenční a technické podmínky.

Také oddělte signál, který chcete použít, od produktu, jenž jej poskytuje. Vyžadovat vyhovující zařízení není pouze otázka Entra. Musíte vědět, jak se stav zařízení určí a zda je tato část řešení licencovaná.

Jak spočítat rozsah

Vezměte uživatele a skupiny zahrnuté do pravidla. Zkontrolujte výjimky, další pravidla a skutečná přihlášení. Počet zakoupených licencí nemá být odvozen pouze od počtu lidí v bezpečnostním týmu.

Hypotetický příklad: společnost má 60 interních zaměstnanců, deset z nich Business Premium a ostatní Business Standard. Pravidlo vyžadující MFA se má přes Conditional Access vztahovat na všech 60. Vyhodnotit musíte oprávnění celé cílové skupiny, nejen deseti uživatelů s Premium.

Není nutné všem automaticky kupovat stejnou sadu. U každé role zjistěte, zda potřebné oprávnění už obsahuje její produkt, zda lze vhodně doplnit samostatnou licenci a které další služby opravdu využívá. Výsledek zaznamenejte po uživatelích nebo udržovaných skupinách.

Co porovnávat při návrhu

Tabulka je kontrolní pomůcka, nikoli kompletní produktový ceník. U nákupu potvrďte přesné SKU, dostupné služby a cílovou populaci.

Security defaults mohou být vhodný začátek

Microsoft nabízí i security defaults. Pro jednoduché prostředí mohou být rozumným základem. Jejich použití ale neznamená, že máte stejnou flexibilitu jako u vlastních pravidel Conditional Access.

Přechod plánujte jako změnu ochrany přihlášení. Zaznamenejte, co dnešní stav zajišťuje a který nový mechanismus to převezme. Neodstraňujte dosavadní ochranu jen proto, abyste si v klidu zkoušeli nové rozhraní.

U malé firmy si srovnejte potřeby: stačí jí jednotná výchozí ochrana, nebo má rozdílné požadavky na pobočky, citlivé aplikace či správu zařízení? Složitější konfigurace má smysl, když řeší doložený problém a někdo ji bude dlouhodobě spravovat.

Pravidla se skládají, nevybírá se jedno vítězné

Uživatel může spadat do více pravidel. Microsoft popisuje jejich souběh v dokumentaci Conditional Access policies. Při diagnostice proto kontrolujte všechny použitelné zásady.

Pravidlo požadující MFA nemusí vyřešit situaci, kdy jiné pravidlo přístup blokuje nebo navíc vyžaduje vyhovující zařízení. Správce pak často zbytečně přeřazuje licence, přestože problém vzniká v kombinaci podmínek.

Pro každou pracovní roli si sepište očekávané cesty přihlášení: notebook, telefon, web, firemní aplikace. Tento seznam použijte jako testovací scénáře. Úspěch na jednom správcovském notebooku ještě nepotvrzuje, že zítra bude fungovat práce celé firmy.

Bezpečný postup zavedení

1. Exportujte stávající zásady a popište jejich účel.
2. Zkontrolujte licence cílových uživatelů a potřebných souvisejících služeb.
3. Vyberte pilotní skupinu zahrnující běžné pracovní scénáře.
4. Použijte režim report-only tam, kde odpovídá testu, a vyhodnoťte přihlášení.
5. Ověřte připravenost uživatelů a podporu používaných klientů.
6. Zapněte pravidlo pro pilot a sledujte skutečné dopady.
7. Rozšiřujte po skupinách s připraveným postupem návratu.

V report-only se pravidlo vyhodnocuje bez běžného vynucení jeho požadavků. Režim slouží k posouzení dopadu; nepovažujte jej za už nasazenou ochranu. Podrobnosti a omezení popisuje Microsoft v dokumentaci report-only.

Jak řešit blokované přihlášení

Požádejte o čas, účet, aplikaci a zařízení. V přihlašovacích protokolech zjistěte, která zásada rozhodnutí způsobila. Nezačínejte plošným přidáváním lidí do výjimek.

V praxi bývají v jednom incidentu smíchané různé věci: chybějící registrace ověření, starý klient, nesprávný stav zařízení nebo zásada cílená na jinou skupinu, než správce zamýšlel. Vyřešte potvrzenou příčinu a zopakujte původní pracovní úkol.

Každá nutná výjimka má mít důvod, vlastníka a datum přezkoumání. Bez těchto údajů se dočasná oprava postupně mění v trvalou mezeru v ochraně.

Co hlídat v prostředí s různými licencemi

Smíšené licence vyžadují přehled skupin a produktů. Pokud člověk změní roli, nemusí se změnit jen licence. Může vstoupit do jiné cílové skupiny a začít podléhat zásadě, pro kterou nový produkt nestačí.

Spojte proto schvalování role, přidělování produktů a bezpečnostní rozsah. Změnu ověřte z obou stran: uživatel má oprávnění a politika se skutečně uplatní. Jedna zelená položka v licenčním přehledu nepokrývá celý proces.

Praktický výstup kontroly

Vytvořte jednoduchou vazbu: zásada → pracovní role → cíloví uživatelé → potřebná oprávnění → test přihlášení. Přehled pravidelně aktualizujte při nástupech, odchodech a změnách rolí. Tím předejdete situaci, kdy správně fungující politika přestane odpovídat licencím.