Considérations relatives à l’utilisation des noms de domaine dans une solution multilocataire

Dans de nombreuses applications web multilocataires, un nom de domaine peut être utilisé pour identifier un locataire, pour faciliter le routage des requêtes vers l’infrastructure appropriée, et pour offrir une expérience de marque à vos clients. Les deux approches courantes sont d’utiliser des sous-domaines et d’utiliser des noms de domaine personnalisés. Dans cette page, nous fournissons des conseils pour les décideurs techniques sur les approches que vous pouvez prendre en compte et leurs compromis.

Sous-domaines

Chaque locataire peut obtenir un sous-domaine unique sous un nom de domaine partagé commun, à l’aide d’un format tel que tenant.provider.com.

Prenons l’exemple d’une solution multilocataire conçue par Contoso. Les clients achètent le produit de Contoso pour faciliter la génération de leurs factures. Tous les locataires de Contoso peuvent se voir attribuer leur propre sous-domaine, sous le nom de domaine contoso.com. Ou, si Contoso utilise des déploiements régionaux, elle peut affecter des sous-domaines sous les domaines us.contoso.com et eu.contoso.com. Dans cet article, nous les désignons comme domaines souches (stem domain). Chaque client obtient son propre sous-domaine sous votre domaine souche. Par exemple, Tailwind Toys peut se voir attribuer tailwind.contoso.com, et, dans un modèle de déploiement régional, Adventure Works peut se voir attribuer adventureworks.us.contoso.com.

Gérer votre espace de noms de domaine

Quand vous créez des sous-domaines sous votre propre nom de domaine, vous devez garder à l’esprit que vous pouvez avoir plusieurs clients portant des noms semblables. Étant donné que les client partagent un domaine souche unique, le premier client à obtenir un domaine particulier obtient son nom préféré. Ensuite, les clients suivants doivent utiliser d’autres noms de sous-domaines, car les noms de domaine complets doivent être globalement uniques.

DNS génériques

Envisagez d’utiliser des entrées DNS génériques pour simplifier la gestion des sous-domaines. Au lieu de créer des entrées DNS pour tailwind.contoso.com, adventureworks.contoso.com, etc., vous pouvez plutôt créer une entrée générique pour *.contoso.com et diriger tous les sous-domaines vers une seule adresse IP (enregistrement A) ou un nom canonique (enregistrement CNAME). Si vous utilisez des domaines souches régionaux, vous devrez peut-être utiliser plusieurs entrées génériques, comme *.us.contoso.com et *.eu.contoso.com.

Sous-domaines avec domaines souches en plusieurs parties

De nombreuses solutions multilocataires sont réparties sur plusieurs déploiements physiques. Cette approche est courante lorsque vous devez vous conformer aux exigences de résidence des données, ou lorsque vous voulez améliorer les performances en déployant des ressources géographiquement plus proches des utilisateurs.

Même au sein d’une même région, vous devrez peut-être également répartir vos locataires dans des déploiements indépendants, afin de prendre en charge votre stratégie de mise à l’échelle Si vous envisagez d’utiliser des sous-domaines pour chaque locataire, vous pouvez envisager une structure de sous-domaines en plusieurs parties.

Voici un exemple : Contoso publie une application multilocataire pour ses quatre clients. Adventure Works et Tailwind Traders se trouvent aux États-Unis et leurs données sont stockées sur une instance américaine partagée de la plateforme Contoso. Fabrikam et Worldwide Importers sont en Europe et leurs données sont stockées sur une instance européenne.

Si Contoso choisissait d’utiliser un domaine souche unique, contoso.com, pour tous ses clients, voici ce à quoi cela pourrait ressembler :

Les entrées DNS (qui sont nécessaires à la prise en charge de cette configuration) peuvent se présenter comme suit :

Chaque nouveau client qui est intégré nécessite un nouveau sous-domaine, et le nombre de sous-domaines augmente avec chaque client.

Contoso peut également utiliser des domaines spécifiques à un déploiement ou à une région, de la manière suivante :

Ensuite, à l’aide du DNS générique, les entrées DNS de ce déploiement peuvent ressembler à ceci :

La société Contoso n’a pas besoin de créer des enregistrements de sous-domaine pour chaque client. Au lieu de cela, elle dispose d’un seul enregistrement DNS générique pour le déploiement de chaque zone géographique, et tous les nouveaux clients ajoutés sous cette souche héritent automatiquement de l’enregistrement CNAME.

Chaque approche a ses avantages et ses inconvénients. Lors de l’utilisation d’un domaine souche unique, chaque locataire que vous intégrez nécessite qu’un nouvel enregistrement DNS soit créé, ce qui entraîne une surcharge opérationnelle supplémentaire. Toutefois, vous disposez de davantage de flexibilité pour déplacer des locataires entre des déploiements, car vous pouvez changer l’enregistrement CNAME afin de diriger leur trafic vers un autre déploiement. Ce changement n’affectera aucun autre locataire. Lors de l’utilisation de plusieurs domaines souches, la surcharge de gestion est plus faible. Par ailleurs, vous pouvez réutiliser les noms des clients dans plusieurs domaines souches régionaux, car chaque domaine souche représente son propre espace de noms.

Noms de domaine personnalisés

Vous pouvez autoriser vos clients à apporter leurs propres noms de domaine. Certains clients voient cela comme un aspect important de leur personnalisation. Les noms de domaine personnalisés peuvent également être nécessaires afin de répondre aux exigences de sécurité des clients, en particulier s’ils doivent fournir leurs propres certificats TLS. Bien que cela puisse sembler dérisoire de permettre aux clients d’apporter leurs propres noms de domaine, cette approche peut comporter des complexités masquées et nécessite d’y réfléchir à deux fois.

Résolution de noms

Pour finir, chaque nom de domaine doit être résolu en une adresse IP. Comme vous l’avez vu, l’approche par laquelle la résolution de noms se produit peut varier selon que vous déployez une instance unique ou plusieurs instances de votre solution.

Revenons à notre exemple. L’un des clients de Contoso, Fabrikam, a demandé à utiliser invoices.fabrikam.com comme nom de domaine personnalisé pour accéder au service de Contoso. Contoso ayant plusieurs déploiements de sa plateforme mutualisée, elle décide d’utiliser des sous-domaines et des enregistrements CNAME pour répondre à ses besoins de routage. Contoso et Fabrikam configurent les enregistrements DNS suivants :

Du point de vue de la résolution de noms, cette chaîne d’enregistrements résout rigoureusement les requêtes pour invoices.fabrikam.com en l’adresse IP du déploiement en Europe de Contoso.

Résolution d’en-tête d’hôte

La résolution de noms n’est que la moitié du problème. Tous les composants web au sein du déploiement en Europe de Contoso doivent savoir comment gérer les requêtes qui arrivent avec le nom de domaine de Fabrikam dans leur en-tête de requête Host. En fonction des technologies web spécifiques utilisées par Contoso, une configuration complémentaire peut s’avérer nécessaire pour le nom de domaine de chaque locataire, ce qui ajoute une surcharge opérationnelle supplémentaire à l’intégration des locataires.

Vous pouvez également envisager de réécrire des en-têtes d’hôtes, de sorte que, quel que soit l’en-tête Host de la demande entrante, votre serveur web voit une valeur d’en-tête cohérente. Par exemple, Azure Front Door vous permet de réécrire des en-têtes Host, de sorte que, quelle que soit la demande, votre serveur d’applications reçoit un seul en-tête Host. Azure Front Door propage l’en-tête d’hôte d’origine dans l’en-tête X-Forwarded-Host afin que votre application puisse l’inspecter puis rechercher le locataire. Toutefois, la réécriture d’un en-tête Host peut entraîner d’autres problèmes. Pour plus d’informations, consultez Conservation du nom d’hôte.

Validation de domaine

Il est important de valider la propriété de domaines personnalisés avant de les intégrer. Sinon, vous risquez qu’un client parque un nom de domaine de façon malveillante ou accidentelle.

Prenons l’exemple du processus d’intégration de Contoso pour Adventure Works, qui a demandé à utiliser invoices.adventureworks.com comme nom de domaine personnalisé. Malheureusement, une personne a fait une faute de frappe quand elle a essayé d’intégrer le nom de domaine personnalisé et elle a oublié le s. Par conséquent, elle l’a configuré en tant que invoices.adventurework.com. Non seulement le trafic n’est pas correctement transmis pour Adventure Works, mais quand une autre société appelée Adventure Work tente d’ajouter son domaine personnalisé à la plateforme de Contoso, elle est informée que le nom de domaine est déjà utilisé.

Quand vous utilisez des domaines personnalisés, en particulier dans un processus en libre-service ou automatisé, il est courant d’exiger une étape de vérification du domaine. Cela peut demander la configuration des enregistrements CNAME pour que le domaine puisse être ajouté. Contoso peut également générer une chaîne aléatoire et demander à Adventure Works d’ajouter un enregistrement TXT DNS avec la valeur de chaîne. Cela empêche que le nom de domaine soit ajouté jusqu’à ce que la vérification soit terminée.

Attaques de DNS non résolus et de prise de contrôle de sous-domaines

Quand vous utilisez des noms de domaine personnalisés, vous êtes potentiellement vulnérable à une classe d’attaques appelée DNS non résolus ou prise de contrôle de sous-domaines. Cette attaque se produit quand les clients dissocient leur nom de domaine personnalisé de votre service, mais qu’ils ne suppriment pas l’enregistrement de leur serveur DNS. Cette entrée DNS pointe ensuite vers une ressource inexistante et est vulnérable à une prise de contrôle.

Voyons comment les relations de Fabrikam avec Contoso peuvent changer :

1. Fabrikam a décidé de ne plus travailler avec Contoso et a, par conséquent, mis fin à sa relation commerciale.
2. L’intégration du locataire Fabrikam a été annulée par Contoso, qui a demandé que le nom de domaine fabrikam.contoso.com ne soit plus opérationnel. Toutefois, Fabrikam a oublié de supprimer l’enregistrement CNAME pour invoices.fabrikam.com.
3. Un acteur malveillant crée un nouveau compte Contoso et lui attribue le nom fabrikam.
4. L’attaquant intègre le nom de domaine personnalisé invoices.fabrikam.com à son nouveau locataire. Étant donné que la société Contoso effectue une validation de domaine CNAME, elle vérifie le serveur DNS de Fabrikam. Elle voit que le serveur DNS retourne un enregistrement CNAME pour invoices.fabrikam.com, qui pointe vers fabrikam.contoso.com. Contoso considère la validation de domaine personnalisée comme réussie.
5. Si des employés de Fabrikam ont essayé d’accéder au site, les demandes semblaient fonctionner. Si l’attaquant configure son locataire Contoso avec la personnalisation de Fabrikam, les employés peuvent être dupés en accédant au site et en fournissant des données sensibles auxquelles l’attaquant peut alors accéder.

Les stratégies courantes de protection contre les attaques par entrées DNS non résolues sont les suivantes :

• Exiger que l’enregistrement CNAME soit supprimé avant que le nom de domaine puisse être supprimé du compte du locataire.
• Interdire la réutilisation des identificateurs de locataire, et exiger également que le locataire crée un enregistrement TXT avec un nom correspondant au nom de domaine et une valeur générée de manière aléatoire, qui change pour chaque tentative d’intégration.

Certificats TLS/SSL

Le protocole TLS (Transport Layer Security) est un composant essentiel quand vous travaillez avec des applications modernes. Il assure la confiance et la sécurité pour vos applications web. La propriété et la gestion des certificats TLS nécessitent une attention particulière pour les applications multilocataires.

En général, le propriétaire d’un nom de domaine est responsable de l’émission et du renouvellement de ses certificats. Par exemple, Contoso est responsable de l’émission et du renouvellement des certificats TLS pour us.contoso.com, ainsi que d’un certificat générique pour *.contoso.com. De même, Fabrikam est généralement responsable de la gestion des enregistrements pour le domaine fabrikam.com, notamment invoices.fabrikam.com.

Le type d’enregistrement DNS CAA (Certificate Authority Authorization) peut être utilisé par le propriétaire d’un domaine. Les enregistrements CAA garantissent que seules des autorités spécifiques peuvent créer des certificats pour le domaine.

Si vous envisagez d’autoriser les clients à apporter leurs propres domaines, déterminez si vous envisagez d’émettre le certificat pour le compte du client ou si les clients doivent apporter leurs propres certificats. Chaque option présente des avantages et des inconvénients :

• Si vous émettez un certificat pour un client, vous pouvez gérer le renouvellement du certificat, de sorte que le client n’a pas à se rappeler de le maintenir à jour. Toutefois, si les clients ont des enregistrements CAA sur leurs noms de domaine, ils devront peut-être vous autoriser à émettre des certificats pour leur compte.
• Si vous pensez que les clients doivent émettre et vous fournir leurs propres certificats, vous êtes responsable de la réception et de la gestion sécurisées des clés privées, et vous devrez peut-être rappeler à vos clients de renouveler le certificat avant qu’il n’expire, afin d’éviter une interruption de leur service.

Plusieurs services Azure prennent en charge la gestion automatique des certificats pour les domaines personnalisés. Par exemple, Azure Front Door et App Service fournissent des certificats pour les domaines personnalisés, et ils gèrent automatiquement le processus de renouvellement. Cela supprime, pour votre équipe en charge des opérations, la charge liée à la gestion des certificats. Toutefois, vous devez toujours prendre en compte la question de la propriété et de l’autorité, comme le fait de déterminer si les enregistrements CAA sont en vigueur et correctement configurés. De plus, vous devez garantir que les domaines de vos clients sont configurés pour autoriser les certificats qui sont gérés par la plateforme.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• John Downs | Ingénieur logiciel principal

Autres contributeurs :

• Daniel Scott-Raynsford | Stratégiste de la technologie partenaire
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Revenez à la vue d’ensemble des considérations sur l’architecture. Ou consultez le Microsoft Azure Well-Architected Framework.