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,7 +13,7 @@
|
|||
|
||||
* **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);
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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