Condividi tramite

Architettura di riferimento di Azure Spring Apps

  • Articolo

Nota

Azure Spring Apps è il nuovo nome per il servizio Azure Spring Cloud. Anche se il servizio ha un nuovo nome, verrà visualizzato il vecchio nome in alcune posizioni per un po', mentre si lavora per aggiornare gli asset, ad esempio screenshot, video e diagrammi.

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

Questa architettura di riferimento è una base usando una tipica progettazione hub aziendale e spoke per l'uso di Azure Spring Apps. Nella progettazione, Azure Spring Apps viene distribuito in un singolo spoke dipendente dai servizi condivisi ospitati nell'hub. L'architettura viene compilata con i componenti per ottenere i set di dati in Microsoft Azure Well-Architected Framework.

Esistono due versioni di Azure Spring Apps: piano Standard e Piano Enterprise.

Il piano Standard di Azure Spring Apps è costituito da Spring Cloud Config Server, dal Registro di sistema 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 dell'applicazione per VMware Tanzu, dal Registro di sistema 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, interfaccia della riga di comando di Azure e Bicep. Gli artefatti in questo repository forniscono una base che è possibile personalizzare per l'ambiente. È possibile raggruppare risorse come Firewall di Azure o gateway applicazione in diversi gruppi di risorse o sottoscrizioni. Questo raggruppamento consente di mantenere diverse funzioni separate, ad esempio infrastruttura IT, sicurezza, team di applicazioni aziendali e così via.

Pianificazione dello spazio indirizzi

Azure Spring Apps richiede due subnet dedicate:

  • Runtime del servizio
  • Applicazioni Spring Boot

Ognuna di queste subnet richiede un cluster 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. È possibile trovare i requisiti di rete virtuale dettagliati nella sezione Requisiti di rete virtuale della distribuzione di Azure Spring Apps in una rete virtuale.

Avviso

Le dimensioni della subnet selezionate non possono sovrapporsi allo spazio indirizzi della rete virtuale esistente e non devono sovrapporsi a intervalli di indirizzi di subnet peered o locali.

Casi d'uso

Tra gli usi tipici di questa architettura sono inclusi:

  • Applicazioni private: applicazioni interne distribuite in ambienti cloud ibridi
  • Applicazioni pubbliche: applicazioni esterne

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

Applicazioni private

Nell'elenco seguente vengono descritti i requisiti di 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 a almeno un benchmark di sicurezza deve essere applicata.
  • I record DNS (Application Host Domain Name Service) devono essere archiviati in Azure DNS privato.
  • 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 (NVA) (ad esempio, Firewall di Azure).
  • Se il 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 Microsoft richiede segreti, certificati e credenziali da archiviare in un insieme di credenziali sicuro. Il servizio consigliato è Azure Key Vault.
  • La risoluzione dei nomi degli host in locale e nel cloud deve essere bidirezionale.
  • Nessuna uscita diretta verso Internet pubblico, ad eccezione del 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
    • Servizio nome di dominio (DNS)
    • Gateway
  • Sottoscrizione dell'hub
    • subnet gateway applicazione
    • subnet Firewall di Azure
    • Subnet dei servizi condivisi
  • Sottoscrizione connessa
    • Azure Bastion Subnet
    • Rete virtuale peer

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

  • Azure Key Vault: un servizio di gestione delle credenziali supportato da hardware con integrazione stretta con i servizi di identità Microsoft e le risorse di calcolo.

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

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

  • Microsoft Defender per cloud: un sistema di gestione e protezione delle minacce unificato per i carichi di lavoro in locale, più cloud e Azure.

  • App Spring di Azure: un servizio gestito progettato e ottimizzato in modo specifico per le applicazioni Spring Boot basate su Java e . Applicazioni Steeltoe basate su NET.

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

Applicazioni pubbliche

Nell'elenco seguente vengono descritti i requisiti di 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 a almeno un benchmark di sicurezza deve essere applicata.
  • I record DNS (Application Host Domain Name Service) devono essere archiviati in Azure DNS privato.
  • 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 (NVA) (ad esempio, Firewall di Azure).
  • Il traffico in ingresso deve essere gestito da almeno gateway applicazione o frontdoor di Azure.
  • Gli indirizzi internet instradabili devono essere archiviati in DNS pubblico di Azure.
  • L'approccio di sicurezza Zero Trust Microsoft richiede segreti, certificati e credenziali da archiviare in un insieme di credenziali sicuro. Il servizio consigliato è Azure Key Vault.
  • La risoluzione dei nomi degli host in locale e nel cloud deve essere bidirezionale.
  • Nessuna uscita diretta verso Internet pubblico, ad eccezione del 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
    • Servizio nome di dominio (DNS)
    • Gateway
  • Sottoscrizione dell'hub
    • subnet gateway applicazione
    • subnet Firewall di Azure
    • Subnet dei servizi condivisi
  • Sottoscrizione connessa
    • Azure Bastion Subnet
    • Rete virtuale peer

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

  • applicazione Azure Firewall: una funzionalità di gateway applicazione di Azure che fornisce una protezione centralizzata delle applicazioni da exploit e vulnerabilità comuni.

  • gateway applicazione di Azure: un servizio di bilanciamento del carico responsabile del traffico dell'applicazione con l'offload TLS (Transport Layer Security) al livello 7.

  • Azure Key Vault: un servizio di gestione delle credenziali supportato da hardware con integrazione stretta con i servizi di identità Microsoft e le risorse di calcolo.

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

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

  • Microsoft Defender per cloud: un sistema di gestione e protezione delle minacce unificato per i carichi di lavoro in locale, più cloud e Azure.

  • App Spring di Azure: un servizio gestito progettato e ottimizzato in modo specifico per le applicazioni Spring Boot basate su Java e . Applicazioni Steeltoe basate su NET.

I diagrammi seguenti rappresentano un hub ben progettato e progettazione spoke che soddisfa i requisiti precedenti. Solo la rete virtuale hub 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 e spoke, le applicazioni possono instradare il traffico esterno o alla rete locale usando Express Route o Rete privata virtuale da sito a sito.

Considerazioni su Azure Well-Architected Framework

Azure Well-Architected Framework è un set di set di linee 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 distribuita, l'infrastruttura sprawl è una realtà. Questa realtà comporta costi imprevisti e non controllabili. Azure Spring Apps viene creato usando componenti che consentono di ridimensionare in modo che possa soddisfare la domanda e ottimizzare i costi. Il core di questa architettura è l'servizio Azure Kubernetes (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 del 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 risolve 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, consentendo di evitare 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 Monitora facilmente le applicazioni e le dipendenze in Azure Spring Apps.
  • È possibile usare Microsoft Defender per 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 staging in Azure Spring Apps.

Affidabilità

Azure Spring Apps è basato sul servizio Azure Kubernetes. Sebbene il servizio Azure Kubernetes fornisca un livello di resilienza tramite clustering, questa architettura di riferimento si estende ulteriormente incorporando servizi e considerazioni sull'architettura per aumentare la disponibilità dell'applicazione se si verifica un errore del 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 Azure DNS privato 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 garantire la disponibilità.

Sicurezza

La sicurezza di questa architettura viene affrontata dall'adesione ai controlli e ai benchmark definiti dal settore. In questo contesto, "controllo" significa una procedura consigliata concisa e ben definita, ad esempio "Usare il principio dei privilegi minimi durante l'implementazione dell'accesso al sistema informativo. IAM-05" I controlli in questa architettura provengono dalla matrice di controllo cloud (CCM) di Cloud Security Alliance (CSA) e dal Centro per la sicurezza Internet (CIS) di Microsoft Azure Foundations Benchmark (MAFB). Nei controlli applicati, lo stato attivo è incentrato sui principi principali di progettazione della sicurezza di governance, rete e sicurezza delle applicazioni. È responsabilità dell'utente gestire i principi di progettazione di Identity, Access Management e Storage in relazione all'infrastruttura di destinazione.

Governance

L'aspetto principale della governance a cui si rivolge questa architettura è la separazione attraverso l'isolamento delle risorse di rete. Nel CCM DCS-08 consiglia il controllo in ingresso e uscita per il data center. Per soddisfare il controllo, l'architettura usa una progettazione hub e spoke usando gruppi di sicurezza di rete (NSG) per filtrare il traffico est-ovest tra le risorse. L'architettura filtra anche il traffico tra i servizi centrali nell'hub e le risorse nell'spoke. L'architettura usa un'istanza di Firewall di Azure per gestire il traffico tra Internet e le risorse all'interno dell'architettura.

Nell'elenco seguente viene illustrato il controllo che indirizza la sicurezza del data center in questo riferimento:

ID controllo CSA CCM Dominio di controllo CCM CSA
DCS-08 Immissione di persone non autorizzate per la sicurezza del data center

Rete

La progettazione di rete che supporta questa architettura deriva dal modello hub e 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 la Firewall di Azure per il traffico nord-sud (all'esterno del "data center"). Il controllo CCM IPY-04 consiglia di usare protocolli di rete sicuri per lo scambio di dati tra i servizi. I servizi di Azure che supportano questa architettura usano tutti i 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:

ID controllo CSA CCM Dominio di controllo CCM CSA
IPY-04 Protocolli di rete
IVS-06 Sicurezza di rete

L'implementazione di rete è ulteriormente protetta definendo i controlli da MAFB. I controlli garantiscono che il traffico nell'ambiente sia limitato da Internet pubblico.

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

ID controllo CIS Descrizione del controllo CIS
6,2 Assicurarsi che l'accesso SSH sia limitato da Internet.
6.3 Assicurarsi che nessun database SQL consenta l'ingresso 0.0.0.0/0 (ANY IP).
6.5 Assicurarsi che Network Watcher sia "Abilitato".
6.6 Assicurarsi che l'ingresso con UDP sia limitato da Internet.

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

Sicurezza delle applicazioni

Questo principio di progettazione illustra i componenti fondamentali dell'identità, della protezione dei dati, della gestione delle chiavi e della configurazione dell'applicazione. Per progettazione, 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 livelli.

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

ID controllo CSA CCM Dominio di controllo CCM CSA
EKM-01 Diritto di crittografia e gestione delle chiavi
EKM-02 Generazione di chiavi di crittografia e gestione delle chiavi
EKM-03 Protezione dei dati sensibili alla crittografia e alla gestione delle chiavi
EKM-04 Archiviazione e accesso alla crittografia e alla gestione delle chiavi

Da CCM, EKM-02 e EKM-03 consiglia criteri e procedure per gestire le chiavi e usare 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.

Nell'elenco seguente vengono illustrati i controlli CIS che indirizzano la gestione delle chiavi in questo riferimento:

ID controllo CIS Descrizione del controllo CIS
8.1 Assicurarsi che la data di scadenza sia impostata su tutte le chiavi.
8.2 Assicurarsi che la data di scadenza sia impostata su tutti i segreti.
8.4 Assicurarsi che l'insieme di credenziali delle chiavi sia recuperabile.

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'insieme di credenziali 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

Esplorare questa architettura di riferimento tramite le distribuzioni dell'interfaccia della riga di comando di Azure arm, Terraform e Azure disponibili nel repository architettura di riferimento di Azure Spring Apps .