Architettura di base cruciale con controlli di rete

Questa architettura fornisce indicazioni per la progettazione di un carico di lavoro cruciale con controlli di rete rigorosi per impedire l'accesso pubblico non autorizzato da Internet a qualsiasi risorsa del carico di lavoro. Lo scopo è arrestare i vettori di attacco a livello di rete in modo che l'affidabilità complessiva del sistema non sia influenzata. Ad esempio, un attacco Distributed Denial of Service (DDoS), se lasciato deselezionato, può causare la mancata disponibilità di una risorsa con traffico non autorizzato.

Si basa sull'architettura di base cruciale, che si concentra sulla massimizzazione dell'affidabilità e dell'efficacia operativa senza controlli di rete. Questa architettura aggiunge funzionalità per limitare i percorsi in ingresso e in uscita usando le funzionalità native del cloud appropriate, ad esempio rete virtuale di Azure e endpoint privati, collegamento privato di Azure, zona DNS privato di Azure e altri.

È consigliabile acquisire familiarità con la baseline prima di procedere con questo articolo.

Strategie di progettazione chiave

Le strategie di progettazione per le baseline cruciali si applicano ancora in questo caso d'uso. Ecco le considerazioni aggiuntive sulla rete per questa architettura:

• Controllare il traffico in ingresso

  Le comunicazioni in ingresso o in ingresso nella rete virtuale devono essere limitate per evitare attacchi dannosi.

  Applicare funzionalità web application firewall (WAF) a livello globale per arrestare gli attacchi al perimetro della rete più vicino all'origine di attacco.

  Eliminare la connettività pubblica ai servizi di Azure. Un approccio consiste nell'usare endpoint privati.

  Controllare il traffico prima che entri nella rete. I gruppi di sicurezza di rete (NSG) nelle subnet consentono di filtrare il traffico consentendo o negando il flusso agli indirizzi IP e alle porte configurati. Questo livello di controllo consente anche la registrazione granulare.

• Controllare il traffico in uscita

  Il traffico in uscita da una rete virtuale a entità esterne a tale rete deve essere limitato. La mancanza di controlli potrebbe causare attacchi di esfiltrazione di dati da servizi dannosi di terze parti.

  Limitare il traffico in uscita a Internet usando Firewall di Azure. Il firewall può filtrare il traffico in modo granulare usando il nome di dominio completo (FQDN).

• Bilanciare i compromessi con la sicurezza

  Esistono compromessi significativi quando le funzionalità di sicurezza vengono aggiunte a un'architettura del carico di lavoro. Si potrebbe notare un certo impatto sulle prestazioni, sull'agilità operativa e persino sull'affidabilità. Tuttavia , gli attacchi, ad esempio Denial-Of-Service (DDoS), l'intrusione dei dati e altri, possono indirizzare l'affidabilità complessiva del sistema e alla fine causare l'indisponibilità.

Le strategie sono basate sulle linee guida generali fornite per i carichi di lavoro cruciali in carichi di lavoro cruciali ben strutturati. È consigliabile esplorare l'area di progettazione della rete e della connettività per consigli e procedure consigliate durante la definizione di un'architettura mission critical.

Architettura

Scaricare un file di Visio di questa architettura.

I componenti di questa architettura possono essere suddivisi in categorie in questo modo. Per la documentazione del prodotto sui servizi di Azure, vedere Risorse correlate.

Risorse globali

Le risorse globali vivono a lungo e condividono la durata del sistema. Hanno la possibilità di essere disponibili a livello globale nel contesto di un modello di distribuzione in più aree. Per altre informazioni, vedere Risorse globali.

Lo SKU Premium di Frontdoor di Azure viene usato come servizio di bilanciamento del carico globale per instradare in modo affidabile il traffico alle distribuzioni a livello di area, esposte tramite endpoint privati.

Fare riferimento a Carichi di lavoro cruciali ben strutturati: Routing globale del traffico.

Azure Cosmos DB per NoSQL viene ancora usato per archiviare lo stato all'esterno del cluster di calcolo e dispone di impostazioni di configurazione di base per l'affidabilità. L'accesso è limitato alle connessioni endpoint private autorizzate.

Fare riferimento a Carichi di lavoro cruciali ben progettato: archivio dati multi-scrittura distribuito a livello globale.

Registro Azure Container viene usato per archiviare tutte le immagini del contenitore con funzionalità di replica geografica. L'accesso è limitato alle connessioni endpoint private autorizzate.

Fare riferimento a Carichi di lavoro cruciali ben architettati: Registro Contenitori.

Risorse a livello di area

Il provisioning delle risorse a livello di area viene effettuato come parte di un stamp di distribuzione in una singola area di Azure. Sono di breve durata per offrire maggiore resilienza, scalabilità e prossimità agli utenti. Queste risorse non condividono nulla con le risorse in un'altra area. Possono essere rimossi o replicati in modo indipendente in altre aree. Tuttavia, condividono le risorse globali tra loro. Per altre informazioni, vedere Risorse stamp a livello di area.

Il sito Web statico in un account di archiviazione di Azure ospita un'applicazione a pagina singola che invia richieste ai servizi back-end. Questo componente ha la stessa configurazione del front-end di base. L'accesso è limitato alle connessioni endpoint private autorizzate.

Le reti virtuali di Azure offrono ambienti sicuri per l'esecuzione del carico di lavoro e delle operazioni di gestione.

Il servizio di bilanciamento del carico interno è l'origine dell'applicazione. Frontdoor usa questa origine per stabilire la connettività privata e diretta al back-end tramite collegamento privato.

Il servizio Azure Kubernetes è l'agente di orchestrazione per il calcolo back-end che esegue un'applicazione ed è senza stato. Il cluster del servizio Azure Kubernetes viene distribuito come cluster privato. Il server API Kubernetes non viene quindi esposto alla rete Internet pubblica. L'accesso al server API è limitato a una rete privata. Per altre informazioni, vedere l'articolo Cluster di calcolo di questa architettura.

Vedere Carichi di lavoro cruciali ben progettato: Orchestrazione dei contenitori e Kubernetes.

Firewall di Azure controlla e protegge tutto il traffico in uscita dalle risorse della rete virtuale di Azure.

Hub eventi di Azure viene usato come broker di messaggi. L'accesso è limitato alle connessioni endpoint private autorizzate.

Fare riferimento a Carichi di lavoro cruciali ben progettato: architettura basata su eventi ad accoppiamento debole.

Azure Key Vault viene usato come archivio segreto a livello di area. L'accesso è limitato alle connessioni endpoint private autorizzate.

Fare riferimento a Carichi di lavoro cruciali ben progettato: Protezione dell'integrità dei dati.

Risorse della pipeline di distribuzione

Le pipeline di compilazione e rilascio per un'applicazione mission critical devono essere completamente automatizzate per garantire un modo coerente di distribuire un timbro convalidato.

GitHub viene ancora usato per il controllo del codice sorgente come piattaforma basata su Git a disponibilità elevata.

Azure Pipelines viene scelto per automatizzare le pipeline necessarie per la compilazione, il test e la distribuzione di un carico di lavoro in ambienti di preproduzione e produzione.

Fare riferimento a Carichi di lavoro cruciali ben progettato: processi DevOps.

I pool di agenti di compilazione di Azure DevOps self-hosted vengono usati per avere un maggiore controllo sulle compilazioni e le distribuzioni. Questo livello di autonomia è necessario perché il cluster di calcolo e tutte le risorse PaaS sono private, che richiede un'integrazione a livello di rete non possibile negli agenti di compilazione ospitati da Microsoft.

Risorse di osservabilità

I dati di monitoraggio per le risorse globali e le risorse a livello di area vengono archiviati in modo indipendente. Un singolo archivio di osservabilità centralizzato non è consigliato per evitare un singolo punto di guasto. Per altre informazioni, vedere Risorse di osservabilità.

• Azure Log Analytics viene usato come sink unificato per archiviare log e metriche per tutti i componenti dell'applicazione e dell'infrastruttura.

• Azure Application Insights viene usato come strumento APM (Application Performance Management) per raccogliere tutti i dati di monitoraggio delle applicazioni e archiviarlo direttamente all'interno di Log Analytics.

Fare riferimento a Carichi di lavoro cruciali ben progettato: azione predittiva e operazioni di intelligenza artificiale.

Risorse di gestione

Una modifica significativa della progettazione rispetto all'architettura di base è il cluster di calcolo. In questa progettazione il cluster del servizio Azure Kubernetes è privato. Questa modifica richiede il provisioning di risorse aggiuntive per ottenere l'accesso.

Set di scalabilità di macchine virtuali di Azure per gli agenti di compilazione privati e le istanze jump box per eseguire strumenti nel cluster, ad esempio kubectl.

Azure Bastion consente di accedere in modo sicuro alle macchine virtuali jump box e di rimuovere la necessità di avere indirizzi IP pubblici.

Endpoint privati per i servizi PaaS

Per elaborare le operazioni aziendali o di distribuzione, l'applicazione e gli agenti di compilazione devono raggiungere diversi servizi PaaS di Azure di cui viene effettuato il provisioning a livello globale, all'interno dell'area e anche all'interno dello stamp. Nell'architettura di base, tale comunicazione si trova sugli endpoint pubblici dei servizi.

In questa progettazione questi servizi sono stati protetti con endpoint privati per rimuoverli dall'accesso a Internet pubblico. Questo approccio riduce la superficie di attacco complessiva per attenuare la manomissione diretta del servizio da origini impreviste. Tuttavia, introduce un altro potenziale punto di errore e aumenta la complessità. Considerare attentamente i compromessi con la sicurezza prima di adottare questo approccio.

Gli endpoint privati devono essere inseriti in una subnet dedicata della rete virtuale dello stamp. Gli indirizzi IP privati agli endpoint privati vengono assegnati da tale subnet. Essenzialmente, qualsiasi risorsa nella rete virtuale può comunicare con il servizio raggiungendo l'indirizzo IP privato. Assicurarsi che lo spazio indirizzi sia sufficientemente grande per contenere tutti gli endpoint privati necessari per tale stamp.

Per connettersi tramite un endpoint privato, è necessario un record DNS. È consigliabile che i record DNS associati ai servizi vengano mantenuti nelle zone DNS private di Azure gestite da DNS di Azure. Assicurarsi che il nome di dominio completo (FQDN) venga risolto nell'indirizzo IP privato.

In questa architettura sono stati configurati endpoint privati per Registro Azure Container, Azure Cosmos DB, Key Vault, risorse di archiviazione e Hub eventi. Il cluster del servizio Azure Kubernetes viene distribuito anche come cluster privato, che crea un endpoint privato per il servizio API Kubernetes nella rete del cluster.

In questa progettazione sono presenti due reti virtuali di cui è stato effettuato il provisioning e entrambe hanno subnet dedicate per contenere endpoint privati per tutti questi servizi. Il layout di rete è descritto in Layout di rete virtuale.

Quando si aggiungono altri componenti all'architettura, è consigliabile aggiungere altri endpoint privati. Ad esempio, è possibile aggiungere restrizioni alle risorse di osservabilità. Sia Azure Log Analytics che Azure Application Insights supportano l'uso di endpoint privati. Per informazioni dettagliate, vedere Usare il collegamento privato di Azure per connettere le reti a Monitoraggio di Azure.

Possono essere create nella stessa subnet o in subnet diverse all'interno della stessa rete virtuale. Sono previsti limiti per il numero di endpoint privati che è possibile creare in una sottoscrizione. Per altre informazioni, consultare limiti di Azure.

Controllare ulteriormente l'accesso ai servizi usando i gruppi di sicurezza di rete nella subnet.

Ingresso privato

Lo SKU Premium di Frontdoor di Azure viene usato come punto di ingresso globale per tutto il traffico client in ingresso. Usa funzionalità web application firewall (WAF) per consentire o negare il traffico nella rete perimetrale. Le regole WAF configurate impediscono attacchi anche prima di entrare nelle reti virtuali stamp.

Questa architettura sfrutta anche la funzionalità di Frontdoor per usare il collegamento privato di Azure per accedere all'origine dell'applicazione senza l'uso di indirizzi IP/endpoint pubblici nei back-end. Ciò richiede un servizio di bilanciamento del carico interno nella rete virtuale stamp. Questa risorsa si trova davanti al controller di ingresso Kubernetes in esecuzione nel cluster. Oltre a questo servizio di bilanciamento del carico privato, un servizio collegamento privato viene creato dal servizio Azure Kubernetes, che viene usato per la connessione privata da Frontdoor.

Dopo aver stabilito la connessione, gli endpoint privati nella rete Frontdoor hanno connettività diretta con il servizio di bilanciamento del carico e il sito Web statico nella rete stamp tramite collegamento privato.

Per altre informazioni, vedere Funzionamento del collegamento privato.

Fare riferimento a Carichi di lavoro cruciali ben progettato: Servizi di distribuzione di applicazioni.

Uscita con restrizioni

Le applicazioni potrebbero richiedere una connettività Internet in uscita. Il controllo del traffico consente di limitare, monitorare e limitare il traffico in uscita. In caso contrario, l'accesso interno imprevisto potrebbe causare compromissioni e potenzialmente uno stato del sistema inaffidabile. L'uscita con restrizioni può anche risolvere altri problemi di sicurezza, ad esempio l'esfiltrazione di dati.

L'uso del firewall e dei gruppi di sicurezza di rete può assicurarsi che il traffico in uscita dall'applicazione venga controllato e registrato.

In questa architettura Firewall di Azure è il singolo punto in uscita e viene usato per controllare tutto il traffico in uscita che ha origine dalla rete virtuale. Le route definite dall'utente vengono usate nelle subnet in grado di generare traffico in uscita, ad esempio la subnet dell'applicazione.

Per informazioni sulla limitazione del traffico in uscita, vedere Controllare il traffico in uscita per i nodi del cluster nel servizio Azure Kubernetes.

Layout di rete virtuale

Isolare le risorse regionali e le risorse di gestione in reti virtuali separate. Hanno caratteristiche, finalità e considerazioni sulla sicurezza distinte.

• Tipo di traffico: le risorse regionali, che partecipano all'elaborazione delle operazioni aziendali, richiedono controlli di sicurezza più elevati. Ad esempio, il cluster di calcolo deve essere protetto dal traffico Internet diretto. Viene effettuato il provisioning delle risorse di gestione solo per accedere alle risorse a livello di area per le operazioni.

• Durata: anche le durate previste di tali risorse sono diverse. Si prevede che le risorse regionali siano di breve durata (temporanee). Vengono creati come parte del timbro di distribuzione e distrutti quando il timbro viene strappato. Le risorse di gestione condividono la durata dell'area ed escono dalle risorse del timbro.

In questa architettura sono disponibili due reti virtuali: rete di stamp e rete operativa. Creare un ulteriore isolamento all'interno di ogni rete virtuale usando subnet e gruppi di sicurezza di rete (NSG) per proteggere la comunicazione tra le subnet.

Fare riferimento a Carichi di lavoro cruciali ben architettati: reti virtuali isolate.

Rete virtuale stamp a livello di area

Il timbro di distribuzione effettua il provisioning di una rete virtuale in ogni area.

La rete virtuale è divisa in queste subnet principali. A tutte le subnet sono assegnati gruppi di sicurezza di rete (NSG) per bloccare qualsiasi accesso non autorizzato dalla rete virtuale. I gruppi di sicurezza di rete limitano il traffico tra la subnet dell'applicazione e altri componenti nella rete.

• Subnet dell'applicazione

  I pool di nodi del cluster del servizio Azure Kubernetes sono isolati in una subnet. Se è necessario isolare ulteriormente il pool di nodi di sistema dal pool di nodi di lavoro, è possibile inserirli in subnet separate.

• Subnet di ingresso stamp

  Il punto di ingresso a ogni stamp è un'istanza interna di Azure Load Balancer Standard che viene inserita in una subnet dedicata. Anche il servizio Collegamento privato usato per la connessione privata da Frontdoor viene inserito qui.

  Entrambe le risorse vengono sottoposte a provisioning come parte della distribuzione di stamp.

• Subnet di uscita stamp

  Firewall di Azure viene inserito in una subnet separata e controlla il traffico in uscita dalla subnet dell'applicazione usando una route definita dall'utente.

• Subnet endpoint privati

  La subnet dell'applicazione dovrà accedere ai servizi PaaS nel timbro a livello di area, nell'insieme di credenziali delle chiavi e in altri. È inoltre necessario accedere alle risorse globali, ad esempio il registro contenitori. In questa architettura , tutti i servizi PaaS sono bloccati e possono essere raggiunti solo tramite endpoint privati. Viene quindi creata un'altra subnet per tali endpoint. L'accesso in ingresso a questa subnet è protetto dal gruppo di sicurezza di rete che consente solo il traffico proveniente dall'applicazione.

  È possibile aggiungere altre restrizioni usando il supporto UDR per gli endpoint privati, in modo che questo traffico possa anche essere in uscita attraverso la subnet di uscita stamp.

Rete virtuale operativa

Il traffico operativo è isolato in una rete virtuale separata. Poiché il servizio API del cluster del servizio Azure Kubernetes è privato in questa architettura, tutto il traffico operativo e di distribuzione deve provenire anche da risorse private, ad esempio agenti di compilazione self-hosted e jump box. Queste risorse vengono distribuite in una rete virtuale separata con connettività diretta alle risorse dell'applicazione tramite il proprio set di endpoint privati. Gli agenti di compilazione e i jumpbox si trovano in subnet separate.

Anziché usare endpoint privati, un approccio alternativo consiste nell'usare il peering di rete virtuale. Tuttavia, il peering aggiunge complessità che possono essere difficili da gestire soprattutto quando le reti virtuali sono progettate per essere temporanee.

Sia gli agenti di compilazione (che facoltativamente i jump box) devono accedere ai servizi PaaS che si trovano a livello globale e all'interno del timbro regionale. Analogamente alla rete virtuale di stamp a livello di area, viene creata una subnet dedicata per gli endpoint privati ai servizi PaaS necessari. Il gruppo di sicurezza di rete in questa subnet garantisce che il traffico in ingresso sia consentito solo dalle subnet di gestione e distribuzione.

Operazioni di gestione

Un caso d'uso tipico è quando un operatore deve accedere al cluster di calcolo per eseguire strumenti e comandi di gestione. Non è possibile accedere direttamente al servizio API in un cluster privato. Ecco perché viene effettuato il provisioning dei jumpbox in cui l'operatore può eseguire gli strumenti. È presente una subnet separata per i jumpbox.

Tuttavia, queste jump box devono essere protette e dall'accesso non autorizzato. È consigliabile evitare l'accesso diretto ai jump box aprendo porte RDP/SSH. Azure Bastion è consigliato a questo scopo e richiede una subnet dedicata in questa rete virtuale.

È possibile limitare ulteriormente l'accesso alla subnet jump box usando un gruppo di sicurezza di rete che consente solo il traffico in ingresso dalla subnet Bastion tramite SSH.

Operazioni di distribuzione

Per creare pipeline di distribuzione, è necessario effettuare il provisioning di risorse di calcolo aggiuntive per eseguire gli agenti di compilazione. Queste risorse non influiscono direttamente sulla disponibilità in fase di esecuzione del carico di lavoro, ma un errore di affidabilità può compromettere la possibilità di distribuire o gestire l'ambiente mission critical. Pertanto, le funzionalità di affidabilità devono essere estese a queste risorse.

Questa architettura usa set di scalabilità di macchine virtuali sia per gli agenti di compilazione che per i jump box , anziché per singole macchine virtuali. Inoltre, la segmentazione di rete viene fornita tramite l'uso di subnet. L'ingresso è limitato ad Azure DevOps.

Considerazioni sui costi

Si verifica un impatto significativo sui costi per i carichi di lavoro cruciali. In questa architettura, le scelte tecnologico, ad esempio l'uso dello SKU Premium di Frontdoor di Azure e il provisioning di Firewall di Azure in ogni stamp, comportano un aumento dei costi. Sono stati inoltre aggiunti costi correlati alla manutenzione e alle risorse operative. Tali compromessi devono essere presi in considerazione attentamente prima di adottare una versione controllata dalla rete dell'architettura di base.

Distribuire questa architettura

Gli aspetti di rete di questa architettura vengono implementati nell'implementazione mission-critical connected.

Passaggi successivi

Per informazioni dettagliate sulle decisioni di progettazione prese in questa architettura, vedere l'area di progettazione della rete e della connettività per carichi di lavoro cruciali in Azure Well-architected Framework.

" output is necessary.)

Per la documentazione del prodotto sui servizi di Azure usati in questa architettura, vedere questi articoli.

• Frontdoor di Azure
• Azure Cosmos DB
• Registro dei contenitori di Azure
• Log Analytics di Azure
• Azure Key Vault
• Bus di servizio di Azure
• Servizio Azure Kubernetes
• Azure Application Insights
• Hub eventi di Azure
• Archiviazione BLOB di Azure
• Firewall di Azure