Överväganden vid användning av domännamn i en lösning med flera klienter

I många webbprogram med flera klienter kan ett domännamn användas som ett sätt att identifiera en klientorganisation, för att hjälpa till med routningsbegäranden till rätt infrastruktur och för att ge kunderna en varumärkesanpassad upplevelse. Två vanliga metoder är att använda underdomäner och anpassade domännamn. På den här sidan ger vi vägledning till tekniska beslutsfattare om de metoder du kan tänka på och deras kompromisser.

Underdomäner

Varje klientorganisation kan få en unik underdomän under ett gemensamt delat domännamn med hjälp av ett format som tenant.provider.com.

Låt oss överväga ett exempel på en lösning för flera klientorganisationer som skapats av Contoso. Kunder köper Contosos produkt för att hantera fakturagenereringen. Alla Contosos klienter kan tilldelas sin egen underdomän under domännamnet contoso.com . Eller om Contoso använder regionala distributioner kan de tilldela underdomäner under us.contoso.com domänerna och eu.contoso.com . I den här artikeln refererar vi till dessa som stamdomäner. Varje kund får sin egen underdomän under din stamdomän. Tailwind Toys kan till exempel tilldelas tailwind.contoso.com, och i en regional distributionsmodell kan Adventure Works tilldelas adventureworks.us.contoso.com.

Hantera ditt domännamnområde

När du skapar underdomäner under ditt eget domännamn måste du vara medveten om att du kan ha flera kunder med liknande namn. Eftersom de delar en enda stamdomän får den första kunden som får en viss domän sitt önskade namn. Därefter måste efterföljande kunder använda alternativa underdomännamn, eftersom fullständiga domännamn måste vara globalt unika.

Dns med jokertecken

Överväg att använda DNS-poster med jokertecken för att förenkla hanteringen av underdomäner. I stället för att skapa DNS-poster för tailwind.contoso.com, adventureworks.contoso.comoch så vidare, kan du i stället skapa en jokerteckenpost för *.contoso.com och dirigera alla underdomäner till en enskild IP-adress (A-post) eller kanoniskt namn (CNAME-post). Om du använder regionala stamdomäner kan du behöva flera jokerteckenposter, till exempel *.us.contoso.com och *.eu.contoso.com.

Underdomäner med stamdomäner med flera delar

Många lösningar för flera klientorganisationer är spridda över flera fysiska distributioner. Det här är en vanlig metod när du behöver uppfylla kraven för datahemvist, eller när du vill ge bättre prestanda genom att distribuera resurser geografiskt närmare användarna.

Även inom en enda region kan du också behöva sprida dina klienter mellan oberoende distributioner för att stödja din skalningsstrategi. Om du planerar att använda underdomäner för varje klientorganisation kan du överväga en underdomänstruktur för flera delar.

Här är ett exempel: Contoso publicerar ett program med flera klientorganisationer för sina fyra kunder. Adventure Works och Tailwind Traders finns i USA och deras data lagras på en delad amerikansk instans av Contoso-plattformen. Fabrikam och Worldwide Importers finns i Europa och deras data lagras på en europeisk instans.

Om Contoso väljer att använda en enda stamdomän contoso.com för alla sina kunder kan det se ut så här:

DNS-posterna (som krävs för att stödja den här konfigurationen) kan se ut så här:

Varje ny kund som registreras kräver en ny underdomän och antalet underdomäner växer med varje kund.

Contoso kan också använda distributions- eller regionspecifika stamdomäner, så här:

Genom att använda jokertecken-DNS kan DNS-posterna för den här distributionen se ut så här:

Contoso behöver inte skapa underdomänposter för varje kund. I stället har de en enda DNS-post med jokertecken för varje geografis distribution, och alla nya kunder som läggs till under den här stammen ärver automatiskt CNAME-posten.

Det finns fördelar och nackdelar med varje metod. När du använder en enda stamdomän kräver varje klientorganisation som du registrerar en ny DNS-post som ger mer driftkostnader. Du har dock större flexibilitet att flytta klientorganisationer mellan distributioner, eftersom du kan ändra CNAME-posten så att trafiken dirigeras till en annan distribution. Den här ändringen påverkar inte andra klienter. När du använder flera stamdomäner finns det lägre hanteringskostnader. Du kan också återanvända kundnamn i flera regionala stamdomäner, eftersom varje stamdomän effektivt representerar sitt eget namnområde.

Egna domännamn

Du kanske vill göra det möjligt för dina kunder att ta med sina egna domännamn. Vissa kunder ser detta som en viktig aspekt av sitt varumärke. Anpassade domännamn kan också krävas för att uppfylla kundernas säkerhetskrav, särskilt om de behöver ange sina egna TLS-certifikat. Även om det kan verka trivialt att göra det möjligt för kunder att ta med sina egna domännamn, finns det vissa dolda komplexiteter i den här metoden, och det kräver tankeväckande övervägande.

Namnmatchning

I slutändan måste varje domännamn matchas till en IP-adress. Som du har sett kan metoden med vilken namnmatchning sker bero på om du distribuerar en enda instans eller flera instanser av din lösning.

Låt oss gå tillbaka till vårt exempel. En av Contosos kunder, Fabrikam, har bett om att få åtkomst invoices.fabrikam.com till Contosos tjänst som sitt anpassade domännamn. Eftersom Contoso har flera distributioner av sin plattform för flera klientorganisationer bestämmer de sig för att använda underdomäner och CNAME-poster för att uppnå sina routningskrav. Contoso och Fabrikam konfigurerar följande DNS-poster:

Ur ett namnmatchningsperspektiv löser den här kedjan av poster korrekt begäranden om till IP-adressen för invoices.fabrikam.com Contosos europeiska distribution.

Matchning av värdhuvud

Namnmatchning är bara hälften av problemet. Alla webbkomponenter i Contosos europeiska distribution måste vara medvetna om hur begäranden som tas emot med Fabrikams domännamn hanteras i begärandehuvudet Host . Beroende på de specifika webbtekniker som Contoso använder kan detta kräva ytterligare konfiguration för varje klientorganisations domännamn, vilket ger extra driftkostnader för registrering av klienter.

Du kan också överväga att skriva om värdhuvuden, så att webbservern ser ett konsekvent rubrikvärde oavsett rubriken för den inkommande begäran Host . Med Azure Front Door kan du till exempel skriva om Host rubriker, så att programservern får ett enda Host huvud oavsett begäran. Azure Front Door sprider den ursprungliga värdrubriken X-Forwarded-Host i rubriken så att programmet kan inspektera det och sedan leta upp klientorganisationen. Om du skriver om en Host rubrik kan det dock orsaka andra problem. Mer information finns i Bevarande av värdnamn.

Domänverifiering

Det är viktigt att verifiera ägarskapet för anpassade domäner innan du registrerar dem. Annars riskerar du att en kund oavsiktligt eller på ett skadligt sätt parkerar ett domännamn.

Låt oss överväga Contosos registreringsprocess för Adventure Works, som har bett om att få använda invoices.adventureworks.com som sitt anpassade domännamn. Tyvärr gjorde någon ett stavfel när de försökte registrera det anpassade domännamnet, och de missade s. Så de konfigurerade det som invoices.adventurework.com. Trafiken flödar inte bara korrekt för Adventure Works, utan när ett annat företag med namnet Adventure Work försöker lägga till sin anpassade domän till Contosos plattform får de veta att domännamnet redan används.

När du arbetar med anpassade domäner, särskilt inom en självbetjäning eller automatiserad process, är det vanligt att kräva ett steg för domänverifiering. Detta kan kräva att CNAME-posterna konfigureras innan domänen kan läggas till. Contoso kan också generera en slumpmässig sträng och be Adventure Works att lägga till en DNS TXT-post med strängvärdet. Det skulle förhindra att domännamnet läggs till tills verifieringen har slutförts.

Dangling DNS- och underdomänövertagandeattacker

När du arbetar med anpassade domännamn är du potentiellt sårbar för en attackklass som kallas dangling DNS eller underdomänövertagande. Den här attacken inträffar när kunder kopplar bort sitt anpassade domännamn från din tjänst, men de tar inte bort posten från sin DNS-server. Den här DNS-posten pekar sedan på en obefintlig resurs och är sårbar för ett övertagande.

Nu ska vi fundera på hur Fabrikams relation med Contoso kan ändras:

1. Fabrikam har beslutat att inte längre arbeta med Contoso, och därför har de avslutat sin affärsrelation.
2. Contoso har avregistrerat Fabrikam-klientorganisationen och begärde fabrikam.contoso.com att inte längre fungera. Fabrikam glömde dock att ta bort CNAME-posten för invoices.fabrikam.com.
3. En illvillig aktör skapar ett nytt Contoso-konto och ger det namnet fabrikam.
4. Angriparen registrerar det anpassade domännamnet invoices.fabrikam.com till sin nya klientorganisation. Eftersom Contoso utför CNAME-baserad domänverifiering kontrollerar de Fabrikams DNS-server. De ser att DNS-servern returnerar en CNAME-post för invoices.fabrikam.com, som pekar på fabrikam.contoso.com. Contoso anser att valideringen av den anpassade domänen är lyckad.
5. Om några Fabrikam-anställda försökte komma åt webbplatsen verkar begäranden fungera. Om angriparen konfigurerar sin Contoso-klientorganisation med Fabrikams varumärke kan anställda luras att komma åt webbplatsen och tillhandahålla känsliga data, som angriparen sedan kan komma åt.

Vanliga strategier för att skydda mot dinglande DNS-attacker är:

• Kräv att CNAME-posten tas bort innan domännamnet kan tas bort från klientorganisationens konto.
• Förhindra återanvändning av klientidentifierare och kräva även att klienten skapar en TXT-post med ett namn som matchar domännamnet och ett slumpmässigt genererat värde, vilket ändras för varje registreringsförsök.

TLS-/SSL-certifikat

Transport Layer Security (TLS) är en viktig komponent när du arbetar med moderna program. Det ger förtroende och säkerhet för dina webbprogram. Ägarskapet och hanteringen av TLS-certifikat är något som måste beaktas noggrant för program med flera klienter.

Vanligtvis ansvarar ägaren av ett domännamn för att utfärda och förnya sina certifikat. Contoso ansvarar till exempel för att utfärda och förnya TLS-certifikat för us.contoso.com, samt ett jokerteckencertifikat för *.contoso.com. På samma sätt skulle Fabrikam vanligtvis ansvara för att hantera alla poster för domänen fabrikam.com , inklusive invoices.fabrikam.com.

DNS-posttypen CAA (Certifikatutfärdarauktorisering) kan användas av en domänägare. CAA-poster säkerställer att endast specifika myndigheter kan skapa certifikat för domänen.

Om du planerar att tillåta kunder att ta med sina egna domäner kan du överväga om du planerar att utfärda certifikatet för kundens räkning eller om kunderna måste ta med sina egna certifikat. Varje alternativ har fördelar och nackdelar:

• Om du utfärdar ett certifikat för en kund kan du hantera förnyelsen av certifikatet så att kunden inte behöver komma ihåg att hålla det uppdaterat. Men om kunderna har CAA-poster på sina domännamn kan de behöva ge dig behörighet att utfärda certifikat för deras räkning.
• Om du förväntar dig att kunderna ska utfärda och förse dig med sina egna certifikat ansvarar du för att ta emot och hantera de privata nycklarna på ett säkert sätt, och du kan behöva påminna dina kunder om att förnya certifikatet innan det upphör att gälla för att undvika avbrott i deras tjänst.

Flera Azure-tjänster stöder automatisk hantering av certifikat för anpassade domäner. Azure Front Door och App Service tillhandahåller till exempel certifikat för anpassade domäner, och de hanterar automatiskt förnyelseprocessen. Detta tar bort ansvaret för att hantera certifikat från ditt driftsteam. Du måste dock fortfarande överväga frågan om ägarskap och auktoritet, till exempel om CAA-poster är i kraft och konfigurerade korrekt. Du måste också se till att dina kunders domäner är konfigurerade för att tillåta de certifikat som hanteras av plattformen.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• John Downs | Huvudprogramtekniker

Övriga medarbetare:

• Daniel Scott-Raynsford | Partnerteknikstrateg
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Gå tillbaka till översikten över arkitekturöverväganden. Eller granska Microsoft Azure Well-Architected Framework.