Overwegingen bij het gebruik van domeinnamen in een multitenant-oplossing

Azure

In veel webtoepassingen met meerdere tenants kan een domeinnaam worden gebruikt als een manier om een tenant te identificeren, om te helpen bij het routeren van aanvragen naar de juiste infrastructuur en om uw klanten een merkervaring te bieden. Twee veelgebruikte benaderingen zijn het gebruik van subdomeinen en aangepaste domeinnamen. Op deze pagina bieden we technische besluitvormers richtlijnen over de benaderingen die u kunt overwegen en hun compromissen.

Subdomeinen

Elke tenant kan een uniek subdomein krijgen onder een gemeenschappelijke gedeelde domeinnaam, met behulp van een indeling zoals tenant.provider.com.

Laten we eens kijken naar een voorbeeld van een multitenant-oplossing die is gebouwd door Contoso. Klanten kopen het product van Contoso om het genereren van facturen te beheren. Aan alle tenants van Contoso kan een eigen subdomein worden toegewezen, onder de contoso.com domeinnaam. Of, als Contoso regionale implementaties gebruikt, kunnen ze subdomeinen toewijzen onder de us.contoso.com domeinen en eu.contoso.com . In dit artikel verwijzen we naar deze als stem-domeinen. Elke klant krijgt een eigen subdomein onder uw stamdomein. Tailwind Toys kan bijvoorbeeld worden toegewezen tailwind.contoso.comen Adventure Works kan worden toegewezen adventureworks.contoso.com.

Notitie

Veel Azure-services gebruiken deze methode. Wanneer u bijvoorbeeld een Azure-opslagaccount maakt, wordt er een set subdomeinen toegewezen die u kunt gebruiken, zoals <your account name>.blob.core.windows.net.

Uw domeinnaamruimte beheren

Wanneer u subdomeinen onder uw eigen domeinnaam maakt, moet u er rekening mee houden dat u meerdere klanten met vergelijkbare namen kunt hebben. Omdat ze één stamdomein delen, krijgt de eerste klant die een bepaald domein krijgt de voorkeursnaam. Vervolgens moeten volgende klanten alternatieve subdomeinnamen gebruiken, omdat volledige domeinnamen globaal uniek moeten zijn.

DNS met jokertekens

Overweeg het gebruik van DNS-vermeldingen met jokertekens om het beheer van subdomeinen te vereenvoudigen. In plaats van DNS-vermeldingen voor tailwind.contoso.com, adventureworks.contoso.comenzovoort te maken, kunt u in plaats daarvan een jokertekenvermelding maken voor *.contoso.com en alle subdomeinen doorsturen naar één IP-adres (A-record) of canonieke naam (CNAME-record).

Notitie

Zorg ervoor dat uw weblaagservices ondersteuning bieden voor DNS met jokertekens als u van plan bent om gebruik te maken van deze functie. Veel Azure-services, waaronder Azure Front Door en Azure App Service, ondersteunen DNS-vermeldingen met jokertekens.

Subdomeinen met stamdomeinen met meerdere delen

Veel multitenant-oplossingen zijn verspreid over meerdere fysieke implementaties. Dit is een veelgebruikte benadering wanneer u moet voldoen aan vereisten voor gegevenslocatie of wanneer u betere prestaties wilt bieden door resources geografisch dichter bij de gebruikers te implementeren.

Zelfs binnen één regio moet u mogelijk uw tenants spreiden over onafhankelijke implementaties om uw schaalstrategie te ondersteunen. Als u van plan bent om subdomeinen voor elke tenant te gebruiken, kunt u overwegen om een subdomeinstructuur met meerdere delen te gebruiken.

Hier volgt een voorbeeld: Contoso publiceert een toepassing met meerdere tenants voor de vier klanten. Adventure Works en Tailwind Traders bevinden zich in de Verenigde Staten en hun gegevens worden opgeslagen op een gedeeld Exemplaar in de Vs van het Contoso-platform. Fabrikam en Worldwide Importers bevinden zich in Europa en hun gegevens worden opgeslagen op een Europees exemplaar.

Als Contoso ervoor kiest om één stamdomein te gebruiken, contoso.com, voor al hun klanten, ziet dit er als volgt uit:

Diagram met implementaties in de VS en de EU van een web-app, met één stamdomein voor het subdomein van elke klant.

De DNS-vermeldingen (die vereist zijn om deze configuratie te ondersteunen) kunnen er als volgt uitzien:

Subdomein CNAME naar
adventureworks.contoso.com us.contoso.com
tailwind.contoso.com us.contoso.com
fabrikam.contoso.com eu.contoso.com
worldwideimporters.contoso.com eu.contoso.com

Elke nieuwe klant waarvoor onboarding wordt ingesteld, vereist een nieuw subdomein en het aantal subdomeinen groeit met elke klant.

Contoso kan ook implementatie- of regiospecifieke stamdomeinen gebruiken, zoals:

Diagram met implementaties in de VS en de EU van een web-app, met meerdere stamdomeinen.

Met behulp van dns met jokertekens kunnen de DNS-vermeldingen voor deze implementatie er als volgt uitzien:

Subdomein CNAME naar
*.us.contoso.com us.contoso.com
*.eu.contoso.com eu.contoso.com

Contoso hoeft niet voor elke klant subdomeinrecords te maken. In plaats daarvan hebben ze één DNS-record met jokertekens voor de implementatie van elke geografie, en nieuwe klanten die onder die stam worden toegevoegd, nemen automatisch de CNAME-record over.

Elke benadering heeft voor- en nadelen. Wanneer u één stamdomein gebruikt, moet voor elke tenant die u onboardt een nieuwe DNS-record worden gemaakt, wat leidt tot meer operationele overhead. U hebt echter meer flexibiliteit om tenants tussen implementaties te verplaatsen, omdat u de CNAME-record kunt wijzigen om het verkeer naar een andere implementatie te leiden. Deze wijziging is niet van invloed op andere tenants. Wanneer u meerdere stamdomeinen gebruikt, is er een lagere overhead voor beheer. U kunt ook klantnamen hergebruiken in meerdere regionale stamdomeinen, omdat elk stamdomein in feite een eigen naamruimte vertegenwoordigt.

Aangepaste domeinnamen

Mogelijk wilt u uw klanten in staat stellen hun eigen domeinnamen mee te nemen. Sommige klanten zien dit als een belangrijk aspect van hun huisstijl. Aangepaste domeinnamen kunnen ook vereist zijn om te voldoen aan de beveiligingsvereisten van klanten, met name als ze hun eigen TLS-certificaten moeten leveren. Hoewel het misschien onbelangrijk lijkt om klanten in staat te stellen hun eigen domeinnamen mee te nemen, zijn er enkele verborgen complexiteiten aan deze benadering en moet u er goed over nadenken.

Naamomzetting

Uiteindelijk moet elke domeinnaam worden omgezet in een IP-adres. Zoals u hebt gezien, kan de manier waarop naamomzetting wordt uitgevoerd, afhankelijk zijn van het feit of u één exemplaar of meerdere exemplaren van uw oplossing implementeert.

Laten we teruggaan naar ons voorbeeld. Een van de klanten van Contoso, Fabrikam, heeft gevraagd om , te gebruiken invoices.fabrikam.comals hun aangepaste domeinnaam om toegang te krijgen tot de service van Contoso. Omdat Contoso meerdere implementaties van hun platform heeft, besluiten ze subdomeinen en CNAME-records te gebruiken om aan hun routeringsvereisten te voldoen. Contoso en Fabrikam configureren de volgende DNS-records:

Naam Recordtype Waarde Geconfigureerd door
invoices.fabrikam.com CNAME fabrikam.eu.contoso.com Fabrikam
*.eu.contoso.com CNAME eu.contoso.com Contoso
eu.contoso.com A (IP-adres van Contoso) Contoso

Vanuit het perspectief van naamomzetting worden aanvragen voor invoices.fabrikam.com met deze keten nauwkeurig omgezet in het IP-adres van de Europese implementatie van Contoso.

Resolutie van hostheader

Naamomzetting is slechts de helft van het probleem. Alle webonderdelen in de Europese implementatie van Contoso moeten zich bewust zijn van hoe aanvragen moeten worden verwerkt die binnenkomen met de domeinnaam van Fabrikam in de Host aanvraagheader. Afhankelijk van de specifieke webtechnologieën die Contoso gebruikt, is hiervoor mogelijk verdere configuratie vereist voor de domeinnaam van elke tenant, wat extra operationele overhead toevoegt aan de onboarding van tenants.

U kunt ook overwegen om hostheaders opnieuw te schrijven, zodat uw webserver, ongeacht de header van de binnenkomende aanvraag Host , een consistente headerwaarde ziet. Met Azure Front Door kunt u bijvoorbeeld headers herschrijven Host , zodat uw toepassingsserver, ongeacht de aanvraag, één Host header ontvangt. Azure Front Door geeft de oorspronkelijke hostheader door in de X-Forwarded-Host header, zodat uw toepassing deze kan inspecteren en vervolgens de tenant kan opzoeken. Het herschrijven van een Host koptekst kan echter andere problemen veroorzaken. Zie Behoud van hostnaam voor meer informatie.

Domeinvalidatie

Het is belangrijk om het eigendom van aangepaste domeinen te valideren voordat u ze onboardt. Anders loopt u het risico dat een klant per ongeluk of met opzet een domeinnaam parkeert .

Laten we eens kijken naar het onboardingproces van Contoso voor Adventure Works, die hebben gevraagd om te gebruiken invoices.adventureworks.com als hun aangepaste domeinnaam. Helaas heeft iemand een typfout gemaakt toen ze probeerde de aangepaste domeinnaam te onboarden en ze misten de s. Daarom hebben ze het ingesteld als invoices.adventurework.com. Niet alleen stroomt het verkeer niet correct voor Adventure Works, maar wanneer een ander bedrijf met de naam Adventure Work probeert hun aangepaste domein toe te voegen aan het platform van Contoso, krijgen ze te horen dat de domeinnaam al in gebruik is.

Wanneer u met aangepaste domeinen werkt, met name binnen een selfservice of geautomatiseerd proces, is het gebruikelijk om een domeinverificatiestap te vereisen. Hiervoor moet u mogelijk de CNAME-records instellen voordat het domein kan worden toegevoegd. Contoso kan ook een willekeurige tekenreeks genereren en Adventure Works vragen om een DNS TXT-record met de tekenreekswaarde toe te voegen. Dat voorkomt dat de domeinnaam wordt toegevoegd totdat de verificatie is voltooid.

Zwevende DNS- en subdomeinovernameaanvallen

Wanneer u met aangepaste domeinnamen werkt, bent u mogelijk kwetsbaar voor een aanvalsklasse die zwevende DNS - of subdomeinovername wordt genoemd. Deze aanval treedt op wanneer klanten hun aangepaste domeinnaam loskoppelen van uw service, maar ze de record niet van hun DNS-server verwijderen. Deze DNS-vermelding verwijst vervolgens naar een niet-bestaande resource en is kwetsbaar voor een overname.

Laten we eens kijken hoe de relatie van Fabrikam met Contoso kan veranderen:

  1. Fabrikam heeft besloten niet langer met Contoso samen te werken en daarom hebben ze hun zakelijke relatie beëindigd.
  2. Contoso heeft de Fabrikam-tenant offboarded en ze hebben aangevraagd fabrikam.contoso.com om niet meer te werken. Fabrikam is echter vergeten de CNAME-record voor invoices.fabrikam.comte verwijderen.
  3. Een kwaadwillende actor maakt een nieuw Contoso-account en geeft dit de naam fabrikam.
  4. De aanvaller onboardt de aangepaste domeinnaam invoices.fabrikam.com naar de nieuwe tenant. Omdat Contoso op CNAME gebaseerde domeinvalidatie uitvoert, controleren ze de DNS-server van Fabrikam. Ze zien dat de DNS-server een CNAME-record retourneert voor invoices.fabrikam.com, die verwijst naar fabrikam.contoso.com. Contoso beschouwt de validatie van het aangepaste domein als geslaagd.
  5. Als een fabrikam-werknemer toegang probeert te krijgen tot de site, lijken aanvragen te werken. Als de aanvaller zijn Contoso-tenant instelt met de huisstijl van Fabrikam, worden werknemers mogelijk misleid om toegang te krijgen tot de site en gevoelige gegevens te verstrekken, waartoe de aanvaller vervolgens toegang heeft.

Veelvoorkomende strategieën voor bescherming tegen zwevende DNS-aanvallen zijn:

  • Vereisen dat de CNAME-record wordt verwijderd voordat de domeinnaam kan worden verwijderd uit het account van de tenant.
  • Verbied het hergebruik van tenant-id's en eis ook dat de tenant een TXT-record maakt met een naam die overeenkomt met de domeinnaam en een willekeurig gegenereerde waarde, die wordt gewijzigd voor elke onboardingpoging.

TLS/SSL-certificaten

Tls (Transport Layer Security) is een essentieel onderdeel bij het werken met moderne toepassingen. Het biedt vertrouwen en beveiliging voor uw webtoepassingen. Het eigendom en beheer van TLS-certificaten is iets dat zorgvuldig moet worden overwogen voor toepassingen met meerdere tenants.

Normaal gesproken is de eigenaar van een domeinnaam verantwoordelijk voor het uitgeven en vernieuwen van de certificaten. Contoso is bijvoorbeeld verantwoordelijk voor het uitgeven en vernieuwen van TLS-certificaten voor us.contoso.com, evenals een jokertekencertificaat voor *.contoso.com. Op dezelfde manier is Fabrikam over het algemeen verantwoordelijk voor het beheren van alle records voor het fabrikam.com domein, met inbegrip van invoices.fabrikam.com. Het DNS-recordtype CAA (Certificeringsinstantieautorisatie) kan worden gebruikt door een domeineigenaar. CAA-records zorgen ervoor dat alleen specifieke instanties certificaten voor het domein kunnen maken.

Als u van plan bent om klanten toe te staan hun eigen domeinen mee te nemen, moet u overwegen of u van plan bent om het certificaat namens de klant uit te geven of dat de klanten hun eigen certificaten moeten meenemen. Elke optie heeft voor- en nadelen.

  • Als u een certificaat voor een klant uitgeeft, kunt u het vernieuwen van het certificaat afhandelen, zodat de klant het niet hoeft te onthouden om het bijgewerkt te houden. Als de klanten echter CAA-records voor hun domeinnamen hebben, moeten ze u mogelijk machtigen om namens hen certificaten uit te geven.
  • Als u verwacht dat klanten hun eigen certificaten moeten uitgeven en aan u moeten verstrekken, bent u verantwoordelijk voor het op een veilige manier ontvangen en beheren van de persoonlijke sleutels. Mogelijk moet u uw klanten eraan herinneren om het certificaat te vernieuwen voordat het verloopt, om een onderbreking van hun service te voorkomen.

Verschillende Azure-services ondersteunen automatisch beheer van certificaten voor aangepaste domeinen. Zo bieden Azure Front Door en App Service certificaten voor aangepaste domeinen en verwerken ze automatisch het verlengingsproces. Dit verwijdert de last van het beheren van certificaten voor uw operationele team. U moet echter nog steeds rekening houden met de vraag van eigendom en autoriteit, zoals of CAA-records van kracht zijn en correct zijn geconfigureerd. U moet er ook voor zorgen dat de domeinen van uw klanten zijn geconfigureerd om de certificaten toe te staan die door het platform worden beheerd.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteur:

Andere inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Tip

Veel services maken gebruik van Azure Front Door om domeinnamen te beheren. Zie Azure Front Door gebruiken in een multitenant-oplossing voor informatie over het gebruik van Azure Front Door in een multitenant-oplossing.

Ga terug naar het overzicht van overwegingen voor de architectuur. Of bekijk het Microsoft Azure Well-Architected Framework.