I dati dei clienti vivono su hardware PSA in data center Tier III italiani. Uscita internet via AS42425 (PSA ha proprio Autonomous System, peering su TOP-IX). Replicazione per DR solo verso 2a sede italiana, mai extra-UE. Encryption AES-256 at rest, TLS 1.3 in transit. Accesso amministrativo via PAM con firma temporale qualificata, audit log immutabile. GDPR-compliant per costruzione, niente SCC / DPA internazionali da firmare.
01Perché la domanda conta (oggi, non in teoria)
Fino a qualche anno fa "dove stanno i dati" era una casella da spuntare a fine contratto. Oggi è la prima domanda che un DPO serio pone — e ha ragione. Tre pressioni convergenti l'hanno riportata al centro:
- Schrems II (CJEU, 2020) ha invalidato il Privacy Shield e reso fragile qualsiasi trasferimento verso gli Stati Uniti: i presidi organizzativi (SCC, DPA) non bastano più se la legge del paese destinatario permette accessi governativi incontrollati. Il nuovo Data Privacy Framework è sotto contestazione, di nuovo, davanti alla stessa corte.
- NIS2 (direttiva UE 2022/2555, recepita in Italia nel 2024) estende gli obblighi di sicurezza e continuità operativa a categorie ampie di aziende — manifatturiero, servizi digitali, sanità, trasporti. Serve sapere, e documentare, dove passa ogni bit.
- I clienti regolati (sanità, finance, PA, utilities) iniziano a inserire clausole contrattuali che pretendono infrastruttura UE o italiana, con penali concrete se il fornitore non riesce a dimostrarlo in audit.
Tradotto: se il tuo provider risponde "i dati sono in Europa, credimi sulla parola", hai un problema. Serve topologia tracciabile.
02Dove stanno, in pratica
La topologia fisica è semplice e volutamente conservativa. Niente distribuzione multi-region creativa, niente edge node sparsi nel mondo — la semplicità è un requisito di compliance, non un limite.
- Sede primaria: data center Tier III nell'area di Torino. Rack PSA, hardware PSA, accesso fisico controllato con badge nominativi e registro accessi conservato dal gestore del DC.
- Sede secondaria per DR: secondo data center Tier III in Italia, geograficamente separato (distanza sufficiente a coprire scenari di catastrofe localizzata — blackout metropolitano, alluvione, incendio).
- Replicazione: solo tra queste due sedi. Mai verso cloud pubblici, mai verso infrastrutture extra-UE. Nessun "finisce che magari un backup sta altrove" — il percorso dei dati è mappato e chiuso.
Hardware e racking sono gestiti con il nostro partner infrastrutturale Adenda S.r.l., con cui lavoriamo da anni sul lato fisico di housing e hosting.
03Uscita internet: AS42425 su TOP-IX
PSA ha un proprio Autonomous System (AS42425). In pratica significa che siamo un soggetto di rete autonomo riconosciuto a livello BGP — non acquistiamo connettività come cliente finale da un singolo carrier, peeriamo direttamente su TOP-IX (il Torino Internet Exchange) e con altri operatori.
Perché conta, per la sovereignty:
- Il traffico dei clienti esce dalla nostra infrastruttura su rotte BGP che controlliamo. Non c'è un upstream che silenziosamente fa trombone via New York o Francoforte perché in quel momento è la rotta più economica.
- Il peering pubblico italiano riduce fisicamente gli hop: per destinazioni italiane il traffico resta nel territorio nazionale; per destinazioni europee passa su peering EU diretti.
- In fase di audit siamo in grado di produrre la topologia di routing — non è una black box del carrier.
04Encryption at rest: AES-256 con chiavi per cliente
Tutti i volumi persistenti sono cifrati a riposo con AES-256. Le chiavi non sono "una per tutto il data center" — c'è separazione crittografica per cliente, gestita tramite un key management system interno. Cliente terminato, chiavi distrutte: il dato residuo diventa non decifrabile anche se per qualche motivo sopravvive fisicamente su un disco.
La cifratura copre backup, snapshot, repliche asincrone verso la 2a sede, supporti di archiviazione a freddo. Non ci sono finestre "in chiaro" tra primary e DR.
05Encryption in transit: TLS 1.3, mTLS per backend
Il traffico esterno è servito esclusivamente su TLS 1.3 (con TLS 1.2 ancora accettato dove obbligatorio per compatibilità — segnalato e con data di dismissione). Suite moderne, HSTS, disabilitazione di cipher legacy.
Tra i componenti interni — application server, database, code, servizi di auth — usiamo mTLS: ogni chiamata è autenticata reciprocamente con certificato, non "dentro la rete privata è tutto fidato". È un'abitudine che vent'anni fa sarebbe sembrata paranoica, oggi è il minimo indispensabile: la rete interna non è più un perimetro di fiducia, è solo un percorso.
06Accesso amministrativo controllato
La parte più delicata della data sovereignty non è dove stanno i dati — è chi può leggerli amministrativamente. Qui il presidio è a tre livelli:
- PAM (Privileged Access Management): nessun amministratore si collega direttamente ai sistemi del cliente con la propria shell personale. Tutte le sessioni privilegiate passano per il PAM, che emette credenziali temporanee, registra la sessione e applica policy (chi, cosa, quando, con quale motivazione).
- 2FA obbligatoria per ogni operatore, sempre — coerente con il modello che applichiamo a tutti i backend clienti. Niente eccezioni "solo per un minuto".
- Audit log immutabile degli accessi amministrativi, con firma temporale qualificata. Significa che il log non è modificabile a posteriori (neanche da noi) e che l'orario è attestato da un'autorità di marcatura temporale — in audit vale come prova.
Se un cliente chiede "chi ha toccato il mio sistema il 12 aprile alle 15:47", la risposta è una riga di log firmata, non una ricostruzione a memoria.
07Quando l'extra-UE serve davvero
Essere onesti: ci sono casi in cui il dato deve uscire dall'UE, e fingere di no sarebbe marketing. Il più frequente oggi è l'uso di modelli di AI via API di provider non europei (OpenAI, Anthropic, Google). Il nostro approccio:
- Trasparenza: se un flusso chiama un LLM extra-UE, è documentato nel DPA e nel registro dei trattamenti. Niente opt-in nascosto.
- Minimizzazione: pseudonimizzazione a monte della chiamata, zero retention lato provider dove l'API lo permette contrattualmente.
- Alternativa self-hosted: per chi non può o non vuole, mettiamo a disposizione LLM self-hosted dentro la nostra infrastruttura italiana. Non sono i modelli di frontiera in termini assoluti, ma per la maggior parte dei casi d'uso aziendali (RAG su documentazione interna, classificazione, estrazione strutturata) coprono bene — e i dati non escono.
08Cosa deve firmare il cliente
La conseguenza pratica di tutto quanto sopra: il pacchetto contrattuale è volutamente leggero.
| Tema | Stack italiano PSA | Hyperscaler tipico (anche con region EU) |
|---|---|---|
| Dove vivono i dati | Due data center Tier III italiani, hardware PSA | Distribuiti globalmente, region EU dichiarata ma controllo legale USA/cloud-provider |
| Uscita internet | AS42425 proprio, peering su TOP-IX, rotte documentabili | Backbone del provider, opaco al cliente |
| Trasferimenti extra-UE | Nessuno di default; se serve (es. LLM), esplicitato nel DPA | Possibili per telemetria, support ops, servizi gestiti — spesso non visibili |
| Contratti necessari | DPA standard italiano | DPA + SCC + TIA + valutazione rischio giurisdizionale |
| Audit degli accessi admin | Log immutabile con firma temporale qualificata | Log del provider, fidati del report |
| Chi risponde in audit | La stessa persona che gestisce il sistema | Commerciale + documenti contrattuali, zero dialogo tecnico diretto |
In pratica: il cliente firma DPA standard (contratto ex art. 28 GDPR) e niente Standard Contractual Clauses, niente Transfer Impact Assessment, niente analisi della legge FISA. Non perché "non serve" — perché il trasferimento che renderebbe necessari quei documenti non avviene.