GDPR inutile: server in Europa, gestione in Indonesia e clienti all’oscuro

Sulla carta il GDPR è una delle leggi più belle mai scritte sulla protezione dei dati. Principi chiari, responsabilità precise, diritti per le persone, sanzioni fino al 4% del fatturato mondiale. Nella pratica, almeno per la parte che riguarda chi mette davvero le mani sui server, è spesso una legge che nessuno verifica e che quasi nessuno rispetta fino in fondo.

Non lo diciamo per partito preso. Lo diciamo perché il nostro lavoro ci porta ogni giorno dentro i sistemi di altre aziende: interventi di assistenza sistemistica, migrazioni, ottimizzazioni, analisi di incidenti, recupero di siti compromessi. E quando si entra in un server, il server racconta sempre chi ci è passato prima. Da dove si è collegato, con quale utente, con quali privilegi, e cosa ha lasciato in giro.

Quello che raccontano i log, troppo spesso, è una storia che i clienti di quelle aziende non conosceranno mai.

Le aziende “a norma”

Parliamo di un tipo di azienda molto preciso, e molto diffuso. Fornisce servizi in abbonamento, gestisce un e-commerce importante, una piattaforma con centinaia di migliaia di utenti registrati. Fattura milioni. Ha in homepage i loghi delle certificazioni ISO 9001 e ISO/IEC 27001, magari anche altre. Ha un controllo di gestione impeccabile, procedure di qualità documentate, un ufficio legale interno o uno studio di riferimento che viene coinvolto anche per firmare il contratto di fornitura più banale.

Per rinnovare un abbonamento a un software servono tre giri di revisione delle clausole. Per accettare l’offerta di un fornitore servono il modulo di qualifica, la verifica della visura, la nomina a responsabile del trattamento firmata in tre copie.

Poi si guarda chi amministra davvero il server su cui girano il sito, il database dei clienti, gli ordini, le fatture, i documenti caricati. E si scopre che la gestione quotidiana è stata affidata a personale offshore a basso costo, in Indonesia, in India o in Paesi simili, scelto per il prezzo orario e collegato con la password di root.

Server in Europa, chiavi altrove

Lo schema è quasi sempre lo stesso, e ha un’apparenza perfettamente rispettabile.

L’azienda italiana acquista un server dedicato o una VPS da un provider europeo serio, con data center in Germania, Francia o Finlandia. Firma il contratto di trattamento con il provider, che è in regola. Scrive nell’informativa privacy che i dati sono conservati su infrastrutture situate nell’Unione europea. Fin qui, tutto vero.

Il server però va gestito: aggiornamenti, configurazioni, backup, problemi del sito, modifiche al database. E qui entra in gioco la scorciatoia. La gestione viene affidata a un’agenzia che a sua volta subappalta, a un consulente che “ha dei ragazzi bravi all’estero”, oppure direttamente a un freelance trovato su Fiverr o su una piattaforma simile. Il primo che risponde, al prezzo più basso.

Da quel momento il dato è “in Europa” solo nel senso che i dischi si trovano in Europa. Chi lo legge, lo copia, lo esporta e lo modifica si trova dall’altra parte del mondo. Senza contratto, senza nomina, senza che nessuno l’abbia mai dichiarato ai clienti.

Come ce ne accorgiamo

Non serve un’indagine. Bastano i comandi che qualunque sistemista lancia nei primi cinque minuti su un server che non conosce.

• Gli ultimi accessi. Lo storico dei login SSH mostra gli indirizzi IP da cui ci si è collegati. Una ricerca sull’IP restituisce operatore e Paese. Quando gli accessi come root arrivano tutti i giorni da reti di provider indonesiani o indiani, il quadro è chiaro.
• Le chiavi autorizzate. Nel file delle chiavi SSH di root troviamo spesso chiavi di persone di cui il cliente non conosce nemmeno il nome, con il commento lasciato dal portatile di chi le ha generate. Nessuno sa a chi appartengano né quando siano state aggiunte.
• Gli utenti del database. Utenti MySQL o MariaDB con tutti i privilegi e accesso da qualunque indirizzo, creati “per comodità” per lavorare da remoto senza passare dal server.
• I log dei pannelli e degli strumenti. Accessi a phpMyAdmin, al pannello di controllo, all’amministrazione del CMS da IP extra-UE, con account generici usati da più persone.
• Quello che resta sul disco. Esportazioni complete del database in una cartella pubblica, file come backup.sql o clienti.csv dimenticati dopo un intervento, script scaricati da chissà dove, strumenti di desktop remoto installati e mai rimossi.
• Le credenziali. Password di root e del database uguali da anni, mai cambiate dopo l’avvicendamento di decine di collaboratori, spesso passate in chat.

Il punto non è che questi accessi siano per forza malevoli. Nella maggior parte dei casi chi lavora da lì sta facendo il proprio lavoro. Il punto è che nessuno, in azienda, sa chi abbia accesso a cosa. Il responsabile della qualità no, l’ufficio legale no, il DPO quasi mai. E i clienti, ovviamente, ancora meno.

Il problema non è l’Indonesia

Va detto con chiarezza, perché il tema si presta a letture sbagliate. In Indonesia, in India e in molti altri Paesi lavorano tecnici eccellenti, società strutturate, professionisti più preparati di tanti colleghi europei. Il problema non è la nazionalità di chi lavora.

Il problema è il modello. Scegliere chi avrà accesso a centinaia di migliaia di dati personali con lo stesso criterio con cui si sceglie la carta per la stampante: il prezzo. Senza verificare chi sia davvero il soggetto, quante persone ci siano dietro il profilo, dove finiscano le credenziali, cosa succeda ai dati quando l’incarico finisce. E soprattutto senza dirlo a nessuno.

Un’azienda che fa outsourcing in modo serio, anche verso Paesi lontani, firma contratti, nomina responsabili, valuta il trasferimento, limita gli accessi e lo dichiara. Un’azienda che lo fa per risparmiare qualche centinaio di euro al mese, di solito, non fa niente di tutto questo.

Cosa dice la carta

Senza entrare in tecnicismi giuridici, che abbiamo già approfondito parlando di outsourcing IT a basso costo fuori dall’UE, alcuni principi sono semplici.

• Un server in Europa non basta. Secondo le linee guida dell’European Data Protection Board, rendere i dati accessibili da remoto a un soggetto distinto che opera da un Paese terzo è un trasferimento internazionale. Che il database resti fisicamente a Francoforte non cambia nulla.
• Servono basi giuridiche precise. Né l’India né l’Indonesia hanno una decisione di adeguatezza della Commissione europea. Il trasferimento richiede quindi strumenti come le Clausole Contrattuali Standard e una valutazione concreta dei rischi.
• Chi tratta i dati per conto dell’azienda va nominato. L’articolo 28 richiede un contratto con il responsabile del trattamento, e l’autorizzazione del titolare per ogni ulteriore subfornitore.
• I clienti vanno informati. L’informativa deve indicare l’eventuale trasferimento verso Paesi terzi e le garanzie adottate. Chi lo chiede, con una richiesta di accesso, ha diritto di sapere a quali destinatari sono comunicati i suoi dati.
• La sicurezza deve essere adeguata. L’articolo 32 parla di riservatezza, controllo degli accessi, capacità di ripristino. Una password di root condivisa in chat non rientra in nessuna definizione di misura adeguata.

È tutto scritto, è tutto chiaro. Ed è proprio qui che il GDPR mostra il suo limite più grande: è perfetto nel definire cosa si deve fare, ma non ha nessun modo realistico di vedere cosa succede davvero.

Perché nessuno lo saprà mai

Nel 2025 il Garante per la protezione dei dati personali ha effettuato 130 ispezioni, in linea con l’anno precedente. Centotrenta, a fronte di oltre quattro milioni di imprese attive in Italia. Nello stesso anno gli sono stati notificati 2.415 data breach, più di sei al giorno. Sono quelli notificati, cioè quelli che qualcuno si è accorto di aver subito e ha deciso di dichiarare.

Con questi numeri la probabilità che qualcuno vada a guardare chi si collega come root al server di un e-commerce è, statisticamente, nulla. E anche nel caso di un’ispezione, si controllano documenti: registro dei trattamenti, informative, nomine, procedure. Documenti che, nelle aziende di cui parliamo, sono spesso impeccabili.

Il cliente finale, dal canto suo, non ha alcuno strumento per accorgersene. Vede un sito curato, un’informativa che parla di server europei, i loghi delle certificazioni. Non vedrà mai il log degli accessi. Se un giorno i suoi dati finiranno in vendita su un forum, nessuno potrà ricostruire da dove siano usciti. Molto probabilmente nemmeno l’azienda stessa, perché quei log, quando esistono, nessuno li conserva e nessuno li guarda.

È questa la vera inutilità del GDPR nella pratica. Non i principi, che sono giusti. Ma l’assenza totale di un meccanismo che porti alla luce quello che succede dietro le quinte. Un sistema che si basa sull’autodichiarazione funziona solo con chi ha già deciso di comportarsi bene.

Le certificazioni non guardano nei log

Viene da chiedersi come sia possibile che aziende certificate ISO/IEC 27001 arrivino a questo punto. La risposta è scomoda ma semplice.

La norma prevede controlli molto precisi proprio su questi temi: la sicurezza nei rapporti con i fornitori, gli accordi con la catena di fornitura ICT, la gestione degli accessi privilegiati, la registrazione e il monitoraggio delle attività. Sulla carta, uno scenario come quello descritto non dovrebbe sopravvivere a un audit.

Ma l’audit di certificazione verifica il sistema di gestione, per campione, attraverso documenti e interviste. L’auditor chiede se esiste una procedura di qualifica dei fornitori, e la procedura esiste. Chiede se gli accessi privilegiati sono censiti, e gli viene mostrato un elenco. Nessuno apre una sessione sul server di produzione per confrontare quell’elenco con le chiavi SSH effettivamente presenti o con gli IP degli ultimi accessi.

Il risultato è un paradosso che vediamo di continuo: l’azienda più documentata è spesso quella con la maggiore distanza tra ciò che dichiara e ciò che fa. Perché la documentazione è curata dall’ufficio qualità, mentre il server è “una cosa tecnica” che è stata delegata e dimenticata.

Il conto che arriva dopo

Finché non succede niente, il risparmio sembra un affare. Poi un giorno succede qualcosa: un database esportato e mai cancellato, una chiave rimasta attiva dopo la fine della collaborazione, un account compromesso sul computer personale di qualcuno che nessuno ha mai conosciuto. E l’azienda si trova a dover notificare una violazione entro 72 ore senza sapere chi avesse accesso, da dove, e con quali dati.

A quel punto il trasferimento mai dichiarato, la nomina mai firmata, l’informativa non veritiera diventano tutti insieme un problema legale, oltre che tecnico e reputazionale. E l’ufficio legale, che per un contratto di fornitura di cancelleria aveva chiesto tre revisioni, scopre per la prima volta chi ha avuto le chiavi di tutto negli ultimi anni.

Cosa dovrebbe fare un’azienda seria

Non servono budget enormi. Servono poche regole applicate davvero, e verificate sul server, non sui documenti.

• Sapere chi entra. Un inventario reale degli accessi: utenti di sistema, chiavi SSH, utenti del database, account dei pannelli e del CMS. Confrontato periodicamente con quello che c’è davvero sulle macchine.
• Accessi nominativi. Niente password di root condivise. Ogni persona ha il proprio utente, con i soli privilegi necessari, e le attività sono tracciate. È il motivo per cui nei servizi gestiti seri la password di root non viene consegnata.
• Autenticazione forte e accessi filtrati. Chiavi al posto delle password, secondo fattore, accesso consentito solo da indirizzi o reti autorizzate, database mai esposto su Internet.
• Dati finti per chi sviluppa. Chi deve correggere un tema o un plugin non ha bisogno del database reale con i dati dei clienti. Bastano copie anonimizzate.
• Revoca immediata. Quando un incarico finisce, gli accessi si chiudono il giorno stesso e le credenziali si cambiano.
• Contratti e informative coerenti. Se un fornitore extra-UE accede ai dati, va nominato, il trasferimento va valutato e reso trasparente nell’informativa. Se non si vuole dichiararlo, la risposta giusta è non farlo.

E una regola di buon senso valida per i fornitori: se un fornitore sistemistico non sa dire con precisione chi dei suoi tecnici accede ai vostri server, da dove e con quali privilegi, il problema non è il prezzo che vi fa.

E il cliente finale?

Chi è cliente di un servizio in abbonamento o di un e-commerce ha uno strumento che pochi usano: la richiesta di accesso ai propri dati. Il GDPR consente di chiedere a quali destinatari siano stati comunicati i propri dati e, in caso di trasferimento verso Paesi terzi, quali garanzie siano state adottate.

Non risolverà il problema, ma obbliga l’azienda a mettere per iscritto una risposta. E per qualcuno, forse, sarà la prima volta che se lo chiede davvero.

Come lavoriamo noi

In Managed Server facciamo assistenza sistemistica Linux e gestiamo Server Dedicati per aziende che, giustamente, si aspettano di sapere chi mette le mani sulla loro infrastruttura. Gli accessi sono nominativi e tracciati, la password di root non viene distribuita, i privilegi sono quelli che servono per il lavoro da fare.

E quando, entrando nel server di un nuovo cliente, troviamo accessi che nessuno sa spiegare, chiavi di sconosciuti, database esposti o dump dimenticati, il nostro primo compito è dirlo. Chiaramente, anche quando è scomodo. Perché a volte l’intervento più utile non è l’ottimizzazione richiesta, ma mostrare al cliente chi ha davvero le chiavi di casa sua.

Conclusioni

Il GDPR ha dato alle persone dei diritti e alle aziende delle regole. Quello che non ha dato è un modo per verificare che le regole vengano rispettate là dove conta davvero: sui server, nei log, negli accessi. In quel vuoto prosperano aziende impeccabili sulla carta che, per risparmiare, consegnano i dati di centinaia di migliaia di persone a chiunque costi meno, senza dirlo a nessuno.

Non è l’eccezione. Nella nostra esperienza è diventata la regola. E finché la conformità verrà misurata sui documenti invece che sui sistemi, continuerà a esserlo.

Se volete sapere chi ha davvero accesso alla vostra infrastruttura, la risposta non è nel registro dei trattamenti. È nel server. E basta guardarci.