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 kierowania żądań do właściwej infrastruktury oraz zapewnienia klientom środowiska oznaczonego marką. 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że być przypisana wartość tailwind.contoso.com, a firma Adventure Works może mieć przypisaną wartość adventureworks.contoso.com.

Zarządzanie przestrzenią nazw domeny

Podczas tworzenia poddomeny w ramach własnej nazwy domeny należy pamiętać, że może istnieć wielu klientów o podobnych nazwach. Ponieważ współużytkują jedną domenę macierzystą, pierwszy klient, który uzyska konkretną domenę, otrzyma preferowaną nazwę. Następnie kolejni klienci muszą używać alternatywnych nazw domen podrzędnych, 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).

Poddomeny z domenami macierzystymi z wieloma częściami

Wiele rozwiązań wielodostępnych jest rozmieszczonych w wielu wdrożeniach fizycznych. Jest to typowe podejście, gdy zachodzi potrzeba spełnienia wymagań dotyczących rezydencji danych lub gdy chcesz 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 między niezależne wdrożenia, aby obsługiwać strategię skalowania. Jeśli planujesz używać poddomeny dla każdej dzierżawy, możesz rozważyć strukturę poddomeny wieloczęściowej.

Oto przykład: Firma Contoso publikuje aplikację wielodostępną 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 amerykańskiej 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żywać jednej domeny macierzystej, contoso.com dla wszystkich swoich klientów, oto jak może to wyglądać:

Wpisy DNS (które są 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 geografii i wszystkich nowych klientów, którzy są dodawani poniżej, że stem automatycznie dziedziczą rekord CNAME.

Każde podejście ma zalety i wady. W przypadku korzystania z jednej domeny macierzystej każda dołączona dzierżawa wymaga utworzenia nowego rekordu DNS, co 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 występuje mniejsze obciążenie związane z zarządzaniem. 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. Nazwy domen niestandardowych 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 wydawać się banalne, aby umożliwić klientom wprowadzanie własnych nazw domen, istnieje pewne ukryte złożoność tego podejścia i wymaga przemyślanego rozważenia.

Rozpoznawanie nazw

Ostatecznie każda nazwa domeny musi zostać rozpoznana jako adres IP. Jak już wiesz, podejście do rozpoznawania nazw może zależeć od tego, czy wdrażasz pojedyncze 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 nazwy invoices.fabrikam.comdomeny jako niestandardowej nazwy domeny w celu uzyskania dostępu do usługi firmy Contoso. Ponieważ firma Contoso ma wiele wdrożeń swojej platformy, decyduje się na użycie domen podrzędnych i rekordów CNAME w celu osiągnięcia wymagań dotyczących routingu. Firmy Contoso i Fabrikam konfigurują następujące rekordy DNS:

Z perspektywy 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 internetowych używanych przez firmę Contoso może to wymagać dalszej konfiguracji dla nazwy domeny każdej dzierżawy, co dodaje dodatkowe obciążenie operacyjne do dołączania dzierżaw.

Możesz również rozważyć ponowne zapisywanie nagłówków hosta, 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 spowodować inne problemy. Aby uzyskać więcej informacji, zobacz Zachowywanie nazw hostów.

Walidacja domeny

Przed ich dołączaniem ważne jest zweryfikowanie własności 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 jej jako niestandardowej nazwy domeny. Niestety, ktoś zrobił literówkę, gdy próbował dołączyć niestandardową nazwę domeny, i brakowało im 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ć swoją domenę niestandardową do platformy Firmy Contoso, powiedziano im, że nazwa domeny jest już używana.

Podczas pracy z domenami niestandardowymi, szczególnie 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 przejęcia poddomeny

Podczas pracy z niestandardowymi nazwami domen potencjalnie narażony jest na atak o nazwie zwisające przejęcie DNS lub 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 podatny na przejęcie.

Rozważmy, w jaki sposób relacja firmy Fabrikam z firmą Contoso może ulec zmianie:

1. Firma Fabrikam zdecydowała się już nie pracować z firmą Contoso i dlatego zakończyła relację biznesową.
2. Firma Contoso odłączyła dzierżawę firmy Fabrikam i zażądała fabrikam.contoso.com , aby nie działała już. Jednak Fabrikam nie pamięta o usunięciu rekordu CNAME dla invoices.fabrikam.comelementu .
3. Złośliwy aktor tworzy nowe konto firmy 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 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ą zostać oszukani w celu uzyskania dostępu do witryny i podania poufnych danych, do których osoba atakująca może uzyskać dostęp.

Typowe strategie ochrony przed atakami DNS są następujące:

• Wymagaj usunięcia rekordu CNAME przed usunięciem nazwy domeny z konta dzierżawy.
• Uniemożliwia ponowne użycie identyfikatorów dzierżawy, a także wymaga, aby dzierżawa utworzyła rekord TXT o nazwie pasującej do nazwy domeny i losowo wygenerowanej wartości, która zmienia się dla każdej próby dołączenia.

Certyfikaty TLS/SSL

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

Zazwyczaj właściciel nazwy domeny będzie 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 z symbolami wieloznacznymi dla programu *.contoso.com. Podobnie firma Fabrikam zazwyczaj odpowiada za zarządzanie wszelkimi 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, rozważ, czy planujesz wystawiać certyfikat w imieniu klienta, czy też klienci muszą przynieść własne certyfikaty. 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 autoryzacja do wystawiania certyfikatów w ich imieniu.
• Jeśli oczekujesz, że klienci powinni wystawiać i dostarczać ci własne certyfikaty, odpowiadasz za odbieranie kluczy prywatnych i zarządzanie nimi 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ługa 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 musisz wziąć pod uwagę kwestię własności i urzędu, na przykład czy rekordy CAA są w życie 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 klienta, fasttrack dla platformy Azure

Inni współautorzy:

• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Władimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure

Aby wyświetlić niepubliowe profile usługi LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

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