Segmentazione di rete on-prem e in cloud: VLANs, Firewalls, Security Groups e best practice

La segmentazione della rete è una delle contromisure più efficaci per ridurre la superficie di attacco, limitare la diffusione degli incidenti e separare chiaramente i processi operativi. Il termine segmentazione della rete indica la creazione intenzionale di zone logiche o fisiche nella rete in cui dispositivi, servizi e utenti possono comunicare tra loro solo in modo controllato. In ambito aziendale questo significa tipicamente una combinazione di VLAN (Virtual LAN), zone Router/Layer‑3, firewall e meccanismi specifici del cloud come Security Groups o Network ACLs. Questo articolo spiega in modo pratico come progettare, implementare, testare e gestire in sicurezza la segmentazione on‑prem e in cloud.

Concetti di base, brevi e chiari

Prima di passare a configurazione e rollout, assegnare brevemente e in modo comprensibile i termini principali nello stesso paragrafo:

• VLAN (Virtual Local Area Network): separazione logica a Layer‑2 (data link). Le VLAN isolano domini di broadcast sulle porte degli switch e richiedono routing (Layer‑3) per la comunicazione inter‑VLAN.
• Firewall: dispositivo o software che consente o blocca il traffico in base a regole. Può essere stateful (orientato alla connessione) o stateless.
• Security Group: costrutto cloud (es. AWS/Azure) per la raggruppamento di regole; solitamente stateful e associato alle istanze.
• Network ACL: insieme di regole, cloud o on‑prem, che opera in genere in modalità stateless e agisce a livello di subnet/rete.
• Microsegmentazione: controllo a grana fine delle connessioni fino al livello di processo o host (ad esempio via host‑firewall, iptables/nftables o policy eBPF).

Segmentazione di rete: principi fondamentali e obiettivi

Una buona segmentazione segue obiettivi operativi chiari: limitare la diffusione degli attacchi, isolare i dati sensibili, migliorare la distribuzione del carico di rete e separare responsabilità operative. I principi sono:

• Least privilege: consentire solo le connessioni strettamente necessarie.
• Trust zoning: strutturare le aree di rete per livello di fiducia (ad es. DMZ, App‑Tier, DB‑Tier).
• Logging und Monitoring: tutti i confini di zona devono essere tracciabili e registrati.
• Automatisierung: policy come codice (IaC), pipeline di revisione e test automatici prevengono la deriva e le errate configurazioni.

On‑Prem: progettare e gestire VLAN in pratica

Le VLAN sono il metodo classico per la segmentazione on‑prem. Una VLAN raggruppa porte e crea una propria dominio di broadcast; il routing tra VLAN avviene tramite router o L3‑switch (Inter‑VLAN‑Routing).

Prerequisiti e pianificazione

Prerequisiti importanti: switch con supporto trunk (IEEE 802.1Q) per il passaggio dei VLAN, un piano di indirizzamento IP coerente, ID VLAN e convenzioni di denominazione documentate, oltre a policy di routing sul gateway L3. Senza un piano IP pulito si genera rapidamente overlap, gateway posizionati in modo errato o tempeste di broadcast.

Esempio: creare una VLAN su uno switch (Cisco IOS)

Configurazione di una porta trunk e di una porta access:

configure terminal
vlan 10
 name VLAN-APP
interface GigabitEthernet1/0/1
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
interface GigabitEthernet1/0/2
 switchport mode access
 switchport access vlan 10
end
write memory

Perché funziona: il trunk trasporta più VLAN tra switch; le porte access appartengono a un singolo VLAN. Quando fallisce: configurazione trunk mancante sul dispositivo opposto, VLAN native diverse o problemi di MTU (prestare attenzione al traffico voce e al VLAN tagging).

Linux‑Host als Router / VLAN‑Interface

Per siti di piccole dimensioni o ambienti di test un Linux‑gateway può gestire direttamente VLAN‑interface:

ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 192.168.10.1/24 dev eth0.10
ip link set eth0.10 up
sysctl -w net.ipv4.ip_forward=1

Rischio: limiti di performance e mancanza di supporto per hardware‑offload su host commodity. Per carichi produttivi si raccomandano L3‑switch o router/firewall dedicati.

Cloud‑Konzepte: Security Groups, NACLs und Routing

Nelle Public Cloud come AWS, Azure o Google Cloud esistono primitive diverse. Security Groups (SG) sono regole tipicamente associate alle istanze, per lo più stateful. Network ACLs (NACL) operano a livello di subnet e sono spesso stateless, cioè richiedono regole separate per ingresso/uscita.

Stateful vs. stateless kurz erklärt

Stateful significa che il firewall tiene traccia delle connessioni (p.es. una connessione TCP consentita permette poi il traffico di ritorno). Stateless tratta ogni direzione in modo indipendente e pertanto richiede una gestione di regole più dettagliata. In AWS le SGs sono stateful; le NACL sono stateless. In Azure le NSGs (Network Security Groups) sono stateful.

Beispiel: Security Group anlegen (AWS CLI)

aws ec2 create-security-group --group-name zammad-app-sg --description "Zammad App SG" --vpc-id vpc-123abc
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 5432 --source-group sg-0dbonly

L’ultima regola mostra un modello importante: la porta DB (5432) consentita solo dalla Application‑SG. In questo modo si impediscono accessi diretti da Internet ai database.

Firewalls strategisch einsetzen: Zonen, Regeln, Logging

La segmentazione funziona meglio con zone ben definite: Perimeter/DMZ, App‑Tier, Database‑Tier, Management. Le firewall applicano la policy ai punti di transizione tra le zone. Punti importanti:

• Regole basate sul bisogno funzionale, non sugli IP: raggruppate i servizi, non i singoli host.
• Default‑Deny: policy perimetrale impostata di default su deny; consentire solo i flussi esplicitamente autorizzati.
• Limitazioni di protocollo e porta: aprire solo i protocolli necessari (p.es. HTTPS invece di HTTP, proxy applicativi, mTLS).
• Logging e retention: raccogliere centralmente i log delle firewall (SIEM) per rilevare anomalie.

Beispiel: Minimaler nftables‑Input‑Chain (Host‑Firewall)

nft add table inet filter
nft 'add chain inet filter input { type filter hook input priority 0 ; }'
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iifname "lo" accept
nft add rule inet filter input tcp dport 443 accept
nft add rule inet filter input tcp dport 22 ct state new limit rate 10/second accept
nft add rule inet filter input drop

Perché funziona: semplice strategia Default‑Deny con permesso per connessioni stabilite e per i servizi necessari. Quando fallisce: assenza di regole di logging, lasciare la console (SSH) troppo aperta o posizionare le regole in ordine errato.

Best‑Practices: Design, Automatisierung und Betrieb

Linee guida concrete che nei progetti fanno spesso la differenza:

1. Convenzioni per tagging e naming: Usate tag coerenti in cloud (p.es. environment, role, owner) e una struttura di nomenclatura VLAN on‑prem (p.es. VLAN-APP-10).
2. Policy as Code: Gestire firewall e Security Groups tramite IaC (Terraform, ARM, CloudFormation), inclusa revisione del codice e test.
3. Change‑Control: Ogni modifica della policy attraversa test automatizzati (Connectivity‑Smoke, Regression) e dispone di un’opzione di rollback.
4. Least‑Privilege e regole esplicite: Nessuna regola aperta 0.0.0.0/0 tranne quando strettamente necessario.
5. Monitoraggio & Avvisi: Anomalie come picchi improvvisi nel traffico East‑West o scansioni di porta non usuali generano allarmi.
6. Documentazione: Mantenere aggiornati IP‑Plan, VLAN‑Map e Firewall‑Matrix (chi può raggiungere chi?).

Piano di migrazione e rollout: passo per passo

Per la migrazione da reti piatte a ambienti segmentati è consigliabile un percorso di rollback garantito. Una sequenza esemplare:

1. Analisi: registrare i flussi correnti con NetFlow/sFlow, tcpdump e le dipendenze di servizio.
2. Progettazione: creare una mappa di zone e servizi, documentare porte ed endpoint.
3. Distribuzione automatizzata: generare template IaC, dry‑run, review e deploy in staging.
4. Canary: applicare la segmentazione su un piccolo sottoinsieme e osservare.
5. Rollout in produzione: cutover graduale con monitoraggio e rollback d’emergenza.

Comandi di test importanti

Usare sistematicamente questi comandi per verificare connettività e regole:

# Test connessione TCP (Netcat)
nc -vz 192.168.10.5 5432

# Cattura pacchetti (es. traffico DB)
tcpdump -i eth0 -n 'host 192.168.10.5 and port 5432'

# Visualizzare le regole del firewall
nft list ruleset

# Controllare route/next‑hop
ip route show

# Traceroute per diagnosi del percorso
traceroute -n 10.0.0.5

# Controllo HTTP
curl -v --connect-timeout 5 https://app.example.local/health

Monitoraggio, logging e rilevamento delle derive

La segmentazione è efficace quanto il suo monitoraggio. Requisiti principali:

• Flow‑Logging: Attivare NetFlow/sFlow sugli switch e VPC Flow Logs nelle cloud per analizzare il traffico East‑West.
• Firewall Logs: Inoltrare log strutturati (JSON) a un SIEM per permettere correlazioni.
• Drift Detection: Confrontare continuamente le configurazioni correnti con lo stato IaC (p.es. Terraform plan in CI). Strumenti cloud come AWS Config o Azure Policy possono segnalare modifiche non gestite.

Esempio: attivare VPC Flow Logs e una semplice query CloudWatch Logs Insights per indirizzi IP sorgente anomali:

# VPC Flow Logs (esempio breve - CLI)
aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-123abc --traffic-type ALL --log-group-name /aws/vpc/flowlogs --deliver-logs-permission-arn arn:aws:iam::123456:role/flowlogs-role

# Esempio di query CloudWatch Logs Insights
fields @timestamp, srcAddr, dstAddr, action | filter action = 'REJECT' | stats count() by srcAddr | sort @timestamp desc

Prestazioni, MTU e latenza

La segmentazione può avere effetti collaterali su latenza e MTU. I frame taggati aumentano la dimensione dei pacchetti; in VPN o overlay (p.es. VXLAN) gli header si sommano. Verificare le impostazioni MTU lungo il percorso e misurare latenza/throughput prima e dopo le modifiche.

Strumenti di misura e comandi di esempio:

# Verificare MTU
ip link show dev eth0

# Misurare latenza e throughput (iperf3)
iperf3 -c 10.0.0.5 -p 5201 --parallel 4 --time 30

Microsegmentazione, firewall host e eBPF

Se Layer‑2/3 non sono sufficienti o è richiesta l’operatività multi‑tenant, aiuta la microsegmentazione: basata sull’host tramite nftables/iptables, agent‑based (es. agent specifici per aree) o approcci moderni con eBPF, che porta filtri pacchetti ad alte prestazioni nel kernel. Vantaggio: controllo molto fine; Svantaggio: maggiore complessità e carico operativo.

Zammad‑spezifische Betriebs‑ und Troubleshooting‑Ergänzungen

Per le installazioni Zammad concretizzi la segmentazione secondo i punti seguenti:

• Elenco delle porte minime: Web (80/443), Postgres (5432), Elasticsearch (9200), Redis (6379).
• Protezione dei percorsi amministrativi: SSH/Management solo nella Management‑Zone, 2FA per gli account webadmin e restrizioni IP per i pannelli di amministrazione.
• Health‑Checks e playbook: semplici endpoint di health verificano il Web, le connessioni al DB e l’index‑health di Elasticsearch.

Sequenza di troubleshooting per problemi di raggiungibilità:

1. Verificare firewall e Security Groups (log per ACCEPT/REJECT).
2. Testare il percorso di rete (traceroute, tcpdump sull’App‑Host).
3. Controllare i log delle applicazioni (Zammad Rails Logs, Postgres Logs, Elasticsearch Logs).
4. Rollback alla versione precedente di Security‑Group/Firewall se la connettività è stata dimostrabilmente causata da una policy.

Beispiel: Terraform‑Snippet für Security Group (Cloud‑Policy as Code)

resource "aws_security_group" "zammad_app" {
  name        = "zammad_app_sg"
  description = "App SG für Zammad"
  vpc_id      = var.vpc_id

  ingress {
    description = "Web"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description     = "DB Access aus App SG"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.zammad_db.id]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "zammad_app_sg"
  }
}

Importante: definire versionamento, controlli CI (terraform plan) e approvazioni automatizzate per garantire distribuzioni prive di drift.

Operationales Runbook und Rückfallstrategie

Un runbook preciso riduce lo stress durante un incidente. Punti chiave:

• Comandi per test rapidi (connettività, log, Health‑Checks).
• ID di snapshot/backup e relativo timestamp documentati.
• Comando di rollback o playbook di revert IaC, inclusi referenti e catena di escalation.
• Piano di comunicazione: aggiornamenti di stato ai team interessati e finestre di manutenzione.

Checkliste vor dem Produktivstart

• IP‑Plan e VLAN‑Map finali e condivisi con il team.
• Template IaC creati, review completato, test automatici superati.
• Backup/Snapshot creato prima del rollout.
• Monitoring (Flows, Firewall‑Logs) attivo e soglie di alert configurate.
• Playbook di rollback documentato e testato.
• Documentazione di regole e responsabilità disponibile.

Fazit

La segmentazione di rete è un progetto continuo, non un’iniziativa una tantum. L’approccio migliore combina principi di progettazione solidi (Least‑Privilege, Trust Zoning), automazione (Policy as Code) e una procedura chiara di test e rollback. I VLAN on‑prem e le Cloud Security Groups si completano spesso a vicenda e nella pratica devono essere intesi come un set di policy coerente. Per soluzioni aziendali digitali vicine ai processi come Zammad una segmentazione pulita ripaga: superficie d’attacco ridotta, responsabilità univoche e roll‑out riproducibili. Iniziate in piccolo (Canary), misurate i flussi e automatizzate la distribuzione delle policy — così i progetti di segmentazione diventano gestibili e sostenibili.