Ciao Giacomo, Giacomo Tesio <giac...@tesio.it> writes:
[...] > On Fri, 14 Jan 2022 14:46:23 +0100 380° wrote: > >> un server dedicato in un datacentre USA è tecnicamente "tuo" no [0]? > > No. > > Un server dedicato in un datacenter USA è (o meglio _può_essere_, > dipende dal contratto con il fornitore USA) _amministrativamente_ tuo. sì hai ragione [...] > Ma poiché può essere obbligato dalla legge USA a violare il contratto > senza avvertirti, aprendo il case del tuo server e agganciandosi al BUS > di sistema, sì certo [...] >> a meno di FARSI CARICO IN PROPRIO di valutare le misure tecniche, >> ecc. ecc.... è ormai giuridicamente noto che gli USA non sono tra quei >> paesi e /non ci sono/ misure tecniche adeguate per dimostrare di >> essere "GDPR compliant" > > > Poi, come scrivevi, se l'utente autorizza consapevolmente, liberamente > ed esplicitamente il trasferimento, qualsiasi trasferimento è lecito. Se l'ho scritto credo di aver sbagliato: l'utente che risiede in EU autorizza il trattamento (non trasferimento) dei propri dati e il responsabile del trattamento (anche extra EU, ma che opera sul territorio EU) li deve trattare in ottemperanza al GDPR; non c'è bisogno di esplicita autorizzazione al trasferimento, "semplicemente" il trasferimento è /vietato/ verso altre nazioni extra EU che non hanno norme equipollenti a quelle previste dal GDPR (e se non mi sbaglio queste altre nazioni devono essere elencate in un apposito elenchino); gli USA non sono tra queste. [...] > TUTTAVIA, è anche un dato tecnicamente necessario all'erogazione del > servizio (quanto meno sui protocolli HTTPS). sì ma non è tecnicamente necessario memorizzarlo nei log > Quindi non puoi tecnicamente rifiutarne l'invio o evitarne la > ricezione, se intendi usufruire di un servizio che vi si basa. no, ma /in teoria/ potresti rifiutare che venga memorizzato nei log (di /tutti/ quelli che fanno il routing del tuo traffico :-O ) > Essendo tecnicamente necessario per il funzionamento del servizio, non > devi chiedere l'autorizzazione al trattamento per l'IP, effettivamente non mi risulta che nessuno chieda autorizzazione al salvataggio dell'IP nei log... quindi molto probabilmente hai ragione tu... però: [...] > Devi, questo sì, proteggere i log per evitare che vengano diffusi a > terze parti, ma fintanto che li detieni per fini di sicurezza, per > tempi ragionevoli (da qualche parte ho letto 15gg?) etc... non hai > AFAIK grandi attività burocratiche da gestire. Mi sbaglio? no hai ragione, i fini di sicurezza sono sufficienti, ma a che scopo di sicurezza serve tenere l'IP completo dei visitatori alle pagine web di un sito? IMHO è difficile poter dimostrare le necessità di sicurezza e quindi fare a meno del consenso informato. Cosa diversa sono invece le necessità di sicurezza dei server email (per questioni antispam, adottando il graylisting, anche se cominicia a essere superato), dei servizi tipo fail2ban (protezione da tentativi di attacchi brute-force) o di verifica della sicurezza degli accessi via SSH. Alcuni riferimenti: 1. https://www.termsfeed.com/blog/gdpr-log-data/ «GDPR and Log Data» 2. https://www.ctrl.blog/entry/gdpr-web-server-logs.html «EU GDPR and personal data in web server logs» In merito alla "data minimization" il sito 1. sopra indicato riporta: --8<---------------cut here---------------start------------->8--- The Internet Engineering Task Force's Internet Area Working Group (IntArea) has produced some draft guidance which makes a suggestion about how to minimize the data collected for your log files: "keep only the first two octets (of an IPv4 address) or the first three octets (of an IPv6 address) with remaining octets set to zero, when logging" --8<---------------cut here---------------end--------------->8--- Per quanto riguarda quindi i log dei web server, direi che una "best pratice" sarebbe quella di anonimizzare in partenza gli IP. In metrito allo storage sicuro degli altri log necessari ai fini della sicurezza, l'articolo 2. suggerisce: --8<---------------cut here---------------start------------->8--- logrotate is a very useful tool that can be used to encrypt logs in storage even on edge servers, and can help automate the deletion of old log files. It can also be used to encrypt log files in storage which when combined with organizational measures can limit access to decrypting the log files. [...] The server can then use the public key to encrypt its log files without with public key cryptography; resulting in the server being able to encrypt the data without being able to decrypt it without the private. The log files could even be transferred to a centralized log-storage server for cold storage. [...] The logs are still kept unencrypted for up to 24-hours when they were first recorded. This is a small time window when the data isn’t stored encrypted, but it’s required to allow human technicians and automated log analyzing tools (like SSHGuard or Fail2Ban) to process the data and act upon it to help detect and prevent unauthorized or unlawful system access. --8<---------------cut here---------------end--------------->8--- [...] >> P.S.: più il tempo passa più si dimostra che il GDPR serve SOLO a >> rompere le scatole alle brave persone mentre quelli che /catturano/ >> immense quantità di dati personali per profilare il mondo intero, >> Pubblica Amministrazione italiana compresa, continuano imperterriti >> nella loro opera di tracciamento. > > Ma questo è vero SOLO perché non viene applicato. No, questo succede perché il GDPR è la risposta sbagliata a una /gravissima/ carenza tecnica: la completa mancanza di anonimato in rete, ovvero l'IP non è anonimo. Sia chiaro: tutte le persone che hanno progettato, implementato e che cercano di far rispettare il GDPR hanno la mia più sincera stima, ma quello strumento non può funzionare. > E non viene applicato per ignoranza informatica e debolezza politica. Anche se venisse pienamente applicato avrebbe così tante carenze /informatiche/ (i devices /hanno/ backdoors, la rete /è/ un colabrodo) che sarebbe comunque inadeguato; non vale la pena rischiare di perderci la salute per vederlo applicato a un ambiente tecnicamente inadeguato Il succo della mia critica del GDPR è contenuto in un mio messaggio del 13 Dic. scorso https://server-nexa.polito.it/pipermail/nexa/2021-December/022758.html --8<---------------cut here---------------start------------->8--- Il senso profondo di questo progetto (uno dei molti esempi, purtroppo spesso falliti nel tempo per varie ragioni) è che un altro modo di /progettare/ e /implementare/ la tecnologia (digitale in questo caso) è possibile. É ovvio ma purtroppo tocca ribadirlo ogni volta. Io credo che questo modo di procedere, ovvero agire /nella/ tecnologia (dall'interno), sia di almeno un ordine di grandezza più efficace che agire /sulla/ tecnologia (dall'esterno), con regole /estremamente/ difficili da applicare proprio perché /aliene/ allo spazio - il cyberspazio - nel quale le persone /agiscono/ tecnologicamente. --8<---------------cut here---------------end--------------->8--- >> > MAI usare questi servizi "as a Service"! >> >> beh no dai, "su hardware di persone di cui ti fidi" significa "as a >> Service" > > Permettimi di chiarire: quando un'azienda che sviluppa opensource offre > il proprio software come SaaSS [1] (improprimanete detto SaaS), è > sempre meglio installare tale software su server sotto il proprio > controllo fisico ed amministrativo. > > Il fatto che il software sia opensource NON SIGNIFICA AFFATTO che ci si > la versione eseguita da terze parti corrisponda al codice pubblicato. sì certo, è per questo che è importante /compilarlo/ (le distribuzioni software svolgono un servizio di "compilation as a service", il 98% delle quali usando compilatori e librerie già compilate la cui integrità è impossibile da verificare) ed eseguirlo su hardware di persone di cui ti fidi, il vero problema è come si "guadagna" la fiducia. > L'unico modo per garantire la protezione dei dati personali degli > utenti è amministrare il sistema di Analytics come si amministra il > software cui si riferiscono. concordo, con il /caveat/ che purtroppo trasmettere i dati in rete è tecnicamente insicuro... ma questo in genere viene escluso dalla responsabilità di chi tratta i dati personali, perché non ci può fare nulla (almeno se applica le protezioni allo "stato dell'arte") [...] Ciao, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
signature.asc
Description: PGP signature
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
