corrected leftover typos
richardmacduff
parent
7ffc4d318a
commit
82556090b7
|
|
@ -21,7 +21,7 @@
|
|||
* da un singolo dato (esempi: cognome e nome)
|
||||
* dall’incrocio di insiemi di dati (esempio: una donna che vive a un dato indirizzo, nata in una certa data e membro di una data associazione).
|
||||
|
||||
* Alcuni dati sono considerati **particolarmente sensibili**. Il GDPR proibisce la raccolta o l’uso di questi dati a meno che, in particolare, l’interessato abbia dato il proprio consenso (consenso attivo, esplicito e preferibilmente per iscritto, che deve essere libereo, specifico e informato).
|
||||
* Alcuni dati sono considerati **particolarmente sensibili**. Il GDPR proibisce la raccolta o l’uso di questi dati a meno che, in particolare, l’interessato abbia dato il proprio consenso (consenso attivo, esplicito e preferibilmente per iscritto, che deve essere libero, specifico e informato).
|
||||
|
||||
* I requisiti di cui al punto precedente riguardano i seguenti tipi di dati:
|
||||
|
||||
|
|
@ -40,7 +40,7 @@
|
|||
* _collegabilità_: il dataset non consente di collegare due o più record che si riferiscono a uno stesso interessato o a uno stesso gruppo di interessati
|
||||
* _inferenza_: non è possibile dedurre, con probabilità significativa, il valore di un attributo a partire dai valori di un insieme di altri attributi.
|
||||
|
||||
* queste operazioni di trattamento implicano nella maggior parte dei casi una **perdità di qualità del dataset risultante**. L’[opinione sulle tecniche di anonimizzazione](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf) dell Gruppo di Lavoro Articolo 29 (Art. 29 WP) descrive le principali tecniche di anonimizzazione attualmente in uso, nonché esempi di dataset erroneamente considerati anonimi. È importante notare che le tecniche di anonimizzazione hanno delle controindicazioni. La scelta se anonimizzare o meno i dati, nonché la scelta della particolare tecnica di anonimizzazione deve essere fatta caso per caso, sulla base del particolare contesto, dell’uso e delle necessità (natura dei dati, utilità dei dati, rischi per le persone, ecc.) .
|
||||
* queste operazioni di trattamento implicano nella maggior parte dei casi una **perdita di qualità del dataset risultante**. L’[opinione sulle tecniche di anonimizzazione](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf) del Gruppo di Lavoro Articolo 29 (Art. 29 WP) descrive le principali tecniche di anonimizzazione attualmente in uso, nonché esempi di dataset erroneamente considerati anonimi. È importante notare che le tecniche di anonimizzazione hanno delle controindicazioni. La scelta se anonimizzare o meno i dati, nonché la scelta della particolare tecnica di anonimizzazione deve essere fatta caso per caso, sulla base del particolare contesto, dell’uso e delle necessità (natura dei dati, utilità dei dati, rischi per le persone, ecc.) .
|
||||
|
||||
|
||||
## Pseudonimizzazione di dati personali
|
||||
|
|
@ -49,6 +49,6 @@
|
|||
|
||||
* Si riferisce al trattare i dati personali in modo che **dati che si riferiscono a una persona fisica non possano più essere attribuiti ad essa senza l'uso di informazioni aggiuntive**. Il GDPR insiste che tali informazioni aggiuntive debbano essere conservate separatamente e soggette a misure tecniche e organizzative volte a evitare la re-identificazione degli interessati. A differenza dell'anonimizzazione, la pseudonimizzazione può essere un processo reversibile.
|
||||
|
||||
* In pratica, un processo di pseudonimizzazione consiste nel **sostituire in un dataset i dati immediatamente identificanti (cognome, nome, ecc.) con dati indirettamente identificanti** (pseudonimo, numero di pratica, ecc.) allo scopo di ridurre la loro sensibilità. Questi dati indiretttamente identificanti potrebbero essere il risultato di un hash crittografico dei dati degli individui, come l'indirizzo IP, la user ID, l'indirizzo e-mail.
|
||||
* In pratica, un processo di pseudonimizzazione consiste nel **sostituire in un dataset i dati immediatamente identificanti (cognome, nome, ecc.) con dati indirettamente identificanti** (pseudonimo, numero di pratica, ecc.) allo scopo di ridurre la loro sensibilità. Questi dati indirettamente identificanti potrebbero essere il risultato di un hash crittografico dei dati degli individui, come l'indirizzo IP, la user ID, l'indirizzo e-mail.
|
||||
|
||||
* I dati risultanti dalla pseudonimizzazione sono considerati come **dati personali e pertanto soggetti alle prescrizioni del GDPR**. Ad ogni modo, il Regolamento Europeo incoraggia l'uso della pseudonimizzazione nel trattamento di dati personali. Inoltre il GDPR ritiene che la pseudonimizzazione renda possibile ridure il rischio per gli interessati e contribuisca alla compliance con il Regolamento.
|
||||
* I dati risultanti dalla pseudonimizzazione sono considerati come **dati personali e pertanto soggetti alle prescrizioni del GDPR**. Ad ogni modo, il Regolamento Europeo incoraggia l'uso della pseudonimizzazione nel trattamento di dati personali. Inoltre il GDPR ritiene che la pseudonimizzazione renda possibile ridurre il rischio per gli interessati e contribuisca alla compliance con il Regolamento.
|
||||
|
|
|
|||
|
|
@ -26,6 +26,6 @@
|
|||
* **Usa standard di programmazione che tengono in conto la sicurezza**. Spesso sono già disponibili liste di standard, buone pratiche o guide di programmazione per migliorare la sicurezza dei tuoi sviluppi. Puoi anche integrare tool aggiuntivi nel tuo ambiente integrato di sviluppo (“**IDE**”) in modo da controllare in automatico che il tuo codice corrisponda alle regole dettate dagli standard e dalle buone pratiche. Su Internet puoi facilmente reperire elenchi di buone pratiche per i tuoi linguaggi di programmazione preferiti. Per esempio [qui](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards) per C, C++ o Java. Esistono anche buone pratiche specifiche per lo sviluppo di applicazioni Web, come quelle pubblicate da [OWASP](https://www.owasp.org).
|
||||
* **Le scelte tecnologiche sono critiche**. Alcuni aspetti che devi tenere in conto:
|
||||
* A seconda del campo di applicazione o della funzionalità sviluppata, uno specifico linguaggio o tecnologia potrebbe essere più appropriato di un altro.
|
||||
* I linguaggi e le tecnologie più maturi sono più sicuri. In generale, sono stati soggetti a audit per correggere le vulerabilità più note. Ad ogni modo, devi fare attenzione a usare le ultime versioni di ciascun componente tecnologico che userai.
|
||||
* I linguaggi e le tecnologie più maturi sono più sicuri. In generale, sono stati soggetti a audit per correggere le vulnerabilità più note. Ad ogni modo, devi fare attenzione a usare le ultime versioni di ciascun componente tecnologico che userai.
|
||||
* Devi evitare di scrivere la tua soluzione in un linguaggio che hai appena imparato e non domini ancora completamente. La tua mancanza di esperienza potrebbe esporti a maggiori rischi.
|
||||
* **Appronta un ambiente di sviluppo sicuro che ti consenta la gestione delle versioni del codice** seguendo la [scheda dedicata](#Sheet_n°3:_Secure_your_development_environment) di questa guida.
|
||||
|
|
|
|||
|
|
@ -13,15 +13,15 @@
|
|||
|
||||
* **Segui le [raccomandazioni CNIL per le password](https://www.cnil.fr/fr/node/23803)**. In particolare, ricordati di mettere un limite al numero di tentativi di accesso.
|
||||
|
||||
* **Non archiviare mai le passowrd in chiaro**. Memorizza il loro hash usando una libreria consolidata, come [bcrypt](https://en.wikipedia.org/wiki/Bcrypt).
|
||||
* **Non archiviare mai le password in chiaro**. Memorizza il loro hash usando una libreria consolidata, come [bcrypt](https://en.wikipedia.org/wiki/Bcrypt).
|
||||
|
||||
* **Se usi cookie per l’autenticazione**, ti raccomandiamo:
|
||||
* di forzare l’uso di HTTPS tramite [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security);
|
||||
|
||||
|
||||
* di usare il flag `secure`;
|
||||
|
||||
|
||||
* usa il flag `HttpOnly`.
|
||||
|
||||
|
||||
* **Testa le librerire di crittografia installate sui tuoi sistemi** e disabilita quelle obsolete (RC4, MD4, MD5 etc.). Incoraggia l’utilizzo di AES256. [Leggi le note di OWASP al riguardo](https://owasp.org/www-project-cheat-sheets/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html).
|
||||
|
||||
* **Adotta una politica specifica per le password degli amministratori**. Come minimo, cambia le loro password ogni volta che un amministratore lascia il lavoro, e comunque sempre in caso di sospetta violazione della sicurezza.
|
||||
|
|
@ -48,5 +48,5 @@
|
|||
|
||||
* per l’accesso al database **usare account nominativi ** e creare account specifici per ciascuna applicazione;
|
||||
* **revoca i privilegi di amministratore** degli account (utente o applicativo) per evitare modifiche alla struttura del database (tabelle, viste, processi, ecc.);
|
||||
* assicurati di proteggerti contro attacchi di tipo SQL injection o *script injection;
|
||||
* assicurati di proteggerti contro attacchi di tipo SQL injection o *script injection*;
|
||||
* incoraggia la cifratura a riposo di dischi e database.
|
||||
|
|
|
|||
|
|
@ -8,9 +8,9 @@
|
|||
|
||||
* **Scegli software, librerie e SDK che vengono mantenuti:**
|
||||
* Se vuoi usare software libero o open source, scegli progetti o soluzioni con una comunità attiva di utenti, aggiornamenti regolari e buona documentazione.
|
||||
|
||||
|
||||
* Se usi altri tipi di soluzioni con un supporto commerciale, assicurati contrattualmente che il codice sia mantenuto e aggiornato per la durata di vita del tuo progetto.
|
||||
|
||||
|
||||
* **Tieni in considerazione la privacy.** Alcune librerie e alcuni SDK si ripagano usando i dati personali raccolti dalle applicazioni e dai siti in cui sono integrati. Assicurati che queste terze parti rispondano alle leggi applicabili sui dati personali, inclusa la corretta raccolta del consenso.
|
||||
|
||||
* **Se usi meccanismi crittografici, ti sconsigliamo fortemente di implementarti da solo gli algoritmi di cifratura**, piuttosto scegli librerie crittografiche che sono riconosciute, mantenute e semplici da usare.
|
||||
|
|
|
|||
|
|
@ -20,23 +20,23 @@
|
|||
|
||||
* **Queste condizioni, specificate nelle [linee guida per i cookie e altri tracciatori (in Inglese)](https://www.cnil.fr/en/cookies-and-other-tracking-devices-cnil-publishes-new-guidelines), sono**:
|
||||
* Informare gli utenti del loro uso;
|
||||
|
||||
|
||||
* Dare loro la possibilità di non acconsentire al loro uso;
|
||||
|
||||
|
||||
* Limitarsi ai soli scopi che seguono:
|
||||
|
||||
|
||||
* misurazione del pubblico;
|
||||
|
||||
* A/B testing;
|
||||
|
||||
* Non incrociare i dati trattati con altri trattamenti (schede cliente, statistiche sulle visite ad altri siti, ecc.);
|
||||
|
||||
|
||||
* Limitare lo scopo del tracciatore a un singolo sito o applicazione;
|
||||
|
||||
|
||||
* troncare l’ultimo bit dell’indirizzo IP;
|
||||
|
||||
|
||||
* Limitare la vita del tracciatore a 13 mesi.
|
||||
|
||||
|
||||
* Se queste condizioni sono soddisfatte, possiamo **passare da un regime opt-in (soggetto a consenso) a un regime opt-out**.
|
||||
|
||||
* È anche possibile che una singola terza parte (fornitore) fornisca un servizio di misura comparativa del pubblico per più siti o applicazioni, a patto che **i dati siano raccolti, trattati e registrati indipendentemente per ciascun sito o applicazione e che i tracciatori siano indipendenti l’uno dall’altro.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
#### Al fine di aiutare gli sviluppatori di applicativi e di siti web a rendere il loro lavoro rispondente ai requisiti del GDPR, lo CNIL ha redatto una nuova guida alle buone pratiche sotto licenza aperta, in modo che possa essere arricchita da altri professionisti.
|
||||
|
||||
Questa guida è pubblicata con [licenza GPLv3](https://www.gnu.org/licenses/gpl-3.0.html) e [open license 2.0](https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf) (esplicitamente compatibile con [CC-BY 4.0 FR](https://creativecommons.org/licenses/by/4.0/deed.fr)). Potete contribuire liberamente alla sua reedazione.
|
||||
Questa guida è pubblicata con [licenza GPLv3](https://www.gnu.org/licenses/gpl-3.0.html) e [open license 2.0](https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf) (esplicitamente compatibile con [CC-BY 4.0 FR](https://creativecommons.org/licenses/by/4.0/deed.fr)). Potete contribuire liberamente alla sua redazione.
|
||||
|
||||
La [versione francese](https://github.com/LINCnil/Guide-RGPD-du-developpeur) è la versione autentica di questa guida.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue