Referentiearchitectuur voor Azure Spring Apps

Dit artikel is van toepassing op: ✔️ Standard ✔️ Enterprise

Deze referentiearchitectuur vormt een fundament voor het gebruik van Azure Spring Apps en is gebaseerd op een typisch ontwerpprincipe van een enterprise hub-en-spoke-structuur. In het ontwerp wordt Azure Spring Apps geïmplementeerd in één spoke die afhankelijk is van gedeelde services die worden gehost in de hub. De architectuur is gebouwd met onderdelen voor het realiseren van de principes in het Microsoft Azure Well-Architected Framework.

Er zijn twee varianten van Azure Spring Apps: Standard-abonnement en Enterprise-abonnement.

Het Azure Spring Apps Standard-plan bestaat uit de Spring Cloud-configuratieserver, het Spring Cloud-serviceregister en de kpack-buildservice.

Het Azure Spring Apps Enterprise-plan bestaat uit de VMware Tanzu® Build Service™, Application Configuration Service voor VMware Tanzu®, VMware Tanzu® Service Registry, Spring Cloud Gateway voor VMware Tanzu® en API-portal voor VMware Tanzu®.

Zie de Referentiearchitectuur van Azure Spring Apps op GitHub voor een implementatie van deze architectuur.

Implementatieopties voor deze architectuur zijn onder andere Azure Resource Manager (ARM), Terraform, Azure CLI en Bicep. De artefacten in deze opslagplaats bieden een basis die u kunt aanpassen voor uw omgeving. U kunt resources, zoals Azure Firewall of Application Gateway, groeperen in verschillende resourcegroepen of abonnementen. Deze groepering helpt bij het scheiden van verschillende functies, zoals IT-infrastructuur, beveiliging, bedrijfstoepassingsteams, enzovoort.

De adresruimte plannen

Voor Azure Spring Apps zijn twee toegewezen subnetten vereist:

• Service runtime
• Spring Boot-toepassingen

Voor elk van deze subnetten is een toegewezen Azure Spring Apps-cluster vereist. Meerdere clusters kunnen niet dezelfde subnetten delen. De minimale grootte van elk subnet is /28. Het aantal toepassingsexemplaren dat Door Azure Spring Apps kan worden ondersteund, is afhankelijk van de grootte van het subnet. U vindt de gedetailleerde vereisten voor virtuele netwerken in de sectie Vereisten voor virtuele netwerken van Azure Spring Apps implementeren in een virtueel netwerk.

Gebruikssituaties

Deze architectuur wordt doorgaans gebruikt voor:

• Privétoepassingen: Interne toepassingen die zijn geïmplementeerd in hybride cloudomgevingen
• Openbare toepassingen: extern gerichte toepassingen

Deze gebruiksvoorbeelden zijn vergelijkbaar, met uitzondering van de regels voor beveiliging en netwerkverkeer. Deze architectuur is ontworpen ter ondersteuning van de nuances van elk.

Privétoepassingen

In de volgende lijst worden de infrastructuurvereisten voor privétoepassingen beschreven. Deze vereisten zijn typisch in sterk gereglementeerde omgevingen.

• Een subnet mag slechts één exemplaar van Azure Spring Apps hebben.
• Naleving van ten minste één beveiligingsbenchmark moet worden afgedwongen.
• DNS-records (Application Host Domain Name Service) moeten worden opgeslagen in privé-DNS van Azure.
• Azure-serviceafhankelijkheden moeten communiceren via service-eindpunten of Private Link.
• Gegevens die stilliggen moeten worden versleuteld.
• Gegevens die onderweg zijn, moeten worden versleuteld.
• DevOps-implementatiepijplijnen kunnen worden gebruikt (bijvoorbeeld Azure DevOps) en vereisen netwerkconnectiviteit met Azure Spring Apps.
• Uitgaand verkeer moet worden uitgevoerd via een centraal NVA (Network Virtual Appliance) (bijvoorbeeld Azure Firewall).
• Als Azure Spring Apps Config Server wordt gebruikt om configuratie-eigenschappen uit een opslagplaats te laden, moet de opslagplaats privé zijn.
• Voor de Zero Trust-beveiligingsbenadering van Microsoft moeten geheimen, certificaten en referenties worden opgeslagen in een beveiligde kluis. De aanbevolen service is Azure Key Vault.
• Naamresolutie van hosts on-premises en in de cloud moet bidirectioneel zijn.
• Geen directe uitgaand verkeer naar het openbare internet, met uitzondering van besturingsvlakverkeer.
• Resourcegroepen die worden beheerd door de Azure Spring Apps-implementatie, mogen niet worden gewijzigd.
• Subnetten die worden beheerd door de Azure Spring Apps-implementatie, mogen niet worden gewijzigd.

De volgende lijst bevat de onderdelen waaruit het ontwerp bestaat:

• On-premises netwerk
  • Domain Name Service (DNS)
  • Toegangspoort
• Hub-abonnement
  • Application Gateway subnet
  • Azure Firewall-subnet
  • Subnet gedeelde diensten
• Verbonden abonnement
  • Azure Bastion-subnet
  • Peer van virtueel netwerk

In de volgende lijst worden de Azure-services in deze referentiearchitectuur beschreven:

• Azure Key Vault: een door hardware ondersteunde referentiebeheerservice die nauw is geïntegreerd met Microsoft Identity Services en rekenresources.

• Azure Monitor: een uitgebreide suite met bewakingsservices voor toepassingen die zowel in Azure als on-premises worden geïmplementeerd.

• Azure Pipelines: een volledig functionele CI/CD-service (Continuous Integration/ Continuous Development) waarmee automatisch bijgewerkte Spring Boot-apps kunnen worden geïmplementeerd in Azure Spring Apps.

• Microsoft Defender voor Cloud: een geïntegreerd systeem voor beveiligingsbeheer en bedreigingsbeveiliging voor workloads in on-premises, meerdere clouds en Azure.

• Azure Spring Apps: een beheerde service die speciaal is ontworpen en geoptimaliseerd voor Spring Boot-toepassingen op basis van Java en . Op NET gebaseerde Steeltoe-toepassingen .

De volgende diagrammen vertegenwoordigen een goed ontworpen hub- en spoke-ontwerp dat voldoet aan de bovenstaande vereisten:

Openbare toepassingen

In de volgende lijst worden de infrastructuurvereisten voor openbare toepassingen beschreven. Deze vereisten zijn typisch in sterk gereglementeerde omgevingen.

• Een subnet mag slechts één exemplaar van Azure Spring Apps hebben.
• Naleving van ten minste één beveiligingsbenchmark moet worden afgedwongen.
• DNS-records (Application Host Domain Name Service) moeten worden opgeslagen in privé-DNS van Azure.
• Azure DDoS Protection moet zijn ingeschakeld.
• Azure-serviceafhankelijkheden moeten communiceren via service-eindpunten of Private Link.
• Data in rust dienen te worden versleuteld.
• Gegevens die onderweg zijn, moeten worden versleuteld.
• DevOps-implementatiepijplijnen kunnen worden gebruikt (bijvoorbeeld Azure DevOps) en vereisen netwerkconnectiviteit met Azure Spring Apps.
• Uitgaand verkeer moet worden uitgevoerd via een centraal NVA (Network Virtual Appliance) (bijvoorbeeld Azure Firewall).
• Inkomend verkeer moet worden beheerd door minstens Application Gateway of Azure Front Door.
• Routeerbare internetadressen moeten worden opgeslagen in openbare DNS van Azure.
• Voor de Zero Trust-beveiligingsbenadering van Microsoft moeten geheimen, certificaten en referenties worden opgeslagen in een beveiligde kluis. De aanbevolen service is Azure Key Vault.
• Naamresolutie van hosts on-premises en in de cloud moet bidirectioneel zijn.
• Geen directe uitgaand verkeer naar het openbare internet, met uitzondering van besturingsvlakverkeer.
• Resourcegroepen die worden beheerd door de Azure Spring Apps-implementatie, mogen niet worden gewijzigd.
• Subnetten die worden beheerd door de Azure Spring Apps-implementatie, mogen niet worden gewijzigd.

De volgende lijst bevat de onderdelen waaruit het ontwerp bestaat:

• On-premises netwerk
  • Domain Name Service (DNS)
  • Toegangspoort
• Hub-abonnement
  • Application Gateway-subnet
  • Azure Firewall Subnet
  • Subnet gedeelde services
• Verbonden abonnement
  • Azure Bastion-subnetwerk
  • Peer van virtueel netwerk

In de volgende lijst worden de Azure-services in deze referentiearchitectuur beschreven:

• Azure Application Firewall: een functie van Azure Application Gateway die gecentraliseerde beveiliging van toepassingen biedt tegen veelvoorkomende aanvallen en beveiligingsproblemen.

• Azure Application Gateway: een load balancer die verantwoordelijk is voor toepassingsverkeer met TLS-offload (Transport Layer Security) op laag 7.

• Azure Key Vault: een door hardware ondersteunde referentiebeheerservice die nauw is geïntegreerd met Microsoft Identity Services en rekenresources.

• Azure Monitor: een uitgebreide suite met bewakingsservices voor toepassingen die zowel in Azure als on-premises worden geïmplementeerd.

• Azure Pipelines: een volledig functionele CI/CD-service (Continuous Integration/ Continuous Development) waarmee automatisch bijgewerkte Spring Boot-apps kunnen worden geïmplementeerd in Azure Spring Apps.

• Microsoft Defender voor Cloud: een geïntegreerd systeem voor beveiligingsbeheer en bedreigingsbeveiliging voor workloads in on-premises, meerdere clouds en Azure.

• Azure Spring Apps: een beheerde service die speciaal is ontworpen en geoptimaliseerd voor Spring Boot-toepassingen op basis van Java en . Op NET gebaseerde Steeltoe-toepassingen .

De volgende diagrammen vertegenwoordigen een goed ontworpen hub- en spoke-ontwerp dat voldoet aan de bovenstaande vereisten. Alleen het hub-virtual-network communiceert met internet:

On-premises connectiviteit van Azure Spring Apps

Toepassingen in Azure Spring Apps kunnen communiceren met verschillende Azure-, on-premises en externe resources. Met behulp van het hub- en spoke-ontwerp kunnen toepassingen verkeer extern of naar het on-premises netwerk routeren met behulp van Express Route of Site-to-Site Virtual Private Network (VPN).

Overwegingen voor Azure Well-Architected Framework

Het Azure Well-Architected Framework is een reeks richtlijnen die moeten worden gevolgd bij het opzetten van een sterke infrastructuurbasis. Het framework bevat de volgende categorieën: kostenoptimalisatie, operationele uitmuntendheid, prestatie-efficiëntie, betrouwbaarheid en beveiliging.

Kostenoptimalisatie

Vanwege de aard van gedistribueerd systeemontwerp is infrastructuursprawl een realiteit. Deze realiteit resulteert in onverwachte en onbeheersbare kosten. Azure Spring Apps is gebouwd met behulp van onderdelen die schalen, zodat deze aan de vraag kan voldoen en de kosten kan optimaliseren. De kern van deze architectuur is de Azure Kubernetes Service (AKS). De service is ontworpen om de complexiteit en operationele overhead van het beheren van Kubernetes te verminderen, waaronder efficiëntie in de operationele kosten van het cluster.

U kunt verschillende toepassingen en toepassingstypen implementeren in één exemplaar van Azure Spring Apps. De service biedt ondersteuning voor automatisch schalen van toepassingen die worden geactiveerd door metrische gegevens of schema's die het gebruik en de kostenefficiëntie kunnen verbeteren.

U kunt Application Insights en Azure Monitor ook gebruiken om de operationele kosten te verlagen. Met de zichtbaarheid van de uitgebreide logboekregistratieoplossing kunt u automatisering implementeren om de onderdelen van het systeem in realtime te schalen. U kunt logboekgegevens ook analyseren om inefficiëntie in de toepassingscode weer te geven die u kunt aanpakken om de totale kosten en prestaties van het systeem te verbeteren.

Operationele uitmuntendheid

Azure Spring Apps heeft betrekking op meerdere aspecten van operationele uitmuntendheid. U kunt deze aspecten combineren om ervoor te zorgen dat de service efficiënt wordt uitgevoerd in productieomgevingen, zoals beschreven in de volgende lijst:

• U kunt Azure Pipelines gebruiken om ervoor te zorgen dat implementaties betrouwbaar en consistent zijn en u helpen menselijke fouten te voorkomen.
• U kunt Azure Monitor en Application Insights gebruiken om logboek- en telemetriegegevens op te slaan. U kunt verzamelde logboek- en metrische gegevens evalueren om de status en prestaties van uw toepassingen te garanderen. Application Performance Monitoring (APM) is volledig geïntegreerd in de service via een Java-agent. Deze agent biedt inzicht in alle geïmplementeerde toepassingen en afhankelijkheden zonder extra code. Zie het blogbericht Moeiteloos toepassingen en afhankelijkheden bewaken in Azure Spring Apps voor meer informatie.
• U kunt Microsoft Defender voor Cloud gebruiken om ervoor te zorgen dat toepassingen de beveiliging behouden door een platform te bieden voor het analyseren en beoordelen van de verstrekte gegevens.
• De service ondersteunt verschillende implementatiepatronen. Zie Een faseringsomgeving instellen in Azure Spring Apps voor meer informatie.

Betrouwbaarheid

Azure Spring Apps is gebouwd op AKS. Hoewel AKS een niveau van tolerantie biedt via clustering, gaat deze referentiearchitectuur nog verder door services en architectuuroverwegingen op te nemen om de beschikbaarheid van de toepassing te vergroten als er sprake is van een storing in het onderdeel.

Door voort te bouwen op een goed gedefinieerd hub- en spoke-ontwerp, zorgt de basis van deze architectuur ervoor dat u deze in meerdere regio's kunt implementeren. Voor de use-case van de privétoepassing maakt de architectuur gebruik van Azure Private DNS om ervoor te zorgen dat de beschikbaarheid tijdens een geografische fout blijft bestaan. Voor de use-case voor openbare toepassingen zorgen Azure Front Door en Azure Application Gateway voor beschikbaarheid.

Veiligheid

De beveiliging van deze architectuur wordt aangepakt door naleving van door de branche gedefinieerde controles en benchmarks. In deze context betekent 'controle' een beknopte en goed gedefinieerde best practice, zoals 'Gebruik het principe van minimale bevoegdheden bij het implementeren van toegang tot het informatiesysteem. IAM-05" De besturingselementen in deze architectuur zijn afkomstig van de Cloud Control Matrix (CCM) door de Cloud Security Alliance (CSA) en de Microsoft Azure Foundations Benchmark (MAFB) door het Center for Internet Security (CIS). In de toegepaste besturingselementen ligt de focus op de primaire principes voor beveiligingsontwerp van governance, netwerken en toepassingsbeveiliging. Het is uw verantwoordelijkheid om de ontwerpprincipes van Identiteit, Toegangsbeheer en Opslag af te handelen, omdat deze betrekking hebben op uw doelinfrastructuur.

Bestuur

Het belangrijkste aspect van governance dat door deze architectuur wordt aangepakt, is scheiding door de isolatie van netwerkbronnen. In de CCM raadt DCS-08 aan om toegangscontrole en uitgangscontrole voor het datacenter uit te voeren. Om aan het beheer te voldoen, gebruikt de architectuur een hub- en spoke-ontwerp met behulp van netwerkbeveiligingsgroepen (NSG's) om oost-westverkeer tussen resources te filteren. De architectuur filtert ook verkeer tussen centrale services in de hub en middelen in de spoke. De architectuur maakt gebruik van een exemplaar van Azure Firewall voor het beheren van verkeer tussen internet en de resources in de architectuur.

In de volgende lijst ziet u het besturingselement waarmee de beveiliging van datacenters in deze verwijzing wordt aangepakt:

Netwerk

Het netwerkontwerp dat deze architectuur ondersteunt, is afgeleid van het traditionele hub- en spoke-model. Deze beslissing zorgt ervoor dat netwerkisolatie een basisconstructie is. CCM-controle IVS-06 raadt aan dat verkeer tussen netwerken en virtuele machines wordt beperkt en bewaakt tussen vertrouwde en niet-vertrouwde omgevingen. Deze architectuur neemt de controle over door de implementatie van de NSG's voor oost-west-verkeer (binnen het 'datacentrum') en de Azure Firewall voor noord-zuidverkeer (buiten het 'datacentrum'). CCM-beheer IPY-04 raadt aan dat de infrastructuur beveiligde netwerkprotocollen moet gebruiken voor de uitwisseling van gegevens tussen services. De Azure-services die deze architectuur ondersteunen, maken allemaal gebruik van standaard beveiligde protocollen, zoals TLS voor HTTP en SQL.

In de volgende lijst ziet u de CCM-besturingselementen voor netwerkbeveiliging in deze verwijzing:

De netwerkuitvoering wordt verder beveiligd door besturingselementen van de MAFB te definiëren. Maatregelen zorgen ervoor dat verkeer naar de omgeving beperkt toegang heeft vanaf het openbare internet.

In de volgende lijst ziet u de CIS-besturingselementen die betrekking hebben op netwerkbeveiliging in deze verwijzing:

Azure Spring Apps vereist beheerverkeer om uitgaande verbindingen van Azure te maken wanneer deze wordt geïmplementeerd in een beveiligde omgeving. U moet de netwerk- en toepassingsregels die worden vermeld in de verantwoordelijkheden van de klant voor het uitvoeren van Azure Spring Apps in een virtueel netwerk toestaan.

Toepassingsbeveiliging

Dit ontwerpprincipe heeft betrekking op de fundamentele onderdelen van identiteit, gegevensbescherming, sleutelbeheer en toepassingsconfiguratie. Een toepassing die is geïmplementeerd in Azure Spring Apps, wordt standaard uitgevoerd met minimale bevoegdheid die is vereist om te functioneren. De set autorisatiebesturingselementen is rechtstreeks gerelateerd aan gegevensbeveiliging bij het gebruik van de service. Sleutelbeheer versterkt deze gelaagde benadering voor toepassingsbeveiliging.

In de volgende lijst ziet u de CCM-besturingselementen waarmee sleutelbeheer in deze verwijzing wordt aangepakt:

Vanuit de CCM, EKM-02 en EKM-03 worden beleidsregels en procedures aanbevolen om sleutels te beheren en versleutelingsprotocollen te gebruiken om gevoelige gegevens te beveiligen. EKM-01 raadt aan dat alle cryptografische sleutels identificeerbare eigenaren hebben, zodat ze kunnen worden beheerd. EKM-04 raadt het gebruik van standaardalgoritmen aan.

In de volgende lijst ziet u de CIS-controles die sleutelbeheer in deze context adresseren.

De CIS-besturingselementen 8.1 en 8.2 raden aan dat vervaldatums zijn ingesteld voor referenties om ervoor te zorgen dat rotatie wordt afgedwongen. CIS-controle 8.4 zorgt ervoor dat de inhoud van de sleutelkluis kan worden hersteld om bedrijfscontinuïteit te behouden.

De aspecten van toepassingsbeveiliging vormen een basis voor het gebruik van deze referentiearchitectuur ter ondersteuning van een Spring-workload in Azure.

Volgende stappen

Verken deze referentiearchitectuur via de ARM-, Terraform- en Azure CLI-implementaties die beschikbaar zijn in de opslagplaats voor referentiearchitectuur van Azure Spring Apps .