Considerazioni sul nome di dominio nelle soluzioni multi-tenant

2025-07-04

In molte applicazioni Web multi-tenant è possibile usare un nome di dominio per fornire le funzionalità seguenti:

Per distinguere un tenant da un altro
Per facilitare il routing delle richieste all'infrastruttura corretta
Per offrire ai clienti un'esperienza personalizzata

È possibile usare sottodomini o nomi di dominio personalizzati. Questo articolo fornisce indicazioni per i decision maker tecnici sugli approcci ai nomi di dominio e sui compromessi.

Sottodomini

È possibile assegnare a ogni tenant un sottodominio univoco con un nome di dominio condiviso comune usando un formato come tenant.provider.com.

Si consideri un esempio di soluzione multi-tenant creata da Contoso. I clienti acquistano il prodotto contoso per gestire la generazione della fattura. Contoso assegna a tutti i tenant il proprio sottodominio sotto il nome di dominio contoso.com. Se Contoso usa distribuzioni regionali, potrebbero assegnare sottodomini sotto i domini us.contoso.com e eu.contoso.com.

Questo articolo fa riferimento a questi domini regionali come domini stem. Ogni cliente ottiene il proprio sottodominio nel dominio stem. Ad esempio, Tailwind Toys potrebbe ricevere tailwind.contoso.com. Se si usa un modello di distribuzione a livello di area, Adventure Works potrebbe ricevere adventureworks.us.contoso.com.

Annotazioni

Molti servizi di Azure usano questo approccio. Ad esempio, quando si crea un account di archiviazione di Azure, Azure assegna un set di sottodomini, ad esempio <your account name>.blob.core.windows.net.

Gestire lo spazio dei nomi del dominio

Quando si creano sottodomini con il proprio nome di dominio, è possibile avere più clienti con nomi simili. Condividono un singolo dominio stem, quindi il primo cliente a richiedere un dominio specifico riceve il nome preferito. I clienti successivi devono usare nomi di sottodominio alternativi perché i nomi di dominio completi devono rimanere univoci a livello globale.

DNS con caratteri jolly

Usare le voci DNS (Domain Name System) con caratteri jolly per semplificare la gestione dei sottodomini. Al posto di creare voci DNS per tailwind.contoso.com o adventureworks.contoso.com, puoi creare una voce con caratteri jolly per *.contoso.com. Indirizzare tutti i sottodomini a un singolo indirizzo IP usando un record A o un nome canonico usando un record CNAME. Se si usano domini stem regionali, potrebbero essere necessarie più voci con caratteri jolly, ad esempio *.us.contoso.com e *.eu.contoso.com.

Annotazioni

Assicurati che i servizi di livello web supportino il DNS wildcard se prevedi di usare questa funzionalità. Molti servizi di Azure, tra cui Frontdoor di Azure e Servizio app di Azure, supportano voci DNS con caratteri jolly.

Sottodomini basati su domini radice in più parti

Molte soluzioni multi-tenant si estendono su più distribuzioni fisiche. Questo approccio è comune quando è necessario rispettare i requisiti di residenza dei dati o migliorare le prestazioni distribuendo le risorse geograficamente più vicine agli utenti.

Anche all'interno di una singola area, è possibile distribuire i tenant tra distribuzioni indipendenti per supportare la strategia di scalabilità. Se si prevede di utilizzare sottodomini per ciascun cliente, considerare una struttura di sottodominio suddivisa in più parti.

Ad esempio, Contoso pubblica un'applicazione multi-tenant per i suoi quattro clienti. Adventure Works e Tailwind Traders si trovano negli Stati Uniti e i relativi dati vengono archiviati in un'istanza condivisa degli Stati Uniti della piattaforma Contoso. Fabrikam e Worldwide Importers si trovano in Europa e i relativi dati vengono archiviati in un'istanza europea.

Il diagramma seguente mostra un esempio di Contoso che utilizza il dominio a singolo livello contoso.com per tutti i clienti.

Contoso può usare le voci DNS seguenti per supportare questa configurazione.

Sottodominio	Da CNAME a
`adventureworks.contoso.com`	`us.contoso.com`
`tailwind.contoso.com`	`us.contoso.com`
`fabrikam.contoso.com`	`eu.contoso.com`
`worldwideimporters.contoso.com`	`eu.contoso.com`

Ogni nuovo cliente di cui è stato eseguito l'onboarding richiede un nuovo sottodominio. Il numero di sottodomini aumenta con ogni cliente.

In alternativa, Contoso potrebbe usare domini radice specifici all'implementazione o alla regione.

Utilizzando il DNS con wildcard, le voci DNS per questa distribuzione potrebbero assomigliare ai seguenti esempi.

Sottodominio	Da CNAME a
`*.us.contoso.com`	`us.contoso.com`
`*.eu.contoso.com`	`eu.contoso.com`

Contoso non deve creare record di sottodominio per ogni cliente. Al contrario, un singolo record DNS wildcard per ciascuna implementazione geografica consente ai nuovi clienti di quella sotto struttura di ereditare automaticamente il record CNAME.

Ogni approccio presenta vantaggi e svantaggi. Quando si usa un dominio stem singolo, è necessario creare un record DNS per ogni tenant di cui si esegue l'onboarding, aumentando il sovraccarico operativo. Tuttavia, hai una maggiore flessibilità per spostare i clienti tra le distribuzioni. È possibile modificare il record CNAME per indirizzare il traffico a un'altra distribuzione. Questa modifica non influisce su altri tenant.

I domini con più stem hanno un sovraccarico di gestione inferiore. È possibile riutilizzare i nomi dei clienti in più domini stem regionali perché ogni dominio stem rappresenta in modo efficace il proprio spazio dei nomi.

Nomi di dominio personalizzati

È possibile consentire ai clienti di usare i propri nomi di dominio. Alcuni clienti vedono questa funzionalità come un aspetto importante della loro personalizzazione. I clienti potrebbero anche richiedere nomi di dominio personalizzati per soddisfare i requisiti di sicurezza, soprattutto se devono fornire i propri certificati TLS (Transport Layer Security). Questo approccio potrebbe sembrare semplice, ma alcune complessità nascoste richiedono considerazioni ponderate.

Risoluzione dei nomi

In definitiva, ogni nome di dominio deve essere risolto in un indirizzo IP. Come illustrato in precedenza, il processo di risoluzione dei nomi dipende dal fatto che si distribuisca una singola istanza o più istanze della soluzione.

Per rivedere l'esempio, uno dei clienti di Contoso, Fabrikam, richiede di usare invoices.fabrikam.com come nome di dominio personalizzato per accedere al servizio di Contoso. Contoso ha più distribuzioni della piattaforma multi-tenant, quindi decide di usare sottodomini e record CNAME per soddisfare i requisiti di routing. Contoso e Fabrikam configurano i record DNS seguenti.

Nome	Tipo di record	Valore	Configurato da
`invoices.fabrikam.com`	CNAME	`fabrikam.eu.contoso.com`	Fabrikam
`*.eu.contoso.com`	CNAME	`eu.contoso.com`	Contoso
`eu.contoso.com`	Un	(indirizzo IP di Contoso)	Contoso

Dal punto di vista della risoluzione dei nomi, questa catena di record risolve accuratamente le richieste per invoices.fabrikam.com l'indirizzo IP della distribuzione europea di Contoso.

Risoluzione dell'intestazione host

La risoluzione dei nomi fa solo parte del problema. Tutti i componenti Web all'interno della distribuzione europea di Contoso devono sapere come gestire le richieste che includono il nome di dominio di Fabrikam nell'intestazione Host della richiesta. A seconda delle tecnologie Web specifiche usate da Contoso, il nome di dominio di ogni tenant potrebbe richiedere un'ulteriore configurazione, con un sovraccarico operativo aggiuntivo per l'onboarding del tenant.

È anche possibile riscrivere le intestazioni host in modo che, indipendentemente dall'intestazione della Host richiesta in ingresso, il server Web visualizzi un valore di intestazione coerente. Ad esempio, Azure Front Door consente di riscrivere le intestazioni Host in modo che, indipendentemente dalla richiesta, il server di applicazione riceva una singola intestazione Host. Frontdoor di Azure propaga l'intestazione host originale nell'intestazione X-Forwarded-Host in modo che l'applicazione possa esaminarla e quindi cercare il tenant. Tuttavia, la riscrittura di un'intestazione Host può causare altri problemi. Per altre informazioni, vedere Conservazione dei nomi host.

Convalida del dominio

Prima di eseguirne l'onboarding, è necessario convalidare la proprietà dei domini personalizzati. In caso contrario, un cliente potrebbe appropriarsi accidentalmente o dannosamente di un nome di dominio, a volte definito parcheggiare un dominio.

Si consideri il processo di onboarding di Contoso per Adventure Works, che ha richiesto di usare invoices.adventureworks.com come nome di dominio personalizzato. Sfortunatamente, qualcuno ha fatto un errore di ortografia quando ha cercato di caricare il nome di dominio personalizzato, e hanno perso la s. Quindi lo configurano come invoices.adventurework.com. Di conseguenza, il traffico non riesce a fluire correttamente per Adventure Works. Tuttavia, quando un'altra società denominata Adventure Work tenta di aggiungere il dominio personalizzato alla piattaforma contoso, viene indicato che il nome di dominio è già in uso.

Per evitare questo problema, soprattutto all'interno di un processo self-service o automatizzato, è possibile richiedere un passaggio di verifica del dominio. Potrebbe essere necessario che il cliente crei un record CNAME prima che il dominio possa essere aggiunto. In alternativa, è possibile generare una stringa casuale e chiedere al cliente di aggiungere un record TXT DNS che include il valore stringa. Il nome di dominio non può essere aggiunto finché la verifica non è completata con successo.

Attacchi di acquisizione del dns e del sottodominio dangling

Quando si lavora con nomi di dominio personalizzati, si espone la piattaforma a una classe di attacchi denominati attacco DNS o acquisizione del sottodominio. Questi attacchi si verificano quando i clienti annullano l'associazione del nome di dominio personalizzato dal servizio, ma non eliminano il record dal server DNS. Questa voce DNS punta quindi a una risorsa inesistente ed è vulnerabile a un'acquisizione.

Valutare il modo in cui la relazione di Fabrikam con Contoso potrebbe cambiare se si verifica lo scenario seguente:

Fabrikam decide di non lavorare più con Contoso, quindi termina la relazione di business.
Contoso rimuove il tenant di Fabrikam e disabilita fabrikam.contoso.com.
Fabrikam dimentica di eliminare il record CNAME per invoices.fabrikam.com.
Un attore malintenzionato crea un nuovo account Contoso e assegna il nome fabrikam.
L'utente malintenzionato esegue l'onboarding del nome invoices.fabrikam.com di dominio personalizzato nel nuovo tenant.
Contoso controlla il server DNS di Fabrikam durante la convalida del dominio basata su CNAME. Si noterà che il server DNS restituisce un record CNAME per invoices.fabrikam.com, che punta a fabrikam.contoso.com. Contoso considera corretta la convalida del dominio personalizzato.
Se i dipendenti di Fabrikam tentano di accedere al sito, le richieste sembrano funzionare. Se l'utente malintenzionato configura il tenant contoso con la personalizzazione di Fabrikam, i dipendenti potrebbero essere ingannati nell'accedere al sito e fornire dati sensibili, a cui l'utente malintenzionato può accedere.

Usare le strategie seguenti per proteggersi da attacchi DNS incerti:

Richiedere l'eliminazione del record CNAME prima che il nome di dominio possa essere rimosso dall'account del tenant.
Impedire il riutilizzo degli identificatori dei clienti. E richiedere a ogni tenant di creare un record TXT con un nome corrispondente al nome di dominio e a un valore generato in modo casuale che cambia per ogni tentativo di onboarding.

Certificati TLS

TLS è un componente essenziale delle applicazioni moderne. Offre attendibilità e sicurezza per le applicazioni Web. Considerare attentamente la proprietà e la gestione dei certificati TLS per le applicazioni multi-tenant.

In genere, il proprietario di un nome di dominio rilascia e rinnova i certificati. Ad esempio, Contoso rilascia e rinnova certificati TLS per us.contoso.com e un certificato wildcard per *.contoso.com. Analogamente, Fabrikam gestisce i record per il fabrikam.com dominio, incluso invoices.fabrikam.com.

Un proprietario del dominio può usare il tipo di record DNS CAA (Certificate Authority Authorization). I record CAA assicurano che solo autorità specifiche possano creare certificati per il dominio.

Se si consente ai clienti di portare i propri domini, valutare se si prevede di rilasciare certificati per loro conto o richiedere loro di usare i propri domini. Ogni opzione presenta vantaggi e svantaggi:

Se si rilascia un certificato per un cliente, è possibile gestire il rinnovo del certificato, in modo che il cliente non debba gestirlo. Tuttavia, se i clienti hanno record CAA sui nomi di dominio, potrebbe essere necessario autorizzare l'utente a rilasciare certificati per loro conto.
Se i clienti rilasciano e forniscono i propri certificati, si ricevono e gestiscono in modo sicuro le chiavi private. Per evitare un'interruzione del servizio, potrebbe essere necessario ricordare ai clienti di rinnovare il certificato prima della scadenza.

Diversi servizi di Azure supportano la gestione automatica dei certificati per i domini personalizzati. Ad esempio, Frontdoor di Azure e servizio app forniscono certificati per i domini personalizzati e gestiscono automaticamente il processo di rinnovo. Questa funzionalità elimina il carico di lavoro per la gestione dei certificati dal team operativo. Tuttavia, è comunque necessario prendere in considerazione la proprietà e l'autorità. Verificare che i record CAA siano presenti e configurati correttamente. Assicurarsi anche che i domini dei clienti consentano i certificati gestiti dalla piattaforma.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

John Downs | Principal Software Engineer

Altri collaboratori:

Daniel Scott-Raynsford | Partner Technology Strategist
Arsen Vladimirskiy | Ingegnere principale per i clienti, FastTrack per Azure

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Molti servizi usano Frontdoor di Azure per gestire i nomi di dominio. Per altre informazioni, vedere Usare Frontdoor di Azure in una soluzione multi-tenant.

Tornare alla panoramica delle considerazioni sull'architettura. In alternativa, vedere Azure Well-Architected Framework.