Podmíněný přístup: Cílové prostředky

Cílové prostředky (dříve cloudové aplikace, akce a kontext ověřování) jsou klíčovými signály v zásadách podmíněného přístupu. Zásady podmíněného přístupu umožňují správcům přiřazovat ovládací prvky ke konkrétním aplikacím, službám, akcím nebo kontextu ověřování.

• Správci si můžou vybrat ze seznamu aplikací nebo služeb, které zahrnují vestavěné aplikace Microsoft a všechny aplikace integrované s Microsoft Entra, včetně galerie, jiné než galerie a aplikací publikovaných prostřednictvím Application Proxy.
• Správci můžou definovat zásady na základě akce uživatele , jako je registrace bezpečnostních informacínebo registrace nebo připojení zařízení, a umožnit podmíněnému přístupu vynutit ovládací prvky týkající se těchto akcí.
• Správci můžou cílit na profily předávání přenosů z globálního zabezpečeného přístupu pro vylepšené funkce.
• Správci můžou pomocí kontextu ověřování poskytnout další vrstvu zabezpečení v aplikacích.

Cloudové aplikace Microsoftu

Správci mohou cloudovým aplikacím Microsoftu přiřadit zásady podmíněného přístupu, pokud se služební objekt zobrazí v jejich tenantovi, s výjimkou Microsoft Graphu. Microsoft Graph funguje jako zastřešující prostředek. Pomocí vytváření sestav cílové skupiny můžete zobrazit základní služby a cílit na tyto služby ve vašich zásadách. Některé aplikace jako Office 365 a rozhraní API pro správu služeb Windows Azure zahrnují několik souvisejících podřízených aplikací nebo služeb. Když se vytvoří nové cloudové aplikace Microsoftu, zobrazí se v seznamu aplikací hned po vytvoření služby service principal v tenantovi.

Office 365

Microsoft 365 nabízí cloudové služby pro produktivitu a spolupráci, jako jsou Exchange, SharePoint a Microsoft Teams. Cloudové služby Microsoftu 365 jsou hluboce integrované, aby se zajistilo bezproblémové prostředí a prostředí pro spolupráci. Tato integrace může způsobit nejasnosti při vytváření zásad, protože některé aplikace, jako je Microsoft Teams, závisejí na jiných aplikacích, jako je SharePoint nebo Exchange.

Seskupování aplikací Office 365 umožňuje cílit všechny tyto služby najednou. Místo cílení na jednotlivé cloudové aplikace doporučujeme používat seskupení Office 365, abyste se vyhnuli problémům se závislostmi služeb.

Cílení na tuto skupinu aplikací pomáhá vyhnout se problémům, ke kterým může dojít kvůli nekonzistentním zásadám a závislostem. Příklad: Aplikace Exchange Online je svázaná s tradičními daty Exchange Online, jako je pošta, kalendář a kontaktní údaje. Související metadata můžou být zpřístupněna prostřednictvím různých prostředků, jako je vyhledávání. Aby bylo zajištěno, že všechna metadata jsou chráněná podle očekávání, měli by správci přiřadit zásady k aplikaci Office 365.

Správci můžou vyloučit celou sadu Office 365 nebo konkrétní cloudové aplikace Office 365 ze zásad podmíněného přístupu.

Úplný seznam všech zahrnutých služeb najdete v článku Aplikace zahrnuté v sadě aplikací Office 365 s podmíněným přístupem.

Správa služeb Windows Azure API

Když cílíte na aplikaci rozhraní API pro správu služeb Windows Azure, zásady se vynucují pro tokeny vydané sadou služeb úzce svázaných s portálem. Toto seskupení zahrnuje ID aplikací:

• Azure Resource Manager
• Azure Portal, který se zabývá také centrem pro správu Microsoft Entra a Centrem Microsoft Engage Center
• Azure Data Lake
• Rozhraní API pro Application Insights
• Rozhraní API služby Log Analytics

Vzhledem k tomu, že se zásady použijí na portál pro správu Azure a rozhraní API, můžou být nepřímo ovlivněny všechny služby nebo klienty závislé na rozhraní Azure API. Například:

• Azure CLI
• Portál služby Azure Data Factory
• Azure Event Hubs
• Azure PowerShell
• Azure Service Bus
• Azure SQL Database
• Azure Synapse
• Rozhraní API modelu nasazení Classic
• Centrum pro správu Microsoft 365
• Microsoft IoT Central
• Správa víceklientských aplikací v programu Microsoft Defender
• SQL Managed Instance
• Portál pro správu předplatných sady Visual Studio

Upozornění

Zásady podmíněného přístupu přidružené k rozhraní API pro správu služeb Windows Azure už nepokrývají Azure DevOps.

Note

Aplikace pro správu služeb Windows Azure API se vztahuje na Azure PowerShell, který volá API Azure Resource Manageru. Nevztahuje se na Microsoft Graph PowerShell, který volá Microsoft Graph API.

Tip

V případě azure Government byste měli cílit na aplikaci API pro správu cloudu Azure Government.

Portály pro správu Microsoftu

Když zásady podmíněného přístupu cílí na cloudovou aplikaci portálů pro správu Microsoftu, zásady se vynucují pro tokeny vydané pro ID aplikací následujících portálů pro správu Microsoftu:

• Azure Portal
• Centrum pro správu Exchange
• Centrum pro správu Microsoft 365
• Portál Microsoft 365 Defender
• Centrum pro správu Microsoft Entra
• Centrum pro správu Microsoft Intune
• Portál pro dodržování předpisů Microsoft Purview
• Centrum pro správu Microsoft Teams

Do seznamu neustále přidáváme další portály pro správu.

Jiné aplikace

Správci můžou do zásad podmíněného přístupu přidat libovolnou zaregistrovanou aplikaci Microsoft Entra. Mezi tyto aplikace můžou patřit:

• Aplikace publikované prostřednictvím Microsoft Entra application proxy
• Aplikace přidané z galerie
• Vlastní aplikace, které nejsou v galerii
• Starší verze aplikací publikované prostřednictvím kontrolerů a sítí pro doručování aplikací
• Aplikace využívající jednotné přihlašování založené na heslech

Note

Vzhledem k tomu, že zásady podmíněného přístupu nastavují požadavky pro přístup ke službě, nemůžete ji použít pro klientskou (veřejnou/nativní) aplikaci. Jinými slovy, zásada není nastavená přímo v aplikaci klienta (veřejné/nativní), ale použije se, když klient volá službu. Například zásada nastavená ve službě SharePoint platí pro všechny klienty, kteří volají SharePoint. Na pokusy o přístup k e-mailu pomocí klienta Outlook se vztahují zásady nastavené pro Exchange. To je důvod, proč nejsou klientské (veřejné nebo nativní) aplikace dostupné pro výběr v nástroji pro výběr aplikace a možnost podmíněného přístupu nejsou k dispozici v nastavení aplikace pro klient (veřejné nebo nativní) aplikace zaregistrované ve vašem tenantovi.

Některé aplikace se ve výběru vůbec nezobrazují. Jediným způsobem, jak tyto aplikace zahrnout do zásad podmíněného přístupu, je zahrnout všechny prostředky (dříve Všechny cloudové aplikace) nebo přidat chybějící instanční objekt pomocí rutiny Prostředí PowerShell New-MgServicePrincipal nebo pomocí rozhraní Microsoft Graph API.

Principy podmíněného přístupu pro různé typy klientů

Podmíněný přístup se vztahuje na prostředky, nikoli na klienty, kromě případů, kdy je klient důvěrným klientem požadujícím ID token.

• Veřejný klient
  • Veřejné klienty jsou klienti, kteří běží místně na zařízeních, jako je Microsoft Outlook na stolních nebo mobilních aplikacích, jako je Microsoft Teams.
  • Zásady podmíněného přístupu se nevztahují na samotné veřejné klienty, ale jsou založené na požadovaných prostředcích.
• Důvěrný klient
  • Podmíněný přístup se vztahuje na prostředky požadované klientem a samotným důvěrným klientem, pokud požádá o token ID.
  • Příklad: Pokud Outlook Web požádá o token pro obory Mail.Read a Files.Read, použije podmíněný přístup zásady pro Exchange a SharePoint. Kromě toho platí, že pokud Outlook Web požádá o token ID, použije podmíněný přístup také zásady pro Outlook Web.

Pokud chcete zobrazit protokoly přihlášení pro tyto typy klientů z Centra pro správu Microsoft Entra:

1. Přihlaste se do centra pro správu Microsoft Entra alespoň jako Čtenář Sestav.
2. Přejděte do Entra ID>Monitorování a stav>Protokoly přihlášení.
3. Přidejte filtr pro typ přihlašovacích údajů klienta .
4. Upravte filtr tak, aby se zobrazila konkrétní sada protokolů na základě přihlašovacích údajů klienta použitého v přihlášení.

Další informace najdete v článku Veřejný klient a důvěrné klientské aplikace.

Všechny prostředky

Použití zásad podmíněného přístupu na všechny prostředky (dříve Všechny cloudové aplikace) bez vyloučení aplikací vynucuje zásadu pro všechny žádosti o tokeny z webů a služeb, včetně profilů předávání přenosů globálního zabezpečeného přístupu. Tato možnost zahrnuje aplikace, které nejsou v zásadách podmíněného přístupu jednotlivě zacílené, například Windows Azure Active Directory (00000002-0000-0000-c000-0000000000000).

Important

Microsoft doporučuje vytvořit základní zásady vícefaktorového ověřování, které cílí na všechny uživatele a všechny prostředky (bez vyloučení aplikací), jako je to popsané v Vyžadovat vícefaktorové ověřování pro všechny uživatele.

Chování podmíněného přístupu, když zásada pro všechny prostředky obsahuje vyloučení aplikace

Pokud je některá aplikace ze zásady vyloučená, aby nedošlo k neúmyslnému blokování přístupu uživatelů, jsou určité obory s nízkými oprávněními vyloučené z vynucení zásad. Tyto obory umožňují volání základních rozhraní Graph API, jako jsou Windows Azure Active Directory (00000002-0000-0000-c000-00000000000000) a Microsoft Graph (00000003-0000-0000-c000-00000000000) pro přístup k profilu uživatele a informacím o členství ve skupinách běžně používaných aplikacemi jako součást ověřování. Například: Když Outlook požádá o token pro Exchange, požádá také o User.Read rozsah, aby mohl zobrazit základní informace o účtu aktuálního uživatele.

Většina aplikací má podobnou závislost, proto jsou nízkoúrovňová oprávnění automaticky vyloučena, kdykoli je aplikace vyloučena v rámci politiky Všechny prostředky. Tato vyloučení rozsahu nízkých oprávnění neumožňují přístup k datům nad rámec základních informací o profilu uživatele a skupině. Vyloučené obory jsou uvedené následovně, souhlas se stále vyžaduje, aby aplikace tato oprávnění používaly.

• Nativní klienti a jednostráňové aplikace (SPA) mají přístup k následujícím oborům s nízkými oprávněními:
  • Azure AD Graph: email, offline_access, openid, profile, User.Read
  • Microsoft Graph: email, offline_access, openid, profile, User.ReadPeople.Read
• Důvěrní klienti mají přístup k následujícím rozsahům nízkých oprávnění, pokud jsou vyloučeni ze zásad Všechny prostředky:
  • Azure AD Graph: email, offline_access, openid, profile, User.Read, User.Read.AllUser.ReadBasic.All
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, User.Read.AllUser.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.AllMember.Read.Hidden

Další informace o uvedených oborech najdete v tématu referenční příručka k oprávněním Microsoft Graph a Obory a oprávnění v platformě Microsoft identity.

Ochrana informací o adresáři

Pokud doporučené základní zásady vícefaktorového ověřování bez vyloučení aplikací nejde nakonfigurovat z obchodních důvodů a zásady zabezpečení vaší organizace musí obsahovat rozsahy nízkých oprávnění souvisejících s adresářem (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), vytvořte samostatné zásady podmíněného přístupu cílené na Windows Azure Active Directory (00000002-0000-0000-c000-000000000000). Windows Azure Active Directory (označovaný také jako Azure AD Graph) je prostředek představující data uložená v adresáři, jako jsou uživatelé, skupiny a aplikace. Prostředek Windows Azure Active Directory je součástí Všechny prostředky ale můžou být jednotlivě zacílené v zásadách podmíněného přístupu pomocí následujícího postupu:

1. Přihlaste se do centra pro správu Microsoft Entra jako správce definic atributů a správce přiřazení atributů.
2. Přejděte kvlastním atributům zabezpečení>.
3. Vytvořte novou sadu atributů a definici atributu. Další informace najdete v Přidání nebo deaktivace vlastních definic atributů zabezpečení v Microsoft Entra ID.
4. Přejděte dopodnikové aplikace>.
5. Odeberte filtr Typ aplikace a vyhledejte ID aplikace, které začíná 00000002-0000-0000-c000-000000000000.
6. Vyberte Windows Azure Active Directory>Vlastní atributy zabezpečení>Přidat přiřazení.
7. Vyberte sadu atributů a hodnotu atributu, kterou chcete použít v zásadách.
8. Přejděte na Entra ID>Podmíněný přístup>Zásady.
9. Vytvořte nebo upravte existující zásadu.
10. V části Cílové prostředky>Prostředky (dříve cloudové aplikace)>Zahrnout, vyberte >Vybrat prostředky>Upravit filtr.
11. Upravte filtr tak, aby zahrnoval sadu atributů a definici z předchozích verzí.
12. Uložit zásadu

Note

Nakonfigurujte tuto zásadu, jak je popsáno v předchozích doprovodných materiálech. Jakékoli odchylky při vytváření zásady, jak je popsáno (například definování vyloučení aplikací), můžou mít za následek vyloučení rozsahů s nízkými oprávněními a zásady se nevztahují podle očekávání.

Všechny internetové prostředky s globálním zabezpečeným přístupem

Možnost Všechny internetové prostředky s možností Globální zabezpečený přístup umožňuje správcům cílit profil předávání přenosů z internetu z aplikace Microsoft Entra Internet Access.

Tyto profily v globálním zabezpečeném přístupu umožňují správcům definovat a řídit směrování provozu přes Microsoft Entra Internet Access a Microsoft Entra Private Access. Profily směrování provozu jsou možné přiřadit zařízením a vzdáleným sítím. Příklad, jak použít zásady podmíněného přístupu na tyto profily přenosu, najdete v článku Jak aplikovat zásady podmíněného přístupu na profil provozu Microsoft 365.

Další informace o těchto profilech naleznete v článku Global Secure Access traffic forwarding profiles.

Všechny prostředky agenta (Preview)

Použití zásady podmíněného přístupu pro všechny prostředky agenta vynucuje zásadu pro všechny žádosti o token u hlavních prvků plánu identity agenta a identity agenta.

Akce uživatele

Akce uživatele jsou úkoly, které uživatel provádí. Podmíněný přístup podporuje dvě akce uživatele:

• Registrovat bezpečnostní informace: Tato akce uživatele umožňuje zásadám podmíněného přístupu vynucovat pravidla, když se uživatelé pokusí zaregistrovat informace o zabezpečení. Další informace naleznete v tématu Kombinovaná registrace bezpečnostních údajů.

Note

Pokud správci použijí zásady zaměřené na akce uživatelů pro registraci bezpečnostních informací a uživatelský účet je hostem z osobního účtu Microsoft (MSA), vyžaduje ovládací prvek Vyžadovat vícefaktorové ověřování, aby uživatel MSA zaregistroval bezpečnostní informace v organizaci. Pokud je uživatel typu host od jiného poskytovatele, jako je Google, přístup se zablokuje.

• Registrace nebo připojení zařízení: Tato akce uživatele umožňuje správcům vynutit zásady podmíněného přístupu, když uživatelé zaregistrují nebo připojí zařízení k Microsoft Entra ID. Umožňuje správcům nakonfigurovat vícefaktorové ověřování pro registraci nebo připojování zařízení s větší členitostí než zásady pro celého tenanta. Při této akci uživatele existují tři klíčové aspekty:
  • Require multifactor authentication a Require auth strength jsou jedinými ovládacími prvky přístupu, které jsou k dispozici pro tuto akci uživatele a všechny ostatní jsou zakázané. Toto omezení brání konfliktům s řízením přístupu, které jsou závislé na registraci zařízení Microsoft Entra nebo nejsou použitelné pro registraci zařízení Microsoft Entra.
    • Windows Hello pro firmy a klíče vázané na zařízení se nepodporují, protože tyto scénáře vyžadují, aby bylo zařízení už zaregistrované.
  • Client apps, Filters for devicesa Device state podmínky nejsou v této akci uživatele k dispozici, protože jsou závislé na registraci zařízení Microsoft Entra a vynucují zásady podmíněného přístupu.

Warning

Pokud je zásada podmíněného přístupu nakonfigurována pomocí akce Register or join devices uživatele, nastavte ID Entra>Nastavení zařízení>Přehled>zařízení - Require Multifactor Authentication to register or join devices with Microsoft Entra na Ne. Jinak se zásady podmíněného přístupu s touto akcí uživatele nevynucují správně. Další informace o tomto nastavení zařízení najdete v tématu Konfigurace nastavení zařízení.

Kontext ověřování

Kontext ověřování zabezpečuje data a akce v aplikacích. Mezi tyto aplikace patří vlastní aplikace, obchodní aplikace, SharePoint nebo aplikace chráněné aplikací Microsoft Defender for Cloud Apps. Dá se také použít se službou Microsoft Entra Privileged Identity Management (PIM) k vynucení zásad podmíněného přístupu během aktivace role.

Organizace může například ukládat soubory na sharepointových webech, jako je obědová nabídka nebo tajný recept na bbq omáčku. Každý může přistupovat k webu jídelníčku na oběd, ale uživatelé přistupující k tajné stránce s receptem na BBQ omáčku mohou potřebovat používat spravované zařízení a souhlasit s konkrétními podmínkami použití. Podobně může být správce, který aktivuje privilegovanou roli prostřednictvím PIM, vyžadován k provedení vícefaktorového ověřování nebo použití kompatibilního zařízení.

Kontext ověřování funguje s uživateli nebo identitami úloh, ale ne současně ve stejné zásadě podmíněného přístupu.

Konfigurace kontextů ověřování

Kontexty ověřování můžete spravovat tak, že přejdete do Entra ID>Podmíněný přístup>Kontext ověřování.

Vyberte Nový kontext ověřování a vytvořte definici kontextu ověřování. Organizace můžou vytvářet až 99 definic kontextu ověřování (c1-c99). Nakonfigurujte tyto atributy:

• Zobrazovaný název je název, který se používá k identifikaci kontextu ověřování v Microsoft Entra ID a napříč aplikacemi, které využívají kontexty ověřování. Doporučujeme použít názvy, které se dají použít napříč prostředky, jako jsou důvěryhodná zařízení, a snížit tak počet potřebných kontextů ověřování. Mít redukovanou sadu omezuje počet přesměrování a poskytuje lepší uživatelský zážitek pro koncové uživatele.
• Popis obsahuje další informace o zásadách. Tyto informace používají správci a ti, kteří aplikují kontexty ověřování na prostředky.
• Zaškrtávací políčko Publikovat do aplikací, pokud je zaškrtnuté, oznamuje ověřovací kontext aplikacím a zpřístupňuje ho k přiřazení. Pokud není vybraný, kontext ověřování není pro podřízené prostředky dostupný.
• ID je jen pro čtení a používá se v tokenech a aplikacích pro definice kontextu ověřování specifické pro požadavky. Zde uvedeno pro řešení potíží a vývojové scénáře.

Přidat k politice podmíněného přístupu

Správci můžou vybrat publikované kontexty ověřování v zásadách podmíněného přístupu tak, že přejdou do Přiřazení>Cloudových aplikací nebo akcí a vyberou kontekst ověřování z nabídky vybrat, na co se tato zásada vztahuje.

Odstranění kontextu ověřování

Před odstraněním kontextu ověřování se ujistěte, že ho nepoužívají žádné aplikace. Jinak není přístup k datům aplikací chráněný. Potvrďte to tak, že zkontrolujete protokoly přihlašování v případech, kdy se použijí zásady podmíněného přístupu kontextu ověřování.

Pokud chcete odstranit kontext ověřování, ujistěte se, že nemá přiřazené žádné zásady podmíněného přístupu a nepublikuje se do aplikací. Zabráníte tak náhodnému odstranění kontextu ověřování, který se stále používá.

Označování prostředků pomocí kontextů ověřování

Další informace o používání kontextů ověřování najdete v následujících článcích.

• Ochrana obsahu v Microsoft Teams, skupinách Microsoft 365 a sharepointových webech pomocí popisků citlivosti
• Microsoft Defender pro cloudové aplikace
• Vlastní aplikace
• Privileged Identity Management – Při aktivaci je vyžadován kontext ověřování podmíněného přístupu Microsoft Entra

Související obsah

• Podmíněný přístup: Podmínky – Naučte se konfigurovat podmínky pro upřesnění zásad.
• Společné zásady podmíněného přístupu – Seznamte se s běžnými šablonami zásad, abyste mohli rychle začít.
• Závislosti klientských aplikací – Zjistěte, jak závislosti ovlivňují zásady podmíněného přístupu.