Freigeben über

Azure Spring Apps-Referenzarchitektur

  • Artikel

Hinweis

Azure Spring Apps ist der neue Name für den Azure Spring Cloud-Dienst. Obwohl der Dienst umbenannt wurde, wird der alte Name noch an einigen Stellen verwendet, solange wir Ressourcen wie Screenshots, Videos und Diagramme aktualisieren.

Dieser Artikel gilt für: ✔️ Standard ✔️ Enterprise

Diese Referenzarchitektur dient als Fundament und verwendet ein typisches Hub-and-Spoke-Design für Unternehmen für den Einsatz von Azure Spring Apps. Im Design wird Azure Spring Apps in einer einzigen Spoke bereitgestellt, die von den im Hub gehosteten gemeinsamen Diensten abhängig ist. Die Architektur wird mit Komponenten erstellt, um den Grundsätzen des Microsoft Azure Well-Architected Framework gerecht zu werden.

Es gibt zwei Varianten von Azure Spring Apps: Standardplan und Enterprise-Plan.

Der Azure Spring Apps Standard-Plan besteht aus dem Spring Cloud Config Server, der Spring Cloud Service Registry und dem kpack-Builddienst.

Der Azure Spring Apps Enterprise-Plan besteht aus dem VMware Tanzu® Build Service™, dem Anwendungskonfigurationsdienst für VMware Tanzu®, der VMware Tanzu® Service Registry, spring Cloud Gateway für VMware Tanzu® und dem API-Portal für VMware Tanzu®.

Eine Implementierung dieser Architektur finden Sie in der Azure Spring Apps-Referenzarchitektur auf GitHub.

Zu den Bereitstellungsoptionen für diese Architektur gehören Azure Resource Manager (ARM), Terraform, die Azure CLI und Bicep. Die Artefakte in diesem Repository bilden eine Grundlage, die Sie für Ihre Umgebung anpassen können. Sie können Ressourcen wie Azure Firewall oder Application Gateway in verschiedenen Ressourcengruppen oder Abonnements gruppieren. Diese Gruppierung hilft dabei, verschiedene Funktionen wie z. B. IT-Infrastruktur, Sicherheit, Geschäftsanwendungsteams usw. voneinander getrennt zu halten.

Planen des Adressraums

Azure Spring Apps erfordert zwei dedizierte Subnetze:

  • Dienstruntime
  • Spring Boot-Anwendungen

Jedes dieser Subnetze erfordert einen dedizierten Azure Spring Apps-Cluster. Mehrere Cluster können nicht die gleichen Subnetze gemeinsam verwenden. Die Mindestgröße jedes Subnetzes beträgt /28. Die Anzahl der von Azure Spring Apps unterstützten Anwendungsinstanzen variiert je nach Größe des Subnetzes. Die detaillierten Anforderungen an das virtuelle Netzwerk finden Sie im Abschnitt Anforderungen für virtuelle Netzwerke des Artikels Bereitstellen von Azure Spring Apps in einem virtuellen Netzwerk.

Warnung

Die ausgewählte Subnetzgröße darf sich weder mit dem vorhandenen Adressraum des virtuellen Netzwerks noch mit den Adressbereichen eines mit Peering verbundenen oder lokalen Subnetzes überlappen.

Anwendungsfälle

Typische Einsatzmöglichkeiten für diese Architektur sind:

  • Private Anwendungen: Interne Anwendungen, die in hybriden Cloud-Umgebungen bereitgestellt werden
  • Öffentliche Anwendungen: Nach außen gerichtete Anwendungen

Diese Anwendungsfälle sind mit Ausnahme ihrer Sicherheits- und Netzwerkverkehrsregeln vergleichbar. Diese Architektur ist darauf ausgelegt, die einzelnen Nuancen zu unterstützen.

Private Anwendungen

In der folgenden Liste werden die Infrastrukturanforderungen für private Anwendungen beschrieben. Diese Anforderungen sind für hochgradig regulierte Umgebungen typisch.

  • Ein Subnetz darf nur eine Instanz von Azure Spring Apps enthalten.
  • Die Einhaltung mindestens eines Sicherheitsvergleichstests sollte erzwungen werden.
  • Anwendungshost-DNS-Einträge (Domain Name Service) sollten im privaten DNS von Azure gespeichert werden.
  • Azure-Dienstabhängigkeiten sollten über Dienstendpunkte oder Private Link kommuniziert werden.
  • Ruhende Daten sollten verschlüsselt werden.
  • In Übertragung begriffene Daten sollten verschlüsselt werden.
  • DevOps-Bereitstellungspipelines können verwendet werden (z. B. Azure DevOps) und benötigen Netzwerkkonnektivität mit Azure Spring Apps.
  • Ausgehender Datenverkehr sollte durch ein zentrales virtuelles Netzwerkgerät (Network Virtual Appliance, NVA; z. B. Azure Firewall) geleitet werden.
  • Wenn der Azure Spring Apps-Konfigurationsserver verwendet wird, um Konfigurationseigenschaften aus einem Repository zu laden, muss das Repository privat sein.
  • Der Zero Trust-Sicherheitsansatz von Microsoft erfordert, dass Geheimnisse, Zertifikate und Anmeldeinformationen in einem sicheren Tresor gespeichert werden. Azure Key Vault wird als Dienst empfohlen.
  • Die Namensauflösung von Hosts sollte lokal und in der Cloud bidirektional sein.
  • Mit Ausnahme des Datenverkehrs auf Steuerungsebene kein direkter Ausgang zum öffentlichen Internet.
  • Von der Azure Spring Apps-Bereitstellung verwaltete Ressourcengruppen dürfen nicht geändert werden.
  • Von der Azure Spring Apps-Bereitstellung verwaltete Subnetze dürfen nicht geändert werden.

Die folgende Liste enthält die Komponenten, die das Design ausmachen:

  • Lokales Netzwerk
    • Domain Name Service (DNS)
    • Gateway
  • Hubabonnement
    • Application Gateway-Subnetz
    • Azure Firewall-Subnetz
    • Shared Services-Subnetz
  • Verbundenes Abonnement
    • Azure Bastion-Subnetz
    • VNET-Peer

In der folgenden Liste werden die Azure-Dienste in dieser Referenzarchitektur beschrieben:

  • Azure Key Vault: Ein hardwaregestützter Dienst zur Verwaltung von Anmeldeinformationen, der eng in Microsoft-Identitätsdienste und -Computeressourcen integriert ist.

  • Azure Monitor: Eine allumfassende Sammlung von Überwachungsdiensten für Anwendungen, die Dateien sowohl in Azure als auch in der lokalen Umgebung bereitstellen.

  • Azure Pipelines: ein CI/CD-Dienst (Continuous Integration/Continuous Delivery) mit vollem Funktionsumfang, der aktualisierte Spring Boot-Apps automatisch in Azure Spring Apps bereitstellen kann.

  • Microsoft Defender für Cloud: Ein einheitliches System für Sicherheitsmanagement und Bedrohungsschutz für Workloads, die über lokale Umgebungen, mehrere Clouds und Azure hinweg genutzt werden.

  • Azure Spring Apps: ein verwalteter Dienst, der speziell für Java-basierte Spring Boot-Anwendungen und .NET-basierte Steeltoe-Anwendungen entworfen und optimiert wurde.

Die folgenden Diagramme zeigen ein gut durchdachtes Hub-and-Spoke-Konzept, das die oben genannten Anforderungen erfüllt:

Öffentliche Anwendungen

In der folgenden Liste werden die Infrastrukturanforderungen für öffentliche Anwendungen beschrieben. Diese Anforderungen sind für hochgradig regulierte Umgebungen typisch.

  • Ein Subnetz darf nur eine Instanz von Azure Spring Apps enthalten.
  • Die Einhaltung mindestens eines Sicherheitsvergleichstests sollte erzwungen werden.
  • Anwendungshost-DNS-Einträge (Domain Name Service) sollten im privaten DNS von Azure gespeichert werden.
  • Azure DDoS Protection sollte aktiviert sein.
  • Azure-Dienstabhängigkeiten sollten über Dienstendpunkte oder Private Link kommuniziert werden.
  • Ruhende Daten sollten verschlüsselt werden.
  • In Übertragung begriffene Daten sollten verschlüsselt werden.
  • DevOps-Bereitstellungspipelines können verwendet werden (z. B. Azure DevOps) und benötigen Netzwerkkonnektivität mit Azure Spring Apps.
  • Ausgehender Datenverkehr sollte durch ein zentrales virtuelles Netzwerkgerät (Network Virtual Appliance, NVA; z. B. Azure Firewall) geleitet werden.
  • Der eingehende Datenverkehr sollte mindestens von Application Gateway oder Azure Front Door verwaltet werden.
  • Adressen, die über das Internet geroutet werden können, sollten im öffentlichen DNS von Azure gespeichert werden.
  • Der Zero Trust-Sicherheitsansatz von Microsoft erfordert, dass Geheimnisse, Zertifikate und Anmeldeinformationen in einem sicheren Tresor gespeichert werden. Azure Key Vault wird als Dienst empfohlen.
  • Die Namensauflösung von Hosts sollte lokal und in der Cloud bidirektional sein.
  • Mit Ausnahme des Datenverkehrs auf Steuerungsebene kein direkter Ausgang zum öffentlichen Internet.
  • Von der Azure Spring Apps-Bereitstellung verwaltete Ressourcengruppen dürfen nicht geändert werden.
  • Von der Azure Spring Apps-Bereitstellung verwaltete Subnetze dürfen nicht geändert werden.

Die folgende Liste enthält die Komponenten, die das Design ausmachen:

  • Lokales Netzwerk
    • Domain Name Service (DNS)
    • Gateway
  • Hubabonnement
    • Application Gateway-Subnetz
    • Azure Firewall-Subnetz
    • Shared Services-Subnetz
  • Verbundenes Abonnement
    • Azure Bastion-Subnetz
    • VNET-Peer

In der folgenden Liste werden die Azure-Dienste in dieser Referenzarchitektur beschrieben:

  • Azure Application Firewall: Ein Feature von Azure Application Gateway, das zentralisierten Schutz von Anwendungen vor allgemeinen Exploits und Sicherheitsrisiken bietet.

  • Azure Application Gateway: Ein Lastenausgleich, der für den Anwendungsdatenverkehr mit TLS-Auslagerung (Transport Layer Security) auf Schicht 7 zuständig ist.

  • Azure Key Vault: Ein hardwaregestützter Dienst zur Verwaltung von Anmeldeinformationen, der eng in Microsoft-Identitätsdienste und -Computeressourcen integriert ist.

  • Azure Monitor: Eine allumfassende Sammlung von Überwachungsdiensten für Anwendungen, die Dateien sowohl in Azure als auch in der lokalen Umgebung bereitstellen.

  • Azure Pipelines: ein CI/CD-Dienst (Continuous Integration/Continuous Delivery) mit vollem Funktionsumfang, der aktualisierte Spring Boot-Apps automatisch in Azure Spring Apps bereitstellen kann.

  • Microsoft Defender für Cloud: Ein einheitliches System für Sicherheitsmanagement und Bedrohungsschutz für Workloads, die über lokale Umgebungen, mehrere Clouds und Azure hinweg genutzt werden.

  • Azure Spring Apps: ein verwalteter Dienst, der speziell für Java-basierte Spring Boot-Anwendungen und .NET-basierte Steeltoe-Anwendungen entworfen und optimiert wurde.

Die folgenden Diagramme zeigen ein gut durchdachtes Hub-and-Spoke-Konzept, das die oben genannten Anforderungen erfüllt. Beachten Sie, dass nur das virtuelle Hub-Netz mit dem Internet kommuniziert:

Konnektivität zwischen Azure Spring Apps und lokalen Systemen

Anwendungen in Azure Spring Apps können mit verschiedenen Azure-Ressourcen sowie lokalen und externen Ressourcen kommunizieren. Das Hub-and-Spoke-Design ermöglicht Anwendungen, den Datenverkehr mithilfe von Express Route oder Site-to-Site-VPN (virtuelles privates Netzwerk) extern oder an das lokale Netzwerk weiterleiten.

Überlegungen zu Azure Well-Architected Framework

Das Azure Well-Architected Framework ist eine Reihe von Leitfäden, die bei der Einrichtung einer starken Infrastrukturbasis befolgt werden müssen. Das Framework umfasst folgende Kategorien: Kostenoptimierung, erstklassige Betriebsprozesse, effiziente Leistung, Zuverlässigkeit und Sicherheit.

Kostenoptimierung

Der Entwurf des verteilten Systems bringt die Ausdehnung der Infrastruktur mit sich. Dies führt zu unerwarteten und unkontrollierbaren Kosten. Azure Spring Apps basiert auf Komponenten, die sich skalieren lassen, um die Nachfrage zu erfüllen und die Kosten zu optimieren. Der Kern dieser Architektur ist der Azure Kubernetes Service (AKS). Der Dienst ist so konzipiert, dass die Komplexität und der betriebliche Aufwand bei der Verwaltung von Kubernetes reduziert werden. Dies umfasst auch die Effizienz der Betriebskosten des Clusters.

Sie können verschiedene Anwendungen und Anwendungstypen in einer einzelnen Instanz von Azure Spring Apps bereitstellen. Der Dienst unterstützt die automatische Skalierung von Anwendungen, die durch Metriken oder Zeitpläne ausgelöst werden, die die Auslastung und Kosteneffizienz verbessern.

Sie können auch Application Insights und Azure Monitor verwenden, um die Betriebskosten zu senken. Mit den von der umfassenden Protokollierungslösung gebotenen Einblicken können Sie Automatisierung implementieren, um die Komponenten des Systems in Echtzeit zu skalieren. Sie können Protokolldaten auch analysieren, um Ineffizienzen im Anwendungscode zu erkennen, die Sie zur Verbesserung der Gesamtkosten und der Leistung des Systems beseitigen können.

Optimaler Betrieb

Azure Spring Apps eignet sich für verschiedene Aspekte eines optimalen Betriebs. Sie können diese Aspekte kombinieren, um sicherzustellen, dass der Dienst in Produktionsumgebungen effizient ausgeführt wird, wie in der folgenden Liste beschrieben:

  • Mit Azure Pipelines können Sie sicherstellen, dass Bereitstellungen zuverlässig und konsistent sind, und dabei dazu beitragen, menschliche Fehler zu vermeiden.
  • Sie können Azure Monitor und Application Insights verwenden, um Protokoll- und Telemetriedaten zu speichern. Sie können gesammelte Protokoll- und Metrikdaten bewerten, um die Integrität und Leistung Ihrer Anwendungen sicherzustellen. Die Überwachung der Anwendungsleistung (Application Performance Monitoring, APM) ist über einen Java-Agent vollständig in den Dienst integriert. Dieser Agent bietet Einblick in alle bereitgestellten Anwendungen und Abhängigkeiten, ohne dass zusätzlicher Code erforderlich ist. Weitere Informationen finden Sie im Blogbeitrag Müheloses Überwachen von Anwendungen und Abhängigkeiten in Azure Spring Apps.
  • Indem Sie mit Microsoft Defender für Cloud eine Plattform zur Analyse und Bewertung der bereitgestellten Daten einsetzen, können Sie sicherstellen, dass die Sicherheit der Anwendungen aufrechterhalten wird.
  • Der Dienst unterstützt verschiedene Bereitstellungsmuster. Weitere Informationen finden Sie unter Einrichten einer Stagingumgebung in Azure Spring Apps.

Zuverlässigkeit

Azure Spring Apps basiert auf AKS. Während AKS durch Clustering ein gewisses Maß an Ausfallsicherheit bietet, geht diese Referenzarchitektur sogar noch weiter, indem sie Dienste und architektonische Überlegungen einbezieht, um die Verfügbarkeit der Anwendung im Falle eines Komponentenausfalls zu erhöhen.

Da diese Architektur auf einem gut definierten Hub-and-Spoke-Design aufgebaut ist, gewährleistet ihre Grundlage, dass Sie sie in mehreren Regionen bereitstellen können. Für den Anwendungsfall der privaten Anwendung nutzt die Architektur privates Azure-DNS, um die fortlaufende Verfügbarkeit während eines geografischen Ausfalls sicherzustellen. Für den Anwendungsfall der öffentlichen Anwendung stellen Azure Front Door und Azure Application Gateway die Verfügbarkeit sicher.

Sicherheit

Für die Sicherheit dieser Architektur sorgt die Einhaltung branchendefinierter Steuerungen und Benchmarks. In diesem Zusammenhang bedeutet "Kontrolle" eine prägnante und klar definierte bewährte Praxis, wie z. B. "Anwendung des Prinzips der geringsten Privilegien bei der Implementierung des Zugriffs auf Informationssysteme. IAM-05" Die Kontrollen in dieser Architektur stammen aus der Cloud Control Matrix (CCM) der Cloud Security Alliance (CSA) und dem Microsoft Azure Foundations Benchmark (MAFB) des Center for Internet Security (CIS). In den angewendeten Steuerungen liegt der Schwerpunkt auf den primären Sicherheitsentwurfsprinzipien von Governance, Netzwerk und Anwendungssicherheit. Es liegt in ihrer Verantwortung, die Entwurfsprinzipien für Identität, Zugriffsverwaltung und Speicher zu beachten, da sie sie sich auf Ihre Zielinfrastruktur beziehen.

Governance

Der wichtigste Aspekt der Governance, den diese Architektur berücksichtigt, ist Trennung durch die Isolierung von Netzwerkressourcen. In der CCM empfiehlt DCS-08 die Eingangs- und Ausgangssteuerung für das Rechenzentrum. Für diese Steuerung verwendet die Architektur ein auf Netzwerksicherheitsgruppen (NSGs) basierendes Hub-and-Spoke-Design, um den Ost-West-Datenverkehr zwischen Ressourcen zu filtern. Die Architektur filtert auch den Datenverkehr zwischen zentralen Diensten im Hub und Ressourcen in der Spoke. Die Architektur verwendet eine Instanz von Azure Firewall zur Verwaltung des Datenverkehrs zwischen dem Internet und den Ressourcen innerhalb der Architektur.

In der folgenden Liste wird die Steuerung angezeigt, die die Sicherheit des Rechenzentrums in dieser Referenz behandelt:

CSA CCM Control ID CSA CCM Control Domain
DCS-08 Rechenzentrumssicherheit-Eintrag nicht autorisierter Personen

Netzwerk

Der Netzwerkentwurf, der diese Architektur unterstützt, wird aus dem herkömmlichen Hub-and-Spoke-Modell abgeleitet. Diese Entscheidung stellt sicher, dass die Netzwerkisolation ein grundlegendes Konstrukt ist. CCM-Steuerung IVS-06 empfiehlt, den Datenverkehr zwischen Netzwerken und virtuellen Computern zwischen vertrauenswürdigen und nicht vertrauenswürdigen Umgebungen einzuschränken und zu überwachen. Bei dieser Architektur wird die Kontrolle durch die Implementierung der NSGs für den Ost-West-Verkehr (innerhalb des "Rechenzentrums") und der Azure Firewall für den Nord-Süd-Verkehr (außerhalb des "Rechenzentrums") übernommen. CCM-Steuerung IPY-04 empfiehlt, dass die Infrastruktur sichere Netzwerkprotokolle für den Datenaustausch zwischen Diensten verwenden soll. Alle Azure-Dienste, die diese Architektur unterstützen, verwenden standardmäßige sichere Protokolle wie TLS für HTTP und SQL.

In der folgenden Liste werden die CCM-Steuerungen angezeigt, die die Netzwerksicherheit in dieser Referenz behandeln:

CSA CCM Control ID CSA CCM Control Domain
IPY-04 Netzwerkprotokolle
IVS-06 Netzwerksicherheit

Die Netzwerkimplementierung wird durch die Definition von MAFB-Steuerungen weiter gesichert. Die Steuerungen stellen sicher, dass der vom öffentlichen Internet in die Umgebung eingehende Datenverkehr eingeschränkt wird.

In der folgenden Liste werden die CIS-Steuerungen angezeigt, die die Netzwerksicherheit in dieser Referenz behandeln:

CIS Control ID CIS Control-Beschreibung
6.2 Stellt sicher, dass der SSH-Zugriff aus dem Internet eingeschränkt ist.
6.3 Stellt sicher, dass keine SQL-Datenbank-Instanzen Eingang 0.0.0.0/0 (BELIEBIGE IP) zulassen.
6,5 Stellt sicher, dass Network Watcher „aktiviert“ ist.
6.6 Stellt sicher, dass der Eingang mit UDP aus dem Internet eingeschränkt ist.

Bei Bereitstellung in einer gesicherten Umgebung erfordert Azure Spring Apps ausgehenden Verwaltungsdatenverkehr aus Azure. Sie müssen die unter Kundenzuständigkeiten für die Ausführung von Azure Spring Apps im virtuellen Netzwerk aufgeführten Netzwerk- und Anwendungsregeln zulassen.

Anwendungssicherheit

Dieses Entwurfsprinzip deckt die grundlegenden Komponenten von Identität, Datenschutz, Schlüsselverwaltung und Anwendungskonfiguration ab. Entwurfsbedingt wird eine in Azure Spring Apps bereitgestellte Anwendung mit den geringsten Berechtigungen ausgeführt, die zur Funktion erforderlich sind. Bei Verwendung des Diensts ist der Satz der Autorisierungssteuerungen direkt auf den Datenschutz bezogen. Die Schlüsselverwaltung verstärkt diesen mehrstufigen Anwendungssicherheitsansatz.

In der folgenden Liste werden die CCM-Steuerungen angezeigt, die die Schlüsselverwaltung in dieser Referenz behandeln:

CSA CCM Control ID CSA CCM Control Domain
EKM-01 Verschlüsselung und Schlüsselverwaltung: Berechtigung
EKM-02 Verschlüsselung und Schlüsselverwaltung: Schlüsselgenerierung
EKM-03 Verschlüsselung und Schlüsselverwaltung: Schutz von sensiblen Daten
EKM-04 Verschlüsselung und Schlüsselverwaltung: Speicherung und Zugriff

Von CCM, EKM-02 und EKM-03 werden Richtlinien und Verfahren zum Verwalten von Schlüsseln und Verwenden von Verschlüsselungsprotokollen zum Schutz sensibler Daten empfohlen. EKM-01 empfiehlt, dass alle kryptografischen Schlüssel über identifizierbare Besitzer verfügen, damit sie verwaltet werden können. EKM-04 empfiehlt die Verwendung von Standardalgorithmen.

In der folgenden Liste werden die CIS-Steuerungen angezeigt, die die Schlüsselverwaltung in dieser Referenz behandeln:

CIS Control ID CIS Control-Beschreibung
8.1 Stellt sicher, dass das Ablaufdatum für alle Schlüssel festgelegt ist.
8,2 Stellt sicher, dass das Ablaufdatum für alle Geheimnisse festgelegt ist.
8,4 Stellt sicher, dass der Schlüsseltresor wiederhergestellt werden kann.

Die CIS-Steuerungen 8.1 und 8.2 empfehlen, dass die Ablaufdaten für Anmeldeinformationen festgelegt werden, um sicherzustellen, dass die Rotation erzwungen wird. Die CIS-Steuerung 8.4 stellt sicher, dass der Inhalt des Schlüsseltresors wiederhergestellt werden kann, um die Geschäftskontinuität aufrechtzuerhalten.

Die Aspekte der Anwendungssicherheit legen eine Grundlage für die Verwendung dieser Referenzarchitektur fest, um eine Spring-Workload in Azure zu unterstützen.

Nächste Schritte

Erkunden Sie diese Referenzarchitektur mit den ARM-, Terraform- und Azure CLI-Bereitstellungen, die im Repository zur Azure Spring Apps-Referenzarchitektur verfügbar sind.