VPC Cloud e Segmentazione Rete: Guida Architetturale

Un container esposto a internet senza controlli di rete ha causato la violazione dati di 57 milioni di record in un'azienda fintech nel 2023. Il costo medio di una breach cloud-based è arrivato a 4,45 milioni di dollari secondo IBM. La segmentazione rete cloud non è un'opzione — è sopravvivenza aziendale.

Perché la Sicurezza della Rete Cloud È Fallita Fin Dall'Inizio

Il problema è strutturale. Quando le aziende migrano workload su cloud pubblico, applicano mentalità on-premise a un'infrastruttura che funziona in modo radicalmente diverso. Su AWS, Azure e GCP, il network è virtualizzato, elastico e globale per natura. Deleghi la segmentazione fisica a qualcun altro — ma i confini logici restano responsabilità tua.

Il dato è inequivocabile**: il 67% delle violazioni cloud nel 2024 è avvenuto per configurazione errata dei security group, secondo il rapporto Verizon Data Breach Investigations. Non si tratta di attacchi sofisticati. Si tratta di architetture progettate senza comprendere i primitives di rete cloud.

Le Tre Dimensioni del Fallimento

1. Complessità accidentalmente introdotta

Ogni VPC che crei senza design metodico diventa un sistema a spaghetti. Ho visto VPC con 340 regole di peering, nessuna documentazione, e un team che temeva toccare qualsiasi cosa perché "funzionava". Questo è debito tecnico che si paga in ore di incident response.

2. Lateral movement non controllato

In un'architettura flat, un attacker che compromette un'istanza ha potenzialmente accesso a tutto. Il 2023 Mandiant M-Trends report ha documentato che il dwell time medio — il tempo tra compromissione iniziale e discovery — è di 16 giorni in ambienti cloud. Sedici giorni di movimento laterale indisturbato.

3. Compliance che diventa teatro

PCI-DSS 4.0 richiede esplicitamente segmentazione delle reti di pagamento. GDPR impone misure tecniche adeguate. ISO 27001 parla di controlli di accesso alla rete. Se la tua segmentazione rete cloud è un monolite con security group applicati inconsistentemente, non sei compliant — sei un audit waiting to fail.

Perché Gli Approcci Tradizionali Non Funzionano

Firewall tradizionali hanno concetti come "zona demilitarizzata" e "rete interna". Su cloud pubblico, le zone esistono solo come costrutti logici che crei tu. AWS Transit Gateway non è un firewall — è un hub di routing. Azure Virtual WAN non segmenta per te. GCP Network Connectivity Center connette, non isola.

La responsabilità della segmentazione è tua, e il toolsset è diverso.

Architettura di Segmentazione: VPC Cloud Moderno

La segmentazione efficace richiede un approccio a strati. Non esiste una soluzione singola — esiste un stack di controlli che lavorano insieme.

Layer 1: VPC Design Con Multi-Tier Architecture

Il foundation layer è come strutturi i Virtual Private Cloud. Opzioni principali:

Single VPC con Subnet per Ambiente

Adatto per startup o workload isolati. Tutto in un VPC, subnet pubbliche per load balancer, private per application tier, isolated per database.

VPC: 10.0.0.0/16
├── Subnet Pubblica (Web Tier): 10.0.1.0/24
├── Subnet Applicazione (App Tier): 10.0.2.0/24
├── Subnet Dati (Data Tier): 10.0.3.0/24
└── Subnet Isolata (Security/Tools): 10.0.4.0/24

Questo modello funziona per MVP e team piccoli. Ma scala male oltre 50 risorse — il blast radius di un errore diventa sistemico.

Multi-VPC Architecture con Transit Gateway

Per aziende enterprise, la right answer è multi-VPC con AWS Transit Gateway o equivalenti Azure/GCP. Ogni workload o dominio ha il proprio VPC isolato. Transit Gateway agisce come hub centrale per comunicazione controllata.

Architettura	Caso d'Uso	Complessità	Costo Mensile Stimato	Scalabilità
Single VPC + Subnet	MVP, Startup	Bassa	$50-150	Fino a 100 istanze
Multi-VPC + TGW	Mid-market	Media	$500-2000	Fino a 500 risorse
Hub & Spoke Federato	Enterprise	Alta	$2000-10000+	Illimitata
Landing Zone AWS	Enterprise Globale	Molto Alta	$5000-50000+	Multi-account

Layer 2: Security Groups come Firewall Stateful

Security groups sono stateful — se permetti inbound su porta 443, il traffico di ritorno è automatico. Questa è la foundation del controllo, ma anche la trappola.

Best Practice Security Groups

Regola 1: Never allow 0.0.0.0/0 su porte elevate. Mai.

# Security Group per Application Tier - BEST PRACTICE
resource "aws_security_group" "app_tier" {
  name        = "app-tier-sg"
  description = "Security group per application tier"
  vpc_id      = aws_vpc.main.id

  ingress {
    description     = "HTTPS from Web Tier only"
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.web_tier.id]
  }

  ingress {
    description     = "SSH from Bastion only"
    from_port       = 22
    to_port         = 22
    protocol        = "tcp"
    security_groups = [aws_security_group.bastion.id]
  }

  egress {
    description = "HTTPS outbound to internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Environment = "production"
    Compliance  = "PCI-DSS"
  }
}

Il vantaggio di referenziare security groups invece di CIDR ranges è che le regole sopravvivono ai cambiamenti IP. Se una instance viene ricreata, le regole continuano a funzionare.

Layer 3: Network ACLs come Firewall Stateless Secondario

Network ACLs operano a livello subnet — sono stateless e valutano ogni pacchetto. Usali come controllo difensivo aggiuntivo, non primario.

Quando NACLs hanno senso:

• Bloccare ranges IP specifici a livello subnet
• Implementare regole di deny esplicite
• Segmentare tra tier di rete

Quando NACLs sono overkill:

• Controllo per-instance (usare security groups)
• Traffico East-West tra tier (security groups sono sufficienti)

# NACL per subnet database - blocca tutto tranne accesso specifico
Rule #: 100 | Type: Custom | Protocol: TCP | Port: 3306 | Source: 10.0.2.0/24 | Allow
Rule #: 200 | Type: Custom | Protocol: ALL | Source: 0.0.0.0/0 | Deny
Rule #: * | Type: All | Protocol: All | Source: All | Deny

Il DENY esplicito finale è mandatory. NACLs hanno regole evaluate in ordine numerico — tutto ciò che non match esplicitamente viene negato.

Layer 4: PrivateLink e VPC Endpoint per Accesso Zero-Internet

Per servizi AWS come S3, DynamoDB, Secrets Manager, il traffico non deve mai uscire su internet. VPC Endpoint con PrivateLink crea connessioni private al servizio.

# VPC Endpoint per S3 con bucket policy restrittiva
resource "aws_vpc_endpoint" "s3_endpoint" {
  vpc_id            = aws_vpc.main.id
  service_name      = "com.amazonaws.eu-west-1.s3"
  route_table_ids   = [aws_route_table.private_rt.id]
  policy            = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Deny"
      Principal = "*"
      Action = "s3:*"
      Resource = ["arn:aws:s3:::production-data-bucket"]
      Condition = {
        StringNotEquals = {
          "aws:sourceVpce" = aws_vpc_endpoint.s3_endpoint.id
        }
      }
    }]
  })
}

Con questa configurazione, anche se qualcuno ottiene credenziali, non può accedere al bucket da outside del VPC.

Framework di Decisione: Quale Modello di Segmentazione?

Domande critiche per scegliere:

1. Quanti team/lavoreload devono essere isolati?

   • < 5 team → Single VPC con strong security groups
   • 5-20 team → Multi-VPC con Shared Services centrali

   • 20 team → AWS Landing Zone o Azure Landing Zones con governance automatizzata

2. Requisiti di compliance?

   • Solo SOC2 → Network segmentation base
   • PCI-DSS → VPC dedicati per cardholder data environment
   • HIPAA → VPC isolati con crittografia e audit trail

3. Necessità di network inspection?

   • Nessuna → Security groups sufficienti
   • IDS/IPS basic → AWS Gateway Load Balancer con partner solutions
   • Deep packet inspection → Transit Gateway + Appliance virtuali dedicate

Implementazione Pratica: Step-by-Step su AWS

Fase 1: Landing Zone Foundation

# Creazione VPC con Terraform - approccio infrastruttura come codice
# Sempre preferire IaC a click-ops per reproducibility

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-1"
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "production-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
  database_subnets = ["10.0.201.0/24", "10.0.202.0/24", "10.0.203.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = false  # Alta disponibilità

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

Fase 2: Bastion Host e Accesso Privilegiato

Mai SSH direttamente su istanze production. Il pattern corretto:

1. AWS Systems Manager Session Manager per accesso senza bastion (best option)
2. Bastion host in public subnet se SSM non è praticabile (sempre con strict security groups)

# Security Group per bastion - porta 22 solo dal management network
Ingress:
  - FromPort: 22
    ToPort: 22
    Source: 10.255.0.0/24  # Management network dedicato
    Description: SSH from on-premises VPN

Egress:
  - ToPort: 443
    FromPort: 443
    Destination: 0.0.0.0/0
    Description: HTTPS per Session Manager agent

Fase 3: Transit Gateway per Multi-VPC

Per architetture con più VPC, Transit Gateway centralizza il routing.

# Transit Gateway con route tables segmentate
resource "aws_ec2_transit_gateway" "main" {
  description = "Central transit gateway"
  auto_accept_shared_attachments = "enable"
  default_route_table_propagation = "enable"
  default_route_table_association = "enable"
  dns_support                     = "enable"
  vpn_ecmp_support                = "enable"
}

# Route table per spoke production - default deny
resource "aws_ec2_transit_gateway_route_table" "production" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id

  route {
    destination_cidr_block = "0.0.0.0/0"
    transit_gateway_attachment_id = "tgw-attach-internet-vpc"
  }
}

Fase 4: Network Watcher e Monitoring

# Abilitare VPC Flow Logs per tutti i VPC production
aws logs create-log-group --log-group-name /aws/vpc/flow-logs/production

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-0123456789abcdef \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flow-logs/production \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/FlowLogsRole

Con Flow Logs in CloudWatch, puoi interrogare pattern anomali:

-- Query Athena per identificare connection refused anomali
SELECT 
  srcaddr,
  dstaddr,
  dstport,
  count(*) as attempts
FROM vpc_flow_logs
WHERE action = 'REJECT'
  AND dstport IN (22, 3389, 3306, 5432)
  AND date_diff('hour', from_iso8601_timestamp(partition_0), current_timestamp) < 24
GROUP BY srcaddr, dstaddr, dstport
ORDER BY attempts DESC
LIMIT 20;

Errori Critici che Ho Visto in Produzione

Errore 1: Security Group Universale "Allow All"

Il problema: Assegnare 0.0.0.0/0 su tutte le porte a "testing" e dimenticarsene in production.

Perché succede: Urgency vs. security. Il developer che chiede accesso urgentemente, il sysadmin che approva senza review. Lavo fatto — tutti lo abbiamo fatto.

Come evitarlo: Policy as code con AWS Config rules che rilevano e auto-remediano security groups permissivi.

# AWS Config rule che blocca security groups permissivi
resource "aws_config_config_rule" "restricted-sg" {
  name = "restricted-common-ports-sg"
  
  source {
    owner            = "AWS"
    source_identifier = "INCOMING_SSH_DISABLED"
  }
  
  scope {
    compliance_types = ["COMPLIANT", "NON_COMPLIANT"]
  }
}

Errore 2: Peering Cross-Account Senza Route Planning

Il problema: VPC Peering creati senza considerare transitivity. A può parlare con B, B può parlare con C, quindi A parla con C? No — ma confusione causa errore umano.

Perché succede: Peering sembra semplice. Due click. Ma dimentichi che route tables devono essere aggiornate su entrambe le sides.

Come evitarlo: Documentare ogni peering con diagramma di flusso e test di connettività post-deployment con nc o telnet.

Errore 3: Nuvola Pubblica per Database Critici Senza Encryption at Rest

Il problema: RDS instances senza KMS encryption. GDPR violation in piena regola.

Perché succede: Encryption è disabilitato by default su alcune configurazioni. Terraform non forza encryption se non specificato.

Come evitarlo: Terraform module che强制 encryption su tutte le risorse data.

# Terraform che forza encryption per default
variable "enable_encryption" {
  description = "Force encryption on all storage resources"
  type        = bool
  default     = true
}

resource "aws_db_instance" "main" {
  # ... altre config ...
  
  storage_encrypted = var.enable_encryption
  kms_key_id        = var.enable_encryption ? aws_kms_key.main.arn : null
}

Errore 4: Secrets in Environment Variables invece di Secrets Manager

Il problema: Database passwords in environment variables, visibili in AWS Console, nei log, nel codice versionato.

Perché succede: Quick & dirty. Funziona. Rotate è un nightmare ma "lo farai dopo".

Come evitarlo: AWS Secrets Manager con rotation configurata. Kubernetes External Secrets Operator se su EKS.

Errore 5: Ignoring Egress Traffic

Il problema: Security groups configurati solo per inbound. Tutto l'egress è allow by default in AWS. Un compromised workload diventa exfiltration machine.

Perché succede: Stateful per natura significa che "il default è aperto in uscita". Non pensi al outbound finché non succede qualcosa.

Come evitarlo: Security groups con egress espliciti. Site-to-Site VPN per accesso internet centralizzato e ispezionato.

Raccomandazioni Opzionee e Concrete

Usa Terraform per tutto. Mai click-ops su production. Il giorno che hai un incident e devi capire perché la regola è così, il version control è l'unica source of truth.

Implementa AWS Verified Access per applicazioni SaaS internal. Quando Zscaler o Similar costano $15/user/month, Verified Access a $6/month per accesso zero-VPN è la scelta giusta per team sotto 500 utenti.

Segmenta by ownership, not by tier. Il team di payments non dovrebbe condividere subnet con team marketing, anche se entrambi hanno web-app tier. Ownership boundary è più importante di layer boundary.

Automatizza compliance con Prowler o ScoutSuite. Scan settimanali automatici di tutte le risorse contro CIS benchmarks. Configura CloudWatch Events per alert in tempo reale su finding critici.

Quando scegliere AWS vs. Azure vs. GCP per networking:

• AWS: L'ecosistema è il più maturo. Transit Gateway, PrivateLink, VPC Lattice per service mesh networking. Right choice quando hai workload eterogenei e нуждаешься в vendor lock-in controllato.

• Azure: Seориентируешься su Microsoft stack (Office 365, Teams, Active Directory). Azure Virtual WAN è competitivo per branch connectivity. Good choice per hybrid scenarios con strong Windows integration.

• GCP: Autopilot GKE con built-in network policies è donde il gioco. Anthos per multi-cloud management. Scegli per container-native architectures.

Il prossimo passo concreto: Audit dei tuoi security groups esistenti con questo one-liner che genera report di tutte le regole permissivе:

aws ec2 describe-security-groups \
  --query 'SecurityGroups[*].{Name:GroupName,ID:GroupId,Rules:IpPermissions}' \
  --output table \
  --profile production | grep -E "0.0.0.0|/0|::/0"

Se l'output è più lungo di 10 righe, hai lavoro da fare.

La sicurezza rete cloud non è un progetto con data di fine. È un processo continuo di monitoraggio, adattamento, e improvement. Ma con la struttura giusta dal giorno uno, i 16 giorni di dwell time diventano ore. Il breach da 4.45 milioni diventa un near-miss investigato e bloccato. La difference tra architecture fatta bene e architecture fatta per necessity è il costo che paghi quando qualcosa va storto — e quanto recovery costa in tempo, reputation, e denaro.