Sostituire i profili delle entità servizio con le entità servizio

Se la soluzione usa profili dell'entità servizio principale (SPP) e le relative identità, governance, API o limitazioni operative vincolano i requisiti, questa guida consente di valutare e implementare una sostituzione basata su entità servizio principale dedicate Microsoft Entra. Se la soluzione basata su profilo esistente soddisfa i requisiti, è possibile continuare a usarla.

Per i clienti che scelgono di eseguire la migrazione, questa guida consiglia l'identità gestita e le credenziali federate quando sono soddisfatti i requisiti di hosting e attendibilità. L'autenticazione diretta del service principal rimane un'alternativa. Entrambi i percorsi forniscono identità dei clienti dedicate per la governance delle directory, il monitoraggio indipendente dell'autenticazione e l'accesso ai servizi supportati oltre alle interfacce con riconoscimento dei profili.

Perché eseguire la migrazione dai profili

Valutare la possibilità di sostituire i profili quando le limitazioni seguenti vincolano la soluzione:

• I profili non sono conformi alle best practice di Microsoft Entra ID per le identità del carico di lavoro gestibili. Un profilo non ha alcuna rappresentazione in Microsoft Entra ID. Non produce log di accesso indipendenti, non può avere criteri di Accesso Condizionale propri e non può essere governato dagli strumenti usati per il resto del patrimonio di identità.

Ad esempio, non è possibile configurare un profilo come identità di una connessione Direct Lake da un modello semantico a un lakehouse o a un warehouse. Né è possibile concedergli l'accesso come identità indipendente Microsoft Entra ad altri servizi downstream che l'applicazione o i relativi carichi di lavoro devono raggiungere. Un service principal dedicato può ricevere tali autorizzazioni se il servizio lo supporta.

Non è possibile usare i profili con le API REST Fabric. I profili sono supportati solo dall'API REST compatibile con il profilo, da .NET SDK e dalle interfacce XMLA/TOM supportate. Le API REST Fabric non supportano i profili e il supporto non è previsto. Usare un'identità supportata per le chiamate API anziché un profilo. La creazione di un service principal dedicato risolve il requisito di identità, ma ogni API e operazione deve comunque supportare tale identità e concederle le autorizzazioni necessarie.

• L'autenticazione rimane associata all'identità principale. Quando l'elemento padre usa un segreto o un certificato, proteggerla ed eseguirne la rotazione. Il modello di sostituzione consigliato evita l'archiviazione delle credenziali dell'applicazione del cliente. I profili possono anche usare un elemento padre con identità gestita, quindi la sola autenticazione senza segreti non richiede la sostituzione dei profili. Un'identità gestita padre non offre ai profili identità di directory indipendenti né un supporto API più ampio.

I profili risolvono un problema di scalabilità, non un problema di identità indipendente. Un service principal padre può creare fino a 100.000 profili e ogni profilo può accedere o creare fino a 1.000 aree di lavoro. Un service principal può appartenere al massimo a 1.000 aree di lavoro in questo modello. Le identità dei clienti dedicate consumano invece oggetti directory di Microsoft Entra. Convalida i limiti applicabili in base al numero di clienti prima di procedere con la migrazione.

Note

Limite di sicurezza: Un profilo non è un limite crittografico del cliente: il service principal padre può agire tramite uno qualsiasi dei relativi profili. Il modello consigliato consente anche all'identità gestita di runtime di autenticarsi come qualsiasi applicazione del cliente che la considera attendibile. Le autorizzazioni dell'area di lavoro e delle risorse rimangono il confine di autorizzazione applicato. Proteggere il runtime e il mapping da cliente a identità in entrambi i modelli.

Altre limitazioni del profilo da considerare

Limitation	Impatto della migrazione
Nessuna identità di controllo o dei criteri indipendenti	Un profilo non dispone di un record di accesso Microsoft Entra indipendente né di una destinazione di Accesso condizionale per l'identità del carico di lavoro. I service principal dedicati forniscono tali funzionalità, in base all'idoneità prevista dai criteri e ai requisiti di licenza.
Accoppiamento permanente tra profilo ed elemento padre	I profili non possono essere trasferiti a un'altra entità servizio principale padre. Per sostituire l'elemento padre sono necessari nuovi profili, nuove autorizzazioni del workspace e mappature clienti aggiornate.
Nessun portale di amministrazione delle identità	I profili sono solo API e non sono rappresentati negli strumenti di amministrazione di Microsoft Entra. Le applicazioni dedicate e le entità servizio principale hanno visibilità e interfacce di gestione della directory.

Pattern di identità gestita e credenziali federate

Usare questo modello quando si sceglie di sostituire i profili e il runtime soddisfa i requisiti di hosting delle identità gestite.

Lo schema

Assegnare a ogni cliente un service principal Microsoft Entra reale e usare l'identità gestita dell'applicazione come origine di asserzione. Questo approccio sostituisce sia la credenziale dell'applicazione condivisa che l'astrazione del profilo. È possibile registrare, gestire e prendere in considerazione ogni identità cliente per l'Accesso condizionale per identità del carico di lavoro, e ognuna di esse può chiamare le API REST di Fabric supportate.

Questo approccio è il percorso di migrazione consigliato nei casi in cui i requisiti di hosting e fiducia di Azure si adattano alla soluzione. Rimuove le credenziali dell'applicazione del cliente archiviate e i relativi processi di rotazione senza modificare la posizione in cui viene applicata l'autorizzazione dell'area di lavoro e delle risorse.

L'architettura mostra le operazioni di runtime dell'applicazione, tre identità e trust delle applicazioni cliente e le relazioni uno a uno tra le aree di lavoro dei clienti. Rappresenta la configurazione predefinita del runtime condiviso, non un nuovo confine di isolamento.

Figura 1. Un'identità gestita dell'applicazione viene autenticata come entità servizio dedicate del cliente.

Funzionamento

1. Identità gestita dall'applicazione. Assegnare un'identità gestita assegnata dall'utente all'applicazione ISV in esecuzione nelle risorse di calcolo Azure supportate, ad esempio App Service, Container Apps, un carico di lavoro AKS configurato in modo appropriato o una macchina virtuale. Usare un'identità gestita per l'applicazione, non una per ogni cliente. Non dispone di autorizzazioni specifiche per l'area di lavoro del cliente o del servizio di destinazione; il suo ruolo è solo quello di fornire un'asserzione.

2. Entità servizio per cliente, per utente o per gruppo. Per ogni limite di autorizzazione o cliente esistente, creare una registrazione dell'applicazione Microsoft Entra e un service principal nel tenant della directory ISV. Un cliente logico non significa necessariamente un tenant di Microsoft Entra separato e non è necessaria un'identità per ogni utente finale, a meno che la progettazione dell'accesso esistente non lo richieda.

3. Credenziale di identità federata. Configurare una credenziale di identità federata in ogni registrazione dell'applicazione cliente per considerare attendibile l'identità gestita dell'applicazione. Il runtime può quindi usare il token di identità gestito come asserzione per ottenere un token di accesso per l'applicazione cliente senza un segreto client o un certificato.

4. Scambio di token di runtime. Quando l'utente A o un processo specifico del cliente richiama l'applicazione, risolvere il cliente A tramite un mapping lato server attendibile. Acquisire il token di identità gestita con audience api://AzureADTokenExchange; scambiarlo con un token di accesso come SP-A; quindi chiamare le API di destinazione usando il token di SP-A per gestire le aree di lavoro, eseguire operazioni sulle risorse o richiedere token specifici dell'applicazione, se necessario.

   Per lo scambio nel passaggio precedente, il .NET Azure Identity ClientAssertionCredential accetta il token di identità gestito come asserzione client. Si tratta di un tipo di credenziale identity Azure, non di una classe MSAL. Il token di accesso deve essere destinato all'audience dell'API della risorsa, non all'audience di token exchange.

5. Accesso all'area di lavoro. Concedere a ogni membro o amministratore del service principal l'accesso solo alle aree di lavoro designate quando questi ruoli sono necessari o al ruolo supportato con privilegi minimi per le operazioni necessarie. Tale autorizzazione definisce l'ambito dell'accesso alle risorse. Poiché l'identità gestita dell'applicazione può eseguire l'autenticazione come ogni applicazione del cliente che la considera attendibile, considerarla e i relativi host di calcolo come identità e infrastruttura di valore elevato.

Perché questo percorso è consigliato

• Meno credenziali di lunga durata. Non è necessario archiviare, recuperare o distribuire al runtime alcun segreto dell'applicazione cliente o chiave privata del certificato.

• Meno lavoro per la rotazione. Azure gestisce le credenziali dell'identità gestita e rilascia token di breve durata. Non è necessario un processo di rinnovo del segreto o del certificato separato per ogni applicazione cliente che usa questa relazione di trust.

• Onboarding coerente. Effettuare il provisioning di un'applicazione cliente e di un service principal, definire l'attendibilità esplicita e concedere l'accesso alle risorse del cliente. I nuovi clienti non richiedono nuove credenziali di lunga durata.

Questi vantaggi non eliminano la necessità di amministrazione delle relazioni di trust, autorizzazione del cliente, monitoraggio degli audit o pianificazione della capacità della directory.

Alternativa: autenticazione diretta del service principal

Se non si vuole usare l'identità gestita e le credenziali federate, creare le stesse registrazioni di applicazione cliente dedicate e gli stessi entità servizio, ma autenticarli direttamente con certificati o un'altra credenziale dell'applicazione supportata. Preferire i certificati rispetto ai segreti del client, se supportati. Proteggere chiavi private e secret, limitare l'accesso a tali chiavi e automatizzare la rotazione.

L'autenticazione diretta mantiene la visibilità della directory, i log di accesso per identità e l'accesso alle API supportate. Non richiede l'hosting o la configurazione di trust dell'identità gestita, ma non elimina le credenziali del cliente archiviate.

Concetti chiave

Distinguere le credenziali che stabiliscono l'attendibilità dai token usati in fase di esecuzione.

Credenziali di identità federate

Configurare una credenziale dell'identità federata (FIC) nella registrazione dell'applicazione Microsoft Entra associata all'entità servizio. Definisce una relazione di trust con un'autorità emittente di token e specifica quale asserzione accetta l'applicazione anziché un segreto client o un certificato.

In questa architettura, l'identità di destinazione è l'applicazione del cliente e il service principal; l'identità gestita dell'applicazione è l'origine dell'asserzione. Questo è il motivo per cui si configura la credenziale del cliente nella registrazione dell'applicazione anziché nell'oggetto entità servizio o nell'identità gestita di origine.

Note

Distinzione di configurazione: Le credenziali di identità federate sono supportate anche nelle identità gestite con assegnazione utente in altri scenari di federazione. Questo non modifica lo schema qui: configurare l'attendibilità per ogni registrazione dell'applicazione del cliente. Solo un'identità gestita assegnata dall'utente è supportata come origine dell'asserzione di identità gestita nel modello di attendibilità dell'app descritto in questa guida.

Campo trust	Valore nel cloud globale
Issuer	https://login.microsoftonline.com/{directory-tenant-id}/v2.0
Subject	ID entità (oggetto) dell'identità gestita assegnata a livello di utente. Non usare il relativo ID client.
Partecipanti	api://AzureADTokenExchange

Quando l'applicazione presenta il token di identità gestita e richiede un token di accesso per l'applicazione del cliente, Microsoft Entra ID convalida l'asserzione rispetto alla credenziale federata. L'autorità emittente, l'oggetto e il gruppo di destinatari devono corrispondere. Se la convalida ha esito positivo, rilascia un token di accesso che rappresenta il service principal del cliente di destinazione per la risorsa richiesta.

L'identità gestita e la registrazione dell'applicazione attendibile devono trovarsi nello stesso tenant Microsoft Entra. Il gruppo di destinatari delle risorse è una scelta separata dal gruppo di destinatari dell'asserzione. Per Azure Identity, l'ambito global-cloud token-exchange è api://AzureADTokenExchange/.default; l'ambito dell'API di destinazione è in genere l'identificatore della risorsa seguito da /.default.

Flusso di scambio di token: credenziali client con un'asserzione federata

Questo flusso prevede tre partecipanti e sei passaggi. SP-A è l'applicazione e il service principal del cliente A. Il token di asserzione dell'identità gestita e il token di accesso alle risorse SP-A restituito hanno scopi diversi.

Figura 2. Scambio di token di credenziali client supportato da un'asserzione di identità gestita.

1. Richiedere il token di identità gestita. L'app in Azure richiede un token di identità gestita con audience api://AzureADTokenExchange.

2. Restituisce il token di asserzione. Microsoft Entra ID rilascia il token di identità gestita, che l'app riceve tramite il relativo meccanismo di identità gestita dell'ambiente di hosting Azure.

3. Inviare la richiesta di token del cliente. Inviare una richiesta all'endpoint del tenant della /oauth2/v2.0/token directory con grant_type=client_credentials, client_id=<SP-A-client-id>client_assertion=<MI-token>, e scope=<target-resource>/.default. La richiesta OAuth completa fornisce client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-beareranche ; una libreria di identità gestisce questo parametro.

4. Convalida l'asserzione. Microsoft Entra ID convalida il token di identità gestita rispetto alla credenziale federata nella registrazione dell'applicazione di SP-A.

5. Restituire il token di accesso del cliente. Microsoft Entra ID restituisce un token di accesso per SP-A con la risorsa di destinazione come destinatario.

6. Chiamare le API REST di destinazione. L'app invia il token di accesso di SP-A all'API di destinazione. Non usa il token di asserzione come token bearer della risorsa e non seleziona un profilo.

Confronto tra architetture

La colonna di sostituzione copre in genere le entità di servizio dedicate. L'identità gestita e la federazione sono il metodo di autenticazione consigliato, ma è anche possibile l'autenticazione diretta tramite certificato o un altro metodo di autenticazione supportato tramite credenziali.

Aspect	Profili dell'entità servizio	entità servizio dedicate
ID per cliente	Profilo logico, non oggetto Microsoft Entra.	Registrazione dell'applicazione e service principal che rappresenta il limite di autorizzazione del cliente.
Confine imposto	Autorizzazioni per l'area di lavoro e le risorse.	Autorizzazioni per l'area di lavoro e le risorse.
Portata dell'identità root	Il service principal padre può fungere da uno qualsiasi dei suoi profili.	Un runtime può raggiungere tutte le identità per le quali dispone di credenziali o asserzioni attendibili; un'identità gestita (MI) può autenticarsi come qualsiasi app che la considera attendibile.
Rotazione dei segreti	Obbligatorio quando l'elemento padre usa un segreto o un certificato.	Non obbligatorio per le credenziali dell'identità gestita; obbligatorio per i certificati archiviati o i segreti client nel percorso diretto.
Ridimensiona il soffitto	Fino a 100.000 profili per SP padre; ogni profilo fino a 1.000 aree di lavoro. Lo SP padre può appartenere a un massimo di 1.000 aree di lavoro.	Registrazione dell'applicazione e service principal per cliente, soggetta a quote di oggetti directory e limiti delle risorse di ogni servizio di destinazione.
Traccia di controllo	Gli ID profilo potrebbero essere visualizzati nei log delle risorse, ma i profili non dispongono di un record di accesso indipendente di Microsoft Entra.	Microsoft Entra record di accesso per ogni service principal, correlati ai log di controllo delle applicazioni e delle risorse.
Accesso condizionale	Nessun criterio dell'identità del carico di lavoro per profilo.	Disponibile per i service principal idonei con ID dei carichi di lavoro di Microsoft Entra Premium; il criterio deve essere destinato direttamente a ogni service principal.
Visibilità del portale	Non presente in Microsoft Entra ID.	Registrazione dell'applicazione in Registrazioni app; entità servizio principale nelle applicazioni aziendali.
supporto dell'API REST Fabric	Non supportato; il supporto non è previsto.	Supportato quando l'API e l'operazione specifiche accettano service principal, con le autorizzazioni necessarie.
Trasferimento delle credenziali e associazione al parent	Non è possibile trasferire un profilo tra le entità servizio principali padre.	Il trust federato può essere riconfigurato; le credenziali dirette possono essere sostituite senza ricreare un'astrazione del profilo.

Come leggere questa tabella: nessuna configurazione fornisce l'isolamento crittografico dei tenant. Le autorizzazioni delle risorse regolano l'accesso e il runtime potrebbe avere un accesso indiretto tra i clienti. I profili offrono una gestione dell'identità leggera e scalabile. Le entità servizio dedicate migliorano la governance delle directory, la visibilità degli accessi e la compatibilità delle API. Il percorso di identità gestita e federazione consigliato rimuove anche le credenziali dell'applicazione del cliente archiviate.

Percorso di migrazione

Il percorso seguente sostituisce i profili con entità servizio del cliente dedicate. Mantenere separate le decisioni relative alla migrazione e al rollback per ogni cliente.

Da profili a identità gestite e credenziali federate

Usare le fasi di migrazione seguenti con una coorte pilota di piccole dimensioni e un interruttore di rollout per cliente. Mantenere disponibile la route del profilo fino al completamento della convalida e del periodo di rollback concordato.

Fase 0: Creare l'identità gestita dell'applicazione

• Creare l'identità gestita assegnata dall'utente per l'applicazione e assegnarla alla risorsa di calcolo. La guida all'implementazione mostra i comandi di creazione e assegnazione.

• Registrare l'ID dell'oggetto principale. Le credenziali federate di ogni applicazione cliente usano questo valore come soggetto. Registrare anche l'ID client, l'ID tenant della directory e l'ID risorsa di Azure.

Usare un'identità gestita per l'applicazione, non una per cliente. Un'identità gestita separata per ogni cliente non è necessaria in questo modello: l'identità del cliente è il service principal e l'identità gestita fornisce l'asserzione. Per distribuzioni di dimensioni maggiori o un ambito di compromissione inferiore, suddividere i clienti tra un numero ridotto di identità di runtime, ognuna considerata attendibile solo dal sottoinsieme assegnato delle applicazioni dei clienti.

Fase 1: Inventario

Elencare tutti i profili esistenti tramite profile-management API:

GET {profile-api-base}/v1.0/myorg/profiles

Per ogni profilo, registrare:

• ID profilo e nome visualizzato, entità servizio principale padre e mapping dei clienti.

• Workspace associati e assegnazioni dei ruoli

• Modelli semantici associati o set di dati, report e altre risorse.

• Connessioni, credenziali dell'origine dati, dipendenze di proprietà, processi in background e operazioni API che dipendono dal profilo.

Prima di modificare la configurazione di un cliente, registrare i ruoli dell'area di lavoro esistenti, la proprietà del modello semantico, le identità di connessione, la configurazione delle credenziali e il mapping da cliente a profilo necessari per il rollback. Registrare riferimenti sicuri alle credenziali, non ai valori segreti.

Registrare il numero totale dei clienti e confrontare gli oggetti applicazione e gli oggetti entità servizio necessari con la quota degli oggetti directory di Microsoft Entra prima di continuare. Verificare anche il limite di appartenenza a 1.000 aree di lavoro e tutti i limiti specifici delle risorse. Se la popolazione supera la quota di una singola directory, pianificare un aumento di quota supportato o una progettazione deliberatamente gestita da più directory; non viene risolto automaticamente da questo schema.

Note

Notazione endpoint:{profile-api-base} indica l'URL di base dell'API REST sensibile al profilo già usato dalla tua soluzione. Mantieni l'URL nella configurazione di distribuzione. Questi esempi mantengono i percorsi operativi; sostituire ogni segnaposto prima di eseguirli. Il termine profile-aware descrive il supporto dell'API, non uno stato di deprecazione.

Fase 2: Effettuare il provisioning di nuove identità

Per ogni profilo o gruppo di profili appartenenti allo stesso perimetro di autorizzazione del cliente:

1. Creare una registrazione dell'applicazione e un service principal. Registrare separatamente l'ID client dell'applicazione, l'ID oggetto applicazione e l'ID oggetto dell'entità servizio.

2. Configurare una credenziale di identità federata nella registrazione dell'applicazione del cliente che si fida dell'identità gestita (MI) dell'applicazione creata nella fase 0.

3. Concedere alla nuova entità servizio dell'applicazione l'accesso alle stesse aree di lavoro e risorse del cliente. Usare Membro in cui le operazioni inventariate lo richiedono o il ruolo supportato con privilegi minimi. Concedi i diritti di amministratore solo quando necessario.

Mantenere gli ID di risorse e dell'area di lavoro esistenti ovunque sia supportato. Un'autorizzazione dell'area di lavoro non trasferisce automaticamente la proprietà delle risorse, le identità di connessione o le credenziali della fonte dati. Completare gli aggiornamenti specifici del servizio prima del cutover.

Fase 3: Aggiornare il codice dell'applicazione

• Sostituire l'intestazione di selezione del profilo e la configurazione del profilo SDK con lo scambio di token supportato da identità gestita per l'applicazione cliente selezionata.

• Aggiornare il mapping da cliente a identità nel database dell'applicazione.

Prima di	Dopo
customerId -> profileId con una credenziale sp condivisa e un'intestazione del profilo.	customerId -> spClientId con l'autenticazione SP per cliente tramite lo scambio di token di identità gestito. Mantenere anche l'ID tenant della directory, la configurazione di autenticazione e gli ID risorsa consentiti.

Gli ID cliente sono identificatori logici dei clienti ISV, non necessariamente ID tenant di Microsoft Entra. Verificare l'appartenenza del cliente dell'utente autenticato prima di selezionare un'identità. Cache dei token chiave in base al tenant della directory, all'ID client e alla risorsa o all'ambito.

• Aggiornare la generazione di token specifici dell'applicazione per usare il token di accesso del service principal del cliente. Se la soluzione incorpora report o altri contenuti, aggiornare anche la generazione di token; l'incorporamento è un carico di lavoro esistente di cui eseguire la migrazione, non un prerequisito per questa guida.

• Aggiornare la gestione dell'area di lavoro, le connessioni downstream, il provisioning, i processi pianificati e ogni altro punto di ingresso usando la vecchia configurazione del profilo.

Fase 4: Convalidare

Per ogni cliente, verificare:

• L'accesso alle risorse e all'area di lavoro ha esito positivo tramite il nuovo service principal.

• L'acquisizione del token di identità gestita e lo scambio di token federati hanno esito positivo per l'applicazione cliente prevista.

• I token specifici dell'applicazione vengono generati correttamente se usati e i report esistenti o altri contenuti incorporati vengono visualizzati correttamente, se applicabile.

• I nuovi accessi del service principal vengono visualizzati in Microsoft Entra ID e possono essere correlati ai log di controllo delle applicazioni e delle risorse.

• Accesso tra clienti negato: un chiamante non può selezionare l'identità dell'applicazione o gli ID risorsa di un altro cliente.

Prima del cutover di produzione, documentare e testare la procedura di rollback per un cliente pilota. Includi il ripristino di qualsiasi titolarità del modello semantico, identità di connessione, credenziali dell'origine dati e autorizzazioni modificate durante la migrazione. Verificare che il profilo precedente possa eseguire le operazioni necessarie dopo il rollback, inclusi l'aggiornamento della configurazione e gli aggiornamenti dei parametri.

Cambiare il percorso dell'applicazione del cliente solo dopo il superamento dei criteri di accettazione. Monitorare guasti, prestazioni e autorizzazioni prima di espandere l'implementazione.

Se la convalida ha esito negativo, sospendere i processi in background interessati e ripristinare la configurazione precedente usando le procedure supportate per ogni servizio. Il passaggio della route dell'applicazione di nuovo al profilo da solo potrebbe non ripristinare operazioni che dipendono dalla proprietà o dalle credenziali. Dopo aver ripristinato la configurazione richiesta, tornare alla route basata su profilo e verificare l'accesso alle risorse e le operazioni dipendenti prima di riprendere i processi. Mantenere i profili originali e le autorizzazioni necessarie per tutto il periodo di rollback.

Fase 5: Dismettere i profili

• Dopo il periodo di rollback, rimuovere le autorizzazioni obsolete dei workspace original-parent e profile, dopo aver confermato che i service principal del cliente dedicati dispongono dell'accesso necessario.

Eliminare ogni profilo migrato tramite l'API profile-management:

DELETE {profile-api-base}/v1.0/myorg/profiles/{profileId}

• Facoltativamente, eliminare la registrazione dell'applicazione condivisa originale e il service principal se nessun cliente, processo o carico di lavoro non correlato li usa ancora. Ritirare le credenziali obsolete e mantenere i mapping di migrazione e i record di controllo in base ai requisiti di conservazione.

Note

Migrazione alternativa senza MI o federazione: L'identità gestita e le credenziali federate sono consigliate, non obbligatorie. Se non si vuole usarli, omettere la fase 0. Nella fase 2 configurare un certificato o un'altra credenziale supportata in ogni applicazione del cliente anziché una credenziale federata. Nelle fasi 3 e 4, ottenere e convalidare i token di accesso direttamente come tale applicazione. Mantenere lo stesso inventario, le concessioni di risorse, l'autorizzazione del cliente, l'implementazione e le fasi di dismissione e gestire l'archiviazione e la rotazione delle credenziali sicure.

Guida all'implementazione

Questa guida implementa l'identità gestita consigliata e l'approccio delle credenziali federate. L'alternativa per l'autenticazione diretta segue la stessa configurazione di identità e autorizzazione e viene descritta dopo i passaggi principali. Gli esempi di interfaccia della riga di comando di Azure usano la sintassi Bash; sostituire i segnaposto e accedere alla directory e alla sottoscrizione desiderata prima di eseguirli.

Prerequisites

• Una sottoscrizione Azure e le autorizzazioni per creare e assegnare identità gestite per il percorso consigliato.

• Autorizzazioni in Microsoft Entra ID per creare registrazioni delle applicazioni ed entità di servizio e aggiornare le credenziali dell'applicazione. Azure autorizzazioni per le risorse e le autorizzazioni della directory sono separate.

• Un'applicazione ospitata in un ambiente di calcolo Azure supportato, ad esempio App Service, Container Apps, un carico di lavoro AKS configurato in modo appropriato o una macchina virtuale. L'origine dell'asserzione basata su MI in questo modello dipende da tale configurazione di hosting di Azure.

• Autorizzazioni amministrative per concedere l'accesso alle risorse e all'area di lavoro dei clienti, configurare le impostazioni del servizio necessarie e concedere autorizzazioni API o consenso in cui il servizio di destinazione li richiede.

• interfaccia della riga di comando di Azure installato e connesso al tenant di directory corretto. Verificare il contesto della sottoscrizione prima di creare Azure risorse.

Impostazioni del tenant per sviluppatori

Esaminare le impostazioni pertinenti nell'interfaccia di amministrazione del servizio nelle impostazioni del tenant e nelle impostazioni per sviluppatori. Limitare l'accesso dell'entità servizio a un gruppo di sicurezza consentito contenente le entità servizio del cliente. Per le etichette esatte e il comportamento corrente, vedere Impostazioni del tenant per sviluppatori.

Per ogni impostazione con ambito gruppo richiesta dalla soluzione, aggiungere tutte le entità servizio del cliente sostitutive a un gruppo di sicurezza consentito prima di eseguire il test o il cutover. L'accesso concesso al service principal padre originale non autorizza automaticamente i service principal di sostituzione. L'impostazione di accesso all'API pubblica si applica sia alle API REST esistenti con riconoscimento del profilo sia alle API REST Fabric. La migrazione della sola identità non rimuove questo prerequisito.

L'impostazione public-API seguente usa un'etichetta indipendente dal prodotto; L'interfaccia di amministrazione potrebbe includere il nome del servizio.

Impostazione	Predefinito pubblicato	Obbligatorio quando
Le entità di servizio possono chiamare API pubbliche	Abilitato per i nuovi clienti.	Le entità servizio chiamano le API REST con riconoscimento del profilo esistenti o le API REST Fabric. Includi ogni principale sostitutivo nel gruppo di sicurezza consentito quando l'impostazione è limitata al gruppo.
Le entità servizio possono creare aree di lavoro, connessioni e pipeline di distribuzione	Disabilitato per i nuovi clienti.	L'applicazione effettua il provisioning di queste risorse.
Incorpora il contenuto nelle app	Abilitato nelle configurazioni esistenti; verificare il tenant.	L'applicazione esistente incorpora il contenuto tramite le API REST applicabili.
Consenti ai principali del servizio di creare e usare i profili	Non presupporre un valore predefinito.	Solo finché i clienti utilizzano ancora la route del profilo; non necessario per i clienti migrati.

Verificare i valori effettivi anziché presupporre le impostazioni predefinite. I tenant nuovi ed esistenti possono differire e gli amministratori possono modificare le impostazioni. Mantenere l'impostazione del profilo fino a quando non viene eseguita la migrazione di tutti i clienti dipendenti e i job. Non abilitare le impostazioni di incorporamento per un carico di lavoro non di incorporamento.

Passaggio 1: Creare e assegnare l'identità gestita assegnata dall'utente

Questa identità gestita rappresenta l'applicazione ISV, non un singolo cliente. Usare un gruppo di risorse esistente:

az identity create \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --location "<azure-region>"

Registrare l'ID client, l'ID dell'entità (oggetto), l'ID tenant della directory e l'ID della risorsa Azure. Assegnalo alla risorsa di calcolo. Per un'applicazione App Service esistente:

az webapp identity assign \
  --resource-group "<resource-group>" \
  --name "<web-app-name>" \
  --identities "<managed-identity-resource-id>"

Usare la procedura di assegnazione di identità corrispondente per altri servizi di calcolo. Selezionare in modo esplicito questa identità assegnata dall'utente nel runtime. Poiché l'identità è indipendente dalla risorsa host, la nuova distribuzione di un host non deve sostituire ogni relazione di trust con il cliente.

Passaggio 2: Creare un service principal per ogni cliente

Per ogni cliente, utente o ambito del gruppo rappresentato dai profili esistenti, creare una registrazione dell'applicazione e la relativa entità servizio/service principal. Questo esempio crea un'applicazione a tenant singolo nella directory dell'ISV:

APP_CLIENT_ID=$(az ad app create \
  --display-name "customer-a-application" \
  --sign-in-audience AzureADMyOrg \
  --query appId --output tsv)

az ad sp create --id "$APP_CLIENT_ID"

APP_OBJECT_ID=$(az ad app show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

SP_OBJECT_ID=$(az ad sp show \
  --id "$APP_CLIENT_ID" --query id --output tsv)

Identificatore	Utilizza
ID client dell’applicazione	Identificare l'applicazione del cliente quando si richiede un token di accesso.
ID oggetto applicazione	Configurare le credenziali federate nella registrazione dell'applicazione.
ID oggetto dell'entità servizio	Concedere ruoli dell'area di lavoro o delle risorse quando l'API richiede l'ID oggetto dell'entità servizio.

Note

Credenziali del percorso consigliato: Non creare un segreto client o un certificato per questa route di autenticazione. Il trust federativo dell'applicazione cliente fornisce il meccanismo di autenticazione.

Passaggio 3: Configurare le credenziali di identità federate

Recuperare l'ID principale dell'identità gestita e il relativo ID tenant della directory. Usare il tenant dell'identità anziché presupporre che una sottoscrizione corrente diversa abbia lo stesso tenant:

MI_PRINCIPAL_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query principalId --output tsv)

DIRECTORY_TENANT_ID=$(az identity show \
  --name "mi-customer-app" \
  --resource-group "<resource-group>" \
  --query tenantId --output tsv)

Aggiungere una credenziale di identità federata a ogni registrazione di ogni applicazione cliente. Il comando global-cloud seguente usa l'ID oggetto applicazione del passaggio 2 e i valori MI appena recuperati:

az ad app federated-credential create \
  --id "$APP_OBJECT_ID" \
  --parameters "{
    \"name\": \"trust-application-mi\",
    \"issuer\": \"https://login.microsoftonline.com/$DIRECTORY_TENANT_ID/v2.0\",
    \"subject\": \"$MI_PRINCIPAL_ID\",
    \"audiences\": [\"api://AzureADTokenExchange\"],
    \"description\": \"Trust the ISV application managed identity\"
  }"

In alternativa, salvare lo stesso JSON con valori sostituiti in un file locale credential.json e passare --parameters credential.json. Ripetere la fiducia per ogni applicazione cliente. Consentire la propagazione della configurazione prima di convalidare lo scambio di token.

Passaggio 4: Concedere a ogni service principal l'accesso all'area di lavoro

Aggiungere l'entità servizio del servizio clienti come Membro o Amministratore solo alle aree di lavoro designate in cui è necessario tale ruolo. Preferisci un ruolo supportato inferiore se soddisfa i requisiti dell'operazione. Questo grant è ciò che in realtà definisce l'ambito dell'accesso alle risorse del cliente.

Usare l'interfaccia di amministrazione dell'area di lavoro o l'operazione REST di assegnazione di ruolo dell'area di lavoro. L'esempio seguente usa l'API configurabile e gli identificatori di risorsa. Richiede un'identità di provisioning autorizzata; la MI di runtime stessa non dispone delle autorizzazioni per le risorse del cliente per lo scambio di token.

PROFILE_API_BASE="<existing-profile-aware-api-base-url>"
PROFILE_RESOURCE="<existing-api-resource-identifier>"
WORKSPACE_ID="<customer-workspace-id>"

TOKEN=$(az account get-access-token \
  --resource "$PROFILE_RESOURCE" \
  --query accessToken --output tsv)

curl --fail-with-body --request POST \
  "$PROFILE_API_BASE/v1.0/myorg/groups/$WORKSPACE_ID/users" \
  --header "Authorization: Bearer $TOKEN" \
  --header "Content-Type: application/json" \
  --data "{
    \"identifier\": \"$SP_OBJECT_ID\",
    \"groupUserAccessRight\": \"Member\",
    \"principalType\": \"App\"
  }"

Usare l'endpoint e la struttura della richiesta documentati per il servizio che gestisce l'area di lavoro esistente. L'operazione visualizzata si applica all'API workspace basata sul profilo; altre API possono usare schemi di assegnazione di ruolo diversi. Non sostituire un ID client quando l'operazione richiede un ID oggetto dell'entità servizio. Evitare di registrare token bearer e consentire la propagazione delle autorizzazioni.

Passaggio 5: Autenticare e chiamare le API in fase di esecuzione

1. Risolvere l'ID client dell'applicazione del cliente autenticato e le risorse consentite dalla configurazione lato server attendibile.

2. Acquisire un token di asserzione usando l'identità gestita assegnata dall'utente selezionata e l'ambito api://AzureADTokenExchange/.default nel cloud globale.

3. Usare il token MI come asserzione client per l'applicazione del cliente. Richiedere un token di accesso con l'ambito dell'applicazione dell'API della risorsa, non l'audience dell'asserzione.

4. Chiamare l'API di destinazione usando il token di accesso dell'applicazione del cliente e senza la configurazione di selezione del profilo. Gestire le aree di lavoro, richiedere i token specifici dell'applicazione necessari ed eseguire altre operazioni censite tramite l'identità del cliente.

Per .NET, usare Azure Identity ClientAssertionCredential con il token dell'identità gestita come callback dell'asserzione. Il flusso in sei passaggi e gli esempi di configurazione ufficiali mostrano lo scambio senza richiedere un esempio di codice dell'applicazione specifico per l'incorporamento.

Automatizzare l'onboarding e l'offboarding

Raggruppare le quattro operazioni di onboarding nella pipeline di provisioning: creare la registrazione dell'applicazione, crearne il service principal, configurarne l'attendibilità federata e assegnare il ruolo nell'area di lavoro. Creare contemporaneamente il percorso di offboarding corrispondente: rimuovere le concessioni di risorse, revocare l'attendibilità o le credenziali obsolete ed eliminare le identità dell'applicazione solo dopo aver controllato le dipendenze.

Implementazione alternativa: autenticare direttamente i service principal

Se non si vuole usare MI e la federazione, ignorare i passaggi 1 e 3. Completare il passaggio 2 per ogni cliente e configurare una credenziale dell'applicazione supportata anziché un trust federato.

Usare un certificato se supportato e seguire le linee guida per la configurazione delle credenziali dell'applicazione. Caricare il certificato pubblico, proteggere la chiave privata in un archivio credenziali appropriato e automatizzare il rinnovo. Se è necessario un segreto client, proteggerlo e rinnovarlo prima della scadenza.

Completare il passaggio 4 con le stesse autorizzazioni cliente con privilegi minimi. Nel passaggio 5 usare l'ID client del cliente e le relative credenziali per richiedere direttamente un token di accesso client credentials. Mantenere gli stessi controlli di instradamento cliente, separazione della cache dei token, convalida e controlli di pulizia della migrazione.

Sicurezza, limitazioni e considerazioni

Applicare i controlli seguenti al percorso di autenticazione selezionato e pianificarne i limiti operativi.

Raccomandazioni sulla sicurezza

• Usare un'identità gestita stabile assegnata dall'utente. In questo modo si evita di perdere le relazioni di trust dei clienti semplicemente perché viene sostituita una risorsa di calcolo. Non usare un'identità assegnata dal sistema come origine dell'asserzione per questo modello di attendibilità dell'app.

• Considera l'MI dell'applicazione come un'identità con privilegi elevati. Può eseguire l'autenticazione come qualsiasi applicazione cliente che si fida di esso. Limitare i diritti di distribuzione delle risorse di calcolo, l'assegnazione di identità gestite, i proprietari delle applicazioni e l'amministrazione delle credenziali. Partiziona le identità di runtime, se necessario, per ridurre l'ambito di compromissione.

• Non concedere all'istanza gestita autorizzazioni proprie per il servizio clienti. È un'origine di asserzione; le entità servizio del servizio clienti ricevono autorizzazioni per workspace e servizi downstream.

• Definire l'ambito delle impostazioni del tenant con un gruppo di sicurezza. Includere tutte le entità servizio pertinenti nel gruppo consentito anziché abilitare l'accesso alle entità servizio per l'intera organizzazione.

• Monitorare e generare avvisi per gli accessi di ogni entità di servizio. Correlare con i log dell'applicazione e delle risorse. La raccolta di log senza indagini e avvisi specifici per il cliente non offre il vantaggio operativo.

• Automatizzare l'onboarding e l'offboarding insieme. La rimozione dei ruoli dell'area di lavoro, il ritiro di credenziali o trust e l'eliminazione di entità servizio obsolete devono essere controllati e ripetibili quanto il loro provisioning.

Mantenere i mapping dei clienti sul lato server, convalidare l'appartenenza prima di selezionare un'identità e rifiutare ID di identità o risorse arbitrari forniti dal client. Il riutilizzo del token significa che un record di accesso non è un record di ogni chiamata API. Non registrare segreti, asserzioni, token di accesso o chiavi private del certificato.

Limitazioni e requisiti operativi

Consideration	Cosa pianificare
Limite superiore della scala rispetto ai profili	I profili consentono 100.000 per entità servizio principale padre, con un massimo di 1.000 aree di lavoro per profilo. Le registrazioni di applicazioni dedicate e le entità servizio utilizzano oggetti directory. Controllare le quote di directory, i limiti dell'area di lavoro del service principal e la velocità effettiva di provisioning prima del commit.
Limite di credenziali federate	Una registrazione dell'applicazione supporta al massimo 20 credenziali di identità federate. In genere questa architettura richiede una per ogni identità gestita di runtime attendibile per ogni applicazione cliente, non una per cliente in un'applicazione condivisa.
Requisito dello stesso tenant	L'identità gestita e ogni registrazione dell'applicazione considerata attendibile deve appartenere allo stesso tenant Microsoft Entra. L'accesso alle risorse in un altro tenant richiede inoltre una configurazione dell'applicazione supportata, il consenso e autorizzazioni per le risorse.
Nessun scambio di token tra cloud	Non scambiare token tra diversi cloud Azure, ad esempio il cloud globale e US Government. Usare l'audience corretta e gli endpoint di autorità corretti all'interno del cloud di destinazione.
requisito di calcolo di Azure	Il flusso di asserzione supportato da identità gestita richiede il meccanismo di identità gestita di un ambiente di hosting Azure supportato. Se l'app viene eseguita altrove o non si vuole usare questo schema, usare l'alternativa di autenticazione diretta o un'altra progettazione federata supportata.
Accesso condizionale	ID dei carichi di lavoro di Microsoft Entra Premium è necessario per creare o modificare i criteri di Accesso condizionale di Workload ID. Le policy coprono le entità servizio a tenant singolo idonee di proprietà dell'organizzazione e devono essere destinate direttamente a tali entità servizio. Non coprono le identità gestite né si applicano semplicemente tramite l'appartenenza ai gruppi.
Impostazioni del tenant per sviluppatori	Ogni principale di servizio cliente che usa un'impostazione con ambito gruppo deve trovarsi nel gruppo di sicurezza consentito. Esaminare le quattro impostazioni nei prerequisiti di implementazione; non presupporre le impostazioni predefinite.
Automation	La gestione manuale di centinaia o migliaia di identità dei clienti è poco pratica. Automatizzazione del provisioning, modifiche alle autorizzazioni, monitoraggio, rotazione o aggiornamenti delle relazioni di trust e offboarding. Gestire il throttling con tentativi limitati e backoff.
Le esperienze solo delegate non rientrano nell'ambito	La sostituzione dei profili non abilita l'autenticazione per sole app quando un carico di lavoro richiede token utente delegati. Nell'anteprima di incorporamento del dashboard Real-Time sono supportati solo quel tipo di elemento e l'autenticazione utente delegata; i token di dati solo app e app-owns-data non sono supportati. L'incorporamento di report esistente usa il meccanismo specifico del servizio applicabile.

Consultare limiti del servizio Microsoft Entra e il supporto dell'identità API del servizio di destinazione prima di finalizzare capacità e autorizzazioni.

Per i limiti di attendibilità correnti e il comportamento di propagazione, vedere Considerazioni sulle credenziali delle identità federate.

Per l'idoneità ai criteri e i requisiti di licenza correnti, vedere Accesso condizionale per le identità del carico di lavoro.

Usare il pubblico token-exchange global-cloud api://AzureADTokenExchange, il pubblico del governo degli Stati Uniti api://AzureADTokenExchangeUSGov, o il pubblico cinese api://AzureADTokenExchangeChina, in base alle esigenze. Abbina l'endpoint di autorità al cloud. Gli esempi in questo articolo usano il cloud globale.

Usare le librerie di identità supportate per la memorizzazione nella cache e l'aggiornamento dei token. Consentire la propagazione dell'attendibilità e dell'autorizzazione, ritentare in caso di errori transitori con backoff delimitato e analizzare le mancate corrispondenze persistenti dell'autorità emittente, del soggetto o del destinatario previsto. Per l'autenticazione diretta, ruotare certificati e credenziali segrete con un periodo di sovrapposizione e monitorare la scadenza.

Non presupporre che l'eliminazione di un profilo, la rimozione di credenziali o la modifica di un trust invalidi immediatamente i token rilasciati in precedenza. Tenere conto della durata dei token e del comportamento di autorizzazione e revoca di ogni servizio di risorse durante la pianificazione del cutover e dell'offboarding.

Contenuti correlati

Usare questi riferimenti per le autorizzazioni specifiche dell'API, le restrizioni di identità correnti e la configurazione del carico di lavoro esistente.

Profili, entità servizio e carichi di lavoro esistenti

• Profili entità di servizio per applicazioni multi-tenant
• Configurare un'applicazione di contenuto esistente per usare un'entità servizio
• Impostazioni del tenant per sviluppatori
• Panoramica dell'incorporamento di analytics esistente
• Anteprima dell'integrazione del dashboard Real-Time per utente delegato

Federazione dell'identità del carico di lavoro e identità gestita

• Panoramica della federazione delle identità del carico di lavoro
• Considerazioni importanti e restrizioni per le credenziali di identità federate
• Configurare un'applicazione per considerare attendibile un'identità gestita
• Identità gestite per le risorse di Azure
• Esempi di configurazione della federazione

SDK, API e limiti di servizio

• Azure Identity ClientAssertionCredential per .NET
• Riferimento per la generazione di token specifica dell'applicazione per carichi di lavoro di embedding esistenti
• Microsoft Entra limiti e restrizioni del servizio
• Identità dell'applicazione supportate per le API REST Fabric
• Identità di connessione e sicurezza Direct Lake
• Accesso condizionale per le identità di risorse di lavoro
• Operazione di assegnazione del ruolo del workspace
• API di gestione dei profili