Soluzione Completa Traccia B

Catena di Hotel con Prenotazioni Online

Schema di rete, DMZ, isolamento reti e sicurezza PCI-DSS

📊 Panoramica della Soluzione

Contesto: 12 hotel + 1 sede centrale a Milano

Rete assegnata: 192.168.0.0/16

Requisiti per hotel: 3 reti completamente isolate: gestionale (15 host), Wi-Fi ospiti (100 host), videosorveglianza (20 telecamere)

Dati critici: Prenotazioni online, database clienti, pagamenti (PCI-DSS)

Architettura chiave: DMZ per server pubblici, VPN per hotel, isolamento reti guest



📝 Ipotesi Aggiuntive e Schema di Rete

🏨 Ipotesi Aggiuntive Formulate

📍 Struttura Hotel

Ogni hotel ha: 1 router/firewall, 2 switch managed (uno per rete gestionale/videosorveglianza, uno per Wi-Fi ospiti), Access Point enterprise per Wi-Fi ospiti.

💳 Sistema Pagamenti

Il sito di prenotazione integra gateway di pagamento esterno (es: Stripe, PayPal). I dati delle carte NON transitano sui server dell’hotel (PCI-DSS compliance).

🌐 Collegamenti

La sede centrale ha collegamento Internet fibra business con IP pubblici statici. Ogni hotel ha connessione Internet dedicata con IP pubblico.

🛡️ Ipotesi di Sicurezza Critiche

1. Il database clienti è separato fisicamente dal server web, in rete interna protetta da firewall

2. Accesso al database solo da applicazione server web, non direttamente da Internet

3. Rete Wi-Fi ospiti completamente isolata: no accesso a rete gestionale, solo Internet

4. Sistema di videosorveglianza su rete dedicata, accessibile solo da postazioni autorizzate

5. Backup crittografati giornalieri con retention di 30 giorni on-site + 1 anno off-site

🏗️ Schema di Rete Complessivo

🌍 INTERNET

IP Pubblici: 95.100.50.0/29

↓

🔥 FIREWALL SEDE CENTRALE

Zone: Internet • DMZ • Rete Interna • VPN Hotel

F

🛡️ ZONA DMZ

Server Web

192.168.0.10/28
prenotazioni.hotel.it

Server Mail

192.168.0.11/28
mail.hotel.it

🏢 RETE INTERNA

Database Clienti

192.168.0.50/28
Accesso solo da DMZ

Server Backup

192.168.0.60/28
Backup crittografati

PC Amministrativi

192.168.0.65-90/28
Uffici sede centrale

🏨 VPN HOTEL (12 sedi)

Hotel Milano Centrale

192.168.1.0/22
VPN IPsec tunnel

Hotel Roma Termini

192.168.2.0/22
VPN IPsec tunnel

Hotel Napoli Mare

192.168.3.0/22
VPN IPsec tunnel

↓ ↑

🏨 HOTEL TIPICO – Struttura

🔥 Firewall Hotel

WAN: IP pubblico ISP
LAN: 3 reti separate

🔀 3 Reti Isolate

GESTIONALE

15 host

WI-FI OSPITI

100 host

TELEGAMERE

20 host

📌 Legenda dello Schema:

DMZ (Demilitarized Zone)

Rete Interna Protetta

VPN Site-to-Site

Hotel Remoti



📐 Parte 1 — Piano di Indirizzamento IP

🧮 Ragionamento sul Subnetting

Dati di partenza:

  • Rete assegnata: 192.168.0.0/16 (65.534 host totali)
  • Numero hotel: 12 + 1 sede centrale = 13 “siti”
  • Reti per hotel: 3 completamente isolate (gestionale, Wi-Fi ospiti, videosorveglianza)
  • Requisiti per hotel:
    • Gestionale: ~15 dispositivi
    • Wi-Fi ospiti: fino a 100 dispositivi simultanei
    • Videosorveglianza: 20 telecamere + server NVR

Decisioni di progetto:

  1. Assegnare a ogni hotel un blocco /22 (1.022 host) → sufficiente per tutte e 3 le reti con ampio margine
  2. All’interno di ogni /22, creare 3 subnet:
    • Gestionale: /26 (62 host) per ~15 dispositivi + crescita
    • Wi-Fi ospiti: /25 (126 host) per fino a 100 dispositivi + margine
    • Videosorveglianza: /27 (30 host) per 20 telecamere + server
  3. La sede centrale ottiene il primo blocco /24 (192.168.0.0/24) con ulteriore suddivisione in:
    • DMZ per server pubblici: /28 (14 host)
    • Rete interna per database e uffici: /28 (14 host) + /27 (30 host)
    • Server backup: /28 dedicato

💡 Nota sull’isolamento reti:

Le 3 reti di ogni hotel devono essere completamente isolate. Questo si ottiene con:
VLAN separate + firewall rules che bloccano il traffico inter-VLAN per la rete Wi-Fi ospiti.
Le reti gestionale e videosorveglianza possono comunicare tra loro sotto controllo firewall.

📋 Tabella del Piano di Indirizzamento

Piano completo per i primi 3 hotel (esemplificativi) e la sede centrale:

Sede Rete / Funzione Subnet CIDR Host utili Gateway Note
Sede Centrale
Milano		 DMZ – Server Web 192.168.0.0 /28 14 192.168.0.1 Accessibile da Internet
→ Server Web 192.168.0.10 /32 1 192.168.0.1 prenotazioni.hotel.it
→ Server Mail 192.168.0.11 /32 1 192.168.0.1 mail.hotel.it
Rete Interna – Database 192.168.0.16 /28 14 192.168.0.17 Isolata, solo da DMZ
Rete Interna – Uffici 192.168.0.32 /27 30 192.168.0.33 PC amministrativi
Server Backup 192.168.0.64 /28 14 192.168.0.65 Backup crittografati
Hotel 1
Milano Centrale		 Blocco assegnato 192.168.1.0 /22 1022 — Intero hotel
VLAN 10 – Gestionale 192.168.1.0 /26 62 192.168.1.1 Reception, uffici
VLAN 20 – Wi-Fi Ospiti 192.168.1.64 /25 126 192.168.1.65 Completamente isolata
VLAN 30 – Videosorveglianza 192.168.1.192 /27 30 192.168.1.193 Telecamere IP + NVR
Hotel 2
Roma Termini		 Blocco assegnato 192.168.2.0 /22 1022 — Intero hotel
VLAN 10 – Gestionale 192.168.2.0 /26 62 192.168.2.1 Reception, uffici
VLAN 20 – Wi-Fi Ospiti 192.168.2.64 /25 126 192.168.2.65 Completamente isolata
VLAN 30 – Videosorveglianza 192.168.2.192 /27 30 192.168.2.193 Telecamere IP + NVR
Hotel 3
Napoli Mare		 Blocco assegnato 192.168.3.0 /22 1022 — Intero hotel
VLAN 10 – Gestionale 192.168.3.0 /26 62 192.168.3.1 Reception, uffici
VLAN 20 – Wi-Fi Ospiti 192.168.3.64 /25 126 192.168.3.65 Completamente isolata
VLAN 30 – Videosorveglianza 192.168.3.192 /27 30 192.168.3.193 Telecamere IP + NVR
Hotel 4-12: seguono lo schema con blocchi 192.168.4.0/22 … 192.168.15.0/22

📌 Note importanti:

  • Isolamento Wi-Fi ospiti: La VLAN 20 non ha route verso le altre VLAN (né locali né remote). Solo traffico verso Internet tramite NAT.
  • Gateway: Ogni subnet ha il primo indirizzo utile come gateway (es: .1 per /26, .65 per /25, .193 per /27)
  • DMZ vs Rete Interna: La DMZ ha indirizzi IP nella stessa rete 192.168.0.0/24 ma è separata fisicamente/logicamente dal firewall
  • Database isolato: Il database clienti (192.168.0.16/28) è raggiungibile SOLO dal server web in DMZ (porta 3306), non da Internet



🏰 Parte 3 — DMZ e Architettura di Sicurezza

🛡️ Architettura DMZ Dettagliata

La DMZ (Demilitarized Zone) è una rete semi-fidata tra Internet e la rete interna. Contiene i server accessibili da Internet ma isolati dalla rete interna.

🌍 INTERNET

Clienti, Ospiti

→

🔥 FIREWALL

Palo Alto / FortiGate

ZONE

→

🛡️ ZONA DMZ

Server Web

192.168.0.10

→

🏢 RETE INTERNA

Database

192.168.0.50

📋 Regole Firewall (Esempio)

Da A Servizio Azione Note
Internet DMZ HTTP (80), HTTPS (443) PERMIT Accesso sito web
Internet DMZ SMTP (25), SMTPS (465) PERMIT Server mail
DMZ Rete Interna MySQL (3306) PERMIT Solo server web → DB
Internet Rete Interna ANY DENY Nessun accesso diretto
DMZ Internet DNS (53), NTP (123) PERMIT Server escono per servizi

🌐 Server Web (DMZ)

  • IP: 192.168.0.10/28
  • DNS: prenotazioni.hotel.it
  • Servizi: Apache/Nginx + PHP, WordPress
  • Sicurezza: WAF, HTTPS, aggiornamenti automatici
  • Accesso DB: Solo verso 192.168.0.50:3306

🗄️ Database Clienti (Rete Interna)

  • IP: 192.168.0.50/28
  • DBMS: MySQL 8.0 / PostgreSQL
  • Sicurezza: Crittografia at-rest (AES-256)
  • Accesso: Solo da IP 192.168.0.10 (server web)
  • Backup: Giornaliero crittografato

📧 Server Mail (DMZ)

  • IP: 192.168.0.11/28
  • DNS: mail.hotel.it, MX record
  • Servizi: Postfix + Dovecot
  • Sicurezza: TLS obbligatorio, SPF, DKIM, DMARC
  • Antispam: Rspamd / SpamAssassin

🔄 Flusso di una Prenotazione Online

1

Cliente visita sito

https://prenotazioni.hotel.it → Firewall permette 443 → Server Web DMZ

2

Inserimento dati

Cliente inserisce: nome, email, date, numero carta (se pagamento)

3

Pagamento (PCI-DSS)

JavaScript invia dati carta DIRECTAMENTE a gateway di pagamento (Stripe/PayPal). I dati NON passano sui nostri server.

4

Salvataggio prenotazione

Server Web → Firewall permette 3306 → Database salva: nome, email, date (NO dati carta)

5

Conferma email

Server Web → Server Mail invia email conferma. Firewall permette SMTP tra DMZ server.

🎯 Vantaggi architettura DMZ:

  • Sicurezza: Se il server web viene compromesso, l’attaccante è confinato nella DMZ
  • Isolamento: Il database è protetto nella rete interna, accessibile solo dal server web
  • PCI-DSS compliance: I dati delle carte di credito NON transitano sui nostri server
  • Controllo: Tutto il traffico passa attraverso il firewall con regole granulari



🏨 Parte 4 — Isolamento Reti negli Hotel

🔐 Schema di Isolamento Reti per Hotel

Ogni hotel ha 3 reti completamente isolate. Ecco lo schema dettagliato:

🔥 FIREWALL HOTEL (UTM)

Interfacce: WAN (Internet), LAN1 (Gestionale), LAN2 (Wi-Fi Ospiti), LAN3 (Videosorveglianza)

F

🏢 RETE GESTIONALE

Switch VLAN 10

Porte: Reception, Uffici, Stampanti

PC Reception

192.168.x.10-25
Software gestionale

▶ Accesso: VPN a sede, Internet (filtro), altre reti hotel

📶 WI-FI OSPITI

Access Point Enterprise

SSID: Hotel-Guest
Captive Portal

Dispositivi Ospiti

Smartphone, Tablet, Laptop
DHCP su 192.168.x.65-190

⛔ Accesso: SOLO Internet. NO altre reti, NO tra ospiti

📹 VIDEOSORVEGLIANZA

Switch VLAN 30

Porte: Telecamere IP, Server NVR

Server NVR

192.168.x.200
Registrazione 30 giorni

🔒 Accesso: Solo da rete gestionale, NO da Internet, NO da Wi-Fi

📋 Regole di Isolamento sul Firewall Hotel

Sorgente Destinazione Servizio Azione Motivazione
Wi-Fi Ospiti Internet HTTP, HTTPS, DNS PERMIT Navigazione web base
Wi-Fi Ospiti Gestionale ANY DENY Isolamento sicurezza
Wi-Fi Ospiti Videosorveglianza ANY DENY Privacy telecamere
Wi-Fi Ospiti Altri Ospiti ANY DENY Isolamento client-to-client
Gestionale Sede Centrale HTTPS, VPN PERMIT Accesso a sistema centrale
Gestionale Videosorveglianza HTTP, RTSP PERMIT Monitoraggio telecamere

🔒 Isolamento Fisico/Logico

  • Switch separati o VLAN con tagging 802.1Q
  • Interfacce firewall separate per ogni rete
  • Regole firewall che bloccano traffico inter-VLAN per Wi-Fi ospiti
  • Client isolation sugli Access Point per Wi-Fi ospiti

📡 Captive Portal Wi-Fi Ospiti

  • Pagina di benvenuto con termini e condizioni
  • Limite di tempo (es: 24 ore) o dati (es: 2GB)
  • Registrazione opzionale (nome, email, camera)
  • Content filtering (blocco siti non appropriati)
  • Bandwidth shaping (limite velocità per ospite)

🔐 Sicurezza Videosorveglianza

  • Rete dedicata senza accesso a Internet
  • Credenziali forti su telecamere e NVR
  • Firmware aggiornato regolarmente
  • Accesso solo da rete gestionale (reception/ufficio)
  • Backup registrazioni su NAS separato

🔗 VPN Site-to-Site per Collegamento Hotel

🌉 Tunnel VPN IPsec

Tra firewall hotel e firewall sede centrale. Cifratura AES-256, autenticazione con certificati digitali.

🎯 Traffico nella VPN

Solo rete gestionale (192.168.x.0/26) → sede centrale. Wi-Fi ospiti e videosorveglianza RESTANO locali.

📊 Monitoraggio VPN

SNMP monitoring, alert in caso di tunnel down, log di tutte le connessioni.

🎯 Vantaggi dell’isolamento:

  • Sicurezza: Un ospite malintenzionato non può accedere alla rete gestionale o alle telecamere
  • Performance: Il traffico degli ospiti non interferisce con quello gestionale
  • Compliance: Isolamento richiesto da standard di sicurezza e privacy
  • Scalabilità: Facile aggiungere nuovi hotel senza modificare l’architettura



🛡️ Parte 4 — Sicurezza Dati e Compliance

⚖️ Misure per GDPR e PCI-DSS

📜 Compliance GDPR per Dati Clienti

🔐 Crittografia Dati

  • In transito: HTTPS TLS 1.3, VPN IPsec
  • A riposo: Database cifrato (AES-256), backup cifrati
  • Email: TLS forzato per SMTP

📝 Gestione Consensi

  • Checkbox esplicita per privacy policy
  • Registro trattamenti aggiornato
  • DPO (Data Protection Officer) nominato
  • Diritti interessati facilmente esercitabili

🗄️ Retention e Cancellazione

  • Politica di retention: Dati prenotazioni: 5 anni
  • Cancellazione sicura allo scadere
  • Backup con retention separata
  • Diritto all’oblio implementato

📋 Dati Personali Trattati:

Nome e Cognome

Dati identificativi

Email e Telefono

Dati di contatto

N° Documento

Dati identificativi ufficiali

Date Soggiorno

Dati transazionali

💳 Compliance PCI-DSS per Pagamenti

⚠️ IMPORTANTE: I dati delle carte di credito NON transitano sui nostri server.

Utilizziamo un gateway di pagamento esterno (Stripe, PayPal, Braintree) che gestisce direttamente i dati delle carte. Questo riduce drasticamente il scope PCI-DSS.

🛡️ Architettura Sicura

  • Tokenizzazione: Il gateway restituisce un token, non il PAN
  • Iframe/Redirect: Il cliente inserisce i dati direttamente sul sito del gateway
  • JavaScript SDK: Dati inviati direttamente al gateway, bypassando i nostri server

📋 Scope Ridotto PCI-DSS

  • SAQ A: Self-Assessment Questionnaire tipo A (più semplice)
  • Nessun PAN storage: Non memorizziamo numeri di carte
  • Vulnerability scanning: Solo server web in DMZ
  • Penetration test: Annuale sul sito web

🔄 Flusso Pagamento PCI-DSS Compliant:

  1. Cliente clicca “Paga ora” sul nostro sito
  2. Si apre iframe/redirect al sito del gateway di pagamento (es: checkout.stripe.com)
  3. Cliente inserisce dati carta NEL iframe del gateway (HTTPS diretto)
  4. Gateway processa il pagamento e restituisce al nostro server solo token di transazione
  5. Il nostro server salva il token (non la carta) e conferma la prenotazione
  6. Per rimborsi/annullamenti: usiamo il token per richiedere operazioni al gateway

💾 Strategia Backup e Disaster Recovery

🔄 Backup Database

  • Completo: Giornaliero notturno (02:00)
  • Incrementale: Ogni 4 ore (06, 10, 14, 18, 22)
  • Crittografia: AES-256 at-rest e in-transit
  • Destinazioni: NAS locale + cloud (S3 compatibile)

📊 Retention Policy

  • Giornalieri: Conservati per 30 giorni
  • Settimanali: (domenica) conservati per 12 settimane
  • Mensili: (ultimo del mese) conservati per 12 mesi
  • Annuali: (31 dicembre) conservati per 7 anni

🚨 Disaster Recovery

  • RTO: 4 ore (Time to Recovery)
  • RPO: 1 ora (Point in Time Recovery)
  • Sito DR: Cloud provider alternativo
  • Test DR: Semestrale (simulazione)

📈 Monitoraggio e Alerting:

Nagios/Zabbix

Monitoraggio server e servizi

ELK Stack

Log centralizzati e analisi

PRTG

Monitoraggio rete e bandwidth

Alert via SMS/Email

Notifiche immediate problemi critici



📝 Seconda Parte — Soluzioni ai Quesiti

🎯 Soluzione ai 2 Quesiti Scelti

I. Wi-Fi Ospiti con Captive Portal

Soluzione: Implementazione di rete Wi-Fi ospiti con captive portal, content filtering e limitazione bandwidth.

🏗️ Architettura del Sistema:

📶 Access Point

SSID: Hotel-Guest
VLAN 20 isolata

→

🔥 Firewall Hotel

Redirect HTTP a captive portal
Isolamento client-to-client

→

🌐 Server Captive Portal

192.168.x.200
Gestione sessioni, termini

🗄️ Database Sessioni

Registro accessi
Scadenza sessioni

→

🔧 Content Filter

Blocco categorie
DNS filtering

→

📊 Bandwidth Shaper

Limite 5 Mbps/ospite
Priorità gestionale

→

🌍 Internet

NAT overload
Solo traffico autorizzato

🔄 Flusso di Connessione Ospite:

  1. Connessione Wi-Fi: Ospite si connette a SSID “Hotel-Guest”, ottiene IP via DHCP (192.168.x.65-190)
  2. Captive Portal: Qualsiasi richiesta HTTP viene reindirizzata a https://wifi.hotel.local/portal
  3. Pagina Termini: Ospite vede pagina con logo hotel, termini e condizioni, politica privacy
  4. Accettazione: Ospite inserisce (opzionale): nome, numero camera, accetta termini
  5. Autorizzazione: Il captive portal registra la sessione nel database, notifica il firewall di autorizzare l’IP
  6. Navigazione: L’ospite ora può navigare, con limiti di banda e content filtering attivi
  7. Scadenza: Dopo 24 ore o disconnessione, la sessione scade e deve riautenticarsi

✅ Vantaggi

  • Termini e condizioni legalmente vincolanti
  • Marketing: raccolta email (opt-in)
  • Monitoraggio utilizzo Wi-Fi
  • Prevenzione abuso (limitazioni)

⚙️ Configurazioni Tecniche

  • Session timeout: 24 ore
  • Bandwidth limit: 5 Mbps download / 2 Mbps upload per dispositivo
  • Max dispositivi per ospite: 3
  • Content filter: blocca categorie inappropriate

🛡️ Sicurezza

  • HTTPS per captive portal
  • Isolamento client-to-client
  • Firewall blocca porte pericolose
  • Log di tutte le connessioni

III. Alta Disponibilità Server Prenotazioni

Soluzione: Implementazione di cluster attivo-attivo con load balancer, database replication e failover automatico.

⚖️ LOAD BALANCER (HAProxy)

VIP: 192.168.0.10, Health checks, SSL termination

🖥️ Server Web 1

IP: 192.168.0.11

Apache + PHP, Session sticky

Stato: ⬤ Attivo

Carico: 45%

🖥️ Server Web 2

IP: 192.168.0.12

Apache + PHP, Session sticky

Stato: ⬤ Attivo

Carico: 40%

🗄️ Database Cluster

Master

192.168.0.50
Scritture

Slave 1

192.168.0.51
Replica sincrona

Slave 2

192.168.0.52
Replica asincrona

🔄 Load Balancing

  • Algoritmo: Round-robin con peso
  • Health checks: HTTP GET /health ogni 10 secondi
  • SSL termination: Sul load balancer
  • Sticky sessions: Cookie-based session persistence

🗄️ Database Replication

  • Master-Slave: Replicazione binlog
  • Failover automatico: Usando Orchestrator
  • Backup da slave: Senza impatto su master
  • Read replicas: Web server leggono da slave

🚨 Failover & Recovery

  • RTO: < 2 minuti (web), < 5 minuti (DB)
  • Monitoraggio: Nagios con alerting
  • Failover test: Trimestrale
  • DR site: Cloud standby (AWS/Azure)

🔧 Scenari di Failover:

Server Web 1 si guasta

Load balancer rileva tramite health check, rimuove dal pool. Traffico tutto su Server 2. Notifica a sysadmin.

Database Master si guasta

Orchestrator promuove Slave 1 a nuovo Master. Web server riconfigurati per puntare al nuovo Master. Tempo: < 5 min.

Load Balancer si guasta

VRRP (Virtual Router Redundancy Protocol) con standby LB prende il VIP. Tempo: < 30 secondi.



🎯 Riepilogo della Soluzione

🏗️ Architettura

DMZ per server pubblici, rete interna protetta, VPN per hotel, 3 reti isolate per hotel

🔐 Isolamento

Wi-Fi ospiti completamente isolato, no accesso a rete gestionale o videosorveglianza

⚖️ Compliance

GDPR per dati clienti, PCI-DSS tramite gateway esterno, no dati carte sui nostri server

💾 Disaster Recovery

Backup crittografati, replica database, alta disponibilità server, RTO 4 ore

Note per l’esame: Questa soluzione dimostra padronanza di concetti avanzati: DMZ, isolamento reti, compliance normativa. All’esame, enfatizza gli schemi di rete e le misure di sicurezza specifiche. Spiega sempre PERCHÉ si isolano le reti (sicurezza, privacy, compliance).

Prossima soluzione: Traccia C — Azienda Manifatturiera con IoT

Contesto: industria 4.0 | Difficoltà: ⭐⭐⭐ | Focus: IoT security, VLAN isolation, VPN site-to-site

Torna in alto