Traccia B – Catena di hotel con prenotazioni online

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

🖧 CLICCA QUI — Diagramma di Rete Interattivo

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:

📌 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)

🌐 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

🔒 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