GDPR e server: requisiti tecnici minimi
Il GDPR impone misure tecniche e organizzative adeguate alla protezione dei dati personali (art. 32). Tradurre la norma in requisiti pratici per i server e l'unico modo per essere realmente conformi e non solo formalmente. Vediamo i requisiti tecnici minimi imprescindibili.
Cifratura at-rest e in-transit
I dati personali devono essere cifrati sia in archiviazione (disco, backup, snapshot) sia in transito (TLS 1.2+). Implementa LUKS o dm-crypt per dischi server, HTTPS obbligatorio con HSTS, VPN per accessi amministrativi, cifratura applicativa per campi sensibili (es. AES-256). I backup off-site devono essere cifrati lato client prima dell'upload.
Accessi e identità
Solo personale autorizzato deve accedere ai sistemi: utenti nominali (no shared), MFA per amministrazione, principio del minimo privilegio (least privilege), revisione periodica degli accessi, rotazione chiavi/password, log degli accessi. Per amministrazione SSH con chiave + passphrase + 2FA sui pannelli.
Logging e monitoraggio
Mantieni log centralizzati e protetti: chi ha fatto cosa, quando. Conservali per il tempo previsto (tipicamente 6-12 mesi). Implementa monitoring di sicurezza per anomalie (login da paesi inusuali, escalation privilegi, accessi massivi a dati personali). Considera SIEM open source come Wazuh.
Backup e business continuity
Backup quotidiani con regola 3-2-1, test di restore periodici, RTO/RPO documentati, piano di disaster recovery scritto. La perdita di dati personali a causa di backup mancanti o non ripristinabili e violazione GDPR. Conservazione backup proporzionata: troppo lunga e essa stessa un rischio.
Patch management
Aggiornamenti tempestivi: patch di sicurezza entro 30 giorni dal rilascio (idealmente 7-14 per critical). Documenta il processo di patching, mantieni inventario versioni software, traccia CVE applicabili. Sistemi non aggiornati che subiscono breach sono violazione manifesta.
Procedura passo-passo per conformita
- Mappa i sistemi e i dati personali trattati (registro trattamenti).
- Identifica i fornitori e raccogli DPA (Data Processing Agreement).
- Implementa hardening server, cifratura, MFA.
- Centralizza i log e definisci retention.
- Configura monitoring di sicurezza.
- Pianifica backup conformi e test di restore.
- Scrivi procedure di incident response.
- Forma il team su policy e procedure.
- Esegui audit annuali e Data Protection Impact Assessment per trattamenti ad alto rischio.
DPA con i fornitori
Ogni fornitore che tratta dati personali per tuo conto (provider hosting, email, backup, CDN) deve firmare un Data Processing Agreement. Verifica che il provider sia in UE o offra garanzie adeguate per trasferimenti extra-UE. Tieni traccia dei sub-processor.
Errori comuni e come risolverli
- Backup non cifrati su S3 USA: dati personali fuori UE senza adeguate garanzie.
- Log di accesso assenti: impossibile dimostrare chi ha fatto cosa.
- Patch dimenticate: vulnerabilita note non chiuse sono violazione manifesta.
- Account condivisi: rendono impossibile l'accountability.
Domande frequenti
D: GDPR richiede ISO 27001?
R: No, ma e una eccellente base per dimostrare conformita.
D: Posso usare AWS USA?
R: Si con clausole tipo + valutazione impatto + cifratura applicativa; meglio regioni EU.
D: Quanto durano i log?
R: Proporzionato alla finalita; tipicamente 6-12 mesi per sicurezza.
Approfondimento tecnico: pseudonimizzazione e cifratura colonnare
La pseudonimizzazione e una misura di sicurezza esplicitamente menzionata nel GDPR (art. 4.5, art. 32). Diversamente dall'anonimizzazione (che rende impossibile risalire all'individuo), la pseudonimizzazione sostituisce dati identificativi con pseudonimi tramite chiavi separate. Tecniche: tokenizzazione, hashing con sale, cifratura deterministica per ricerca. Pseudonimizzare riduce il rischio in caso di breach e puo facilitare elaborazioni per finalita compatibili.
La cifratura colonnare (campo per campo) e più granulare della cifratura del filesystem: il server applicativo cifra i campi sensibili (numero carta, codice fiscale, dati sanitari) prima di scriverli al DB. Chiavi gestite da KMS dedicati (Hashicorp Vault, AWS KMS). Anche con DB compromesso, i campi cifrati restano illeggibili.
Scenari d'uso reali
Una app sanitaria pseudonimizza pazienti con ID interni; mapping ID -> dati personali in DB separato con accesso ristretto.
Un e-commerce tokenizza i numeri carta affidando il dato al PSP certificato PCI-DSS: il server non vede mai il PAN.
Una HR cripta campi salary e SSN in DB con chiave KMS rotata semestralmente.
Checklist operativa GDPR tecnica
- Cifratura at-rest e in-transit.
- MFA per accessi privilegiati.
- Log centralizzati con retention adeguata.
- Backup cifrati lato client.
- Patch management documentato.
- DPA con ogni fornitore.
- Registro trattamenti aggiornato.
Risorse e riferimenti
Regolamento UE 2016/679 testo integrale. Garante Privacy provvedimenti generali. ENISA Guidelines on security measures. ISO 27001 e ISO 27701 per privacy management. Strumenti: OneTrust, iubenda per privacy management.
Considerazioni economiche e organizzative
Implementare correttamente quanto descritto in questo articolo su gdpr e server richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.
Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.
Glossario rapido dei termini chiave
RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).
Hai bisogno di aiuto?
Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.