Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni

Un Network Security Group (NSG) svolge la funzione di firewall virtuale per le risorse Azure. Contiene un elenco di regole di sicurezza che consentono o negano il traffico di rete in entrata e in uscita in base all'IP di origine, all'IP di destinazione, al numero di porta e al protocollo. Gli NSG possono essere associati alle subnet (con effetto su tutte le risorse della subnet) oppure a singole interfacce di rete (con effetto su una sola VM). Quando sono presenti sia un NSG della subnet sia un NSG della NIC, Azure valuta entrambi: per il traffico in entrata viene applicato prima l'NSG della subnet; per quello in uscita viene applicato prima l'NSG della NIC.

Ogni regola NSG ha le proprietà seguenti: Priorità — un numero compreso tra 100 e 4096; i numeri più bassi vengono valutati per primi. Origine/Destinazione — un indirizzo IP, un intervallo CIDR, un service tag o un application security group. Porta di origine/destinazione — numeri di porta o intervalli specifici (ad esempio, 80, 443, 3389 o 1024-65535). Protocollo — TCP, UDP, ICMP o Any. Azione — Allow o Deny. Le regole vengono valutate in ordine di priorità; prevale la prima regola corrispondente. Se nessuna regola corrisponde, vengono applicate le regole predefinite: negare tutto il traffico in entrata e consentire tutto il traffico in uscita.

Ogni NSG include tre regole predefinite in entrata e tre regole predefinite in uscita, con priorità comprese tra 65000 e 65500, che non possono essere eliminate. Regole predefinite in entrata: AllowVnetInBound (consente il traffico dalla VNet), AllowAzureLoadBalancerInBound (consente i probe di integrità di Azure), DenyAllInBound (nega tutto il resto). Regole predefinite in uscita: AllowVnetOutBound, AllowInternetOutBound, DenyAllOutBound. È possibile sostituire le impostazioni predefinite aggiungendo regole con numeri di priorità inferiori (100-64999), che hanno effetto prima delle regole predefinite.

I service tag sono gruppi predefiniti di intervalli di indirizzi IP per i servizi Azure e consentono di scrivere regole NSG concise senza specificare lunghi elenchi di indirizzi IP che cambiano nel tempo. Tra i service tag comuni figurano: Internet — tutti gli indirizzi IP esterni alla VNet. VirtualNetwork — tutti gli IP all'interno della VNet. AzureLoadBalancer — l'indirizzo IP del load balancer dell'infrastruttura Azure. Storage — gli IP del servizio Azure Storage per l'area selezionata. AzureActiveDirectory — gli endpoint di Entra ID. Microsoft aggiorna automaticamente questi tag, quindi le regole NSG rimangono corrette anche quando cambiano gli IP dei servizi.

L'associazione di un NSG a una subnet applica le relative regole a tutte le risorse della subnet, rendendola il modo più efficiente per applicare criteri di rete su larga scala. Ad esempio, associare un NSG 'DenyRDP' a una subnet del livello dati impedisce di accedere tramite RDP (porta 3389) dall'esterno a qualsiasi VM della subnet, indipendentemente da ciò che consentono gli NSG a livello di NIC. Questo NSG a livello di subnet funge da prima linea di difesa prima che il traffico raggiunga le singole VM, riducendo la superficie di attacco al confine della rete.

Gli Application Security Group (ASG) consentono di raggruppare le interfacce di rete delle VM Azure in base al ruolo applicativo anziché all'indirizzo IP. Ad esempio, può creare ASG denominati webServers, appServers e dbServers, quindi assegnare la NIC di ogni VM all'ASG appropriato. Nelle regole NSG può quindi scrivere: 'Consenti il traffico da webServers a appServers sulla porta 8080', senza specificare alcun indirizzo IP. Quando aggiunge o rimuove VM, deve semplicemente aggiornare la relativa appartenenza agli ASG; tutte le regole NSG vengono applicate automaticamente in modo corretto, senza modificare alcuna regola.

Una volta definiti gli ASG e assegnate le VM, può scrivere regole NSG che fanno riferimento agli ASG come origine o destinazione. Questo approccio è molto più facile da gestire rispetto alle regole basate sugli IP perché offre: nessuna gestione degli IP — non è necessario conoscere gli IP delle VM; l'appartenenza agli ASG gestisce la corrispondenza. Scalabilità dinamica — le nuove VM ereditano automaticamente le regole corrette quando vengono aggiunte all'ASG appropriato. Chiarezza semantica — le regole sono leggibili in modo naturale ('webServers → appServers sulla porta 8080') anziché come intervalli IP poco significativi. Gli ASG sono particolarmente utili negli ambienti dinamici, in cui le VM vengono aggiunte o sostituite frequentemente.

Gli NSG Flow Logs registrano informazioni su tutto il traffico IP che attraversa un NSG, inclusi IP di origine e destinazione, porta, protocollo, indicazione del fatto che il traffico sia stato consentito o negato e byte trasferiti. I flow log vengono scritti in un account Azure Storage in formato JSON e possono essere visualizzati nello strumento Traffic Analytics di Azure Network Watcher. I flow log sono preziosi per risolvere i problemi di connettività ('perché questo traffico viene bloccato?'), svolgere indagini di sicurezza e preparare report di conformità che richiedono prove dei modelli di traffico.

Tre errori comuni negli NSG che causano problemi di connettività: dimenticare l'ordine di valutazione — se esiste una regola Deny con priorità 100 e la regola Allow ha priorità 200, il traffico viene negato perché prevalgono i numeri di priorità inferiori. Bloccare i probe di integrità di Azure — i probe di integrità del Load Balancer provengono dall'IP 168.63.129.16; bloccare questa origine fa apparire non integri i backend del load balancer e impedisce loro di ricevere traffico. Sovrapporre gli NSG della subnet e della NIC — il traffico deve superare entrambe le valutazioni NSG; una regola che consente il traffico nell'NSG della subnet non sarà sufficiente se l'NSG della NIC lo nega.

Gli NSG e Azure Firewall sono complementari, ma diversi: NSG — decentralizzati, associati a subnet e NIC, filtraggio a livello 3/4 (IP e porta), nessuna registrazione del traffico per impostazione predefinita, inclusi gratuitamente in ogni VNet. Azure Firewall — centralizzato, servizio gestito in una VNet hub, filtraggio a livello 3/4 e a livello 7 (FQDN, URL, IDPS), registrazione completa tramite Azure Monitor e costo di circa 1.000+ USD al mese. Utilizzi gli NSG per il perimetro di base e l'isolamento dei livelli. Utilizzi Azure Firewall quando è necessaria un'applicazione centralizzata e verificabile delle regole per l'accesso Internet in uscita, con filtraggio FQDN, intelligence sulle minacce o ispezione TLS.

Quando un NSG è associato sia a una subnet sia a una NIC, può diventare difficile capire quali regole vengano effettivamente applicate. Azure offre nel portale la visualizzazione Effective Security Rules per la NIC di qualsiasi VM, mostrando il risultato combinato di tutte le regole NSG a livello di subnet e di NIC. Questo è l'elenco definitivo di ciò che viene effettivamente consentito o negato per quella VM. Lo strumento IP flow verify di Azure Network Watcher consente di andare oltre: specificando un IP e una porta di origine e destinazione, indica immediatamente se il traffico sarebbe consentito o negato e quale regola specifica ne è responsabile.

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

In questa lezione ha appreso che: gli NSG contengono regole Allow/Deny valutate in ordine di priorità, che filtrano il traffico per le subnet o per singole interfacce di rete, i service tag semplificano le regole rappresentando gruppi dinamici di intervalli IP dei servizi Azure e gli Application Security Group consentono di raggruppare le VM in base al ruolo, creando regole NSG che non richiedono manutenzione e si adattano alla crescita dell'ambiente. Nella prossima lezione esamineremo il VNet Peering e i Service Endpoint per connettere risorse tra VNet diverse e ai servizi Azure.