Overwegingen bij het gebruik van domeinnamen in een multitenant-oplossing

In veel multitenant-webtoepassingen 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 veelvoorkomende benaderingen zijn het gebruik van subdomeinen en aangepaste domeinnamen. Op deze pagina bieden we richtlijnen voor technische besluitvormers over de benaderingen die u kunt overwegen en hun compromissen.

Subdomeinen

Elke tenant krijgt mogelijk een uniek subdomein 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 hun factuurgeneratie te beheren. Aan alle tenants van Contoso kan een eigen subdomein worden toegewezen, onder de contoso.com domeinnaam. Als Contoso regionale implementaties gebruikt, kunnen ze subdomeinen onder de us.contoso.com en eu.contoso.com domeinen toewijzen. In dit artikel verwijzen we naar deze domeinen als stamdomeinen. Elke klant krijgt een eigen subdomein onder uw stemdomein. Tailwind Toys kan bijvoorbeeld worden toegewezen tailwind.contoso.comen in een regionaal implementatiemodel kan Adventure Works worden toegewezen adventureworks.us.contoso.com.

Uw domeinnaamruimte beheren

Wanneer u subdomeinen maakt onder uw eigen domeinnaam, moet u er rekening mee houden dat u meerdere klanten met vergelijkbare namen zou kunnen hebben. Omdat ze één stemdomein delen, krijgt de eerste klant die een bepaald domein heeft de voorkeursnaam. Vervolgens moeten volgende klanten alternatieve subdomeinnamen gebruiken, omdat volledige domeinnamen wereldwijd 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 te maken voor tailwind.contoso.com, adventureworks.contoso.comenzovoort, 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). Als u regionale stamdomeinen gebruikt, hebt u mogelijk meerdere jokertekens nodig, zoals *.us.contoso.com en *.eu.contoso.com.

Subdomeinen met domeinen met meerdere onderdelen

Veel multitenant-oplossingen zijn verspreid over meerdere fysieke implementaties. Dit is een algemene benadering wanneer u moet voldoen aan de 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 uw tenants mogelijk ook verspreiden over onafhankelijke implementaties om uw schaalstrategie te ondersteunen. Als u van plan bent subdomeinen voor elke tenant te gebruiken, kunt u een subdomeinstructuur met meerdere onderdelen overwegen.

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

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

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

Elke nieuwe klant die wordt onboarded, vereist een nieuw subdomein en het aantal subdomeinen groeit met elke klant.

Contoso kan ook gebruikmaken van implementatie- of regiospecifieke stemdomeinen, zoals deze:

Als u vervolgens DNS met jokertekens gebruikt, kunnen de DNS-vermeldingen voor deze implementatie er als volgt uitzien:

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

Er zijn voordelen en nadelen voor elke benadering. Wanneer u één stemdomein gebruikt, moet voor elke tenant die u onboardt een nieuwe DNS-record worden gemaakt, waardoor er meer operationele overhead ontstaat. U hebt echter meer flexibiliteit om tenants tussen implementaties te verplaatsen, omdat u de CNAME-record kunt wijzigen om hun verkeer naar een andere implementatie te leiden. Deze wijziging heeft geen invloed op andere tenants. Wanneer u meerdere stemdomeinen gebruikt, is er een lagere beheeroverhead. U kunt ook klantnamen hergebruiken in meerdere regionale stemdomeinen, omdat elk stemdomein effectief 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 opgeven. Hoewel het misschien onbelangrijk lijkt om klanten in staat te stellen om hun eigen domeinnamen mee te nemen, zijn er enkele verborgen complexiteiten aan deze benadering en is een doordachte overweging vereist.

Naamomzetting

Uiteindelijk moet elke domeinnaam worden omgezet in een IP-adres. Zoals u hebt gezien, kan de aanpak voor naamomzetting 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 deze te gebruiken invoices.fabrikam.com als hun aangepaste domeinnaam voor toegang tot de service van Contoso. Omdat Contoso meerdere implementaties van hun multitenant-platform heeft, besluiten ze subdomeinen en CNAME-records te gebruiken om hun routeringsvereisten te bereiken. Contoso en Fabrikam configureren de volgende DNS-records:

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

Oplossing van hostheader

Naamomzetting is slechts de helft van het probleem. Alle webonderdelen in de Europese implementatie van Contoso moeten op de hoogte zijn van het verwerken van aanvragen die binnenkomen met de domeinnaam van Fabrikam in de Host aanvraagheader. Afhankelijk van de specifieke webtechnologieën die Contoso gebruikt, kan dit verdere configuratie vereisen voor de domeinnaam van elke tenant, waardoor extra operationele overhead wordt toegevoegd aan de onboarding van tenants.

U kunt ook overwegen om hostheaders te herschrijven, 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 stuurt 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 hostnamen voor meer informatie.

Domeinvalidatie

Het is belangrijk om het eigendom van aangepaste domeinen te valideren voordat u ze onboardt. Anders riskeer je een klant per ongeluk of kwaadwillend een domeinnaam te parkeren .

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 typefout gemaakt toen ze probeerden de aangepaste domeinnaam te onboarden en ze misten de s. Dus, ze hebben 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 is mogelijk vereist dat de CNAME-records worden ingesteld voordat het domein kan worden toegevoegd. Contoso kan ook een willekeurige tekenreeks genereren en Adventure Works vragen een DNS TXT-record toe te voegen met de tekenreekswaarde. Zo voorkomt u dat de domeinnaam wordt toegevoegd totdat de verificatie is voltooid.

Overnameaanvallen voor DNS- en subdomeinen

Wanneer u met aangepaste domeinnamen werkt, bent u mogelijk kwetsbaar voor een aanvalsklasse genaamd zwevende DNS- of subdomeinovername. Deze aanval treedt op wanneer klanten hun aangepaste domeinnaam loskoppelen van uw service, maar ze verwijderen de record niet van hun DNS-server. 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 om niet langer met Contoso te werken en dus hebben ze hun zakelijke relatie beëindigd.
2. Contoso heeft de Fabrikam-tenant uitgeschakeld en ze hebben gevraagd 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 het de naam fabrikam.
4. De aanvaller onboardt de aangepaste domeinnaam invoices.fabrikam.com naar de nieuwe tenant. Omdat Contoso CNAME-domeinvalidatie uitvoert, controleren ze de DNS-server van Fabrikam. Ze zien dat de DNS-server een CNAME-record retourneert, invoices.fabrikam.comwaarnaar wordt verwezen fabrikam.contoso.com. Contoso beschouwt de validatie van het aangepaste domein als geslaagd.
5. Als fabrikam-werknemers toegang proberen te krijgen tot de site, lijken aanvragen te werken. Als de aanvaller zijn Contoso-tenant instelt met de huisstijl van Fabrikam, kunnen werknemers worden 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 vereist ook dat de tenant een TXT-record maakt met een naam die overeenkomt met de domeinnaam en een willekeurig gegenereerde waarde, die voor elke onboardingpoging verandert.

TLS/SSL-certificaten

Transport Layer Security (TLS) 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 multitenant-toepassingen.

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 zou Fabrikam over het algemeen verantwoordelijk zijn voor het beheren van records voor het fabrikam.com domein, waaronder invoices.fabrikam.com.

Het DNS-recordtype CAA (Autorisatie van certificeringsinstantie) kan worden gebruikt door een domeineigenaar. CAA-records zorgen ervoor dat alleen specifieke autoriteiten 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 het certificaat namens de klant wilt uitgeven of of de klanten hun eigen certificaten moeten meenemen. Elke optie heeft voordelen 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 bij te houden. Als klanten echter CAA-records voor hun domeinnamen hebben, moeten ze u mogelijk autoriseren om namens hen certificaten uit te geven.
• Als u verwacht dat klanten hun eigen certificaten uitgeven en opgeven, bent u verantwoordelijk voor het ontvangen en beheren van de persoonlijke sleutels op een veilige manier. 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. Azure Front Door en App Service bieden bijvoorbeeld certificaten voor aangepaste domeinen en ze verwerken het verlengingsproces automatisch. Dit verwijdert de last van het beheren van certificaten van uw operations-team. U moet echter nog steeds rekening houden met de vraag over 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 worden beheerd door het platform.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• John Downs | Principal Software Engineer

Andere Inzenders:

• Daniel Scott-Raynsford | PartnerTechnologie Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

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

Volgende stappen

Ga terug naar het overzicht van architectuuroverwegingen. Of bekijk het Microsoft Azure Well-Architected Framework.