Initial commit of italian version
Co-authored-by: richardmacduff <ipse@waltervannini.it>it
LINC
parent
52d1d18a3d
commit
57349380a5
|
|
@ -1,19 +0,0 @@
|
|||
# Sheet n°0: Develop in compliance with the GDPR
|
||||
|
||||
#### Whether you work alone, are part of a team developing a project, manage a development team, or are a service provider carrying out developments for third parties, it is essential to ensure that user data and all personal data processing are sufficiently protected throughout the lifecycle of the project.
|
||||
|
||||
The following steps will help you in developing privacy-friendly applications or websites:
|
||||
|
||||
1. **Be aware of the GDPR core principles**. If you work in a team, we recommend that you identify a person responsible for monitoring compliance. If your company has a Data Protection Officer (DPO), then that person is a key asset in [understanding and meeting the GDPR obligations](https://www.cnil.fr/sites/default/files/atoms/files/guidelines_on_dpos_5_april_2017.pdf). The appointment of a DPO may also be mandatory in some cases, for example if your programs or applications process so-called "sensitive" data (see [examples](#Sheet_n°1:_Identify_personal_data)) on a large scale or conduct regular and systematic monitoring on a large scale.
|
||||
|
||||
2. **Map and categorize the data and processing in your system**. Accurately mapping the data processing performed by your program or application will help you ensuring that they comply with legal requirements. Keeping a [record of processing activities](https://www.cnil.fr/en/record-processing-activities) (an example of which can be found on the [CNIL website](https://www.cnil.fr/sites/default/files/atoms/files/record-processing-activities.ods)), allows you to have an overall view of these data, and to identify and prioritize the associated risks. Indeed, personal data may be present in unexpected places such as in server logs, cache files, Excel files, etc., and may be stored in a number of different places. Such record-keeping is mandatory in most cases.
|
||||
|
||||
3. **Prioritize the required actions**. On the basis of the data processing registry, identify the required actions to comply with the obligations of the GDPR in advance of the development and prioritize the attention points with regard to the risks that the processing carries for the data subjects. These points of attention concern in particular [the necessity and types of data collected and processed](#Sheet_n°7:_Minimize_the_data_collection) by your software, [the legal basis](#Sheet_n°15:_Take_into_account_the_legal_basis_in_the_technical_implementation) on which your data processing operations are based, [the information mentions](#Sheet_n°12:_Inform users) of your software or application, [the contractual clauses](#Sheet_n°5_:_Make_an_informed_choice_of_its_architecture) binding you to your contractors, the terms and conditions for [exercising rights](#Sheet_n°13:_Prepare_for_the_exercise_of_people_rights), the measures implemented to [secure your processing](#Sheet_n°6:_Secure_your_websites,_applications_and_servers).
|
||||
|
||||
4. **Manage the risks**. When you find out that a processing of personal data is likely to create high risks for data subjects, make sure that you manage those risks appropriately in the context. A [Privacy Impact Assessment (PIA) ](https://www.cnil.fr/en/privacy-impact-assessment-pia) can help you manage those risks. The CNIL has developed a [method](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-1-en-methodology.pdf), [model documents](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-2-en-templates.pdf) and a [tool](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment) that will help you to identify those risks, as well as a [catalogue of good practices](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-3-en-knowledgebases.pdf) that will assist you in implementing measures to address the identified risks. Furthermore, a Privacy Impact Assessment is mandatory for all processing operations that are likely to create high risks to the rights and freedoms of data subjects. The CNIL proposes, on its [website](https://www.cnil.fr/sites/default/files/atoms/files/liste-traitements-aipd-requise.pdf), a list of types of processing operations for which a DPA is required or not.
|
||||
|
||||
5. **Put in place internal processes** to ensure compliance during all development stages, ensure that internal procedures guarantee that data protection is taken into account in all aspects of your project and for all events that may occur (e.g. security breach, requests for rectification or access fulfillment, modification of data collected, change of provider, data breach, etc.). The requirements of the [governance label](https://www.cnil.fr/sites/default/files/typo/document/CNIL_Privacy_Seal-Governance-EN.pdf) (even if this one is no longer granted by the CNIL since the entry into force of the GDPR) can constitute a useful basis of inspiration to help you set up the necessary organization.
|
||||
|
||||
6. **Document developments compliance** to prove your compliance with the GDPR at all times: the actions performed and the documents produced at each stage of development must be mastered. This implies in particular a regular review and update of the documentation of your developments so that it is constantly consistent with the features deployed on your program.
|
||||
|
||||
The CNIL website provides numerous practical files which will assist you in setting up law-abiding treatments according to your sector of activity.
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
# Scheda n°0: Sviluppa rispondendo al GDPR
|
||||
|
||||
#### Sia che tu lavori da solo, che tu sia parte di un gruppo di progetto, che tu gestisca un gruppo di sviluppatori, o che tu sia un fornitore di servizi che sviluppa per conto terzi, è essenziale che tu ti assicuri che i dati degli utenti e tutti i trattamenti di dati personali siano sufficientemente protetti durante tutto il ciclo di vita del progetto.
|
||||
|
||||
Questi passi ti aiuteranno a sviluppare applicativi e siti web che siano privacy-friendly:
|
||||
|
||||
1. **Sii consapevole dei principi cardine del GDPR**. Se lavori in un team, raccomandiamo che tu identifichi una persona responsabile di monitorare la compliance. Se la tua azienda ha un RPD/DPO (Responsabile della Protezione Dati/Data Protection Officer) allora quella persona è una risorsa fondamentale per [comprendere e rispondere agli obblighi del GDPR](https://www.cnil.fr/sites/default/files/atoms/files/guidelines_on_dpos_5_april_2017.pdf). La nomina di un RPD in alcuni casi potrebbe essere obbligatoria, per esempio se i tuoi programmi o le tue app trattano dati cosiddetti “particolari” (vedi [esempi](#Scheda_n°1:_Individuare i dati personali)) su larga scala o se effettuano monitoraggi regolari e sistematici su larga scala o se lavori per una pubblica amministrazione.
|
||||
2. **Mappa e categorizza i dati e i trattamenti nel tuo sistema**. Una mappatura accurata dei trattamenti effettuati dal tuo programma o app ti aiuterà a garantire che rispondano ai requisiti di legge. Mantenere un [registro delle attività di trattamento](https://www.cnil.fr/en/record-processing-activities) (un esempio lo puoi trovare sul [sito di CNIL](https://www.cnil.fr/sites/default/files/atoms/files/record-processing-activities.ods)) ti permette di avere una visione d’insieme di questi dati, e di individuare e prioritizzare i rischi associati. Peraltro, dati personali potrebbero essere presenti in posti inattesi come server log, file di cache, file Excel, ecc., o potrebbero essere archiviati in una quantità di luoghi diversi. Nella maggior parte dei casi, la tenuta di un registro di questo tipo è obbligatoria.
|
||||
3. **Prioritizza le azioni necessarie**. Sulla base del registro delle attività di trattamento, identifica prima dello sviluppo le azioni necessarie per rispondere agli obblighi del GPDR e prioritizza i punti di attenzione relativi ai rischi per gli interessati dal trattamento. Questi punti di attenzione riguardano in particolare [la necessità e i tipi di dati raccolti e trattati](#Sheet_n°7:_Minimize_the_data_collection) dal tuo software, [le basi giuridiche](#Sheet_n°15:_Take_into_account_the_legal_basis_in_the_technical_implementation) su cui si basano le tue operazioni di trattamento, [le informative](#Sheet_n°12:_Inform users) del tuo software o app, [le clausole contrattuali](#Sheet_n°5_:_Make_an_informed_choice_of_its_architecture) che ti legano ai tuoi fornitori, i termini e le condizioni per [esercitare i diritti](#Sheet_n°13:_Prepare_for_the_exercise_of_people_rights), e le misure implementate per [la sicurezza dei trattamenti](#Sheet_n°6:_Secure_your_websites,_applications_and_servers).
|
||||
4. **Gestisci i rischi**. Quando determini che un trattamento di dati personali può creare rischi elevati per gli interessati, assicurati di gestire i rischi in modo appropriato al contesto. Un [Privacy Impact Assessment (PIA) ](https://www.cnil.fr/en/privacy-impact-assessment-pia) può aiutarti a gestirli. La CNIL ha sviluppato un [metodo](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-1-en-methodology.pdf), dei [modelli di documento](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-2-en-templates.pdf) e un [tool](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment) che ti aiuteranno a individuare i rischi nonché un [catalogo di buone pratiche](https://www.cnil.fr/sites/default/files/atoms/files/cnil-pia-3-en-knowledgebases.pdf) che ti assisterà nella implementazione delle misure per rispondere ai rischi che avrai identificato. Inoltre, un Privacy Impact Assessment è obbligatorio per tutti quei trattamenti che possono creare rischi gravi peri diritti e le libertà degli interessati. Lo CNIL propone, sul suo [sito](https://www.cnil.fr/sites/default/files/atoms/files/liste-traitements-aipd-requise.pdf), un elenco dei tipi di trattamento per i quali un Privacy Impact Assessment è obbligatorio. Un analogo elenco è disponibile sul sito del Garante.
|
||||
5. **Attiva dei processi interni** per garantire la compliance durante tutte le fasi dello sviluppo, assicura che ci siano procedure interne per garantire che la protezione dei dati sia tenuta in conto in tutti gli aspetti del progetto e a fronte di qualsiasi evento possa verificarsi (ad es. falla di sicurezza, risposta a richieste di rettifica o di accesso, modifica dei dati raccolti, cambio di fornitore, trafugamento di dati, ecc.). I requisiti alla base dell’[etichetta di governance](https://www.cnil.fr/sites/default/files/typo/document/CNIL_Privacy_Seal-Governance-EN.pdf) (anche se non viene più rilasciata da CNIL dopo l’entrata in vigore del GDPR) possono costituire una utile base per aiutarti a definire le necessarie misure organizzative.
|
||||
6. **Documenta la compliance dello sviluppo** per dimostrare in ogni momento la tua compliance al GDPR: ci deve essere piena consapevolezza delle azioni compiute e dei documenti prodotti a ciascuno stadio dello sviluppo. Questo implica in particolare la periodica revisione e l’aggiornamento della documentazione così da renderla sempre consistente con le caratteristiche del tuo programma.
|
||||
|
||||
Il sito di CNIL fornisce numerosi esempi pratici che ti assisteranno, a seconda del tuo settore di attività, nella definizione di trattamenti dati rispondenti alla legge.
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
# Sheet n°1: Identify personal data
|
||||
|
||||
#### Understanding the notions of "personal data", "purpose" and "processing" is essential to ensure that software complies with the law when it processes user data. In particular, be careful not to confuse "anonymisation" and "pseudonymization", which have very precise and different definitions in the GDPR.
|
||||
|
||||
## Definition
|
||||
* The notion of **personal data** is defined in the [General Data Protection Regulation](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679) (GDPR) as "[any information relating to an identified or identifiable natural person (referred to as "data subject")](https://www.cnil.fr/en/personal-data-definition)". It covers a broad scope that includes both directly identifying data (e.g. first and last name) and indirectly identifying data (e.g. telephone number, license plate, terminal identifier, etc.).
|
||||
|
||||
* Any operation on this type of data (collection, recording, transmission, modification, dissemination, etc.) constitutes **processing within the meaning of the GDPR** and must therefore meet the requirements laid down by that regulation. Such processing operations must be lawful and have a specified purpose. The personal data collected and processed must be relevant and limited to what is strictly necessary to achieve the purpose.
|
||||
|
||||
## Examples of personal data
|
||||
|
||||
* Where they relate to natural persons, **the following data are personal data**:
|
||||
* Surname, first name, pseudonym, date of birth;
|
||||
* photos, sound recordings of voices;
|
||||
* fixed or mobile telephone number, postal address, email address;
|
||||
* IP address, computer connection identifier or cookie identifier;
|
||||
* Fingerprint, palm or venous network of the hand, retinal print;
|
||||
* License plate number, social security number, ID number;
|
||||
* Application usage data, comments, etc...
|
||||
|
||||
* **Identification of natural persons can be carried out**:
|
||||
* from a single piece of data (examples: surname and first name);
|
||||
* from crossing of a set of data (example: a woman living at such and such an address, born on such and such a day and member of such and such an association).
|
||||
|
||||
* Some data are considered **particularly sensitive**. The GDPR prohibits the collection or use of such data, unless, in particular, all involved data subjects have given their express consent (active, explicit and preferably written consent, which must be free, specific and informed).
|
||||
|
||||
* These requirements concern the following data:
|
||||
|
||||
* data relating to the **health of individuals**;
|
||||
* data concerning **sexual life** or **sexual orientation**;
|
||||
* data revealing an alleged **racial** or **ethnic** origin;
|
||||
* political opinions, religious beliefs, philosophical beliefs or trade union membership;
|
||||
* **genetic** and **biometric data used for the purpose of uniquely identifying an individual**.
|
||||
|
||||
## Anonymisation of personal data
|
||||
|
||||
* An **anonymisation process of personal data** aims at making impossible to identify individuals within data sets. It is therefore an irreversible process. When this anonymisation is effective, the data are no longer considered as personal data and the requirements of the GDPR are no longer applicable.
|
||||
|
||||
* By default, we recommend that you **never consider raw datasets as anonymous**. Anonymisation results from processing personal data in order to irreversibly prevent identification, whether by:
|
||||
|
||||
* _singling out_: it is not possible to isolate some or all records which identify an individual in the dataset;
|
||||
* _linkability_: the dataset does not allow to link together two or more records concerning the same data subject or a group of data subjects;
|
||||
* _inference_: it is not possible to infer, with significant probability, the value of an attribute from the values of a set of other attributes.
|
||||
|
||||
* These data processing operations imply in most cases a **loss of quality on the produced dataset**. The Article 29 Working Party (Art. 29 WP) [opinion on anonymisation techniques](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf) describes the main anonymisation techniques used today, as well as examples of datasets wrongly considered anonymous. It is important to note that anonymisation techniques have short comings. The choice whether or not to anonymize the data as well as the choice of an anonymisation technique must be made on a case-by-case basis according to the different contexts of use (nature of the data, usefulness of the data, risks for people, etc.).
|
||||
|
||||
|
||||
## Pseudonymization of personal data
|
||||
|
||||
* **Pseudonymization is a compromise between retaining raw data and producing anonymized datasets**.
|
||||
|
||||
* It refers to the processing of personal data in such a way that **data relating to a natural person can no longer be attributed without additional information**. The GDPR insists that this additional information must be kept separately and be subject to technical and organisational measures to avoid re-identification of data subjects. Unlike anonymisation, pseudonymization can be a reversible process.
|
||||
|
||||
* In practice, a pseudonymization process consists in **replacing directly identifying data (surname, first name, etc.) in a dataset with indirectly identifying data** (alias, number in a filing system, etc.) in order to reduce their sensitivity. They may result from a cryptographic hash of the data of individuals, such as their IP address, user ID, e-mail address.
|
||||
|
||||
* Data resulting from pseudonymization are considered as **personal data and therefore remain subject to the obligations of the DPMR**. However, the European Regulation encourages the use of pseudonymization in the processing of personal data. Moreover, the GDPR considers that pseudonymization makes it possible to reduce the risks for data subjects and to contribute to compliance with the Regulation.
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
# Scheda n°1: Individua i dati personali
|
||||
|
||||
#### Comprendere i concetti di “dato personali”, “scopo” e “trattamento” è essenziale per sviluppare trattamenti rispondenti ai requisiti di legge. In particolare, stai attento a non confondere “anonimizzazione” e “pseudonimizzazione”, che sono definiti con molta precisione nel GDPR.
|
||||
|
||||
## Definizione
|
||||
* Il concetto di **dato personale** è definito nel [Regolamento Generale per la Protezione dei Dati Personali](https://eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=CELEX:32016R0679&from=IT) come *“qualsiasi informazione riguardante una persona fisica identificata o identificabile («interessato»)”*. La definizione copre un ambito vasto che include tanto dati che identificano direttamente (ad es. nome e cognome) quanto dati che identificano indirettamente (ad es, numero di telefono, targa dell’auto, identificativo del terminale, ecc.).
|
||||
* Qualsiasi operazione su dati di questo tipo (raccolta, registrazione, trasmissione, modifica, disseminazione, ecc.) costituisce **trattamento ai sensi dei GDPR** e deve quindi rispondere ai requisiti definiti dalla legge. Queste operazioni di trattamento devono essere lecite e avere una finalità specificata. I dati personali raccolti e trattati devono essere rilevanti e limitati a quelli strettamente necessari per raggiungere la finalità prefissata.
|
||||
|
||||
## Esempi di dati personali
|
||||
|
||||
* Quando si riferiscono a persone fisiche, **i seguenti dati sono dati personali**:
|
||||
* Cognome, nome, pseudonimo, data di nascita
|
||||
* foto e registrazioni della voce
|
||||
* numero di telefono fisso o mobile, indirizzo postale, indirizzo email
|
||||
* indirizzo IP, identificatore di connessione telematica o cookie identificativo
|
||||
* Impronta digitale, impronta del palmo o reticolo venoso della mano, impronta retinica
|
||||
* Targa automobilistica, codice fiscale, numero di matricola
|
||||
* Dati di utilizzo dell’applicazione, commenti, ecc.
|
||||
|
||||
* **L’identificazione di persone fisiche si può ottenere**:
|
||||
* 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, libero, specifico e informato).
|
||||
|
||||
* I requisiti di cui al punto precedente riguardano i seguenti tipi di dati:
|
||||
|
||||
* dati relativi alla **salute degli individui**
|
||||
* dati relativi alla **vita sessuale** o **all’orientamento sessuale**
|
||||
* dati che possono rivelare una (anche presunta) origine **razziale** o **etnica**
|
||||
* opinioni politiche, credo religiosi, convinzioni filosofiche o appartenenza a sindacati
|
||||
* dati **genetici** e **biometrici usati allo scopo di identificare in modo univoco un individuo**.
|
||||
|
||||
## Anonimizzazione di dati personali
|
||||
|
||||
* Un **processo di anonimizzazione di dati personali** mira a rendere impossibile, a meno di uno sforzo ritenuto irragionevole, l’identificazione degli individui appartenenti al dataset. Quando questa anonimizzazione riesce, i dati non sono più considerati dati personali e le prescrizioni del GDPR non si applicano più.
|
||||
|
||||
* Di default, ti raccomandiamo di **non considerare mai anonimi dei dataset sui quali non è stata applicata alcuna tecnica di anonimizzazione.** L’anonimizzazione è il risultato del trattamento di dati personali al fine di prevenire l’identificazione. Una tecnica di anonimizzazione deve evitare che i seguenti eventi possano verificarsi :
|
||||
* _individuazione_: non è possibile isolare uno o tutti i record del dataset che identificano un individuo
|
||||
* _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 **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_it.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.) .
|
||||
|
||||
|
||||
## Pseudonimizzazione di dati personali
|
||||
|
||||
* **La pseudonimizzazione è un compromesso fra mantenere i dati nella loro forma originale e produrre dataset anonimizzati**.
|
||||
|
||||
* Si riferisce al trattamento di 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 rimarca che tali informazioni aggiuntive debbano essere conservate separatamente e soggette a misure tecniche e organizzative volte a evitare la re-identificazione degli interessati. 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 il loro potere identificativo. Questi dati indiretttamente identificativi potrebbero essere il risultato di un hash crittografico di dati degli personali, 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.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Scheda n°2: Prepara lo sviluppo
|
||||
|
||||
#### I principi della protezione dei dati personali devono essere integrati negli sviluppi IT dalla fase di design in poi, al fine di proteggere la privacy delle persone i cui dati verranno trattati, per dare loro un maggior controllo sui loro dati e per limitare errori, perdite, modifiche non autorizzate o abusi dei loro dati nelle applicazioni.
|
||||
|
||||
## Scelte metodologiche
|
||||
|
||||
* **Metti la protezione della privacy al centro dei tuoi sviluppi** adottando una metodologia di [Privacy By Design](https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2019/guidelines-42019-article-25-data-protection-design_it).
|
||||
|
||||
* Considera di **integrare la sicurezza al centro dei processi**. ANSSI rende disponibile una guida ["digital security & agility"](https://www.ssi.gouv.fr/uploads/2018/11/guide-securite-numerique-agile-anssi-pa-v1.pdf) (solo in Francese) che indica come portare avanti gli sviluppi nell’ambito di un framework agile tenendo in conto gli aspetti di sicurezza. Prendila come fonte di ispirazione.
|
||||
|
||||
* Per ogni sviluppo rivolto al grande pubblico, **considera i setting di sicurezza** e in particolare i valori di default come, per esempio, le caratteristiche e i contenuti utente visibili per default.
|
||||
|
||||
* **Conduci un [Privacy Impact Assessment (PIA)](https://www.cnil.fr/en/privacy-impact-assessment-pia)**. Per [alcune operazioni di trattamento](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-impact-assessments/) è obbligatorio. In altri casi costituisce una buona pratica che ti permetterà di individuare e affrontare i rischi a valle del tuo sviluppo. La CNIL ha una sezione speciale del proprio sito e fornisce un [software libero](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment) dedicato a questo tipo di analisi.
|
||||
|
||||
|
||||
## Scelte tecnologiche
|
||||
|
||||
#### Architettura e caratteristiche
|
||||
|
||||
* **Includi la protezione della privacy, inclusi i requisiti per la sicurezza dei dati, nella fase di design dell’applicazione o del servizio.** Questi requisiti dovrebbero influenzare le [scelte architetturali](#Scheda_n°5:_Fare_una_scelta_informata_di_architettura) (ad es. decentralizzato vs. centralizzato) o le funzionalità (ad es. anonimizzazione, minimizzazione dei dati). Le regolazioni di default dell’applicazione devono almeno rispondere ai requisiti minimi di sicurezza e rispondere ai requisiti di legge. Per esempio, la complessità di default delle password deve rispondere come minimo alle [raccomandazioni CNIL sulle password](https://www.cnil.fr/fr/node/23803)
|
||||
* **Mantieni il controllo del tuo sistema**. È importante che tu mantenga il controllo del tuo sistema, sia per assicurarne il corretto funzionamento, sia per garantire un alto livello di sicurezza. Mantenere il tuo sistema semplice ti permette di comprendere con precisione come funziona e di individuarne i punti deboli. Se una certa complessità è necessaria, è consigliabile partire da un sistema semplice, sicuro e progettato correttamente. Su questa base è possibile aumentare la complessità passo a passo, mettendo via via in sicurezza le nuove funzionalità che vengono aggiunte.
|
||||
* **Non contare su una sola linea di difesa**. Nonostante tutte le misure prese per progettare un sistema sicuro, può sempre accadere che alcune componenti aggiunte in un secondo tempo non siano sufficientemente sicure. Per minimizzare i rischi per gli utenti finali, è suggeribile che il sistema adotti una difesa in profondità. Per esempio, controllare i valori immessi in un modulo online è parte delle difese perimetrali. Se questa difesa viene scavalcata, la protezione delle query al database può risultare compromessa.
|
||||
|
||||
#### Strumenti e pratiche
|
||||
|
||||
* **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.
|
||||
* 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.
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
# Sheet n°2: Prepare your development
|
||||
|
||||
#### The principles of personal data protection must be integrated into IT developments from the design phase onwards in order to protect the privacy of the people whose data you are going to process, to give them better control over their data and to limit errors, losses, unauthorised modifications or misuses of their data in applications.
|
||||
|
||||
## Methodological choices
|
||||
|
||||
* **Put privacy protection at the center of your developments** by adopting a [Privacy By Design](https://edpb.europa.eu/our-work-tools/public-consultations-art-704/2019/guidelines-42019-article-25-data-protection-design_en) methodology.
|
||||
|
||||
* If you use agile methods for your developments, consider **integrating security at the center of your process**. The ANSSI has made available a guide ["digital security & agility"](https://www.ssi.gouv.fr/uploads/2018/11/guide-securite-numerique-agile-anssi-pa-v1.pdf) (in French only) which indicates how to conduct your developments within the framework of an agile method while taking into account the security aspects. Don't hesitate to draw inspiration from it.
|
||||
|
||||
* For any development aimed at the general public, **consider the privacy settings**, and in particular the default settings, such as the characteristics and user content visible by default.
|
||||
|
||||
* **Conduct a [Privacy Impact Assessment (PIA)](https://www.cnil.fr/en/privacy-impact-assessment-pia)**. For [certain processing operations](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/accountability-and-governance/data-protection-impact-assessments/) it is mandatory. In other cases it is a good practice that will allow you to identify and deal with all the risks upstream of your developments. The CNIL has a special section on its website and provides a [free software](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assesment) dedicated to this type of analysis.
|
||||
|
||||
|
||||
## Technological choices
|
||||
|
||||
#### Architecture and features
|
||||
|
||||
* **Include privacy protection, including data security requirements, at the design stage of the application or service**. These requirements should influence [architecture choices](#Sheet_n°5:_Making_an_informed_choice_of_architecture) (e.g. decentralized vs. centralized) or functionality (e.g. short term anonymization, data minimization). The default settings of the application must meet minimum security requirements and comply with the law. For example, the default complexity of passwords must comply at least with the [CNIL recommendation on passwords](https://www.cnil.fr/fr/node/23803).
|
||||
|
||||
* **Maintain control of your system**. It is important to keep control of your system, both to ensure proper operation and to guarantee a high level of security. Keeping a system simple allows you to understand precisely how it works and to identify its weak points. If a certain complexity is required, it is advisable to start with a simple, correctly designed and secure system. Then, it is possible to increase the complexity little by little, while continuing to secure the new features that are added.
|
||||
|
||||
* **Don't rely on a single line of defense**. In spite of all the steps taken to design a secure system, it may happen that some components added later may not be sufficiently secure. To minimize the risk to end users, it is advisable to defend the system in depth. For example, checking the data entered in an online form is part of the periphery defenses. If this defense is hijacked, database query protection can take over.
|
||||
|
||||
#### Tools and practices
|
||||
|
||||
* **Use programming standards that take into account safety**. Often, lists of standards, best practices or coding guides improving the security of your developments are already available. Ancillary tools can also be integrated into your integrated development environments ("**IDE**") in order to automatically check that your code complies with the various rules that are part of these standards or good practices. You can easily find lists of good practices for your favourite programming language on the Internet. For example [here](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards) for C, C++ or Java. For web application development, specific good practice guides exist, such as those published by [OWASP](https://www.owasp.org).
|
||||
|
||||
* **The technological choices are critical.** A few parameters need to be taken into account:
|
||||
* Depending on the field of application or functionality developed, one language or technology may be more appropriate than another.
|
||||
* Time-tested languages and technologies are safer. They have, in general, been audited to correct the most known vulnerabilities. However, you should be careful to use the latest versions of each of the technology building blocks you will be using.
|
||||
* You must avoid coding your final solution in a language you have just learned and not yet mastered. Otherwise, you expose yourself to an increased risk of a security flaw due to lack of experience.
|
||||
* **Set up a secure development environment that allows versioning of the code** by following the [dedicated sheet](#Sheet_n°3:_Secure_your_development_environment) in this guide.
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# Sheet n°3: Secure your development environment
|
||||
|
||||
#### The security of production, development and continuous integration servers as well as developer workstations must be a priority because they centralize access to a large amount of data.
|
||||
|
||||
## Assess your risks and adopt the appropriate security measures
|
||||
|
||||
* **Assess the risks** in the tools and processes used for your developments. Make an inventory of your existing security measures and define an action plan to improve your risk coverage. Appoint a person responsible for its implementation.
|
||||
|
||||
* Consider the risks on all the tools you use, including risks related to SaaS (Software as a Service) and collaborative tools in the cloud (such as [Slack](https://slack.com), [Trello](https://trello.com), [GitHub](https://github.com), etc.).
|
||||
|
||||
## Secure your servers and workstations in a homogeneous and reproducible way
|
||||
|
||||
* Lists of **recommendations** concerning the security of servers, workstations and internal networks are available in the [sheets n° 5 to 8](https://www.cnil.fr/sites/default/files/atoms/files/cnil_guide_securite_personnelle_gb_web.pdf) of the **security of personal data guide** of the CNIL.
|
||||
|
||||
* Write a **document listing those measures and explaining their configuration** to ensure that security measures are implemented uniformly on servers and workstations. In order to reduce the workload, **configuration management tools**, such as [Ansible](https://github.com/ansible/ansible), [Puppet](https://github.com/puppetlabs/puppet) or [Chef](https://github.com/chef/chef), can be used.
|
||||
|
||||
* Update servers and workstations, if possible automatically. You can set up a watchlist of the most important vulnerabilities, for example the [NVD Data Feeds](https://nvd.nist.gov/vuln/data-feeds).
|
||||
|
||||
## Put special emphasis on access management and traceability of operations
|
||||
|
||||
* Remember to document the management of your **SSH keys** (use of state of the art cryptography and key length algorithms, protection of private keys with a passphrase, key rotation). For examples of good practice, see [the document on the secure use of (open)SSH](https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH_en.pdf).
|
||||
|
||||
* Encourage strong authentication on the services used by the development team.
|
||||
|
||||
* **Trace** access to your machines and, if possible, implement **automated log analysis**. In order to keep reliable traces, the use of generic accounts is to be avoided.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# Scheda n°3: Sviluppa in un ambiente sicuro
|
||||
|
||||
#### La sicurezza dei server di produzione, sviluppo e continuous integration, non ché quella delle macchine degli sviluppatori deve essere una priorità, perché centralizzano l’accesso a vaste moli di dati.
|
||||
|
||||
## Valuta i tuoi rischi e adotta misure di sicurezza appropriate
|
||||
|
||||
* **Valuta i rischi** degli strumenti e dei processi che usi per lo sviluppo. Fai un inventario delle misure di sicurezza esistenti e definisci un piano d’azione per migliorare la tua copertura dai rischi. Incarica una persona come responsabile della sua implementazione.
|
||||
|
||||
* Considera i rischi per tutti gli strumenti che usi, inclusi gli strumenti SaaS (Software as a Service) e gli strumenti collaborativi in cloud (come [Slack](https://slack.com), [Trello](https://trello.com), [GitHub](https://github.com), ecc.).
|
||||
|
||||
## Metti in sicurezza server e workstation in modo omogeneo e riproducibile
|
||||
|
||||
* Una lista di raccomandazioni riguardo alla sicurezza di server, workstation e reti interne sono disponibili nelle [schede dal n° 5 all’8](https://www.cnil.fr/sites/default/files/atoms/files/cnil_guide_securite_personnelle_gb_web.pdf) della Guida alla Sicurezza dei dati personali della CNIL.
|
||||
|
||||
* **Redigi un documento che elenchi le misure di sicurezza e ne spieghi la configurazione**, per assicurare che le misure di sicurezza siano implementate uniformemente sia sui server che sulle workstation. Per ridurre il carico di lavoro, puoi usare **strumenti di configuration management** come [Ansible](https://github.com/ansible/ansible), [Puppet](https://github.com/puppetlabs/puppet) o[Chef](https://github.com/chef/chef).
|
||||
|
||||
* Aggiorna sempre server e workstation, se possibile in modo automatico. Puoi definire una watchlist delle vulnerabilità più importanti, per esempio gli [NVD Data Feed](https://nvd.nist.gov/vuln/data-feeds) del NIST.
|
||||
|
||||
## Poni particolare attenzione alla gestione degli accessi e alla tracciabilità delle operazioni
|
||||
|
||||
* Ricordati di documentare la gestione delle tue **chiavi SSH** (uso di algoritmi di crittografia e lunghezze delle chiavi allo stato dell’arte, protezioni delle frasi con una password, rotazione delle chiavi). Per esempi di buone pratiche, vedi il [documento sull’uso siduro di (open)SSH](https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH_en.pdf).
|
||||
|
||||
* Incoraggia l’autenticazione forte nei servizi usati dal team di sviluppo.
|
||||
|
||||
* **Traccia** gli accessi alle macchine e, se possibile, implementa una **analisi automatica dei log**. Per poter raccogliere tracce affidabili, occorre evitare l’uso di account generici.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Scheda n°4: Gestisci il codice sorgente
|
||||
|
||||
#### Qualunque sia la dimensione del tuo progetto, ti raccomandiamo fortemente l’uso di uno strumento di gestione del codice sorgente, come ad esempio un *version control system*, per tenere traccia delle differenti versioni nel corso del tempo.
|
||||
|
||||
## Definisci un sistema efficiente di controllo delle versioni efficiente, pensando alla sua sicurezza.
|
||||
|
||||
* Un sistema di controllo delle versioni è un programma software che ti permette di archiviare **tutto il tuo codice sorgente e i file associati** mantenendo la **cronologia di tutte le modifiche** che sono state fatte. Un semplice server FTP non è un sistema di controllo delle versioni.
|
||||
* Imposta il tuo ambiente correttamente usando le funzionalità offerte dal tuo sistema di controllo delle versioni. Ti raccomandiamo di utilizzare una **autenticazione forte** o un’**autenticazione con chiavi SSH** sin dall’inizio del tuo progetto.
|
||||
* Oltre a questo, assegna dei *livelli di accesso* al progetto per i diversi utenti del tuo sistema di controllo delle versioni e per ciascun livello definisci i corrispondenti **permessi** (per esempio, un livello “guest” con diritti di limitati di lettura, un livello “developer” con diritti di scrittura, ecc.)
|
||||
* Fai **backup** regolari del tuo sistema di gestione del codice sorgente: In particolare, ricordati di fare il backup del server principale dove vengono registrate tutte le modifiche.
|
||||
* Definisci procedure di sviluppo per lavorare in efficienza anche se **più persone sviluppano in contrmporanea**. Per esempio, puoi decidere **che non tutti lavorino sullo stesso ramo (*master branch*) ma che ciascuno lavori su un ramo distinto, che verrà poi inglobato nel ramo principale mano a mano che lo sviluppo procede. Questo tipo di strategie sono già ben documentate, per esempio in [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/).** In aggiunta, alcuni sistemi di controllo delle versioni ti permettono di definire **branch protetti** che impediscono cambiamenti non autorizzati ai file di quei branch.
|
||||
|
||||
|
||||
## Sii consapevole del contenuto del tuo codice sorgente.
|
||||
|
||||
* Adotta **strumenti di valutazione della qualità del codice** (quality metrics) che analizzano il codice al momento del *commit* per verificarne la buona qualità. Puoi anche aggiungere script per il controllo di queste metriche alla [configurazione del sistema di controllo delle versioni](https://git-scm.com/book/uz/v2/Customizing-Git-Git-Hooks), in modo che il *commit* sia annullato se il sorgente non è di una qualità sufficiente.
|
||||
* Mantieni i file segreti e le password di fuori del repository del codice sorgente:
|
||||
* in **file separati, non soggetti a *commit***. Ricorda di usare i file speciali del tuo sistema di controllo delle versioni (come ad esempio _.gitignore_ PER _Git_) in modo che non ti succeda per errore di fare *commit* di file sensibili
|
||||
* riguardo alle **variabili d’ambiente** assicurati di controllare che non vengano accidentalmente registrate nei *log* o visualizzate quando un applicativo va in errore
|
||||
* usa [**specifici software di configuration management o di secret management**](https://www.digitalocean.com/community/tutorials/an-introduction-to-managing-secrets-safely-with-version-control-systems#using-configuration-management-systems-for-secret-management).
|
||||
|
||||
- Infine, se devi includere dati di questo genere nel tuo repository, prendi in considerazione la possibilità di **cifrare/decifrare automaticamente** questi file tramite un *plugin* del sistema di controllo di versione (ad es. [_git-crypt_](https://github.com/AGWA/git-crypt)).
|
||||
|
||||
* Dopo un *commit* che contiene dati personali o altri dati critici, non dimenticare di fare un [*purge*](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) [completo](https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository#purging-a-file-from-your-repositorys-history) del repository del codice sorgente: anche dopo ulteriori modifiche, quei dati potrebbero essere ancora disponibili nella *history* del tuo repository.
|
||||
* Fa’ attenzione prima di **pubblicare online il tuo codice sorgente**. Passa in rassegna **tutti i contenuti**, inclusa tutta la *history* delle modifiche.
|
||||
|
||||
## Esempi di strumenti
|
||||
|
||||
* A differenza di strumenti come [Subversion](https://subversion.apache.org/), che richiedono un server centrale per funzionare, i principali sistemi di controllo delle versioni (come ad esempio[Git](https://git-scm.com/) o [Mercurial](https://www.mercurial-scm.org/) sono **decentralizzati**.
|
||||
|
||||
* La maggior parte di questi sistemi, inclusi gli strumenti relativi (bug management, wiki per la documentazione, ecc.), sono anche disponibili attraverso **un’interfaccia web** . Queste soluzioni possono essere accessbili via Internet ([GitHub](https://github.com/), [Bitbucket](https://bitbucket.org/), ecc.), o possono essere integrate nei tuoi server.
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# Sheet n°4: Manage your source code
|
||||
|
||||
#### Whatever the size of your project, it is highly recommended to use a source code management tool, such as a *version control system*, to track its different versions over time.
|
||||
|
||||
## Set up your version control system efficiently, thinking about its security.
|
||||
|
||||
* A version control system is a software program that allows you to store **all your source code and associated files**, while keeping the **chronology of all changes** that have been made. A simple FTP server is not a version control system.
|
||||
|
||||
* Set up your environment correctly using the features offered by your version control system. It is recommended that you implement strong **authentication** and/or **authentication with SSH keys** at the beginning of your project.
|
||||
|
||||
* In addition, assign *levels of access* to your project to the users of your version control system and define for each level the corresponding **permissions** (for example, a "guest" level with limited read rights, a "developer" level with write rights, etc.).
|
||||
|
||||
* Make regular **backups** of your source code management system. In particular, remember to back up your main server where all changes are saved.
|
||||
|
||||
* Set up development procedures to work efficiently even if **several people are developing at the same time**. For example, you may decide not to work on the same branch (_master_), but to set up feature-based branches, which will be merged into the main branch as development progresses. Such development strategies are already well documented, for example in [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/). In addition, some version control systems offer to set up **protected branches** that prevent unauthorized changes to the files in these branches.
|
||||
|
||||
|
||||
## Be aware of your source code content.
|
||||
|
||||
* Implement **code quality metrics tools** that will scan your code as soon as it is _committed_ to check its good quality. You can also add scripts to check these metrics in the [version control system configuration](https://git-scm.com/book/uz/v2/Customizing-Git-Git-Hooks): the _commit_ will be cancelled if the source code is not of sufficient quality.
|
||||
|
||||
* Keep your secrets and passwords out of your source code repository:
|
||||
* in separate **files, which have not been _committed_**. Remember to use special files from your version control system (such as _.gitignore_ for _Git_) so that you don't _commit_ sensitive files by mistake.
|
||||
* in **environment variables**, take care to check that environment variables are not accidentally written to *logs* or displayed when an application error occurs.
|
||||
* using [**specific secret or configuration management software**](https://www.digitalocean.com/community/tutorials/an-introduction-to-managing-secrets-safely-with-version-control-systems#using-configuration-management-systems-for-secret-management).
|
||||
|
||||
Finally, if you need to include such data in your repository, consider **automatically encrypting/decrypting** the files using a *plugin* from your version control system (e.g. [_git-crypt_](https://github.com/AGWA/git-crypt)).
|
||||
|
||||
* After a _commit_ that contains personal or other critical data, don't forget to [purge](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) [completely](https://help.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository#purging-a-file-from-your-repositorys-history) the source code repository: even after modification, the data may still be available in your repository history.
|
||||
|
||||
* Be careful before **publishing your source code online**. Review **its entire contents** to make sure that no personal data, passwords or other secrets are present, including the entire change history.
|
||||
|
||||
## Examples of tools
|
||||
|
||||
* Unlike tools such as [Subversion](https://subversion.apache.org/), which need a central server to run, the main version control systems ([Git](https://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) for example) are **decentralized**.
|
||||
|
||||
* For most of these tools, a **web interface and related tools** (bug management, wiki for your documentation, etc.) are provided. These solutions can either be accessible via the internet ([GitHub](https://github.com/), [Bitbucket](https://bitbucket.org/), etc.), or they can be integrated into your own servers.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
# Scheda n°5: Fai scelte architetturali informate
|
||||
|
||||
#### Quando progetti l’architettura della tua applicazione, devi identificare i dati personali che verranno raccolti, e definire un percorso e un ciclo di vita per ciascuno di essi. La scelta degli asset di supporto (storage locale, server servizi in cloud) è un momento cruciale, che deve essere adeguato ai tuoi bisogni ma anche alla tua conoscenza tecnica. Il registro dei trattamenti e la conduzione di un Privacy Impact Assessment ti possono assistere in questa scelta.
|
||||
|
||||
## Esaminare il ciclo di vita di dati e processi, dalla raccolta alla cancellazione.
|
||||
|
||||
* Descrivi e rappresenta il modo in cui funziona il tuo prodotto prima di avviare il progetto, usando diagrammi di tipo *data flow* e fornendo una descrizione dettagliata dei processi.
|
||||
* Quando i dati sono **registrati solo sul terminale dell’utente** (storage locale) o **rimangono confinati a reti sotto il controllo dell’utente** (ad es. Wi-Fi o altra rete locale), la sicurezza dei dati è il principale punto di attenzione. Il periodo di conservazione dei dati e la loro cancellazione dovrebbero essere determinati dai singoli utenti.
|
||||
* **quando i dati viaggiano attraverso servizi online**, devi scegliere se a avvalerti di un servizio di hosting o usare un fornitore di servizi sulla base delle tue competenze di sicurezza e della qualità che ci si aspetta dal servizio. I fornitori cloud più noti possono offrire livelli di sicurezza più elevati, ma generano nuovi rischi che devono essere tenuti sotto controllo. Queste [Raccomandazioni per le aziende che desiderano avvalersi di servizi di cloud computing ](https://www.cnil.fr/sites/default/files/typo/document/Recommendations_for_companies_planning_to_use_Cloud_computing_services.pdf) possono guidarti durante questo stadio di scelta.
|
||||
|
||||
|
||||
## Nel caso si usi un hosting esterno
|
||||
|
||||
* **Scegli un fornitore di servizi che ti assicuri misure adeguate di sicurezza e confidenzialità e sia sufficientemente trasparente**.
|
||||
* **Assicurati di conoscere la collocazione geografica dei server che accoglieranno i tuoi dati**. Ti potrebbe venire chiesto di trasferire i dati al di fuori dell’Unione Europea (UE) e della European Economic Area (EEA). Mentre i dati possono muoversi liberamente all’interno della UE/EEA, i trasferimenti al di fuori idi UE/EEA sono possibili solo se vengono assicurati livelli sufficienti e appropriati di protezione dei dati personali. Sul sito di CNIL puoi trovare una mappa che mostra [i diversi livelli di protezione dei dati nei diversi paesi del mondo](https://www.cnil.fr/en/data-protection-around-the-world).
|
||||
* **Se devi immagazzinare dati relativi alla salute**, assicurati che il provider di cui ti servi sia [certificato](https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-certifies) o [approvato](https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-agrees) per questo genere di attività.
|
||||
* Altri punti da tenere presente:
|
||||
- l’esistenza di una policy di sicurezza accessibile;
|
||||
- misure fisiche di protezione e sicurezza presso il sito di hosting;
|
||||
- cifratura dei dati e altri processi per assicurare che il provider non abbia accesso ai dati che gli vengono affidati;
|
||||
- gestione degli aggiornamenti, gestione delle autorizzazioni, autenticazione del personale e sicurezza degli sviluppi applicativi;
|
||||
- facilità della reversibilità/portabilità dei dati in un formato strutturato di uso comune, in qualsiasi momento e su richiesta.
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
# Sheet n°5: Make an informed choice of architecture
|
||||
|
||||
#### When designing the architecture of your application, you must identify personal data that will be collected and define a path and life cycle for each of them. The choice of supporting assets (local storage, server, cloud service) is a crucial step, which must be adapted to your needs, but also to your technical knowledge. The registry and conduction a privacy impact assesment can assist you in this choice.
|
||||
|
||||
## Examining life cycle of data and processes, from collection to erasure
|
||||
|
||||
* Represent and describe how the product generally works before starting your project, with a diagram of data flows and a detailed description of the processes carried out.
|
||||
|
||||
* When data is only **stored on the user's terminal** (local storage) or remains **confined on communication networks under the control of the user** (e.g. Wi-Fi or other local network), the main point of attention is data security. The duration for which data is stored and the actual deletion should be determined by the individuals.
|
||||
|
||||
* **When the data transits through online services**, the choice of hosting the data yourself or using a service provider must be made according to your security knowledge and the expected quality of service. Recognized cloud offerings may offer higher levels of security. However, they generate new risks that need to be mastered. [Recommendations for companies planning to use Cloud computing services](https://www.cnil.fr/sites/default/files/typo/document/Recommendations_for_companies_planning_to_use_Cloud_computing_services.pdf) can guide at this selection stage.
|
||||
|
||||
|
||||
## In case of use of external hosting
|
||||
|
||||
* **Choose a service provider that ensures appropriate security and confidentiality measures and is sufficiently transparent**.
|
||||
|
||||
* **Make sure you know the geographical location of the servers that will host your data**. You may be required to transfer data outside the European Union (EU) and the European Economic Area (EEA). While data can move freely within the EU/EEA, transfers outside the EU/EEA are possible, provided that sufficient and appropriate level of data protection is ensured. The CNIL provides an on-site map showing the [different levels of data protection in countries around the world](https://www.cnil.fr/en/data-protection-around-the-world).
|
||||
|
||||
* **If you need to host health data**, make sure that provider used is [certified](https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-certifies) or [approved](https://esante.gouv.fr/labels-certifications/hds/liste-des-herbergeurs-agrees) for this activity.
|
||||
|
||||
* Other points to be aware of include:
|
||||
- the existence of an accessible security policy;
|
||||
- physical security and safety measures at the hosting site;
|
||||
- data encryption and other processes to ensure that the provider does not have access to the data entrusted to it;
|
||||
- the management of updates, the management of authorizations, the authentication of personnel and the security of application developments;
|
||||
- the easy reversibility/portability of data in a structured and commonly used format, on request and at any time.
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
# Scheda n°6: Metti in sicurezza siti, applicazioni e server
|
||||
|
||||
#### Ogni sito, applicazione e server deve incorporare regole di base di sicurezza allo stato dell’arte, non solo per le comunicazioni di rete, ma anche per l’autenticazione e la gestione dell’infrastruttura.
|
||||
|
||||
## Mettere in sicurezza le reti di comunicazione
|
||||
|
||||
* **Implementare TLS versione 1.2 or 1.3** (al posto di SSL) su tutti i siti web e per le trasmissioni dati elle tue applicazioni mobili, per esempio con [LetsEncrypt](https://letsencrypt.org/fr/), usando solo le versioni più recenti e controllando la correttezza dell’implementazione.
|
||||
* **Rendi obbligatorio l’uso di TLS** per tutte le pagine del tuo sito e per tutte le applicazioni mobili.
|
||||
* **Riduci le porte i comunicazione aperte** a quelle strettamente necessarie per il corretto funzionamento delle applicazioni installate. Se l’accesso a un server web è possibile solo attraverso il protocollo HTTPS, allora solo le port 80 e 443 del server devono essere accessibili, e tutte le altre porte possono essere bloccate dal firewall.
|
||||
* **OWASP ha pubblicato delle schede-guida**, ad esempio per [implementare correttamente TLS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) o per [mettere in sicurezza un webservice](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html).
|
||||
|
||||
## Mettere in sicurezza le autenticazioni
|
||||
|
||||
* **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).
|
||||
|
||||
* **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.
|
||||
|
||||
* **Limita l’accesso ai tool e alle interfacce di amministrazione al solo staff qualificato per il loro uso.** Per le operazioni quotidiane, incoraggia l’utilizzo di account a privilegi ridotti.
|
||||
|
||||
* **L’accesso remoto alle interfacce di amministrazione deve essere soggetto a misure di sicurezza rinforzate.** Per esempio, per i server interni, può essere una buona soluzione dotarsi di una VPN con autenticazione forte dell’utente e della macchina che usa per connettersi.
|
||||
|
||||
## Mettere in sicurezza le infrastrutture
|
||||
|
||||
* **Fai backup regolari, cifrati e controllati regolarmente**. Questo è particolarmente utile nel caso di attacchi di tipo *ransomware* perché in quel caso la disponibilità di un backup di tutti i sistemi è la tua sola possibilità di ripristinare i sistemi.
|
||||
|
||||
* **Limita la dimensione dello stack software che impieghi** e per ciascun elemento dello stack:
|
||||
* **Installa gli update critici** senza ritardo, programmando un controllo automatico settimanale;
|
||||
* **Automatizza il controllo delle vulnerabilità** abbonandoti per esempio ai [Data Feed di NVD](https://nvd.nist.gov/vuln/data-feeds).
|
||||
|
||||
* **Adotta strumenti di scoperta delle vulnerabilità** per i processi più critici, in modo da poter scoprire possibili violazioni di sicurezza. Puoi usare sistemi per la scoperta e la prevenzione di attacchi anche sui sistemi e sui server critici. Questi test devono essere condotti regolarmente e comunque prima della messa in produzione di ogni nuovo software.
|
||||
|
||||
* **Limita o proibisci l’accesso sia fisico che via software alle porte di diagnostica e di configurazione remota**. Per esempio, puoi avere l’elenco di tutte le porte aperte con lo strumento `netstat`.
|
||||
|
||||
* **Proteggi i database che esponi su Internet**, come minimo limitando il più possibile l’accesso e cambiando la password di default per l’account dell’amministratore.
|
||||
|
||||
* Per quanto riguarda la gestione di database, le buone pratiche includono:
|
||||
|
||||
* 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;
|
||||
* incoraggia la cifratura a riposo di dischi e database.
|
||||
|
|
@ -1,57 +0,0 @@
|
|||
# Sheet n°6: Secure your websites, applications and servers
|
||||
|
||||
#### Any website, application or server must incorporate basic state-of-the-art security rules, not only on network communications but also on authentication and infrastructure.
|
||||
|
||||
## Securing communication networks
|
||||
|
||||
* **Implement TLS version 1.2 or 1.3** (replacing SSL) on all websites and for data transmissions of your mobile applications, for example with [LetsEncrypt](https://letsencrypt.org/fr/), using only the most recent versions and checking its correct implementation.
|
||||
|
||||
* **Make the use of TLS mandatory** for all pages of your site and for your mobile applications.
|
||||
|
||||
* **Limit the communication ports** strictly necessary for the proper functioning of the installed applications. If access to a web server is only possible using the HTTPS protocol, only ports 443 and 80 of this server must be accessible, all other ports can be blocked by the firewall.
|
||||
|
||||
* **The OWASP has published on its website some cheatsheets** for exemple to [correctly implement TLS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) or to [secure a webservice](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html).
|
||||
|
||||
## Securing Authentications
|
||||
|
||||
* **Follow [the CNIL recommendation on passwords](https://www.cnil.fr/fr/node/23803)**. In particular, remember to limit the number of access attempts.
|
||||
|
||||
* **Never store passwords in clear text**. Store them as a hash using a proven library, such as [bcrypt](https://en.wikipedia.org/wiki/Bcrypt).
|
||||
|
||||
* **If cookies are used for authentication**, it is recommended:
|
||||
|
||||
* to force the use of HTTPS via [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security);
|
||||
|
||||
* to use the `secure` flag;
|
||||
|
||||
* use the `HttpOnly` flag.
|
||||
|
||||
* **Test the cryptographic suites installed on the systems** and disable obsolete ones (RC4, MD4, MD5 etc.). Encourage the use of AES256. [Read the OSWAP note on the subject](https://owasp.org/www-project-cheat-sheets/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html).
|
||||
|
||||
* **Adopt a specific password policy for administrators**. Change the passwords, at least, each time an administrator leaves and in case of suspected breach. Encourage strong authentication when possible.
|
||||
|
||||
* **Limit access to administration tools and interfaces to qualified staff.** Encourage the use of lower-privilege accounts for day-to-day operations.
|
||||
|
||||
* **Remote access to administration interfaces should be subject to increased security measures.** For example, for internal servers, implementing a VPN with strong authentication of the user and the workstation he or she is using may be a good solution.
|
||||
|
||||
## Securing infrastructures
|
||||
|
||||
* **Make backups, if possible encrypted and checked regularly**. This is especially useful in case of a ransomware attack on your systems as having backups for all your systems will be the only measure that will allow you to restore your systems.
|
||||
|
||||
* **Limit the size of the software stack used,** and for each element of the stack:
|
||||
|
||||
* **Install critical updates** without delay by scheduling an automatic weekly check;
|
||||
* **Automate a vulnerability watch** by subscribing to the [NVD Data Feeds](https://nvd.nist.gov/vuln/data-feeds) for example.
|
||||
|
||||
* **Use vulnerability detection tools** for the most critical processes to detect possible security breach. Systems for detecting and preventing attacks on critical systems or servers can also be used. These tests must be conducted regularly and before any new software version is put into production.
|
||||
|
||||
* **Restrict or fordbid physical and software access to diagnostic and remote configuration ports.** For example, you can list all open ports using the *netstat* tool.
|
||||
|
||||
* **Protect the databases you make available on the Internet**, at least by restricting access as much as possible (for example, by IP filtering) and by changing the default password for the administrator account.
|
||||
|
||||
* In terms of database management, good practices include:
|
||||
|
||||
* **using nominative accounts** for database access and create specific accounts for each application;
|
||||
* **revoking the administrative privileges** of user or application accounts to avoid modification to database structure (table, vues, process, etc);
|
||||
* having protection against SQL or script injection attacks;
|
||||
* encouraging at rest disk and database encryption.
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
# Sheet n°7: Minimize data collection
|
||||
|
||||
#### You shall only collect personal data that is adequate, relevant and necessary in relation to the purposes for which they are processed, as defined at the time of collection.
|
||||
|
||||
## Before collection, think about the different types of data you need to collect and try to limit your collection to what is strictly necessary.
|
||||
|
||||
* Think about the different **types of data** that will need to be collected before an application is implemented and **document** this thinking.
|
||||
|
||||
* If specific data is not **needed for a certain category of people**, do not collect it.
|
||||
|
||||
* Process and store data in a way that **reduces accuracy** (similar to pseudonymization). For example, store only the year of birth instead of a full date of birth if the application only needs the year.
|
||||
|
||||
* If collecting particularly sensitive data, such as health or criminal convictions data, be sure to collect only the **minimum required**. Due to the regulatory constraints, the simplest solution is still to **not collect them** if you can do without them.
|
||||
|
||||
* Minimize the amount of data collected also in the **log data** and do not store sensitive or critical data (health data, passwords, etc.).
|
||||
|
||||
* Some features may improve the user experience, but are **not strictly necessary for your application to work properly** (e.g. geolocation to simplify a geographic search). In this case, the end user must be able to **choose whether or not to use** this functionality. If he uses it, the data that you are led to collect for its operation must only be kept for the time strictly necessary for its operation and never be used for other purposes.
|
||||
|
||||
* Remember to associate **retention periods** for each category of data, depending on the purpose of the processing and the legal or regulatory obligations relating to their retention. Logs must also have a retention period. Document the defined retention durations. You will need to be able to justify them.
|
||||
|
||||
## Once the data has been collected, set up automatic deletion mechanisms.
|
||||
|
||||
* Implement an automatic **purge** system at the end of the shelf life. You can also implement manual reviews of stored data on a periodic basis.
|
||||
|
||||
* To ensure complete erasure, erase **physically** all data that is no longer needed using specialized tools or by destroying the physical media.
|
||||
|
||||
* If the data is still useful, you can reduce its sensitivity by using **pseudomisation** or even **anonymisation** methods. In case of pseudonymization, these data remain subject to the regulations on personal data (see [Sheet 1](#Sheet_n°1_:_Identify_personal_data)).
|
||||
|
||||
* Log the **automatic deletion procedures**. The corresponding logs can be used as a **proof of deletion** of a data item.
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# Scheda n°7: Minimizza la raccolta di dati
|
||||
|
||||
#### Devi raccogliere solo i dati personali rilevanti, adeguati e necessari per la finalità per la quale li raccogli, come definita al momento della raccolta.
|
||||
|
||||
## Prima della raccolta, pensa ai diversi tipi di dati che devi raccogliere e limita la raccolta a ciò che è strettamente necessario.
|
||||
|
||||
* Pensa ai diversi **tipi di dati** che dovrai raccogliere prima di implementare la tua applicazione e **documenta** questi ragionamenti.
|
||||
* Se **per una certa categoria di persone non servono** alcuni dati, non raccoglierli.
|
||||
* Tratta e archivia i dati in modo da generalizzarli (analogamente a quanto avviene per la pseudonimizzazione). Per esempio, se l’applicazione necessita solo dell’anno di nascita, archivia soltanto l’anno di nascita invece dell’intera data di nascita.
|
||||
* Se raccogli dati particolarmente sensibili, come dati riguardanti la salute o informazioni giudiziarie, assicurati di raccogliere solo il **minimo necessario**. A causa delle restrizioni legali, la soluzione più semplice è ancora una volta **non raccoglierli** se puoi farne a meno.
|
||||
* Minimizza anche i dati raccolti nei **log di sistema** e non fargli registrare dati sensibili o critici (password, dati sanitari, ecc.)
|
||||
* Alcune funzionalità potrebbero migliorare l’esperienza utente ma **non sono strettamente necessarie per il corretto funzionamento dell’applicazione** (ad es. la geolocalizzazione per migliorare una ricerca geografica). In questo caso, l’utente finale deve poter **scegliere se usare o meno queste funzionalità**. Se decide di usarle, i dati ulteriori che raccoglierai devono essere conservati solo per il tempo strettamente necessario e non devono mai essere usati per altri scopi.
|
||||
* Ricordati di associare un **periodo di conservazione** a ciascuna categoria di dati, sulla base dello scopo del trattamento e degli obblighi di legge relativi alla loro conservazione. Anche i log di sistema devono avere un periodo di conservazione predefinito. Documenta i periodi di conservazione che hai definito, perché dovrai poterli motivare.
|
||||
|
||||
## Una volta che i dati sono stati raccolti, predisponi meccanismi di cancellazione automatica.
|
||||
|
||||
* Implementa un sistema automatico di **eliminazione** al termine della conservazione. Puoi anche predisporre revisioni manuali periodiche dei dati conservati.
|
||||
* Per assicurare una cancellazione completa, cancella **fisicamente** tutti i dati non più necessari tramite strumenti specializzati, o distruggendo i supporti fisici.
|
||||
* Se i dati sono ancora utili, puoi ridurne il potere identificativo usando metodi di **pseduonimizzazione** o **anonimizzazione**. Nel caso della pseudonimizzazione, i dati rimangono soggetti alle norme sulla protezione dei dati personali (vedi [Scheda 1](#Scheda_n°1_:_Individua_i_dati_personali)).
|
||||
* Tieni un log delle **procedure di cancellazione automatica**. Questi log possono essere usati come **prova di cancellazione** di un certo dato.
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
# Scheda n°8: Gestisci i profili utente
|
||||
|
||||
#### La gestione dei profili dello staff e degli utenti deve essere valutata a monte dello sviluppo. Si tratta di definire profili di accesso e autorizzazione differenti in modo che ciascun utente possa accedere solo ai dati di cui ha effettiva necessità.
|
||||
|
||||
## Buone pratiche per la gestione degli utenti
|
||||
|
||||
* Il punto di partenza è l’**uso di identificativi unici e individuali**, tanto per gli utenti dell’applicazione che per il team di sviluppo.
|
||||
* Assicurati di richiedere l’autenticazione prima di qualunque accesso a dati personali, in linea con le [raccomandazioni di CNIL](https://www.cnil.fr/en/passwords-minimum-security-recommendations-businesses-and-citizens).
|
||||
* Per assicurarti che ogni persona (utente o staff) possa accedere solo **ai dati di cui ha effettiva necessità**, il tuo sistema deve fornire **politiche differenziare di gestione degli accessi ai dati** (lettura, scrittura, cancellazione, ecc.) a seconda delle persone e delle loro necessità. Un meccanismo generale di gestione dei profili utente ti permetterà di raggruppare diritti diversi a seconda del ruolo svolto da un gruppo di utenti all’interno dell’applicazione.
|
||||
* La gestione dei profili utente si può accompagnare a **sistemi di log che consentano di tracciare le attività e individuare anomalie o eventi legati alla sicurezza**, come accessi fraudolenti o uso improprio di dati personali. Questi sistemi non devono essere usati per altro scopo che non sia garantire un utilizzo corretto dei sistemi informatici. Inoltre, i log non possono essere conservati più di quanto sia necessario. In generale, si considera adeguata una conservazione per sei mesi.
|
||||
* Considera anche di pianificare audit del codice o *penetration testing* per il tuo ambiente di sviluppo per **garantire la robustezza del tuo sistema di gestione dei profili utente**.
|
||||
|
||||
## Semplifica la gestione dei profili di sicurezza
|
||||
|
||||
* Pianifica di **documentare o automatizzare gli spostamenti dello staff**. Per esempio, dovresti definire procedure che prescrivono cosa fare nel momento in cui una persona non è più autorizzata ad accedere a un locale o a una risorsa IT, o al termine del contratto.
|
||||
* Gestire staff e utenti implica **una revisione periodica dei permessi** sulla base dell’evoluzione delle necessità e della mobilità organizzativa all’interno del progetto. L’uso di servizi di directory come ad esempio *Lightweight Directory Access Protocol*, ti aiuterà a tenere sotto controllo questi cambiamenti e ti permetterà di affinare le tue strategie di accesso, per esempio definendo ruoli sulla base dei profili di utilizzo delle risorse. Questo ti permetterà di rispettare al meglio il principio del minimo privilegio.
|
||||
* L’uso di account “superutente” (come *root*, *Administrator*, ecc.) deve essere evitato per le operazioni quotidiane e di routine, perché costituiscono le fondamenta del tuo sistema e allo stesso tempo un bersaglio di elezione per un possibile attaccante esterno. In particolare per questi account ti raccomandiamo di adottare una politica di password forti (da 10 a 20 caratteri, oppure multi-fattore) e di limitare al massimo il numero di persone che le conoscono.
|
||||
* **Favorisci l’utilizzo di un password manager all’interno del progetto** e, ogni volta che sia possibile, la transizione all’autenticazione forte. Evita account generici condivisi fra più persone.
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
# Sheet n°8: Manage user profiles
|
||||
|
||||
#### The way to manage profiles of your collaborators and your end-users must be thought out upstream of your developments. It consists in defining different access and authorization profiles so that each person can access only the data he or she actually needs.
|
||||
|
||||
|
||||
## Good practices for user management
|
||||
|
||||
* It all starts with the **use of unique and individual identifiers**, whether they are users of your application or collaborators in development.
|
||||
|
||||
* Make sure to **impose authentication** before any access to personal data, in accordance with the [recommendations of the CNIL](https://www.cnil.fr/en/passwords-minimum-security-recommendations-businesses-and-citizens).
|
||||
|
||||
* To ensure that each person (user or collaborator) can only access to **data he or she actually needs**, your system must provide **differentiated data access management policies** (read, write, delete, etc.) according to people and needs. A global user profile management mechanism will allow you to group different rights according to a role exercised by a group of users within the application.
|
||||
|
||||
* The management of user profiles can be used along with **logging systems in order to trace activities, and detect anomalies or events related to security**, such as fraudulent access and misuse of personal data. These devices must not be used for any purpose other than ensuring the proper use of the computer system. Logs must also not be kept longer than necessary. In general, a period of six months is adequate.
|
||||
|
||||
* You can also plan code audits or penetration testing within your development environment to **ensure robustness of your profile management system**.
|
||||
|
||||
## Streamline the management of clearance profiles
|
||||
|
||||
* Plan to **document or automate the movement of your collaborators**. For example, these procedures should lead the actions to be taken when people are no longer authorized to access a room or an IT resource, or at the end of their contract.
|
||||
|
||||
* Managing your users and collaborators implies **a regular review of the permission** according to the evolution of uses and organizational movements within your project. The use of directory services, such as _Lightweight Directory Access Protocol_ (_LDAP_), will help you monitor these changes and allow you to refine your access strategies, for example by assigning roles based on usage profiles. This allows you to better respect the principle of least privilege.
|
||||
|
||||
|
||||
* The use of "supreme" accounts (type _root_, administrator, etc.) has to be avoided for conventional operations, as it constitutes the keystone of your system and a privileged target for a possible external attacker. We recommend that you associate a strong password policy with it (10 to 20 characters or multi-factor) and that you limit the number of people with knowledge of it to the strictest necessary.
|
||||
|
||||
|
||||
* **Favour the use of a password manager within your project** and the transition to strong authentication when possible. Avoid generic accounts shared by several people.
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
# Sheet n°09: Control your libraries and SDKs
|
||||
|
||||
#### Do you use libraries, SDKs, or other software components written by third parties? Here are a few tips on how to integrate these tools while keeping control of your developments.
|
||||
|
||||
## Make an informed choice
|
||||
|
||||
* **Assess the value of adding each dependency.** Some commonly used software bricks are only a few lines long. However, each added element is an increase in your system's attack surface. In the case where a single library offers several functionalities, integrate only the functionalities you actually need. By activating the minimum number of functionalities, you reduce the number of potential bugs that could occur.
|
||||
|
||||
* **Choose maintained software, libraries and SDKs:**
|
||||
|
||||
* If you want to use free or open source software, try to choose projects or solutions with an active community, regular updates and good documentation.
|
||||
|
||||
* If you use other types of solutions with commercial support, contractually ensure that the code will be maintained and updated for the life of your project.
|
||||
|
||||
* **Take privacy into account.** Some SDKs or libraries pay for themselves by using personal data collected from the applications or sites on which they are integrated. Make sure that such third parties comply with applicable laws regarding personal data, including a mechanism for obtaining user consent.
|
||||
|
||||
* **If you use cryptographic mechanisms, it is strongly discouraged to implement cryptographic algorithms or protocols yourself**, but rather try to choose cryptographic libraries that are maintained, recognized and easy to use.
|
||||
|
||||
## Evaluate the selected elements
|
||||
|
||||
* **Read the documentation and change the default configurations**. It is important to know how your dependencies work. Third party libraries and SDKs often come with default configuration files, which are rarely changed due to lack of time, which causes many security holes.
|
||||
* **Audit your libraries and SDKs.** Do you really know what all the libraries and SDKs you integrate do? What data is sent through these dependencies and to whom? This audit will allow you to determine the data protection obligations to be respected and to establish the responsibility of the actors.
|
||||
* **Map your dependencies.** Third-party libraries and SDKs can also integrate other components: auditing their code will allow you to better map all your dependencies and to better act if a problem affects one of them. It is also recommended that you perform security audits of your third-party components and monitor them.
|
||||
* **Beware of [typosquatting](https://en.wikipedia.org/wiki/Typosquatting) and other malicious techniques.** Check the names of dependencies, as well as their own dependencies to avoid attacks. Do not copy and paste command lines from unknown sites.
|
||||
|
||||
## Maintain libraries and SDKs
|
||||
|
||||
* **Use dependency management systems** (such as yum, apt, maven, pip, etc.) to maintain an up-to-date list of your dependencies.
|
||||
* **Manage updates to your dependencies,** especially in the case of security updates that fix vulnerabilities. You must set up a documented procedure to manage and deploy them as soon as possible.
|
||||
* **Be aware of the versions of libraries and SDKs at the end of support** that will no longer be maintained: try to find another solution (choose a new library, renew commercial support).
|
||||
* **Check the status of open-source projects,** especially the change of domain or package ownership, some attacks using malicious updates of popular dependencies.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
# Scheda n°09: Controlla librerie e SDK
|
||||
|
||||
#### Usi librerie, SDK o altri componenti software scritti da terze parti? Ecco alcuni suggerimenti su come integrarli mantenendo comunque il controllo del tuo sviluppo.
|
||||
|
||||
## Fai una scelta informata
|
||||
|
||||
* **Valuta il valore di ciascuna dipendenza che aggiungi.** Alcuni componenti software di uso comune sono lunghi solo poche righe. Però, ogni elemento aggiunto significa un aumento della superficie di attacco del tuo sistema. Se una singola libreria offre più funzionalità, integra solo le funzionalità di cui hai reale esigenza. Attivando il numero minimo di funzionalità riduci il numero di potenziali *bug* a cui sarai esposto.
|
||||
|
||||
* **Scegli software, librerie e SDK che vengono sottoposti a revisioni:**
|
||||
* 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.
|
||||
|
||||
## Valuta gli elementi individuati
|
||||
|
||||
* **Leggi la documentazione e cambia le configurazioni di default**. È importante sapere come funzionano le dipendenze del tuo codice. Le librerie di terze parti e gli SDK di solito hanno dei file di configurazione di default che spesso, per mancanza di tempo, non vengono nemmeno adattati, aprendo la via a molte falle di sicurezza.
|
||||
* **Fai un audit delle tue librerie e degli SDK.** Sai davvero tutto quello che fanno le librerie e gli SDK che integri nel tuo sviluppo? Quali dati vengono trasmessi attraverso queste dipendenze, e a chi? Un audit ti permetterà di determinare le prescrizioni di legge sulla protezione dei dati a cui devi attenerti e di stabilire le responsabilità di tutti gli attori coinvolti.
|
||||
**Fai una mappa delle dipendenze.** Le librerie di terze parti possono anche integrare altre componenti: fare un audit del loro codice ti permetterà di mappare meglio le tue dipendenze e di agire al meglio se una di loro mostra dei problemi. Per le componenti di terze parti, raccomandiamo anche che tu faccia degli audit di sicurezza e che li tenga poi monitorati.
|
||||
* **Fai attenzione al [typosquatting](https://it.wikipedia.org/wiki/Typosquatting) e altre tecniche malevole.** Controlla i nomi delle dipendenze, e delle loro dipendenze, per evitare attacchi. Non fare copia-e-incolla di linee di comando da siti che non conosci.
|
||||
|
||||
## Mantieni aggiornate librerie e SDK
|
||||
|
||||
* **Usa sistemi di gestione delle dipendenze** (come yum, apt, maven, pip, ecc.) per mantenere una lista aggiornata delle tue dipendenze.
|
||||
* **Gestisci gli aggiornamenti delle tue dipendenze**, specialmente nel caso di aggiornamenti di sicurezza che risolvono delle vulnerabilità. Devi predisporre una procedura documentata per gestirle e metterle in produzione nel minor tempo possibile.
|
||||
* **Fai attenzione a versioni di librerie e SDK a fine vita o a fine contratto** che non saranno più supportati: cerca di trovare un’altra soluzione (scegli una nuova libreria, rinnova il supporto commerciale).
|
||||
* **Controlla lo status dei progetti open-source**, in particolare il cambio di dominio o di proprietà del pacchetto, alcuni attacchi usano aggiornamenti fasulli di dipendenze ampiamente in uso.
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
# Sheet n°10: Ensure quality of the code and its documentation
|
||||
|
||||
#### It is essential to adopt good code-writing techniques as soon as possible. Code readability reduce the effort of maintenance and bug fixes over time for you and your (possibly future)collaborators.
|
||||
|
||||
## Document code and architecture
|
||||
|
||||
* Documentation is sometimes left out during development, due to lack of time or visibility on the project. However, it is **crucial for the maintainability of your project**: it allows you to understand how the code works globally, and to know which parts of the code are affected by a modification.
|
||||
|
||||
* **Document the architecture, not just the code**: you need to be able to keep the big picture in mind when you write your documentation and help developers understand how all your components work together. Therefore, focus on diagrams and clear explanations when documenting your project.
|
||||
|
||||
* **Maintain the documentation along with the code**: The best way to keep your documentation up to date is to modify it as you go along with the code.
|
||||
|
||||
* If you use a source code manager, you can also include documentation changes for each "_commit_" that modifies your code (see in particular [the "Manage your source code" form](#Sheet_n°4_:_Manage your source code)).
|
||||
|
||||
* **Do not forget to address security in your documentation**. In particular, you can document the different configuration choices for your application, and explain which settings are the most secure.
|
||||
|
||||
## Check the quality of your code and its documentation.
|
||||
|
||||
* A quality code involves **adoption of good practices and coding conventions** applied consistently throughout the program. It is also best to refer to [existing conventions](https://github.com/Kristories/awesome-guidelines). Here are a few examples of good practice:
|
||||
* **Using explicit variable and function names** makes it easier to understand what is going on at first glance.
|
||||
* **Correctly indenting your code** allows you to see the structure of the code more quickly.
|
||||
* **Avoiding code redundancy** reduces the correction efforts that have to be made in several places. An oversight is quickly forgotten.
|
||||
|
||||
* **Tools can help you control the quality of your code**. Once correctly set up, they will avoid re-reading the code to check the correct implementation of coding conventions. Example of these tools are:
|
||||
|
||||
* **Integrated development environments** ("_IDE_"), possibly using plugins ("_plugins_"), can be configured to respect code indentation rules, line breaks between different portions of code, or the position of braces and other parentheses.
|
||||
* **Source code quality measurement software** can report code duplications, compliance with programming rules or potential bugs.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Scheda n°10: Garantisci la qualità del codice e della documentazione
|
||||
|
||||
#### È essenziale adottare il prima possibile buone tecniche di scrittura del codice. La leggibilità del codice riduce nel tempo gli sforzi di mantenimento e di correzione dei bug per te e per i tuoi (magari futuri) collaboratori.
|
||||
|
||||
## Documenta il codice e l’architettura
|
||||
|
||||
* A volte durante lo sviluppo la documentazione viene trascurata, per mancanza di tempo o di visibilità del progetto. Però, è **cruciale per la manutenibilità del progetto**: ti permette di capire il modo in cui il codice funziona nel suo insieme, e di sapere quali parti di codice verranno affette da una modifica.
|
||||
|
||||
* **Documenta l’architettura, non solo il codice**: quando scrivi la documentazione devi essere in grado di tenere in mente la visione d’insieme e aiutare altri sviluppatori a capire come tutte le diverse componenti del codice lavorano insieme. Perciò, quando documenti il tuo progetto concentrati su diagrammi e spiegazioni chiare.
|
||||
|
||||
* **Aggiorna la documentazione assieme al codice**: il miglior modo per mantenere aggiornata la documentazione è di modificarla mano a mano che modifichi il codice.
|
||||
|
||||
* Se usi uno strumento di gestione del codice sorgente, in ciascun *commit* che modifica il sorgente puoi includere anche le modifiche alla relativa documentazione (vedi in particolare la scheda ["Gestisci il codice sorgente”](#Scheda_n°4_:_Gestisci il codice sorgente)).
|
||||
|
||||
* **Nella documentazione, non scordare di trattare la parte relativa alla sicurezza**. In particolare, puoi documentare le differenti scelte di configurazione della tua applicazione, e spiegare quali regolazioni sono più sicure.
|
||||
|
||||
## Controlla la qualità del codice e della documentazione
|
||||
|
||||
* Un codice di qualità richiede **l’adozione di buone pratiche e convenzioni di scrittura**, applicate in modo consistente in tutta l’applicazione. È anche opportuno fare riferimento a [convenzioni esistenti](https://github.com/Kristories/awesome-guidelines). Ecco alcuni esempi di buone pratiche:
|
||||
* **Usare nomi di variabile e di funzione espliciti** rende più semplice capire a colpo d’occhio cosa sta succedendo.
|
||||
* **Indentare correttamente il codice** ti permette di comprendere più velocemente la struttura del codice.
|
||||
* **Evitare la ridondanza del codice** riduce la necessità di replicare una modifica in più punti. Una svista si dimentica in fretta.
|
||||
|
||||
* **Esistono strumenti che possono aiutarti a controllare la qualità del codice**. Una volta che li hai configurati correttamente, ti eviteranno di rileggere il codice per assicurarti che le convenzioni di scrittura siano state rispettate. Alcuni esempi di questi strumenti sono:
|
||||
* **Ambienti di sviluppo integrati ** ("_IDE–Integrated Development Environments_"), magari con l’aggiunta di plugin, che possono essere configurati per rispettare le regole di indentazione, le linee vuote fra diverse porzioni di codice o la posizione delle parentesi, graffe o di altro tipo.
|
||||
* **Software di misurazione della qualità del codice** possono segnalarti duplicazioni, mancate adesioni alle regole di programmazione e potenziali bug.
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
# Sheet n°11: Test your applications
|
||||
|
||||
#### Testing your product allows you to check its correct operation, to ensure a good user experience and to find and prevent defects before it goes into production. Testing your product also reduces the risk of personal data breaches.
|
||||
|
||||
## Automate testing
|
||||
|
||||
* The **development tests** (unit, functional, etc.) will verify the adequacy between the specifications and the functioning of the product. The **security tests** (random data tests also called "_fuzzing_", _scan_ of vulnerabilities, etc.), will check that the product continues to function acceptably when you move away from its normal use and that it does not present any vulnerability that could allow third parties to compromise its security. Both types of tests are important for the proper functioning of your application.
|
||||
|
||||
* Set up a **continuous integration system** to run the tests automatically after each change in your source code.
|
||||
|
||||
## Integrate testing into your business strategy.
|
||||
|
||||
* Add the implementation of the test environment into the company's strategy. The **acceptable metrics** must be defined jointly by all parties prior to development.
|
||||
|
||||
* Metrics to consider are for example:
|
||||
|
||||
* The **coverage rate** of tests and their type;
|
||||
* the **duplication rate** of your code;
|
||||
* the **number of vulnerabilities** (as defined by the tools) and their type, etc.
|
||||
|
||||
## Watch out for your test data!
|
||||
|
||||
* "Real" production data should not be used during the development and testing phase. Using personal data from your production database for testing purposes is tantamount to **diverting it from its original purpose**.
|
||||
|
||||
* If personal data is used outside of production, it should be noted that the **security risks** are also **increased**: access to the data by people who do not have a need to know, multiple storage locations, etc.
|
||||
|
||||
* So build a **dummy data set** that will look like the data that will be processed by your application. A dummy data set will ensure that disclosure of this data will not have any impact on people.
|
||||
|
||||
* If you need to **import existing configurations** from production into your test cases, consider **anonymizing the personal data** that may be present.
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
# Scheda n°11: Testa le applicazioni
|
||||
|
||||
#### Testare i tuoi prodotti ti permette di controllare che funzionino correttamente, che l’esperienza utente sia buona e di trovare e prevenire difetti prima che il codice vada in produzione. I test riducono anche i rischi di violazioni dei dati personali.
|
||||
|
||||
## Automatizza i test
|
||||
|
||||
* I **test di sviluppo** (unit, funzionali, ecc.) verificheranno la corrispondenza fra le specifiche e il funzionamento del prodotto. I **test di sicurezza** (test con dati casuali anche detti *“fuzzying”*, scansione delle vulnerabilità, ecc.) verificheranno che il prodotto continui a funzionare in modo accettabile anche al di fuori dell’utilizzo normale, e che non presenti vulnerabilità che permetterebbero a terze parti di comprometterne la sicurezza. Entrambi i tipi di test sono importanti per il corretto funzionamento della tua applicazione.
|
||||
|
||||
* Appronta un **sistema di integrazione continua** per eseguire i test in automatico dopo ogni modifica al codice sorgente.
|
||||
|
||||
## Integra i test nella tua strategia di business
|
||||
|
||||
* Aggiungi l’implementazione dell’ambiente di test alla strategia di business. Le **metriche accettabili** devono essere definite congiuntamente da tutte le parti in causa prima dello sviluppo..
|
||||
|
||||
* Le metriche che puoi considerare sono per esempio:
|
||||
|
||||
* Il **tasso di copertura dei test** e il loro tipo;
|
||||
* il **tasso di duplicazione** nel codice;
|
||||
* il **numeri di vulnerabilità** (come definite dagli strumenti) e il loro tipo, ecc.
|
||||
|
||||
## Fai attenzione ai dati di test!
|
||||
|
||||
* Non si dovrebbero usare dati "veri” di produzione nelle fasi di sviluppo e di test. Usare dati personali per fare dei test dal tuo database di produzione equivale a **distoglierlo dal suo scopo originario**.
|
||||
* Se usi dati personali al di fuori della produzione, occorre ricordare che i **rischi di sicurezza aumentano**: accesso ai dati da parte di persone che non ne hanno necessità, molteplici posizioni di archiviazione, ecc.
|
||||
* Per questo motivi devi costituire un **dataset fittizio** che assomigli ai dati che verranno effettivamente trattati dalla tua applicazione. Un dataset fittizio garantirà che la comunicazione di questi dati non abbia alcun impatto sulle persone.
|
||||
* Se devi **importare configurazioni esistenti** dalla produzione nei tuoi test, considera l’**anonimizzazione dei dati** presenti.
|
||||
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
# Sheet n°12: Inform users
|
||||
|
||||
#### The transparency principle of the GDPR requires that any information or communication relating to the processing of personal data should be concise, transparent, comprehensible and easily accessible in plain and simple language.
|
||||
|
||||
## Who to inform and when?
|
||||
|
||||
* Data subjects must be informed:
|
||||
|
||||
* both **in the case of direct data collection** i.e. when data are collected directly from individuals (examples: form, online purchase, subscription of a contract, opening of a bank account) or when they are collected via devices or technologies for observing the activity of individuals (examples: analysis of Internet navigation, geolocation and Wi-Fi analytics/tracking for audience measurement, etc.) ;
|
||||
|
||||
* and **in the case of indirect collection of personal data**, when data are not collected directly from individuals (examples: data retrieved from trading partners, *data brokers*, publicly available sources, or others).
|
||||
|
||||
* This information is needed:
|
||||
* **during the data collection** in the case of direct collection;
|
||||
* **as soon as possible in the case of indirect collection** (in particular at the time of first contact with the person) and no later than a month from the collection (with [exceptions](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-be-informed/#exceptions));
|
||||
* **in the event of a substantial change or a particular event**. For example: new purpose, new recipients, change in the way rights are exercised, [data breach](#Sheet_n°1:_Identify_personal_data).
|
||||
|
||||
## What information do I have to give?
|
||||
|
||||
* In all cases, you must specify:
|
||||
|
||||
* **The identity and contact details of the organization** that collects the data (who processes the data?) ;
|
||||
* **The purposes** (what will the collected data be used for?);
|
||||
* **The lawful basis** on which the data processing is based (find all the [**information on the lawful basis**](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/));
|
||||
* **The compulsory or optional nature of the data collection** (which implies an upstream reflection on the usefulness of collecting the data in view of the objective pursued - the principle of "minimisation" of the data) and the **consequences for the person** in case of failure to provide the data;
|
||||
* **Recipients or categories of recipients of the data** (who needs to access or receive them for the defined purposes, including processors?) ;
|
||||
* **The data retention period** (or criteria for determining it);
|
||||
* **The existence of data subjects' rights and the means to exercise them** (the rights of access, rectification, erasure and restriction are applicable to all processing operations) ;
|
||||
* **The contact details of the Data Protection Officer** of the body, if appointed, or of a contact point on personal data protection issues ;
|
||||
* **The right to file a complaint with your local Data Protection Agency.**
|
||||
|
||||
* In certain specific cases, additional information must be provided, for example in the case of data transfers outside the EU, fully automated decision-making or profiling, or when the lawful basis for the processing is the legitimate interest pursued by the body collecting the data ( see the [guidelines on transparency](https://www.cnil.fr/sites/default/files/atoms/files/wp260_enpdf_transparency.pdf) for more information).
|
||||
|
||||
* In the case of indirect collection, the following must be added:
|
||||
|
||||
* **Categories of data** collected ;
|
||||
* **The source of the data** (indicating in particular whether it comes from publicly available sources).
|
||||
|
||||
## In what form should I provide this information?
|
||||
|
||||
* The information must be **easy to access**: the user must be able to find it without difficulty.
|
||||
|
||||
* **It must be provided in a clear and comprehensible manner**, i.e. with simple vocabulary (short sentences, no legal or technical terms, no ambiguities) and information adapted to the target audience (with particular attention to children and vulnerable persons).
|
||||
|
||||
* **It should be written in a concise manner**. In order to avoid the pitfall of a flood of information drowning out the user, it is necessary to **bring the most relevant information at the right time**.
|
||||
|
||||
* Data protection related information must be **distinguishable from information that is not specifically related to privacy (such as contractual clauses or general terms and conditions of use).**
|
||||
|
||||
## What communication should be made when data security is compromised?
|
||||
|
||||
* **An organization may mistakenly or negligently suffer, accidentally or maliciously, a personal data breach, i.e. the destruction, loss, alteration or unauthorized disclosure of data**. In this case, the organization must report the violation to the local data protection agency within **72 hours** if it is likely to pose a risk to the rights and freedoms of individuals.
|
||||
|
||||
* If these risks are high, the organization must also inform the persons concerned as soon as possible and provide them with advice on how to protect their data (e.g. cancellation of a compromised bank card, modification of a password, modification of privacy settings, etc.).
|
||||
|
||||
* Notification of the violation to the CNIL must be made via the [CNIL website](https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles).
|
||||
|
||||
## Useful resources
|
||||
|
||||
* The [Data & Design](https://design.cnil.fr/en/) site developed by the CNIL's Digital Innovation Laboratory develops these concepts and contains [interface examples](https://design.cnil.fr/en/concepts/information/).
|
||||
* The CNIL site also contains [many examples of information notices in French](https://www.cnil.fr/fr/rgpd-exemples-de-mentions-dinformation).
|
||||
* The [personal data violations](https://www.cnil.fr/fr/les-violations-de-donnees-personnelles) page on the CNIL website (in French).
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
# Scheda n°12: Informa gli utenti
|
||||
|
||||
#### Il principio di trasparenza del GDPR richiede che ogni informazione relativa al trattamento di dati personali sia concisa, trasparente, comprensibile e facilmente accessibile in linguaggio chiaro e semplice.
|
||||
|
||||
## Chi informare, e quando?
|
||||
|
||||
* Gli interessati devono essere informati:
|
||||
|
||||
* sia **nel caso di raccolta diretta dei dati**, per esempio quando i dati sono raccolti direttamente dagli interessati (ad es. moduli, acquisti online, sottoscrizione di un contratto, apertura di un conto corrente bancario) oppure tramite strumenti o tecnologie che monitorano l’attività delle persone (ad es. analisi della navigazione Internet, geolocalizzazione e analytics o tracciamento Wi-Fi per la misura del pubblico, ecc.);
|
||||
|
||||
* che **nel caso di raccolta indiretta di dati personali**, quando i dati non sono raccolti dai diretti interessati (ad es.: dati ottenuti da partner commerciali, *data broker*, fonti pubblicamente disponibili, o altro).
|
||||
|
||||
* Le informazioni devono essere fornite:
|
||||
* **prima dell’avvio della raccolta di dati**, nel caso di raccolta diretta;
|
||||
* **il prima possibile nel caso di raccolta indiretta** (tutt’al più al primo contatto con la persona) e non oltre un mese dalla raccolta (con alcune [eccezioni](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-be-informed/#exceptions));
|
||||
* **nel caso di modifiche sostanziali al trattamento o di eventi particolari**. Per esempio: nuova finalità, nuovi destinatari, modifiche al modo in cui si possono esercitare i diritti, [data breach](#Scheda_n°1:_Identifica_i_dati_personali).
|
||||
|
||||
## Quali informazioni devo fornire?
|
||||
|
||||
* In tutti i casi, devi specificare:
|
||||
|
||||
* **L’identità e i contatti dell’organizzazione** che tratta i dati (chi tratta i dati?) ;
|
||||
* **Le finalità** (per cosa saranno usati i dati raccolti?);
|
||||
* **La base giuridica** su cui si fonda il trattamento (vedi tutte le [**informazioni sulla base giuridica**](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/));
|
||||
* **La natura obbligatoria o facoltativa della raccolta di dati** (la qual cosa richiede una riflessione a monte riguardo all’utilità della raccolta rispetto alla finalità perseguita – il principio di “minimizzazione” dei dati) e le **conseguenze per l’interessato** nel caso decida di non fornire i dati;
|
||||
* **I destinatari o le categorie di destinatari dei dati** (chi, per le finalità dichiarate, ha bisogno di accedere ai dati, o di riceverli, inclusi eventuali responsabili esterni?) ;
|
||||
* **Il periodo di conservazione dei dati** (o i criteri per determinarlo);
|
||||
* **L’esistenza dei diritti dell’interessato e il modo in cui può esercitarli** (diritti di accesso, rettifica, cancellazione, opposizione sono applicabili a tutte le operazioni di trattamento) ;
|
||||
* **I contatti del responsabile per la Protezione dei Dati/Data Protection Officer** dell’organizzazione, se nominato, o della persona che segue le problematiche relative alla protezione dati;
|
||||
* **Il diritto di presentare reclamo all’Autorità Garante.**
|
||||
|
||||
* In certi casi particolare bisogna fornire informazioni ulteriori, come per esempio nel caso che i dati siano trasferiti al di fuori della UE, nel caso di profilazione o decisioni automatizzate, o quando la base giuridica del trattamento è il legittimo interesse di chi raccoglie i dati (Titolare); (v. le [linee guida sulla trasparenza](https://www.cnil.fr/sites/default/files/atoms/files/wp260_enpdf_transparency.pdf) per ulteriori informazioni).
|
||||
|
||||
* Nel caso di raccolta indiretta dei dati, occorre specificare anche:
|
||||
|
||||
* **Le categorie di dati** raccolti;
|
||||
* **L’origine dei dati** (indicando in particolare se vengono da fonti pubblicamente disponibili).
|
||||
|
||||
## In quale forma devo fornire queste informazioni (informativa)?
|
||||
|
||||
* Le informazioni devono essere **di facile accesso**: l’utente deve essere in gradi di trovarle senza difficoltà.
|
||||
|
||||
* **Devono essere fornite in modo chiaro e comprensibile**, ad es. con un vocabolario ridotto (frasi brevi, niente termini tecnici o legali, niente ambiguità) e con informazioni adattate al tipo di pubblico (con particolare attenzione ai minori e alle persone vulnerabili).
|
||||
|
||||
* **Devono essere scritte in modo conciso**. Per evitare che troppe informazioni distolgano l’utente, è necessario **fornire le informazioni più rilevanti al momento giusto**.
|
||||
|
||||
* Le informazioni relative alla protezione dei dati devono essere **distinguibili da informazioni non specificamente relative alla privacy (come clausole contrattuali o termini generali e condizioni d’uso).**
|
||||
|
||||
## Cosa devo comunicare quando la sicurezza dei dati viene compromessa?
|
||||
|
||||
* **Un’organizzazione può, per errore o negligenza, accidentalmente o in seguito a un attacco, subire una violazione di dati personali, cioè la perdita, alterazione, distruzione o distribuzione non autorizzata di dati**. In questo caso, se l’evento può rappresentare un rischio per i diritti e le libertà fondamentali degli interessati, l’organizzazione deve comunicare l’evento alla propria Autorità Garante **entro 72 ore**.
|
||||
|
||||
* Se questi rischi sono elevati, l’organizzazione deve anche informare il prima possibile gli interessati, fornendo loro indicazioni su come proteggere i propri dati (ad es. cancellazione di carte di credito compromesse, modifica di password, modifica dei parametri di sicurezza, ecc.).
|
||||
|
||||
* La notifica della violazione all’Autorità Garante deve avvenire tramite il modulo [sul sito del Garante](https://gpdp.it/web/guest/home/docweb/-/docweb-display/docweb/9128501)
|
||||
|
||||
## Risorse utili
|
||||
|
||||
* Il sito [Data & Design](https://design.cnil.fr/en/) (in Inglese) sviluppato dal Digital Innovation Laboratory di CNIL sviluppa questi concetti e contiene [esempi di interfaccia](https://design.cnil.fr/en/concepts/information/).
|
||||
* Il sito di CNIL e del Garante contengono anche [molti esempi in Francese](https://www.cnil.fr/fr/rgpd-exemples-de-mentions-dinformation) e in italiano.
|
||||
* La [pagina sulle violazioni dei dati personali](https://www.cnil.fr/fr/les-violations-de-donnees-personnelles) sul sito di CNIL (in Francese) ) e del Garante (in Italiano).
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
# Scheda n°13: Preparati all’esercizio dei diritti degli interessati
|
||||
|
||||
#### Le persone di cui tratti i dati mantengono dei diritti su quei dati: diritto di accesso, di rettifica, di opposizione, di cancellazione, di portabilità dei dati e di limitazione del trattamento. Devi fornire loro gli strumenti per esercitare in modo effettivo i loro diritti, e allo stesso tempo includere nei tuoi sistemi informatici tutti gli strumenti informatici necessari perché quei diritti possano essere adeguatamente rispettati.
|
||||
|
||||
#### Definendo in anticipo le modalità con cui potranno contattarti, e i modi con cui risponderai alle loro richieste, sarai in grado di gestire in modo efficace il loro esercizio dei diritti.
|
||||
|
||||
|
||||
## Misure minime da attivare
|
||||
|
||||
* All organisations that use personal data have **the obligation to indicate where and how** individuals can exercise their rights in relation to this data. For example, you can mention an e-mail address or a web form when informing individuals, as well as in your privacy policy.
|
||||
|
||||
* In order to facilitate the exercise of people's rights, these rights may also be **implemented**, in whole or in part, directly in **the application or software you develop**. This specific implementation is not mandatory, but it allows you to meet users' expectations and reduce the time and complexity of processing this type of request.
|
||||
|
||||
* Above all, in case of access or operations directly performed by a person who exercises his or her rights, do not forget to manage his **authentication** in a secure way. Overall, **trace** also all operations that have an impact on his or her personal data.
|
||||
|
||||
* Ogni organizzazione che usa dati personali ha **l’obbligo di indicare dove e come** le persone interessate possono esercitare i propri diritti relativamente a quei dati. Per esempio, puoi indicare un indirizzo email o un form web al momento in cui informi le persone del trattamento o nella tua privacy policy.
|
||||
* Per facilitare l’esercizio dei diritti delle persone, questi diritti possono anche essere **implementati**, in tutto o in parte, direttamente **nell’applicazione o nel software che sviluppi**. Questo ti permette di venire incontro alle aspettative degli utenti e di ridurre il tempo e la complessità di trattare le loro richieste.
|
||||
* Soprattutto, sia nell’accesso ai propri dati che nelle operazioni effettuate direttamente da una persona sui propri dati in tuo possesso, non dimenticare di gestire **l’autenticazione** in modo sicuro. Ad ogni modo, **tieni traccia** di tutte le operazioni che hanno un impatto sui suoi dati personali.
|
||||
|
||||
## Alcuni esempi di diritti e di una loro possibile implementazione
|
||||
|
||||
* **Diritto di accesso**: le persone hanno il diritto di ottenere una copia di tutte le informazioni su di loro di cui sei in possesso. Questo, fra l’altro, permette a una persona di sapere se dati che la riguardano sono oggetto di trattamento e di ottenerne una copia in un formato di uso comune. In particolare, la persona può controllare la correttezza delle informazioni.
|
||||
|
||||
**_Possibile implementazione_**: Prevedi una funzionalità che consenta la visualizzazione di tutti i dati relativi a uno specifico interessato. Se la quantità di dati è eccessiva, offri all’interessato la possibilità di scaricare un archivio contenente tutti i suoi dati.
|
||||
|
||||
- **Diritto di cancellazione**: le persone hanno il diritto di chiedere la cancellazione di tutti i dati di cui disponi su di loro.
|
||||
|
||||
**_Possibili implementazioni_**:
|
||||
|
||||
1. Prevedi una funzionalità che cancelli tutti i dati di una persona.
|
||||
2. Prevedi anche una notifica automatica a tutti i responsabili esterni perché a loro volta cancellino i dati relativi a quella persona.
|
||||
3. Prevedi anche la possibilità di cancellare i dati anche dai backup, o fornisci una soluzione alternativa che, quando si ripristina un backup, non ripristini i dati cancellati.
|
||||
|
||||
* **Diritto di opposizione**: in alcuni casi le persone hanno il diritto a opporsi al trattamento dei loro dati per uno scopo specifico.
|
||||
**_Possibile implementazione_**: prevedi una funzionalità che permetta agli interessati di esprimere la propria opposizione al trattamento. Quando l’interessato esercita il proprio diritto di opposizione in questo modo, il Titolare del trattamento deve cancellare i dati già raccolti, e deve astenersi dal raccogliere altri dati relativi alla persona in questione.
|
||||
* **Diritto alla portabilità dei dati**: le persone hanno il diritto a ricevere i propri dati in un formato leggibile da computer per il proprio uso personale o per il trasferimento a un’altra organizzazione
|
||||
**_Possibile implementazione_**: Prevedi una funzionalità che consenta alle persone di scaricare i propri dati in un formato machine-readable standard (CSV, XML, JSON, etc.).
|
||||
* **Diritto di rettifica**: le persone hanno il diritto a chiedere la modifica dei propri dati quando questi siano scorretti, al fine di evitare la disseminazione di informazioni erronee.
|
||||
**_Possibile implementazione_**: consenti la modifica diretta dei dati nell’account dell’utente.
|
||||
* **Diritto alla limitazione del trattamento**: le persone hanno il diritto a chiedere la sospensione per un certo periodo di tempo del trattamento dei propri dati, ad esempio per valutare una loro disputa riguardo al trattamento dei loro dati o per dar loro il tempo di esercitare i propri diritti.
|
||||
**_Possibile implementazione_**: Permetti agli amministratori di sistema di mettere “in quarantena” i dati di una persona: da quel momento quei dati non possono più essere né letti né modificati.
|
||||
|
||||
## In conclusione
|
||||
|
||||
* Il [sito Data & Design](https://design.cnil.fr/en) sviluppato dal Digital Innovation Laboratory di CNIL sviluppa questi concetti e contiene [esempi di interfacce per l’esercizio dei diritti](https://design.cnil.fr/en/concepts/exercising-rights/).
|
||||
|
||||
* E poi, lascia andare la tua **inventiva**!(In caso di dubbi, puoi aconsultare la CNIL o il Garante nelle forme previste).
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
# Sheet n°13: Prepare for the exercise of people rights
|
||||
|
||||
#### The persons whose data you process have rights on his or her data: right of access, to rectification, to object, to erasure, to data portability and to restriction of processing. You must give them the means to effectively exercise their rights and provide in your computer systems the technical tools that will allow their rights to be properly taken into account.
|
||||
|
||||
#### Preparing in advance how they will contact you and how you will deal with their requests will enable you to manage the exercise of these rights effectively.
|
||||
|
||||
|
||||
## Minimum measures to be put in place
|
||||
|
||||
* All organisations that use personal data have **the obligation to indicate where and how** individuals can exercise their rights in relation to this data. For example, you can mention an e-mail address or a web form when informing individuals, as well as in your privacy policy.
|
||||
|
||||
* In order to facilitate the exercise of people's rights, these rights may also be **implemented**, in whole or in part, directly in **the application or software you develop**. This specific implementation is not mandatory, but it allows you to meet users' expectations and reduce the time and complexity of processing this type of request.
|
||||
|
||||
* Above all, in case of access or operations directly performed by a person who exercises his or her rights, do not forget to manage his **authentication** in a secure way. Overall, **trace** also all operations that have an impact on his or her personal data.
|
||||
|
||||
## Here are some examples of rights and their possible implementation
|
||||
|
||||
* **Right of access**: people have the right to obtain a copy of all the information you have about them. This allows, among other things, a person to know whether data concerning him or her is being processed and to obtain a readable copy in an understandable format. In particular, it allows the accuracy of the data to be checked.
|
||||
**_Possible implementation_**: Provide a functionality to display all data relating to a person. If there is a lot of data, you can split the data into several displays. If the data is too large, offer the person to download an archive containing all his or her data.
|
||||
|
||||
* **Right to erasure**: Persons have the right to request the deletion of all the data you hold on them.
|
||||
**_Possible implementations_**:
|
||||
1. Provide a functionality to erase all data relating to a person.
|
||||
2. Also provide for automatic notification of processors to also erase the data relating to that person.
|
||||
3. Provide for data erasure also in backups, or provide an alternative solution that does not restore erased data relating to that person.
|
||||
|
||||
* **Right to object**: individuals have the right to object in certain cases to their data being used for a specific purpose.
|
||||
**_Possible implementation_**: provide a functionality allowing the data subject to object to the processing. When the data subject exercises his or her right to object in this way, the controller must delete data already collected, and must not subsequently collect any more data related to that person.
|
||||
|
||||
* **Right to data portability**: Individuals have the right to retrieve their data in a machine-readable format for their own use or for transfer to another organisation.
|
||||
**_Possible implementation_**: Provide a feature that allows the data subject to download his or her data in a standard machine-readable format (CSV, XML, JSON, etc.).
|
||||
|
||||
* **Right to rectification**: Individuals have the right to request the modification of their data when it is incorrect in order to limit the use or dissemination of erroneous information.
|
||||
**_Possible implementation_**: Allow to directly modify data in the user account.
|
||||
|
||||
* **Right to restriction of processing**: individuals have the right to request that the processing of their data be blocked for a certain period of time, e.g. the time to examine a dispute on their part regarding the use of their data or a request to exercise rights.
|
||||
**_Possible implementation_**: Allow administrators to put data about a person in "quarantine": this data can then no longer be read or modified.
|
||||
|
||||
## In conclusion
|
||||
|
||||
* The [Data & Design site](https://design.cnil.fr/en) developed by the CNIL's Digital Innovation Laboratory develops these concepts and contains [examples of interfaces for exercising rights](https://design.cnil.fr/en/concepts/exercising-rights/).
|
||||
|
||||
* Finally, be **inventive**! (In case of doubt, ask the CNIL for advice).
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
# Sheet n°14: Define a data retention period
|
||||
|
||||
#### Personal data cannot be kept for an indefinite period of time: this must be defined according to the purposes of the processing. Once this purpose has been achieved, the data should be archived, deleted or made anonymous (e.g. in order to produce statistics).
|
||||
|
||||
## Data retention cycles
|
||||
|
||||
* The personal data retention cycle can be divided into **three distinct successive phases**:
|
||||
* The active database;
|
||||
* Intermediate archiving;
|
||||
* Final archiving or deletion.
|
||||
|
||||
|
||||
* The mechanisms for deleting personal data from the active bases ensure that the data are kept and accessible by the operational services only **for the time necessary to achieve the purpose of the processing operation**.
|
||||
|
||||
* Ensure that **data is not kept in active databases** by simply noting them **as being archived**. The archived data (intermediate archive) must be accessible only to a specific service responsible for accessing and removing them from the archive if necessary.
|
||||
|
||||
* Please also ensure that you have **specified access modes** for the archived data, as the use of an archive must be on an ad hoc and exceptional basis.
|
||||
|
||||
* If possible, use the same implementation when implementing the **data purging or anonymisation** as the one managing the **right to erasure** (see [sheet on the exercise of rights](Sheet_n°13:_Prepare_for_the_exercise_of_people's_rights)), in order to guarantee a homogeneous operation of your system.
|
||||
|
||||
## Some examples of shelf life
|
||||
|
||||
* The **data relating to payroll management or employee time control** can be kept for 5 years.
|
||||
|
||||
* The **data in a medical file** must be kept for 20 years.
|
||||
|
||||
* The **data of a prospect not responding to any solicitation** can be kept for 3 years.
|
||||
|
||||
* The **log data** can be kept for 6 months.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
# Scheda n°14: Definisci un periodo di conservazione dei dati
|
||||
|
||||
#### I dati personali non possono essere conservati per un periodo di tempo indefinito: il periodo di conservazione deve essere determinato sulla base dello scopo del trattamento. Una volta che lo scopo è stato raggiunto, i dati devono essere archiviati (se esiste un obbligo di legge di conservazione), cancellati o anonimizzati (ad esempio, per produrne delle statistiche).
|
||||
|
||||
## Cicli di conservazione dei dati
|
||||
|
||||
* Il ciclo di conservazione dei dati personali può essere diviso in **tre distinte fasi successive**:
|
||||
* il database attivo;
|
||||
* l’archiviazione intermedia;
|
||||
* l’archiviazione finale o la cancellazione.
|
||||
|
||||
|
||||
* I meccanismi per la cancellazione di dati personali dai database attivi assicurano che i dati siano conservati ed acceduti da parte dei servizi operativi solo **per il tempo necessario al raggiungimento dello scopo del trattamento** .
|
||||
* Assicurati che **i dati non sono mantenuti in database attivi** semplicemente **catalogandoli come archiviati** . I dati archiviati (archivio intermedio) devono essere accessibili solo a uno specifico servizio responsabile della loro cancellazione dall’archivio se necessario.
|
||||
* Assicurati di avere **specificato dei modelli di accesso** per i dati archiviati, perché l’accesso a un archivio deve avvenire solo per motivi specifici o eccezionali.
|
||||
* Se possibile, utilizza la stessa implementazione tanto per **la cancellazione o l’anonimizzazione** quanto per il **diritto alla cancellazione** (vedi [scheda 13 sull’esercizio dei diritti](Scheda_n°13:_Preparati_all'esercizio_dei_diritti_degli_interessati)), in modo da garantire un funzionamento omogeneo del tuo sistema.
|
||||
|
||||
## Alcuni esempi di tempi di conservazione (validi in Francia)
|
||||
|
||||
* I **dati relativi agli stipendi o al computo orario degli impiegati** possono essere conservati per 5 anni.
|
||||
|
||||
* I **dati in un archivio medico** devono essere conservati per 20 anni.
|
||||
|
||||
* I **dati di un potenziale cliente che non risponde ai solleciti** possono venire conservati per 3 anni.
|
||||
|
||||
* I **dati di log** possono essere conservati per 6 mesi.
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
# Scheda n°15: Considera la base giuridica durante l’implementazione tecnica
|
||||
|
||||
#### Il trattamento dei dati personali si deve basare su una delle “basi giuridiche” indicate nell’[Articolo 6 del GDPR](https://eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=CELEX:32016R0679&from=IT#d1e1898-1-1). La base giuridica di un trattamento è in un certo senso la giustificazione dell’esistenza del trattamento. La scelta di una base giuridica ha una ricaduta diretta sulle condizioni per implementare le operazioni di trattamento e i [diritti degli interessati](#Scheda_n°13_:_Preparati_all'esercizio_dei_diritti_degli_interessati). Per questo, individuare le basi giuridiche del trattamento prima di avviare qualsiasi sviluppo ti aiuterà a includere le funzioni necessarie ad assicurare che tutte le operazioni di trattamento rispondano ai requisiti di legge e rispettino i diritti delle persone.
|
||||
|
||||
## Definizione delle basi giuridiche nel GDPR
|
||||
|
||||
* Nell’ambito di un’organizzazione privata, le basi giuridiche usate per sviluppare un trattamento di dati sono di solito:
|
||||
* **Contratto**: il trattamento è necessario per la preparazione o la realizzazione di un contratto fra l’interessato e l’entità che effettua le operazioni di trattamento;
|
||||
* **Legittimo interesse**: l’organizzazione ha un “legittimo” interesse a eseguire le operazioni di trattamento, purché non vengano meno i diritti e le libertà degli interessati.;
|
||||
* **Consenso**: L’interessato ha dato il suo esplicito consenso al trattamento dei propri dati.
|
||||
|
||||
* Un ente o una autorità pubblica che svolgono compiti di pubblico interesse possono usare anche altre basi giuridiche:
|
||||
* **Obbligo di legge**: il trattamento è richiesto da un testo normativo.
|
||||
* **Compito di pubblico interesse**: il trattamento è necessario per svolgere un compito nel pubblico interesse.
|
||||
|
||||
* Infine, in casi molto specifici, la base giuridica può essere la **tutela degli interessi vitali**, per esempio in casi di emergenza sanitaria.
|
||||
|
||||
|
||||
## Scegli la base giuridica appropriata
|
||||
|
||||
* Per prima cosa, controlla sul sito di CNIL o del Garante che non ci siano **norme che impongono specifici vincoli** (per esempio: [cookie e altri tracciatori](https://www.cnil.fr/sites/default/files/atoms/files/draft_recommendation_cookies_and_other_trackers_en.pdf)).
|
||||
|
||||
* **Una sola base giuridica può essere scelta** per una data finalità. Non si possono cumulare più basi giuridiche per una stessa finalità. Le stesse operazioni possono rispondere a più di una finalità, e ciascuna di esse deve avere la propria base giuridica.
|
||||
|
||||
* Come detto sopra, nel caso di una **pubblica autorità**, l’obbligo di legge e il pubblico interesse saranno le basi giuridiche più rilevanti nella maggior parte dei casi.
|
||||
|
||||
* Se le operazioni di trattamento sono parte di una relazione contrattuale e il loro scopo è oggettivamente e strettamente necessario per la fornitura del servizio all’utente (ad es. nome, cognome e indirizzo per creare un account su un sito di commercio elettronico), allora la base giuridica più appropriata dovrebbe essere il **contratto**.
|
||||
|
||||
* Se il trattamento non è parte di una relazione contrattuale con l’utente, allora puoi appellarti **alla base giuridica del consenso o del legittimo interesse**. Se il trattamento è potenzialmente intrusivo (ad esempio, raccolta di dati di geolocalizzazione, ecc.) allora **è probabile che la base giuridica appropriata sia il consenso**.
|
||||
|
||||
* Se il trattamento riguarda **dati sensibili** (dati riguardanti la salute, orientamento sessuale, politico, ecc.) allora, oltre alla base giuridica, devi identificare anche un’eccezione [nell’articolo 9 del GDPR](https://eur-lex.europa.eu/legal-content/IT/TXT/HTML/?uri=CELEX:32016R0679&from=IT#d1e2058-1-1) al divieto di trattamento.
|
||||
|
||||
## Esercizio dei diritti e informazione da fornire a seconda della base giuridica
|
||||
|
||||
* La tabella qui sotto riassume i diritti che possono essere esercitati per ciascuna base giuridica:
|
||||
|
||||
| | Diritto di accesso | Diritto di rettifica | Diritto di cancellazione | Diritto di limitazione | Diritto alla portabilità dei dati | Diritto di obiezione |
|
||||
|:---------------------:|:-------------:|:----------------------:|:--------------------:|:-----------------------------------:|:----------------------:|:---------------------------:|
|
||||
| **Consenso** | ✔ | ✔ | ✔ | ✔ | ✔ | **Ritiro del consenso** |
|
||||
| **Contratto** | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ |
|
||||
| **Legittimo interesse** | ✔ | ✔ | ✔ | ✔ | ✘ | ✔ |
|
||||
| **Obbligo di legge** | ✔ | ✔ | ✘ | ✔ | ✘ | ✘ |
|
||||
| **Pubblico interesse** | ✔ | ✔ | ✘ | ✔ | ✘ | ✔ |
|
||||
| **Tutela degli interessi vitali** | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ |
|
||||
|
||||
* La base giuridica deve sempre comparire nell’informativa fornita alla persona interessata.
|
||||
|
||||
* **Se il trattamento si basa sul legittimo interesse**, devi anche indicare quale interesse intendi perseguire (contrasto alle frodi, sicurezza del sistema, ecc.).
|
||||
|
||||
* Ti raccomandiamo di **documentare la tua scelta di una base giuridica**. Per esempio, puoi riportare queste scelte in una mappa dei processi o includerle nella documentazione tecnica.
|
||||
|
||||
|
||||
## Il caso specifico dei cookie e degli altri tracciatori
|
||||
|
||||
* La Direttiva Europea ePrivacy richiede il consenso dell’utente prima di qualsiasi azione che registri informazioni (tramite cookie, identificatori o altri tracciatori come fingerprint e pixel) o che acceda a informazioni registrate nel dispositivo dell’utente.
|
||||
|
||||
* Viene fatta un’eccezione quando i cookie hanno il solo scopo di consentire comunicazioni elettroniche, o sono strettamente necessari per fornire un servizio richiesto dall’utente.
|
||||
|
||||
* Inoltre, l’uso di un singolo tracciatore per una pluralità di scopi non ti esenta dall’ottenere il consenso per ciascuno degli scopi che lo richiedono. Per esempio, se un cookie di autenticazione viene usato anche per consentire pubblicità mirate, devi ottenere il consenso per questo secondo scopo, come faresti se l’utente non fosse autenticato.
|
||||
|
||||
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
# Sheet n°15: Take into account the legal basis in the technical implementation
|
||||
|
||||
#### Processing of personal data must be based on one of the "legal basis" mentioned in [Article 6 of the GDPR](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=FR#d1e1888-1-1). The legal basis of a processing operation is in a way the justification of the existence of the processing operation. The choice of a legal basis has a direct impact on the conditions for implementing the processing operation and [the rights of individuals](#Fiche_n°13_:_Preparing_the_exercise_of_persons_rights). Thus, anticipating the legal basis of the processing operations prior to any development will help you integrating the necessary functions to ensure that these processing operations comply with the law and respect the individuals rights.
|
||||
|
||||
## Definition of the legal bases in the GDPR
|
||||
|
||||
* In the context of a development for a private organization (companies, associations, etc.), the legal basis often used are:
|
||||
* **The contract**: the processing is necessary for the performance or preparation of a contract between the data subject and the body carrying out the processing operation;
|
||||
* **The legitimate interest**: the organization has a "legitimate" interest in carrying out the processing and it is not likely to adversely affect the rights and freedoms of the data subjects;
|
||||
* **Consent**: the data subject has given his or her explicit consent to the processing.
|
||||
|
||||
* If you are a public authority or a body pursuing tasks in the public interest, other legal bases may also be used:
|
||||
* **The legal obligation**: the processing is imposed by regulatory texts.
|
||||
* **The public-interest mission**: the processing is necessary for the performance of a task carried out in the public interest.
|
||||
|
||||
* Finally, in very specific cases, **protect of vital interests** may be used as a legal basis, for example when processing is necessary to monitor the spread of epidemics or in cases of humanitarian emergency.
|
||||
|
||||
|
||||
## Choose the appropriate legal basis
|
||||
|
||||
* First of all, check on the CNIL website that **a text does not impose any particular constraints** (for example: [cookies and other trackers](https://www.cnil.fr/sites/default/files/atoms/files/draft_recommendation_cookies_and_other_trackers_en.pdf)).
|
||||
|
||||
* **Only one legal basis must be chosen** for a given purpose. Legal basis cannot be cumulated for the same purpose. The same data processing operation may pursue several purposes and a legal basis must then be defined for each of them.
|
||||
|
||||
* As mentioned above, if you are a **public authority**, the legal obligation and the public interest mission will be the most relevant in most cases.
|
||||
|
||||
* If your processing operation is part of a contractual relationship and its purpose is objectively and strictly necessary for the provision of the user's service (e.g. name, first name and address to create an account on an e-commerce site) then **contract should be appropriate**.
|
||||
|
||||
* If your processing is not part of a contractual relationship with the user, then **the legal basis of consent or legitimate interest** may be invoked. If your processing is potentially intrusive (profiling, collection of geolocation data, etc.) then **consent is likely to be the appropriate legal basis**.
|
||||
|
||||
* If your processing contains **sensitive data** (health data, data concerning life or sexual orientation, etc.), then you will need to identify, in addition to the legal basis, an exception provided for by [Article 9 of the GDPR](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=FR#d1e2051-1-1).
|
||||
|
||||
## Rights exercises and modalities of information to be provided according to legal basis
|
||||
|
||||
* The following table summarizes the exercises of rights to be provided in accordance with legal basis:
|
||||
|
||||
| | Right of access | Right to rectification | Right to erasure | Right to restriction of processing| Right to data portability | Right to object |
|
||||
|:---------------------:|:-------------:|:----------------------:|:--------------------:|:-----------------------------------:|:----------------------:|:---------------------------:|
|
||||
| **Consent** | ✔ | ✔ | ✔ | ✔ | ✔ | **Withdraw of consent**|
|
||||
| **Contract** | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ |
|
||||
| **Legitimate interest** | ✔ | ✔ | ✔ | ✔ | ✘ | ✔ |
|
||||
| **Legal obligation** | ✔ | ✔ | ✘ | ✔ | ✘ | ✘ |
|
||||
| **Public interest** | ✔ | ✔ | ✘ | ✔ | ✘ | ✔ |
|
||||
| **Protect of vital interests** | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ |
|
||||
|
||||
* The legal basis used must **always appear in the information transmitted to the person**.
|
||||
|
||||
* **Where your processing is based on legitimate interest**, you must also indicate the legitimate interests pursued (fight against fraud, system security, etc.).
|
||||
|
||||
* It is recommended to **document your choice of legal basis**. As an example, these choices can be indicated in a processing map or associated with your technical documentation.
|
||||
|
||||
|
||||
## The specific case of cookies and other trackers
|
||||
|
||||
* The European ePrivacy Directive requires the user's consent before any action is taken to store information - via cookies, identifiers or other tracers (software fingerprints, pixels) or to access information stored in the user's terminal equipment.
|
||||
|
||||
* However, an exception is made when cookies are for the sole purpose of carrying out electronic communication, or are strictly necessary to provide a service requested by the user.
|
||||
|
||||
* Furthermore, the use of a single tracer for multiple purposes does not exempt from obtaining consent for the purposes that require it. For example, if an authentication cookie is also used for advertising targeting purposes, consent must be obtained for the latter purpose, in the same way as for a non-logged site.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
# Scheda n°16: Usa le analytics nei tuoi siti e applicazioni
|
||||
|
||||
#### Gli strumenti per la misurazione del pubblico sono utilizzati per ottenere informazioni riguardo alla navigazione dei visitatori di un sito o di una applicazione mobile. In particolare, rendono possibile comprendere in che modo gli utenti arrivano al sito e di ricostruire il loro percorso al suo interno. I cookie sono soggetti a consenso, eccetto in un caso particolare. Nota che questa sezione fa riferimento alla direttiva ePrivacy e può essere soggetta a variazioni su base nazionale. Informati presso la tua Autorità Garante per la Protezione dei Dati Personali per conoscere la sua posizione al riguardo.
|
||||
|
||||
## Ottenere il consenso
|
||||
|
||||
* In generale, **prima di caricare o leggere un cookie o un tracciatore**, chi produce un sito o un’applicazione deve:
|
||||
|
||||
* informare gli utenti Internet riguardo allo scopo dei cookie;
|
||||
|
||||
* ottenere il loro consenso;
|
||||
|
||||
* fornirgli la possibilità di rifiutarlo.
|
||||
|
||||
* A meno di ricadere nel perimetro esatto descritto nel prossimo paragrafo, **questo obbligo si applica ai tracciatori usati per la misurazione del pubblico sui siti web**.
|
||||
|
||||
## Per beneficiare dell’esenzione dal consenso
|
||||
|
||||
* **A seconda di un certo numero di condizioni**, i cookie usati per la misurazione del pubblico sono esentati dal consenso.
|
||||
|
||||
* **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)linee guida per i cookie e altri tracciatori (in Inglese), per la Francia e sul sito del Garante per l’Italia, 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.
|
||||
|
||||
## In pratica
|
||||
|
||||
* **La maggior parte delle offerte riguardanti la misura del pubblico non ricadono nello scopo dell’esenzione, indipendentemente da come vengono configurate**.
|
||||
|
||||
* Per beneficiare di questa esenzione, contatta il tuo solution provider, o usa software open source come Matomo che puoi configurare autonomamente.
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
# Sheet n°16: Use analytics on your websites and applications
|
||||
|
||||
#### Audience measurement tools are used to obtain information about the navigation of visitors on a website or mobile application. In particular, they make it possible to understand how users arrive at a site and to reconstruct their journey. Using cookies, they are subject to the rule of consent, except in one particular case. Please note that this section is relative to the ePrivacy directive and may be subject to national variation. Contact you local data protection agency to know its position.
|
||||
|
||||
## Obtaining consent
|
||||
|
||||
* Generally speaking, **before depositing or reading a cookie or tracer,** editors of sites or applications must:
|
||||
|
||||
* inform Internet users of the purpose of cookies;
|
||||
|
||||
* obtain their consent;
|
||||
|
||||
* provide them with a means of refusing them.
|
||||
|
||||
* Unless they fall exactly within the perimeter defined below, **this obligation applies to tracers used for audience measurement**.
|
||||
|
||||
## To benefit from the exemption from consent
|
||||
|
||||
* **Subject to a number of conditions**, cookies used for audience measurement are exempt from consent.
|
||||
|
||||
* **These conditions, as specified in the [guidelines on cookies and other trackers](https://www.cnil.fr/en/cookies-and-other-tracking-devices-cnil-publishes-new-guidelines), are**:
|
||||
|
||||
* To inform users of their use;
|
||||
|
||||
* To give them the ability to object to their use;
|
||||
|
||||
* To limit to the following purposes only:
|
||||
|
||||
* audience measurement;
|
||||
|
||||
* A/B testing;
|
||||
|
||||
* Not to cross-check the data processed with other processing (customer files, statistics on visits to other sites, etc.);
|
||||
|
||||
* To limit the scope of the tracer to a single site or application editor;
|
||||
|
||||
* To truncate the last byte of the IP address;
|
||||
|
||||
* To limit the lifetime of the trackers to 13 months.
|
||||
|
||||
* Provided that the conditions are met, **we therefore switch from an opt-in to an opt-out regime**.
|
||||
|
||||
* It is also possible for the same third party (subcontractor) to provide a comparative audience measurement service to multiple publishers, provided that **the data is collected, processed and stored independently for each publisher and that the trackers are independent of each other**.
|
||||
|
||||
## In practice
|
||||
|
||||
* **Most large audience measurement offerings do not fall within the scope of the exemption, regardless of their configuration**.
|
||||
|
||||
* In order to benefit from this exemption, please contact your solution provider or use open source software such as Matomo that you can configure yourself.
|
||||
103
README.md
103
README.md
|
|
@ -1,99 +1,100 @@
|
|||
<p align="center"><img src="https://github.com/LINCnil/GDPR-Developer-Guide/raw/master/templates/BANNIERE-EN.JPG" width="100%" align="middle"></p>
|
||||
<p align="center"><img src="https://github.com/LINCnil/GDPR-Developer-Guide/raw/it/templates/BANNIERE-IT.jpg" width="100%" align="middle"></p>
|
||||
|
||||
|
||||
# GDPR Developer Guide
|
||||
# GDPR Guida per sviluppatori
|
||||
|
||||
#### In order to assist web and application developers in making their work GDPR-compliant, the CNIL has drawn up a new guide to best practices under an open source license, which is intended to be enriched by professionals.
|
||||
#### Al fine di aiutare gli sviluppatori di applicativi e di siti web a rendere il loro lavoro rispondente ai requisiti del GDPR, la CNIL ha redatto una nuova guida alle buone pratiche sotto licenza aperta, in modo che possa essere arricchita da altri professionisti.
|
||||
|
||||
This guide is published under [license GPLv3](https://www.gnu.org/licenses/gpl-3.0.html) and under [open license 2.0](https://www.etalab.gouv.fr/wp-content/uploads/2017/04/ETALAB-Licence-Ouverte-v2.0.pdf) (explicitly compatible with [CC-BY 4.0 FR](https://creativecommons.org/licenses/by/4.0/deed.fr)). You can freely contribute to its redaction.
|
||||
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.
|
||||
|
||||
The [French version](https://github.com/LINCnil/Guide-RGPD-du-developpeur) is the authentic version of this guide. An Italian version of this guide is also available [in pdf](https://github.com/LINCnil/GDPR-Developer-Guide/releases/tag/V1.0) and [for contributions](https://github.com/LINCnil/GDPR-Developer-Guide/tree/it).
|
||||
Questa versione italiana è stata gentilmente fornita da collaboratori esterni e rivista dal Garante per la Protezione dei Dati Personali. La [versione francese](https://github.com/LINCnil/Guide-RGPD-du-developpeur) è la versione autentica di questa guida.
|
||||
|
||||
#### Is this guide for developers only?
|
||||
La guida contiene indicazioni e buone pratiche, e pertanto fornisce a ogni stakeholder delle chiavi utili per comprendere il GDPR, quale che sia la dimensione della sua organizzazione. La guida può anche stimolare la discussione e lo sviluppo di pratiche all’interno delle organizzazioni e nelle relazioni con i clienti.
|
||||
|
||||
This guide is mainly aimed at developers working alone or in teams, team leaders, service providers but also at anyone interested in web or application development.
|
||||
## Che cosa contiene la guida?
|
||||
|
||||
It provides advice and best practices, and thus gives useful keys to understand the GDPR for every stakeholder, regardless of the size of their structure. It can also stimulate discussions and practices within the organisations and in customer relationships.
|
||||
Questa guida è divisa in **16 schede tematiche** che coprono la maggior parte delle necessità degli sviluppatori in ciascuno stadio di progetto, dalla preparazione dello sviluppo all’uso di analytics.
|
||||
|
||||
#### What does the guide contain?
|
||||
Il Regolamento Generale per la Protezione dei Dati Personali (GDPR) specifica che la protezione dei diritti e delle libertà delle persone fisiche richiede **“l'adozione di misure tecniche e organizzative adeguate per garantire il rispetto delle disposizioni del presente regolamento”** (Considerando 78).
|
||||
|
||||
This guide is divided into **16 thematic sheets** which cover most of the needs of developers at each stage of their project, from the preparation of the development to the use of analytics.
|
||||
La determinazione di tali misure è necessariamente **collegate al contesto delle operazioni di trattamento poste in essere**, e il Titolare del trattamento (l’entità pubblica o privata che tratta i dati personali) deve pertanto assicurare la protezione dei dati che è chiamato a trattare.
|
||||
|
||||
The General Data Protection Regulation (or GDPR) specifies that the protection of the rights and freedoms of natural persons requires that **"appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met"** (Recital 78).
|
||||
Le buone pratiche di questa guida, pertanto, **non intendono coprire tutte le richieste del Regolamento né intendono essere prescrittive**, ma forniscono un primo livello di misure per affrontare i problemi di sicurezza dei dati negli sviluppi IT che riguardano il trattamento di dati personali. A seconda della natura dei trattamenti, in alcuni casi potrà essere necessario implementare misure aggiuntive al fine di rispondere pienamente ai requisiti di legge.
|
||||
|
||||
The determination of these measures is necessarily **related to the context of the processing operations put in place**, and the controller (the public or private entity processing personal data) must therefore ensure the security of the data it is called upon to process.
|
||||
## Sommario
|
||||
|
||||
The good practices in this guide **are therefore not intended to cover all the requirements of the regulations nor to be prescriptive**, they provide a first level of measures to take into account privacy protection issues in IT developments that are intended to be applied to all data processing projects. Depending on the nature of the processing carried out in certain cases, additional measures will have to be implemented in order to fully comply with the regulations.
|
||||
0. [Sviluppa in linea con il GDPR](#Scheda_n°0_:_Sviluppa_in_linea_con_il_GDPR)
|
||||
|
||||
## Table of contents
|
||||
1. [Individua i dati personali](#Scheda_n°1_:_Individua_i_dati_personali)
|
||||
|
||||
0. [Develop in compliance with the GDPR](#Sheet_n°0_:_Develop_in_compliance_with_the_GDPR)
|
||||
2. [Prepara lo sviluppo](#Scheda_n°2_:_Prepara_lo_sviluppo)
|
||||
|
||||
1. [Identify personal data](#Sheet_n°1_:_Identify_personal_data)
|
||||
3. [Sviluppa in un ambiente sicuro](#Scheda_n°3_:_Sviluppa_in_un_ambiente_sicuro)
|
||||
|
||||
2. [Prepare your development](#Sheet_n°2_:_Prepare_your_development)
|
||||
4. [Gestisci il codice sorgente](#Scheda_n°4_:_Gestisci_il_codice_sorgente)
|
||||
|
||||
3. [Securing your development environment](#Sheet_n°3_:_Securing_your_development_environment)
|
||||
5. [Fai scelte architetturali informate](#Scheda_n°5_:_Fai_scelte_architetturali_informate)
|
||||
|
||||
4. [Manage your source code](#Sheet_n°4_:_Manage_your_source_code)
|
||||
6. [Metti in sicurezza siti, applicazioni e server](#Scheda_n°6_:_Metti_in_sicurezza_siti,_applicazioni_e_server)
|
||||
|
||||
5. [Make an informed choice of architecture](#Sheet_n°5_:_Make_an_informed_choice_of_architecture)
|
||||
7. [Minimizza la raccolta dati](#Scheda_n°7_:_Minimizza_la_raccolta_dati)
|
||||
|
||||
6. [Securing your websites, applications and servers](#Sheet_n°6_:_Securing_your_websites,_applications_and_servers)
|
||||
8. [Gestisci i profili utente](#Scheda_n°8_:_Gestisci_i_profili_utente)
|
||||
|
||||
7. [Minimize data collection](#Sheet_n°7_:_Minimize_data_collection)
|
||||
9. [Controlla librerie e SDK](#Scheda_n°09_:_Controlla_librerie_e_SDK)
|
||||
|
||||
8. [Manage user profiles](#Sheet_n°8_:_Manage_users_profiles)
|
||||
10. [Garantisci la qualità del codice e della documentazione](#Scheda_n°10_:_Garantisci_la_qualità_del_codice_e_della_documentazione)
|
||||
|
||||
9. [Control your libraries and SDKs](#Sheet_n°09_:_Control_your_libraries_and_SDKs)
|
||||
11. [Testa le tue applicazioni](#Scheda_n°11_:_Testa_le_tue_applicazioni)
|
||||
|
||||
10. [Ensure the quality of the code and its documentation](#Sheet_n°10_:_Ensure_quality_of_the_code_and_its_documentation)
|
||||
12. [Informa gli utenti](#Scheda_n°12_:_Informa_gli_utenti)
|
||||
|
||||
11. [Test your applications](#Sheet_n°11_:_Test_your_applications)
|
||||
13. [Preparati all'esercizio dei diritti degli interessati](#Scheda_n°13_:_Preparati_all'esercizio_dei_diritti_degli_interessati)
|
||||
|
||||
12. [Inform users](#Sheet_n°12_:_Inform_users)
|
||||
14. [Definisci un periodo di conservazione dei dati](#Scheda_n°14_:_Definisci_un_periodo_conservazione_dei_dati)
|
||||
|
||||
13. [Prepare to exercise people's rights](#Sheet_n°13_:_Prepare_for_the_exercise_of_people_rights)
|
||||
15. [Considera la base giuridica durante l’implementazione tecnica](#Scheda_n°15_:_Considera_la_base_giuridica_durante_l'implementazione_tecnica)
|
||||
|
||||
14. [Define a data retention period](#Sheet_n°14_:_Define_a_data_retention_period)
|
||||
|
||||
15. [Take into account the legal basis in the technical implementation](#Sheet_n°15_:_Take_into_account_the_legal_bases_in_the_technical_implementation)
|
||||
|
||||
16. [Use analytics on your websites and applications](#Sheet_n°16:_Use_analytics_on_your_websites_and_applications)
|
||||
16. [Usa le analytics nei tuoi siti e applicazioni](#Scheda_n°16:_Usa_le_analytics_nei_tuoi_siti_e_applicazioni)
|
||||
|
||||
|
||||
|
||||
## How can I contribute to this guide?
|
||||
## Come posso contribuire a questa guida?
|
||||
|
||||
**This guide is available in two versions**:
|
||||
**Questa guida è disponibile in due versioni**:
|
||||
|
||||
* A [web version on the CNIL website](http://www.cnil.fr/en/gdpr-developers-guide) and in the tab [the "Releases" tab](https://github.com/LINCnil/GDPR-Developer-Guide/releases) of this repository;
|
||||
* This [GitHub version](https://github.com/LINCnil/GDPR-Developer-Guide), which offers the possibility for everyone to contribute.
|
||||
* Una [versione web sul sito di CNIL](http://www.cnil.fr/en/rgpd-developers-guide) e [nel tab "Releases"](https://github.com/LINCnil/GDPR-Developer-Guide/releases) di questo repository;
|
||||
* Questa [versione GitHub](https://github.com/LINCnil/GDPR-Developer-Guide), che offre a chiunque la possibilità di contribuire.
|
||||
|
||||
**The contribution is done in a few steps**:
|
||||
**Il contributo si articola in alcuni passi**:
|
||||
|
||||
* Register on Github;
|
||||
* Go to the project page;
|
||||
* You can:
|
||||
* Use the "Issue" tab to open comments or participate in the discussion
|
||||
* Use the "Fork" option to make your own modifications and propose their inclusion via the "Pull Requests" button.
|
||||
* Registrati su GitHub;
|
||||
* Vai alla pagina di progetto
|
||||
* Puoi:
|
||||
* usare il tab "Issue" per aprire commenti o partecipare alla discussione
|
||||
* Usare l’opzione "Fork" per apportare le tue modifiche e proporre la loro inclusione tramite il bottone "Pull Requests".
|
||||
|
||||
**Your contribution proposal will be examined by the CNIL before publication**. The web version of the GDPR developer's guide will be regularly updated.
|
||||
**Le tue proposte di contributo verranno esaminate da CNIL prima della pubblicazione**. La versione web della Guida al GDPR per sviluppatori sarà aggiornata regolarmente.
|
||||
|
||||
## Usage
|
||||
## Uso
|
||||
|
||||
Per rilasciare tu stesso una copia di questo repository, puoi usare **Pandoc**. Questo strumento ti aiuta a convertire le schede in un unico documento docx, odt o HTML.
|
||||
|
||||
To release this repository yourself, you can use the **Pandoc** tool. This tool will allow you to convert the records into a docx file or an HTML document.
|
||||
Puoi trovare le istruzioni su come installare Pandoc [qui]( https://pandoc.org/installing.html)
|
||||
|
||||
You can find the instructions to install this tool [here]( https://pandoc.org/installing.html)
|
||||
|
||||
* **To generate a .docx file**:
|
||||
* **Per generare un file .docx**:
|
||||
|
||||
```bash
|
||||
pandoc -s --toc --toc-depth=1 -o GDPR_developer_guide.docx [0-9][0-9]*.md
|
||||
pandoc -s --toc --toc-depth=1 -o Guide_GDPR_sviluppatori.docx [0-9][0-9]*.md
|
||||
```
|
||||
|
||||
* **To generate an .html file**:
|
||||
* **Per generare un file .odt**:
|
||||
|
||||
```bash
|
||||
pandoc -s --toc --toc-depth=1 -o Guide_GDPR_sviluppatori.odt [0-9][0-9]*.md
|
||||
```
|
||||
|
||||
* **To generare un file .html file**:
|
||||
|
||||
```bash
|
||||
pandoc -s --template="templates/mytemplate.html" -H templates/pandoc.css -o index.html README.md [0-9][0-9]*.md
|
||||
|
|
|
|||
880
index.html
880
index.html
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 142 KiB |
Loading…
Reference in New Issue