📦 Sistemi e Reti · Informatica
2018 — Sessione Ordinaria
Avanzato
Soluzione completa
FastDelivery — tracciamento pacchi
Sistema di tracciamento nazionale con QR/RFID, infrastruttura cloud AWS, REST API, sicurezza GDPR, GPS tracking automezzi. Tutti e 4 i quesiti della seconda parte.
Prima Parte
Traccia originale — Ministero dell’Istruzione
Prima e Seconda Parte · Sessione Ordinaria 2018
// testo ufficiale
Riportato per comodità di consultazione.START
Lettura e Analisi della Traccia
Scenario · Requisiti · Output
Scenario operativo
FastDelivery è un corriere nazionale che opera tramite Sedi Operative (SO) dislocate nelle città italiane e Centri di Smistamento Regionale (CSR) per gestire il trasporto interregionale. Esempio di percorso: un pacco da Voghera (Lombardia) verso Barletta (Puglia) viene ritirato dalla SO di Voghera, inoltrato al CSR di Milano, poi al CSR di Bari, e infine alla SO di Barletta per la consegna.
Sfide tecniche da affrontare
| Sfida | Vincolo | Impatto |
|---|---|---|
| Identificazione univoca | Ogni pacco deve avere un codice non duplicabile, resistente a manomissioni | Determinare il formato (UUID, QR code, RFID) e come generarlo |
| Tracciamento in tempo reale | Presa in carico, transito per SO/CSR, consegna devono essere registrate istantaneamente | Infrastruttura IT con API, dispositivi mobili, rete connessa |
| Consistenza dati | Milioni di pacchi in movimento simultaneamente; ogni evento va verificato | DB scalabile, ridondanza, backup |
| Sicurezza e continuità | Dati personali mittente/destinatario (GDPR), criticità operativa se sistema cade | Cifratura, autenticazione, fault tolerance, RTO/RPO |
Tre ipotesi da sviluppare nella prima parte
- Procedura operativa: come sono acquisiti i dati, come identificato il pacco, come tracciato in ogni passaggio
- Infrastruttura IT: dispositivi (trasportatori, magazzinieri), comunicazioni (rete, protocolli), server (on-prem vs cloud)
- Sicurezza e continuità: protezione dati, autenticazione, disaster recovery, vincoli RTO/RPO
// decisioni progettuali da fare
La traccia non specifica se usare QR code, RFID, o NFC. Né se ricorrere a cloud (AWS, Azure) o data center interno. Queste scelte aperte sono il punto centrale: il candidato deve motivare le ipotesi, confrontare almeno due alternative (es. on-prem vs cloud), e giustificare la scelta.01
Quesito 1 — Procedura operativa di tracciamento
Identificazione · Acquisizione dati · Flusso di vita del pacco
Identificazione univoca del pacco
Ogni pacco riceve un Codice Pacco Univoco (CPU) generato al momento della richiesta online dal cliente. Formato proposto: FD-YYYY-XXXXXX (es. FD-2024-AB7K2M) — 14 caratteri alfanumerici univoci su scala nazionale.
// QR Code (supporto primario)
- Stampato su etichetta del pacco
- Leggibile da smartphone trasportatori
- Include URL tracking + CPU cifrato
// RFID (supporto secondario)
- Tag passivo ISO 14443 HF 13.56 MHz
- Lettura automatica ai varchi SO/CSR
- Zero contatto fisico richiesto
- Gateway RFID alle entrate/uscite
Ciclo di vita del pacco — flusso di tracciamento
| # | Fase | Attore | Evento registrato | Dati acquisiti |
|---|---|---|---|---|
| 0 | Richiesta online | Cliente mittente | Form web con dati mittente/destinatario | CPU, timestamp, percorso calcolato da algoritmo |
| 1 | Presa in carico SO-A | Trasportatore | Scansione QR via app smartphone | Timestamp, GPS, stato=IN_TRANSITO |
| 2 | Ingresso SO-A magazzino | Gate RFID automatico | Lettura tag al varco entrata | Timestamp ingresso, posizione magazzino |
| 3 | Uscita SO-A → CSR | Magazziniere | Scan barcode su bancale di spedizione | Timestamp uscita, ID mezzo, CSR destinazione |
| 4 | Transito CSR | Gate RFID + smistamento | Lettura automatica ai nastri trasportatori | Ingresso CSR, uscita CSR, corsia smistamento |
| 5 | Ricezione SO-B | Gate RFID | Lettura tag al varco SO destinazione | Timestamp ricezione, posizione magazzino |
| 6 | Consegna finale | Trasportatore | Scansione QR + firma digitale destinatario | Timestamp, firma, foto opzionale, GPS, stato=CONSEGNATO |
Acquisizione dati mittente e destinatario (GDPR-compliant)
// conformità GDPR (Regolamento UE 2016/679)
Al momento della richiesta online, il mittente fornisce consenso esplicito al trattamento dei dati personali. I dati sono:
• Memorizzati cifrati (AES-256 at-rest) nel database
• Trasmessi su HTTPS TLS 1.3 (in transit)
• Conservati per 5 anni (obblighi fiscali) con diritto alla cancellazione su richiesta
• Separati per ruolo: il destinatario riceve notifica con link tracking ma senza dati del mittente
02
Quesito 2 — Infrastruttura informatica
Dispositivi · Comunicazioni · Confronto on-prem vs cloud
2a — Dispositivi per trasportatori e magazzinieri
| Ruolo | Dispositivo | Hardware | Software/App |
|---|---|---|---|
| Trasportatore | Smartphone rugged Android | IP65, batteria 12h, GPS, 4G LTE, NFC, fotocamera | App FastDelivery: scansione QR, GPS, firma digitale, notifiche push, mode offline |
| Magazziniere SO/CSR | Palmare industriale | Scanner 1D/2D, WiFi 802.11ac, touchscreen, IP54 | Client web responsive + lettore codice barcode/QR |
| Gate RFID varco | Portale RFID UHF | Lettore 860–960 MHz, range 3–5 m, 500 tag/sec, PoE | Middleware RFID con API REST al sistema centrale |
| Stampante etichette | Stampante termica con encoder RFID | Stampa + scrittura tag in passaggio singolo | Driver integrato nel gestionale |
2b — Modalità di comunicazione
| Collegamento | Protocollo | Dettaglio |
|---|---|---|
| Trasportatore → server | HTTPS REST API (TLS 1.3) | POST /spedizioni/{cpu}/eventi. Bearer JWT(Json Web Token) per auth. Payload JSON cifrato. Retry offline con queue locale per permettere di salvare le operazioni in locale offline e sincronizzarle quando la rete torna disponibile. |
| Magazzino WiFi | WPA2-Enterprise 802.1X | VLAN dedicata magazzino. Rete 192.168.x.0/24 locale. DNS split che permette di utilizzare lo stesso nome di dominio per accedere alle risorse sia dall’ufficio (IP privato) che da fuori (IP pubblico). |
| Gate RFID | GbE cablato + rete locale | Isolamento fisico dalla rete guest. Connessione a API server via tunnel VPN site-to-site SO/CSR→data center. |
| SO/CSR → server centrale | IPSec IKEv2 VPN | Tunnel site-to-site per traffico interno. Endpoint per ogni SO/CSR. Failover automatico su rottura tunnel. |
| Backup / Replicazione | HTTPS + SSH | Replica DB master-slave. Backup incrementali notturni. Cross-region offsite che consiste nell’ archiviare dati, sistemi o backup in una posizione geografica diversa rispetto alla regione principale di produzione. |
2c — Architettura server: confronto on-premise vs cloud
// IPOTESI A: DATA CENTER INTERNO
| Componente | Soluzione | Costo/nota |
|---|---|---|
| Web server | 2× con load balancer HW | ~€150k + manutenzione |
| Database | MySQL 8 master-slave su 2 server + NAS backup | RPO (Recovery Point Objective) max 24h, RTO (Recovery Time Objective) ~1h |
| Storage | SAN (Storage Area Network) con RAID-10, 20 TB raw | Scaling manuale, costo incrementale |
| Connectivity | Dual ISP con BGP failover, rack datacenter proprietario | ~€2-3k/mese |
| Problema | Scaling difficile con traffico stagionale; team IT 24/7; DR site (disaster Recovery) aggiuntivo costoso | |
// IPOTESI B: AWS CLOUD (SCELTA CONSIGLIATA ✓)
| Servizio AWS | Uso | Vantaggio |
|---|---|---|
| ECS (Elastic Container Service) + Fargate | Container API REST (auto-scaling 2–20 istanze) | Scale to zero di notte (risparmio se non c’è attività), paghi solo quello che usi |
| Aurora MySQL | DB managed | Failover < 30s, backup automatici, Zero RPO |
| ElastiCache Redis | Cache sessioni + rate limiting | Sub-ms latency per letture frequenti |
| S3 + CloudFront | Firme digitali, foto consegna, gestione asset statici | Scalabilità illimitata |
| Route 53(DNS) + ALB (Application Load Balancer) | DNS + load balancer | Failover DNS < 60s, health check automatici |
| SQS (Simple Queue Service) + Lambda | Code eventi RFID + processing asincrono | Rendono il sistema totalmente resiliente e gestiscono il traffico in modo asincrono, evitando di perdere dati durante il failover |
Motivazione della scelta cloud: FastDelivery ha picchi stagionali prevedibili (festività, Black Friday). Il cloud elimina circa il 60–70% di costi operativi rispetto a on-prem. Disaster recovery nativo (RTO <30s, RPO≈0). Conformità GDPR.
// TOPOLOGIA DELLA RETE PARZIALE: Rappresentazione di rete domestica, tablet trasportatore, un SO e un CSR
03
Quesito 3 — Sicurezza e business continuity
Minacce · Protezioni · RTO/RPO · Disaster recovery
Minacce e protezioni — livelli di sicurezza
| Asset | Minaccia | Contromisura | Standard |
|---|---|---|---|
| Smartphone/palmare | Furto, smarrimento, malware | MDM con wipe remoto, crittografia disco, PIN/biometrico obbligatorio, app whitelist | Android Keystore, Knox |
| Gate RFID | Clonazione tag, intercettazione RF | Tag con cifratura AES-128, autenticazione challenge-response, rete LAN isolata VLAN | ISO 29167 |
| Rete WiFi | Accesso non autorizzato | WPA3-Enterprise 802.1X, RADIUS server, SSID nascosto, IDS wireless | IEEE 802.11i |
| DB Server | Accesso non autorizzato, SQL injection | TLS 1.3 in transito, AES-256 at-rest, prepared statements, RBAC ruoli | GDPR art. 32 |
| API REST | Man-in-the-middle, reverse engineering | Certificate pinning su app mobile, JWT con scadenza, rate limiting, WAF | OWASP Top 10 |
Business Continuity: RTO e RPO
| Componente | Strategia FT | RTO | RPO |
|---|---|---|---|
| API server (ECS) | Multi-AZ auto-scaling, istanza sostitutiva in 60s | < 60s | 0 |
| DB Aurora | Multi-AZ Primary+Standby, failover automatico | < 30s | ≈ 0 |
| Load Balancer (ALB) | Nativamente ridondato 3 AZ | 0 | 0 |
| SO offline | App mobile store-and-forward: buffering locale + sync al ripristino | N/A | < 1h |
| Disaster Recovery | S3 cross-region replica (eu-west-1), snapshot DB daily, test restore mensile | < 4h | < 24h |
// piano business continuity (BCP)
- Backup: snapshot Aurora ogni 5 min (PITR), S3 cross-region continuo, test restore mensile
- Monitoring: CloudWatch + PagerDuty alerting 24/7, SLA uptime 99.9% (~8.7h downtime/anno)
- Incident response: runbook per scenari critici, team on-call con escalation
- Change management: deploy blue/green zero-downtime, rollback automatico
Seconda Parte
I
Quesito I — Database e pagine web tracking
Schema ER · DDL · PHP pagina tracking pubblico
Schema concettuale ER — entità principali
Entità: CLIENTE, SPEDIZIONE, EVENTO_TRACCIAMENTO, NODO_LOGISTICO, OPERATORE
Relazioni: Cliente (1) ←richiede→ (N) Spedizione | Spedizione (1) ←genera→ (N) Evento | Evento (N) ←presso→ (1) Nodo | Nodo si specializza in: SO, CSR
Modello logico — DDL MySQL
Schema relazionale FastDelivery
CREATE TABLE CLIENTE (
id_cliente INT PRIMARY KEY AUTO_INCREMENT,
nome VARCHAR(150) NOT NULL,
email VARCHAR(150) UNIQUE NOT NULL,
telefono VARCHAR(20),
indirizzo TEXT
);CREATE TABLE SPEDIZIONE (
cpu CHAR(14) PRIMARY KEY, — FD-YYYY-XXXXXX
id_cliente INT FOREIGN KEY → CLIENTE,
dest_nome VARCHAR(150) NOT NULL,
dest_indirizzo TEXT NOT NULL,
peso_kg DECIMAL(6,2),
stato ENUM(‘RICHIESTA’,’IN_TRANSITO’,’CONSEGNATO’,’FALLITO’),
data_richiesta DATETIME DEFAULT CURRENT_TIMESTAMP,
data_consegna DATETIME NULL,
firma_digitale BLOB
);CREATE TABLE NODO_LOGISTICO (
id_nodo INT PRIMARY KEY AUTO_INCREMENT,
codice VARCHAR(10) UNIQUE, — SO-MI-01, CSR-LOM
tipo ENUM(‘SO’,’CSR’) NOT NULL,
nome VARCHAR(100),
citta VARCHAR(100),
lat DECIMAL(9,6),
lng DECIMAL(9,6)
);CREATE TABLE EVENTO_TRACCIAMENTO (
id_evento INT PRIMARY KEY AUTO_INCREMENT,
cpu CHAR(14) FOREIGN KEY → SPEDIZIONE,
id_nodo INT FOREIGN KEY → NODO_LOGISTICO,
tipo_evento ENUM(‘RITIRO’,’INGRESSO’,’USCITA’,’CONSEGNATO’),
timestamp_evento DATETIME NOT NULL,
lat DECIMAL(9,6),
lng DECIMAL(9,6)
);
Pagina web — tracking pubblico (PHP)
tracking.php — visualizzazione stato spedizione
<?php
session_start();
require_once ‘db.php’;if ($_SERVER[‘REQUEST_METHOD’] === ‘POST’) {
$cpu = trim($_POST[‘cpu’] ?? ”);
// Validazione formato CPU (whitelist)
if (preg_match(‘/^FD-\d{4}-[A-Z0-9]{6}$/’, $cpu)) {
// Query stato attuale spedizione
$stmt = $pdo->prepare(
“SELECT s.cpu, s.dest_nome, s.stato, s.data_consegna,
e.tipo_evento, n.nome, n.citta, e.timestamp_evento
FROM SPEDIZIONE s
LEFT JOIN EVENTO_TRACCIAMENTO e ON s.cpu = e.cpu
LEFT JOIN NODO_LOGISTICO n ON e.id_nodo = n.id_nodo
WHERE s.cpu = ?
ORDER BY e.timestamp_evento DESC LIMIT 1”
);
$stmt->execute([$cpu]);
$spedizione = $stmt->fetch(PDO::FETCH_ASSOC);
if ($spedizione) {
// Query storico eventi
$stmt2 = $pdo->prepare(
“SELECT tipo_evento, timestamp_evento, n.nome, n.citta
FROM EVENTO_TRACCIAMENTO e
JOIN NODO_LOGISTICO n ON e.id_nodo = n.id_nodo
WHERE e.cpu = ? ORDER BY e.timestamp_evento ASC”
);
$stmt2->execute([$cpu]);
$storia = $stmt2->fetchAll();
}
}
}
?>
<!DOCTYPE html>
<html><head>
<meta charset=“UTF-8”>
<title>Traccia spedizione FastDelivery</title>
</head><body>
<h1>Traccia la tua spedizione</h1>
<form method=“post”>
<input type=“text” name=“cpu” placeholder=“FD-YYYY-XXXXXX” required>
<button>Cerca</button>
</form>
<?php if ($spedizione): ?>
<h2><?= htmlspecialchars($spedizione[‘cpu’]) ?></h2>
<p>Destinatario: <?= htmlspecialchars($spedizione[‘dest_nome’]) ?></p>
<p>Stato: <strong><?= htmlspecialchars($spedizione[‘stato’]) ?></strong></p>
<table border=“1”>
<tr><th>Evento</th><th>Data</th><th>Sede</th></tr>
<?php foreach ($storia as $ev): ?>
<tr><td><?= htmlspecialchars($ev[‘tipo_evento’]) ?></td>
<td><?= htmlspecialchars($ev[‘timestamp_evento’]) ?></td>
<td><?= htmlspecialchars($ev[‘nome’]) ?></td></tr>
<?php endforeach; ?>
</table>
<?php endif; ?>
</body></html>
II
Quesito II — Monitoraggio GPS automezzi
Tecnologie · Protocolli MQTT · Real-time tracking
Soluzioni tecnologiche — confronto
| Tecnologia | Precisione | Latenza | Costo | Scelta |
|---|---|---|---|---|
| GPS puro (ricevitore) | 3–5 m outdoor | 1–5 sec | Basso | Supporto primario outdoor |
| A-GPS (assisted) | 5–15 m | < 2 sec (fix rapido) | Basso | Integrato smartphone 4G |
| OBD-II + GPS tracker | 3–5 m | 30 sec | Medio (€50–150/device) | ✓ Scelta principale |
| Cell-ID / LBS | 50–300 m | Istantaneo | Zero (rete operatore) | Fallback in tunnel |
// soluzione consigliata: OBD-II tracker
Installare un GPS tracker OBD-II (es. Teltonika FMB120) su ogni automezzo FastDelivery. Il dispositivo trasmette posizione, velocità, stato motore, carburante, ogni 30 secondi via 4G LTE. In gallerie/tunnel, buffering locale fino a ripristino segnale (store-and-forward). Costo operativo ridotto grazie all’assenza di SIM ulteriore (condivisa con infrastruttura di rete) e batteria sempre alimentata dalla batteria del veicolo.Protocolli di comunicazione — MQTT ottimale
| Protocollo | Come funziona | Vantaggio | Svantaggio |
|---|---|---|---|
| MQTT | Publish/subscribe leggero. Veicolo pubblica topic fastdelivery/veicoli/{id}/gps al broker. Server si sottoscrive. QoS 1 (at-least-once) ridondanza. | Overhead minimo (header 2 byte), efficiente su 4G LTE, perfetto per timeseries | Necessita broker MQTT (AWS IoT Core o Mosquitto) |
| HTTPS REST | POST periodico a /api/v1/veicoli/{id}/gps. Payload JSON. Stateful. | Semplice da implementare, no broker esterno | Overhead HTTP grande (~500 byte header), inefficiente per centinaia di veicoli con aggiornamenti frequenti |
Payload MQTT — posizione veicolo in tempo reale
// Topic: fastdelivery/veicoli/VH-0042/gps
// QoS: 1 (at-least-once), Retain: true (ultimo state disponibile)
{
“veicolo_id”: “VH-0042”,
“timestamp”: “2024-11-15T09:42:17Z”,
“lat”: 45.464211,
“lng”: 9.189282,
“speed_kmh”: 47,
“heading”: 235,
“motore”: true,
“carburante_pct”: 73,
“segnale_db”: -78
}
// architettura centrale operativa
AWS IoT Core riceve messaggi MQTT dai 500+ automezzi. IoT Rule attiva Kinesis Data Streams in real-time. Lambda consumer normalizza payload, aggiorna DB, calcola ETA. TimescaleDB mantiene serie storica GPS. WebSocket API Gateway esegue push dashboard dispatcher (Leaflet map, posizioni live). Dashboard backend: Node.js + Socket.io per WebSocket bidirezionale.III
Quesito III — Clustering e virtualizzazione
Hardware clustering · Virtualizzazione software · Vantaggi/svantaggi
Clusterizzazione hardware — architetture
| Tipo cluster | Come funziona | Vantaggi | Svantaggi |
|---|---|---|---|
| HA Attivo-Passivo | 1 nodo primario, 1 standby. Heartbeat monitora primary (es. Keepalived/VRRP). Se cade, standby prende l’IP virtuale in <30s. | Semplice, economico, RTO basso | Nodo standby al 50% sprecato |
| Load Balancing Attivo-Attivo | 3+ nodi tutti attivi. LB distribuisce richieste (Round Robin, Least Conn, IP Hash). Usato per stateless (web server, API). | Scaling orizzontale, nessuno spreco | Complessità session, LB è SPOF |
| Multi-Master DB (es. InnoDB Cluster) | 3+ nodi con replica sincrona. Qualsiasi nodo accetta write. Group Replication MySQL. | Zero data loss, failover automatico | Latenza write (sincronizzazione), rete bassa latency richiesta |
Virtualizzazione software — tipi e applicazioni
| Tipo | Tecnologia | Isolamento | Overhead | Use case |
|---|---|---|---|---|
| Hypervisor Tipo 1 (bare-metal) | ESXi, Hyper-V, KVM | Completo (OS dedicato per VM) | 5–15% | Consolidazione server, ambienti misti |
| Hypervisor Tipo 2 (hosted) | VirtualBox, VMware Workstation | Completo (over OS host) | 15–30% | Dev/test locale, non produzione |
| Container (OS-level) | Docker, Podman, containerd | Parziale (kernel host condiviso, ma namespace isolati) | < 3% | Microservizi, CI/CD, cloud-native |
| Orchestrazione container | Kubernetes, AWS ECS/Fargate | Cluster multi-host container | Overhead K8s | Produzione cloud-scale, autoscaling |
// applicazione a FastDelivery
L’architettura cloud usa container Docker su ECS/Fargate per i microservizi API (tracking, spedizioni, notifiche). RDS gestisce il database. Benefici: deploy blue/green zero-downtime, autoscaling in <60s durante picchi, isolation tra servizi, rollback immediato, portabilità codice.IV
Quesito IV — Sicurezza email
Minacce · SPF/DKIM/DMARC · Protocolli TLS · S/MIME
Minacce alle comunicazioni email
| Minaccia | Descrizione | Impatto |
|---|---|---|
| Phishing | Email contraffatta che imita mittente legittimo per ottenere credenziali o dati | Furto account, danni reputazione |
| Email spoofing | Falsificazione campo From mediante SMTP non autenticato | Frode, invio malware come se da mittente legittimo |
| Man-in-the-Middle (MITM) | Intercettazione email in transito SMTP plaintext (porta 25) | Lettura contenuto, modifica messaggi |
| Business Email Compromise (BEC) | Impersonificazione dirigenti per autorizzare trasferimenti fraudolenti | Perdite finanziarie critiche (media €75k/incidente FBI) |
| Malspam | Invio massiccio email con allegati malware (.exe, .zip), macro Word | Infezione ransomware, botnet |
Protocolli di sicurezza email — stack completo
Layer 1 — Autenticazione mittente (anti-spoofing)
| Protocollo | Meccanismo | Record DNS |
|---|---|---|
| SPF | Elenca IP autorizzati per il dominio | v=spf1 include:_spf.google.com ~all |
| DKIM | Firma SMTP con chiave privata. Verifica con pubblica nel DNS. | v=DKIM1; k=rsa; p=MIGfMA0... |
| DMARC | Policy: cosa fare se SPF/DKIM falliscono (p=reject, quarantine, none) | v=DMARC1; p=reject; rua=mailto:... |
Layer 2 — Cifratura in transito
| Protocollo | Uso | Porta | Dettaglio |
|---|---|---|---|
| STARTTLS | SMTP server-to-server | 587 | Upgrade opportunistico a TLS (compatibilità legacy) |
| SMTPS | SMTP cifrato | 465 | TLS implicito dal connection start |
| IMAPS | Ricezione client (cifrato) | 993 | IMAP-over-TLS, obbligatorio |
| POP3S | Ricezione client (cifrato) | 995 | POP3-over-TLS, obbligatorio |
| MTA-STS | Enforce TLS policy | HTTPS | Previene downgrade TLS tra MTA |
Layer 3 — Cifratura end-to-end del contenuto
| Standard | Meccanismo | Quando usare |
|---|---|---|
| S/MIME | Certificati X.509, firma digitale + cifratura asimmetrica | Email critiche (legali, finanziarie). Integrato in Outlook, Apple Mail. |
| PGP/OpenPGP | Web of Trust, chiavi pubbliche su keyserver | Comunità tecnica/open-source. Meno integrato in client enterprise. |
Stack di sicurezza email FastDelivery (raccomandazione)
// configurazione completa
- DNS: SPF + DKIM + DMARC p=reject per tutti i domini (@fastdelivery.it)
- SMTP: STARTTLS obbligatorio su porta 587, SMTPS su 465, MTA-STS policy
- Client: IMAPS porta 993, POP3S porta 995, nessun plaintext
- Gateway: anti-spam/anti-malware cloud (Google Workspace o Microsoft 365 Defender)
- Email critiche: S/MIME firma digitale obbligatoria per comunicazioni legali/finanziarie
- MFA: su tutti gli account email aziendali (TOTP o security key)
- User awareness: training anti-phishing periodico, simulazioni