Peering delle VNet ed endpoint di servizio

Per impostazione predefinita, le risorse in VNet Azure diverse non possono comunicare tra loro, anche se si trovano nella stessa area Azure. Tuttavia, le grandi organizzazioni hanno spesso più VNet: VNet separate per sviluppo, staging e produzione, oppure VNet diverse per i vari reparti. Il VNet Peering connette direttamente due VNet tramite la rete backbone privata di Microsoft, consentendo alle risorse di entrambe le VNet di comunicare come se si trovassero nella stessa rete, senza che il traffico attraversi la rete Internet pubblica o richieda un gateway VPN.

Il VNet Peering è una connessione non transitiva: se la VNet A è sottoposta a peering con la VNet B e la VNet B è sottoposta a peering con la VNet C, la VNet A non può comunicare con la VNet C a meno che non venga creato un peering separato tra A e C. I collegamenti di peering sono bidirezionali, ma devono essere configurati su entrambi i lati: la creazione di un peering da A a B non ne crea automaticamente uno da B a A. Dopo aver configurato entrambi i lati, il traffico tra le VNet sottoposte a peering utilizza l'Azure backbone, con bassa latenza e larghezza di banda elevata, paragonabili alla comunicazione tra subnet all'interno di una singola VNet.

Il peering VNet offre due opzioni di ambito: peering VNet locale connette due VNet nella stessa area geografica di Azure. Il traffico rimane all'interno dell'area e comporta un piccolo costo di trasferimento per GB. Il peering VNet globale connette due VNet in aree geografiche Azure diverse, instradando il traffico sulla rete backbone globale di Microsoft. In questo modo, le risorse in East US possono comunicare privatamente con le risorse in West Europe senza attraversare Internet pubblico. Il peering globale ha un costo di trasferimento leggermente superiore rispetto a quello locale, ma resta significativamente più economico e affidabile dell'instradamento tramite VPN.

Un modello comune nelle aziende utilizza il peering VNet per implementare una topologia hub-and-spoke. Una VNet hub centrale ospita servizi condivisi: Azure Firewall, VPN Gateway, server DNS e monitoraggio. Più VNet spoke (una per ogni ambiente o carico di lavoro) stabiliscono il peering con l'hub. Instradando tutto il traffico degli spoke attraverso il firewall dell'hub, l'organizzazione ottiene un'ispezione di sicurezza centralizzata senza dover gestire configurazioni NSG complesse in ogni spoke. Poiché il peering non è transitivo, il firewall dell'hub instrada il traffico tra gli spoke utilizzando le route definite dall'utente (UDR).

Il peering VNet prevede un requisito fondamentale: gli spazi di indirizzi delle VNet con peering non devono sovrapporsi. Se la VNet A utilizza 10.0.0.0/16 e anche la VNet B utilizza 10.0.0.0/16, il peering non riesce perché Azure non può instradare il traffico tra intervalli di indirizzi identici. Per questo è essenziale pianificare intervalli CIDR non sovrapposti per tutte le VNet e per le reti locali prima di iniziare. La modifica dello spazio di indirizzi di una VNet dopo la distribuzione delle risorse richiede la ricreazione della VNet oppure l'utilizzo della funzionalità, limitata, di aggiunta o rimozione dello spazio di indirizzi.

Gli endpoint di servizio estendono l'identità della VNet ai servizi PaaS di Azure, come Azure Storage, Azure SQL Database, Azure Key Vault e Cosmos DB. Quando si abilita un endpoint di servizio in una subnet, il traffico dalle risorse di quella subnet verso il servizio Azure specificato viene instradato sulla rete backbone di Azure anziché su Internet pubblico, anche se viene utilizzato l'indirizzo IP pubblico del servizio. Il servizio può quindi limitare l'accesso alle sole risorse che si trovano in VNet con l'endpoint di servizio abilitato, offrendo un miglioramento significativo della sicurezza rispetto agli endpoint accessibili da Internet.

Gli endpoint di servizio e gli endpoint privati offrono entrambi un accesso sicuro ai servizi PaaS di Azure, ma funzionano in modo diverso: endpoint di servizio — instrada il traffico sulla rete backbone di Azure, ma utilizza ancora l'indirizzo IP pubblico del servizio; l'endpoint di servizio esiste a livello di subnet. endpoint privato — assegna al servizio un indirizzo IP privato della VNet; l'endpoint pubblico può essere disabilitato completamente, rendendo il servizio realmente privato. Gli endpoint privati offrono un isolamento più efficace e sono accessibili anche dalla rete locale tramite VPN/ExpressRoute. Per il massimo livello di sicurezza, sono preferibili gli endpoint privati; gli endpoint di servizio rappresentano un'alternativa più semplice ed economica.

Dopo aver abilitato un endpoint di servizio in una subnet, si configura il servizio Azure affinché accetti connessioni esclusivamente da quella subnet. Per un account di archiviazione, ciò significa aggiungere una regola VNet nelle impostazioni del firewall dell'account. Dopo questa modifica, solo le VM nella subnet specificata possono raggiungere l'account di archiviazione; tutto il restante traffico proveniente da Internet viene negato. È un modo rapido e gratuito per migliorare significativamente la sicurezza dell'account di archiviazione rispetto a lasciarlo aperto a tutto il traffico Internet, soprattutto nel caso di account che ospitano dati applicativi sensibili.

Integrazione VNet (distinta dal peering VNet) consente alle applicazioni Azure App Service di effettuare chiamate in uscita verso risorse all'interno di una VNet. Senza l'integrazione VNet, il traffico in uscita di un App Service passa sempre attraverso Internet pubblico, anche quando chiama risorse come Azure SQL o Azure Cache for Redis nella stessa VNet. Con l'integrazione VNet abilitata, il traffico in uscita dell'app viene instradato nella VNet e può raggiungere risorse private. È necessaria una subnet delegata dedicata nella VNet, con uno spazio di indirizzi di almeno /28.

Poiché il peering VNet non è transitivo, per connettere più di due VNet è necessario stabilire un peering diretto tra ogni coppia, con complessità O(n²), oppure utilizzare un hub di routing centrale. In un modello hub-and-spoke, la VNet hub contiene una Network Virtual Appliance (NVA) o Azure Firewall che funge da router di transito tra le VNet spoke. Ogni spoke aggiunge una UDR che indirizza tutto il traffico (0.0.0.0/0 o specifici CIDR degli spoke) all'indirizzo IP della NVA nell'hub. La NVA inoltra quindi il traffico verso lo spoke di destinazione corretto, fornendo di fatto una connettività transitiva attraverso l'hub.

Principali limitazioni del peering VNet: sono necessari spazi di indirizzi non sovrapposti — pianificare attentamente gli intervalli CIDR prima di creare le VNet. Non transitivo — il peering tra A-B e B-C non connette A-C. Non è possibile ridimensionare lo spazio di indirizzi di una VNet se sono presenti peering attivi, senza eliminarli temporaneamente. Transito del gateway — le VNet spoke possono utilizzare il gateway VPN o ExpressRoute nella VNet hub abilitando l'opzione 'Use Remote Gateways' nella configurazione del peering, ma è necessario creare prima il gateway dell'hub. Comprendere queste limitazioni è importante per progettare architetture scalabili e facilmente gestibili con più VNet.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha appreso che: il peering VNet connette due VNet tramite la rete backbone di Microsoft per una comunicazione privata e a bassa latenza senza VPN, ma il peering non è transitivo; gli endpoint di servizio instradano il traffico della subnet verso i servizi PaaS di Azure tramite la rete backbone senza esporlo a Internet pubblico; gli endpoint privati sono l'alternativa più sicura: assegnano un IP privato a un servizio PaaS e consentono di disabilitare completamente l'endpoint pubblico. Nella prossima lezione analizzeremo i concetti fondamentali di Azure DNS e Load Balancer.