Co je třeba zvážit při použití názvů domén ve víceklientském řešení
V mnoha webových aplikacích s více klienty se dá název domény použít jako způsob identifikace tenanta, pro usnadnění požadavků na směrování a poskytování zkušeností pro vaše zákazníky. Existují dva běžné přístupy k použití subdomén a názvů vlastních domén.
Subdomén
Každý tenant může získat jedinečnou subdoménu pod běžným názvem sdílené domény. Podívejme se na ukázkové řešení víceklientské architektury sestavené společností contoso. Zákazníci si nakupují produkt společnosti Contoso, aby mohli spravovat jejich generování faktury. Všem klientům společnosti Contoso může být v rámci názvu domény přiřazena vlastní subdoména contoso.com . Nebo pokud používáte regionální nasazení, můžete přiřadit subdomény v us.contoso.com eu.contoso.com doménách a. V tomto článku se na ně odkazuje jako na domény kmenů. Každý zákazník získá svoji vlastní subdoménu do vaší domény kmene. Můžete například přiřadit Tailwind Toys tailwind.contoso.com a společnosti Adventure Works adventureworks.contoso.com .
Poznámka
Tento přístup využívá řada služeb Azure. Když například vytvoříte účet úložiště Azure, přiřadí se mu sada subdomén, kterou můžete použít, například <your account name>.blob.core.windows.net .
Správa oboru názvů domén
Při vytváření subdomén v rámci vlastního názvu domény je nutné mít na vědomí, že můžete mít více zákazníků s podobnými názvy. Vzhledem k tomu, že sdílí jednu doménu se systémem, první zákazník získá konkrétní doménu a další zákazníci budou muset použít alternativní názvy subdomén, protože úplné názvy domén musí být globálně jedinečné.
DNS se zástupnými znaky
Zvažte použití položek DNS se zástupnými znaky ke zjednodušení správy subdomén. Místo vytváření záznamů DNS pro, tailwind.contoso.com a adventureworks.contoso.com tak můžete místo toho vytvořit položku se zástupnými znaky pro *.contoso.com všechny subdomény a SMĚROVAT na jednu IP adresu (záznam) nebo kanonický název (záznam CNAME).
Poznámka
Pokud se budete chtít spoléhat na tuto funkci, ujistěte se, že vaše služby webové vrstvy podporují DNS se zástupnými znaky. Mnoho služeb Azure, včetně front-bran Azure a Azure App Service, podporuje položky DNS se zástupnými znaky.
Subdomény s doménami kmenů v částech
Mnoho víceklientské řešení je rozděleno mezi několik fyzických nasazení. To je běžné, pokud potřebujete dodržovat požadavky na data, nebo pokud chcete zajistit lepší výkon nasazením prostředků geograficky blíž k uživatelům. I v rámci jedné oblasti může být také nutné rozložit klienty v různých nasazeních, a to v rámci vaší strategie škálování. Pokud máte v úmyslu použít subdomény pro každého tenanta, můžete uvažovat o struktuře subdomén v různých částech.
Tady je příklad: contoso zveřejňuje víceklientské aplikace pro čtyři zákazníky. Adventure Works a Tailwind obchodníci jsou v USA a jejich data jsou uložená na sdílené instanci US platformy contoso. Vydavatelé Fabrikam a celosvětově jsou v Evropě a jejich data se ukládají na Evropskou instanci.
Pokud společnost Contoso zvolí pro všechny své zákazníky jednu doménu contoso.com, bude to vypadat nějak takto:

Položky DNS (které jsou nutné k podpoře této konfigurace) můžou vypadat takto:
| Subdoména | CNAME na |
|---|---|
adventureworks.contoso.com |
us.contoso.com |
tailwind.contoso.com |
us.contoso.com |
fabrikam.contoso.com |
eu.contoso.com |
worldwideimporters.contoso.com |
eu.contoso.com |
Každý nově zaregistrované zákazníky vyžaduje novou subdoménu a počet subdomén se v jednotlivých zákaznících rozroste.
Společnost Contoso může alternativně používat domény ve standardu pro nasazení nebo konkrétní oblast, jako je tato:

Položky DNS pro toto nasazení můžou vypadat takto:
| Subdoména | CNAME na |
|---|---|
*.us.contoso.com |
us.contoso.com |
*.eu.contoso.com |
eu.contoso.com |
Contoso nemusí vytvářet záznamy subdomény pro každého zákazníka. Místo toho mají jeden zástupný znak DNS pro každé nasazení geografické oblasti a všichni noví zákazníci, kteří byli přidáni pod tuto stopu, automaticky zdědí záznam CNAME.
Každý přístup přináší výhody a nevýhody. Pokud používáte jednu doménu se systémem, každý tenant, který zahájíte, vyžaduje vytvoření nového záznamu DNS, který přináší větší provozní režii. Máte ale větší flexibilitu, pokud potřebujete přesunout klienty mezi nasazeními, protože záznam CNAME můžete změnit tak, aby se provoz směroval na jiné nasazení. To nebude mít vliv na žádné další klienty. Pokud používáte více domén kmenů, existuje nižší režijní náklady na správu a můžete opakovaně používat názvy zákazníků v rámci několika regionálních domén kmenů, protože každý z nich efektivně představuje vlastní obor názvů.
Vlastní názvy domén
Možná budete chtít zákazníkům povolit, aby si přenesli vlastní názvy domén. Někteří zákazníci to uvidí jako důležitý aspekt jejich brandingu. Může být taky nutné splnit požadavky zákazníků na zabezpečení, zejména v případě, že potřebují zadat vlastní certifikáty TLS. I když se může zdát, že zákazníkům umožňuje přenášet si své vlastní názvy domén, existují určité skryté složitosti tohoto přístupu a vyžaduje zvážení důkladné.
Překlad adres
Nakonec je potřeba přeložit každý název domény na IP adresu. Jak jste viděli, přístup k tomuto chování může záviset na tom, jestli nasazujete jednu instanci nebo víc instancí svého řešení.
Pojďme se vrátit na náš příklad. Jeden ze zákazníků společnosti Contoso, který požádal o použití invoices.fabrikam.com , jako vlastní název domény pro přístup ke službě společnosti Contoso. Vzhledem k tomu, že společnost Contoso má více nasazení svých platforem, rozhodnou se pro dosažení požadavků na směrování použití subdomén a záznamů CNAME. Společnosti Contoso a Fabrikam nakonfigurují následující záznamy DNS:
| Name | Typ záznamu | Hodnota | Kde se provádí konfigurace |
|---|---|---|---|
invoices.fabrikam.com |
CNAME | fabrikam.eu.contoso.com |
Fabrikam |
*.eu.contoso.com |
CNAME | eu.contoso.com |
Contoso |
eu.contoso.com |
A | (IP adresa společnosti Contoso) | Contoso |
Z perspektivy překladu názvů tento řetězec záznamů přesně řeší požadavky na invoices.fabrikam.com IP adresu Evropského nasazení společnosti Contoso.
Rozlišení hlavičky hostitele
Překlad názvů je jenom polovina problému. Všechny webové součásti (v rámci Evropského nasazení společnosti Contoso) potřebují vědět, jak zpracovávat požadavky, které dorazí s názvem domény společnosti Fabrikam do své Host hlavičky žádosti. V závislosti na konkrétních webových technologiích, které společnost Contoso používá, to může vyžadovat další konfiguraci pro každý název domény tenanta, což zvyšuje provozní režii do zprovoznění klientů.
Můžete také zvážit přepsání hlaviček hostitele, takže bez ohledu na hlavičku příchozího požadavku Host webový server uvidí konzistentní hodnotu hlavičky. Například přední dvířka Azure umožňují přepsat Host hlavičky, takže bez ohledu na požadavek obdrží aplikační server jednu Host hlavičku. Přední dvířka Azure šíří původní hlavičku hostitele v X-Forwarded-Host hlavičce, takže ji vaše aplikace může zkontrolovat a vyřešit tak klienta.
Ověřování domény
Před registrací je důležité ověřit vlastnictví vlastních domén. Jinak riskujete, že zákazník omylem nebo záměrně zaparkuje název domény.
Podívejme se na proces zprovoznění společnosti Contoso pro Adventure Works, který požádal o použití invoices.adventureworks.com jako svůj vlastní název domény. Někdo bohužel překlepal při pokusu o připojení vlastního názvu domény a vynechal . Proto je nastaví jako invoices.adventurework.com . Bez toku přenosů nefunguje správně, ale pokud se jiná společnost s názvem Adventure Works pokusí přidat svou vlastní doménu na platformu společnosti Contoso, sdělí to, že název domény se už používá.
Při práci s vlastními doménami, zejména v rámci samoobslužné nebo automatizovaného procesu, je běžné vyžadovat krok ověření domény. To může vyžadovat, aby byly záznamy CNAME nastaveny před tím, než bude možné doménu přidat. Společnost Contoso může alternativně generovat náhodný řetězec a zeptat se na Adventure Works a přidat záznam TXT DNS s řetězcovou hodnotou. Tím se zabrání přidání názvu domény do doby, než se ověření dokončí.
Dangling útoky DNS a subdomén převzetí
Když pracujete s vlastními názvy domén, můžete být zranitelní vůči napadení třídy s názvem dangling DNS nebo převzetí subdomény. K tomuto útoku dochází, když zákazníci ztratí přidružení vlastního názvu domény z vaší služby, ale neodstraňují záznam ze svého serveru DNS. Tato položka DNS pak odkazuje na neexistující prostředek a je zranitelná vůči převzetí.
Pojďme se rozhodnout, jak se může stát, že se vztah společnosti Fabrikam se společností Contoso změní:
- Společnost Fabrikam se rozhodla, že přestane fungovat se společností Contoso, a proto ukončila své obchodní vztahy.
- Společnost Contoso offboarded tenanta Fabrikam a požadovala,
fabrikam.contoso.comaby už nefungovala. Společnost Fabrikam ale zapomněla odstranit záznam CNAME proinvoices.fabrikam.com. - Aktér se zlými úmysly vytvoří nový účet Contoso a pojme ho
fabrikam. - Útočník vlastní název domény onboarduje do
invoices.fabrikam.comnového tenanta. Vzhledem k tomu, že Společnost Contoso provádí ověřování domény založené na CNAME, zkontroluje server DNS společnosti Fabrikam. Uvidí, že server DNS vrací záznam CNAME proinvoices.fabrikam.com, který odkazuje nafabrikam.contoso.com. Společnost Contoso považuje ověření vlastní domény za úspěšné. - Pokud se některý ze zaměstnanců společnosti Fabrikam pokusil o přístup k webu, zdá se, že žádosti fungují. Pokud útočník nastaví tenanta společnosti Contoso pomocí brandingu společnosti Fabrikam, můžou být zaměstnanci oklamaní při přístupu k webu a poskytování citlivých dat, ke kterým pak může útočník získat přístup.
Běžnou strategií pro ochranu před nesnášejícími útoky DNS je vyžadování odstranění záznamu CNAME před odebráním názvu domény z účtu tenanta. Můžete také zvážit zákaz opakovaného použití identifikátorů tenanta a pak můžete posílit proces onboardingu vlastní domény pomocí náhodně generovaného záznamu TXT (který se pro každý pokus o registraci liší).
Certifikáty TLS/SSL
Protokol TLS (Transport Layer Security) je důležitou součástí při práci s moderními aplikacemi. Poskytuje vašim webovým aplikacím vztah důvěryhodnosti a zabezpečení. Vlastnictví a správa certifikátů TLS je něco, co je potřeba pečlivě zvážit pro vícetenantové aplikace.
Za vystavování a obnovení certifikátů obvykle zodpovídá vlastník názvu domény. Společnost Contoso například zodpovídá za vystavování a obnovování certifikátů TLS pro a také za certifikát se zástupnými us.contoso.com znaky pro *.contoso.com . Podobně by společnost Fabrikam obecně zodpovědná za správu všech záznamů pro fabrikam.com doménu, včetně invoices.fabrikam.com . Typ záznamu DNS CAA (Certificate Authority Authorization) může používat vlastník domény, aby se zajistilo, že certifikáty pro svou doménu mohou vytvářet jenom konkrétní autority.
Pokud chcete zákazníkům umožnit, aby si přinesli vlastní domény, zvažte, jestli plánujete certifikát vydat jménem zákazníka, nebo jestli zákazníci musí přinést vlastní certifikáty. Každá možnost má výhody a nevýhody. Pokud vydáte certifikát pro zákazníka, můžete zpracovat jeho obnovení, takže si ho nemusí pamatovat. Pokud ale zákazníci mají ve svých názvech domén záznamy CAA, možná vás budou muset autorizovat k vydávání certifikátů jejich jménem. Pokud očekáváte, že zákazníci budou vydávat a poskytovat vám vlastní certifikáty, zodpovídáte za zabezpečené přijímání a správu privátních klíčů a možná budete muset zákazníky připomenout, aby si certifikát před vypršením jeho platnosti obnovili, abyste se vyhnuli přerušení jejich služby.
Několik služeb Azure podporuje automatickou správu certifikátů pro vlastní domény. Například Azure Front Door a App Service certifikáty pro vlastní domény a automaticky zpracovávají proces prodloužení platnosti. Tím se zbavíte zátěže spojené se správou certifikátů od provozního týmu. Stále ale musíte zvážit otázku vlastnictví a autority, například jestli jsou záznamy CAA aktivní a správně nakonfigurované. Musíte také zajistit, aby domény vašich zákazníků byly nakonfigurované tak, aby povoloval certifikáty spravované platformou.
Další kroky
Vraťte se k přehledu architektonických informací. Nebo si prohlédněte Microsoft Azure Well-Architected Framework.