Condividi tramite

Implementare la comunicazione tra tenant usando applicazioni multi-tenant

  • Articolo

Questa guida fornisce una soluzione per ottenere comunicazioni bidirezionali e sicure tra i servizi ospitati nelle sottoscrizioni di Azure gestite da tenant Microsoft Entra diversi.

La protezione delle comunicazioni multi-tenant in Azure può essere complessa a causa di limitazioni intrinseche a molti servizi. È possibile eliminare la necessità di gestire le credenziali direttamente usando le identità gestite di Azure per ottenere i token dall'ID Microsoft Entra. Tuttavia, le identità gestite di Azure non funzionano oltre i limiti del tenant e l'alternativa tipica consiste nell'usare segreti condivisi, ad esempio gli URL della firma di accesso condiviso. Tenere presente che se si usano segreti condivisi, è necessario distribuire e ruotare in modo sicuro i segreti attraverso i limiti del tenant di Microsoft Entra.

Un'opzione che evita questo sovraccarico consiste nel creare un'applicazione multi-tenant per rappresentare l'identità del carico di lavoro. Tramite un processo di consenso, è possibile rendere nota questa identità del carico di lavoro a un tenant esterno e consentire l'autenticazione dei servizi nel tenant esterno.

Questo articolo presenta un'implementazione di esempio di questo modello che usa il codice di esempio.

Questo modello può essere riutilizzato per qualsiasi scenario multi-tenant con vari servizi che devono comunicare tra i limiti del tenant di Microsoft Entra.

Architettura

Diagramma dell'architettura di comunicazione tra tenant.

Scaricare un file PowerPoint di questa architettura.

Workflow

Il flusso di lavoro seguente corrisponde al diagramma precedente:

  1. Un amministratore sul lato provider crea una registrazione dell'applicazione multi-tenant e ne configura un segreto client.

  2. Un amministratore sul lato cliente effettua il provisioning di un'entità servizio nel tenant. Questa entità servizio si basa sull'applicazione multi-tenant creata dal provider. Puoi completare questo passaggio in più modi. Nell'esempio è stato scelto di creare un URL da fornire all'amministratore tenant del cliente, ma è possibile usare l'API Microsoft Graph.

  3. Il cliente applica ruoli di controllo degli accessi in base al ruolo a questa nuova entità servizio in modo che sia autorizzato ad accedere bus di servizio di Azure.

  4. L'app per le funzioni del provider usa l'ID client e il segreto client della registrazione dell'applicazione per inviare un messaggio autenticato alla coda di bus di servizio del cliente.

  5. L'app per le funzioni del cliente usa un'identità gestita per leggere il messaggio del provider dalla coda tramite un trigger di bus di servizio.

  6. Dopo aver ricevuto il messaggio, l'app per le funzioni del cliente esegue in genere alcune operazioni prima di inviare un messaggio di stato al provider. In questo caso, a scopo dimostrativo, l'app per le funzioni invia immediatamente un messaggio di stato al provider in una coda separata nella stessa bus di servizio.

  7. Questa app per le funzioni legge dalla coda di stato dal tenant del cliente tramite un timer che Funzioni di Azure trigger.

Dettagli dello scenario

Un provider ha più clienti. Il provider e ogni cliente hanno il proprio tenant microsoft Entra ID e le risorse di Azure. Il provider e ogni cliente hanno bisogno di un metodo di comunicazione bidirezionale sicuro in modo che possano scambiare messaggi tramite bus di servizio code. La soluzione deve avere una storia di identità accattivante che evita di introdurre credenziali o segreti non necessari.

Cosa sapere sulle applicazioni multi-tenant

  • Un oggetto applicazione è un'istanza univoca globale dell'applicazione.

  • Quando un'applicazione viene registrata in Microsoft Entra, un oggetto applicazione e un oggetto entità servizio vengono creati automaticamente nel tenant.

  • Un oggetto entità servizio viene creato in ogni tenant che usa l'applicazione e fa riferimento all'oggetto applicazione. Un oggetto applicazione ha una relazione uno-a-molti con l'oggetto entità servizio corrispondente.

  • L'oggetto applicazione è la rappresentazione globale dell'applicazione e viene usato in tutti i tenant. L'oggetto entità servizio è la rappresentazione locale usata in un tenant specifico.

  • È necessario creare un oggetto principale del servizio in ciascun tenant in cui viene utilizzata l'applicazione, in modo che possa stabilire un'identità per accedere alle risorse protette dal tenant. Un'applicazione a tenant singolo ha un solo oggetto entità servizio nel tenant principale. Questo oggetto entità servizio viene creato e consentito per l'uso durante la registrazione dell'applicazione. Un'applicazione multi-tenant presenta anche un'entità servizio creata in ogni tenant di cui è stato concesso l’uso da parte di un utente del tenant stesso.

  • Per accedere alle risorse protette da un tenant Microsoft Entra, un'entità di sicurezza deve rappresentare l'entità che richiede l'accesso.

  • Quando a un'applicazione viene concesso di accedere alle risorse in un tenant (al momento della registrazione o del consenso), viene creato un oggetto entità servizio. Questa architettura viene implementata con il flusso di consenso.

In che modo il provider ha inviato un messaggio al cliente?

Idealmente, il provider è in grado di assegnare un'identità gestita alla risorsa di calcolo di Azure responsabile dell'invio di messaggi alla coda di un cliente. Il tenant del cliente è configurato per considerare attendibili le identità gestite dal tenant del provider. Tuttavia, una vera federazione tra due tenant di Microsoft Entra, che consentirebbe essenzialmente la "condivisione" delle identità da un tenant a un altro, non è attualmente possibile. Il provider deve quindi eseguire l'autenticazione usando un'identità riconosciuta dal cliente. Il provider deve eseguire l'autenticazione al tenant Microsoft Entra del cliente come entità servizio che il cliente conosce.

È consigliabile che il provider registri un'applicazione multi-tenant nel proprio tenant e che ogni cliente esegua il provisioning di un'entità servizio associata nel tenant. Il provider può quindi eseguire l'autenticazione al tenant del cliente e alle API ospitate dal cliente usando questa entità servizio. Il provider non deve mai condividere un segreto client in questo approccio. La gestione delle credenziali è l'unica responsabilità del provider.

In che modo il cliente ha inviato un messaggio al provider?

È consigliabile che il cliente crei o ospiti una coda da cui il provider può leggere. Il cliente scrive un messaggio nella coda. Il provider esegue ripetutamente il polling di ogni coda dei clienti per i messaggi usando un oggetto entità servizio. Lo svantaggio di questo approccio è che introduce la latenza di polling quando il provider riceve un messaggio. Anche il codice deve essere eseguito più spesso nel provider perché deve riattivarsi ed eseguire la logica di polling invece di attendere che un evento venga attivato. Tuttavia, la gestione delle credenziali rimane l'unica responsabilità del provider, che rafforza la sicurezza.

Un'altra possibile soluzione consiste nel fare in modo che il provider crei o ospiti una coda per ognuno dei suoi clienti. Ogni cliente crea una propria applicazione multi-tenant e richiede che il provider lo esegua il provisioning nel tenant come oggetto entità servizio. Il cliente usa quindi questo oggetto entità servizio per inviare messaggi a una coda specifica del cliente sul lato provider. La gestione delle credenziali rimane l'unica responsabilità del cliente. Uno svantaggio di questo approccio è che il provider deve effettuare il provisioning delle entità servizio associate alle applicazioni dei clienti nel tenant. Questo processo è manuale e i provider probabilmente non vogliono che i passaggi manuali facciano parte del flusso per l'onboarding di un nuovo cliente.

Configurare il codice di esempio

I passaggi seguenti illustrano il processo di configurazione della comunicazione tra tenant tra un provider e un cliente.

Configurazione del provider

L'installazione del provider include i passaggi per generare ed effettuare il provisioning di un'entità servizio dell'applicazione multi-tenant e i passaggi per effettuare il provisioning del tenant del cliente.

  1. Creare un'app per le funzioni attivata da HTTP per inviare un messaggio da scrivere nella coda dei comandi bus di servizio del cliente all'interno del tenant del cliente.

  2. Creare un'app per le funzioni attivata dal tempo per controllare periodicamente una coda di stato all'interno del bus di servizio del cliente all'interno del tenant del cliente.

Creare un'applicazione multi-tenant all'interno del tenant del provider

Creare prima di tutto un'applicazione multi-tenant nel tenant del provider ed effettuare il provisioning di tale identità all'interno del tenant del cliente. In questo scenario, l'identità è un'entità servizio. L'architettura descritta in precedenza in questo articolo illustra come configurare e effettuare il provisioning di un'entità servizio dal tenant del provider nel tenant del cliente. L'architettura descrive anche come eseguire il provisioning con più tenant di Microsoft Entra.

  1. Scegliere l'opzione organizzazione multi-tenant.

  2. Aggiungere il sito Web seguente come URI di reindirizzamento: https://entra.microsoft.com. È possibile modificare questo URI in base alle esigenze aziendali.

  3. Registrati e prendi nota del valore dell'ID dell'applicazione (client).

Creare un nuovo segreto client

  1. Dopo aver creato l'applicazione multi-tenant, creare un segreto client per questa entità servizio.

  2. Salvare il segreto generato in un luogo sicuro. Il segreto e l'ID client sono le credenziali client necessarie per scambiare il codice, nel flusso del codice di autorizzazione e per un token ID nel passaggio successivo.

Funzioni di Azure, trigger HTTP

Usare la funzione HTTP per avviare la distribuzione dal tenant del provider inviando un messaggio nella coda di distribuzione bus di servizio del cliente. È stata scelta la funzione attivata da HTTP come metodo di recapito per avviare questo modello di verifica. L'entità servizio generata in precedenza funge da credenziale per accedere al tenant del cliente e scrivere in una coda specifica all'interno di bus di servizio. È anche necessario completare la configurazione del cliente per il corretto funzionamento di questo passaggio.

Trigger timer in Funzioni di Azure

Usare la funzione attivata dal timer per eseguire il polling della coda di stato della distribuzione dall'interno del tenant del cliente. La coda di stato della distribuzione viene eseguita ogni 10 secondi a scopo dimostrativo in questo modello di verifica. Questo approccio elimina la necessità che il cliente disponga di un'entità servizio per accedere al tenant del provider.

Configurazione del cliente

  1. Effettuare il provisioning dell'entità servizio modificando e usando l'URL fornito.

  2. Definire l'ambito dell'entità servizio del provider per usare i controlli controllo degli accessi in base al ruolo appropriati.

  3. Creare una funzione attivata bus di servizio per leggere un messaggio da una coda di messaggi bus di servizio e inserire un messaggio in un'altra coda. A scopo dimostrativo, questo flusso è ottimale per testare la funzionalità.

  4. Creare un'identità gestita assegnata dal sistema per la funzione attivata bus di servizio.

  5. Assegnare l'ambito dell'identità gestita assegnata dal sistema bus di servizio.

Effettuare il provisioning dell'entità servizio dal tenant del provider al tenant del cliente

  1. Visitare l'URL seguente dopo aver sostituito il parametro della client_id stringa di query con il proprio ID client: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    È anche possibile effettuare il provisioning dell'entità servizio in un altro tenant di Microsoft Entra con una chiamata dell'API Microsoft Graph amministratore, un comando di Azure PowerShell o un comando dell'interfaccia della riga di comando di Azure.

  2. Accedere con un account dal tenant del cliente.

  3. Nella schermata di consenso selezionare Accetta per effettuare il provisioning dell'applicazione del provider nel tenant del cliente. L'URL viene infine reindirizzato a microsoft.com, che ha comunque l'effetto desiderato di effettuare il provisioning dell'identità nel tenant del cliente.

  4. Verificare l'identità all'interno del tenant Microsoft Entra del cliente passando a Applicazioni aziendali per visualizzare l'entità servizio di cui è stato appena effettuato il provisioning.

Configurare il controllo degli accessi in base al ruolo per l'entità servizio di cui è stato effettuato il provisioning

Definire l'ambito dell'entità servizio del provider dalla configurazione dell'entità servizio del provider per avere ruoli "proprietario dati bus di servizio" nel bus di servizio. Questa entità servizio viene usata sia per la scrittura in una coda con una funzione attivata tramite HTTP che per la lettura da una coda da una funzione attivata dal timer. Assicurarsi di aggiungere il ruolo "proprietario dati bus di servizio di Azure" all'entità servizio.

Funzioni di Azure come trigger del bus di servizio

Seguire i passaggi dell'esercitazione sulle funzioni basate su identità per definire il trigger di funzione dalla coda bus di servizio e per informazioni su come configurare un'identità gestita. Queste indicazioni consentono di attivare l'app per le funzioni dalla coda bus di servizio quando viene aggiunto un messaggio alla coda. È anche possibile usare l'identità gestita quando si inserisce un messaggio in una coda diversa. A scopo dimostrativo, viene usata la stessa funzione per eseguire il push del messaggio.

Nello spazio dei nomi bus di servizio appena creato selezionare Controllo di accesso (IAM). È possibile visualizzare e configurare chi può accedere alla risorsa nel piano di controllo.

Concedere all'app per le funzioni l'accesso allo spazio dei nomi bus di servizio usando le identità gestite

  1. Assicurarsi di aggiungere il ruolo "ricevitore dati bus di servizio di Azure" all'identità gestita.

  2. Nel selettore di identità gestita scegliere App per le funzioni dalla categoria Identità gestita assegnata dal sistema. L'etichetta App per le funzioni potrebbe avere un numero tra parentesi accanto a esso. Tale numero indica il numero di app con identità assegnate dal sistema nella sottoscrizione.

Connettersi a bus di servizio nell'app per le funzioni

  1. Nel portale cercare l'app per le funzioni o accedervi nella pagina App per le funzioni .

  2. In Impostazioni applicazione selezionare + Nuovo per creare una nuova impostazione dell'applicazione nella tabella. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Gestione del ciclo di vita del segreto client dell'entità servizio

Se si introducono segreti nell'architettura tra tenant, è necessario gestire il ciclo di vita di tali segreti client generati. Vedere Procedure consigliate per la gestione dei segreti per informazioni su come archiviare, ruotare e monitorare i segreti client in modo sicuro.

Local Settings

Ogni sottodirectory contiene una versione stub dei local.settings.json file, che può essere modificata per eseguire le funzioni di Azure in locale. Per configurare le impostazioni in Azure, aggiornare le impostazioni dell'applicazione.

Il DefaultAzureCredential comando enumera più impostazioni prima di raggiungere le credenziali dell'interfaccia della riga di comando di Azure. Per evitare confusione, è consigliabile eseguire il az login -t <tenant ID> comando per selezionare le credenziali corrette quando si sviluppano funzioni locali.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Passaggi successivi