Il recente provvedimento della Autorità Garante Privacy 9978728, titolato “Programmi e servizi informatici di gestione della posta elettronica nel contesto lavorativo e trattamento dei metadati“, nelle intenzioni della Autorità “documento di indirizzo”, sta invece suscitando una serie di interrogativi e problematiche da risolvere urgentemente.
MA ANDIAMO CON ORDINE.
Il provvedimento del 21 dicembre 2023 affonda le sue radici in altri precedenti provvedimenti, come il 5408460 – Trattamento di dati personali dei dipendenti mediante posta elettronica e altri strumenti di lavoro del 13 luglio 2016, ma sopratutto la più recente Ordinanza di ingiunzione nei confronti di Regione Lazio – 1 dicembre 2022 – num. 9833530 a carico di Regione Lazio,
Nella ordinanza, il Garante ha sanzionato l’illecito monitoraggio effettuato dalla Regione di e-mail inviate da alcuni dipendenti, sfruttando i meta-dati generati dalla infrastruttura informatica e conservati sino a 180 giorni per finalità di sicurezza.
Il core del provvedimento 9978728 è al seguente considerando:
CONSIDERATO che nell’ambito di accertamenti condotti dal Garante con riguardo ai trattamenti di dati personali effettuati nel contesto lavorativo è emerso il rischio che programmi e servizi informatici per la gestione della posta elettronica, commercializzati da fornitori in modalità cloud, possano raccogliere, per impostazione predefinita, in modo preventivo e generalizzato, i metadati relativi all’utilizzo degli account di posta elettronica in uso ai dipendenti (ad esempio, giorno, ora, mittente, destinatario, oggetto e dimensione dell’email), conservando gli stessi per un esteso arco temporale; ciò talvolta ponendo, altresì, limitazioni al cliente (datore di lavoro) in ordine alla possibilità di modificare le impostazioni di base del programma informatico al fine di disabilitare la raccolta sistematica di tali dati o di ridurre il periodo di conservazione degli stessi …
Occorre chiarire bene – specialmente ai non addetti ai lavori – cosa siano questi meta-dati, in quanto abbiamo letto alcuni post nei quali si afferma che per essere compliant al documento di indirizzo occorre cancellare le e-mail aziendali che i dipendenti hanno prodotto – nello svolgimento della propria prestazione lavorativa – dopo 7 giorni.
Precisiamo che non si tratta di “caselle dei dipendenti“, ma di caselle e-mail aziendali, affidate loro per rendere la prestazione lavorativa. Occorre sempre ricordarlo in quanto molti dipendenti ancora non hanno ben compreso che non si tratta della “loro casella di posta elettronica“.
COSA SONO I META-DATI
Wikipedia descrive un metadato come “un dato che descrive una qualche proprietà di un altro dato … in senso lato una informazione a proposito di un’altra informazione“.
Nello specifico del funzionamento dei protocolli di scambio della posta elettronica, si tratta delle informazioni generate durante il flusso delle e-mail e necessarie al normale funzionamento dei vari server di posta (mailserver).
Sono quindi dati informatici generati dai protocolli di comunicazione (smtp, pop3, imap), non riguardano direttamente il contenuto del messaggio, ed in generale contengono le seguenti informazioni ancillari:
- data di invio e ricezione del messaggio (timestamp);
- indirizzo e-mail mittente e destinatario;
- indirizzo IP del mittente che invia al mailserver aziendale;
- la grandezza del messaggio trasferito;
- i protocolli usati durante la sessione e le impostazioni di cifratura adottate;
- i records DNS SPF, DKIM, DMARC, ARC che certificano l’autenticità delle e-mail scambiate;
- lo stato della consegna, degli errori incontrati o del rifiuto del messaggio;
- altre informazioni correlate ai mailserver ed ai componenti software, le configurazioni, ecc.
Di seguito una dimostrazione di log sintetico (verosimile, generato da ChatGPT) di un mailserver fittizio:
Feb 17 2024 14:00:00 postfix/smtpd[54321]: connect from sender.example.com[192.168.1.15]
Feb 17 2024 14:00:02 postfix/smtpd[54321]: Anonymous TLS connection established from sender.example.com[192.168.1.15]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
Feb 17 2024 14:00:03 postfix/smtpd[54321]: 250 2.0.0 Ok: queued as 12345-67890
Feb 17 2024 14:00:03 postfix/qmgr[13579]: 12345-67890: from=<[email protected]>, size=2567, nrcpt=1 (queue active)
Feb 17 2024 14:00:04 postfix/smtpd[54321]: disconnect from sender.example.com[192.168.1.15] ehlo=1 starttls=1 mail=1 rcpt=1 data=1/2 quit=1 commands=6/7 size=2567
Feb 17 2024 14:05:00 dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=192.168.1.30, lip=192.168.1.1, mpid=98765, TLS, session=<abcdefg>
Feb 17 2024 14:10:00 dovecot: pop3-login: Login: user=<[email protected]>, method=PLAIN, rip=192.168.1.40, lip=192.168.1.1, mpid=23456, TLS, session=<hijklmn>
Feb 17 2024 14:15:00 postfix/smtpd[13579]: connect from mail.forwarder.org[192.168.1.50]
Feb 17 2024 14:15:02 postfix/smtpd[13579]: Anonymous TLS connection established from mail.forwarder.org[192.168.1.50]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
Feb 17 2024 14:15:03 postfix/smtpd[13579]: 250 2.0.0 Ok: queued as 2BCDEF-13579
Feb 17 2024 14:15:03 postfix/qmgr[13579]: 2BCDEF-13579: from=<[email protected]>, size=1789, nrcpt=1 (queue active)
Feb 17 2024 14:15:03 postfix/smtpd[13579]: disconnect from mail.forwarder.org[192.168.1.50] ehlo=1 starttls=1 mail=1 rcpt=1 data=1/2 quit=1 commands=6/7 size=1789
Feb 17 2024 14:20:00 postfix/smtpd[98765]: connect from hacker.example.net[192.168.1.55]
Feb 17 2024 14:20:01 postfix/smtpd[98765]: NOQUEUE: reject: RCPT from hacker.example.net[192.168.1.55]: 554 5.7.1 <[email protected]>: Recipient address rejected: Access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<hacker.example.net>
Feb 17 2024 14:20:01 postfix/smtpd[98765]: NOQUEUE: reject: RCPT from hacker.example.net[192.168.1.55]: 554 5.7.1 Service unavailable; Client host [192.168.1.55] blocked using zen.spamhaus.org; https://www.spamhaus.org/query/ip/192.168.1.55; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<hacker.example.net>
Feb 17 2024 14:20:01 postfix/smtpd[98765]: disconnect from hacker.example.net[192.168.1.55] ehlo=1 starttls=0 mail=1 rcpt=0/1 data=0/1 quit=1 commands=3/4
Feb 17 2024 14:25:00 dovecot: pop3-login: Login: user=<[email protected]>, method=PLAIN, rip=192.168.1.55, lip=192.168.1.1, mpid=1234, TLS, session=<a1b2c3>
Feb 17 2024 14:25:01 dovecot: pop3-login: Login: user=<[email protected]>, method=PLAIN, rip=192.168.1.55, lip=192.168.1.1, mpid=5678, TLS, session=<d4e5f6>
Feb 17 2024 14:25:02 dovecot: pop3-login: Disconnected (auth failed, 2 attempts in 2 secs): user=<[email protected]>, method=PLAIN, rip=192.168.1.55, lip=192.168.1.1, TLS, session=<a1b2c3>
Nei log si riscontrano le sessioni di consegna della posta inviata dagli utenti per l’inoltro, quella a loro destinata, gli scambi tra mailservers origine e destinazione, i messaggi marcati come spam o rifiutati, i tentativi di brute-force alle credenziali utente, le scansioni ostili e gli attacchi hacker, e tutta una serie di dati informatici che sono essenziali al regolare funzionamento del sistema di interscambio della posta elettronica mondiale (come SPF-DKIM-DMARC), oltre che ai fini della sicurezza del mailserver, delle comunicazioni intra-mailserver, degli account e-mail e del contenuto delle relative caselle.
Da quanto sinora espresso, comprendiamo bene che “cancellare le e-mail dei dipendenti dopo sette giorni” non solo è totalmente assurdo, ma non rimuove i metadati (in quanto la maggior parte di essi si trova nel mailserver, e la cancellazione di un messaggio di posta non ne rimuove i relativi metadati).
Si consideri anche l’effetto di cancellare i dati di log del mailserver dopo 7 giorni (dove si trovano una parte rilevante dei metadati, e che sono quelli oggetto di attenzione da parte del Garante, ma trascurando che altri metadati sono presenti negli headers delle e-mail contenute nelle cartelle IMAP o del MUA – Mail User Agent del dispositivo utente); diventa impossibile sapere se 8 giorni prima un e-mail è stata realmente consegnata ad un mailserver destinatario, oppure è stata marcata come spam, oppure rifiutata.
Non solo, ma diventa impossibile sapere con certezza se un utente abbia effettivamente inviato un messaggio al mailserver aziendale stesso.
Inoltre tutti i controlli di sicurezza basati sul log del mailserver dovrebbero essere effettuati entro 7 giorni.
Sappiamo anche che spesso le aziende hanno contenziosi correlati alla spedizione (o mancata spedizione) di e-mail, talvolta anche a distanza di mesi dall’invio. Senza disporre dei relativi log del mailserver, diventa impossibile portare davanti ad un giudice quantomeno uno straccio di log del mailserver.
Da ultimo, vorremmo ricordare come esistano obblighi (in carico ad operatori telematici) di data retention, che variano da 6 a 72 mesi.
A complicare ulteriormente la casistica, esistono aziende che sfruttano un servizio mailserver esternalizzato (presso un provider o cloud provider) ed aziende che operano in proprio il mailserver aziendale.
Nel documento di indirizzo della Autorità, si chiede al Titolare di non accedere ai metadati più vecchi di 7 giorni (eventualmente +2), se non per comprovate esigenze, a meno che non sia presente uno specifico accordo sindacale fra l’azienda ed i lavoratori. Perchè questo può comportare un indiretto controllo a distanza dell’attività del lavoratore.
I file di log di un mailserver Linux (i più adottati nel mondo) sono nel percorso /var/log/ e sono accessibili ad ogni amministratore del mailserver.
Come facciamo ad evitare di accedere ai metadati più vecchi di 7 giorni?
La soluzione semplicistica sarebbe cancellarli automaticamente, allo scadere dei 7 giorni; ogni OS server ha dei task ricorrenti e questo è semplicissimo da fare .
A nostro avviso, tale soluzione crea talmente tante serie problematiche, non solo a carico delle organizzazioni (e probabilmente anche a carico dei loro dipendenti, che passati 7 giorni non potranno dimostrare il loro corretto operato di fronte a contestazioni di terzi) ma anche della sicurezza e della integrità di funzionamento delle infrastrutture italiane di interscambio delle e-mail.
SCONSIGLIAMO TASSATIVAMENTE AI NOSTRI CLIENTI DI CANCELLARE I LOG, PASSATI 7 GIORNI.
Se nel caso di aziende che hanno esternalizzato il servizio di posta elettronica aziendale la soluzione è facile (si chiede al provider di limitare l’accesso ai METADATI degli ultimi 7 giorni), per le innumerevoli organizzazioni medio-piccole che gestiscono in-house il mailserver aziendale, la soluzione è molto pIù complessa.
Occorre pertanto trovare – quanto prima – una soluzione logica e praticabile, alla portata delle organizzazioni che hanno un reparto ICT con risorse limitate; sappiamo bene come soluzioni improvvisate siano molto peggio del problema da risolvere.
Questa soluzione non può che passare da un tavolo di confronto con tutti gli stake-holders (titolari del trattamento, sindacati, ispettorato del lavoro, garante privacy, informatici, responsabili della protezione dei dati), sempre tenendo conto del bilanciamento degli interessi in campo.
UPDATE: oggi 27 febbraio, l’Autorità Garante ha emesso un avviso pubblico relativo all’avvio di una consultazione generale sul termine di conservazione dei metadati generati e raccolti automaticamente dai mail-servers; è stato inoltre deciso di differire l’efficacia del documento di indirizzo.
Da parte nostra, abbiamo già ideato una soluzione per rendere compliant al documento di indirizzo il trattamento dei meta-dati nella organizzazioni che gestiscono in proprio il servizio di posta elettronica del loro dominio aziendale.