Migrowanie i modernizacja ścieżki projektowania sieci

Ten przewodnik przedstawia uporządkowaną ścieżkę lektury przewodnika Azure Networking Design Guide dla klientów wdrażających usługi platformowe (PaaS), kontenery i zarządzane bazy danych. Wykonaj ponumerowane kroki, aby utworzyć wieloregionową sieć warstwową zabezpieczeń, która obsługuje nowoczesne architektury aplikacji.

Overview

Projekty migracji i modernizacji wykraczają poza maszyny wirtualne i obejmują usługi natywne dla platformy Azure: Azure Kubernetes Service (AKS) dla kontenerów, Azure App Service dla aplikacji internetowych, Azure SQL Database i Azure Cosmos DB do zarządzanych baz danych oraz Azure Front Door do globalnej dystrybucji ruchu. Sieć musi obsługiwać prywatną łączność z tymi usługami PaaS, wdrożenia typu active-active obejmujące wiele regionów oraz ścisłą segmentację zabezpieczeń między warstwami aplikacyjnymi.

Architektura docelowa korzysta z topologii z dwoma centrami obejmującymi dwa Azure regiony. Sieci wirtualne koncentratora zarządzane przez dział IT obsługują usługi współdzielone, takie jak Azure Firewall i VPN Gateway. Zespoły aplikacyjne mają własne sieci wirtualne typu spoke i zarządzają własnymi podsieciami Private Link na potrzeby łączności z usługami PaaS. Ruch wchodzi przez Azure Front Door lub Azure Traffic Manager, przechodzi przez inspekcję zapory koncentratora i dociera do usług aplikacyjnych uruchomionych w izolowanych szprychach.

Ta ścieżka do czytania zawiera 14 podstawowych artykułów w pięciu fazach. Ta droga jest dłuższa niż „lift and shift”, ponieważ nowoczesne architektury wymagają podjęcia decyzji dotyczących wzorców ruchu wejściowego, łączności z prywatnym środowiskiem PaaS, zapór aplikacji internetowych i ochrony przed atakami DDoS, które w projektach opartych wyłącznie na IaaS można odłożyć na później. Dwa kamienie milowe pomagają określić, kiedy można przejść dalej, jeśli obciążenie robocze nie wymaga wszystkich komponentów.

Prerequisites

  • Zapoznaj się z omówieniem planowania i projektowania sieci platformy Azure, aby zapoznać się z dostępnymi usługami.
  • Dowiedz się, które usługi PaaS są przeznaczone dla Twoich aplikacji (AKS, App Service, Azure SQL, Azure Cosmos DB lub inne).
  • Ustal, czy wdrożenie obejmuje wiele regionów platformy Azure (aktywna-aktywna lub aktywna-pasywna).
  • Zidentyfikuj wzorzec ruchu przychodzącego: czy aplikacja obsługuje publiczny ruch internetowy, ruch interfejsu API dla urządzeń przenośnych lub ruch tylko do wewnątrz?

Ścieżka do czytania

Faza 1: Podstawy

1. Sieci wirtualne i podsieci

Umożliwia ustawianie rozmiaru podsieci dla pul węzłów usługi AKS, podsieci delegowanych App Service Environment (ASE) i podsieci Private Link. Gdy używasz funkcji AKS Container Networking Interface (CNI) Overlay, adresy IP zasobników pochodzą z oddzielnego zakresu CIDR sieci nakładkowej i nie zużywają przestrzeni adresowej podsieci sieci wirtualnej. Tylko adresy IP węzłów wymagają adresów podsieci. Zaplanuj zakres adresów CIDR sieci nakładkowej tak, aby uwzględnić planowaną skalę zasobników, i przydziel dedykowane podsieci dla każdego typu usługi.

2. Planowanie adresów IP

Zaplanuj przydział adresów IP w dwóch regionach dla wdrożenia active-active. Regiony podstawowe i zapasowe wymagają nienakładających się przestrzeni adresowych, które obsługują komunikację równorzędną sieci wirtualnych i replikację między regionami. Przydziel wystarczająco duże zakresy, aby uwzględnić przyszłe dodatki szprych.

3. Sieciowe grupy zabezpieczeń i grupy zabezpieczeń aplikacji

Zaprojektuj ścisłą segmentację, aby tylko ruch modułu równoważenia obciążenia docierał do podsieci aplikacji. Blokuj bezpośredni dostęp do Internetu do warstw aplikacji. Użyj grup zabezpieczeń aplikacji (ASG), aby stosować reguły na podstawie roli obciążenia zamiast poszczególnych adresów IP.

Faza 2. Topologia

4. Topologia piasty i szprych

Wdróż topologię z dwoma koncentratorami dla wielu regionów. Subskrypcja IT obejmuje zarówno centralne sieci wirtualne, jak i zarządza usługami współdzielonymi, takimi jak Azure Firewall, VPN Gateway i serwery przekazujące DNS. Zespoły aplikacyjne są właścicielami swoich sieci wirtualnych typu spoke i zarządzają podsieciami Private Link, klastrami AKS oraz zasobami aplikacji w ramach przydzielonej im przestrzeni adresowej.

5. Sieć w wielu regionach

Zaprojektuj wdrożenie typu active-active obejmujące region podstawowy i zapasowy. Skonfiguruj peering sieci wirtualnych między regionami między hubami, skonfiguruj routing przełączania awaryjnego i zaplanuj działanie na wypadek awarii pojedynczego regionu. Oba regiony obsługują ruch jednocześnie, przy czym Azure Front Door rozdziela żądania na podstawie opóźnień i sond kondycji usługi.

Note

Punkt kontrolny: Topologia ukończona. Topologia wieloregionowa z dwoma koncentratorami jest wdrożona. Jeśli aplikacja jest tylko wewnętrzna bez punktów końcowych dostępnych z Internetu, możesz przejść do kroku 9 (wychodzący dostęp do Internetu) i kontynuować z tego miejsca.

Co pomijasz: Kroki 6–8 obejmują ruch przychodzący z Internetu, dostarczanie i wydajność aplikacji oraz dostęp prywatny usługi PaaS. Pominięcie tego jest bezpieczne, jeśli Twoje obciążenie robocze nie ma publicznie dostępnych punktów końcowych i nie wymaga usługi Private Link.

Ważne: Nawet aplikacje tylko wewnętrzne często potrzebują Private Link (krok 8), jeśli łączą się z Azure SQL, Azure Storage, Azure Key Vault lub innymi usługami PaaS za pośrednictwem prywatnych punktów końcowych. Jeśli aplikacja korzysta z dowolnej z tych usług, wykonaj krok 8 przed przejściem do kroku 9.

Pozostałe artykuły: Sześć artykułów po pomijaniu (kroki 9–14) w porównaniu do dziewięciu artykułów bez pomijania (kroki 6–14).

Faza 3. Łączność

6. Ruch przychodzący z Internetu

Wzorce ruchu skierowane do klientów określają zewnętrzny kształt architektury. Użyj Azure Front Door dla aplikacji internetowych, które wymagają globalnego równoważenia obciążenia, buforowania i Web Application Firewall (WAF). Użyj usługi Azure Traffic Manager w przypadku aplikacji mobilnych lub interfejsów API, gdy wystarczy routing oparty na DNS z sondami kondycji.

7. Dostarczanie i wydajność aplikacji

Wybierz między Azure Front Door a Azure Traffic Manager na podstawie typu aplikacji. Aplikacje internetowe korzystają z możliwości warstwy 7 usługi Front Door: odciążania protokołu TLS, buforowania, routingu opartego na adresach URL i zintegrowanej zapory aplikacji internetowych. Zaplecza dla urządzeń przenośnych i interfejsów API używają usługi Traffic Manager na potrzeby trybu failover na poziomie DNS z niższym obciążeniem.

8. Dostęp prywatny PaaS

Utwórz podsieci Private Link w każdej szprychowej sieci wirtualnej na potrzeby łączności z usługami PaaS. Zespoły aplikacji zarządzają własnymi prywatnymi punktami końcowymi: usługa AKS ściąga obrazy kontenerów za pośrednictwem Private Link, aplikacje internetowe łączą się z Azure SQL za pośrednictwem prywatnych punktów końcowych, a żaden ruch PaaS nie przechodzi przez publiczny Internet. Przeznacz oddzielną podsieć dla każdej szprychy na potrzeby zasobów Private Link.

Note

Punkt kontrolny: łączność została ukończona. Skonfigurowano dostęp przychodzący oraz prywatną łączność z usługą PaaS.

Pozostałe kroki: ruch wychodzący (krok 9), Azure Firewall (krok 10), Web Application Firewall (krok 11), ochrona przed atakami DDoS (krok 12), zabezpieczenia DNS (krok 13) i monitorowanie sieci (krok 14), łącznie 6 artykułów.

Niezbędne dla wszystkich wdrożeń: Kroki 9–10 (ruch wychodzący i Azure Firewall) dotyczą każdego wdrożenia modernizacji. Zapora centrum kontroluje cały ruch wychodzący i zapewnia scentralizowaną inspekcję niezależnie od tego, czy obciążenie jest dostępne publicznie, czy tylko wewnętrzne.

Tylko publicznie dostępne punkty końcowe: Kroki 11–12 (WAF i ochrona przed atakami DDoS) mają zastosowanie wyłącznie wtedy, gdy aplikacja udostępnia publicznie dostępne punkty końcowe za pośrednictwem usług Azure Front Door, Application Gateway lub publicznego modułu równoważenia obciążenia. Obciążenia tylko wewnętrzne mogą pominąć te dwa artykuły i przejść do kroku 13 (zabezpieczenia DNS).

9. Wychodzący dostęp do Internetu

Kieruj cały ruch wychodzący z sieci szprychowych do zapory w koncentratorze przy użyciu tras zdefiniowanych przez użytkownika (UDR). Zapora węzła centralnego pełni funkcję punktu translacji adresów sieciowych źródła (SNAT) dla całego ruchu wychodzącego. IT centralnie zarządza regułami zapory, dzięki czemu zespoły aplikacyjne nie mogą obchodzić mechanizmów kontroli ruchu wychodzącego.

Faza 4. Zabezpieczenia

10. Azure Firewall

Skonfiguruj usługę Azure Firewall w obu centralnych sieciach wirtualnych jako punkt translacji adresów sieciowych źródłowych (SNAT) i docelowych (DNAT). Cały ruch przychodzący przechodzi przez zaporę przed dotarciem do warstwy aplikacji. Użyj zasad zapory, aby kontrolować ruch wschodnio-zachodni między szprychami a ruchem północno-południowym do Internetu.

11. Web Application Firewall

Wdróż WAF w usłudze Azure Front Door lub Azure Application Gateway dla swoich aplikacji internetowych. Zapora aplikacji internetowych (WAF) chroni przed 10 najpoważniejszymi zagrożeniami według projektu Open Web Application Security Project (OWASP), atakami typu SQL injection, cross-site scripting oraz innymi atakami na warstwie HTTP. Użyj zarządzanych zestawów reguł i dodaj reguły niestandardowe dla określonych wzorców aplikacji.

12. Ochrona przed atakami DDoS

Włącz ochronę przed atakami DDoS platformy Azure dla wszystkich zasobów publicznych adresów IP. Usługa DDoS Protection zapewnia zawsze włączone monitorowanie ruchu, automatyczne ograniczanie ryzyka ataków i gwarancje ochrony kosztów. Połącz ochronę przed atakami DDoS z WAF, aby zapewnić wielowarstwową ochronę przed atakami wolumetrycznymi i atakami na warstwę aplikacji.

13. Zabezpieczenia DNS i rozpoznawanie nazw prywatnych

Skonfiguruj publiczne strefy DNS dla domen skierowanych do klientów przy użyciu rekordów CNAME wskazujących na punkty końcowe usługi Azure Front Door lub Traffic Manager. Zastosuj Role-Based Access Control (RBAC) do stref DNS, aby tylko autoryzowane zespoły mogły modyfikować rekordy. Włącz rozszerzenia zabezpieczeń DNS (DNSSEC) dla stref, które wymagają weryfikacji kryptograficznych.

Faza 5. Operacje

14. Monitorowanie i obserwowanie sieci

Gotowość produkcyjna wymaga monitorowania od pierwszego dnia. Włącz Azure Network Watcher na potrzeby diagnostyki łączności, monitor wydajności sieci na potrzeby śledzenia opóźnień i dzienników przepływu na potrzeby analizy ruchu. Zespoły aplikacji monitorują własne obciążenia usług AKS i ASE. Zespół platformy monitoruje infrastrukturę koncentratora i łączność między regionami.

Artykuły warunkowe

Uwzględnij następujące artykuły na podstawie określonych wymagań:

Warunek Artykuł Kiedy należy uwzględnić
Współistnienie hybrydowe Łączność hybrydowa Zmodernizowane aplikacje muszą współistnieć z systemami lokalnymi w okresie przejściowym
Wymagany jest dostęp administratora maszyny wirtualnej Dostęp dewelopera i administratora Twoje środowisko obejmuje maszyny wirtualne, które wymagają bezpiecznego dostępu RDP/SSH, a także obciążenia PaaS
Duży majątek zarządzany Scentralizowane zarządzanie siecią Zarządzasz środowiskiem sieci wirtualnych (VNet) obejmującym wiele subskrypcji i zespołów, które wymaga scentralizowanego egzekwowania zasad
Między chmurami Łączność międzyregionowa i wielochmurowa Architektura wymaga jawnej łączności prywatnej między regionami poza siecią obejmującą wiele regionów
Bardzo małe obciążenie Topologia sieci płaskiej Masz pojedyncze obciążenie, które nie uzasadnia złożoności topologii piasty i szprych

Podsumowanie

Podążając tą ścieżką lektury, zaprojektowałeś wieloregionową, wielowarstwowo zabezpieczoną architekturę sieci dla obciążeń PaaS. Projekt obejmuje topologię dwóch koncentratorów ze współdzielonymi usługami zarządzanymi przez dział IT, architekturę active-active obejmującą wiele regionów z użyciem Azure Front Door lub Azure Traffic Manager, łączność Private Link dla usług PaaS, scentralizowaną inspekcję ruchu przez zaporę dla wszystkich przepływów ruchu, ochronę WAF i przed atakami DDoS dla publicznych punktów końcowych oraz DNS z mechanizmem RBAC i DNSSEC. Ta architektura obsługuje nowoczesne wzorce aplikacji przy zachowaniu scentralizowanego ładu zabezpieczeń.

Lista kontrolna weryfikacji poprawności

Użyj tej listy kontrolnej, aby potwierdzić, że projekt sieci modernizacji został ukończony:

  • Topologia dual-hub została wdrożona w regionach podstawowym i zapasowym.
  • Nienakładające się przestrzenie adresowe przydzielone zarówno regionom, jak i przyszłym spoke’om.
  • Azure Front Door lub Azure Traffic Manager skonfigurowane do obsługi globalnego ruchu wejściowego, jeśli obciążenie jest skierowane do odbiorców publicznych.
  • Podsieci Private Link utworzone w każdej sieci wirtualnej typu spoke, w której hostowane są zależności PaaS.
  • Trasy definiowane przez użytkownika kierują ruch wychodzący z sieci spoke przez zaporę centrum.
  • Azure Firewall wdrożona w obu centralnych sieciach wirtualnych do inspekcji ruchu przychodzącego, wschodnio-zachodniego i wychodzącego.
  • Zasady WAF stosowane w odniesieniu do publicznych internetowych punktów końcowych, jeśli dotyczy.
  • Ochrona przed atakami DDoS włączona w zasobach publicznych adresów IP, jeśli ma to zastosowanie.
  • Strefy DNS i prywatne rozpoznawanie nazw DNS skonfigurowane dla prywatnych punktów końcowych.
  • Włączone: Network Watcher, dzienniki przepływu i monitorowanie łączności między regionami.

Następne kroki

  • Last updated on