Questa architettura fornisce indicazioni per la progettazione di un carico di lavoro critico che dispone di controlli di rete rigorosi per impedire l'accesso pubblico non autorizzato da Internet a una qualsiasi delle risorse del carico di lavoro. La finalità è 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 l'indisponibilità di una risorsa con il traffico non legittimo.
Si basa sull'architettura di base fondamentale, incentrata sull'ottimizzare l'affidabilità e l'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 Azure Rete virtuale(VNet) 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 bordo 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 di entrare nella rete. I gruppi di sicurezza di rete 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 alle entità esterne alla rete deve essere limitato. La mancanza di controlli potrebbe causare attacchi di esfiltrazione dei 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. È possibile notare un 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 essere destinati all'affidabilità complessiva del sistema e alla fine causano l'indisponibilità.
Le strategie sono basate sulle linee guida complessive fornite per carichi di lavoro cruciali nei carichi di lavoro cruciali ben architettati. È consigliabile esplorare l'area di progettazione delle reti e della connettività per raccomandazioni e procedure consigliate durante la definizione dell'architettura critica.
Architettura
Scaricare un file di Visio di questa architettura.
I componenti di questa architettura possono essere categorizzati in modo generale. 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 capacità di essere disponibili a livello globale nel contesto di un modello di distribuzione a più aree. Per altre informazioni, vedere Risorse globali.
Lo SKU Premium di Azure Frontdoor viene usato come servizio di bilanciamento del carico globale per il routing affidabile del traffico alle distribuzioni internazionali, esposte tramite endpoint privati.
Fare riferimento ai carichi di lavoro cruciali ben architettati: routing del traffico globale.
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 ai carichi di lavoro cruciali ben architettati: archivio dati distribuito a più scritture 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 di mission-architected: Registro contenitori.
Risorse regionali
Le risorse regionali vengono sottoposte a provisioning come parte di un timbro 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. Condividono tuttavia le risorse globali tra loro. Per altre informazioni, vedere Risorse del timbro a livello di area.
Il sito Web statico in un account di archiviazione di Azure ospita un'applicazione a pagina singola (SPA) 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 usando collegamento privato.
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. Quindi, il server API Kubernetes non è esposto a Internet pubblico. L'accesso al server API è limitato a una rete privata. Per altre informazioni, vedere l'articolo Del cluster di calcolo di questa architettura.
Fare riferimento ai carichi di lavoro cruciali di progettazione: Orchestrazione contenitori e Kubernetes.
Firewall di Azure controlla e protegge tutto il traffico in uscita dalle risorse di Azure Rete virtuale.
Hub eventi di Azure viene usato come broker messaggi. L'accesso è limitato alle connessioni endpoint private autorizzate.
Fare riferimento a Carichi di lavoro cruciali di missione ben architettati: architettura basata su eventi in modo flessibile.
Azure Key Vault viene usato come archivio segreto a livello di area. L'accesso è limitato alle connessioni endpoint private autorizzate.
Fare riferimento ai carichi di lavoro cruciali ben architettati: protezione dell'integrità dei dati.
Risorse della pipeline di distribuzione
Le pipeline di compilazione e rilascio per un'applicazione critica 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 è 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 ai carichi di lavoro cruciali ben architettati: processi DevOps.
I pool di agenti di compilazione Azure DevOps self-hosted vengono usati per avere più controllo sulle compilazioni e le distribuzioni. Questo livello di autonomia è necessario perché il cluster di calcolo e tutte le risorse PaaS sono private, che richiedono 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 regionali vengono archiviati in modo indipendente. Un singolo archivio di osservabilità centralizzato non è consigliato per evitare un singolo punto di errore. Per altre informazioni, vedere Risorse di osservabilità.
Azure Log Analytics viene usato come sink unificato per archiviare i log e le metriche per tutti i componenti dell'applicazione e dell'infrastruttura.
applicazione Azure Insights viene usato come strumento di Gestione prestazioni applicazioni (APM) per raccogliere tutti i dati di monitoraggio delle applicazioni e archiviarlo direttamente all'interno di Log Analytics.
Fare riferimento ai carichi di lavoro cruciali ben architettati: azioni predittive e operazioni di intelligenza artificiale.
Risorse gestionali
Una modifica significativa della progettazione dall'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.
Azure set di scalabilità di macchine virtuali per gli agenti di compilazione privati e le istanze jump box per eseguire strumenti nel cluster, ad esempio kubectl.
Azure Bastion offre l'accesso sicuro alle macchine virtuali jump box e rimuove la necessità che le macchine virtuali abbiano indirizzi IP pubblici.
Endpoint privati per i servizi PaaS
Per elaborare operazioni aziendali o di distribuzione, l'applicazione e gli agenti di compilazione devono raggiungere diversi servizi PaaS di Azure di cui è stato effettuato il provisioning a livello globale, all'interno dell'area e anche all'interno del timbro. Nell'architettura di base, tale comunicazione si trova sugli endpoint pubblici dei servizi.
In questa progettazione, tali servizi sono stati protetti con endpoint privati per rimuoverli dall'accesso a Internet pubblico. Questo approccio riduce l'area complessiva della superficie di attacco per mitigare 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 del timbro. Gli indirizzi IP privati agli endpoint privati vengono assegnati da tale subnet. In sostanza, qualsiasi risorsa nella rete virtuale può comunicare con il servizio raggiungendo l'indirizzo IP privato. Assicurarsi che lo spazio indirizzi sia abbastanza grande per ospitare tutti gli endpoint privati necessari per tale timbro.
Per connettersi tramite un endpoint privato, è necessario un record DNS. È consigliabile che i record DNS associati ai servizi vengano mantenuti in Azure DNS privato zone 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. Inoltre, il cluster del servizio Azure Kubernetes viene distribuito come cluster privato, che crea un endpoint privato per il servizio API Kubernetes nella rete del cluster.
In questa progettazione sono disponibili due reti virtuali e entrambe hanno subnet dedicate per contenere endpoint privati per tutti questi servizi. Il layout di rete è descritto nel 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 applicazione Azure Insights supportano l'uso di endpoint privati. Per informazioni dettagliate, vedere Usare collegamento privato di Azure per connettere le reti a Monitoraggio di Azure.
Possono essere creati nelle stesse subnet o 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 al bordo della rete. Le regole WAF configurate impediscono attacchi anche prima di immettere le reti virtuali di stamp.
Questa architettura sfrutta anche la funzionalità di Frontdoor per usare 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 questa Load Balancer privata, viene creato un servizio collegamento privato dal servizio Azure Kubernetes, 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 su collegamento privato.
Per altre informazioni, vedere Come funziona collegamento privato.
Fare riferimento a Carichi di lavoro cruciali per la missione ben architettati: servizi di recapito delle applicazioni.
Uscita limitata
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 compromessi e potenzialmente uno stato di sistema non affidabile. L'uscita limitata può anche risolvere altri problemi di sicurezza, ad esempio l'esfiltrazione dei dati.
L'uso di firewall e 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 di uscita e viene usato per controllare tutto il traffico in uscita che proviene 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 in servizio Azure Kubernetes (servizio Azure Kubernetes).
Layout di rete virtuale
Isolare le risorse regionali e le risorse di gestione in reti virtuali separate. Hanno caratteristiche distinte, scopi e considerazioni sulla sicurezza.
Tipo di traffico: 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. Le risorse di gestione vengono sottoposte a provisioning solo per accedere alle risorse regionali per le operazioni.
Durata: anche le durata prevista di tali risorse sono diverse. Le risorse regionali dovrebbero essere di breve durata (effimero). Vengono creati come parte del timbro di distribuzione e distrutti quando il timbro viene rimosso. Le risorse di gestione condividono la durata dell'area e vivono le risorse del timbro.
In questa architettura sono presenti due reti virtuali: rete di stampa e rete operativa. Creare un ulteriore isolamento all'interno di ogni rete virtuale usando subnet e gruppi di sicurezza di rete per proteggere la comunicazione tra le subnet.
Fare riferimento ai carichi di lavoro critici della missione ben architettati: reti virtuali isolate.
Rete virtuale di stamp a livello di area
Il timbro di distribuzione esegue il provisioning di una rete virtuale in ogni area.
La rete virtuale è divisa in queste subnet principali. Tutte le subnet dispongono di gruppi di sicurezza di rete (NSG) assegnati 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 della 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 di stamp
Il punto di ingresso a ogni stampo è un Load Balancer Standard interno di Azure posizionato in una subnet dedicata. Il servizio collegamento privato usato per la connessione privata da Frontdoor viene inserito anche qui.
Entrambe le risorse vengono sottoposte a provisioning come parte della distribuzione di stamp.
Subnet di uscita di 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 (UDR).
Subnet degli endpoint privati
La subnet dell'applicazione dovrà accedere ai servizi PaaS nel timbro regionale, Key Vault e altri. È inoltre necessario accedere alle risorse globali, ad esempio il Registro contenitori. In questa architettura, tutti i servizi PaaS vengono 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 dall'applicazione.
È possibile aggiungere ulteriori restrizioni usando il supporto UDR per gli endpoint privati, in modo che questo traffico possa essere in uscita anche attraverso la subnet di uscita dello stamp.
Rete virtuale delle operazioni
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 anche derivare da risorse private, ad esempio agenti di compilazione self-hosted e caselle di salto. 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 le caselle jump sono in subnet separate.
Anziché usare endpoint privati, un approccio alternativo consiste nell'usare il peering di rete virtuale. Tuttavia, il peering aggiunge complessità che può essere difficile da gestire soprattutto quando le reti virtuali sono progettate per essere temporaneo.
Entrambi gli agenti di compilazione (e facoltativamente 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 regionale, viene creata una subnet dedicata per gli endpoint privati ai servizi PaaS necessari. Il gruppo di sicurezza di rete in questa subnet assicura 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é le caselle di salto vengono sottoposte a provisioning in cui l'operatore può eseguire gli strumenti. C'è una subnet separata per i jump box.
Tuttavia, queste caselle jump devono essere protette anche dall'accesso non autorizzato. È consigliabile evitare l'accesso diretto alle caselle di salto aprendo porte RDP/SSH. Azure Bastion è consigliato per questo scopo e richiede una subnet dedicata in questa rete virtuale.
Attenzione
La connettività tramite Azure Bastion e i jump box possono avere un impatto sulla produttività degli sviluppatori, ad esempio l'esecuzione di strumenti di debug richiede un processo aggiuntivo. Tenere presente questi effetti prima di decidere di proteggere la sicurezza avanzata per il carico di lavoro critico.
È 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 compilare le pipeline di distribuzione, è necessario effettuare il provisioning di calcoli aggiuntivi per eseguire gli agenti di compilazione. Queste risorse non influiscono direttamente sulla disponibilità del runtime del carico di lavoro, ma un errore di affidabilità può compromettere la possibilità di distribuire o servizio l'ambiente critico. 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 sul costo
C'è un impatto significativo sui costi per carichi di lavoro cruciali. In questa architettura, le scelte tecnologico come l'uso dello SKU Premium di Frontdoor di Azure e il provisioning Firewall di Azure in ogni stamp comportano un aumento dei costi. Sono inoltre stati aggiunti costi correlati alla manutenzione e alle risorse operative. Tali compromessi devono essere considerati 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 della connessione critica.
Nota
L'implementazione connessa è destinata a illustrare un carico di lavoro fondamentale che si basa sulle risorse dell'organizzazione, si integra con altri carichi di lavoro e usa servizi condivisi. Si basa su questa architettura e usa i controlli di rete descritti in questo articolo. Tuttavia, lo scenario connesso presuppone che la rete privata virtuale o Azure DNS privato Zona esista già all'interno della sottoscrizione di connettività delle zone di destinazione di Azure.
Passaggi successivi
Per informazioni dettagliate sulle decisioni di progettazione prese in questa architettura, esaminare l'area di progettazione di rete e connettività per carichi di lavoro cruciali in Azure Well-architected Framework.
Risorse correlate
Per la documentazione del prodotto sui servizi di Azure usati in questa architettura, vedere questi articoli.