Considerazioni sull'uso dei nomi di dominio in una soluzione multi-tenant

In molte applicazioni Web multi-tenant, un nome di dominio può essere usato come modo per identificare un tenant, per facilitare il routing delle richieste all'infrastruttura corretta e per offrire un'esperienza branded ai clienti. Due approcci comuni sono l'uso di sottodomini e nomi di dominio personalizzati. In questa pagina vengono fornite indicazioni per i responsabili decisionali tecnici sugli approcci che è possibile prendere in considerazione e sui loro compromessi.

Sottodomini

Ogni tenant potrebbe ottenere 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 compilata da Contoso. I clienti acquistano il prodotto contoso per gestire la generazione della fattura. Tutti i tenant di Contoso potrebbero essere assegnati al proprio sottodominio, sotto il contoso.com nome di dominio. In alternativa, se Contoso usa distribuzioni a livello di area, potrebbero assegnare sottodomini sotto i us.contoso.com domini e eu.contoso.com . In questo articolo si fa riferimento a questi domini stem. Ogni cliente ottiene il proprio sottodominio sotto il dominio stem. Ad esempio, Tailwind Toys potrebbe essere assegnato tailwind.contoso.come Adventure Works potrebbe essere assegnato adventureworks.contoso.com.

Gestire lo spazio dei nomi del dominio

Quando si creano sottodomini sotto il proprio nome di dominio, è necessario tenere presente che è possibile avere più clienti con nomi simili. Poiché condividono un singolo dominio stem, il primo cliente a ottenere un determinato dominio otterrà il proprio nome preferito. I clienti successivi devono quindi usare nomi di sottodominio alternativi, perché i nomi di dominio completi devono essere univoci a livello globale.

DNS con caratteri jolly

È consigliabile usare le voci DNS con caratteri jolly per semplificare la gestione dei sottodomini. Anziché creare voci DNS per tailwind.contoso.com, adventureworks.contoso.come così via, è possibile creare una voce con caratteri jolly per *.contoso.com e indirizzare tutti i sottodomini a un singolo indirizzo IP (record A) o al nome canonico (record CNAME).

Sottodomini con domini stem multipart

Molte soluzioni multi-tenant vengono distribuite in più distribuzioni fisiche. Si tratta di un approccio comune quando è necessario rispettare i requisiti di residenza dei dati o quando si desidera offrire prestazioni migliori distribuendo le risorse geograficamente più vicine agli utenti.

Anche all'interno di una singola area, potrebbe essere necessario distribuire i tenant tra distribuzioni indipendenti, per supportare la strategia di scalabilità. Se si prevede di usare sottodomini per ogni tenant, è possibile considerare una struttura di sottodominio multipart.

Ecco un esempio: Contoso pubblica un'applicazione multi-tenant per i suoi quattro clienti. Adventure Works e Tailwind Traders si trovano nella Stati Uniti e i dati vengono archiviati in un'istanza statunitense condivisa della piattaforma Contoso. Fabrikam e Worldwide Importers sono in Europa e i dati vengono archiviati in un'istanza europea.

Se Contoso ha scelto di usare un singolo dominio stem, contoso.com, per tutti i clienti, ecco come segue:

Le voci DNS (necessarie per supportare questa configurazione) potrebbero essere simili al seguente:

Ogni nuovo cliente che viene eseguito l'onboarding richiede un nuovo sottodominio e il numero di sottodomini aumenta con ogni cliente.

In alternativa, Contoso potrebbe usare domini stem specifici dell'area o della distribuzione, come illustrato di seguito:

Quindi, usando DNS con caratteri jolly, le voci DNS per questa distribuzione potrebbero essere simili al seguente:

Contoso non deve creare record di sottodominio per ogni cliente. Hanno invece un singolo record DNS con caratteri jolly per la distribuzione di ogni area geografica e tutti i nuovi clienti aggiunti sotto che ereditano automaticamente il record CNAME.

Esistono vantaggi e svantaggi per ogni approccio. Quando si usa un singolo dominio stem, ogni tenant eseguito l'onboarding richiede la creazione di un nuovo record DNS, che introduce un sovraccarico operativo maggiore. Tuttavia, è possibile spostare i tenant tra le distribuzioni, perché è possibile modificare il record CNAME per indirizzare il traffico a un'altra distribuzione. Questa modifica non influisce su altri tenant. Quando si usano più domini stem, è presente un sovraccarico di gestione inferiore. È anche 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 portare i propri nomi di dominio. Alcuni clienti vedono questo come un aspetto importante della loro personalizzazione. I nomi di dominio personalizzati potrebbero essere necessari anche per soddisfare i requisiti di sicurezza dei clienti, soprattutto se devono fornire i propri certificati TLS. Anche se potrebbe sembrare semplice consentire ai clienti di portare i propri nomi di dominio, ci sono alcune complessità nascoste per questo approccio e richiede considerazioni ponderate.

Risoluzione dei nomi

In definitiva, ogni nome di dominio deve essere risolto in un indirizzo IP. Come si è visto, l'approccio in base al quale la risoluzione dei nomi si verifica può dipendere dal fatto che si distribuisca un'unica istanza o più istanze della soluzione.

Torniamo al nostro esempio. Uno dei clienti di Contoso, Fabrikam, ha chiesto di usare invoices.fabrikam.com, come nome di dominio personalizzato per accedere al servizio di Contoso. Poiché Contoso dispone di più distribuzioni della piattaforma, decide di usare i sottodomini e i record CNAME per ottenere i requisiti di routing. Contoso e Fabrikam configurano i record DNS seguenti:

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

Risoluzione dell'intestazione host

La risoluzione dei nomi è solo metà del problema. Tutti i componenti Web all'interno della distribuzione europea di Contoso devono essere consapevoli di come gestire le richieste che arrivano con il nome di dominio di Fabrikam nell'intestazione Host della richiesta. A seconda delle tecnologie Web specifiche usate da Contoso, potrebbe richiedere una configurazione aggiuntiva per il nome di dominio di ogni tenant, che aggiunge un sovraccarico operativo aggiuntivo all'onboarding dei 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, Frontdoor di Azure consente di riscrivere Host le intestazioni, in modo che, indipendentemente dalla richiesta, il server applicazioni riceva un'unica Host intestazione. 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

È importante convalidare la proprietà dei domini personalizzati prima di eseguirne l'onboarding. In caso contrario, si rischia un cliente di parcheggio accidentalmente o dannoso di un nome di dominio.

Si consideri il processo di onboarding di Contoso per Adventure Works, che ha chiesto di usare invoices.adventureworks.com come nome di dominio personalizzato. Sfortunatamente, qualcuno ha fatto un errore di digitatura quando hanno cercato di caricare il nome di dominio personalizzato e hanno perso la s. Quindi, lo configurano come invoices.adventurework.com. Non solo il traffico non scorre correttamente per Adventure Works, ma quando un'altra società denominata Adventure Work tenta di aggiungere il proprio dominio personalizzato alla piattaforma di Contoso, viene detto che il nome di dominio è già in uso.

Quando si utilizzano domini personalizzati, soprattutto all'interno di un processo self-service o automatizzato, è comune richiedere un passaggio di verifica del dominio. Ciò potrebbe richiedere che i record CNAME vengano configurati prima che sia possibile aggiungere il dominio. In alternativa, Contoso potrebbe generare una stringa casuale e chiedere a Adventure Works di aggiungere un record TXT DNS con il valore stringa. Ciò impedisce l'aggiunta del nome di dominio fino al completamento della verifica.

Attacchi di acquisizione di dns e sottodominio

Quando si riguardano nomi di dominio personalizzati, si è potenzialmente vulnerabili a una classe di attacco denominata dangling DNS o subdomain takeover. Questo attacco si verifica quando i clienti non accedono al nome di dominio personalizzato dal servizio, ma non eliminano il record dal server DNS. Questa voce DNS punta quindi a una risorsa non esistente ed è vulnerabile a un'acquisizione.

Si consideri come la relazione di Fabrikam con Contoso potrebbe cambiare:

1. Fabrikam ha deciso di non lavorare più con Contoso e quindi hanno terminato la relazione aziendale.
2. Contoso ha disattivato il tenant di Fabrikam e ha richiesto di fabrikam.contoso.com non funzionare più. Tuttavia, Fabrikam ha dimenticato di eliminare il record CNAME per invoices.fabrikam.com.
3. Un attore dannoso crea un nuovo account Contoso e lo assegna al nome fabrikam.
4. L'utente malintenzionato esegue l'onboarding del nome invoices.fabrikam.com di dominio personalizzato nel nuovo tenant. Poiché Contoso esegue la convalida del dominio basata su CNAME, controllano il server DNS di Fabrikam. Il server DNS restituisce un record CNAME per invoices.fabrikam.com, che punta a fabrikam.contoso.com. Contoso considera la convalida del dominio personalizzata con esito positivo.
5. Se i dipendenti di Fabrikam hanno tentato 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ò quindi accedere.

Le strategie comuni per proteggere dagli attacchi DNS in grado di assegnare un'eccezione sono:

• Richiedere che il record CNAME venga eliminato prima che il nome di dominio possa essere rimosso dall'account del tenant.
• Impedire il riutilizzo degli identificatori del tenant e richiedere anche che il tenant crei un record TXT con un nome corrispondente al nome di dominio e un valore generato in modo casuale, che cambia per ogni tentativo di onboarding.

Certificati TLS/SSL

Transport Layer Security (TLS) è un componente essenziale quando si utilizzano applicazioni moderne. Fornisce attendibilità e sicurezza alle applicazioni Web. La proprietà e la gestione dei certificati TLS è qualcosa che richiede un'attenta considerazione per le applicazioni multi-tenant.

In genere, il proprietario di un nome di dominio sarà responsabile dell'emissione e del rinnovo dei relativi certificati. Ad esempio, Contoso è responsabile dell'emissione e del rinnovo dei certificati TLS per us.contoso.com, nonché di un certificato con caratteri jolly per *.contoso.com. Analogamente, Fabrikam sarebbe in genere responsabile della gestione di qualsiasi record per il fabrikam.com dominio, incluso invoices.fabrikam.com. Il tipo di record DNS CAA (Autorizzazione autorità di certificazione) può essere usato da un proprietario di dominio. I record CAA garantiscono che solo le autorità specifiche possano creare certificati per il dominio.

Se si prevede di consentire ai clienti di portare i propri domini, valutare se si prevede di rilasciare il certificato per conto del cliente o se i clienti devono portare i propri certificati. Ogni opzione presenta vantaggi e svantaggi.

• Se si rilascia un certificato per un cliente, è possibile gestire il rinnovo del certificato, quindi il cliente non deve ricordare di mantenerlo aggiornato. Tuttavia, se i clienti hanno record CAA sui nomi di dominio, potrebbe essere necessario autorizzare l'utente a rilasciare certificati per conto del cliente.
• Se si prevede che i clienti debbano emettere e fornire i propri certificati, si è responsabili della ricezione e della gestione delle chiavi private in modo sicuro e potrebbe essere necessario ricordare ai clienti di rinnovare il certificato prima della scadenza, per evitare un'interruzione nel loro servizio.

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 domini personalizzati e gestiscono automaticamente il processo di rinnovo. Ciò consente di rimuovere il carico di gestione dei certificati dal team operativo. Tuttavia, è comunque necessario considerare la questione della proprietà e dell'autorità, ad esempio se i record CAA sono effettivi e configurati correttamente. È inoltre necessario assicurarsi che i domini dei clienti siano configurati per consentire i certificati gestiti dalla piattaforma.

Autori di contributi

Questo articolo viene gestito da Microsoft. È stato originariamente scritto dai collaboratori seguenti.

Autore principale:

• John Downs | Principal Customer Engineer, FastTrack per Azure

Altri collaboratori:

• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirsky | Principal Customer Engineer, FastTrack per Azure

Per visualizzare profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

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