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

Přehled

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í integrované aplikace Microsoft a všechny integrované aplikace Microsoft Entra včetně galerie, jiné než galerie a aplikací publikovaných prostřednictvím proxy aplikací.
• 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.

Microsoft cloudové aplikace

Správci můžou přiřadit zásady podmíněného přístupu k Microsoft cloudovým aplikacím, pokud se služební objekt zobrazí ve svém tenantovi, s výjimkou Microsoft Graph. Microsoft Graph funguje jako zastřešující zdroj. 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 je Microsoft 365/Office 365 a Windows Azure rozhraní API pro správu služeb zahrnují několik souvisejících podřízených aplikací nebo služeb. Když se vytvoří nové aplikace Microsoft cloud, zobrazí se v seznamu aplikací hned po vytvoření servisního principála v rámci tenanta.

Office 365

Microsoft 365 nabízí cloudové služby pro produktivitu a spolupráci, jako jsou Exchange, SharePoint a Microsoft Teams. V podmíněném přístupu se sada Microsoft 365 aplikací zobrazí v části Office 365. Cloudové služby Microsoft 365 jsou hluboce integrovány, aby zajistily hladkou a spolupracující zkušenost. Tato integrace může způsobit nejasnosti při vytváření zásad, protože některé aplikace, například Microsoft Teams, závisejí na jiných aplikacích, jako jsou SharePoint nebo Exchange.

Seskupení aplikací Office 365 v podmíněném přístupu umožňuje cílit na tyto služby najednou. Místo cílení na jednotlivé cloudové aplikace používejte seskupení Microsoft 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 Exchange Online daty, jako jsou 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 jsou všechna metadata chráněná podle očekávání, měli by správci přiřadit zásady Microsoft 365 aplikaci.

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

Úplný seznam všech zahrnutých služeb najdete v tématu Apps, které jsou součástí sady aplikací podmíněného přístupu Microsoft 365.

rozhraní API pro správu služby Windows Azure

Když zacílíte na aplikaci rozhraní API pro správu služby Windows Azure, zásady se vynucují pro tokeny vystavené sadě služeb úzce propojených s portálem. Toto seskupení zahrnuje ID aplikací:

• Azure Resource Manager
• portál Azure, který se zabývá také Centrum pro správu Microsoft Entra a centrem Microsoft Engage Center
• Azure Data Lake
• Rozhraní API pro Application Insights
• rozhraní API 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í API Azure. Například:

• Azure CLI
• portál 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 Microsoftu 365
• Microsoft IoT Central
• správa Microsoft Defender s více tenanty
• SQL Managed Instance
• portál pro správu předplatných 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 API pro Windows Azure pro správu služeb se vztahuje na Azure PowerShell, který volá rozhraní API Azure Resource Manager. Nevztahuje se na Microsoft Graph PowerShell, který volá rozhraní API Microsoft Graph.

Pro Azure Government byste měli cílit na aplikaci rozhraní API pro správu cloudu Azure Government.

Portály pro správu Microsoft

Když zásady podmíněného přístupu cílí na cloudovou aplikaci portálů pro správu Microsoft, zásada se vynucuje u tokenů vydaných pro konkrétní ID podkladových aplikací prostředků přidružených k portálům pro správu Microsoft. Seskupování aplikací nezahrnuje back-endové služby, na kterých můžou tyto portály volat nebo záviset. K identifikaci závislostí služeb portálů pro správu použijte protokoly přihlašování cílové skupiny podmíněného přístupu.

Následující aplikace tvoří portály pro správu Microsoft:

• Centrum pro správu Exchange ID aplikace: 497effe9-df71-4043-a8bb-14cf78c4b63b
• ID aplikace portálu Azure: c44b4083-3bb0-49c1-b47d-974e53cbdf3c
• Microsoft Office 365 ID aplikace portálu: 00000006-0000-0ff1-ce00-000000000000
• ID aplikace Microsoft 365 Centrum zabezpečení a dodržování předpisů (Centrum ochrany): 80ccca67-54bd-44ab-8625-4b79c4dc7775

Seskupování portálu pro správu je primárně určené pro zahrnující scénáře, což je zjednodušený způsob, jak efektivně cílit jeden nebo více portálů pro správu pomocí zásad podmíněného přístupu (například uplatňování vícefaktorového ověřování). Toto seskupení se používá v MFA pro správce zásady spravované Microsoftem ke zjednodušení vytváření zásad.

Tato možnost není určená k tomu, aby fungovala jako mechanismus hromadného vyloučení pro všechny back-endové služby přidružené k ID podkladových aplikací.

Note

Blokování zásad, které cílí na portály pro správu Microsoft, znemožní koncovým uživatelům přístup ke stránce Microsoft 365 samoobslužné instalace, protože tato stránka je aktuálně umístěná v Centrum pro správu Microsoftu 365. Informace o alternativních možnostech nasazení najdete v tématu Plánujte podnikové nasazení Microsoft 365 Apps.

Jiné aplikace

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

• Aplikace publikované prostřednictvím proxy aplikací Microsoft Entra
• 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á pro službu SharePoint platí pro všechny klienty volající SharePoint. Zásada nastavená na Exchange se vztahuje na pokus o přístup k e-mailu pomocí klienta Outlook. 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í servisní principal pomocí cmdletu PowerShellu New-MgServicePrincipal nebo pomocí Microsoft Graph API.

Podmíněný přístup 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 jsou Microsoft Outlook v desktopový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 administrativního centra Microsoft Entra:

1. Přihlaste se k Centrum pro správu Microsoft Entra alespoň jako Reports Reader.
2. Přejděte na Entra ID>Monitorování a zdraví>Protokoly o 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.

Podmíněný přístup pro 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í prostředků 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í prostředků), jako je to popsané v tématu Require multifactor authentication pro všechny uživatele.

Chování starší verze podmíněného přístupu, když zásady pro všechny prostředky mají vyloučení prostředků

Warning

Mění se následující chování podmíněného přístupu. Tyto nízkoprivilegované obory, které byly dříve vyloučeny z vynucování zásad, již nebudou vyloučeny. Tato změna znamená, že uživatelé, kteří byli dříve schopni získat přístup k aplikaci bez vynucení podmíněného přístupu, teď můžou dostat problémy s podmíněným přístupem. Tato změna se zavádí ve fázích počínaje březnem 2026.

Pokud je některá aplikace ze zásad vyloučená, aby nedocházelo k neúmyslnému blokování přístupu uživatelů, byly z vynucení zásad dříve vyloučeny určité obory s nízkými oprávněními. Tyto obory umožňují volání podkladových rozhraní Graph API, jako jsou Windows Azure Active Directory (00000002-0000-0000-c000-0000000000000) a Microsoft Graph (00000003-0000-0000-c000-000000000000) pro přístup k profilům uživatelů 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 rozsah User.Read, aby mohl zobrazit základní informace o účtu aktuálního uživatele.

Většina aplikací má podobnou závislost, což je důvod, proč se tyto obory s nízkými oprávněními automaticky vyloučily v zásadách všech prostředků . Dříve 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

Nové chování podmíněného přístupu, pokud zásada VŠECH prostředků zahrnuje vyloučení

Obory uvedené v předchozí části se teď vyhodnocují jako přístup k adresáři a mapují se na Azure AD Graph (prostředek: Windows Azure Active Directory, ID: 00000002-0000-0000-c000-000000000000000) pro účely vyhodnocení podmíněného přístupu.

Zásady podmíněného přístupu, které cílí na všechny prostředky s jedním nebo více vyloučeními prostředků, anebo zásady, které explicitně cílí na Azure AD Graph, se uplatňují v procesech přihlašování uživatelů, když klientská aplikace požaduje pouze tyto obory. Když aplikace požádá o další obor nad rámec výše uvedených, neexistuje žádná změna chování.

Pokyny k posouzení dopadu, identifikaci ovlivněných aplikací a zachování staršího chování najdete v tématu Vylepšené vynucování zásad s vyloučeními prostředků.

Note

Vyřazení Azure AD Graphu nemá vliv na prostředek Azure AD Graph (Windows Azure Active Directory) zaregistrovaný ve vašem tenantovi.

Uživatelské prostředí

V tokách přihlašování uživatelů, kde klientské aplikace požadují pouze výše uvedené obory, mohou nyní uživatelé obdržet výzvy podmíněného přístupu (například vícefaktorové ověřování nebo shoda zařízení). Přesná výzva závisí na řízení přístupu nakonfigurované ve vašich zásadách, které cílí na všechny prostředky (s vyloučením prostředků nebo bez nich) nebo na zásady, které explicitně cílí Azure AD Graph.

V následujícím příkladu má tenant zásady podmíněného přístupu s následujícími podrobnostmi:

• Cílení na všechny uživatele a všechny prostředky
• Vyloučení prostředků pro důvěrnou klientskou aplikaci a Exchange Online
• Vícefaktorové ověřování je nakonfigurováno jako řídicí prvek pro udělení

Ukázkové scénáře

Ukázkový scénář	Dopad na uživatele (před → po)	Vyhodnocení podmíněného přístupu
Uživatel se přihlásí k desktopovém klientovi Visual Studio Code, který požaduje obory openid a profilu.	Před: Uživatel není vyzván k vícefaktorovému ověřování Po: Uživatel je vyzván k vícefaktorovému ověřování	Podmíněný přístup se teď vyhodnocuje pomocí Windows Azure Active Directory jako cílová skupina pro vynucování.
Uživatel se přihlásí pomocí Azure CLI, který požaduje pouze User.Read.	Před: Uživatel není vyzván k vícefaktorovému ověřování Po: Uživatel je vyzván k vícefaktorovému ověřování	Podmíněný přístup se nyní vyhodnocuje ve vztahu k Windows Azure Active Directory, které slouží jako publikum pro vynucení.
Uživatel se přihlásí prostřednictvím důvěrné klientské aplikace (vyloučené ze zásad), která požaduje pouze User.Read a People.Read.	Před: Uživatel není vyzván k vícefaktorovému ověřování Po: Uživatel je vyzván k vícefaktorovému ověřování	Podmíněný přístup se teď vyhodnocuje pomocí Windows Azure Active Directory jako cílová skupina vynucení.

Když klientská aplikace požaduje rozsah nad rámec těch předtím uvedených, nedochází ke změně chování, jak je znázorněno v následujících příkladech.

Ukázkové scénáře

Ukázkový scénář	Dopad na uživatele	Vyhodnocení podmíněného přístupu
Uživatel se přihlásí k důvěrné klientské aplikaci (vyloučené ze zásad), která požaduje přístup offline_access a SharePoint (Files.Read).	Žádné změny chování	Podmíněný přístup se bude nadále vynucovat na základě SharePoint zdroje.
Uživatel se přihlásí k klientovi synchronizace plochy OneDrive. OneDrive požaduje offline_access a přístup k aplikaci Exchange Online (Mail.Read).	Žádné změny chování	Podmíněný přístup se nevynucuje, protože Exchange Online je ze zásady vyloučený.

Většina aplikací požaduje obory nad rámec dříve uvedených oborů a již podléhá vynucení podmíněného přístupu, pokud není aplikace explicitně vyloučena ze zásady. V takových případech se chování nijak nemění.

Vlastní aplikace, které jsou záměrně navržené tak, aby požadovaly pouze dříve uvedené obory a nejsou navržené tak, aby řešily problémy s podmíněným přístupem, může být potřeba aktualizovat, aby mohly řešit problémy s podmíněným přístupem. Podrobnosti o implementaci najdete v pokynech pro vývojáře podmíněného přístupu Microsoft.

Jak identifikovat aplikace ovlivněné změnou prosazování nízkoúrovňových oprávnění

Aplikace mohou být předem autorizované k vyžádání pouze jednoho nebo více dříve uvedených oborů. K identifikaci ovlivněných aplikací použijte následující možnosti.

PowerShell

Pomocí následujícího skriptu PowerShellu zobrazte seznam všech aplikací ve vašem tenantovi, které jsou předem autorizované k vyžádání pouze jednoho nebo více oborů ovlivněných touto změnou.

Note

Aplikace můžou dynamicky požadovat další obory (se souhlasem správce). Tento skript takové aplikace neidentifikuje.

# ==============================
# Inventory of apps whose delegated consent grants include ONLY
# the OIDC scopes + specific directory scopes listed below.
#
# Enhancements incorporated:
#  - Supported both PowerShell 5.1 and 7.x
#  - Add user sign-in count (last 7 days) per app
#
# Output:
#  - ServicePrincipalObjectId (oauth2PermissionGrants.clientId = SP object id)
#  - AppId
#  - AppDisplayName
#  - AppOwnerOrganizationId (for classification)
#  - Scopes (union of delegated scopes granted)
#  - UserSigninsLast7Days (Successful + Failed)
# ==============================

$TenantId = Read-Host "Enter your Microsoft Entra tenant ID (GUID)"

$BaselineScopes = @(
  "openid", "profile", "email", "offline_access",
  "User.Read", "User.Read.All", "User.ReadBasic.All",
  "People.Read", "People.Read.All",
  "GroupMember.Read.All", "Member.Read.Hidden"
)

Disconnect-MgGraph -ErrorAction SilentlyContinue

Connect-MgGraph -TenantId $TenantId -Scopes @(
  "DelegatedPermissionGrant.Read.All",
  "Directory.Read.All",
  "Reports.Read.All"
)

# ------------------------------
# Pull oauth2PermissionGrants (paging)
# ------------------------------
$uri = "https://graph.microsoft.com/beta/oauth2PermissionGrants?`$select=clientId,scope,consentType"
$grants = @()
while ($uri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
  $grants += $resp.value
  $uri = $resp.'@odata.nextLink'
}

# ------------------------------
# Build baseline-only candidate set (Jun: HashSet per clientId)
# ------------------------------
$scopesByClient = @{}  # key: clientId (SP objectId), value: HashSet[string] (case-insensitive)

foreach ($g in $grants) {
  $cid = $g.clientId.ToString().Trim()
  if (-not $cid) { continue }

  if (-not $scopesByClient.ContainsKey($cid)) {
    $scopesByClient[$cid] = [System.Collections.Generic.HashSet[string]]::new(
      [System.StringComparer]::OrdinalIgnoreCase
    )
  }

  foreach ($s in ($g.scope -split '\s+')) {
    if ($s -and $s.Trim().Length -gt 0) {
      [void]$scopesByClient[$cid].Add($s.Trim())
    }
  }
}

$candidates = foreach ($cid in $scopesByClient.Keys) {
  $scopes = $scopesByClient[$cid]
  if ($scopes.Count -le 0) { continue }

  $outside = $scopes | Where-Object { $_ -notin $BaselineScopes }
  if ($outside.Count -eq 0) {
    [PSCustomObject]@{
      ServicePrincipalObjectId = $cid
      Scopes = ($scopes -join ' ')
    }
  }
}

# ------------------------------
# Pull per-app sign-in summary for last 7 days (Graph REST via Invoke-MgGraphRequest)
# Endpoint: GET /beta/reports/getAzureADApplicationSignInSummary(period='D7')
# In this API output, 'id' corresponds to the appId (clientId)
# ------------------------------
$signInSummary = @()
$signInUri = "https://graph.microsoft.com/beta/reports/getAzureADApplicationSignInSummary(period='D7')"

while ($signInUri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $signInUri

  if ($resp -and $resp.value) {
    $signInSummary += $resp.value
  }

  # Paging (if present)
  $signInUri = $resp.'@odata.nextLink'
}

# appId -> total sign-ins (7d)
$signInCountByAppId = @{}
foreach ($s in $signInSummary) {
  $appId = $s.id
  if (-not $appId) { continue }

  # PS5.1-safe null handling
  $success = 0
  $failed  = 0
  if ($null -ne $s.successfulSignInCount) { $success = [int]$s.successfulSignInCount }
  if ($null -ne $s.failedSignInCount)     { $failed  = [int]$s.failedSignInCount }

  $signInCountByAppId[$appId] = $success + $failed
}

$resultsTenantOwned = @()
$resultsNotTenantOwned = @()

# ------------------------------
# Filter to tenant-owned or external apps; enrich with appId/displayName + sign-in counts
# ------------------------------
foreach ($c in $candidates) {
  try {
    $spUri = "https://graph.microsoft.com/beta/servicePrincipals/$($c.ServicePrincipalObjectId)?`$select=id,appId,displayName,appOwnerOrganizationId"
    $sp = Invoke-MgGraphRequest -Method GET -Uri $spUri

    $signinCount7d = 0
    if ($sp.appId -and $signInCountByAppId.ContainsKey($sp.appId)) {
      $signinCount7d = $signInCountByAppId[$sp.appId]
    }

    $row = [PSCustomObject]@{
      ServicePrincipalObjectId = $c.ServicePrincipalObjectId
      AppId                   = $sp.appId
      AppDisplayName          = $sp.displayName
      AppOwnerOrganizationId  = $sp.appOwnerOrganizationId
      Scopes                  = $c.Scopes
      UserSigninsLast7Days    = $signinCount7d
    }

    if ($sp.appOwnerOrganizationId -eq $TenantId) {
      $resultsTenantOwned += $row
    }
    else {
      $resultsNotTenantOwned += $row
    }
  }
  catch {
    # Ignore non-enumerable / missing service principals
  }
}

# ------------------------------
# Output
# ------------------------------
'=== Tenant-owned apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

'=== External apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsNotTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

Sestava využití a přehledů

Sestava Usage a Insights v Microsoft Entra může pomoct monitorovat aktivitu přihlašování do aplikací pro konkrétní aplikace.

1. Přihlaste se k Centrum pro správu Microsoft Entra alespoň jako Reports Reader.
2. Přejděte na Entra ID>Sledování a zdraví>Použití a postřehy.
3. Vyberte aplikaci > a vyberte Využití a přehledy.

Protokoly přihlašování

Microsoft Entra ID protokoly přihlašování můžou také poskytnout podrobný seznam přihlášení pro konkrétní aplikace.

1. Přihlaste se k Centrum pro správu Microsoft Entra alespoň jako Reports Reader.
2. Přejděte na Entra ID>Monitorování a zdraví>Protokoly o přihlášení.
3. Nastavte filtr Aplikace a jako hodnotu zadejte název aplikace nebo ID aplikace.

Ochrana informací o adresáři

Note

Následující část platí, dokud nebude dokončeno zavádění změny vynucení rozsahu s nízkou úrovní oprávnění.

Pokud poručené základní zásady vícefaktorového ověřování bez vyloučení prostředků není možné konfigurovat z obchodních důvodů, a zásady zabezpečení vaší organizace musí zahrnovat rozsahy oprávnění související 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, které cílí 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 v zásadách podmíněného přístupu je možné cílit jednotlivě pomocí následujících kroků:

1. Přihlaste se k Centrum pro správu Microsoft Entra jako správce Attribute Definition Administrator a Atribute Assignment Administrator.
2. Přejděte na Entra ID>Vlastní atributy zabezpečení.
3. Vytvořte novou sadu atributů a definici atributu. Další informace najdete v tématu Přidat nebo deaktivovat definice vlastních atributů zabezpečení v Microsoft Entra ID.
4. Přejděte na Entra ID>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 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. V části Řízení přístupu>udělení, vyberte Udělit přístup, vyberte Vyžadovat sílu autentizace, vyberte Vícefaktorové ověřování a pak vyberte Vybrat.
13. Potvrďte nastavení a nastavte možnost Enable policy na Jen pro hlášení.
14. Vyberte Vytvořit, tím aktivujete svou 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í prostředků), můžou vést k vyloučení rozsahů s nízkými oprávněními a k tomu, aby zásady nebyly aplikovány 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 globálním zabezpečeným přístupem umožňuje správcům cílit na profil přesměrování provozu 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 směrování provozu jsou možné přiřadit zařízením a vzdáleným sítím. Příklad, jak aplikovat zásady podmíněného přístupu na tyto profily provozu, najdete v článku Jak aplikovat zásady podmíněného přístupu na profil síťového 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 aplikují zásady zaměřené na uživatelské akce při registraci bezpečnostních informací a uživatelský účet je hostem z osobního účtu Microsoft (MSA), kontrola „Vyžadovat vícefaktorové ověření“ vyžaduje, aby uživatel MSA zaregistroval bezpečnostní informace v rámci organizace. Pokud je uživatel typu host od jiného poskytovatele, jako je Google, přístup se zablokuje.

• Registrace nebo připojení zařízení: Tímto úkonem mohou správci vynucovat zásady podmíněného přístupu, když uživatelé registrují 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 se nevztahují na 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 devices a Device state podmínky nejsou u této akce uživatele dostupné, protože závisí na registraci zařízení Microsoft Entra pro vynucení pravidel podmíněného přístupu.

Warning

Pokud je zásada podmíněného přístupu nakonfigurovaná s akcí uživatele Registrovat nebo připojit se k zařízení, nastavte Entra ID>Devices>Přehled>Nastavení - 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é Microsoft Defender for Cloud Apps. Dá se také použít s 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 SharePoint 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 na Entra ID>Conditional Access> 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:

• Zobrazený název je jméno používané k identifikaci kontextu ověřování v Microsoft Entra ID a v aplikacích, které využívají ověřovací kontexty. Pomocí názvů, které je možné použít napříč prostředky, jako jsou důvěryhodná zařízení, snižte 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í>cílové prostředky a vyberou kontext 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.

• Použití popisků citlivosti k ochraně obsahu v Microsoft Teams, skupinách Microsoft 365 a webech SharePoint
• Microsoft Defender for Cloud Apps
• Vlastní aplikace
• Privileged Identity Management - Při aktivaci vyžadovat kontext ověřování v rámci Microsoft Entra Podmíněný přístup

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.