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 routeringsaanvragen en om uw klanten een merkervaring te bieden. Twee algemene benaderingen zijn het gebruik van subdomeinen en aangepaste domeinnamen.

Subdomeinen

Elke tenant krijgt mogelijk een uniek subdomein onder een algemene gedeelde domeinnaam. 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 contoso.com de domeinnaam. Of als u regionale implementaties gebruikt, kunt u subdomeinen toewijzen onder de us.contoso.com eu.contoso.com domeinen en . In dit artikel verwijzen we hier naar als stemdomeinen. Elke klant krijgt zijn eigen subdomein onder uw stemdomein. Tailwind Toys kan bijvoorbeeld worden toegewezen tailwind.contoso.com en Adventure Works kan worden adventureworks.contoso.com toegewezen.

Uw domeinnaamruimte beheren

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

Wildcard DNS

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

Subdomeinen met meerdelige stemdomeinen

Veel multitenant-oplossingen zijn verdeeld over meerdere fysieke implementaties. Dit komt vaak voor wanneer u moet voldoen aan de vereisten voor gegevensstatus of wanneer u betere prestaties wilt leveren door resources geografisch dichter bij de gebruikers te implementeren. Zelfs binnen één regio moet u uw tenants mogelijk ook over onafhankelijke implementaties verspreiden als onderdeel van uw schaalstrategie. Als u van plan bent om subdomeinen te gebruiken voor elke tenant, kunt u een subdomeinstructuur met meerdere onderdelen overwegen.

Hier is een voorbeeld: Contoso publiceert een multitenant-toepassing voor de vier klanten. Adventure Works en Tailwind Traders zijn in de Verenigde Staten en hun gegevens worden opgeslagen op een gedeeld Exemplaar van de Verenigde Staten van het Contoso-platform. Fabrikam en Worldwide Importers zijn in Europa en hun gegevens worden opgeslagen op een Europese instantie.

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

De DNS-vermeldingen (die vereist zijn voor de ondersteuning van deze configuratie) kunnen er als volgende uitzien:

Voor elke nieuwe klant die wordt onboarding is een nieuw subdomein vereist en het aantal subdomeinen neemt met elke klant toe.

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

De DNS-vermeldingen voor deze implementatie kunnen er als volgende 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. Nieuwe klanten die onder die stem worden toegevoegd, nemen automatisch de CNAME-record over.

Elke benadering heeft voor- en nadelen. Wanneer u één stemdomein 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 als u tenants tussen implementaties wilt verplaatsen, omdat u de CNAME-record kunt wijzigen om hun verkeer om te leiden naar een andere implementatie. Dit heeft geen invloed op andere tenants. Wanneer u meerdere stemdomeinen gebruikt, is er een lagere beheeroverhead en kunt u klantnamen hergebruiken in meerdere regionale stemdomeinen, omdat elk domein 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. Het kan ook vereist zijn om te voldoen aan de beveiligingsvereisten van klanten, met name als ze hun eigen TLS-certificaten moeten leveren. Hoewel het misschien niet eenvoudig lijkt om klanten in staat te stellen hun eigen domeinnamen mee te nemen, zijn er enkele verborgen complexiteiten in deze benadering en is een zorgvuldige overweging vereist.

Naamomzetting

Uiteindelijk moet elke domeinnaam worden omgeslagen in een IP-adres. Zoals u hebt gezien, kan de manier waarop dit gebeurt, afhankelijk zijn van het implementeren van één exemplaar of meerdere exemplaren van uw oplossing.

Laten we terugkeren naar ons voorbeeld. Een van de klanten van Contoso, Fabrikam, heeft gevraagd om , als aangepaste domeinnaam te gebruiken voor toegang tot invoices.fabrikam.com de service van Contoso. Omdat Contoso meerdere implementaties van hun 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 naamomzet worden met deze recordsketen aanvragen voor nauwkeurig opgelost naar het IP-adres van de Europese implementatie invoices.fabrikam.com van Contoso.

Hostheaderresolutie

Naamoplossing is slechts de helft van het probleem. Alle webonderdelen (binnen de Europese implementatie van Contoso) moeten zich bewust zijn van het verwerken van aanvragen die binnenkomen met de domeinnaam van Fabrikam in hun 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 te herschrijven, zodat uw webserver een consistente headerwaarde ziet, ongeacht de header van de Host binnenkomende aanvraag. Met Azure Front Door kunt u bijvoorbeeld headers herschrijven, zodat uw toepassingsserver, ongeacht de aanvraag, één Host Host header ontvangt. Azure Front Door de oorspronkelijke hostheader door in de header, zodat uw toepassing deze kan X-Forwarded-Host inspecteren, om de tenant om te lossen.

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 kwaadwillende bedoelingen een domeinnaam in het spel heeft.

Laten we eens kijken naar het onboardingproces van Contoso voor Adventure Works, dat heeft gevraagd om te gebruiken als invoices.adventureworks.com aangepaste domeinnaam. Helaas heeft iemand een typefout gemaakt toen hij probeerde de aangepaste domeinnaam te onboarden en de s over het hoofd kreeg. Daarom stellen ze deze in als invoices.adventurework.com . Niet alleen stroomt het verkeer niet goed, maar wanneer een ander bedrijf met de naam Adventure Work probeert het aangepaste domein toe te voegen aan het platform van Contoso, wordt hen verteld 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 stap voor domeinverificatie te vereisen. Dit kan vereisen dat de CNAME-records worden ingesteld 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. Zo voorkomt u dat de domeinnaam wordt toegevoegd, totdat de verificatie is voltooid.

Dansbare DNS- en subdomeinovernameaanvallen

Wanneer u met aangepaste domeinnamen werkt, bent u mogelijk kwetsbaar voor een aanvalsklasse met de naam danings-DNS of overname van subdomeinen. Deze aanval teert wanneer klanten hun aangepaste domeinnaam loskoppelen van uw service, maar ze de record niet van hun DNS-server verwijderen. Deze DNS-vermelding wijst 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 te werken en heeft daarom de bedrijfsrelatie beëindigd.
2. Contoso heeft de Fabrikam-tenant ge-offboard en gevraagd om fabrikam.contoso.com niet meer te werken. Fabrikam is echter vergeten om de CNAME-record voor te invoices.fabrikam.com verwijderen.
3. Een kwaadwillende actor maakt een nieuw Contoso-account en geeft dit account de naam fabrikam .
4. De aanvaller onboardt de aangepaste domeinnaam invoices.fabrikam.com naar de nieuwe tenant. Omdat Contoso domeinvalidatie op basis van CNAME uitvoert, controleren ze de DNS-server van Fabrikam. Ze zien dat de DNS-server een CNAME-record retourneert voor invoices.fabrikam.com , die naar fabrikam.contoso.com wijst. Contoso beschouwt de validatie van het aangepaste domein als geslaagd.
5. Als werknemers van Fabrikam proberen toegang te krijgen tot de site, lijken aanvragen te werken. Als de aanvaller zijn Contoso-tenant in de huisstijl van Fabrikam in stelt, worden werknemers mogelijk voor de gek gehouden om toegang te krijgen tot de site en gevoelige gegevens op te geven, die de aanvaller vervolgens kan openen.

Een veelgebruikte strategie om u te beschermen tegen een paarde DNS-aanvallen is te vereisen dat de CNAME-record wordt verwijderd voordat de domeinnaam kan worden verwijderd uit het account van de tenant. U kunt ook overwegen om het hergebruik van tenant-id's te verbieden en vervolgens het onboardingproces voor uw aangepaste domein te versterken met behulp van een willekeurig gegenereerde TXT-record (die voor elke onboardingpoging anders is).

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 , evenals een us.contoso.com jokertekencertificaat voor *.contoso.com . Fabrikam is in het algemeen ook verantwoordelijk voor het beheren van records voor het fabrikam.com domein, waaronder invoices.fabrikam.com . Het DNS-recordtype CAA (Certificate Authority Authorization) kan worden gebruikt door een domeineigenaar om ervoor te zorgen dat alleen specifieke instanties certificaten voor hun 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 dat de klanten hun eigen certificaten moeten meenemen. Elke optie heeft voor- en nadelen. Als u een certificaat voor een klant uit geeft, kunt u de verlenging van het certificaat afhandelen, zodat de klant niet hoeft te onthouden dat het bijgewerkt blijft. Als de klanten echter CAA-records op 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 verstrekken, bent u verantwoordelijk voor het op een veilige manier ontvangen en beheren van de persoonlijke sleutels. Mogelijk moet u uw klanten eraan herinneren het certificaat te vernieuwen voordat het verloopt, om onderbreking van hun service te voorkomen.

Verschillende Azure-services ondersteunen automatisch beheer van certificaten voor aangepaste domeinen. Zo bieden Azure Front Door App Service certificaten voor aangepaste domeinen en verwerken ze automatisch het vernieuwingsproces. Hiermee wordt de last van het beheren van certificaten van uw operationele team verwijderd. 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. Bovendien moet u ervoor zorgen dat de domeinen van uw klanten zijn geconfigureerd om de certificaten toe te staan die door het platform worden beheerd.

Volgende stappen

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