Zagadnienia dotyczące używania nazw domen w rozwiązaniu wielodostępnym

W wielu wielodostępnych aplikacjach internetowych nazwa domeny może służyć jako sposób identyfikowania dzierżawy, ułatwiania routingu żądań do właściwej infrastruktury oraz zapewnienia klientom znakowania. Dwa typowe podejścia to użycie domen podrzędnych i niestandardowych nazw domen. Na tej stronie udostępniamy wskazówki dla osób podejmujących decyzje techniczne dotyczące podejść, które można wziąć pod uwagę i ich kompromisów.

Poddomen

Każda dzierżawa może uzyskać unikatową poddomenę w ramach wspólnej nazwy domeny udostępnionej przy użyciu formatu takiego jak tenant.provider.com.

Rozważmy przykładowe rozwiązanie wielodostępne utworzone przez firmę Contoso. Klienci kupują produkt firmy Contoso, aby ułatwić zarządzanie generowaniem faktur. Wszystkie dzierżawy firmy Contoso mogą być przypisane do własnej poddomeny pod contoso.com nazwą domeny. Jeśli firma Contoso korzysta z wdrożeń regionalnych, może przypisywać poddomeny w domenach us.contoso.com i eu.contoso.com . W tym artykule nazywamy je domenami macierzystymi. Każdy klient otrzymuje własną poddomenę w domenie macierzystej. Na przykład do aplikacji Tailwind Toys można przypisać element tailwind.contoso.com, a w regionalnym modelu wdrażania firma Adventure Works może mieć przypisaną wartość adventureworks.us.contoso.com.

Zarządzanie przestrzenią nazw domeny

Podczas tworzenia poddomen pod własną nazwą domeny należy pamiętać, że wielu klientów ma podobne nazwy. Ponieważ współużytkują jedną domenę macierzystą, pierwszy klient, który uzyska określoną domenę, otrzyma preferowaną nazwę. Następnie kolejni klienci muszą używać alternatywnych nazw poddomeny, ponieważ pełne nazwy domen muszą być globalnie unikatowe.

Dns z symbolami wieloznacznymi

Rozważ użycie wpisów DNS z symbolami wieloznacznymi, aby uprościć zarządzanie poddomenami. Zamiast tworzyć wpisy DNS dla tailwind.contoso.com, adventureworks.contoso.comi tak dalej, można zamiast tego utworzyć wpis wieloznaczny dla *.contoso.com i kierować wszystkie poddomeny do pojedynczego adresu IP (rekordU A) lub nazwy kanonicznej (rekord CNAME). Jeśli używasz regionalnych domen macierzystych, może być konieczne użycie wielu wpisów wieloznacznych, takich jak *.us.contoso.com i *.eu.contoso.com.

Poddomeny z domenami macierzystymi z wieloma częściami

Wiele wielodostępnych rozwiązań jest rozmieszczonych w wielu wdrożeniach fizycznych. Jest to typowe podejście, gdy trzeba spełnić wymagania dotyczące rezydencji danych lub zapewnić lepszą wydajność, wdrażając zasoby geograficznie bliżej użytkowników.

Nawet w jednym regionie może być konieczne rozłożenie dzierżaw w ramach niezależnych wdrożeń, aby obsługiwać strategię skalowania. Jeśli planujesz używać poddomen dla każdej dzierżawy, możesz rozważyć strukturę poddomeny wieloczęściowej.

Oto przykład: firma Contoso publikuje wielodostępną aplikację dla swoich czterech klientów. Firma Adventure Works i Tailwind Traders znajdują się w Stany Zjednoczone, a ich dane są przechowywane w udostępnionym wystąpieniu usa platformy Contoso. Firmy Fabrikam i Worldwide Importers znajdują się w Europie, a ich dane są przechowywane w wystąpieniu europejskim.

Jeśli firma Contoso zdecydowała się użyć jednej domeny macierzystej, contoso.com dla wszystkich swoich klientów, oto jak to może wyglądać:

Wpisy DNS (wymagane do obsługi tej konfiguracji) mogą wyglądać następująco:

Każdy nowy klient, który jest dołączony, wymaga nowej poddomeny, a liczba poddomen rośnie wraz z każdym klientem.

Alternatywnie firma Contoso może użyć domen macierzystych specyficznych dla wdrożenia lub regionu, takich jak:

Następnie przy użyciu systemu DNS z symbolami wieloznacznymi wpisy DNS dla tego wdrożenia mogą wyglądać następująco:

Firma Contoso nie musi tworzyć rekordów poddomeny dla każdego klienta. Zamiast tego mają jeden wieloznaczny rekord DNS dla każdego wdrożenia lokalizacji geograficznej, a wszyscy nowi klienci, którzy są dodawani pod tym elementem, automatycznie dziedziczą rekord CNAME.

Istnieją korzyści i wady każdego podejścia. W przypadku korzystania z jednej domeny macierzystej każda dołączana dzierżawa wymaga utworzenia nowego rekordu DNS, który wprowadza większe obciążenie operacyjne. Jednak masz większą elastyczność przenoszenia dzierżaw między wdrożeniami, ponieważ można zmienić rekord CNAME, aby skierować ruch do innego wdrożenia. Ta zmiana nie wpłynie na żadnych innych dzierżaw. W przypadku korzystania z wielu domen macierzystych obciążenie związane z zarządzaniem jest niższe. Ponadto można ponownie używać nazw klientów w wielu regionalnych domenach macierzystych, ponieważ każda domena macierzystowa skutecznie reprezentuje własną przestrzeń nazw.

Niestandardowe nazwy domen

Możesz umożliwić klientom korzystanie z własnych nazw domen. Niektórzy klienci postrzegają to jako ważny aspekt ich znakowania. Niestandardowe nazwy domen mogą być również wymagane do spełnienia wymagań dotyczących zabezpieczeń klientów, zwłaszcza jeśli muszą dostarczyć własne certyfikaty TLS. Chociaż może się wydawać proste, aby umożliwić klientom wprowadzanie własnych nazw domen, istnieją pewne ukryte złożoność tego podejścia i wymaga przemyślanego rozważenia.

Rozpoznawanie nazw

Ostatecznie każda nazwa domeny musi być rozpoznawana jako adres IP. Jak już wiesz, podejście do rozpoznawania nazw może zależeć od tego, czy wdrażasz jedno wystąpienie, czy wiele wystąpień rozwiązania.

Wróćmy do naszego przykładu. Jeden z klientów firmy Contoso, Fabrikam, poprosił o użycie invoices.fabrikam.com nazwy domeny niestandardowej w celu uzyskania dostępu do usługi firmy Contoso. Ponieważ firma Contoso ma wiele wdrożeń swojej wielodostępnej platformy, decyduje się na użycie poddomen i rekordów CNAME w celu osiągnięcia wymagań dotyczących routingu. Firma Contoso i firma Fabrikam konfigurują następujące rekordy DNS:

Z punktu widzenia rozpoznawania nazw ten łańcuch rekordów dokładnie rozwiązuje żądania dotyczące invoices.fabrikam.com adresu IP europejskiego wdrożenia firmy Contoso.

Rozpoznawanie nagłówka hosta

Rozpoznawanie nazw to tylko połowa problemu. Wszystkie składniki internetowe w ramach europejskiego wdrożenia firmy Contoso muszą wiedzieć, jak obsługiwać żądania dostarczane z nazwą domeny firmy Fabrikam w Host nagłówku żądania. W zależności od określonych technologii sieci Web używanych przez firmę Contoso może to wymagać dalszej konfiguracji dla nazwy domeny każdej dzierżawy, co zwiększa nakład pracy operacyjnej na dołączanie dzierżaw.

Możesz również rozważyć ponowne zapisywanie nagłówków hostów, aby niezależnie od nagłówka Host żądania przychodzącego serwer internetowy widział spójną wartość nagłówka. Na przykład usługa Azure Front Door umożliwia ponowne zapisywanie Host nagłówków, dzięki czemu niezależnie od żądania serwer aplikacji otrzymuje pojedynczy Host nagłówek. Usługa Azure Front Door propaguje oryginalny nagłówek hosta w nagłówku X-Forwarded-Host , aby aplikacja mogła ją sprawdzić, a następnie wyszukać dzierżawę. Jednak ponowne zapisywanie nagłówka Host może powodować inne problemy. Aby uzyskać więcej informacji, zobacz Zachowywanie nazwy hosta.

Walidacja domeny

Ważne jest, aby przed ich dołączaniem zweryfikować własność domen niestandardowych. W przeciwnym razie ryzykujesz, że klient przypadkowo lub złośliwie zaparkowa nazwę domeny.

Rozważmy proces dołączania firmy Contoso dla firmy Adventure Works, który poprosił o użycie invoices.adventureworks.com nazwy domeny niestandardowej. Niestety, ktoś zrobił literówkę, gdy próbował dołączyć niestandardową nazwę domeny, a oni przegapili s. Dlatego konfigurują go jako invoices.adventurework.com. Nie tylko ruch nie przepływa poprawnie dla firmy Adventure Works, ale gdy inna firma o nazwie Adventure Work próbuje dodać domenę niestandardową do platformy Firmy Contoso, powiedziano im, że nazwa domeny jest już używana.

Podczas pracy z domenami niestandardowymi, zwłaszcza w ramach samoobsługowego lub zautomatyzowanego procesu, często wymagane jest przeprowadzenie weryfikacji domeny. Może to wymagać skonfigurowania rekordów CNAME przed dodaniu domeny. Alternatywnie firma Contoso może wygenerować losowy ciąg i poprosić firmę Adventure Works o dodanie rekordu TXT DNS z wartością ciągu. Uniemożliwiłoby to dodanie nazwy domeny do momentu ukończenia weryfikacji.

Zwisające ataki dns i poddomeny przejęcia

Podczas pracy z niestandardowymi nazwami domen potencjalnie narażony jest na atak o nazwie zwisające dns lub przejęcie poddomeny. Ten atak występuje, gdy klienci nie kojarzą swojej niestandardowej nazwy domeny z usługi, ale nie usuwają rekordu z serwera DNS. Ten wpis DNS wskazuje następnie nieistniejący zasób i jest narażony na przejęcie.

Rozważmy, jak może ulec zmianie relacja firmy Fabrikam z firmą Contoso:

1. Firma Fabrikam zdecydowała się już nie współpracować z firmą Contoso, dlatego zakończyła swoją relację biznesową.
2. Firma Contoso odłączyła dzierżawę firmy Fabrikam i poprosiła fabrikam.contoso.com o to, aby przestała działać. Jednak firma Fabrikam nie zapomniała usunąć rekordu CNAME dla elementu invoices.fabrikam.com.
3. Złośliwy aktor tworzy nowe konto Contoso i nadaje mu nazwę fabrikam.
4. Osoba atakująca dołącza niestandardową nazwę invoices.fabrikam.com domeny do nowej dzierżawy. Ponieważ firma Contoso przeprowadza weryfikację domeny opartej na rekordach CNAME, sprawdza serwer DNS firmy Fabrikam. Widzą, że serwer DNS zwraca rekord CNAME dla invoices.fabrikam.comelementu , który wskazuje wartość fabrikam.contoso.com. Firma Contoso uważa, że weryfikacja domeny niestandardowej zakończy się pomyślnie.
5. Jeśli pracownicy firmy Fabrikam próbowali uzyskać dostęp do witryny, żądania wydają się działać. Jeśli osoba atakująca skonfiguruje dzierżawę firmy Contoso przy użyciu znakowania firmy Fabrikam, pracownicy mogą mieć możliwość uzyskania dostępu do witryny i podania poufnych danych, do których osoba atakująca może uzyskać dostęp.

Typowe strategie ochrony przed zwisanymi atakami DNS to:

• Wymagaj usunięcia rekordu CNAME przed usunięciem nazwy domeny z konta dzierżawy.
• Zakazać ponownego użycia identyfikatorów dzierżawy, a także wymagać utworzenia rekordu TXT z nazwą zgodną z nazwą domeny i losowo wygenerowaną wartością, która zmienia się dla każdej próby dołączania.

Certyfikat TLS/SSL

Transport Layer Security (TLS) to podstawowy składnik podczas pracy z nowoczesnymi aplikacjami. Zapewnia zaufanie i bezpieczeństwo aplikacji internetowych. Własność i zarządzanie certyfikatami TLS to coś, co wymaga starannego rozważenia w przypadku aplikacji wielodostępnych.

Zazwyczaj właściciel nazwy domeny jest odpowiedzialny za wystawianie i odnawianie certyfikatów. Na przykład firma Contoso jest odpowiedzialna za wystawianie i odnawianie certyfikatów TLS dla us.contoso.comprogramu , a także certyfikat wieloznaczny dla programu *.contoso.com. Podobnie firma Fabrikam zazwyczaj odpowiada za zarządzanie rekordami domeny fabrikam.com , w tym invoices.fabrikam.com.

Typ rekordu DNS urzędu certyfikacji (autoryzacja urzędu certyfikacji) może być używany przez właściciela domeny. Rekordy caA zapewniają, że tylko określone władze mogą tworzyć certyfikaty dla domeny.

Jeśli planujesz zezwolić klientom na korzystanie z własnych domen, zastanów się, czy planujesz wystawiać certyfikat w imieniu klienta, czy też klienci muszą korzystać z własnych certyfikatów. Każda opcja ma zalety i wady:

• Jeśli wystawiasz certyfikat dla klienta, możesz obsłużyć odnawianie certyfikatu, więc klient nie musi pamiętać o jego aktualizowaniu. Jeśli jednak klienci mają rekordy CAA w swoich nazwach domen, może być konieczne autoryzowanie cię do wystawiania certyfikatów w ich imieniu.
• Jeśli oczekujesz, że klienci będą wystawiać i dostarczać własne certyfikaty, odpowiadasz za odbieranie i zarządzanie kluczami prywatnymi w bezpieczny sposób i może być konieczne przypomnienie klientom o odnowieniu certyfikatu przed jego wygaśnięciem, aby uniknąć przerw w działaniu usługi.

Kilka usług platformy Azure obsługuje automatyczne zarządzanie certyfikatami dla domen niestandardowych. Na przykład usługi Azure Front Door i App Service udostępniają certyfikaty dla domen niestandardowych i automatycznie obsługują proces odnawiania. Eliminuje to obciążenie związane z zarządzaniem certyfikatami od zespołu operacyjnego. Jednak nadal trzeba rozważyć kwestię własności i urzędu, na przykład czy rekordy CAA są w mocy i prawidłowo skonfigurowane. Ponadto należy upewnić się, że domeny klientów są skonfigurowane tak, aby zezwalały na certyfikaty zarządzane przez platformę.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• John Downs | Główny inżynier oprogramowania

Inni współautorzy:

• Daniel Scott-Raynsford | Partner TechnologyStrateg
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Wróć do przeglądu zagadnień dotyczących architektury. Możesz też zapoznać się z witryną Microsoft Azure Well-Architected Framework.