Architektura referencyjna usługi Azure Spring Apps

Uwaga / Notatka

Azure Spring Apps to nowa nazwa usługi Azure Spring Cloud. Mimo że usługa ma nową nazwę, stara nazwa będzie widoczna w niektórych miejscach przez pewien czas, ponieważ pracujemy nad aktualizowaniem zasobów, takich jak zrzuty ekranu, filmy wideo i diagramy.

Ten artykuł dotyczy: ✔️ Standard ✔️ Enterprise

Ta architektura referencyjna stanowi podstawę, wykorzystując typowy projekt z centralnym węzłem (hub) i odnogami (szprychami) dla aplikacji Azure Spring Apps. W projekcie usługa Azure Spring Apps jest wdrażana w jednej szprychy, która jest zależna od usług udostępnionych hostowanych w centrum. Architektura jest budowana z użyciem składników w celu osiągnięcia zasad w Microsoft Azure Well-Architected Framework.

Istnieją dwie wersje usługi Azure Spring Apps: plan Standard i plan Enterprise.

Plan usługi Azure Spring Apps Standard składa się z serwera Spring Cloud Config Server, rejestru Spring Cloud Service Registry i usługi kompilacji kpack.

Plan Azure Spring Apps Enterprise składa się z usługi VMware Tanzu® Build Service™, Usługi Konfiguracji Aplikacji dla VMware Tanzu®, VMware Tanzu® Service Registry, Spring Cloud Gateway dla VMware Tanzu® i portalu API dla VMware Tanzu®.

Aby zapoznać się z implementacją tej architektury, zobacz Architektura referencyjna usługi Azure Spring Apps w witrynie GitHub.

Opcje wdrażania dla tej architektury obejmują usługę Azure Resource Manager (ARM), program Terraform, interfejs wiersza polecenia platformy Azure i Bicep. Artefakty w tym repozytorium stanowią podstawę, którą można dostosować dla danego środowiska. Zasoby, takie jak Usługa Azure Firewall lub Application Gateway, można grupować w różne grupy zasobów lub subskrypcje. Takie grupowanie ułatwia oddzielenie różnych funkcji, takich jak infrastruktura IT, zabezpieczenia, zespoły aplikacji biznesowych itd.

Planowanie przestrzeni adresowej

Usługa Azure Spring Apps wymaga dwóch dedykowanych podsieci:

• Środowisko uruchomieniowe usługi
• Aplikacje Spring Boot

Każda z tych podsieci wymaga dedykowanego klastra usługi Azure Spring Apps. Wiele klastrów nie może współużytkować tych samych podsieci. Minimalny rozmiar każdej podsieci to /28. Liczba wystąpień aplikacji, które może obsługiwać usługa Azure Spring Apps, różni się w zależności od rozmiaru podsieci. Szczegółowe wymagania dotyczące sieci wirtualnej można znaleźć w sekcji Wymagania dotyczące sieci wirtualnej w temacie Wdrażanie usługi Azure Spring Apps w sieci wirtualnej.

Ostrzeżenie

Rozmiar wybranej podsieci nie może nakładać się na istniejącą przestrzeń adresową sieci wirtualnej i nie powinien nakładać się na żadne zakresy adresów podsieci równorzędnej ani lokalnej.

Przypadki użycia

Przykładowe typowe zastosowania tej architektury:

• Aplikacje prywatne: aplikacje wewnętrzne wdrożone w środowiskach chmury hybrydowej
• Aplikacje publiczne: aplikacje dostępne zewnętrznie

Te przypadki użycia są podobne z wyjątkiem reguł zabezpieczeń i ruchu sieciowego. Ta architektura została zaprojektowana tak, aby obsługiwała niuanse każdego z nich.

Aplikacje prywatne

Poniższa lista zawiera opis wymagań dotyczących infrastruktury dla aplikacji prywatnych. Te wymagania są typowe w środowiskach wysoce regulowanych.

• Podsieć musi mieć tylko jedno wystąpienie usługi Azure Spring Apps.
• Należy wymusić przestrzeganie co najmniej jednego testu porównawczego zabezpieczeń.
• Rekordy usługi DNS (Domain Name Service) hosta aplikacji powinny być przechowywane w prywatnej usłudze DNS platformy Azure.
• Zależności usług platformy Azure powinny komunikować się za pośrednictwem punktów końcowych usługi lub usługi Private Link.
• Dane w spoczynku powinny być szyfrowane.
• Dane przesyłane powinny być szyfrowane.
• Można używać potoków wdrażania DevOps (na przykład Azure DevOps) i wymagają one łączności sieciowej z usługą Azure Spring Apps.
• Ruch wychodzący powinien przechodzić przez centralne wirtualne urządzenie sieciowe (Network Virtual Appliance, NVA) (np. Azure Firewall).
• Jeśli serwer konfiguracji usługi Azure Spring Apps jest używany do ładowania właściwości konfiguracji z repozytorium, repozytorium musi być prywatne.
• Podejście zabezpieczeń Zero Trust firmy Microsoft wymaga przechowywania w bezpiecznym magazynie wpisów tajnych, certyfikatów i poświadczeń. Zalecana usługa to Azure Key Vault.
• Rozpoznawanie nazw hostów lokalnych i w chmurze powinno być dwukierunkowe.
• Brak bezpośredniego dostępu do publicznego Internetu z wyjątkiem ruchu sterującego.
• Grupy zasobów zarządzane przez wdrożenie usługi Azure Spring Apps nie mogą być modyfikowane.
• Podsieci zarządzane przez wdrożenie usługi Azure Spring Apps nie mogą być modyfikowane.

Na poniższej liście przedstawiono składniki tworzące projekt:

• Sieć lokalna
  • Usługa nazw domen (DNS)
  • Brama sieciowa
• Subskrypcja hubu
  • Application Gateway Subnet
  • Podsieć usługi Azure Firewall
  • Podsieć udostępnionych usług
• Połączona subskrypcja
  • Podsieć Azure Bastion
  • Wirtualny element równorzędny sieci

Poniższa lista zawiera opis usług platformy Azure w tej architekturze referencyjnej:

• Azure Key Vault: usługa zarządzania poświadczeniami, która ma ścisłą integrację z usługami tożsamości firmy Microsoft i zasobami obliczeniowymi.

• Azure Monitor: obejmujący cały pakiet usług monitorowania dla aplikacji wdrażanych zarówno na platformie Azure, jak i w środowisku lokalnym.

• Azure Pipelines: w pełni funkcjonalna usługa ciągłej integracji/ciągłego programowania (CI/CD), która może automatycznie wdrażać zaktualizowane aplikacje Spring Boot w usłudze Azure Spring Apps.

• Microsoft Defender for Cloud: ujednolicony system zarządzania zabezpieczeniami i ochrony przed zagrożeniami dla obciążeń w środowisku lokalnym, wielu chmurach i na platformie Azure.

• Azure Spring Apps: zarządzana usługa zaprojektowana i zoptymalizowana specjalnie dla aplikacji Spring Boot opartych na języku Java i . Aplikacje Steeltoe oparte na platformie NET.

Na poniższych diagramach przedstawiono dobrze zaprojektowany projekt piasty i szprych, który spełnia powyższe wymagania:

Plan standardowy

Plan przedsiębiorstwa

Aplikacje publiczne

Poniższa lista zawiera opis wymagań dotyczących infrastruktury dla aplikacji publicznych. Te wymagania są typowe w środowiskach wysoce regulowanych.

• Podsieć musi mieć tylko jedno wystąpienie usługi Azure Spring Apps.
• Należy wymusić przestrzeganie co najmniej jednego testu porównawczego zabezpieczeń.
• Rekordy usługi DNS (Domain Name Service) hosta aplikacji powinny być przechowywane w prywatnej usłudze DNS platformy Azure.
• Należy włączyć usługę Azure DDoS Protection.
• Zależności usług platformy Azure powinny komunikować się za pośrednictwem Service Endpoints lub usługi Private Link.
• Dane w spoczynku powinny być szyfrowane.
• Dane przesyłane powinny być szyfrowane.
• Potoki wdrażania DevOps, takie jak Azure DevOps, mogą być używane i wymagają łączności sieciowej z Azure Spring Apps.
• Ruch wychodzący powinien przechodzić przez centralne urządzenie wirtualne sieci (NVA) (np. Azure Firewall).
• Ruch przychodzący powinien być zarządzany co najmniej przez Application Gateway lub Azure Front Door.
• Adresy routingu internetowego powinny być przechowywane w publicznym systemie DNS platformy Azure.
• Podejście zabezpieczeń Zero Trust firmy Microsoft wymaga przechowywania tajemnic, certyfikatów i poświadczeń w bezpiecznym skarbcu. Zalecana usługa to Azure Key Vault.
• Rozpoznawanie nazw hostów lokalnych i w chmurze powinno być dwukierunkowe.
• Brak bezpośredniego ruchu wychodzącego do publicznego Internetu z wyjątkiem ruchu płaszczyzny sterowania.
• Grupy zasobów zarządzane przez wdrożenie usługi Azure Spring Apps nie mogą być modyfikowane.
• Podsieci zarządzane przez wdrożenie usługi Azure Spring Apps nie mogą być modyfikowane.

Na poniższej liście przedstawiono składniki tworzące projekt:

• Sieć lokalna
  • Usługa nazw domen (DNS)
  • Brama sieciowa
• Subskrypcja hubu
  • Brama Aplikacyjna Subnet
  • Podsieć usługi Azure Firewall
  • Podsieć usług wspólnych
• Połączona subskrypcja
  • Podsieć Azure Bastion
  • Wirtualny element równorzędny sieci

Poniższa lista zawiera opis usług platformy Azure w tej architekturze referencyjnej:

• Azure Application Firewall: funkcja usługi Azure Application Gateway, która zapewnia scentralizowaną ochronę aplikacji przed typowymi lukami w zabezpieczeniach i lukami w zabezpieczeniach.

• Azure Application Gateway: moduł równoważenia obciążenia odpowiedzialny za ruch aplikacji przy użyciu odciążania protokołu Transport Layer Security (TLS) działającego w warstwie 7.

• Azure Key Vault: usługa zarządzania poświadczeniami, która ma ścisłą integrację z usługami tożsamości firmy Microsoft i zasobami obliczeniowymi.

• Azure Monitor: obejmujący cały pakiet usług monitorowania dla aplikacji wdrażanych zarówno na platformie Azure, jak i w środowisku lokalnym.

• Azure Pipelines: w pełni funkcjonalna usługa ciągłej integracji/ciągłego programowania (CI/CD), która może automatycznie wdrażać zaktualizowane aplikacje Spring Boot w usłudze Azure Spring Apps.

• Microsoft Defender for Cloud: ujednolicony system zarządzania zabezpieczeniami i ochrony przed zagrożeniami dla obciążeń w środowisku lokalnym, wielu chmurach i na platformie Azure.

• Azure Spring Apps: zarządzana usługa zaprojektowana i zoptymalizowana specjalnie dla aplikacji Spring Boot opartych na języku Java i . Aplikacje Steeltoe oparte na platformie NET.

Na poniższych diagramach przedstawiono dobrze zaprojektowany projekt piasty i szprych, który spełnia powyższe wymagania. Tylko wirtualna sieć koncentratora komunikuje się z Internetem.

Plan standardowy

Diagram przedstawiający architekturę referencyjną dla aplikacji publicznych korzystających z planu Azure Spring Apps Standard.

Plan przedsiębiorstwa

Łączność usługi Azure Spring Apps z infrastrukturą lokalną

Aplikacje w usłudze Azure Spring Apps mogą komunikować się z różnymi zasobami platformy Azure, lokalnymi i zewnętrznymi. Za pomocą architektury hub and spoke, aplikacje mogą kierować ruch do sieci zewnętrznej lub do sieci lokalnej przy użyciu ExpressRoute lub wirtualnej sieci prywatnej (VPN) typu lokacja-do-lokacji.

Zagadnienia dotyczące struktury dobrze zaprojektowanej na platformie Azure

Platforma Azure Well-Architected Framework to zestaw wskazówek, które należy zastosować w tworzeniu silnej podstawy infrastruktury. Struktura zawiera następujące kategorie: optymalizacja kosztów, doskonałość operacyjna, wydajność wydajności, niezawodność i bezpieczeństwo.

Optymalizacja kosztów

Ze względu na charakter projektowania systemu rozproszonego rozrastanie infrastruktury jest rzeczywistością. Ta rzeczywistość powoduje nieoczekiwane i niekontrolowane koszty. Usługa Azure Spring Apps jest kompilowana przy użyciu składników skalowanych w celu zaspokojenia zapotrzebowania i optymalizacji kosztów. Podstawą tej architektury jest usługa Azure Kubernetes Service (AKS). Usługa została zaprojektowana tak, aby zmniejszyć złożoność i nakłady operacyjne związane z zarządzaniem platformą Kubernetes, co obejmuje wydajność w kosztach operacyjnych klastra.

Różne aplikacje i typy aplikacji można wdrożyć w jednym wystąpieniu usługi Azure Spring Apps. Usługa obsługuje skalowanie automatyczne aplikacji wyzwalanych przez metryki lub harmonogramy, które mogą zwiększyć wykorzystanie i wydajność kosztów.

Możesz również użyć usług Application Insights i Azure Monitor, aby obniżyć koszty operacyjne. Dzięki widoczności zapewnianej przez kompleksowe rozwiązanie do rejestrowania można zaimplementować automatyzację w celu skalowania składników systemu w czasie rzeczywistym. Możesz również analizować dane dziennika, aby ujawnić nieefektywność w kodzie aplikacji, który można rozwiązać, aby poprawić ogólny koszt i wydajność systemu.

Doskonałość operacyjna

Usługa Azure Spring Apps zajmuje się wieloma aspektami doskonałości operacyjnej. Te aspekty można połączyć, aby upewnić się, że usługa działa wydajnie w środowiskach produkcyjnych, zgodnie z opisem na poniższej liście:

• Możesz użyć usługi Azure Pipelines, aby upewnić się, że wdrożenia są niezawodne i spójne, a jednocześnie pomagają uniknąć błędów ludzkich.
• Do przechowywania danych dzienników i telemetrii można używać usług Azure Monitor i Application Insights. Możesz ocenić zebrane dane dzienników i metryk, aby zapewnić kondycję i wydajność aplikacji. Program Application Performance Monitoring (APM) jest w pełni zintegrowany z usługą za pośrednictwem agenta Języka Java. Ten agent zapewnia wgląd we wszystkie wdrożone aplikacje i zależności bez konieczności dodatkowego kodu. Aby uzyskać więcej informacji, zobacz wpis w blogu Bez wysiłku monitorowania aplikacji i zależności w usłudze Azure Spring Apps.
• Możesz użyć usługi Microsoft Defender for Cloud, aby zapewnić, że aplikacje utrzymują bezpieczeństwo, udostępniając platformę do analizowania i oceniania dostarczonych danych.
• Usługa obsługuje różne wzorce wdrażania. Aby uzyskać więcej informacji, zobacz Konfigurowanie środowiska przejściowego w usłudze Azure Spring Apps.

Niezawodność

Usługa Azure Spring Apps jest oparta na usłudze AKS. Mimo że usługa AKS zapewnia poziom odporności za pośrednictwem klastrowania, ta architektura referencyjna jest jeszcze bardziej zaawansowana dzięki włączeniu usług i aspektów architektonicznych w celu zapewnienia wysokiej dostępności aplikacji na wypadek awarii składników.

Opierając się na dobrze zdefiniowanym projekcie piasty i szprych, podstawa tej architektury gwarantuje, że można wdrożyć ją w wielu regionach. W przypadku użycia aplikacji prywatnej architektura korzysta z usługi Azure Private DNS, aby zapewnić ciągłą dostępność podczas awarii geograficznej. W przypadku przypadków użycia aplikacji publicznej usługi Azure Front Door i Azure Application Gateway zapewniają dostępność.

Bezpieczeństwo

Bezpieczeństwo tej architektury jest rozwiązywane przez przestrzeganie mechanizmów kontroli i testów porównawczych zdefiniowanych w branży. W tym kontekście "kontrola" oznacza zwięzłe i dobrze zdefiniowane najlepsze rozwiązanie, takie jak "Stosowanie zasady najniższych uprawnień podczas implementowania dostępu do systemu informacyjnego. IAM-05" Kontrolki w tej architekturze pochodzą z Cloud Control Matrix (CCM) firmy Cloud Security Alliance (CSA) oraz z Microsoft Azure Foundations Benchmark (MAFB) opracowanego przez Centrum Bezpieczeństwa Internetowego (CIS). W zastosowanych mechanizmach kontroli skupia się na podstawowych zasadach projektowania zabezpieczeń w zakresie zarządzania, sieci i bezpieczeństwa aplikacji. Twoim zadaniem jest zarządzanie zasadami projektowania systemów zarządzania tożsamością, dostępem i magazynowaniem w odniesieniu do infrastruktury docelowej.

Rządzenie

Podstawowym aspektem ładu, który dotyczy tej architektury, jest segregacja przez izolację zasobów sieciowych. W programie CCM kontroler DCS-08 zaleca kontrolę ruchu przychodzącego i wychodzącego dla centrum danych. Aby spełnić wymagania tej kontrolki, architektura używa projektu piasty i szprych przy użyciu sieciowych grup zabezpieczeń w celu filtrowania ruchu między zasobami we wschodniej części zachodu. Architektura filtruje również ruch między usługami centralnymi w rdzeniu a zasobami w ramionach. Architektura używa Azure Firewall do zarządzania ruchem sieciowym między Internetem a zasobami wewnętrznymi architektury.

Poniższa lista pokazuje kontrolę, która dotyczy zabezpieczeń centrum danych w tej dokumentacji.

Identyfikator kontroli CSA CCM	Domena kontroli CSA CCM
DCS-08	Nieautoryzowany dostęp do centrum danych przez osoby trzecie.

Sieć

Projekt sieci obsługujący tę architekturę pochodzi z tradycyjnego modelu piasty i szprych. Ta decyzja gwarantuje, że izolacja sieci jest podstawową konstrukcją. Kontrolka CCM IVS-06 zaleca, aby ruch między sieciami i maszynami wirtualnymi był ograniczony i monitorowany między zaufanymi i niezaufanymi środowiskami. Ta architektura wprowadza kontrolę poprzez implementację sieciowych grup zabezpieczeń dla ruchu wschód-zachód (w centrum danych) oraz Azure Firewall dla ruchu północno-południowego (poza centrum danych). Program CCM control IPY-04 zaleca, aby infrastruktura korzystała z bezpiecznych protokołów sieciowych do wymiany danych między usługami. Usługi platformy Azure obsługujące tę architekturę używają standardowych bezpiecznych protokołów, takich jak TLS dla protokołów HTTP i SQL.

Na poniższej liście przedstawiono mechanizmy kontroli CCM, które dotyczą zabezpieczeń sieci w tym odniesieniu.

Identyfikator kontrolki CSA CCM	Domena kontroli CSA CCM
IPY-04	Protokoły sieciowe
IVS-06	Bezpieczeństwo sieci

Implementacja sieci jest dodatkowo zabezpieczona przez zdefiniowanie kontrolek z programu MAFB. Kontrolki zapewniają, że ruch do środowiska jest ograniczony z publicznego Internetu.

Na poniższej liście przedstawiono mechanizmy kontrolne CIS, które dotyczą zabezpieczeń sieci w tym odniesieniu:

Identyfikator kontroli CIS	Opis kontroli CIS
6.2	Upewnij się, że dostęp za pomocą protokołu SSH jest ograniczony z Internetu.
6.3	Upewnij się, że żadna baza danych SQL nie zezwala na przyjmowanie ruchu przychodzącego z adresu 0.0.0.0/0 (DOWOLNY adres IP).
6.5	Upewnij się, że usługa Network Watcher jest włączona.
6.6	Upewnij się, że ruch przychodzący przy użyciu protokołu UDP jest ograniczony z Internetu.

Usługa Azure Spring Apps wymaga ruchu zarządzania do ruchu wychodzącego z platformy Azure po wdrożeniu w zabezpieczonym środowisku. Musisz zezwolić na reguły sieci i aplikacji wymienione w temacie Obowiązki klienta dotyczące uruchamiania usługi Azure Spring Apps w sieci wirtualnej.

Zabezpieczenia aplikacji

Ta zasada projektowania obejmuje podstawowe składniki tożsamości, ochrony danych, zarządzania kluczami i konfiguracji aplikacji. Zgodnie z projektem aplikacja wdrożona w usłudze Azure Spring Apps działa z najniższymi uprawnieniami wymaganymi do działania. Zestaw mechanizmów kontroli autoryzacji jest bezpośrednio związany z ochroną danych podczas korzystania z usługi. Zarządzanie kluczami wzmacnia to podejście zabezpieczeń aplikacji warstwowych.

Na poniższej liście przedstawiono kontrolki CCM, które dotyczą zarządzania kluczami w tej dokumentacji:

Identyfikator kontroli CSA CCM	Domena kontroli CSA CCM
EKM-01	Uprawnienie do szyfrowania i zarządzania kluczami
EKM-02	Generowanie kluczy szyfrowania i zarządzania kluczami
EKM-03	Szyfrowanie i zarządzanie kluczami — ochrona poufnych danych
EKM-04	Szyfrowanie i zarządzanie kluczami — magazyn i dostęp

CCM, EKM-02 i EKM-03 zalecają zasady i procedury dotyczące zarządzania kluczami oraz używania protokołów szyfrowania w celu ochrony poufnych danych. EKM-01 zaleca, aby wszystkie klucze kryptograficzne miały możliwych do zidentyfikowania właścicieli, aby można było nimi zarządzać. EKM-04 zaleca użycie standardowych algorytmów.

Poniższa lista zawiera kontrole CIS, które dotyczą zarządzania kluczami w tym odniesieniu:

Identyfikator kontroli CIS	Opis kontroli CIS
8.1	Upewnij się, że data wygaśnięcia jest ustawiona na wszystkich kluczach.
8.2	Upewnij się, że data wygaśnięcia jest ustawiona dla wszystkich sekretów.
8.4	Upewnij się, że magazyn kluczy można odzyskać.

Kontrole CIS 8.1 i 8.2 zalecają, aby daty wygaśnięcia były ustawiane dla poświadczeń, aby zapewnić wymuszanie rotacji. Kontrolka CIS 8.4 zapewnia, że zawartość magazynu kluczy może zostać przywrócona w celu zachowania ciągłości działania.

Aspekty zabezpieczeń aplikacji stanowią podstawę użycia tej architektury referencyjnej do obsługi obciążenia Spring na platformie Azure.

Dalsze kroki

Zapoznaj się z tą architekturą referencyjną za pomocą wdrożeń usługi ARM, programu Terraform i interfejsu wiersza polecenia platformy Azure dostępnych w repozytorium Architektury referencyjnej usługi Azure Spring Apps .