Överväganden vid användning av domännamn i en lösning för 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 dina kunder en varumärkesupplevelse. 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 domänerna us.contoso.com 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 Adventure Works kan tilldelas adventureworks.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 hämtar en viss domän sitt önskade namn. Sedan måste efterföljande kunder använda alternativa underdomännamn, eftersom fullständiga domännamn måste vara globalt unika.

JOKERTECKEN DNS

Ö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).

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 i en enda region kan du också behöva sprida dina klienter över 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 här 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 ska skapas, vilket medför mer driftkostnader. Du har dock större flexibilitet att flytta klientorganisationer mellan distributioner, eftersom du kan ändra CNAME-posten för att dirigera trafiken 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 för namnmatchning bero på om du distribuerar en enda instans eller flera instanser av din lösning.

Nu ska vi gå tillbaka till vårt exempel. En av Contosos kunder, Fabrikam, har bett att få åtkomst invoices.fabrikam.comtill Contosos tjänst som sitt anpassade domännamn. Eftersom Contoso har flera distributioner av sin plattform 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 postkedjan 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, oavsett begäran, får ett enda Host huvud. Azure Front Door sprider det ursprungliga värdhuvudet i X-Forwarded-Host huvudet 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änvalidering

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.

Nu ska vi ö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 dinglande 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 inte tar bort posten från sin DNS-server. Den här DNS-posten pekar sedan på en resurs som inte finns och är sårbar för ett övertagande.

Låt oss överväga 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 tagit bort Fabrikam-klientorganisationen och begärt 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änvalidering 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ärkesanpassning 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äver ä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. Ägarskap och hantering av TLS-certifikat är något som måste övervägas 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 (Certificate Authority Authorization) 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 bör 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å kunden behöver inte 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 kunder 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 tjänsten.

Flera Azure-tjänster stöder automatisk hantering av certifikat för anpassade domäner. Azure Front Door och App Service till exempel tillhandahålla certifikat för anpassade domäner, och de hanterar automatiskt förnyelseprocessen. Detta tar bort bördan av 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. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

• John Downs | Huvudkundtekniker, FastTrack för Azure

Andra deltagare:

• 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.