Implementacja wzorca dla bezpiecznego ruchu przychodzącego sieci

Bezpieczny ruch przychodzący sieci hermetyzuje kilka wzorców projektowych, w tym wzorce routingu globalnego, globalne odciążanie i monitorowanie punktu końcowego kondycji. Implementację wzorca w tym artykule można użyć jako bramy dla dowolnego obciążenia HTTP lub HTTPS, które wymaga wysokiej dostępności lub niezawodności, zapewniając bezpieczny globalny routing dla obciążeń w różnych regionach z trybem failover o małych opóźnieniach.

Wideo: Implementacja bezpiecznego ruchu przychodzącego sieci

Wymagania dotyczące wzorca

W tym artykule opisano trzy wymagania, na których koncentruje się implementacja wzorca dla bezpiecznego ruchu przychodzącego sieci: routing globalny, tryb failover o małych opóźnieniach i ograniczanie ataków na brzegu sieci.

Routing globalny

Wzorzec bezpiecznego ruchu przychodzącego sieci hermetyzuje wzorzec routingu globalnego. W związku z tym implementacja może kierować żądania do obciążeń w różnych regionach.

Diagram przedstawiający żądanie HTTPS kierowane do dwóch obciążeń w różnych regionach.

Tryb failover z małym opóźnieniem

Implementacja musi być w stanie zidentyfikować obciążenia w dobrej kondycji i złej kondycji oraz odpowiednio dostosować routing w sposób wrażliwy na czas. Opóźnienie powinno być w stanie obsługiwać dostosowywanie routingu w ciągu kilku minut.

Diagram przedstawiający żądanie HTTPS, które nie jest kierowane do obciążenia w złej kondycji.

Ograniczanie ataków na brzegu sieci

Łagodzenie ataków na brzegu sieci wymaga części implementacji "zabezpieczonej sieci". Obciążenia lub usługi platformy jako usługi (PaaS) nie powinny być dostępne za pośrednictwem Internetu. Ruch internetowy powinien być w stanie kierować tylko przez bramę. Brama powinna mieć możliwość ograniczenia luk w zabezpieczeniach.

Diagram przedstawiający żądanie HTTPS z instrukcją SQL w ciągu zapytania żądania, które nie jest zatrzymywane na krawędzi.

Wzorce

To rozwiązanie implementuje następujące wzorce projektowe:

Projekt

Diagram przedstawiający żądanie przepływające przez usługę Azure Front Door Premium do sygnatur regionalnych.

Na diagramie przedstawiono żądanie HTTPS przepływające do usługi Azure Front Door Premium, które ma w nim zaporę aplikacji internetowej. Ilustruje to integrację między usługą Azure Front Door Premium i usługą Azure Web Application Firewall. Na diagramie przedstawiono żądanie przepływające przez Private Link do dwóch sygnatur w różnych regionach. Każda sygnatura ma statyczną witrynę internetową i wewnętrzny moduł równoważenia obciążenia. Żądania przepływają przez Private Link do statycznych witryn internetowych i modułów równoważenia obciążenia w obu sygnaturach.

Ta implementacja zawiera następujące szczegóły:

  • Używa Azure Blob Storage kont do symulowania statycznych obciążeń internetowych działających w dwóch regionach. Ta implementacja nie obejmuje żadnych obciążeń uruchomionych za wewnętrznym modułem równoważenia obciążenia (ILB). Na diagramie przedstawiono wewnętrzny moduł równoważenia obciążenia, aby zilustrować, że ta implementacja będzie działać w przypadku obciążeń prywatnych działających za wewnętrznym modułem równoważenia obciążenia.
  • Używa ona warstwy Premium usługi Azure Front Door jako bramy globalnej.
  • Wystąpienie usługi Azure Front Door ma globalne zasady zapory aplikacji internetowej skonfigurowane przy użyciu reguł zarządzanych, które pomagają chronić przed typowymi programami wykorzystującymi luki w zabezpieczeniach.
  • Konta magazynu nie są udostępniane przez Internet.
  • Warstwa Premium usługi Azure Front Door uzyskuje dostęp do kont magazynu za pośrednictwem Azure Private Link.
  • Wystąpienie usługi Azure Front Door ma następującą konfigurację wysokiego poziomu:
    • Punkt końcowy z pojedynczą trasą wskazującą pojedynczą grupę źródeł. Grupa pochodzenia to kolekcja źródeł lub zaplecza.
    • Grupa źródeł ma źródło skonfigurowane tak, aby wskazywało każde konto magazynu.
    • Każde źródło żąda Private Link dostępu do konta magazynu.
    • Grupa źródeł ma sondy kondycji skonfigurowane do uzyskiwania dostępu do strony HTML na kontach magazynu. Strona HTML działa jako punkt końcowy kondycji dla obciążeń statycznych. Jeśli sondy mogą pomyślnie uzyskać dostęp do źródła w trzech z ostatnich czterech prób, źródło jest uznawane za zdrowe.

Składniki

Żądanie internetowe

  • Azure Web Application Firewall: warstwa Premium Web Application Firewall obsługuje reguły zarządzane przez firmę Microsoft, które pomagają chronić przed typowymi programami wykorzystującymi luki w zabezpieczeniach.
  • Azure Private Link: Prywatne punkty końcowe w Azure Private Link uwidaczniają usługę Azure PaaS na prywatny adres IP w sieci wirtualnej. Ta ekspozycja pozwala na przepływ komunikacji przez sieć szkieletową firmy Microsoft, a nie w publicznym Internecie.
  • Warstwa Premium usługi Azure Front Door: usługa Azure Front Door zapewnia globalne równoważenie obciążenia warstwy 7. Usługa Azure Front Door ma integrację z usługą Web Application Firewall. Warstwa Premium obsługuje:
    • Azure Private Link: obsługa Private Link umożliwia usłudze Azure Front Door komunikowanie się z usługami PaaS lub obciążeniami działającymi w prywatnej sieci wirtualnej za pośrednictwem sieci szkieletowej firmy Microsoft.
    • Zestawy reguł zarządzanych przez firmę Microsoft: warstwa Premium usługi Azure Front Door obsługuje warstwę Premium Web Application Firewall, która obsługuje zestaw reguł zarządzanych w zaporze aplikacji internetowej.
  • Azure Storage: Ta implementacja używa kont usługi Blob Storage do reprezentowania statycznej witryny internetowej lub obciążenia.
  • Wewnętrzny moduł równoważenia obciążenia: ta implementacja nie używa wewnętrznego modułu równoważenia obciążenia. Na zdjęciu przedstawiono reprezentację prywatnego obciążenia uruchomionego za tym modułem równoważenia obciążenia. Routing do konta magazynu jest taki sam, jak w przypadku modułów równoważenia obciążenia.

Operacje

Zabezpieczanie zasobów z perspektywy sieci pomaga chronić przed programami wykorzystującymi luki w zabezpieczeniach, ale także izoluje zasoby od procesów lub administratorów, którzy mogą potrzebować dostępu do tych zasobów. Na przykład agent kompilacji w potoku DevOps może wymagać dostępu do konta magazynu, aby wdrożyć aktualizację w aplikacji internetowej. Ponadto administrator może potrzebować dostępu do zasobu na potrzeby rozwiązywania problemów.

Aby zilustrować zapewnienie dostępu do bezpiecznego dostępu do sieci w celach operacyjnych, ta implementacja wdraża maszynę wirtualną w sieci wirtualnej, która ma Private Link dostęp do kont magazynu. Ta implementacja wdraża usługę Azure Bastion, której administrator może użyć do nawiązania połączenia z maszyną wirtualną. W scenariuszu wdrażania można wdrożyć prywatnego agenta kompilacji w sieci wirtualnej, podobnie jak w przypadku maszyny wirtualnej.

Poniżej przedstawiono szczegółowe informacje o składnikach operacji:

  • Azure Virtual Network: ta implementacja używa sieci wirtualnej do przechowywania składników wymaganych przez administratora do bezpiecznego komunikowania się z kontem magazynu za pośrednictwem prywatnej sieci szkieletowej firmy Microsoft.
  • Azure Virtual Machines: Ta implementacja używa maszyny wirtualnej jako serwera przesiadkowego, z którymi administratorzy mogą się łączyć. Maszyna wirtualna jest wdrażana w prywatnej sieci wirtualnej.
  • Azure Bastion: usługa Azure Bastion umożliwia administratorowi bezpieczne łączenie się z maszyną wirtualną serwera przesiadkowego za pośrednictwem protokołu Secure Shell (SSH) bez konieczności posiadania publicznego adresu IP przez maszynę wirtualną.
  • Private Link punkt końcowy: prywatny punkt końcowy ma przypisany prywatny adres IP z sieci wirtualnej i łączy się z usługą PaaS konta magazynu. To połączenie umożliwia zasobom w prywatnej sieci wirtualnej komunikowanie się z kontem magazynu za pośrednictwem prywatnego adresu IP.
  • Prywatna strefa DNS platformy Azure: prywatna strefa Azure DNS jest usługą DNS używaną do rozpoznawania nazwy hosta Private Link konta usługi Azure Storage na prywatny adres IP prywatnego punktu końcowego.

Przepływ żądań internetowych

Diagram przedstawiający przepływ żądania internetowego.

Na diagramie przedstawiono użytkownika wysyłającego żądanie internetowe do usługi Azure Front Door. W polu Azure Front Door diagram przedstawia każdy z kroków przepływu routingu usługi Azure Front Door. Wyróżniony w przepływie jest krokiem, w którym są oceniane reguły zapory aplikacji internetowej, gdzie jest dopasowywana trasa usługi Azure Front Door, a grupa pochodzenia jest zaznaczona i gdzie źródło jest wybierane z grupy źródeł. Ostatni wyróżniony element to miejsce, w którym usługa Azure Front Door łączy się z kontem Azure Blob Storage za pośrednictwem Private Link.

  1. Użytkownik wysyła żądanie HTTP lub HTTPS do punktu końcowego usługi Azure Front Door.

  2. Reguły zapory aplikacji internetowej są oceniane. Reguły zgodne są zawsze rejestrowane. Jeśli tryb zasad zapory aplikacji internetowej usługi Azure Front Door jest ustawiony na zapobieganie , a reguła dopasowania ma ustawioną akcję blokującą anomalię, żądanie zostanie zablokowane. W przeciwnym razie żądanie jest kontynuowane lub przekierowywane albo kolejne reguły są oceniane.

  3. Trasa skonfigurowana w usłudze Azure Front Door jest dopasowywana i wybrano prawidłową grupę pochodzenia. W tym przykładzie ścieżka dotyczyła zawartości statycznej w witrynie internetowej.

  4. Źródło jest wybierane z grupy pochodzenia.

    a. W tym przykładzie sondy kondycji uznały witrynę internetową za złą kondycję, więc zostały wyeliminowane z możliwych źródeł.
    b. Ta witryna internetowa jest zaznaczona.

  5. Żądanie jest kierowane do konta usługi Azure Storage za pośrednictwem Private Link za pośrednictwem sieci szkieletowej firmy Microsoft.

Aby uzyskać więcej informacji na temat architektury routingu usługi Azure Front Door, zobacz Omówienie architektury routingu.

Przepływ operacyjny

Diagram przedstawiający przepływ używany przez administratora do nawiązywania połączenia z chronionym zasobem.

Diagram ma trzy części. Pierwsza część przedstawia Azure Blob Storage działając jako statyczna witryna internetowa. Usługa Azure Front Door łączy się za pośrednictwem Private Link z kontem magazynu. Druga część to pole reprezentujące sieć wirtualną. Sieć wirtualna ma podsieci i ich zawartość. Te podsieci obejmują podsieć prywatnego punktu końcowego, która zawiera punkt końcowy Private Link z adresem IP 10.0.2.5, podsiecią przesiadkową z maszyną wirtualną przesiadkową oraz podsiecią usługi Azure Bastion z usługą Azure Bastion. Trzecia część to użytkownik administracyjny, który używa protokołu SSH do uzyskiwania dostępu do maszyny wirtualnej przesiadkowej w sieci wirtualnej za pośrednictwem usługi Azure Bastion. Strzałka przechodzi z maszyny wirtualnej do prywatnej strefy DNS platformy Azure. Ostatnia strzałka przechodzi z maszyny wirtualnej do punktu końcowego łącza prywatnego, a następnie do konta magazynu.

  1. Administrator łączy się z wystąpieniem usługi Azure Bastion wdrożonym w sieci wirtualnej.

  2. Usługa Azure Bastion zapewnia łączność SSH z maszyną wirtualną przesiadkową.

  3. Administrator w polu przesiadkowym próbuje uzyskać dostęp do konta magazynu za pośrednictwem interfejsu wiersza polecenia platformy Azure. Serwer przesiadkowy wysyła zapytanie DNS do publicznego punktu końcowego konta Azure Blob Storage: storageaccountname.blob.core.windows.net.

    Prywatna strefa DNS ostatecznie rozwiązuje się z storageaccountname.privatelink.blob.core.windows.net. Zwraca prywatny adres IP punktu końcowego Private Link, czyli 10.0.2.5 w tym przykładzie.

  4. Połączenie prywatne z kontem magazynu jest ustanawiane za pośrednictwem punktu końcowego Private Link.

Zagadnienia do rozważenia

Podczas korzystania z tego rozwiązania należy pamiętać o następujących kwestiach.

Niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Omówienie filaru niezawodności.

Ten scenariusz dotyczy następujących kluczowych punktów dotyczących niezawodności:

  • Routing globalny z małym opóźnieniem dzięki użyciu sond kondycji umożliwia niezawodność przez izolowanie aplikacji przed awariami regionalnymi.
  • Web Application Firewall w usłudze Azure Front Door zapewnia scentralizowaną ochronę żądań HTTP i HTTPS.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.

Ten scenariusz dotyczy następujących kluczowych punktów dotyczących zabezpieczeń:

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.

Mimo że zarówno usługa Azure Front Door Premium, jak i Web Application Firewall Premium zapewniają zaawansowane funkcje zabezpieczeń w warstwie Standardowa, są naliczane dodatkowe koszty. Zapoznaj się z następującymi zasobami, aby dowiedzieć się więcej o cenach usługi Azure Front Door i Web Application Firewall:

Efektywność operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.

Implementowanie granic zabezpieczeń sieci zwiększa złożoność operacji i wdrażania. Należy pamiętać o następujących kwestiach:

Ważne

Przykład bezpiecznego ruchu przychodzącego sieci umożliwia wdrożenie wszystkich zasobów wymaganych do nawiązania połączenia z serwerem przesiadkowym za pośrednictwem usługi Azure Bastion i nawiązania połączenia z bezpieczną maszyną wirtualną sieci.

Efektywność wydajności

Wydajność to możliwość skalowania obciążenia w celu spełnienia wymagań, które użytkownicy umieszczają na nim. Aby uzyskać więcej informacji, zobacz Omówienie filaru wydajności.

Routing globalny umożliwia skalowanie w poziomie przez wdrożenie większej liczby zasobów w tym samym regionie lub w różnych regionach.

Następne kroki