Megfontolandó szempontok tartománynevek több-bérlős megoldásban való használatakor

Számos több-bérlős webalkalmazásban a tartománynév használható a bérlő azonosítására, a kérések megfelelő infrastruktúrába való irányítására, valamint az ügyfeleknek nyújtott védjegyes élmény biztosítására. Két gyakori módszer az altartományok és az egyéni tartománynevek használata. Ezen az oldalon útmutatást nyújtunk a műszaki döntéshozóknak a megfontolható megközelítésekről és azok kompromisszumairól.

Aldomain

Előfordulhat, hogy minden bérlő egyedi altartományt kap egy közös megosztott tartománynév alatt, olyan formátumban, mint a tenant.provider.com.

Vegyünk egy példát a Contoso által létrehozott több-bérlős megoldásra. Az ügyfelek megvásárolják a Contoso termékét, hogy segítsenek kezelni a számlagenerálást. Előfordulhat, hogy a Contoso összes bérlője saját altartományt rendel hozzá a contoso.com tartománynév alatt. Vagy ha a Contoso regionális üzemelő példányokat használ, altartományokat rendelhet hozzá a és eu.contoso.com a us.contoso.com tartományokhoz. Ebben a cikkben szártartományként hivatkozunk ezekre. Minden ügyfél saját altartományt kap a törzstartománya alatt. Előfordulhat például, hogy a Tailwind Toys hozzá van rendelve tailwind.contoso.com, és az Adventure Works is hozzárendelhető adventureworks.contoso.com.

Tartománynévtér kezelése

Amikor altartományokat hoz létre a saját tartományneve alatt, figyelembe kell vennie, hogy több, hasonló nevű ügyfele is lehet. Mivel egyetlen törzstartományt osztanak meg, az első ügyfél, aki egy adott tartományt kap, megkapja az előnyben részesített nevet. Ezután a későbbi ügyfeleknek alternatív altartományneveket kell használniuk, mivel a teljes tartományneveknek globálisan egyedinek kell lenniük.

Helyettesítő DNS

Fontolja meg helyettesítő DNS-bejegyzések használatát az altartományok kezelésének egyszerűsítéséhez. Ahelyett, hogy DNS-bejegyzéseket hozna létre a tailwind.contoso.com, adventureworks.contoso.comés így tovább, létrehozhat helyettesítő karaktereket *.contoso.com az altartományokhoz, és az összes altartományt egyetlen IP-címre (A rekordra) vagy canonikus névre (CNAME rekord) irányíthatja.

Többrészes szártartományokkal rendelkező altartományok

Számos több-bérlős megoldás több fizikai üzembe helyezésre is kiterjed. Ez gyakori módszer, ha meg kell felelnie az adattárolási követelményeknek, vagy ha jobb teljesítményt szeretne nyújtani az erőforrások felhasználókhoz földrajzilag közelebbi üzembe helyezésével.

A skálázási stratégia támogatásához akár egyetlen régión belül is el kell osztania a bérlőket a független üzemelő példányok között. Ha altartományokat tervez használni az egyes bérlőkhöz, érdemes lehet többrészes altartománystruktúrát is figyelembe vennie.

Íme egy példa: A Contoso egy több-bérlős alkalmazást tesz közzé négy ügyfele számára. Az Adventure Works és a Tailwind Traders a Egyesült Államok található, és az adataik a Contoso platform megosztott AMERIKAI példányán vannak tárolva. A Fabrikam és a Worldwide Importers Európában található, adataikat pedig egy európai példány tárolja.

Ha a Contoso egyetlen szártartományt használ, contoso.com az összes ügyfél számára, a következőképpen nézhet ki:

A (konfiguráció támogatásához szükséges) DNS-bejegyzések a következőképpen nézhetnek ki:

Minden előkészített új ügyfélnek új altartományra van szüksége, és az altartományok száma az egyes ügyfeleknél növekszik.

Alternatív megoldásként a Contoso üzembe helyezési vagy régióspecifikus törzstartományokat is használhat, például a következőket:

Ezután helyettesítő DNS használatával az üzembe helyezés DNS-bejegyzései a következőképpen néznek ki:

A Contosónak nem kell altartományrekordokat létrehoznia minden ügyfél számára. Ehelyett egyetlen helyettesítő DNS-rekordot használnak az egyes földrajzi helyek üzembe helyezéséhez, és minden új ügyfél, aki a törzs alá kerül, automatikusan örökli a CNAME rekordot.

Az egyes megközelítéseknek vannak előnyei és hátrányai. Egyetlen törzstartomány használata esetén minden előkészített bérlőnek létre kell hoznia egy új DNS-rekordot, ami nagyobb működési többletterhelést jelent. Azonban rugalmasabban helyezheti át a bérlőket az üzemelő példányok között, mivel a CNAME rekordot úgy módosíthatja, hogy a forgalmat egy másik üzembe helyezésre irányítsa. Ez a módosítás nem érinti a többi bérlőt. Több őstartomány használata esetén alacsonyabb a felügyeleti többletterhelés. Emellett több regionális törzstartományban is újra felhasználhatja az ügyfélneveket, mivel minden egyes törzstartomány hatékonyan képviseli a saját névterét.

Egyéni tartománynevek

Előfordulhat, hogy engedélyezni szeretné az ügyfelek számára a saját tartományneveiket. Egyes ügyfelek ezt a márkaépítés fontos aspektusának tekintik. Egyéni tartománynevekre is szükség lehet az ügyfelek biztonsági követelményeinek való megfeleléshez, különösen akkor, ha saját TLS-tanúsítványokat kell szolgáltatniuk. Bár triviálisnak tűnhet, ha lehetővé teszi az ügyfelek számára, hogy saját tartományneveket használjanak, van néhány rejtett összetettség ebben a megközelítésben, és átgondolt megfontolást igényel.

Névfeloldás

Végső soron minden tartománynevet fel kell oldani egy IP-címre. Amint azt már láthatta, a névfeloldás módszere attól függ, hogy a megoldás egyetlen példányát vagy több példányát helyezi üzembe.

Térjünk vissza a példához. A Contoso egyik ügyfele, a Fabrikam kérte, hogy egyéni tartománynévként használja invoices.fabrikam.coma Contoso szolgáltatásának elérését. Mivel a Contoso több üzembe helyezéssel rendelkezik a platformon, úgy döntenek, hogy altartományokat és CNAME rekordokat használnak az útválasztási követelmények teljesítéséhez. A Contoso és a Fabrikam a következő DNS-rekordokat konfigurálja:

Névfeloldási szempontból ez a rekordlánc pontosan megoldja a Contoso európai üzemelő példányának IP-címére irányuló invoices.fabrikam.com kérelmeket.

Gazdagépfejfeloldás

A névfeloldás csak a probléma fele. A Contoso európai üzemelő példányán belüli összes webes összetevőnek tisztában kell lennie azzal, hogyan kell kezelni a Fabrikam tartománynevével érkező kéréseket a kérés fejlécében Host . A Contoso által használt konkrét webes technológiáktól függően ez további konfigurációt igényelhet az egyes bérlők tartománynevéhez, ami további működési többletterhelést okoz a bérlők előkészítésében.

A gazdagépfejlécek újraírását is megfontolhatja, hogy a bejövő kérés Host fejlécétől függetlenül a webkiszolgáló egységes fejlécértéket lát. Az Azure Front Door például lehetővé teszi a fejlécek átírását Host , így a kéréstől függetlenül az alkalmazáskiszolgáló egyetlen Host fejlécet kap. Az Azure Front Door propagálja az eredeti gazdagépfejlécet a X-Forwarded-Host fejlécben, hogy az alkalmazás megvizsgálhassa, majd megkereshesse a bérlőt. A fejléc újraírása Host azonban más problémákat okozhat. További információ: Állomásnév megőrzése.

Tartomány érvényesítése

Az előkészítés előtt fontos ellenőrizni az egyéni tartományok tulajdonjogát. Ellenkező esetben azt kockáztatja, hogy egy ügyfél véletlenül vagy rosszindulatúan parkol egy tartománynéven.

Tekintsük át a Contoso előkészítési folyamatát az Adventure Works számára, akik egyéni tartománynévként kérték fel invoices.adventureworks.com őket. Sajnos valaki elírást csinált, amikor megpróbálta előkészíteni az egyéni tartománynevet, és elmulasztotta az s-t. Tehát úgy állítják be, hogy invoices.adventurework.com. Nem csak a forgalom nem halad megfelelően az Adventure Works esetében, de amikor egy másik , Adventure Work nevű vállalat megpróbálja hozzáadni az egyéni tartományát a Contoso platformjára, azt mondják, hogy a tartománynév már használatban van.

Ha egyéni tartományokkal dolgozik, különösen egy önkiszolgáló vagy automatizált folyamaton belül, gyakori, hogy tartomány-ellenőrzési lépésre van szükség. Ehhez szükség lehet a CNAME rekordok beállítására a tartomány hozzáadása előtt. Másik lehetőségként a Contoso létrehozhat egy véletlenszerű sztringet, és megkérheti az Adventure Workset, hogy adjon hozzá egy DNS TXT rekordot a sztringértékkel. Ez megakadályozza a tartománynév hozzáadását, amíg az ellenőrzés be nem fejeződik.

Dangling DNS- és altartomány-átvételi támadások

Ha egyéni tartománynevekkel dolgozik, potenciálisan sebezhetővé válik a dangling DNS-nek vagy altartomány-átvételnek nevezett támadási osztálynak. Ez a támadás akkor fordul elő, ha az ügyfelek leválasztják az egyéni tartománynevüket a szolgáltatásról, de nem törlik a rekordot a DNS-kiszolgálójukról. Ez a DNS-bejegyzés ezután egy nem létező erőforrásra mutat, és sebezhető az átvétellel szemben.

Tekintsük át, hogyan változhat fabrikam és Contoso kapcsolata:

1. A Fabrikam úgy döntött, hogy nem dolgozik tovább a Contosóval, ezért megszüntették az üzleti kapcsolatukat.
2. A Contoso kiveszette a Fabrikam-bérlőt, és azt kérték fabrikam.contoso.com , hogy ne működjön tovább. A Fabrikam azonban elfelejtette törölni a CNAME rekordot a következőhöz: invoices.fabrikam.com.
3. Egy rosszindulatú szereplő létrehoz egy új Contoso-fiókot, és megadja neki a nevet fabrikam.
4. A támadó előkészíti az egyéni tartománynevet invoices.fabrikam.com az új bérlőnek. Mivel a Contoso CNAME-alapú tartományérvényesítést végez, ellenőrzik a Fabrikam DNS-kiszolgálóját. Azt látják, hogy a DNS-kiszolgáló egy CNAME rekordot ad vissza, invoices.fabrikam.comamely a következőre fabrikam.contoso.commutat: . A Contoso sikeresnek tartja az egyéni tartományérvényesítést.
5. Ha a Fabrikam bármely alkalmazottja megpróbál hozzáférni a webhelyhez, úgy tűnik, hogy a kérések működnek. Ha a támadó a Fabrikam márkajelzésével állítja be a Contoso-bérlőt, előfordulhat, hogy az alkalmazottakat megtévesztik, hogy hozzáférnek a webhelyhez, és bizalmas adatokat szolgáltatnak, amelyekhez a támadó ezután hozzáférhet.

A dangling DNS-támadások elleni védelem gyakori stratégiái a következők:

• A CNAME rekord törlésének megkövetelése ahhoz, hogy a tartománynév eltávolítható legyen a bérlő fiókjából.
• Tiltsa meg a bérlőazonosítók újbóli használatát, és azt is megköveteli, hogy a bérlő hozzon létre egy TXT rekordot a tartománynévnek megfelelő névvel és egy véletlenszerűen létrehozott értékkel, amely minden előkészítési kísérletnél megváltozik.

TLS-/SSL-tanúsítványok

A Transport Layer Security (TLS) a modern alkalmazások használata során alapvető fontosságú összetevő. Megbízhatóságot és biztonságot nyújt a webalkalmazások számára. A TLS-tanúsítványok tulajdonjoga és kezelése olyan dolog, amelyet alaposan meg kell vizsgálni a több-bérlős alkalmazások esetében.

A tartománynév tulajdonosa általában felelős a tanúsítványok kiállításáért és megújításáért. A Contoso például a TLS-tanúsítványok us.contoso.comkiadásáért és megújításáért, valamint a helyettesítő tanúsítványért *.contoso.comfelel. Hasonlóképpen, a Fabrikam általában a tartomány összes rekordjának kezeléséért felel, beleértve a fabrikam.com rekordokat is invoices.fabrikam.com. A HITELESÍTÉSSZOLGÁLTATÓ (hitelesítésszolgáltatói engedély) DNS-rekordtípusát a tartománytulajdonos használhatja. A hitelesítésszolgáltatói rekordok biztosítják, hogy csak bizonyos hatóságok hozzanak létre tanúsítványokat a tartományhoz.

Ha azt tervezi, hogy lehetővé teszi az ügyfelek számára, hogy saját tartományokat hozzanak létre, fontolja meg, hogy a tanúsítványt az ügyfél nevében kívánja-e kiadni, vagy hogy az ügyfeleknek saját tanúsítványokat kell-e hozniuk. Minden lehetőségnek vannak előnyei és hátrányai.

• Ha tanúsítványt állít ki egy ügyfél számára, kezelheti a tanúsítvány megújítását, így az ügyfélnek nem kell emlékeznie a frissítésére. Ha azonban az ügyfelek rendelkeznek CAA-rekordokkal a tartománynevükön, előfordulhat, hogy engedélyezniük kell Önnek, hogy tanúsítványokat állítson ki a nevükben.
• Ha arra számít, hogy az ügyfeleknek ki kell adniuk és meg kell adniuk a saját tanúsítványaikat, önnek kell biztonságosan fogadnia és kezelnie a titkos kulcsokat, és előfordulhat, hogy emlékeztetnie kell az ügyfeleit a tanúsítvány megújítására, mielőtt lejárna, hogy elkerülje a szolgáltatás megszakadását.

Számos Azure-szolgáltatás támogatja az egyéni tartományok tanúsítványainak automatikus kezelését. Az Azure Front Door és App Service például tanúsítványokat biztosítanak az egyéni tartományokhoz, és automatikusan kezelik a megújítási folyamatot. Ez eltávolítja a tanúsítványok kezelésének terhét az üzemeltetési csapattól. Azonban továbbra is figyelembe kell vennie a tulajdonjog és a jogosultság kérdését, például azt, hogy a CAA-rekordok érvényben vannak-e és megfelelően vannak-e konfigurálva. Emellett meg kell győződnie arról, hogy az ügyfelek tartományai úgy vannak konfigurálva, hogy engedélyezve legyenek a platform által felügyelt tanúsítványok.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• John Downs | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke

Egyéb közreműködők:

• Daniel Scott-Raynsford | Partnertechnológiai stratéga
• Arsen Vladimirskiy | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

Térjen vissza az architekturális szempontok áttekintéséhez. Vagy tekintse át a Microsoft Azure Well-Architected-keretrendszert.