Referensarkitektur för Azure Spring Apps

Anmärkning

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 platser 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 nav-och-ekra-design för företagsanvändning av Azure Spring Apps. I utformningen distribueras Azure Spring Apps i en enda arm som är beroende av delade tjänster som är värdade i hubben. Arkitekturen är byggd 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 Config Server, Spring Cloud Service Registry och kpack-byggtjänsten.

Azure Spring Apps Enterprise-planen består av VMware Tanzu® Build Service™, Application Configuration Service för VMware Tanzu®, VMware Tanzu® Service Registry, Spring Cloud Gateway för 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.

Distributionsalternativ för den här arkitekturen omfattar Azure Resource Manager (ARM), Terraform, Azure CLI och Bicep. Artefakterna på den här lagringsplatsen ger 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örtid
Spring Boot-applikationer

Vart och ett av dessa undernät kräver ett dedikerat Azure Spring Apps-kluster. Flera kluster kan inte dela samma undernät. Minsta storlek för varje undernät är /28. Antalet programinstanser som Azure Spring Apps kan stödja varierar beroende på undernätets storlek. Du hittar detaljerade krav för virtuella nätverk i avsnittet Krav för virtuellt nätverk i Distribuera Azure Spring Apps i ett virtuellt nätverk.

Varning

Den valda undernätsstorleken kan inte överlappa det befintliga virtuella nätverkets adressutrymme och bör inte överlappa med några peer-kopplade 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 applikationer

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äkerhetsriktmärke bör tillämpas.
DNS-poster för applikationsvärdar ska lagras i Azure Private 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 bör färdas via en central virtuell nätverksinstallation (NVA) (till exempel Azure Firewall).
Om Azure Spring Apps Config Server används för att läsa in konfigurationsegenskaper från en lagringsplats måste lagringsplatsen vara privat.
Microsofts nollförtroendesäkerhetsmetod kräver att hemligheter, certifikat och autentiseringsuppgifter lagras i ett säkert valv. Den rekommenderade tjänsten är Azure Key Vault.
Namnupplösning för värdar lokalt och i molnet bör vara dubbelriktad.
Ingen direkt utgående trafik till det offentliga Internet förutom för kontrollplanstrafik.
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)
- Gateväg
Hubbprenumeration
- Application Gateway-undernät
- Azure Firewall-undernät
- Undernät för delade tjänster
Ansluten prenumeration
- Azure Bastion-undernät
- Virtuellt nätverkspeer

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 fullt utrustad CI/CD-tjänst som automatiskt kan distribuera uppdaterade Spring Boot-appar till Azure Spring Apps.
Microsoft Defender för molnet: ett enhetligt säkerhetshanterings- och hotskyddssystem för arbetsbelastningar lokalt, flera moln och 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älkonstruerad hubb- och ekerdesign som uppfyller ovanstående krav:

Standardplan
Enterpriseplan

Offentliga applikationer

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äkerhetsriktmärke bör tillämpas.
DNS-poster för applikationsvärdar ska lagras i Azure Private 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 bör 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 nollförtroendesäkerhetsmetod kräver att hemligheter, certifikat och autentiseringsuppgifter lagras i ett säkert valv. Den rekommenderade tjänsten är Azure Key Vault.
Namnlösning av värdars namn lokalt och i molnet bör vara dubbelriktad.
Ingen direkt utgående trafik till det offentliga Internet förutom för kontrollplanstrafik.
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)
- Gateväg
Hubbprenumeration
- Application Gateway-undernät
- Azure Firewall-undernät
- Undernät för delade tjänster
Ansluten prenumeration
- Azure Bastion-undernät
- Virtuellt nätverkspeer

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) som körs på nivå 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 fullständig CI/CD-tjänst (Continuous Integration/Continuous Development) som automatiskt kan distribuera uppdaterade Spring Boot-appar till Azure Spring Apps.
Microsoft Defender för molnet: ett enhetligt säkerhetshanterings- och hotskyddssystem för arbetsbelastningar lokalt, flera moln och 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älkonstruerad hubb- och ekerdesign som uppfyller ovanstående krav. Endast det virtuella hubbnätverket kommunicerar med Internet:

Standardplan
Företagsplan

Lokal Azure Spring Apps-anslutning

Program i Azure Spring Apps kan kommunicera med olika azure-resurser, lokala och externa resurser. Med hjälp av hubb- och ekerdesignen kan applikationer dirigera trafik externt eller till det lokala nätverket via Express Route eller plats-till-plats Virtuellt Privat Nätverk (VPN).

Överväganden för Azure Well-Architected Framework

Azure Well-Architected Framework är en uppsättning vägledande grundsatser att följa för 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 infrastrukturutbredning en verklighet. 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 driftkostnaderna för att hantera Kubernetes, vilket inkluderar 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.

Driftskvalitet

Azure Spring Apps tar upp flera aspekter av driftskvalitet. 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 dina programs hälsa och prestanda. Ö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 att kräva 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 program 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 införliva 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äl definierad hubb- och ekermodell, säkerställer denna arkitekturs grund att du kan distribuera den till flera regioner. För användningsfallet för privata program använder arkitekturen Azure Private DNS för att säkerställa fortsatt tillgänglighet under 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 koncis och väldefinierad metod, till exempel "Använd principen med minsta möjliga behörighet när du implementerar åtkomst till informationssystemet. IAM-05" Kontrollerna i den här arkitekturen kommer från Cloud Control Matrix (CCM) av Cloud Security Alliance (CSA) och Microsoft Azure Foundations Benchmark (MAFB) av 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.

Styrelseskick

Den primära styrningsaspekten som den här arkitekturen hanterar är segregation genom isolering av nätverksresurser. I CCM rekommenderar DCS-08 ingress- och utgående kontroll för datacentret. För att uppfylla kontrollkraven använder arkitekturen en hubb-och-ekerd-design och nätverkssäkerhetsgrupper (NSG:er) för att filtrera östlig-västlig trafik mellan resurser. Arkitekturen filtrerar även trafik mellan centrala tjänster i hubben och resurser 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 den kontroll som hanterar datacentersäkerhet i den här referensen:

CSA CCM-kontroll-ID	CSA CCM-kontrolldomän
DCS-08	Datacentersäkerhet Otillåten Personers Inträde

Nätverk

Nätverksdesignen som stöder den här arkitekturen härleds från den traditionella hubb- 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 trafik mellan nord och syd (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 definiera 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 denna referens.

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 åtkomst från 0.0.0.0/0 (vilken IP-adress som helst).
6.5	Kontrollera att Network Watcher är "Aktiverat".
6.6	Se till att inkommande användning av UDP är begränsad från Internet.

Azure Spring Apps kräver att hanteringstrafik går ut från Azure när det distribueras i en säker 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 säkerhetsmetoden för skiktade program.

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	Kryptering och nyckelhantering: Nyckelgenerering
EKM-03	Kryptering och nyckelhantering Känsligt dataskydd
EKM-04	Kryptering och nyckelhantering: lagring och åtkomst

Från CCM, EKM-02 och EKM-03 rekommenderar 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 adresserar nyckelhantering i denna referens.

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 det går att återställa nyckelvalvet.

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ärskontinuitet.

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 för Azure Spring Apps-referensarkitektur .

Last updated on 2022-05-31

Dela via