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 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í integrované aplikace Microsoftu a všechny integrované aplikace Microsoft Entra, včetně galerie, jiné než galerie a aplikací publikovaných prostřednictvím proxy aplikací.
• Správci se můžou rozhodnout definovat zásady, které nejsou založené na cloudové aplikaci, ale na akci uživatele, jako je registrace bezpečnostních informací nebo registrace nebo připojení zařízení, což umožňuje podmíněnému přístupu vynucovat 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

Mnoho stávajících cloudových aplikací Microsoftu je na seznamu aplikací, ze kterých si můžete vybrat.

Správci můžou těmto cloudovým aplikacím Microsoftu přiřadit zásady podmíněného přístupu. 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.

Důležité

Aplikace, které jsou dostupné pro podmíněný přístup, procházejí procesem onboardingu a ověřování. Tyto aplikace nezahrnují všechny aplikace Microsoftu. Řada aplikací jsou backendové služby, na které se nemají přímo aplikovat zásady. Pokud hledáte aplikaci, která chybí, můžete kontaktovat konkrétní tým aplikace nebo požádat o userVoice.

Office 365

Microsoft 365 poskytuje 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, jako jsou některé aplikace, jako je Microsoft Teams, mají závislosti na jiných aplikacích, jako je SharePoint nebo Exchange.

Sada Office 365 umožňuje na všechny tyto služby cílit najednou. Místo cílení na jednotlivé cloudové aplikace doporučujeme používat novou sadu 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 se zajistilo, ž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.

Rozhraní API pro správu služeb Windows Azure

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ý zahrnuje také centrum pro správu Microsoft Entra
• 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, služby nebo klienty se závislostí služby Azure API, může to mít vliv nepřímo. Příklad:

• Azure CLI
• Portál služby Azure Data Factory
• Azure DevOps
• 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
• Spravovaná instance SQL
• Portál pro správu předplatných sady Visual Studio

Poznámka:

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

Další informace o nastavení ukázkových zásad pro službu rozhraní API pro správu služeb Windows Azure najdete v tématu Podmíněný přístup: Vyžadování vícefaktorového ověření pro správu Azure.

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:

• portál Azure
• 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.

Poznámka:

Aplikace Portály pro správu Microsoftu se vztahuje pouze na interaktivní přihlašování k uvedeným portálům pro správu. Tato aplikace nepokrývá přihlášení k podkladovým prostředkům nebo službám, jako jsou microsoft Graph nebo rozhraní API Azure Resource Manageru. Tyto prostředky jsou chráněné aplikací API služby Windows Azure Service Management. Toto seskupení umožňuje zákazníkům přejít na cestu přechodu na vícefaktorové ověřování pro správce, aniž by to mělo vliv na automatizaci, která závisí na rozhraních API a PowerShellu. Až budete připraveni, Microsoft doporučuje používat zásady , které vyžadují, aby správci prováděli vícefaktorové ověřování vždy pro komplexní ochranu.

Jiné aplikace

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

• Aplikace publikované prostřednictvím proxy aplikací Microsoft Entra ID
• 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

Poznámka:

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).

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ého veřejného klienta, ale vztahují se na základě prostředků požadovaných veřejnými klienty.
• 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 na Monitorování identity>kontrolu stavu &>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 naleznete 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í jakýchkoli aplikací vede k tomu, že zásady se uplatňují na všechny žádosti o tokeny ze stránek a služeb, včetně profilů předávání přenosů v rámci 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).

Důležité

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ž má zásada všech prostředků 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.Read, People.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.All,User.ReadBasic.All
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden

Další informace o uvedených oborech najdete v tématu odkazy na oprávnění Microsoft Graph a Obory a oprávnění vplatformy Microsoft Identity Platform .

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í zahrnovat tyto rozsahy nízkých oprávnění, alternativou je vytvoření samostatného cíle zásad podmíněného přístupu, které cílí na Windows Azure Active Directory (00000002-0000-0000-c000-0000000000000). 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 na Protection>Vlastní atributy 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 na Identity>Aplikace>podnikové 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 Protection>Zásady podmíněného přístupu>.
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

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 na profil předávání přenosů z internetu z Microsoft Entra Přístup k Internetu.

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 Přístup k Internetu a Microsoft Entra Soukromý přístup. Profily předávání přenosů je možné přiřadit zařízením a vzdáleným sítím. Příklad použití zásad podmíněného přístupu pro tyto profily přenosů najdete v článku Postup použití zásad podmíněného přístupu pro profil provozu Microsoftu 365.

Další informace o těchtoprofilech

Akce uživatele

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

• Registrace bezpečnostních informací: Tato akce uživatele umožňuje, aby zásady podmíněného přístupu vynucovaly, když se uživatelé, kteří mají povolenou kombinovanou registraci, pokusili zaregistrovat své bezpečnostní údaje. Další informace najdete v článku Kombinovaná registrace bezpečnostních informací.

Poznámka:

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), pak použití ovládacího prvku 'Vyžadovat vícefaktorové ověřování' vyžaduje, 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. Poskytuje členitost při konfiguraci vícefaktorového ověřování pro registraci nebo připojování zařízení místo zásad v rámci celého tenanta, které aktuálně existují. Při této akci uživatele existují tři klíčové aspekty:
  • Require multifactor authentication je jediné řízení přístupu, které je k dispozici s touto akcí uživatele a všechny ostatní jsou zakázány. 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.
  • Client apps, Filters for devicesa Device state podmínky nejsou k dispozici s touto akcí uživatele, protože jsou závislé na registraci zařízení Microsoft Entra k vynucení zásad podmíněného přístupu.

Upozorňující

Pokud je zásada podmíněného přístupu nakonfigurovaná pomocí akce Zaregistrovat nebo připojit zařízení uživatele, musíte nastavit na > Jinak se zásady podmíněného přístupu s touto akcí uživatele nevynucuje správně. Další informace o tomto nastavení zařízení najdete v části Konfigurace nastavení zařízení.

Kontext ověřování

Kontext ověřování je možné použít k dalšímu zabezpečení dat a akcí v aplikacích. Těmito aplikacemi můžou být vaše vlastní aplikace, vlastní obchodní aplikace (LOB), aplikace typu SharePoint nebo aplikace chráněné Microsoft Defenderem for Cloud Apps.

Organizace může například uchovávat soubory na sharepointových webech, jako je obědová nabídka nebo tajný recept na bbq omáčku. Každý může mít přístup k webu obědových nabídek, ale uživatelé, kteří mají přístup k tajnému webu receptu bbq omáčky, mohou potřebovat přístup ze spravovaného zařízení a souhlasit s konkrétními podmínkami použití.

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

Konfigurace kontextů ověřování

Kontexty ověřování se spravují v rámci kontextu ověřování podmíněného přístupu ochrany>>.

Výběrem možnosti Nový kontext ověřování vytvořte nové definice kontextu ověřování. Organizace jsou omezené na celkem 99 definic kontextu ověřování c1-c99. Nakonfigurujte následující atributy:

• Zobrazovaný název je název, který slouží 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í. Snížením nastaveného limitu je počet přesměrování a poskytuje lepší prostředí pro koncové uživatele.
• Popis obsahuje další informace o zásadách používaných správci a těmi, kteří používají kontexty ověřování na prostředky.
• Zaškrtávací políčko Publikovat do aplikací , když je zaškrtnuté, inzeruje kontext ověřování aplikacím a zpřístupní je pro přiřazení. Pokud není zaškrtnuté, 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. Tady je uvedeno pro řešení potíží a případy použití vývoje.

Přidání do zásad podmíněného přístupu

Správci můžou v cloudových aplikacích nebo akcích> přiřazení vybrat publikované kontexty ověřování v zásadách podmíněného přístupu a vybrat kontext ověřování v nabídce Vybrat, co se tato zásada týká.

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

Když odstraníte kontext ověřování, ujistěte se, že ho stále nepoužívají žádné aplikace. V opačném případě už není přístup k datům aplikace chráněný. Tento požadavek můžete potvrdit kontrolou protokolů 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í, nesmí mít přiřazené žádné zásady podmíněného přístupu a nesmí být publikovány do aplikací. Tento požadavek pomáhá zabránit 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žití kontextu ověřování v aplikacích 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 for Cloud Apps
• Vlastní aplikace

Další kroky

• Podmíněný přístup: podmínky
• Společné zásady podmíněného přístupu
• Závislosti klientské aplikace