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 ai clienti un'esperienza personalizzata. Due approcci comuni sono l'uso di sottodomini e nomi di dominio personalizzati. In questa pagina vengono fornite indicazioni per i decision maker tecnici sugli approcci che è possibile prendere in considerazione e sui relativi 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 ora un esempio di soluzione multi-tenant creata 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, è possibile assegnare sottodomini nei us.contoso.com domini e eu.contoso.com . In questo articolo si fa riferimento a questi come domini stem. Ogni cliente ottiene il proprio sottodominio nel dominio stem. Ad esempio, Tailwind Toys potrebbe essere assegnato tailwind.contoso.come, in un modello di distribuzione a livello di area, Adventure Works potrebbe essere assegnato adventureworks.us.contoso.com.

Gestire lo spazio dei nomi del dominio

Quando si creano sottodomini con 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

Prendere in considerazione l'uso di 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 a un nome canonico (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.

Sottodomini con domini stem multipart

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

Anche all'interno di una singola area, potrebbe anche essere necessario distribuire i tenant tra distribuzioni indipendenti, per supportare la strategia di scalabilità. Se si prevede di usare sottodomini per ogni tenant, è possibile prendere in considerazione 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 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.

Se Contoso ha scelto di usare un singolo dominio stem, contoso.com, per tutti i clienti, ecco come potrebbe essere simile al seguente:

Le voci DNS (necessarie per supportare questa configurazione) potrebbero avere un aspetto simile al seguente:

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

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

Usando quindi il DNS con caratteri jolly, le voci DNS per questa distribuzione potrebbero avere un aspetto simile 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 che vengono aggiunti al di sotto dello stelo ereditano automaticamente il record CNAME.

Esistono vantaggi e svantaggi per ogni approccio. Quando si usa un singolo dominio stem, ogni tenant di cui si esegue l'onboarding richiede la creazione di un nuovo record DNS, che comporta un sovraccarico operativo maggiore. Tuttavia, si ha maggiore flessibilità per spostare i tenant tra le distribuzioni, perché è possibile modificare il record CNAME per indirizzare il traffico a un'altra distribuzione. Questa modifica non influirà su altri tenant. Quando si usano più domini stem, si verifica un sovraccarico di gestione inferiore. Inoltre, è 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 lo vedono come un aspetto importante della loro personalizzazione. I nomi di dominio personalizzati potrebbero anche essere necessari 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 a 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 con cui viene eseguita la risoluzione dei nomi può dipendere dal fatto che si distribuisca una singola istanza o più istanze della soluzione.

Torniamo all'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 ha più distribuzioni della piattaforma multi-tenant, decide di usare sottodomini e record CNAME per soddisfare 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 accuratamente le richieste per invoices.fabrikam.com l'indirizzo IP della distribuzione europea di Contoso.

Risoluzione dell'intestazione host

La risoluzione dei nomi è solo la 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, questa operazione potrebbe richiedere un'ulteriore configurazione per il nome di dominio di ogni tenant, con un sovraccarico operativo aggiuntivo per l'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 una singola 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 che un cliente parcheggi in modo accidentale o dannoso 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 ortografia quando ha 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 viene eseguito correttamente per Adventure Works, ma quando un'altra società denominata Adventure Work tenta di aggiungere il proprio dominio personalizzato alla piattaforma di Contoso, viene indicato che il nome di dominio è già in uso.

Quando si lavora con domini personalizzati, soprattutto all'interno di un processo self-service o automatizzato, è comune richiedere un passaggio di verifica del dominio. Ciò potrebbe richiedere la configurazione dei record CNAME prima che il dominio possa essere aggiunto. 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 del dns e del sottodominio dangling

Quando si lavora con nomi di dominio personalizzati, si è potenzialmente vulnerabili a una classe di attacco denominata dangling DNS o acquisizione di sottodominio. Questo attacco si verifica 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.

Si esaminerà ora il modo in cui la relazione di Fabrikam con Contoso potrebbe cambiare:

1. Fabrikam ha deciso di non lavorare più con Contoso e quindi ha terminato la relazione di business.
2. Contoso ha eseguito l'offboarding del 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 malintenzionato crea un nuovo account Contoso e assegna il 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, controlla il server DNS di Fabrikam. Si noterà che il server DNS restituisce un record CNAME per invoices.fabrikam.com, che punta a fabrikam.contoso.com. Contoso considera che la convalida del dominio personalizzato sia corretta.
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ò accedere.

Le strategie comuni per la protezione dagli attacchi DNS incerti 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 lavora con le applicazioni moderne. Offre attendibilità e sicurezza per le applicazioni Web. La proprietà e la gestione dei certificati TLS è un elemento che richiede un'attenta considerazione per le applicazioni multi-tenant.

In genere, il proprietario di un nome di dominio è responsabile del rilascio e del rinnovo dei certificati. Ad esempio, Contoso è responsabile del rilascio e del rinnovo dei certificati TLS per us.contoso.com, nonché di un certificato con caratteri jolly per *.contoso.com. Analogamente, Fabrikam è in genere responsabile della gestione di tutti i record per il fabrikam.com dominio, incluso invoices.fabrikam.com.

Il tipo di record DNS CAA (Certificate Authority Authorization) può essere usato da un proprietario del dominio. I record CAA assicurano che solo 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 ricordarsi di mantenerlo aggiornato. Tuttavia, se i clienti hanno record CAA sui nomi di dominio, potrebbe essere necessario autorizzare l'utente a rilasciare certificati per loro conto.
• Se si prevede che i clienti rilascino e forniscano 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 del 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. In questo modo, il carico di lavoro per la gestione dei certificati viene rimosso dal team operativo. Tuttavia, è comunque necessario considerare la questione della proprietà e dell'autorità, ad esempio se i record CAA sono attivi e configurati correttamente. Inoltre, è necessario assicurarsi che i domini dei clienti siano configurati per consentire i certificati gestiti dalla piattaforma.

Collaboratori

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

Autore principale:

• John Downs | Principal Software Engineer

Altri contributori:

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

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

Passaggi successivi

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