Architettura di riferimento di Azure Spring Apps

Questo articolo si applica a: ✔️ Standard ✔️ Enterprise

Questa architettura di riferimento rappresenta una base che utilizza una progettazione aziendale tipica di tipo "hub and spoke" per l'utilizzo di Azure Spring Apps. Nella fase di progettazione, Azure Spring Apps viene distribuito in uno spoke unico che dipende dai servizi condivisi ospitati nell'hub. L'architettura è costruita con dei componenti per raggiungere i principi nel Microsoft Azure Well-Architected Framework.

Esistono due versioni di App Spring di Azure: piano Standard ed Enterprise.

Il piano Standard di Azure Spring Apps è costituito dal server di configurazione Spring Cloud, dal Registro di sistema dei servizi Spring Cloud e dal servizio di compilazione kpack.

Il piano Enterprise di Azure Spring Apps è costituito dal servizio di compilazione VMware Tanzu®, dal servizio di configurazione delle applicazioni per VMware Tanzu, dal registro dei servizi VMware Tanzu®®, da Spring Cloud Gateway per VMware Tanzu® e dal portale API per VMware Tanzu®.™

Per un'implementazione di questa architettura, vedere l'architettura di riferimento di Azure Spring Apps in GitHub.

Le opzioni di distribuzione per questa architettura includono Azure Resource Manager (ARM), Terraform, l'interfaccia della riga di comando di Azure e Bicep. Gli artefatti in questo repository forniscono un fondamento che è possibile personalizzare per il tuo ambiente. È possibile raggruppare risorse come Firewall di Azure o il gateway applicazione in diversi gruppi di risorse o sottoscrizioni. Questo raggruppamento consente di mantenere diverse funzioni separate, ad esempio l'infrastruttura IT, la sicurezza, i team delle applicazioni aziendali e così via.

Pianificazione dello spazio degli indirizzi

Azure Spring Apps richiede due subnet dedicate:

• Runtime del servizio
• Applicazioni Spring Boot

Ognuna di queste subnet richiede un cluster di Azure Spring Apps dedicato. Più cluster non possono condividere le stesse subnet. La dimensione minima di ogni subnet è /28. Il numero di istanze dell'applicazione che Azure Spring Apps può supportare varia in base alle dimensioni della subnet. I requisiti dettagliati della rete virtuale sono disponibili nella sezione requisiti di rete virtuale di Distribuire app Azure Spring in una rete virtuale.

Casi d'uso

Tra gli usi tipici di questa architettura sono inclusi:

• Applicazioni private: applicazioni interne distribuite in ambienti cloud ibridi
• Applicazioni pubbliche: applicazioni con connessione esterna

Questi casi d'uso sono simili ad eccezione delle regole di sicurezza e del traffico di rete. Questa architettura è progettata per supportare le sfumature di ognuna.

Applicazioni private

L'elenco seguente descrive i requisiti dell'infrastruttura per le applicazioni private. Questi requisiti sono tipici in ambienti altamente regolamentati.

• Una subnet deve avere solo un'istanza di Azure Spring Apps.
• L'adesione ad almeno un benchmark di sicurezza deve essere applicata.
• I record DNS dell'host dell'applicazione devono essere archiviati nel DNS privato di Azure.
• Le dipendenze del servizio di Azure devono comunicare tramite endpoint di servizio o collegamento privato.
• I dati inattivi devono essere crittografati.
• I dati in transito devono essere crittografati.
• Le pipeline di distribuzione DevOps possono essere usate (ad esempio Azure DevOps) e richiedono la connettività di rete ad Azure Spring Apps.
• Il traffico in uscita deve attraversare un'appliance virtuale di rete centrale ,ad esempio Firewall di Azure.
• Se del server di configurazione di Azure Spring Apps viene usato per caricare le proprietà di configurazione da un repository, il repository deve essere privato.
• L'approccio di sicurezza Zero Trust di Microsoft richiede che segreti, certificati e credenziali siano archiviati in un archivio sicuro. Il servizio consigliato è Azure Key Vault.
• La risoluzione dei nomi degli host in locale e nel cloud deve essere bidirezionale.
• Nessun accesso diretto a Internet pubblico tranne che per il traffico del piano di controllo.
• I gruppi di risorse gestiti dalla distribuzione di Azure Spring Apps non devono essere modificati.
• Le subnet gestite dalla distribuzione di Azure Spring Apps non devono essere modificate.

L'elenco seguente mostra i componenti che costituiscono la progettazione:

• Rete locale
  • Domain Name Service (DNS)
  • Porta di accesso
• Abbonamento all'hub
  • Subnet del gateway applicativo
  • Subnet di Azure Firewall
  • Subnet servizi condivisi
• Sottoscrizione connessa
  • Azure Bastion Subnet
  • Peer di rete virtuale

L'elenco seguente descrive i servizi di Azure in questa architettura di riferimento:

• azure Key Vault: un servizio di gestione delle credenziali supportato dall'hardware che ha una stretta integrazione con i servizi di gestione delle identità Microsoft e le risorse di calcolo.

• Azure Monitor: una suite completa di servizi di monitoraggio per le applicazioni distribuite sia in Azure che in locale.

• Azure Pipelines: un servizio di integrazione continua/sviluppo continuo (CI/CD) completo in grado di distribuire automaticamente le app Spring Boot aggiornate in Azure Spring Apps.

• Microsoft Defender for Cloud: un sistema unificato di gestione della sicurezza e protezione dalle minacce per carichi di lavoro in locale, più cloud e Azure.

• Azure Spring Apps: un servizio gestito progettato e ottimizzato specificamente per le applicazioni Spring Boot basate su Java e le applicazioni di Steeltoe basate su .NET.

I diagrammi seguenti rappresentano una progettazione di hub e spoke ben progettata che soddisfa i requisiti precedenti:

Applicazioni pubbliche

L'elenco seguente descrive i requisiti dell'infrastruttura per le applicazioni pubbliche. Questi requisiti sono tipici in ambienti altamente regolamentati.

• Una subnet deve avere solo un'istanza di Azure Spring Apps.
• L'adesione ad almeno un benchmark di sicurezza deve essere applicata.
• I record DNS dell'host dell'applicazione devono essere archiviati nel DNS privato di Azure.
• La protezione DDoS di Azure deve essere abilitata.
• Le dipendenze del servizio di Azure devono comunicare tramite endpoint di servizio o collegamento privato.
• I dati inattivi devono essere crittografati.
• I dati in transito devono essere crittografati.
• Le pipeline di distribuzione DevOps possono essere usate (ad esempio Azure DevOps) e richiedono la connettività di rete ad Azure Spring Apps.
• Il traffico in uscita deve attraversare un'appliance virtuale di rete centrale ,ad esempio Firewall di Azure.
• Il traffico in ingresso dovrebbe essere gestito almeno da Application Gateway o Azure Front Door.
• Gli indirizzi instradabili Internet devono essere archiviati in DNS pubblico di Azure.
• L'approccio di sicurezza Zero Trust di Microsoft richiede che segreti, certificati e credenziali siano archiviati in un archivio sicuro. Il servizio consigliato è Azure Key Vault.
• La risoluzione dei nomi degli host in locale e nel cloud deve essere bidirezionale.
• Nessun accesso diretto a Internet pubblico tranne che per il traffico del piano di controllo.
• I gruppi di risorse gestiti dalla distribuzione di Azure Spring Apps non devono essere modificati.
• Le subnet gestite dalla distribuzione di Azure Spring Apps non devono essere modificate.

L'elenco seguente mostra i componenti che costituiscono la progettazione:

• Rete locale
  • Domain Name Service (DNS)
  • Porta di accesso
• Abbonamento all'hub
  • Subnet del gateway applicativo
  • Subnet di Azure Firewall
  • Subnet servizi condivisi
• Sottoscrizione connessa
  • Azure Bastion Subnet
  • Peer di rete virtuale

L'elenco seguente descrive i servizi di Azure in questa architettura di riferimento:

• Firewall per Applicazioni di Azure: una funzionalità dell'Application Gateway di Azure che fornisce una protezione centralizzata delle applicazioni dai comuni exploit e vulnerabilità.

• "Azure Application Gateway": un bilanciatore di carico responsabile della gestione del traffico applicativo con offload di TLS (Transport Layer Security) al livello 7.

• azure Key Vault: un servizio di gestione delle credenziali supportato dall'hardware che ha una stretta integrazione con i servizi di gestione delle identità Microsoft e le risorse di calcolo.

• Azure Monitor: una suite completa di servizi di monitoraggio per le applicazioni distribuite sia in Azure che in locale.

• Azure Pipelines: un servizio di integrazione continua/sviluppo continuo (CI/CD) completo in grado di distribuire automaticamente le app Spring Boot aggiornate in Azure Spring Apps.

• Microsoft Defender for Cloud: un sistema unificato di gestione della sicurezza e protezione dalle minacce per carichi di lavoro in locale, più cloud e Azure.

• Azure Spring Apps: un servizio gestito progettato e ottimizzato specificamente per le applicazioni Spring Boot basate su Java e le applicazioni di Steeltoe basate su .NET.

I diagrammi seguenti rappresentano una progettazione di hub e spoke ben progettata che soddisfa i requisiti precedenti. Solo la rete hub-virtuale comunica con Internet:

Connettività locale di Azure Spring Apps

Le applicazioni in Azure Spring Apps possono comunicare con varie risorse di Azure, locali ed esterne. Usando la progettazione hub-spoke, le applicazioni possono instradare il traffico esternamente o alla rete locale usando ExpressRoute o la rete privata virtuale da sito a sito (VPN).

Considerazioni su Azure Well-Architected Framework

L' Azure Well-Architected Framework è un set di principi guida da seguire per stabilire una solida base dell'infrastruttura. Il framework contiene le categorie seguenti: ottimizzazione dei costi, eccellenza operativa, efficienza delle prestazioni, affidabilità e sicurezza.

Ottimizzazione dei costi

A causa della natura della progettazione del sistema distribuito, la diffusione dell'infrastruttura è una realtà. Questa realtà comporta costi imprevisti e non controllabili. App Spring di Azure viene compilata usando componenti scalabili in modo che possa soddisfare la domanda e ottimizzare i costi. Il nucleo di questa architettura è il servizio Azure Kubernetes. Il servizio è progettato per ridurre la complessità e il sovraccarico operativo della gestione di Kubernetes, che include efficienza nel costo operativo del cluster.

È possibile distribuire applicazioni e tipi di applicazioni diversi in una singola istanza di Azure Spring Apps. Il servizio supporta la scalabilità automatica delle applicazioni attivate da metriche o pianificazioni che possono migliorare l'utilizzo e l'efficienza dei costi.

È anche possibile usare Application Insights e Monitoraggio di Azure per ridurre i costi operativi. Con la visibilità fornita dalla soluzione di registrazione completa, è possibile implementare l'automazione per ridimensionare i componenti del sistema in tempo reale. È anche possibile analizzare i dati di log per rivelare inefficienze nel codice dell'applicazione che è possibile affrontare per migliorare il costo complessivo e le prestazioni del sistema.

Eccellenza operativa

Azure Spring Apps affronta più aspetti dell'eccellenza operativa. È possibile combinare questi aspetti per garantire che il servizio venga eseguito in modo efficiente negli ambienti di produzione, come descritto nell'elenco seguente:

• È possibile usare Azure Pipelines per garantire che le distribuzioni siano affidabili e coerenti, evitando al contempo errori umani.
• È possibile usare Monitoraggio di Azure e Application Insights per archiviare i dati di log e telemetria. È possibile valutare i dati dei log e delle metriche raccolti per garantire l'integrità e le prestazioni delle applicazioni. Application Performance Monitoring (APM) è completamente integrato nel servizio tramite un agente Java. Questo agente offre visibilità su tutte le applicazioni e le dipendenze distribuite senza richiedere codice aggiuntivo. Per altre informazioni, vedere il post di blog Monitoraggio semplice di applicazioni e dipendenze in Azure Spring Apps.
• È possibile usare Microsoft Defender for Cloud per garantire che le applicazioni mantengano la sicurezza fornendo una piattaforma per analizzare e valutare i dati forniti.
• Il servizio supporta vari modelli di distribuzione. Per altre informazioni, vedere Configurare un ambiente di gestione temporanea in Azure Spring Apps.

Affidabilità

Azure Spring Apps è basato su AKS. Anche se AKS offre un livello di resilienza tramite il clustering, questa architettura di riferimento va oltre e incorpora servizi e considerazioni architetturali per aumentare la disponibilità dell'applicazione in caso di guasto di un componente.

Basandosi su una progettazione di hub e spoke ben definita, la base di questa architettura garantisce che sia possibile distribuirla in più aree. Per il caso d'uso dell'applicazione privata, l'architettura usa DNS privato di Azure per garantire la disponibilità continua durante un errore geografico. Per il caso d'uso dell'applicazione pubblica, Frontdoor di Azure e gateway applicazione di Azure garantiscono la disponibilità.

Sicurezza

La sicurezza di questa architettura viene affrontata in conformità ai controlli e ai benchmark definiti dal settore. In questo contesto, "controllo" significa una procedura consigliata concisa e ben definita, ad esempio "Impiegare il principio dei privilegi minimi quando si implementa l'accesso al sistema informativo. IAM-05" I controlli in questa architettura provengono dalla Matrice di controllo cloud (CCM) dall'Cloud Security Alliance (CSA) e dal Microsoft Azure Foundations Benchmark (MAFB) dal Center for Internet Security (CIS). Nei controlli applicati, l'attenzione è rivolta ai principali principi di progettazione della sicurezza della governance, della rete e della sicurezza delle applicazioni. È responsabilità dell'utente gestire i principi di progettazione dell'identità, della gestione degli accessi e dell'archiviazione in relazione all'infrastruttura di destinazione.

Gestione

L'aspetto principale della governance affrontato da questa architettura è la separazione tramite l'isolamento delle risorse di rete. In CCM, DCS-08 consiglia il controllo degli ingressi e delle uscite per il datacenter. Per soddisfare il controllo, l'architettura usa una progettazione hub-spoke usando gruppi di sicurezza di rete (NSG) per filtrare il traffico east-west tra le risorse. L'architettura filtra anche il traffico tra i servizi centrali nell'hub e le risorse nello spoke. L'architettura usa un'istanza di Firewall di Azure per gestire il traffico tra Internet e le risorse all'interno dell'architettura.

L'elenco seguente mostra il controllo che punta alla sicurezza del data center in questo riferimento:

Rete

La progettazione di rete che supporta questa architettura deriva dal modello hub-spoke tradizionale. Questa decisione garantisce che l'isolamento della rete sia un costrutto fondamentale. Il controllo CCM IVS-06 consiglia che il traffico tra reti e macchine virtuali sia limitato e monitorato tra ambienti attendibili e non attendibili. Questa architettura adotta il controllo tramite l'implementazione dei gruppi di sicurezza di rete per il traffico est-ovest (all'interno del "data center") e firewall di Azure per il traffico nord-sud (all'esterno del "data center"). Il controllo CCM IPY-04 consiglia all'infrastruttura di usare protocolli di rete sicuri per lo scambio di dati tra servizi. I servizi di Azure che supportano questa architettura usano tutti protocolli sicuri standard, ad esempio TLS per HTTP e SQL.

L'elenco seguente mostra i controlli CCM che indirizzano la sicurezza di rete in questo riferimento:

L'implementazione di rete è ulteriormente protetta definendo i controlli del MAFB. I controlli assicurano che il traffico nell'ambiente sia limitato dalla rete Internet pubblica.

L'elenco seguente mostra i controlli CIS che indirizzano la sicurezza di rete in questo riferimento:

Azure Spring Apps richiede il traffico di gestione verso l'uscita da Azure quando viene distribuito in un ambiente protetto. È necessario consentire le regole di rete e applicazione elencate in Responsabilità del cliente per l'esecuzione di App Spring di Azure in una rete virtuale.

Sicurezza delle applicazioni

Questo principio di progettazione riguarda i componenti fondamentali dell'identità, della protezione dei dati, della gestione delle chiavi e della configurazione dell'applicazione. Per impostazione predefinita, un'applicazione distribuita in Azure Spring Apps viene eseguita con privilegi minimi necessari per funzionare. Il set di controlli di autorizzazione è direttamente correlato alla protezione dei dati quando si usa il servizio. La gestione delle chiavi rafforza questo approccio di sicurezza delle applicazioni a più livelli.

L'elenco seguente mostra i controlli CCM che indirizzano la gestione delle chiavi in questo riferimento:

Da CCM, EKM-02 e EKM-03 consiglia criteri e procedure per gestire le chiavi e usare i protocolli di crittografia per proteggere i dati sensibili. EKM-01 consiglia che tutte le chiavi crittografiche abbiano proprietari identificabili in modo che possano essere gestite. EKM-04 consiglia l'uso di algoritmi standard.

L'elenco seguente mostra i controlli CIS che indirizzano la gestione delle chiavi in questo contesto.

I controlli CIS 8.1 e 8.2 consigliano che le date di scadenza siano impostate per le credenziali per assicurarsi che venga applicata la rotazione. Il controllo CIS 8.4 garantisce che il contenuto dell'archivio delle chiavi possa essere ripristinato per mantenere la continuità aziendale.

Gli aspetti della sicurezza delle applicazioni impostano una base per l'uso di questa architettura di riferimento per supportare un carico di lavoro Spring in Azure.

Passaggi successivi

Esplora questa architettura di riferimento tramite le distribuzioni ARM, Terraform e Azure CLI disponibili nel repository Azure Spring Apps Reference Architecture.