Referensarkitektur för Azure Spring Apps
Anteckning
Azure Spring Apps är det nya namnet på Azure Spring Cloud-tjänsten. Även om tjänsten har ett nytt namn ser du det gamla namnet på vissa ställen ett tag medan vi arbetar med att uppdatera tillgångar som skärmbilder, videor och diagram.
Den här artikeln gäller för: ✔️ Standard ✔️ Enterprise
Den här referensarkitekturen är en grund med en typisk enterprise hub and spoke-design för användning av Azure Spring Apps. I designen distribueras Azure Spring Apps i en enda eker som är beroende av delade tjänster som finns i hubben. Arkitekturen skapas med komponenter för att uppnå grundsatserna i Microsoft Azure Well-Architected Framework.
Det finns två varianter av Azure Spring Apps: Standardplan och Enterprise-plan.
Azure Spring Apps Standard-planen består av Spring Cloud-konfigurationsservern, Spring Cloud Service Registry och kpack-byggtjänsten.
Azure Spring Apps Enterprise-planen består av VMware Tanzu® Build Service™, Application Configuration Service for VMware Tanzu®, VMware Tanzu® Service Registry, Spring Cloud Gateway for VMware Tanzu® och API-portalen för VMware Tanzu®.
En implementering av den här arkitekturen finns i Referensarkitektur för Azure Spring Apps på GitHub.
Distributionsalternativen för den här arkitekturen omfattar Azure Resource Manager (ARM), Terraform, Azure CLI och Bicep. Artefakterna på den här lagringsplatsen utgör en grund som du kan anpassa för din miljö. Du kan gruppera resurser som Azure Firewall eller Application Gateway i olika resursgrupper eller prenumerationer. Den här grupperingen hjälper till att hålla olika funktioner åtskilda, till exempel IT-infrastruktur, säkerhet, affärsprogramteam och så vidare.
Planera adressutrymmet
Azure Spring Apps kräver två dedikerade undernät:
- Tjänstkörning
- Spring Boot-program
Vart och ett av dessa undernät kräver ett dedikerat Azure Spring Apps-kluster. Flera kluster kan inte dela samma undernät. Den minsta storleken för varje undernät är /28. Antalet programinstanser som Azure Spring Apps har stöd för varierar beroende på undernätets storlek. Du hittar detaljerade krav för virtuella nätverk i avsnittet Krav för virtuella nätverki Distribuera Azure Spring Apps i ett virtuellt nätverk.
Varning
Den valda undernätsstorleken får inte överlappa det befintliga virtuella nätverkets adressutrymme och får inte överlappa med peerkopplade eller lokala undernätsadressintervall.
Användningsfall
Vanliga användningsområden för den här arkitekturen inkluderar:
- Privata program: Interna program som distribueras i hybridmolnmiljöer
- Offentliga program: Externt riktade program
Dessa användningsfall är liknande förutom deras säkerhets- och nätverkstrafikregler. Den här arkitekturen är utformad för att stödja nyanserna i var och en.
Privata program
I följande lista beskrivs infrastrukturkraven för privata program. Dessa krav är typiska i strikt reglerade miljöer.
- Ett undernät får bara ha en instans av Azure Spring Apps.
- Efterlevnad av minst ett säkerhetsmått bör tillämpas.
- DNS-poster (Domain Name Service) för programvärdar ska lagras i Azure Privat DNS.
- Azure-tjänstberoenden bör kommunicera via tjänstslutpunkter eller Private Link.
- Vilande data ska krypteras.
- Data under överföring ska krypteras.
- DevOps-distributionspipelines kan användas (till exempel Azure DevOps) och kräva nätverksanslutning till Azure Spring Apps.
- Utgående trafik ska färdas via en central virtuell nätverksinstallation (NVA) (till exempel Azure Firewall).
- Om Azure Spring Apps-konfigurationsservern används för att läsa in konfigurationsegenskaper från en lagringsplats måste lagringsplatsen vara privat.
- Microsofts Nolltillit säkerhetsmetoden kräver att hemligheter, certifikat och autentiseringsuppgifter lagras i ett säkert valv. Den rekommenderade tjänsten är Azure Key Vault.
- Namnmatchningen för värdar lokalt och i molnet ska vara dubbelriktad.
- Ingen direkt utgående trafik till det offentliga Internet förutom kontrollplanstrafiken.
- Resursgrupper som hanteras av Azure Spring Apps-distributionen får inte ändras.
- Undernät som hanteras av Azure Spring Apps-distributionen får inte ändras.
I följande lista visas de komponenter som utgör designen:
- Lokalt nätverk
- Dns (Domain Name Service)
- Gateway
- Hubbprenumeration
- Application Gateway undernät
- Azure Firewall undernät
- Undernät för delade tjänster
- Ansluten prenumeration
- Azure Bastion-undernät
- Virtual Network peer
I följande lista beskrivs Azure-tjänsterna i den här referensarkitekturen:
Azure Key Vault: en maskinvarubaserad hanteringstjänst för autentiseringsuppgifter som har nära integrering med Microsofts identitetstjänster och beräkningsresurser.
Azure Monitor: en heltäckande uppsättning övervakningstjänster för program som distribueras både i Azure och lokalt.
Azure Pipelines: en komplett ci/CD-tjänst (Kontinuerlig integrering/kontinuerlig utveckling) som automatiskt kan distribuera uppdaterade Spring Boot-appar till Azure Spring Apps.
Microsoft Defender för molnet: ett enhetligt system för säkerhetshantering och skydd mot hot för arbetsbelastningar lokalt, i flera moln och i Azure.
Azure Spring Apps: en hanterad tjänst som är utformad och optimerad specifikt för Java-baserade Spring Boot-program och . NET-baserade Steeltoe-program .
Följande diagram representerar en väldesignad nav- och ekerdesign som uppfyller ovanstående krav:
Offentliga program
I följande lista beskrivs infrastrukturkraven för offentliga program. Dessa krav är typiska i strikt reglerade miljöer.
- Ett undernät får bara ha en instans av Azure Spring Apps.
- Efterlevnad av minst ett säkerhetsmått bör tillämpas.
- DNS-poster (Domain Name Service) för programvärdar ska lagras i Azure Privat DNS.
- Azure DDoS Protection ska vara aktiverat.
- Azure-tjänstberoenden bör kommunicera via tjänstslutpunkter eller Private Link.
- Vilande data ska krypteras.
- Data under överföring ska krypteras.
- DevOps-distributionspipelines kan användas (till exempel Azure DevOps) och kräva nätverksanslutning till Azure Spring Apps.
- Utgående trafik ska färdas via en central virtuell nätverksinstallation (NVA) (till exempel Azure Firewall).
- Inkommande trafik ska hanteras av minst Application Gateway eller Azure Front Door.
- Internet-routningsbara adresser ska lagras i Azure Public DNS.
- Microsofts Nolltillit säkerhetsmetoden kräver att hemligheter, certifikat och autentiseringsuppgifter lagras i ett säkert valv. Den rekommenderade tjänsten är Azure Key Vault.
- Namnmatchningen för värdar lokalt och i molnet ska vara dubbelriktad.
- Ingen direkt utgående trafik till det offentliga Internet förutom kontrollplanstrafiken.
- Resursgrupper som hanteras av Azure Spring Apps-distributionen får inte ändras.
- Undernät som hanteras av Azure Spring Apps-distributionen får inte ändras.
I följande lista visas de komponenter som utgör designen:
- Lokalt nätverk
- Dns (Domain Name Service)
- Gateway
- Hubbprenumeration
- Application Gateway undernät
- Azure Firewall undernät
- Undernät för delade tjänster
- Ansluten prenumeration
- Azure Bastion-undernät
- Virtual Network peer
I följande lista beskrivs Azure-tjänsterna i den här referensarkitekturen:
Azure Application Firewall: en funktion i Azure Application Gateway som ger ett centraliserat skydd av program mot vanliga sårbarheter och sårbarheter.
Azure Application Gateway: en lastbalanserare som ansvarar för programtrafik med TLS-avlastning (Transport Layer Security) i lager 7.
Azure Key Vault: en maskinvarubaserad hanteringstjänst för autentiseringsuppgifter som har nära integrering med Microsofts identitetstjänster och beräkningsresurser.
Azure Monitor: en heltäckande uppsättning övervakningstjänster för program som distribueras både i Azure och lokalt.
Azure Pipelines: en komplett ci/CD-tjänst (Kontinuerlig integrering/kontinuerlig utveckling) som automatiskt kan distribuera uppdaterade Spring Boot-appar till Azure Spring Apps.
Microsoft Defender för molnet: ett enhetligt system för säkerhetshantering och skydd mot hot för arbetsbelastningar lokalt, i flera moln och i Azure.
Azure Spring Apps: en hanterad tjänst som är utformad och optimerad specifikt för Java-baserade Spring Boot-program och . NET-baserade Steeltoe-program .
Följande diagram representerar en väldesignad nav- och ekerdesign som uppfyller ovanstående krav. Endast det virtuella hubbnätverket kommunicerar med Internet:
Lokal Azure Spring Apps-anslutning
Program i Azure Spring Apps kan kommunicera med olika Azure-resurser, lokala och externa resurser. Med hjälp av nav- och ekerdesignen kan program dirigera trafik externt eller till det lokala nätverket med hjälp av Express Route eller virtuellt privat nätverk (VPN) från plats till plats.
Överväganden för Azure Well-Architected Framework
Azure Well-Architected Framework är en uppsättning vägledande grundsatser att följa när det gäller att upprätta en stark infrastrukturgrund. Ramverket innehåller följande kategorier: kostnadsoptimering, driftseffektivitet, prestandaeffektivitet, tillförlitlighet och säkerhet.
Kostnadsoptimering
På grund av den distribuerade systemdesignens natur är infrastrukturspridning en realitet. Denna verklighet resulterar i oväntade och okontrollerbara kostnader. Azure Spring Apps skapas med hjälp av komponenter som skalas så att de kan möta efterfrågan och optimera kostnaderna. Kärnan i den här arkitekturen är Azure Kubernetes Service (AKS). Tjänsten är utformad för att minska komplexiteten och driftskostnaderna för att hantera Kubernetes, vilket innefattar effektivitetsvinster i klustrets driftskostnader.
Du kan distribuera olika program och programtyper till en enda instans av Azure Spring Apps. Tjänsten stöder automatisk skalning av program som utlöses av mått eller scheman som kan förbättra användningen och kostnadseffektiviteten.
Du kan också använda Application Insights och Azure Monitor för att sänka driftskostnaderna. Med den synlighet som tillhandahålls av den omfattande loggningslösningen kan du implementera automatisering för att skala systemets komponenter i realtid. Du kan också analysera loggdata för att visa ineffektivitet i programkoden som du kan åtgärda för att förbättra systemets totala kostnad och prestanda.
Utmärkt driftseffektivitet
Azure Spring Apps tar upp flera aspekter av driftseffektivitet. Du kan kombinera dessa aspekter för att säkerställa att tjänsten körs effektivt i produktionsmiljöer, enligt beskrivningen i följande lista:
- Du kan använda Azure Pipelines för att säkerställa att distributionerna är tillförlitliga och konsekventa samtidigt som du undviker mänskliga fel.
- Du kan använda Azure Monitor och Application Insights för att lagra logg- och telemetridata. Du kan utvärdera insamlade logg- och måttdata för att säkerställa hälsotillståndet och prestandan för dina program. Övervakning av programprestanda (APM) är helt integrerad i tjänsten via en Java-agent. Den här agenten ger insyn i alla distribuerade program och beroenden utan extra kod. Mer information finns i blogginlägget Övervaka program och beroenden utan problem i Azure Spring Apps.
- Du kan använda Microsoft Defender för molnet för att säkerställa att programmen upprätthåller säkerheten genom att tillhandahålla en plattform för att analysera och utvärdera de data som tillhandahålls.
- Tjänsten stöder olika distributionsmönster. Mer information finns i Konfigurera en mellanlagringsmiljö i Azure Spring Apps.
Tillförlitlighet
Azure Spring Apps bygger på AKS. AKS ger en återhämtningsnivå genom klustring, men den här referensarkitekturen går ännu längre genom att inkludera tjänster och arkitekturöverväganden för att öka tillgängligheten för programmet om det uppstår komponentfel.
Genom att bygga vidare på en väldefinierad nav- och ekerdesign säkerställer grunden för den här arkitekturen att du kan distribuera den till flera regioner. I det privata programanvändningsfallet använder arkitekturen Azure Privat DNS för att säkerställa fortsatt tillgänglighet vid ett geografiskt fel. För det offentliga programanvändningsfallet säkerställer Azure Front Door och Azure Application Gateway tillgängligheten.
Säkerhet
Säkerheten i den här arkitekturen hanteras genom att den följer branschdefinierade kontroller och riktmärken. I det här sammanhanget innebär "kontroll" en kortfattad och väldefinierad bästa praxis, till exempel "Använda principen om lägsta behörighet när du implementerar åtkomst till informationssystem. IAM-05– Kontrollerna i den här arkitekturen kommer från CCM (Cloud Control Matrix ) av Cloud Security Alliance (CSA) och Microsoft Azure Foundations Benchmark (MAFB) från Center for Internet Security (CIS). I de tillämpade kontrollerna ligger fokus på de primära principerna för säkerhetsdesign för styrning, nätverk och programsäkerhet. Det är ditt ansvar att hantera designprinciperna för identitet, åtkomsthantering och lagring när de relaterar till målinfrastrukturen.
Styrning
Den viktigaste styrningsaspekten som den här arkitekturen hanterar är uppdelning genom isolering av nätverksresurser. I CCM rekommenderar DCS-08 ingress- och utgående kontroll för datacentret. För att uppfylla kontrollen använder arkitekturen en nav- och ekerdesign med hjälp av nätverkssäkerhetsgrupper (NSG:er) för att filtrera öst-västlig trafik mellan resurser. Arkitekturen filtrerar även trafik mellan centrala tjänster i hubben och resurserna i ekern. Arkitekturen använder en instans av Azure Firewall för att hantera trafik mellan Internet och resurserna i arkitekturen.
I följande lista visas kontrollen som hanterar datacentersäkerhet i den här referensen:
| CSA CCM-kontroll-ID | CSA CCM-kontrolldomän |
|---|---|
| DCS-08 | Datacentrets säkerhetsbehörigheter – obehöriga personer |
Nätverk
Nätverksdesignen som stöder den här arkitekturen härleds från den traditionella nav- och ekermodellen. Det här beslutet säkerställer att nätverksisolering är en grundläggande konstruktion. CCM-kontrollen IVS-06 rekommenderar att trafiken mellan nätverk och virtuella datorer begränsas och övervakas mellan betrodda och ej betrodda miljöer. Den här arkitekturen implementerar kontrollen genom implementering av NSG:erna för öst-västlig trafik (inom "datacentret" och Azure Firewall för nord-syd-trafik (utanför "datacentret"). CCM-kontrollen IPY-04 rekommenderar att infrastrukturen använder säkra nätverksprotokoll för utbyte av data mellan tjänster. Azure-tjänsterna som stöder den här arkitekturen använder alla standardsäkerhetsprotokoll som TLS för HTTP och SQL.
I följande lista visas de CCM-kontroller som hanterar nätverkssäkerhet i den här referensen:
| CSA CCM-kontroll-ID | CSA CCM-kontrolldomän |
|---|---|
| IPY-04 | Nätverksprotokoll |
| IVS-06 | Nätverkssäkerhet |
Nätverksimplementeringen skyddas ytterligare genom att man definierar kontroller från MAFB. Kontrollerna säkerställer att trafiken till miljön begränsas från det offentliga Internet.
I följande lista visas DE CIS-kontroller som hanterar nätverkssäkerhet i den här referensen:
| CIS-kontroll-ID | Beskrivning av CIS-kontroll |
|---|---|
| 6,2 | Kontrollera att SSH-åtkomsten är begränsad från Internet. |
| 6.3 | Se till att inga SQL-databaser tillåter inkommande 0.0.0.0/0 (ALLA IP-adresser). |
| 6.5 | Kontrollera att Network Watcher är Aktiverad. |
| 6.6 | Se till att ingress med UDP är begränsad från Internet. |
Azure Spring Apps kräver hanteringstrafik för utgående trafik från Azure när den distribueras i en skyddad miljö. Du måste tillåta de nätverks- och programregler som anges i Kundens ansvarsområden för att köra Azure Spring Apps i ett virtuellt nätverk.
Programsäkerhet
Den här designprincipen omfattar de grundläggande komponenterna i identitet, dataskydd, nyckelhantering och programkonfiguration. Ett program som distribueras i Azure Spring Apps körs avsiktligt med minsta möjliga behörighet för att fungera. Uppsättningen auktoriseringskontroller är direkt relaterad till dataskydd när du använder tjänsten. Nyckelhantering stärker den här metoden för programsäkerhet i lager.
I följande lista visas de CCM-kontroller som hanterar nyckelhantering i den här referensen:
| CSA CCM-kontroll-ID | CSA CCM-kontrolldomän |
|---|---|
| EKM-01 | Berättigande till kryptering och nyckelhantering |
| EKM-02 | Nyckelgenerering för kryptering och nyckelhantering |
| EKM-03 | Kryptering och nyckelhantering Känsligt dataskydd |
| EKM-04 | Lagring och åtkomst för kryptering och nyckelhantering |
Från CCM, EKM-02 och EKM-03 rekommenderar vi principer och procedurer för att hantera nycklar och använda krypteringsprotokoll för att skydda känsliga data. EKM-01 rekommenderar att alla kryptografiska nycklar har identifierbara ägare så att de kan hanteras. EKM-04 rekommenderar användning av standardalgoritmer.
I följande lista visas de CIS-kontroller som hanterar nyckelhantering i den här referensen:
| CIS-kontroll-ID | Beskrivning av CIS-kontroll |
|---|---|
| 8.1 | Kontrollera att förfallodatumet har angetts för alla nycklar. |
| 8.2 | Kontrollera att förfallodatumet har angetts för alla hemligheter. |
| 8,4 | Kontrollera att nyckelvalvet kan återställas. |
CIS-kontrollerna 8.1 och 8.2 rekommenderar att förfallodatum anges för autentiseringsuppgifter för att säkerställa att rotation tillämpas. CIS-kontroll 8.4 säkerställer att innehållet i nyckelvalvet kan återställas för att upprätthålla affärskontinuiteten.
Aspekter av programsäkerhet utgör grunden för användningen av den här referensarkitekturen för att stödja en Spring-arbetsbelastning i Azure.
Nästa steg
Utforska den här referensarkitekturen via ARM-, Terraform- och Azure CLI-distributionerna som är tillgängliga på lagringsplatsen referensarkitektur för Azure Spring Apps .