Zastosowanie konfiguracji DNS z podziałem mózgowym do uruchomienia aplikacji internetowej na platformie Azure

Azure Front Door

Usługa Azure Application Gateway

Azure ExpressRoute

Usługa DNS platformy Azure

Zespoły, które zarządzają obciążeniami, często korzystają z w pełni kwalifikowanych nazw domen (FQDN) na potrzeby dostępu klientów. Nazwy FQDN są zwykle łączone z Wskazaniem Nazwy Serwera (SNI) w protokole Transport Layer Security (TLS). Dzięki takiemu podejściu, gdy klienci publiczni uzyskują dostęp do obciążenia z publicznego Internetu, albo klienci korporacyjni uzyskują do niego dostęp wewnętrznie, routing do aplikacji może być realizowany zgodnie ze stałymi ścieżkami i mieć różne poziomy zabezpieczeń lub jakości usług (QoS).

Poniższa architektura pokazuje podejście do rozróżniania sposobu traktowania ruchu na podstawie systemu nazw domen (DNS) i tego, czy klient pochodzi z Internetu, czy z sieci firmowej.

Architecture

Na diagramie dwukierunkowa strzałka wskazuje od app.contoso.com do Internetu. Kolejna dwukierunkowa strzałka wskazuje z Internetu do strefy Azure DNS dla contoso.com. Strzałka wskazuje z Internetu na Azure Front Door. Strzałka oznaczona etykietą 207.x.x.x (pip-appgw) wskazuje z Azure Front Door do publicznego punktu końcowego w podsieci AppGW. Kolejna strzałka wskazuje z publicznego punktu końcowego do aplikacji w podsieci aplikacji. W sekcji lokalizacji lokalnej strzałka wskazuje z app.contoso.com na Active Directory Domain Services (AD DS) DNS. Kropkowane linie wskazują z usługi AD DS DNS do obwodu Azure ExpressRoute i połączenia sieci VPN typu lokacja-lokacja. Te ścieżki zbiega się przed dotarciem do podsieci AppGW i publicznego punktu końcowego.

Pobierz plik programu Visio tej architektury.

W poniższych sekcjach przepływu pracy opisano dwie konfiguracje: publiczny przepływ pracy w Internecie i prywatny przepływ pracy. Połącz dwa przepływy pracy, aby zaimplementować architekturę hostingu split-brain.

Publiczny przepływ pracy w Internecie

Na diagramie przedstawiono sześcioetapowy przepływ publicznych danych internetowych. W kroku 1 dwukierunkowa strzałka łączy app.contoso.com z Internetem. W kroku 2 dwukierunkowa strzałka łączy strefę Azure DNS dla contoso.com i Internetu. W kroku 3 strzałka wskazuje z Internetu na Azure Front Door. Inna strzałka oznaczona etykietą 207.x.x (pip‑appgw) wskazuje z Azure Front Door do publicznego punktu końcowego adresu IP usługi Azure Application Gateway. W kroku 4 sieciowa grupa zabezpieczeń w podsieci usługi Application Gateway zezwala na dostęp przychodzący z tagu usługi AzureFrontDoor.Backend. W kroku 5 strzałka wskazuje od publicznego punktu końcowego adresu IP Application Gateway do podsieci aplikacyjnej. W kroku 6 podsieć aplikacji hostuje zasoby aplikacji.

Pobierz plik programu Visio tej architektury.

1. Klienci wysyłają żądanie dla aplikacji app.contoso.com za pośrednictwem publicznego Internetu.

2. Strefa azure DNS jest skonfigurowana dla domeny contoso.com. Odpowiednie wpisy nazwy kanonicznej (CNAME) są skonfigurowane dla punktów końcowych usługi Azure Front Door.

3. Klienci zewnętrzni uzyskują dostęp do aplikacji internetowej za pośrednictwem usługi Azure Front Door Standard lub Premium, która działa jako globalny moduł równoważenia obciążenia i zapora aplikacji internetowej (WAF).

   • W usłudze Azure Front Door app.contoso.com jest przypisywany jako FQDN za pośrednictwem tras w skonfigurowanym punkcie końcowym. Usługa Azure Front Door hostuje również certyfikaty SNI protokołu TLS dla aplikacji.

     Note

     Usługa Azure Front Door nie obsługuje certyfikatów z podpisem własnym.

   • Usługa Azure Front Door kieruje żądania do skonfigurowanej grupy źródeł na podstawie Host nagłówka HTTP klienta.

   • Grupa źródeł jest skonfigurowana tak, aby wskazywała na instancję usługi Azure Application Gateway za pośrednictwem publicznego adresu IP tej usługi.

4. A sieciowa grupa zabezpieczeń (NSG) jest skonfigurowana w podsieci AppGW, aby zezwolić na dostęp przychodzący na porcie 80 i porcie 443 z tagu usługi AzureFrontDoor.Backend. Sieciowa grupa zabezpieczeń nie zezwala na ruch przychodzący na porty 80 i 443 z etykiety usługi internetowej.

   Note

   Tag usługi AzureFrontDoor.Backend nie ogranicza ruchu wyłącznie do twojego wystąpienia usługi Azure Front Door. Walidacja odbywa się na następnym etapie.

5. Wystąpienie usługi Application Gateway ma odbiornik na porcie 443. Ruch jest kierowany do zaplecza na podstawie nazwy hosta określonej w odbiorniku.

   • Aby upewnić się, że ruch pochodzi z profilu usługi Azure Front Door, skonfiguruj niestandardową regułę WAF, aby sprawdzić wartość nagłówka X-Azure-FDID.

   • Platforma Azure generuje unikatowy identyfikator dla każdego profilu usługi Azure Front Door. Unikatowy identyfikator to identyfikator Azure Front Door ID znajdujący się na stronie przeglądu portalu Azure.

6. Ruch dociera do zasobu obliczeniowego skonfigurowanego jako pula zaplecza w usłudze Application Gateway.

Przepływ pracy prywatnego przedsiębiorstwa

W kroku 1 użytkownik z etykietą app.contoso.com inicjuje żądanie ze środowiska lokalnego. W kroku 2 żądanie dociera do lokalnego serwera DNS usług AD DS. W kroku 3 wiersze kropkowane rozciągają się od serwera DNS do obwodu usługi ExpressRoute i połączenia sieci VPN typu lokacja-lokacja, które zapewniają ścieżkę ze środowiska lokalnego do Azure. W kroku 4 sieciowa grupa zabezpieczeń w podsieci AppGW kontroluje ruch prywatny, który dociera do usługi Application Gateway. W kroku 5 dwie linie z obwodu usługi ExpressRoute oraz połączenie VPN między lokalizacjami łączą się i tworzą pojedynczą strzałkę wskazującą punkt docelowy w podsieci AppGW. Ten punkt końcowy ma etykietę 207.x.x.x (pip) i 192.168.200.4. W kroku 6 strzałka wskazuje od punktu końcowego Bramy Aplikacji w kierunku aplikacji w podsieci aplikacji.

Pobierz plik programu Visio tej architektury.

1. Klienci inicjują żądanie aplikacji app.contoso.com ze środowiska lokalnego.

2. Nazwy FQDN aplikacji są konfigurowane przez lokalnego dostawcę DNS. Ten dostawca usług DNS może korzystać z lokalnych serwerów DNS Active Directory Domain Services (AD DS) lub innych rozwiązań partnerskich. Wpisy DNS dla każdej nazwy FQDN aplikacji są skonfigurowane tak, aby kierowały na prywatny adres IP instancji usługi Application Gateway.

3. Obwód usługi Azure ExpressRoute lub sieć VPN site-to-site zapewnia dostęp do usługi Application Gateway.

4. Sieciowa grupa zabezpieczeń jest skonfigurowana w podsieci AppGW , aby zezwalać na przychodzące żądania prywatne z lokalnych sieci klientów, z których pochodzi ruch. Ta konfiguracja zapewnia, że inne źródła ruchu prywatnego nie mogą bezpośrednio uzyskać dostępu do prywatnego adresu IP usługi Application Gateway.

5. Usługa Application Gateway ma odbiornik skonfigurowany na porcie 80 i porcie 443. Ruch jest kierowany do zaplecza na podstawie nazwy hosta określonej w odbiorniku.

6. Tylko ruch w sieci prywatnej dociera do zasobów obliczeniowych skonfigurowanych jako pula zaplecza w usłudze Application Gateway.

Components

• DNS to system, który mapuje nazwy domen na adresy IP, co umożliwia klientom lokalizowanie i łączenie się z usługami. W tej architekturze, w przypadku publicznego przepływu pracy w Internecie, należy skonfigurować publiczną strefę DNS z odpowiednim CNAME odpowiadającym FQDN punktu końcowego Azure Front Door. Po stronie prywatnej (firmowej), skonfiguruj lokalnego dostawcę DNS (np. AD DS DNS lub rozwiązanie partnerskie), aby każda aplikacja z nazwą FQDN była kierowana na prywatny adres IP usługi Application Gateway.

• Azure DNS Private Resolver to w pełni zarządzana usługa, która umożliwia rozwiązywanie nazw DNS między środowiskami lokalnymi i Azure bez wdrażania niestandardowych serwerów DNS. W tej architekturze usługa DNS Private Resolver umożliwia rozpoznawanie klientów lokalnych, dzięki czemu użytkownicy korporacyjni mogą używać tego rozwiązania DNS podzielonego mózgu do uzyskiwania dostępu do aplikacji bez przechodzenia przez publiczny Internet.

• Azure Front Door to globalny równoważnik obciążenia i WAF, który zapewnia szybkie i bezpieczne dostarczanie aplikacji internetowych klientom na całym świecie. W tej architekturze Azure Front Door Standard lub Premium kieruje klientów zewnętrznych do instancji Application Gateway i udostępnia opcje buforowania i optymalizacji w celu poprawy doświadczeń klientów.

• Application Gateway to regionalny moduł równoważenia obciążenia i WAF, który zapewnia wysoką dostępność, skalowalność i bezpieczeństwo aplikacji internetowych. W tej architekturze usługa Application Gateway kieruje żądania klientów zewnętrznych i wewnętrznych do obliczeń zaplecza i chroni aplikację internetową przed typowymi atakami internetowymi.

  Zarówno Azure Front Door, jak i Application Gateway zapewniają możliwości zapory aplikacji internetowej, ale prywatny przepływ pracy w tym rozwiązaniu nie korzysta z Azure Front Door. W rezultacie obie architektury korzystają z funkcjonalności Application Gateway WAF.

• ExpressRoute to usługa, która rozszerza sieci lokalne na chmurę za pośrednictwem połączenia prywatnego ustanowionego przez dostawcę łączności. W tej architekturze usługa ExpressRoute ułatwia prywatną łączność z usługą Application Gateway dla klientów lokalnych.

Alternatives

Alternatywnie można usunąć Azure Front Door Standard lub Premium i zamiast tego wskazać publiczny rekord DNS na publiczny adres IP usługi Application Gateway. Na podstawie wymagań tej architektury należy buforować i zoptymalizować ruch w punkcie wejściowym do Azure. W związku z tym nie można użyć alternatywnego rozwiązania dla tego scenariusza. Aby uzyskać więcej informacji, zobacz Optymalizacja kosztów.

Strzałka dwustronna wskazuje od app.contoso.com do internetu. Kolejna dwukierunkowa strzałka wskazuje z Internetu do strefy Azure DNS dla contoso.com. Strzałka oznaczona etykietą 207.x.x.x (pip-appgw) wskazuje publiczny punkt końcowy adresu IP usługi Application Gateway skojarzony z podsiecią AppGW. Strzałka wskazuje z publicznego punktu końcowego adresu IP usługi Application Gateway do aplikacji w podsieci aplikacji.

Pobierz plik programu Visio tej architektury.

Inne możliwe alternatywy dla publicznego ruchu przychodzącego w tej architekturze obejmują:

• Azure Traffic Manager: Traffic Manager to oparta na systemie DNS usługa routingu ruchu, która dystrybuuje ruch między różnymi regionami i punktami końcowymi. Możesz użyć usługi Traffic Manager zamiast Azure Front Door w warstwie Standardowa lub Premium, aby kierować klientów zewnętrznych do najbliższego wystąpienia usługi Application Gateway. Jednak usługa Azure Front Door udostępnia funkcje, takie jak możliwości zapory aplikacji internetowej, buforowanie i powiązanie sesji. Usługa Traffic Manager nie udostępnia tych funkcji.

• Azure Load Balancer: Usługa Azure Load Balancer to moduł równoważenia obciążenia sieciowego, który zapewnia wysoką dostępność i skalowalność ruchu protokołu TRANSMISSION Control Protocol (TCP) i protokołu UDP (User Datagram Protocol). Usługi Load Balancer zamiast usługi Application Gateway można użyć do kierowania żądań klientów zewnętrznych i wewnętrznych do serwerów internetowych zaplecza. Jednak usługa Application Gateway udostępnia funkcje, takie jak możliwości WAF, zakończenie sesji SSL i przyleganie sesji oparte na ciasteczkach. Usługa Load Balancer nie udostępnia tych funkcji.

Szczegóły scenariusza

Ten scenariusz rozwiązuje problem hostowania aplikacji internetowej, która obsługuje zarówno klientów zewnętrznych, jak i wewnętrznych. Ta architektura zapewnia, że ruch jest kierowany odpowiednią ścieżką w oparciu o pochodzenie klienta. Ta architektura:

• Zapewnia szybki i niezawodny dostęp przez Internet do aplikacji internetowej dla globalnych klientów niebędących przedsiębiorstwami.

• Zapewnia klientom korporacyjnym możliwość uzyskiwania dostępu do aplikacji bez przechodzenia przez publiczny Internet.

• Chroni aplikację internetową przed typowymi atakami internetowymi i złośliwym ruchem.

Potencjalne przypadki użycia

Użyj tej architektury w scenariuszach, które wymagają:

• Split-brain DNS: To rozwiązanie używa Azure Front Door dla klientów zewnętrznych i usługi Application Gateway dla klientów wewnętrznych z różnymi rekordami DNS dla każdej usługi. Takie podejście ułatwia optymalizowanie wydajności sieci, zabezpieczeń i dostępności dla różnych klientów.

• Skalowalność aplikacji: To rozwiązanie korzysta z usługi Application Gateway, która może dystrybuować ruch między skonfigurowanymi zasobami obliczeniowymi zaplecza. Takie podejście pomaga zwiększyć wydajność i dostępność aplikacji oraz obsługiwać skalowanie w poziomie.

Considerations

Te zagadnienia obejmują implementację filarów platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Reliability

Niezawodność pomaga zapewnić, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Design review checklist for Reliability(Lista kontrolna dotycząca niezawodności).

• Identyfikowanie punktów awarii. W tej architekturze DNS podzielonego mózgu niezawodność zależy od prawidłowego funkcjonowania kluczowych składników, takich jak Azure Front Door, Application Gateway i konfiguracje DNS. Należy zidentyfikować potencjalne punkty awarii, takie jak błędy konfiguracji, problemy z certyfikatami SSL lub przeciążenia pojemności.

• Ocena wpływu. Należy ocenić wpływ awarii. W przypadku klientów zewnętrznych wszelkie zakłócenia w usłudze Azure Front Door, które służą jako brama, mogą mieć wpływ na dostęp globalny. W przypadku klientów wewnętrznych wszelkie zakłócenia w usłudze Application Gateway mogą utrudniać operacje przedsiębiorstwa.

• Implementowanie strategii ograniczania ryzyka. Aby ograniczyć ryzyko, należy zaimplementować nadmiarowość w wielu strefach dostępności, używać sond kondycji do monitorowania w czasie rzeczywistym i zapewnić poprawną konfigurację routingu DNS zarówno dla ruchu zewnętrznego, jak i wewnętrznego. Upewnij się, że regularnie aktualizujesz rekordy DNS i masz plan odzyskiwania po awarii.

• Monitoruj w sposób ciągły. Aby zachować czujne oko na kondycję systemu, należy stosować funkcje Azure Monitor. Skonfiguruj alerty dotyczące anomalii i przygotuj plan reagowania na zdarzenia, aby szybko rozwiązać potencjalne problemy.

Przestrzegaj tych zasad, aby zapewnić niezawodny i niezawodny system, który może wytrzymać wyzwania i utrzymać ciągłość usług.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

• Użyj podejścia Zero Trust. W konfiguracji DNS z podzielonym mózgiem zastosuj podejście Zero Trust. Jawnie zweryfikuj tożsamość klienta, niezależnie od tego, czy pochodzi z Internetu, czy z sieci firmowej. Takie podejście zapewnia, że tylko zaufane jednostki mogą wykonywać autoryzowane akcje.

• Efektywna implementacja mechanizmów tożsamości i kontroli dostępu. Zaimplementuj Microsoft Entra ID w celu niezawodnego zarządzania tożsamościami. Zasady dostępu warunkowego firmy Microsoft Entra umożliwiają wymuszanie ścisłej kontroli dostępu na podstawie kontekstu klienta, kondycji urządzenia i lokalizacji.

  • Oceń środki zabezpieczeń. Oceń skuteczność środków zabezpieczeń dla obciążenia z podwójnym dostępem, implementując:

    • Regularnie oceniaj swoje inwestycje obronne. Regularnie oceniaj skuteczność Azure Front Door i usługi Application Gateway. Upewnij się, że zapewniają znaczącą ochronę przed zagrożeniami.

    • Ogranicz zakres wpływu potencjalnych naruszeń. Upewnij się, że naruszenia zabezpieczeń są ograniczone do wąskiego zakresu. Na przykład skutecznie izoluj przepływy ruchu zewnętrznego i wewnętrznego.

• Załóżmy, że naruszenie jest zawsze możliwe. Potwierdź, że osoby atakujące mogą naruszać mechanizmy kontroli zabezpieczeń. Przygotuj się do takich scenariuszy.

• Kompleksowo zaimplementuj środki zabezpieczeń. Zaimplementuj segmentację sieci, mikrosegmentację i sieciowe grupy zabezpieczeń. Załóżmy, że osoba atakująca może uzyskać dostęp, i zaprojektuj odpowiednie kompensujące mechanizmy kontrolne.

Zintegruj te zasady bezpieczeństwa z architekturą split-brain DNS, aby stworzyć niezawodny i odporny system, który chroni wewnętrzny i zewnętrzny dostęp do Twoich zasobów.

Inne ulepszenia zabezpieczeń

• Application Gateway: Możesz użyć Web Application Firewall (WAF) w ramach Application Gateway, aby chronić swoje aplikacje internetowe przed typowymi lukami w zabezpieczeniach i exploitami. Możesz również użyć usługi Azure Private Link , aby bezpiecznie uzyskać dostęp do serwerów aplikacji zaplecza z usługi Application Gateway bez uwidaczniania ich w publicznym Internecie.

• Azure Firewall: Możesz dodać Azure firewall do sieci wirtualnej centrum i użyć Azure Firewall analizy zagrożeń aby zablokować złośliwy ruch ze znanych złośliwych adresów IP i domen. Usługę Azure Firewall można również użyć jako serwera proxy DNS , aby przechwycić i sprawdzić ruch DNS oraz zastosować reguły filtrowania DNS.

• Azure Front Door: Możesz użyć Azure Web Application Firewall w celu ochrony aplikacji internetowych przed typowymi lukami w zabezpieczeniach i programami wykorzystującymi luki w zabezpieczeniach na brzegu sieci Web. Możesz również użyć usługi Private Link z warstwą Premium usługi Azure Front Door, aby bezpiecznie uzyskać dostęp do serwerów aplikacji zaplecza z usługi Azure Front Door bez uwidaczniania ich w publicznym Internecie.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.

• Obliczenia zaplecza: Wiele czynników, takich jak wybór jednostki SKU, liczba replik i region, napędzają koszt uruchamiania usług obliczeniowych zaplecza. Przed wybraniem najlepszej opcji dla obciążenia należy wziąć pod uwagę wszystkie elementy zasobu obliczeniowego .

• Application Gateway: Koszty usługi Application Gateway zależą od liczby wystąpień, rozmiaru wystąpień i ilości przetworzonych danych. Koszt można zoptymalizować przy użyciu skalowania automatycznego , aby dostosować liczbę wystąpień na podstawie zapotrzebowania na ruch. Można również wdrożyć jednostki SKU strefowo nadmiarowe w strefach dostępności, aby zmniejszyć potrzebę dodatkowych wystąpień w celu zapewnienia wysokiej dostępności.

• Azure Front Door: Azure Front Door koszty zależą od liczby reguł routingu, liczby żądań HTTP lub HTTPS oraz ilości przesyłanych danych. Możesz użyć Azure Front Door Standard lub Premium, aby uzyskać ujednolicone środowisko pracy z Azure Content Delivery Network, Azure Web Application Firewall i Private Link. Możesz również użyć funkcji silnika reguł usługi Azure Front Door, aby dostosować zarządzanie ruchem i zoptymalizować wydajność i koszty.

Jeśli twój scenariusz nie wymaga dostępu globalnego ani dodatkowych funkcji usługi Azure Front Door, możesz użyć tego rozwiązania tylko z usługą Application Gateway. Wszystkie publiczne rekordy DNS można wskazać na publiczny adres IP skonfigurowany na odbiornikach usługi Application Gateway.

Zapoznaj się z przykładem tego rozwiązania , które przybliża typowe użycie składników w tej architekturze. Dostosuj koszty, aby dopasować je do danego scenariusza.

Contributors

Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Troy Hite | Starszy inżynier rozwiązań

Inni współautorzy:

• Mays Algebary | Starszy specjalista ds. sieci Azure Global Blackbelt
• Michael McKechney | Główny specjalista ds. technologii platformy Azure
• Adam Torkar | Senior Azure Networking Global Blackbelt

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

Dalsze kroki

• Konfiguracja infrastruktury usługi Application Gateway
• Od końca do końca TLS z usługą Azure Front Door
• Dodawanie domeny niestandardowej do usługi Azure Front Door
• Co to jest filtrowanie geograficzne w domenie dla usługi Azure Front Door

Powiązane zasoby

• Zapora i bramka aplikacyjna dla sieci wirtualnych
• Korzystanie z usługi Azure Front Door w rozwiązaniu wielodostępnym

Zespoły, które zarządzają obciążeniami, często korzystają z w pełni kwalifikowanych nazw domen (FQDN) na potrzeby dostępu klientów. Nazwy FQDN są zwykle łączone z Wskazaniem Nazwy Serwera (SNI) w protokole Transport Layer Security (TLS). Dzięki takiemu podejściu, gdy klienci publiczni uzyskują dostęp do obciążenia z publicznego Internetu, albo klienci korporacyjni uzyskują do niego dostęp wewnętrznie, routing do aplikacji może być realizowany zgodnie ze stałymi ścieżkami i mieć różne poziomy zabezpieczeń lub jakości usług (QoS).

Poniższa architektura pokazuje podejście do rozróżniania sposobu traktowania ruchu na podstawie systemu nazw domen (DNS) i tego, czy klient pochodzi z Internetu, czy z sieci firmowej.

Architecture

Na diagramie dwukierunkowa strzałka wskazuje od app.contoso.com do Internetu. Kolejna dwukierunkowa strzałka wskazuje z Internetu do strefy Azure DNS dla contoso.com. Strzałka wskazuje z Internetu na Azure Front Door. Strzałka oznaczona etykietą 207.x.x.x (pip-appgw) wskazuje z Azure Front Door do publicznego punktu końcowego w podsieci AppGW. Kolejna strzałka wskazuje z publicznego punktu końcowego do aplikacji w podsieci aplikacji. W sekcji lokalizacji lokalnej strzałka wskazuje z app.contoso.com na Active Directory Domain Services (AD DS) DNS. Kropkowane linie wskazują z usługi AD DS DNS do obwodu Azure ExpressRoute i połączenia sieci VPN typu lokacja-lokacja. Te ścieżki zbiega się przed dotarciem do podsieci AppGW i publicznego punktu końcowego.

Pobierz plik programu Visio tej architektury.

W poniższych sekcjach przepływu pracy opisano dwie konfiguracje: publiczny przepływ pracy w Internecie i prywatny przepływ pracy. Połącz dwa przepływy pracy, aby zaimplementować architekturę hostingu split-brain.

Publiczny przepływ pracy w Internecie

Na diagramie przedstawiono sześcioetapowy przepływ publicznych danych internetowych. W kroku 1 dwukierunkowa strzałka łączy app.contoso.com z Internetem. W kroku 2 dwukierunkowa strzałka łączy strefę Azure DNS dla contoso.com i Internetu. W kroku 3 strzałka wskazuje z Internetu na Azure Front Door. Inna strzałka oznaczona etykietą 207.x.x (pip‑appgw) wskazuje z Azure Front Door do publicznego punktu końcowego adresu IP usługi Azure Application Gateway. W kroku 4 sieciowa grupa zabezpieczeń w podsieci usługi Application Gateway zezwala na dostęp przychodzący z tagu usługi AzureFrontDoor.Backend. W kroku 5 strzałka wskazuje od publicznego punktu końcowego adresu IP Application Gateway do podsieci aplikacyjnej. W kroku 6 podsieć aplikacji hostuje zasoby aplikacji.

Pobierz plik programu Visio tej architektury.

1. Klienci wysyłają żądanie dla aplikacji app.contoso.com za pośrednictwem publicznego Internetu.

2. Strefa azure DNS jest skonfigurowana dla domeny contoso.com. Odpowiednie wpisy nazwy kanonicznej (CNAME) są skonfigurowane dla punktów końcowych usługi Azure Front Door.

3. Klienci zewnętrzni uzyskują dostęp do aplikacji internetowej za pośrednictwem usługi Azure Front Door Standard lub Premium, która działa jako globalny moduł równoważenia obciążenia i zapora aplikacji internetowej (WAF).

   • W usłudze Azure Front Door app.contoso.com jest przypisywany jako FQDN za pośrednictwem tras w skonfigurowanym punkcie końcowym. Usługa Azure Front Door hostuje również certyfikaty SNI protokołu TLS dla aplikacji.

     Note

     Usługa Azure Front Door nie obsługuje certyfikatów z podpisem własnym.

   • Usługa Azure Front Door kieruje żądania do skonfigurowanej grupy źródeł na podstawie Host nagłówka HTTP klienta.

   • Grupa źródeł jest skonfigurowana tak, aby wskazywała na instancję usługi Azure Application Gateway za pośrednictwem publicznego adresu IP tej usługi.

4. A sieciowa grupa zabezpieczeń (NSG) jest skonfigurowana w podsieci AppGW, aby zezwolić na dostęp przychodzący na porcie 80 i porcie 443 z tagu usługi AzureFrontDoor.Backend. Sieciowa grupa zabezpieczeń nie zezwala na ruch przychodzący na porty 80 i 443 z etykiety usługi internetowej.

   Note

   Tag usługi AzureFrontDoor.Backend nie ogranicza ruchu wyłącznie do twojego wystąpienia usługi Azure Front Door. Walidacja odbywa się na następnym etapie.

5. Wystąpienie usługi Application Gateway ma odbiornik na porcie 443. Ruch jest kierowany do zaplecza na podstawie nazwy hosta określonej w odbiorniku.

   • Aby upewnić się, że ruch pochodzi z profilu usługi Azure Front Door, skonfiguruj niestandardową regułę WAF, aby sprawdzić wartość nagłówka X-Azure-FDID.

   • Platforma Azure generuje unikatowy identyfikator dla każdego profilu usługi Azure Front Door. Unikatowy identyfikator to identyfikator Azure Front Door ID znajdujący się na stronie przeglądu portalu Azure.

6. Ruch dociera do zasobu obliczeniowego skonfigurowanego jako pula zaplecza w usłudze Application Gateway.

Przepływ pracy prywatnego przedsiębiorstwa

W kroku 1 użytkownik z etykietą app.contoso.com inicjuje żądanie ze środowiska lokalnego. W kroku 2 żądanie dociera do lokalnego serwera DNS usług AD DS. W kroku 3 wiersze kropkowane rozciągają się od serwera DNS do obwodu usługi ExpressRoute i połączenia sieci VPN typu lokacja-lokacja, które zapewniają ścieżkę ze środowiska lokalnego do Azure. W kroku 4 sieciowa grupa zabezpieczeń w podsieci AppGW kontroluje ruch prywatny, który dociera do usługi Application Gateway. W kroku 5 dwie linie z obwodu usługi ExpressRoute oraz połączenie VPN między lokalizacjami łączą się i tworzą pojedynczą strzałkę wskazującą punkt docelowy w podsieci AppGW. Ten punkt końcowy ma etykietę 207.x.x.x (pip) i 192.168.200.4. W kroku 6 strzałka wskazuje od punktu końcowego Bramy Aplikacji w kierunku aplikacji w podsieci aplikacji.

Pobierz plik programu Visio tej architektury.

1. Klienci inicjują żądanie aplikacji app.contoso.com ze środowiska lokalnego.

2. Nazwy FQDN aplikacji są konfigurowane przez lokalnego dostawcę DNS. Ten dostawca usług DNS może korzystać z lokalnych serwerów DNS Active Directory Domain Services (AD DS) lub innych rozwiązań partnerskich. Wpisy DNS dla każdej nazwy FQDN aplikacji są skonfigurowane tak, aby kierowały na prywatny adres IP instancji usługi Application Gateway.

3. Obwód usługi Azure ExpressRoute lub sieć VPN site-to-site zapewnia dostęp do usługi Application Gateway.

4. Sieciowa grupa zabezpieczeń jest skonfigurowana w podsieci AppGW , aby zezwalać na przychodzące żądania prywatne z lokalnych sieci klientów, z których pochodzi ruch. Ta konfiguracja zapewnia, że inne źródła ruchu prywatnego nie mogą bezpośrednio uzyskać dostępu do prywatnego adresu IP usługi Application Gateway.

5. Usługa Application Gateway ma odbiornik skonfigurowany na porcie 80 i porcie 443. Ruch jest kierowany do zaplecza na podstawie nazwy hosta określonej w odbiorniku.

6. Tylko ruch w sieci prywatnej dociera do zasobów obliczeniowych skonfigurowanych jako pula zaplecza w usłudze Application Gateway.

Components

• DNS to system, który mapuje nazwy domen na adresy IP, co umożliwia klientom lokalizowanie i łączenie się z usługami. W tej architekturze, w przypadku publicznego przepływu pracy w Internecie, należy skonfigurować publiczną strefę DNS z odpowiednim CNAME odpowiadającym FQDN punktu końcowego Azure Front Door. Po stronie prywatnej (firmowej), skonfiguruj lokalnego dostawcę DNS (np. AD DS DNS lub rozwiązanie partnerskie), aby każda aplikacja z nazwą FQDN była kierowana na prywatny adres IP usługi Application Gateway.

• Azure DNS Private Resolver to w pełni zarządzana usługa, która umożliwia rozwiązywanie nazw DNS między środowiskami lokalnymi i Azure bez wdrażania niestandardowych serwerów DNS. W tej architekturze usługa DNS Private Resolver umożliwia rozpoznawanie klientów lokalnych, dzięki czemu użytkownicy korporacyjni mogą używać tego rozwiązania DNS podzielonego mózgu do uzyskiwania dostępu do aplikacji bez przechodzenia przez publiczny Internet.

• Azure Front Door to globalny równoważnik obciążenia i WAF, który zapewnia szybkie i bezpieczne dostarczanie aplikacji internetowych klientom na całym świecie. W tej architekturze Azure Front Door Standard lub Premium kieruje klientów zewnętrznych do instancji Application Gateway i udostępnia opcje buforowania i optymalizacji w celu poprawy doświadczeń klientów.

• Application Gateway to regionalny moduł równoważenia obciążenia i WAF, który zapewnia wysoką dostępność, skalowalność i bezpieczeństwo aplikacji internetowych. W tej architekturze usługa Application Gateway kieruje żądania klientów zewnętrznych i wewnętrznych do obliczeń zaplecza i chroni aplikację internetową przed typowymi atakami internetowymi.

  Zarówno Azure Front Door, jak i Application Gateway zapewniają możliwości zapory aplikacji internetowej, ale prywatny przepływ pracy w tym rozwiązaniu nie korzysta z Azure Front Door. W rezultacie obie architektury korzystają z funkcjonalności Application Gateway WAF.

• ExpressRoute to usługa, która rozszerza sieci lokalne na chmurę za pośrednictwem połączenia prywatnego ustanowionego przez dostawcę łączności. W tej architekturze usługa ExpressRoute ułatwia prywatną łączność z usługą Application Gateway dla klientów lokalnych.

Alternatives

Alternatywnie można usunąć Azure Front Door Standard lub Premium i zamiast tego wskazać publiczny rekord DNS na publiczny adres IP usługi Application Gateway. Na podstawie wymagań tej architektury należy buforować i zoptymalizować ruch w punkcie wejściowym do Azure. W związku z tym nie można użyć alternatywnego rozwiązania dla tego scenariusza. Aby uzyskać więcej informacji, zobacz Optymalizacja kosztów.

Strzałka dwustronna wskazuje od app.contoso.com do internetu. Kolejna dwukierunkowa strzałka wskazuje z Internetu do strefy Azure DNS dla contoso.com. Strzałka oznaczona etykietą 207.x.x.x (pip-appgw) wskazuje publiczny punkt końcowy adresu IP usługi Application Gateway skojarzony z podsiecią AppGW. Strzałka wskazuje z publicznego punktu końcowego adresu IP usługi Application Gateway do aplikacji w podsieci aplikacji.

Pobierz plik programu Visio tej architektury.

Inne możliwe alternatywy dla publicznego ruchu przychodzącego w tej architekturze obejmują:

• Azure Traffic Manager: Traffic Manager to oparta na systemie DNS usługa routingu ruchu, która dystrybuuje ruch między różnymi regionami i punktami końcowymi. Możesz użyć usługi Traffic Manager zamiast Azure Front Door w warstwie Standardowa lub Premium, aby kierować klientów zewnętrznych do najbliższego wystąpienia usługi Application Gateway. Jednak usługa Azure Front Door udostępnia funkcje, takie jak możliwości zapory aplikacji internetowej, buforowanie i powiązanie sesji. Usługa Traffic Manager nie udostępnia tych funkcji.

• Azure Load Balancer: Usługa Azure Load Balancer to moduł równoważenia obciążenia sieciowego, który zapewnia wysoką dostępność i skalowalność ruchu protokołu TRANSMISSION Control Protocol (TCP) i protokołu UDP (User Datagram Protocol). Usługi Load Balancer zamiast usługi Application Gateway można użyć do kierowania żądań klientów zewnętrznych i wewnętrznych do serwerów internetowych zaplecza. Jednak usługa Application Gateway udostępnia funkcje, takie jak możliwości WAF, zakończenie sesji SSL i przyleganie sesji oparte na ciasteczkach. Usługa Load Balancer nie udostępnia tych funkcji.

Szczegóły scenariusza

Ten scenariusz rozwiązuje problem hostowania aplikacji internetowej, która obsługuje zarówno klientów zewnętrznych, jak i wewnętrznych. Ta architektura zapewnia, że ruch jest kierowany odpowiednią ścieżką w oparciu o pochodzenie klienta. Ta architektura:

• Zapewnia szybki i niezawodny dostęp przez Internet do aplikacji internetowej dla globalnych klientów niebędących przedsiębiorstwami.

• Zapewnia klientom korporacyjnym możliwość uzyskiwania dostępu do aplikacji bez przechodzenia przez publiczny Internet.

• Chroni aplikację internetową przed typowymi atakami internetowymi i złośliwym ruchem.

Potencjalne przypadki użycia

Użyj tej architektury w scenariuszach, które wymagają:

• Split-brain DNS: To rozwiązanie używa Azure Front Door dla klientów zewnętrznych i usługi Application Gateway dla klientów wewnętrznych z różnymi rekordami DNS dla każdej usługi. Takie podejście ułatwia optymalizowanie wydajności sieci, zabezpieczeń i dostępności dla różnych klientów.

• Skalowalność aplikacji: To rozwiązanie korzysta z usługi Application Gateway, która może dystrybuować ruch między skonfigurowanymi zasobami obliczeniowymi zaplecza. Takie podejście pomaga zwiększyć wydajność i dostępność aplikacji oraz obsługiwać skalowanie w poziomie.

Considerations

Te zagadnienia obejmują implementację filarów platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Reliability

Niezawodność pomaga zapewnić, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Design review checklist for Reliability(Lista kontrolna dotycząca niezawodności).

• Identyfikowanie punktów awarii. W tej architekturze DNS podzielonego mózgu niezawodność zależy od prawidłowego funkcjonowania kluczowych składników, takich jak Azure Front Door, Application Gateway i konfiguracje DNS. Należy zidentyfikować potencjalne punkty awarii, takie jak błędy konfiguracji, problemy z certyfikatami SSL lub przeciążenia pojemności.

• Ocena wpływu. Należy ocenić wpływ awarii. W przypadku klientów zewnętrznych wszelkie zakłócenia w usłudze Azure Front Door, które służą jako brama, mogą mieć wpływ na dostęp globalny. W przypadku klientów wewnętrznych wszelkie zakłócenia w usłudze Application Gateway mogą utrudniać operacje przedsiębiorstwa.

• Implementowanie strategii ograniczania ryzyka. Aby ograniczyć ryzyko, należy zaimplementować nadmiarowość w wielu strefach dostępności, używać sond kondycji do monitorowania w czasie rzeczywistym i zapewnić poprawną konfigurację routingu DNS zarówno dla ruchu zewnętrznego, jak i wewnętrznego. Upewnij się, że regularnie aktualizujesz rekordy DNS i masz plan odzyskiwania po awarii.

• Monitoruj w sposób ciągły. Aby zachować czujne oko na kondycję systemu, należy stosować funkcje Azure Monitor. Skonfiguruj alerty dotyczące anomalii i przygotuj plan reagowania na zdarzenia, aby szybko rozwiązać potencjalne problemy.

Przestrzegaj tych zasad, aby zapewnić niezawodny i niezawodny system, który może wytrzymać wyzwania i utrzymać ciągłość usług.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.

• Użyj podejścia Zero Trust. W konfiguracji DNS z podzielonym mózgiem zastosuj podejście Zero Trust. Jawnie zweryfikuj tożsamość klienta, niezależnie od tego, czy pochodzi z Internetu, czy z sieci firmowej. Takie podejście zapewnia, że tylko zaufane jednostki mogą wykonywać autoryzowane akcje.

• Efektywna implementacja mechanizmów tożsamości i kontroli dostępu. Zaimplementuj Microsoft Entra ID w celu niezawodnego zarządzania tożsamościami. Zasady dostępu warunkowego firmy Microsoft Entra umożliwiają wymuszanie ścisłej kontroli dostępu na podstawie kontekstu klienta, kondycji urządzenia i lokalizacji.

  • Oceń środki zabezpieczeń. Oceń skuteczność środków zabezpieczeń dla obciążenia z podwójnym dostępem, implementując:

    • Regularnie oceniaj swoje inwestycje obronne. Regularnie oceniaj skuteczność Azure Front Door i usługi Application Gateway. Upewnij się, że zapewniają znaczącą ochronę przed zagrożeniami.

    • Ogranicz zakres wpływu potencjalnych naruszeń. Upewnij się, że naruszenia zabezpieczeń są ograniczone do wąskiego zakresu. Na przykład skutecznie izoluj przepływy ruchu zewnętrznego i wewnętrznego.

• Załóżmy, że naruszenie jest zawsze możliwe. Potwierdź, że osoby atakujące mogą naruszać mechanizmy kontroli zabezpieczeń. Przygotuj się do takich scenariuszy.

• Kompleksowo zaimplementuj środki zabezpieczeń. Zaimplementuj segmentację sieci, mikrosegmentację i sieciowe grupy zabezpieczeń. Załóżmy, że osoba atakująca może uzyskać dostęp, i zaprojektuj odpowiednie kompensujące mechanizmy kontrolne.

Zintegruj te zasady bezpieczeństwa z architekturą split-brain DNS, aby stworzyć niezawodny i odporny system, który chroni wewnętrzny i zewnętrzny dostęp do Twoich zasobów.

Inne ulepszenia zabezpieczeń

• Application Gateway: Możesz użyć Web Application Firewall (WAF) w ramach Application Gateway, aby chronić swoje aplikacje internetowe przed typowymi lukami w zabezpieczeniach i exploitami. Możesz również użyć usługi Azure Private Link , aby bezpiecznie uzyskać dostęp do serwerów aplikacji zaplecza z usługi Application Gateway bez uwidaczniania ich w publicznym Internecie.

• Azure Firewall: Możesz dodać Azure firewall do sieci wirtualnej centrum i użyć Azure Firewall analizy zagrożeń aby zablokować złośliwy ruch ze znanych złośliwych adresów IP i domen. Usługę Azure Firewall można również użyć jako serwera proxy DNS , aby przechwycić i sprawdzić ruch DNS oraz zastosować reguły filtrowania DNS.

• Azure Front Door: Możesz użyć Azure Web Application Firewall w celu ochrony aplikacji internetowych przed typowymi lukami w zabezpieczeniach i programami wykorzystującymi luki w zabezpieczeniach na brzegu sieci Web. Możesz również użyć usługi Private Link z warstwą Premium usługi Azure Front Door, aby bezpiecznie uzyskać dostęp do serwerów aplikacji zaplecza z usługi Azure Front Door bez uwidaczniania ich w publicznym Internecie.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.

• Obliczenia zaplecza: Wiele czynników, takich jak wybór jednostki SKU, liczba replik i region, napędzają koszt uruchamiania usług obliczeniowych zaplecza. Przed wybraniem najlepszej opcji dla obciążenia należy wziąć pod uwagę wszystkie elementy zasobu obliczeniowego .

• Application Gateway: Koszty usługi Application Gateway zależą od liczby wystąpień, rozmiaru wystąpień i ilości przetworzonych danych. Koszt można zoptymalizować przy użyciu skalowania automatycznego , aby dostosować liczbę wystąpień na podstawie zapotrzebowania na ruch. Można również wdrożyć jednostki SKU strefowo nadmiarowe w strefach dostępności, aby zmniejszyć potrzebę dodatkowych wystąpień w celu zapewnienia wysokiej dostępności.

• Azure Front Door: Azure Front Door koszty zależą od liczby reguł routingu, liczby żądań HTTP lub HTTPS oraz ilości przesyłanych danych. Możesz użyć Azure Front Door Standard lub Premium, aby uzyskać ujednolicone środowisko pracy z Azure Content Delivery Network, Azure Web Application Firewall i Private Link. Możesz również użyć funkcji silnika reguł usługi Azure Front Door, aby dostosować zarządzanie ruchem i zoptymalizować wydajność i koszty.

Jeśli twój scenariusz nie wymaga dostępu globalnego ani dodatkowych funkcji usługi Azure Front Door, możesz użyć tego rozwiązania tylko z usługą Application Gateway. Wszystkie publiczne rekordy DNS można wskazać na publiczny adres IP skonfigurowany na odbiornikach usługi Application Gateway.

Zapoznaj się z przykładem tego rozwiązania , które przybliża typowe użycie składników w tej architekturze. Dostosuj koszty, aby dopasować je do danego scenariusza.

Contributors

Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Troy Hite | Starszy inżynier rozwiązań

Inni współautorzy:

• Mays Algebary | Starszy specjalista ds. sieci Azure Global Blackbelt
• Michael McKechney | Główny specjalista ds. technologii platformy Azure
• Adam Torkar | Senior Azure Networking Global Blackbelt

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

Dalsze kroki

• Konfiguracja infrastruktury usługi Application Gateway
• Od końca do końca TLS z usługą Azure Front Door
• Dodawanie domeny niestandardowej do usługi Azure Front Door
• Co to jest filtrowanie geograficzne w domenie dla usługi Azure Front Door

Powiązane zasoby

• Zapora i bramka aplikacyjna dla sieci wirtualnych
• Korzystanie z usługi Azure Front Door w rozwiązaniu wielodostępnym