Accesso condizionale: risorse di destinazione

Le risorse di destinazione (in precedenza app cloud, azioni e contesto di autenticazione) sono segnali chiave in un criterio di accesso condizionale. I criteri di accesso condizionale consentono agli amministratori di assegnare controlli a applicazioni, servizi, azioni o contesto di autenticazione specifici.

• Gli amministratori possono scegliere dall'elenco di applicazioni o servizi che includono applicazioni Microsoft predefinite e qualsiasi applicazioni integrate di Microsoft Entra, tra cui galleria, non galleria e applicazioni pubblicate tramite Application Proxy.
• Gli amministratori possono definire criteri basati su un'azione dell'utente, come Registrare informazioni di sicurezza o Registrare o associare dispositivi, permettendo al Controllo delle Condizioni di applicare controlli a tali azioni.
• Gli amministratori possono indirizzare i profili di inoltro del traffico da Accesso sicuro globale per funzionalità avanzate.
• Gli amministratori possono usare il contesto di autenticazione per offrire un livello aggiuntivo di sicurezza nelle applicazioni.

Applicazioni cloud Microsoft

Gli amministratori possono assegnare una politica di accesso condizionale alle app cloud Microsoft se il principal del servizio è presente nel tenant, ad eccezione di Microsoft Graph. Microsoft Graph funziona come risorsa generica. Usare Audience Reporting per visualizzare i servizi sottostanti e definire come destinazione tali servizi nei criteri. Alcune app come Microsoft 365/Office 365 e Windows Azure API di Gestione servizi includono più app o servizi figlio correlati. Quando vengono create nuove applicazioni cloud Microsoft, vengono visualizzate nell'elenco di selezione delle applicazioni non appena viene creato il principale del servizio nel tenant.

Office 365

Microsoft 365 offre servizi di produttività e collaborazione basati sul cloud come Exchange, SharePoint e Microsoft Teams. In Accesso condizionale, la suite di applicazioni Microsoft 365 viene visualizzata in "Office 365". Microsoft 365 servizi cloud sono profondamente integrati per garantire esperienze uniformi e collaborative. Questa integrazione può causare confusione durante la creazione di criteri perché alcune app, ad esempio Microsoft Teams, dipendono da altri, ad esempio SharePoint o Exchange.

Il raggruppamento delle app di Office 365 nell'accesso condizionale consente di destinare questi servizi tutti contemporaneamente. È consigliabile usare il raggruppamento Microsoft 365, invece di scegliere come destinazione le singole app cloud per evitare problemi con le dipendenze servizi.

La destinazione di questo gruppo di applicazioni consente di evitare problemi che possono verificarsi a causa di criteri e dipendenze incoerenti. Ad esempio: l'app Exchange Online è associata a dati di Exchange Online tradizionali, ad esempio posta, calendario e informazioni di contatto. I metadati correlati possono essere esposti tramite risorse diverse, ad esempio la ricerca. Per assicurarsi che tutti i metadati siano protetti come previsto, gli amministratori devono assegnare criteri all'app Microsoft 365.

Gli amministratori possono escludere l'intera suite di Microsoft 365 o app cloud specifiche Microsoft 365 dai criteri di accesso condizionale.

Un elenco completo di tutti i servizi inclusi è disponibile nell'articolo App incluse nella suite di app Microsoft 365 Accesso Condizionale.

API di gestione dei servizi Windows Azure

Quando si usa come destinazione l'applicazione API di gestione dei servizi di Windows Azure, i criteri vengono applicati per i token rilasciati a un set di servizi strettamente associati al portale. Questo raggruppamento include gli ID delle applicazioni di:

• Azure Resource Manager
• Portale Azure, che copre anche il centro di amministrazione di Microsoft Entra e il Centro di Coinvolgimento Microsoft
• Azure Data Lake
• API di Application Insights
• API di Log Analytics

Poiché i criteri vengono applicati al portale di gestione e all'API di Azure, tutti i servizi o i client che dipendono dall'API Azure possono essere interessati indirettamente. Per esempio:

• Azure CLI
• portale di Azure Data Factory
• Azure Event Hubs
• Azure PowerShell
• Azure Service Bus
• Azure SQL Database
• Azure Synapse
• API del modello di distribuzione classica
• interfaccia di amministrazione di Microsoft 365
• Microsoft IoT Central
• gestione multi-tenant Microsoft Defender
• SQL Managed Instance (Istanza SQL Gestita)
• portale di amministrazione delle sottoscrizioni Visual Studio

Portale di amministrazione di Microsoft

Quando un criterio di accesso condizionale è destinato all'app cloud Microsoft Admin Portals, i criteri vengono applicati per i token rilasciati a specifici ID applicazione di risorse sottostanti associati ai portali di amministrazione Microsoft. Il raggruppamento di app non include i servizi back-end che tali portali potrebbero chiamare o da cui potrebbero dipendere. Per identificare le dipendenze del servizio dei portali di amministrazione, usare la segnalazione dei destinatari dell'accesso condizionale nei log di accesso

Le applicazioni seguenti comprendono i portali di amministrazione Microsoft:

• ID app dell'interfaccia di amministrazione di Exchange: 497effe9-df71-4043-a8bb-14cf78c4b63b
• Azure ID app del portale: c44b4083-3bb0-49c1-b47d-974e53cbdf3c
• ID app Portale di Microsoft Office 365: 0000006-0000-0ff1-ce00-00000000000000
• ID: 80ccca67-54bd-44ab-8625-4b79c4dc7775 Microsoft 365 Centro sicurezza e conformità (Protection Center) app.

Il raggruppamento del portale di amministrazione è destinato principalmente agli scenari di inclusione, per un modo semplificato per definire come destinazione uno o più portali di amministrazione con criteri di accesso condizionale, ad esempio l'applicazione dell'autenticazione a più fattori. Questo raggruppamento viene sfruttato nei criteri per gli amministratori gestiti da Microsoft MFA per semplificare la creazione dei criteri.

Questa opzione non è progettata per funzionare come meccanismo di esclusione in blocco per tutti i servizi back-end associati agli ID applicazione sottostanti.

Altre applicazioni

Gli amministratori possono aggiungere qualsiasi applicazione registrata Microsoft Entra ai criteri di accesso condizionale. Queste applicazioni possono includere:

• Applicazioni pubblicate tramite Microsoft Entra proxy applicazione
• Applicazioni aggiunte dalla galleria
• Applicazioni personalizzate non incluse nella raccolta
• Applicazioni legacy pubblicate tramite controller di distribuzione delle applicazioni e reti
• Applicazioni che usano l'accesso Single Sign-On basato su password

Alcune applicazioni non vengono visualizzate affatto nella selezione. L'unico modo per includere queste applicazioni in un criterio di accesso condizionale consiste nell'includere Tutte le risorse (in precedenza "Tutte le app cloud") o aggiungere l'entità servizio mancante usando il New-MgServicePrincipal cmdlet di PowerShell o usando il cmdlet Microsoft Graph API.

Accesso condizionale per diversi tipi di client

L'accesso condizionale si applica alle risorse non ai client, tranne quando il client è un client riservato che richiede un token ID.

• Client pubblico
  • I client pubblici sono quelli eseguiti localmente nei dispositivi come Microsoft Outlook sul desktop o sulle app per dispositivi mobili, ad esempio Microsoft Teams.
  • I criteri di accesso condizionale non si applicano ai client pubblici, ma si basano sulle risorse richieste.
• Client riservato
  • L'accesso condizionale si applica alle risorse richieste dal client e al client riservato stesso se richiede un token ID.
  • Ad esempio: se Outlook Web richiede un token per ambiti Mail.Read e Files.Read, l'accesso condizionale applica criteri per Exchange e SharePoint. Inoltre, se Outlook Web richiede un token ID, l'accesso condizionale applica anche i criteri per Outlook Web.

Per visualizzare i log di accesso per questi tipi di client dall'interfaccia di amministrazione di Microsoft Entra:

1. Accedi al centro di amministrazione Microsoft Entra almeno come Reports Reader.
2. Passare a Entra ID>Monitoraggio e integrità>Registri degli accessi.
3. Aggiungere un filtro per il tipo di credenziale client.
4. Modificare il filtro per visualizzare un set specifico di log in base alle credenziali client usate nell'accesso.

Per altre informazioni, vedere l'articolo Applicazioni client pubbliche e client riservate.

Accesso condizionale per tutte le risorse

L'applicazione di un criterio di accesso condizionale a Tutte le risorse (in precedenza "Tutte le app cloud") senza esclusioni di risorse applica i criteri per tutte le richieste di token da siti Web e servizi, inclusi i profili di inoltro del traffico di accesso sicuro globale. Questa opzione include applicazioni che non sono destinate singolarmente ai criteri di accesso condizionale, ad esempio Windows Azure Active Directory (00000002-0000-0000-c000-0000000000000).

Comportamento dell'accesso condizionale legacy quando un criterio per TUTTE le risorse ha un'esclusione di una risorsa

Se un'app viene esclusa dai criteri, per non bloccare inavvertitamente l'accesso utente, alcuni ambiti con privilegi limitati sono stati precedentemente esclusi dall'imposizione dei criteri. Questi ambiti hanno consentito chiamate alle API Graph sottostanti, ad esempio Windows Azure Active Directory (000000002-0000-0000-c000-000000000000) e Microsoft Graph (00000003-0000-0000-c000-0000000000000), per accedere alle informazioni di appartenenza al profilo utente e ai gruppi comunemente usate dalle applicazioni come parte dell'autenticazione. Ad esempio: quando Outlook richiede un token per Exchange, richiede anche l'ambito User.Read per poter visualizzare le informazioni di base sull'account dell'utente corrente.

La maggior parte delle app ha una dipendenza simile, motivo per cui questi ambiti con privilegi limitati sono stati esclusi automaticamente nei criteri Tutte le risorse . Gli ambiti esclusi in precedenza sono elencati come segue, il consenso è comunque necessario per consentire alle app di usare queste autorizzazioni.

• I client nativi e le applicazioni a pagina singola hanno accesso agli ambiti con privilegi limitati seguenti:
  • Grafo Azure AD: email, offline_access, openid, profile, User.Read
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, People.Read
• I client riservati hanno accesso agli ambiti con privilegi limitati seguenti, se sono esclusi da un criterio Tutte le risorse :
  • Graph Azure AD: 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

Nuovo comportamento di accesso condizionale quando un criterio per TUTTE le risorse ha un'esclusione di una risorsa

Gli ambiti elencati nella sezione precedente vengono ora valutati come accesso alla directory ed è stato eseguito il mapping a Azure AD Graph (risorsa: Windows Azure Active Directory, ID: 00000002-0000-0000-c000-00000000000000) per scopi di valutazione dell'accesso condizionale.

I criteri di accesso condizionale destinati a tutte le risorse con una o più esclusioni di risorse, o criteri che mirano esplicitamente Azure AD Graph, vengono applicati nei flussi di accesso degli utenti in cui l'applicazione client richiede solo questi ambiti di autorizzazione. Non viene apportata alcuna modifica al comportamento quando un'applicazione richiede un ambito aggiuntivo oltre a quelli elencati in precedenza.

Esperienza utente

Nei flussi di accesso utente in cui le applicazioni client richiedono solo gli ambiti elencati in precedenza, gli utenti potrebbero ora ricevere problemi di accesso condizionale( ad esempio MFA o conformità del dispositivo). La sfida esatta dipende dai controlli di accesso configurati nei criteri destinati a Tutte le risorse (con o senza esclusioni di risorse) o ai criteri destinati in modo esplicito a Azure Ad Graph.

Nell'esempio seguente il tenant ha un criterio di accesso condizionale con i dettagli seguenti:

• Selezione di tutti gli utenti e tutte le risorse
• Esclusioni di risorse per un'applicazione client riservata e Exchange Online
• L'autenticazione a più fattori è configurata come controllo di concessione delle autorizzazioni

Scenari di esempio

Non viene apportata alcuna modifica al comportamento quando un'applicazione client richiede un ambito oltre quelli elencati in precedenza, come illustrato negli esempi seguenti.

Scenari di esempio

La maggior parte delle applicazioni richiede ambiti oltre gli ambiti elencati in precedenza e sono già soggetti all'imposizione dell'accesso condizionale, a meno che l'applicazione non venga esplicitamente esclusa dai criteri. In questi casi, non vi è alcuna modifica del comportamento.

Le applicazioni personalizzate progettate intenzionalmente per richiedere solo gli ambiti elencati in precedenza e non sono progettate per gestire i problemi di accesso condizionale potrebbero dover essere aggiornate in modo che possano gestire le problematiche di accesso condizionale. Per informazioni dettagliate sull'implementazione, vedere le linee guida per gli sviluppatori per l'accesso condizionale Microsoft .

Come identificare le applicazioni interessate dal cambiamento nell'applicazione dell'ambito a basso privilegio

Le applicazioni possono essere pre-autorizzate a richiedere solo uno o più ambiti elencati in precedenza. Usare le opzioni seguenti per identificare le applicazioni interessate.

# ==============================
# 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

Protezione delle informazioni di directory

Se il criterio di baseline consigliata MFA senza esclusioni di risorse non può essere configurato a causa di motivi aziendali, e i criteri di sicurezza dell'organizzazione devono includere ambiti con privilegi limitati correlati alla directory (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), creare un criterio di accesso condizionale separato destinato a Windows Azure Active Directory (00000002-0000-0000-c000-00000000000000). Windows Azure Active Directory (detto anche Azure AD Graph) è una risorsa che rappresenta i dati archiviati nella directory, ad esempio utenti, gruppi e applicazioni. La risorsa Windows Azure Active Directory è inclusa in Tutte le risorse ma possono essere assegnate singolarmente nei criteri di accesso condizionale seguendo questa procedura:

1. Accedi al centro di amministrazione Microsoft Entra come Amministratore della Definizione degli Attributi e Amministratore dell'Assegnazione degli Attributi.
2. Naviga su Entra ID>Attributi di sicurezza personalizzati.
3. Creare un nuovo set di attributi e una definizione di attributo. Per altre informazioni, vedere Aggiungi o disattiva definizioni di attributi di sicurezza personalizzati in Microsoft Entra ID.
4. Naviga a Entra ID>applicazioni aziendali.
5. Rimuovere il filtro Tipo di applicazione e cercare ID applicazione che inizia con 00000002-0000-0000-c000-000000000000000.
6. Selezionare Windows Azure Active Directory> Attributi di sicurezza personalizzati>Aggiungi assegnazione.
7. Selezionare il set di attributi e il valore dell'attributo che si prevede di usare nei criteri.
8. Passare a Entra ID>Accesso Condizionale>Politiche.
9. Creare o modificare un criterio esistente.
10. In Risorse di destinazione>(in precedenza app cloud)>Includi selezionare >Seleziona risorse>Modifica filtro.
11. Modificare il filtro in modo da includere il set di attributi e la definizione precedenti.
12. In Controlli di accesso>, nella sezione Concedi, selezionare Concedi accesso, Richiedi livello di forza dell'autenticazione, selezionare Autenticazione a più fattori e quindi selezionare Seleziona.
13. Confermate le impostazioni e impostate Abilita politica su Solo segnalazione.
14. Selezionare Crea per abilitare il tuo criterio.

Tutte le risorse Internet con accesso sicuro globale

L'opzione Tutte le risorse Internet con accesso sicuro globale consente agli amministratori di scegliere come destinazione il profilo di inoltro del traffico internet access traffic forwarding profile da Microsoft Entra Internet Access.

Questi profili in Accesso sicuro globale consentono agli amministratori di definire e controllare il modo in cui il traffico viene instradato attraverso Microsoft Entra Internet Access e Microsoft Entra Private Access. I profili di inoltro del traffico possono essere assegnati a dispositivi e reti remote. Per un esempio di come applicare criteri di accesso condizionale a questi profili di traffico, vedere l'articolo Come applicare i criteri di accesso condizionale al profilo di traffico Microsoft 365.

Per altre informazioni su questi profili, vedere l'articolo Profili di inoltro del traffico di accesso sicuro globale.

Tutte le risorse dell'agente (anteprima)

L'applicazione di un criterio di accesso condizionale a tutte le risorse dell'agente applica il criterio per tutte le richieste di token ai principali dello schema di identità dell'agente e alle identità dell'agente.

Azioni utente

Le azioni utente sono attività eseguite da un utente. L'accesso condizionale supporta due azioni utente:

• Registra informazioni di sicurezza: questa azione utente consente ai criteri di accesso condizionale di applicare regole quando gli utenti tentano di registrare le informazioni di sicurezza. Per altre informazioni, vedere Registrazione combinata delle informazioni di sicurezza.

• Registrare o aggiungere dispositivi: questa azione utente consente agli amministratori di applicare i criteri di accesso condizionale quando gli utenti register o join ai dispositivi Microsoft Entra ID. Consente agli amministratori di configurare l'autenticazione a più fattori per la registrazione o l'aggiunta di dispositivi con una maggiore granularità rispetto ai criteri a livello di tenant. Questa azione utente presenta tre considerazioni chiave:
  • Require multifactor authentication e Require auth strength sono gli unici controlli di accesso disponibili con questa azione utente e tutti gli altri sono disabilitati. Questa restrizione impedisce conflitti con i controlli di accesso che dipendono dalla registrazione del dispositivo Microsoft Entra o che non sono applicabili alla registrazione del dispositivo.
    • Windows Hello for Business e passkey associati a dispositivo non sono supportati perché questi scenari richiedono che il dispositivo sia già registrato.
  • Client apps, Filters for devices e Device state condizioni non sono disponibili con questa azione utente perché dipendono dalla registrazione del dispositivo Microsoft Entra per applicare i criteri di accesso condizionale.

Contesto di autenticazione

Il contesto di autenticazione protegge i dati e le azioni nelle applicazioni. Queste applicazioni includono applicazioni personalizzate, applicazioni line-of-business (LOB), SharePoint o applicazioni protette da Microsoft Defender for Cloud Apps. Può essere usato anche con Microsoft Entra Privileged Identity Management (PIM) per applicare i criteri di accesso condizionale durante l'attivazione dei ruoli.

Ad esempio, un'organizzazione potrebbe archiviare file in SharePoint siti come un menu per il pranzo o una ricetta segreta di salsa BARBECUE. Tutti possono accedere al sito del menu per il pranzo, ma gli utenti che accedono al sito della ricetta segreta della salsa BBQ potrebbero dover usare un dispositivo gestito e accettare condizioni specifiche per l'uso. Analogamente, un amministratore che attiva un ruolo con privilegi tramite PIM potrebbe essere necessario per eseguire l'autenticazione a più fattori o usare un dispositivo conforme.

Il contesto di autenticazione funziona con utenti o identità del carico di lavoro, ma non con gli stessi criteri di accesso condizionale.

Configurare i contesti di autenticazione

Gestire i contesti di autenticazione passando a Entra ID>Accesso Condizionale>Contesto di autenticazione.

Selezionare Nuovo contesto di autenticazione per creare una definizione del contesto di autenticazione. Le organizzazioni possono creare fino a 99 definizioni di contesto di autenticazione (c1-c99). Configurare questi attributi:

• Nome visualizzato è il nome usato per identificare il contesto di autenticazione in Microsoft Entra ID e tra le applicazioni che utilizzano contesti di autenticazione. È consigliabile usare nomi tra le risorse, ad esempio i dispositivi attendibili, per ridurre il numero di contesti di autenticazione necessari. La presenza di un set ridotto limita il numero di reindirizzamenti e offre un'esperienza migliore per l'utente finale.
• La descrizione fornisce altre informazioni sui criteri. Queste informazioni vengono usate dagli amministratori e da quelli che applicano contesti di autenticazione alle risorse.
• La casella di controllo Pubblica nelle app, se selezionata, annuncia il contesto di autenticazione alle app e la rende disponibile per l'assegnazione. Se non è selezionata, il contesto di autenticazione non è disponibile per le risorse downstream.
• L'ID è di sola lettura e viene usato nei token e nelle app per le definizioni di contesto di autenticazione specifiche della richiesta. Qui sono elencati i casi d'uso per la risoluzione dei problemi e lo sviluppo.

Aggiungere ai criteri di accesso condizionale

Gli amministratori possono selezionare i contesti di autenticazione pubblicati nei criteri di accesso condizionale passando a Assegnazioni>App o azioni cloud e selezionando Contesto di autenticazione dal menu Seleziona a cui si applica questo criterio .

Eliminare un contesto di autenticazione

Prima di eliminare un contesto di autenticazione, assicurarsi che nessuna applicazione la usi. In caso contrario, l'accesso ai dati dell'app non è protetto. Confermare questo controllando i log di accesso per i casi in cui vengono applicati criteri di accesso condizionale basati sul contesto di autenticazione.

Per eliminare un contesto di autenticazione, assicurarsi che non abbia criteri di accesso condizionale assegnati e non venga pubblicato nelle app. Ciò impedisce l'eliminazione accidentale di un contesto di autenticazione ancora in uso.

Contrassegna le risorse con contesti di autenticazione

Per altre informazioni sull'uso dei contesti di autenticazione, vedere gli articoli seguenti.

• Usare le etichette di riservatezza per proteggere il contenuto in Microsoft Teams, gruppi di Microsoft 365 e siti SharePoint
• Microsoft Defender for Cloud Apps
• Applicazioni personalizzate
• Privileged Identity Management - Durante l'attivazione, richiedere il contesto di autenticazione di Accesso Condizionale di Microsoft Entra

Contenuti correlati

• Accesso condizionale: condizioni: informazioni su come configurare le condizioni per perfezionare i criteri.
• Criteri comuni di accesso condizionale : esplorare i modelli di criteri comuni per iniziare rapidamente.
• Dipendenze dell'applicazione client: informazioni sull'impatto delle dipendenze sui criteri di accesso condizionale.