Implementare una rete ibrida sicura

Firewall di Azure
Azure Load Balancer
Macchine virtuali di Azure
Rete virtuale di Azure

Questa architettura di riferimento consente di visualizzare una rete ibrida sicura che estende una rete locale in Azure. L'architettura implementa una rete perimetrale, detta anche rete perimetrale, tra la rete locale e una rete virtuale di Azure. Tutto il traffico in ingresso e in uscita passa attraverso Firewall di Azure.

Architettura

Diagram that shows the secure hybrid network architecture.

Scaricare un file di Visio di questa architettura.

Componenti

L'architettura è costituita dagli aspetti seguenti:

  • Rete locale. Una rete LAN privata implementata all'interno di un'organizzazione.

  • Rete virtuale di Azure. La rete virtuale ospita i componenti della soluzione e altre risorse in esecuzione in Azure.

    Le route di rete virtuale definiscono il flusso del traffico IP all'interno della rete virtuale di Azure. Nel diagramma sono presenti due tabelle di route definite dall'utente.

    Nella subnet del gateway il traffico viene instradato attraverso l'istanza di Firewall di Azure.

    Nota

    A seconda dei requisiti della connessione VPN, è possibile configurare route BGP (Border Gateway Protocol) per implementare le regole di inoltro che indirizzano il traffico attraverso la rete locale.

  • Gateway. Il gateway fornisce la connettività tra i router nella rete locale e la rete virtuale. Il gateway viene inserito nella propria subnet.

  • Firewall di Azure. Firewall di Azure è un firewall gestito come servizio. L'istanza del firewall viene inserita nella propria subnet.

  • Gruppi di sicurezza di rete. Usare i gruppi di sicurezza per limitare il traffico di rete all'interno della rete virtuale.

  • Azure Bastion. Azure Bastion consente di accedere alle macchine virtuali (VM) nella rete virtuale tramite SSH o RDP (Remote Desktop Protocol) senza esporre le macchine virtuali direttamente a Internet. Usare Bastion per gestire le macchine virtuali nella rete virtuale.

    Bastion richiede una subnet dedicata denominata AzureBastionSubnet.

Potenziali casi d'uso

Questa architettura richiede una connessione al data center locale mediante un gateway VPN o una connessione ExpressRoute. Tra gli usi tipici di questa architettura sono inclusi:

  • Applicazioni ibride in cui i carichi di lavoro vengono eseguiti in parte in locale e in parte in Azure.
  • Infrastruttura che richiede un controllo granulare sul traffico che entra in una rete virtuale di Azure da un data center locale.
  • Applicazioni che devono controllare il traffico in uscita. Il controllo è spesso un requisito normativo di molti sistemi commerciali e può contribuire a impedire la divulgazione pubblica di informazioni private.

Consigli

Le raccomandazioni seguenti sono valide per la maggior parte degli scenari. Seguire queste indicazioni, a meno che non si disponga di un requisito specifico che le escluda.

Consigli per il controllo degli accessi

Usare il controllo degli accessi in base al ruolo di Azure per gestire le risorse nell'applicazione. È consigliabile creare i ruoli personalizzati seguenti:

  • Un ruolo DevOps con le autorizzazioni per amministrare l'infrastruttura per l'applicazione, distribuire i componenti dell'applicazione e monitorare e riavviare le macchine virtuali.

  • Un ruolo di amministratore IT centralizzato per gestire e monitorare le risorse di rete.

  • Ruolo di amministratore IT per la sicurezza per gestire risorse di rete sicure, ad esempio il firewall.

Il ruolo di amministratore IT non deve avere accesso alle risorse del firewall. L'accesso deve essere limitato al ruolo di amministratore IT di sicurezza.

Indicazioni sui gruppi di risorse

Le risorse di Azure, ad esempio macchine virtuali, reti virtuali e servizi di bilanciamento del carico, possono essere facilmente gestite raggruppandole in gruppi di risorse. Assegnare ruoli di Azure a ogni gruppo di risorse per limitare l'accesso.

Si consiglia di creare i gruppi di risorse seguenti:

  • Gruppo di risorse contenente la rete virtuale (escluse le macchine virtuali), i gruppi di sicurezza di rete e le risorse del gateway per la connessione alla rete locale. Assegnare il ruolo di amministratore IT centralizzato al gruppo di risorse.
  • Gruppo di risorse contenente le macchine virtuali per l'istanza di Firewall di Azure e le route definite dall'utente per la subnet del gateway. Assegnare il ruolo di amministratore IT della sicurezza al gruppo di risorse.
  • Separare i gruppi di risorse per ogni rete virtuale spoke che contiene il servizio di bilanciamento del carico e le macchine virtuali.

Raccomandazioni di rete

Per accettare il traffico in ingresso da Internet, aggiungere una regola DNAT (Destination Network Address Translation) a Firewall di Azure.

  • Indirizzo di destinazione = Indirizzo IP pubblico dell'istanza del firewall.
  • Indirizzo convertito = Indirizzo IP privato all'interno della rete virtuale.

Forzare il tunneling di tutto il traffico Internet in uscita attraverso la rete locale usando il tunnel VPN da sito a sito e indirizzare a Internet tramite NAT (Network Address Translation). Questa progettazione impedisce la perdita accidentale di informazioni riservate e consente l'ispezione e il controllo di tutto il traffico in uscita.

Non bloccare completamente il traffico Internet dalle risorse nelle subnet di rete spoke. Il blocco del traffico impedirà a queste risorse di usare i servizi PaaS di Azure che si basano su indirizzi IP pubblici, ad esempio la registrazione diagnostica delle macchine virtuali, il download delle estensioni della macchina virtuale e altre funzionalità. La diagnostica di Azure richiede anche che i componenti siano in grado di leggere e scrivere in un account di archiviazione di Azure.

Verificare la corretta esecuzione del tunneling forzato del traffico Internet in uscita. Se si usa una connessione VPN con il servizio di routing e accesso remoto in un server locale, usare uno strumento come WireShark.

È consigliabile usare gateway applicazione o Frontdoor di Azure per la terminazione SSL.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

Per informazioni dettagliate sui limiti di larghezza di banda di Gateway VPN, vedere SKU del gateway. Per larghezze di banda superiori, è possibile eseguire l'aggiornamento a un gateway ExpressRoute. ExpressRoute offre fino a 10 Gbps con una latenza inferiore rispetto a una connessione VPN.

Per altre informazioni sulla scalabilità dei gateway di Azure, vedere le sezioni considerazioni sulla scalabilità in:

Per informazioni dettagliate sulla gestione di reti virtuali e gruppi di sicurezza di rete su larga scala, vedere Azure Rete virtuale Manager (AVNM): Creare una rete hub e spoke protetta per creare topologie di rete virtuale nuove (ed eseguire l'onboarding di topologie di rete esistenti) per la gestione centrale della connettività e delle regole del gruppo di sicurezza di rete.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

Se si usa Azure ExpressRoute per fornire la connettività tra la rete virtuale e la rete locale, configurare un gateway VPN per fornire il failover se la connessione ExpressRoute non è più disponibile.

Per informazioni sulla gestione della disponibilità per le connessioni VPN ed ExpressRoute, vedere le considerazioni sulla disponibilità in:

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

Se la connettività del gateway dalla rete locale ad Azure è inattiva, è comunque possibile raggiungere le macchine virtuali nella rete virtuale di Azure tramite Azure Bastion.

La subnet di ogni livello nell'architettura di riferimento è protetta dalle regole del gruppo di sicurezza di rete. Potrebbe essere necessario creare una regola per aprire la porta 3389 per l'accesso RDP (Remote Desktop Protocol) sulle macchine virtuali di Windows o la porta 22 per l'accesso SSH (Secure Shell) sulle macchine virtuali Linux. Altri strumenti di gestione e monitoraggio potrebbero richiedere regole per l'apertura di porte aggiuntive.

Se si usa ExpressRoute per consentire la connettività tra il data center locale e Azure, usare l'Azure Connectivity Toolkit (AzureCT) per monitorare e risolvere i problemi di connessione.

Per altre informazioni sul monitoraggio e sulla gestione delle connessioni VPN ed ExpressRoute, vedere l'articolo Implementazione di un'architettura di rete ibrida con Azure e VPN locale.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Questa architettura di riferimento implementa più livelli di sicurezza.

Routing di tutte le richieste utente locali tramite Firewall di Azure

La route definita dall'utente nella subnet del gateway blocca tutte le richieste utente diverse da quelle ricevute dall'ambiente locale. La route passa le richieste consentite al firewall. Le richieste vengono passate alle risorse nelle reti virtuali spoke, se consentite dalle regole del firewall. È possibile aggiungere altre route, ma assicurarsi che non ignorino inavvertitamente il firewall o blocchino il traffico amministrativo destinato alla subnet di gestione.

Uso di gruppi di sicurezza di rete per bloccare/passare il traffico alle subnet di rete virtuale spoke

Il traffico da e verso subnet di risorse nelle reti virtuali spoke è limitato tramite gruppi di sicurezza di rete. Se è necessario espandere le regole del gruppo di sicurezza di rete per consentire un accesso più ampio a queste risorse, valutare questi requisiti in base ai rischi per la sicurezza. Ogni nuovo percorso in ingresso espone al rischio di perdite di dati o danni alle applicazioni, sia di natura accidentale che intenzionale.

Protezione DDoS

Protezione DDoS di Azure, in combinazione con le procedure consigliate per la progettazione di applicazioni, offre funzionalità avanzate di mitigazione DDoS per difendersi meglio dagli attacchi DDoS. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.

Usare AVNM per creare regole di sicurezza di base Amministrazione

AVNM consente di creare linee di base delle regole di sicurezza, che possono assumere la priorità rispetto alle regole del gruppo di sicurezza di rete. Le regole di amministrazione della sicurezza vengono valutate prima delle regole del gruppo di sicurezza di rete e hanno la stessa natura dei gruppi di sicurezza di rete, con il supporto per la definizione delle priorità, i tag del servizio e i protocolli L3-L4. AVNM consente all'IT centrale di applicare una baseline di regole di sicurezza, consentendo al tempo stesso un'indipendenza da regole aggiuntive del gruppo di sicurezza di rete dai proprietari della rete virtuale spoke. Per facilitare un'implementazione controllata delle modifiche alle regole di sicurezza, la funzionalità delle distribuzioni di AVNM consente di rilasciare in modo sicuro le modifiche di rilievo di queste configurazioni negli ambienti hub-spoke.

Accesso DevOps

Usare il controllo degli accessi in base al ruolo di Azure per limitare le operazioni che DevOps può eseguire in ogni livello. Quando si concedono le autorizzazioni, usare il principio del privilegio minimo. Registrare tutte le operazioni amministrative ed eseguire controlli regolari per assicurare che eventuali modifiche alla configurazione siano state pianificate.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Usare il calcolatore dei prezzi di Azure per stimare i costi. Altre considerazioni sono descritte nella sezione Ottimizzazione costi in Microsoft Azure Well-Architected Framework.

Ecco alcune considerazioni sui costi per i servizi usati in questa architettura.

Firewall di Azure

In questa architettura, Firewall di Azure viene distribuito nella rete virtuale per controllare il traffico tra la subnet del gateway e le risorse nelle reti virtuali spoke. In questo modo Firewall di Azure è conveniente perché viene usato come soluzione condivisa usata da più carichi di lavoro. Di seguito sono riportati i modelli tariffari Firewall di Azure:

  • Tariffa fissa all'ora di distribuzione.
  • Dati elaborati per GB per supportare il ridimensionamento automatico.

Rispetto alle appliance virtuali di rete, con Firewall di Azure è possibile risparmiare fino al 30-50%. Per altre informazioni, vedere Firewall di Azure e appliance virtuale di rete.

Azure Bastion

Azure Bastion si connette in modo sicuro alla macchina virtuale tramite RDP e SSH senza dover configurare un indirizzo IP pubblico nella macchina virtuale.

La fatturazione bastion è paragonabile a una macchina virtuale di base di basso livello configurata come jump box. Bastion è più conveniente rispetto a un jump box perché include funzionalità di sicurezza predefinite e non comporta costi aggiuntivi per l'archiviazione e la gestione di un server separato.

Rete virtuale di Azure

La rete virtuale di Azure è gratuita. Per ogni sottoscrizione è possibile creare fino a 50 reti virtuali in tutte le aree. Tutto il traffico che si verifica entro i limiti di una rete virtuale è gratuito. Ad esempio, le macchine virtuali nella stessa rete virtuale che comunicano tra loro non comportano addebiti per il traffico di rete.

Servizio di bilanciamento del carico interno

Il bilanciamento del carico di base tra macchine virtuali che risiedono nella stessa rete virtuale è gratuito.

In questa architettura, i servizi di bilanciamento del carico interni vengono usati per bilanciare il carico del traffico all'interno di una rete virtuale.

Distribuire lo scenario

Questa distribuzione crea due gruppi di risorse; la prima contiene una rete locale fittizia, la seconda un set di reti hub-spoke. La rete locale fittizia e la rete hub sono connesse usando i gateway di Azure Rete virtuale per formare una connessione da sito a sito. Questa configurazione è molto simile a come connettere il data center locale ad Azure.

Il completamento di questa distribuzione può richiedere fino a 45 minuti. Il metodo di distribuzione consigliato usa l'opzione del portale disponibile di seguito.

Usare il pulsante seguente per distribuire il riferimento usando il portale di Azure.

Deploy to Azure

Al termine della distribuzione, verificare la connettività da sito a sito esaminando le risorse di connessione appena create. Nella portale di Azure cercare "connessioni" e notare che lo stato di ogni connessione.

Screenshot showing the status of connections.

È possibile accedere all'istanza di IIS presente nella rete spoke dalla macchina virtuale che si trova nella rete locale fittizia. Creare una connessione alla macchina virtuale usando l'host Azure Bastion incluso, aprire un Web browser e passare all'indirizzo del servizio di bilanciamento del carico di rete dell'applicazione.

Per informazioni dettagliate e opzioni di distribuzione aggiuntive, vedere i modelli di Azure Resource Manager usati per distribuire questa soluzione: Rete ibrida sicura.

Passaggi successivi