Esame 2018 Ordinaria - FastDelivery - Soluzione completa | Prof. Giagnotti

SOLUZIONE ESAME 2018 ORDINARIA — SISTEMI E RETI

A cura di Prof. Giagnotti — soluzione completata dove mancava e raccontata in prima persona

Esame 2018 Ordinaria: FastDelivery tracciamento pacchi — Come l'ho risolta io

Traccia tosta perché aperta: QR o RFID? Cloud o on-prem? Io qui vi racconto le scelte che ho fatto io, perché ho scelto AWS ECS + Aurora invece del data center interno, perché per me RFID + QR insieme è più giusto, e come ho gestito GPS, clustering e SPF/DKIM/DMARC. Dove la soluzione originale era sintetica, la completo io.

📅 2018 Ordinaria 📦 FastDelivery — QR/RFID ☁️ AWS ECS + Aurora 📍 GPS MQTT + Email SEC

INDICE — Il mio ragionamento

0. Come ho letto io la traccia FastDelivery 1. Procedura operativa: il mio Codice Pacco Univoco e flusso Voghera→Barletta 2. Infrastruttura: dispositivi che ho scelto io + on-prem vs AWS (scelta cloud) 3. Sicurezza e Business Continuity: RTO/RPO che ho fissato io + DR 4. Quesito I — DB e tracking web: schema che ho completato io + API REST 5. Quesito II — GPS automezzi: MQTT che ho scelto io + protocollo 6. Quesito III — Clustering e virtualizzazione: HA che ho progettato io 7. Quesito IV — Email security: SPF/DKIM/DMARC + S/MIME vs PGP — il mio stack 8. Riepilogo orale

🎙️ Il mio punto di partenza

Io non parto dalla tecnologia, parto dalla domanda: “Se perdo un pacco, dove lo cerco?”. Quindi mi serve un codice univoco non clonabile + ogni passaggio registrato con timestamp + GPS. Se ho questo, poi scelgo QR/RFID/cloud. È il filo che ho seguito io.

0. Come ho letto io la traccia FastDelivery

FastDelivery per me è un corriere nazionale con Sedi Operative (SO) nelle città e Centri di Smistamento Regionale (CSR). Esempio che mi sono immaginato io: pacco da Voghera (SO Lombardia) → CSR Milano → CSR Bari → SO Barletta → consegna. Ogni passaggio deve essere tracciato.

Vincoli che ho isolato io:

Identificazione univoca resistente a manomissioni — io ho scelto formato FD-YYYY-XXXXXX tipo FD-2024-AB7K2M, 14 char, base36, non sequenziale per non essere indovinabile.
Tracciamento real-time presa in carico, transito SO/CSR, consegna — serve app + API + rete sempre connessa + coda offline.
Milioni di pacchi — DB scalabile, io non metterei MySQL su singolo server.
GDPR su mittente/destinatario + continuità operativa — cifratura, MFA, backup, RTO/RPO che devo fissare io.

💡 Scelta aperta che ho dovuto fare io

La traccia non dice QR o RFID, non dice cloud o on-prem. Per me è voluto: devo confrontare e motivare. Io ho scelto QR + RFID insieme (QR per cliente, RFID per varchi automatici) e AWS cloud perché FastDelivery ha picchi stagionali (Natale, Black Friday) — on-prem mi costa 150k + team 24/7, cloud scala da 2 a 20 container e pago solo uso.

1. Procedura operativa: il mio Codice Pacco Univoco e flusso

Io ho pensato così il ciclo di vita del pacco:

Cliente fa richiesta online → sistema genera CPU FD-2024-AB7K2M con UUID v4 dietro, salvo hash.
Stampante termica con encoder RFID stampa etichetta con QR + tag RFID UHF scritto in un passaggio solo.
Trasportatore con smartphone rugged Android IP65, app FastDelivery: scansiona QR, GPS, firma digitale del destinatario, foto consegna, tutto in HTTPS REST POST /spedizioni/{cpu}/eventi con JWT. Se non c'è rete, queue locale SQLite e retry quando torna 4G.
Varco SO/CSR: gate RFID 860-960 MHz legge 500 tag/sec a 3-5m, middleware chiama API centrale via IPSec VPN site-to-site.
Cliente vede tracking web con mappa + stati.

Perché QR + RFID insieme per me è più giusto? QR costa zero e cliente lo legge con telefono. RFID costa ma automatizza varchi senza intervento umano. Insieme copro entrambi i casi.

2. Infrastruttura: dispositivi che ho scelto io + on-prem vs AWS

Dispositivi che ho scelto io:

Ruolo	Dispositivo	Hardware	App
Trasportatore	Smartphone rugged Android	IP65, batteria 12h, GPS, 4G, NFC, camera	App: scan QR, GPS, firma, foto, push, offline mode
Magazziniere	Palmare industriale	Scanner 1D/2D, WiFi ac, IP54	Web responsive + barcode
Varco	Portale RFID UHF	860-960 MHz, 3-5m, 500 tag/sec, PoE	Middleware REST
Etichetta	Stampante termica RFID	Stampa + scrittura tag	Driver gestionale

Comunicazioni che ho deciso io:

Link	Protocollo	Perché così
Trasportatore → server	HTTPS REST TLS 1.3 + JWT	Payload JSON cifrato, retry offline con coda locale — è più giusto così altrimenti perdi eventi se va giù 4G
Magazzino WiFi	WPA2-Enterprise 802.1X, VLAN magazzino 192.168.x.0/24	Isolamento, DNS split
Gate RFID	GbE + VPN IPSec IKEv2 site-to-site SO/CSR→DC	Isolamento fisico da guest
Backup	HTTPS + SSH, replica cross-region	DR offsite

Confronto che ho fatto io on-prem vs cloud:

Ipotesi A — Data center interno (scartata da me)

2 web server + load balancer HW ~€150k + manutenzione, MySQL master-slave + NAS backup RPO 24h RTO 1h, SAN RAID-10 20TB, dual ISP BGP ~€2-3k/mese. Problema per me: scaling difficile con picchi stagionali, team 24/7, DR site costoso.

Ipotesi B — AWS cloud (scelta mia)

ECS Fargate auto-scaling 2-20 istanze (scale to zero notte), Aurora MySQL failover <30s zero RPO, ElastiCache Redis sub-ms, S3 + CloudFront per firme/foto, Route53 + ALB failover <60s, SQS + Lambda per eventi RFID asincroni. Per me elimina 60-70% costi operativi vs on-prem, DR nativo RTO <30s RPO≈0, GDPR ok. Per questo l'ho scelta io.

3. Sicurezza e Business Continuity: RTO/RPO che ho fissato io

Qui completo perché nella soluzione originale RTO/RPO erano solo accennati. Io li fisso così perché sono dati critici ma non salvavita:

RPO (Recovery Point Objective) = 15 minuti — posso perdere max 15 min di eventi tracking. Lo ottengo io con Aurora backup continuo + binlog + SQS persistente.
RTO (Recovery Time Objective) = 1 ora per on-prem, <30s per AWS (failover automatico). Per me è più giusto così: FastDelivery può stare giù 1h senza perdere pacchi, ma oltre diventa danno economico.
Sicurezza: TLS 1.3 ovunque, MFA su account operativi (TOTP), cifratura at-rest AES-256 S3 + RDS encryption, JWT con scadenza breve + refresh token, WAF su ALB, anti-DDoS Shield, audit log immutabile, GDPR DPIA + DPO.
Continuità: io metto queue locale su app trasportatore (SQLite) + SQS centrale, così se rete va giù non perdo evento. Backup 3-2-1: 1 live Aurora, 1 snapshot giornaliero S3, 1 cross-region offsite. Test restore mensile.

4. Quesito I — DB e tracking web: schema che ho completato io

DB che ho progettato io per tracking web cliente:

SQL - SCHEMA CHE HO COMPLETATO IO

-- Io metto CPU come chiave naturale ma uso ID interno per performance
CREATE TABLE SPEDIZIONE (
  id_spedizione INT PRIMARY KEY AUTO_INCREMENT,
  cpu VARCHAR(14) UNIQUE NOT NULL, -- FD-2024-AB7K2M
  mittente_nome VARCHAR(100) NOT NULL,
  mittente_gdpr_hash VARCHAR(255), -- pseudonimizzato per GDPR
  destinatario_nome VARCHAR(100) NOT NULL,
  stato ENUM('in_attesa','ritirata','in_transito','in_consegna','consegnata','giacenza') DEFAULT 'in_attesa',
  data_creazione DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE EVENTO_TRACCIAMENTO (
  id_evento BIGINT PRIMARY KEY AUTO_INCREMENT,
  cpu VARCHAR(14) NOT NULL,
  tipo_evento ENUM('presa_carico','ingresso_SO','uscita_SO','ingresso_CSR','uscita_CSR','tentativo_consegna','consegna','giacenza'),
  id_sede INT, -- SO o CSR
  lat DECIMAL(10,7),
  lon DECIMAL(10,7),
  timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
  operatore_id INT,
  firma_url VARCHAR(500), -- foto firma S3
  FOREIGN KEY (cpu) REFERENCES SPEDIZIONE(cpu)
);

-- Indice che metto io per query tracking cliente veloci
CREATE INDEX idx_cpu_time ON EVENTO_TRACCIAMENTO(cpu, timestamp);

-- API REST che ho pensato io:
-- POST /spedizioni/{cpu}/eventi {tipo, sede, lat, lon, firma}
-- GET /spedizioni/{cpu}/tracking -> lista eventi ordinati

Tracking web: pagina pubblica /tracking/{cpu} con timeline + mappa Leaflet con lat/lon eventi. Per me niente auth per tracking base (solo CPU), ma dati mittente/destinatario oscurati per GDPR.

5. Quesito II — GPS automezzi: MQTT che ho scelto io

Qui la soluzione originale diceva solo “GPS”. Io la completo perché per me serve protocollo leggero:

Device: tracker GPS su furgoni con 4G, invio ogni 30s posizione.
Protocollo che ho scelto io: MQTT — leggero, pub/sub, QoS 1, topic fastdelivery/fleet/{id_furgone}/position payload JSON {lat,lon,speed,timestamp}. Perché MQTT e non HTTP? Perché HTTP fa 3-way handshake ogni volta, MQTT mantiene connessione persistente, consuma 10x meno batteria/dati, e ha retained message.
Broker: AWS IoT Core o Mosquitto cluster, con TLS + cert client per ogni furgone.
Backend: consumer Lambda che salva su DynamoDB/TimeStream + Redis per posizione real-time + dashboard con WebSocket.
Geofencing: io metto alert se furgone entra/esce da SO/CSR — trigger evento automatico “ingresso_SO” senza scansione manuale.

6. Quesito III — Clustering e virtualizzazione: HA che ho progettato io

Io qui ho pensato a due livelli:

Virtualizzazione: ECS Fargate già è container orchestrato, ma se fossi on-prem userei Proxmox/KVM o VMware ESXi con cluster 3 nodi + vMotion/live migration.
Clustering DB: Aurora MySQL con 1 writer + 2 reader in AZ diverse, failover automatico <30s. Se on-prem, MySQL Galera cluster 3 nodi synchronous.
Load balancer: ALB con health check /health ogni 5s, se istanza non risponde la toglie. Sticky session disabilitate perché uso Redis per sessioni — così posso scalare senza problemi.
Auto-scaling che ho fissato io: CPU >70% per 2 min → scala +2 istanze, CPU <30% per 10 min → scala -1. Min 2, max 20. Di notte scala a 2 (scale to zero non totale per tenere API viva).

7. Quesito IV — Email security: SPF/DKIM/DMARC + S/MIME vs PGP — il mio stack

Questa parte era carente, la completo io come la spiego in classe:

Layer 1 — Autenticazione mittente (DNS) che ho configurato io:

Record	Cosa fa	Il mio valore
SPF	Chi può inviare per @fastdelivery.it	v=spf1 include:_spf.google.com include:amazonses.com -all — solo Google e SES autorizzati, resto reject
DKIM	Firma crittografica ogni email	Selettore s1._domainkey con chiave 2048 bit, rotazione ogni 6 mesi
DMARC	Policy se SPF/DKIM falliscono	v=DMARC1; p=reject; rua=mailto:dmarc@fastdelivery.it; pct=100 — reject diretto, non quarantine, per me più giusto così
MTA-STS	Forza TLS tra MTA	Enforce, previene downgrade TLS

Layer 2 — Trasporto: STARTTLS obbligatorio su 587, SMTPS 465, IMAPS 993, POP3S 995, nessun plaintext. Io disabilito TLS 1.0/1.1, solo 1.2+.

Layer 3 — Contenuto end-to-end che ho scelto io:

Standard	Meccanismo	Quando lo uso io
S/MIME	Cert X.509, firma + cifratura, integrato Outlook/Apple Mail	Email legali/finanziarie — lo impongo io come obbligatorio per fatture, contratti
PGP/OpenPGP	Web of Trust, keyserver	Comunità tech/open-source, meno integrato enterprise, per me sconsigliato in azienda

🎯 Stack finale che ho messo io in produzione

DNS: SPF + DKIM + DMARC p=reject per tutti i domini. SMTP: STARTTLS obbligatorio, MTA-STS. Client: IMAPS 993, anti-spam cloud (Google Workspace o M365 Defender). Email critiche: S/MIME firma obbligatoria. MFA su tutti gli account email con TOTP/security key. Training anti-phishing periodico con simulazioni — perché per me l'anello debole è sempre l'utente.

8. Riepilogo orale

✓QR + RFID insieme — l'ho scelto io perché QR costo zero per cliente, RFID automatizza varchi. Non uno o l'altro, entrambi.

✓AWS vs on-prem: io ho scelto cloud perché picchi stagionali, 60-70% costi operativi in meno, RTO <30s RPO≈0 nativo, scala 2-20.

✓RTO 1h / RPO 15min che ho fissato io — con queue locale SQLite su app + SQS centrale non perdo eventi.

✓GPS MQTT — l'ho scelto io perché leggero, persistente, QoS 1, 10x meno dati di HTTP, con geofencing automatico.

✓Email: SPF/DKIM/DMARC p=reject + S/MIME — per me p=reject è più giusto di quarantine, e S/MIME meglio di PGP in azienda.

📚 Come la porto io all'orale

Io parto dal codice pacco FD-YYYY-XXXXXX e dal flusso Voghera→Barletta, spiego perché QR+RFID insieme, poi confronto on-prem vs AWS con numeri (150k vs pay-per-use) e dico perché ho scelto cloud. Poi RTO/RPO che ho fissato io, GPS MQTT con geofencing, clustering Aurora, e chiudo con SPF/DKIM/DMARC reject + S/MIME. È il mio filo e secondo me funziona.