Udostępnij za pośrednictwem

Architektura referencyjna usługi Azure Spring Apps

  • Artykuł

Uwaga

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

Ten artykuł dotyczy: ✔️ Standard ✔️ Enterprise

Ta architektura referencyjna jest podstawą przy użyciu typowego projektu centrum przedsiębiorstwa i szprych do korzystania z usługi 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 kompilowana przy użyciu składników w celu osiągnięcia zestawów w programie Microsoft Azure Well-Architected Framework.

Istnieją dwie wersje usługi Azure Spring Apps: plan standardowy i plan enterprise.

Plan Usługi Azure Spring Apps w warstwie Standardowa 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 oprogramowania VMware Tanzu®, VMware Tanzu® Service Registry, Spring Cloud Gateway for VMware Tanzu® i portalu interfejsu API dla oprogramowania 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), terraform, interfejs wiersza polecenia platformy Azure i aplikację Bicep. Artefakty w tym repozytorium stanowią podstawę, którą można dostosować dla danego środowiska. Zasoby, takie jak Azure Firewall lub Application Gateway, można grupować w różnych grupach zasobów lub subskrypcjach. To 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 usługa Azure Spring Apps może obsługiwać, 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 podsieci.

Przypadki zastosowań

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 jest przeznaczona do obsługi niuansów każdego z nich.

Aplikacje prywatne

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

  • 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 usłudze Azure Prywatna strefa DNS.
  • Zależności usług platformy Azure powinny komunikować się za pośrednictwem punktów końcowych usługi lub Private Link.
  • Dane magazynowane powinny być szyfrowane.
  • Dane przesyłane powinny być szyfrowane.
  • Potoki wdrażania metodyki DevOps można używać (na przykład usługi Azure DevOps) i wymagać łączności sieciowej z usługą Azure Spring Apps.
  • Ruch wychodzący powinien podróżować przez centralne wirtualne urządzenie sieciowe (WUS) (na przykład Azure Firewall).
  • Jeśli serwer konfiguracji usługi Azure Spring Apps służy do ładowania właściwości konfiguracji z repozytorium, repozytorium musi być prywatne.
  • Podejście Zero Trust zabezpieczeń firmy Microsoft wymaga przechowywania w bezpiecznym magazynie wpisów tajnych, certyfikatów i poświadczeń. Zalecaną usługą jest usługa 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.
  • Nie można modyfikować podsieci zarządzanych przez wdrożenie usługi Azure Spring Apps.

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

  • Sieć lokalna
    • Usługa nazw domen (DNS)
    • Brama
  • Subskrypcja centrum
    • podsieć Application Gateway
    • podsieć Azure Firewall
    • Podsieć usług udostępnionych
  • Połączona subskrypcja
    • Podsieć usługi Azure Bastion
    • element równorzędny Virtual Network

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 zestaw 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 dla chmury: ujednolicony system zarządzania zabezpieczeniami i ochrony przed zagrożeniami dla obciążeń w środowiskach lokalnych, 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 odpowiada powyższym wymaganiom:

Aplikacje publiczne

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

  • 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 usłudze Azure Prywatna strefa DNS.
  • Usługa Azure DDoS Protection powinna być włączona.
  • Zależności usług platformy Azure powinny komunikować się za pośrednictwem punktów końcowych usługi lub Private Link.
  • Dane magazynowane powinny być szyfrowane.
  • Dane przesyłane powinny być szyfrowane.
  • Potoki wdrażania metodyki DevOps można używać (na przykład usługi Azure DevOps) i wymagać łączności sieciowej z usługą Azure Spring Apps.
  • Ruch wychodzący powinien podróżować przez centralne wirtualne urządzenie sieciowe (WUS) (na przykład Azure Firewall).
  • Ruch przychodzący powinien być zarządzany przez co najmniej Application Gateway lub usługę Azure Front Door.
  • Adresy routingu internetowego powinny być przechowywane w publicznym systemie DNS platformy Azure.
  • Podejście Zero Trust zabezpieczeń firmy Microsoft wymaga przechowywania w bezpiecznym magazynie wpisów tajnych, certyfikatów i poświadczeń. Zalecaną usługą jest usługa 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.
  • Nie można modyfikować podsieci zarządzanych przez wdrożenie usługi Azure Spring Apps.

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

  • Sieć lokalna
    • Usługa nazw domen (DNS)
    • Brama
  • Subskrypcja centrum
    • podsieć Application Gateway
    • podsieć Azure Firewall
    • Podsieć usług udostępnionych
  • Połączona subskrypcja
    • Podsieć usługi Azure Bastion
    • Element równorzędny Virtual Network

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

  • aplikacja systemu Azure Zapora: funkcja Azure Application Gateway, która zapewnia scentralizowaną ochronę aplikacji przed typowymi programami wykorzystującymi luki 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: sprzętowa usługa zarządzania poświadczeniami, która ma ścisłą integrację z usługami tożsamości firmy Microsoft i zasobami obliczeniowymi.

  • Azure Monitor: wszechogarniający pakiet usług monitorowania dla aplikacji, które wdrażają zarówno na platformie Azure, jak i lokalnie.

  • 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 dla chmury: ujednolicony system zarządzania zabezpieczeniami i ochrony przed zagrożeniami dla obciążeń w środowiskach lokalnych, 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.

Poniższe diagramy reprezentują dobrze zaprojektowany projekt piasty i szprych, który spełnia powyższe wymagania. Tylko sieć wirtualna koncentratora komunikuje się z Internetem:

Łączność lokalna usługi Azure Spring Apps

Aplikacje w usłudze Azure Spring Apps mogą komunikować się z różnymi zasobami platformy Azure, lokalnymi i zewnętrznymi. Za pomocą projektu piasty i szprych aplikacje mogą kierować ruch zewnętrznie lub do sieci lokalnej przy użyciu usługi Express Route lub wirtualnej sieci prywatnej (VPN) typu lokacja-lokacja.

Zagadnienia dotyczące platformy Azure Well-Architected Framework

Platforma Azure Well-Architected Framework to zestaw wytycznych do naśladowania podczas ustanawiania silnej podstawy infrastruktury. Struktura zawiera następujące kategorie: optymalizacja kosztów, doskonałość operacyjna, wydajność wydajności, niezawodność i zabezpieczenia.

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 spełnienia wymagań i optymalizacji kosztów. Podstawą tej architektury jest Azure Kubernetes Service (AKS). Usługa została zaprojektowana w celu zmniejszenia złożoności i obciążeń operacyjnych związanych 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 dzienników, aby ujawnić nieefektywność w kodzie aplikacji, który można rozwiązać, aby poprawić ogólny koszt i wydajność systemu.

Efektywność operacyjna

Usługa Azure Spring Apps dotyczy wielu aspektów 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:

  • Usługi Azure Pipelines można używać do zapewnienia, ż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żyć 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 Bezproblemowe monitorowanie aplikacji i zależności w usłudze Azure Spring Apps.
  • Możesz użyć 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 dzięki klastrowaniu, ta architektura referencyjna idzie jeszcze dalej, włączając usługi i zagadnienia dotyczące architektury w celu zwiększenia dostępności aplikacji w przypadku awarii składników.

Opierając się na dobrze zdefiniowanym projekcie piasty i szprych, fundament tej architektury gwarantuje, że można wdrożyć go w wielu regionach. W przypadku użycia aplikacji prywatnej architektura korzysta z usługi Azure Prywatna strefa DNS w celu zapewnienia ciągłej dostępności podczas awarii geograficznej. W przypadku użycia aplikacji publicznej usługa Azure Front Door i Azure Application Gateway zapewnić dostępność.

Zabezpieczenia

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) i Microsoft Azure Foundations Benchmark (MAFB) firmy Center for Internet Security (CIS). W zastosowanych mechanizmach kontroli koncentruje się na podstawowych zasadach projektowania zabezpieczeń ładu, sieci i zabezpieczeń aplikacji. Twoim zadaniem jest obsługa zasad projektowania tożsamości, zarządzania dostępem i magazynu w odniesieniu do infrastruktury docelowej.

Nadzór

Podstawowym aspektem ładu, który dotyczy tej architektury, jest podział 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 gwiazdy przy użyciu sieciowych grup zabezpieczeń (NSG) do filtrowania ruchu między zasobami w regionie wschód-zachód. Architektura filtruje również ruch między usługami centralnymi w centrum i zasobami w szprychach. Architektura używa wystąpienia Azure Firewall do zarządzania ruchem między Internetem a zasobami w architekturze.

Poniższa lista zawiera kontrolkę, która odpowiada na zabezpieczenia centrum danych w tym odwołaniu:

IDENTYFIKATOR formantu CSA CCM Domena formantu CSA CCM
DCS-08 Wprowadzanie nieautoryzowanych osób w centrum danych

Sieć

Projekt sieci obsługujący tę architekturę pochodzi z tradycyjnego modelu piasty i szprych. Ta decyzja gwarantuje, że izolacja sieci jest podstawową konstrukcją. Kontrola CCM IVS-06 zaleca, aby ruch między sieciami i maszynami wirtualnymi był ograniczony i monitorowany między zaufanymi i niezaufanym środowiskiem. Ta architektura przyjmuje kontrolę przez implementację sieciowych grup zabezpieczeń dla ruchu wschód-zachód (w "centrum danych") i 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 odwołaniu:

IDENTYFIKATOR formantu CSA CCM Domena formantu 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 kontroli CIS, które dotyczą zabezpieczeń sieci w tej dokumentacji:

Identyfikator kontrolki CIS Opis kontrolki CIS
6,2 Upewnij się, że dostęp za pomocą protokołu SSH jest ograniczony do Internetu.
6.3 Upewnij się, że żadne bazy danych SQL nie zezwalają na ruch przychodzący 0.0.0.0/0 (DOWOLNY adres IP).
6.5 Upewnij się, że 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 PROGRAMU CCM, które odpowiadają za zarządzanie kluczami w tej dokumentacji:

IDENTYFIKATOR formantu CSA CCM Domena formantu CSA CCM
EKM-01 Uprawnienie do szyfrowania i zarządzania kluczami
EKM-02 Generowanie klucza 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

W programie CCM, EKM-02 i EKM-03 zaleca się stosowanie zasad i procedur do 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 stosowanie standardowych algorytmów.

Poniższa lista zawiera kontrolki CIS, które odpowiadają za zarządzanie kluczami w tej dokumentacji:

Identyfikator kontrolki CIS Opis kontrolki 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 na wszystkie wpisy tajne.
8.4 Upewnij się, że magazyn kluczy jest możliwy do odzyskania.

Kontrolki CIS 8.1 i 8.2 zalecają ustawienie dat wygaśnięcia dla poświadczeń w celu zapewnienia wymuszania 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.

Następne kroki

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