1. Misure di sicurezza base

Consideriamo gli elementi seguenti come base da applicare SEMPRE a prescindere dal livello di rischiosità.

1.1 Metodologia

Le misure seguenti potranno essere applicate:

• sui nuovi sviluppi effettuati dalla data di adozione della presente policy di sicurezza aziendale. A discrezione dell'utilizzatore capire se applicarla solo a progetti che superano un certo numero di gg/uomo o a qualsiasi progetto;
• sul pregresso va valutato attentamente e contrattualizzato con il cliente, in quanto su progetti esistenti l'impatto dell'applicazione delle misure potrebbe essere non trascurabile, risultando incompatibile con gli obiettivi di business.

1.2 Checklist

È consigliabile compilare una CHECKLIST che permetta ai gruppi di lavoro di documentare e verificare quali misure siano coperte o meno in ogni progetto che richieda di essere gestito seguendo le misure di sicurezza di seguito documentate.

1.3 Legenda

Legenda delle tipologie di ruolo legate al ciclo di vita del software

[PM/SA] = Project Manager o Responsabile Tecnico / Security Architect

[SYS/OPS] = Sistemista o DevOps

[SD] = Software Developer (generico, comprende BE/MOB/FE)

[BE] = Backend Developer

[MOB] = Mobile Developer

[FE] = Frontend Developer

2. Performance minime

Le soluzioni di programmazione impiegate devono ridurre al minimo l'impatto sulle risorse di sistema (l’attenzione alle performance ha come effetto collaterale una minor superficie di attacco). È necessario quindi:

1. [SD] Utilizzare i Data Type appropriati (es. non utilizzare Long quando Integer è sufficiente);

2. [SD] Porre le risorse più frequentemente utilizzate le une vicine alle altre;

3. [SD] Compilare il software con profilo di produzione:

• Eliminando le informazioni di debug (o utili ad una facile decompilazione);
• Eliminando i commenti o altre informazioni sfruttabili da un attaccante;
• Applicando tutte le ottimizzazioni per migliorare le performance (striping, minification, ecc.);
• Ricorrere all’offuscamento ove supportato dal linguaggio/framework applicativo.

4. [SD] [FE] [MOB] Nell’ottica del mobile first le risorse dovrebbero essere le piu’ piccole (di dimensioni) possibili (es. immagine ottimizzata, risposta json di dimensioni ridotte, ecc). In questa ottica scegliere il formato di file corretto.

3. Formattazione del codice, stile e sintassi

3.1 Formattazione

La formattazione del codice e la sintassi devono seguire le seguenti direttive standard:

1. [SD] Ogni progetto deve definire e adottare uno standard di formattazione condiviso da tutto il gruppo di sviluppo;

2. [PM/SA] condividere delle guidelines per la strutturazione del progetto (es. organizzazione packages).

3.2 Commenti

In generale si consiglia un approccio di sviluppo agile nel quale il software si auto-documenta utilizzando nomi di classi, metodi e variabili quanto più possibile parlanti e riferite al dominio funzionale trattato.

Come criterio guida è richiesto di commentare come da indicazioni successive, tutte le porzioni di codice che presentano un alto livello di complessità e che non sono quindi auto-documentanti.

[SD] Alla dichiarazione di ogni funzione, metodo o classe complessi deve sempre precedere un commento che riporti:

1. Scopo della funzione;

2. Parametri di input e output non banali a/dalla funzione;

3. Tracciamento degli aggiornamenti del codice della funzione (data ultima modifica), se non è presente un sistema di versioning;

4. È raccomandato che ogni funzione assolva un unico compito, in maniera efficiente ed efficace.

3.3 Analisi statica

1. [PM/SA] [SD] Configurare ove possibile un tool di analisi statica (es. Lint) che venga eseguito ad ogni commit. Gli IDE come Android Studio/XCode forniscono (o possono essere configurati per usare) Lint, plugin per la verifica statica del codice;

2. [PM/SA] [SD] Configurare un tool di analisi statica (es. SonarQube) da eseguire come step di pipeline ad ogni nuova release del software.

4. Configurazioni del web server e dell'application server

Le configurazioni del web server e dell'application server svolgono un ruolo chiave nella sicurezza di un'applicazione web.

Questi server sono responsabili della pubblicazione di contenuti e invocano applicazioni che generano contenuti. Inoltre, molti server di applicazioni forniscono un numero di servizi che le applicazioni Web possono utilizzare, tra cui archiviazione dati, servizi di directory, posta, messaggistica e altro. La mancata gestione della corretta configurazione dei server può portare a una vasta gamma di problemi di sicurezza.

Nella configurazione dei server va posta attenzione a:

1. [SYS/OPS] Costante aggiornamento delle security patch dei server;

2. [SYS/OPS] Configurare il web server per disabilitare il directory listing e che le applicazioni ritornino una pagina generica;

3. [SYS/OPS] [SD] Eliminare file di esempio, backup o default non necessari, inclusi script, applicazioni, file di configurazione e pagine Web;

4. [SYS/OPS] Controllare ed eliminare permessi impropri su file e directory;

5. [SYS/OPS] Servizi non necessari abilitati, tra cui gestione dei contenuti e amministrazione remota;

6. [SYS/OPS] [SD] Account predefiniti con le loro password predefinite;

7. [SYS/OPS] [SD] Funzioni amministrative o di debug abilitate o accessibili;

8. [SYS/OPS] [SD] Messaggi di errore eccessivamente informativi (e.g. gli stacktrace);

9. [SYS/OPS] Configurare correttamente Certificati SSL e impostazioni di crittografia;

10. [SYS/OPS] Utilizzo di certificati autofirmati per ottenere l'autenticazione e la protezione man-in-the-middle;

11. [SYS/OPS] Uso di certificati predefiniti;

12. [SYS/OPS] Autenticazione con sistemi esterni adeguata ai requisiti architetturali e ai livelli di rischio;

13. [SYS/OPS] Dimensionare opportunamente le risorse usate da WebServer e AppServer (transaction timeout, threads, ram, connection pools, protocols);

14. [SYS/OPS] Dotare tutti i server di software Antivirus;

15. [SD] [SYS/OPS] Configurare in modo corretto i MIME types sul server web per tutte le tipologie di file utilizzate nelle applicazioni;

16. [SD] [SYS/OPS] Non caricare sul web server nessun tipo di dato, documento, dato sensibile che non sia strettamente necessario al funzionamento dell'applicazione;

17. [SYS/OPS] Configurare il web server per mascherare eccezioni che possono insorgere ritornando sempre una pagina generica;

18. [SYS/OPS] [PM/SA] [SD] [FE] [MOB] Valutare l'utilizzo dell'header "Content-Security-Policy". Il default potrebbe essere: Content-Security-Policy: default-src 'self'. Quando possibile, mitigare problemi di "click-jacking" con il security header: X-Frame-Options: SAMEORIGIN. Valutare l'utilizzo dell'header "Referrer-Policy" per controllare quanta informazione viene passata nelle richieste. Esempio: Referrer-Policy: same-origin. Anche l'header "Permissions-Policy" può essere utile per limitare l'accesso alla funzionalità del browser (telecamera, microfono, clipboard, ecc.).

5. Separazione degli ambienti

[PM/SA] Per quanto riguarda la separazione degli ambienti di sviluppo, test e produzione occorre adottare le seguenti misure:

1. [SYS/OPS] [SD] I sistemi di sviluppo, test e produzione devono essere separati fisicamente e/o logicamente;

2. [SYS/OPS] [SD] Lo sviluppo del software deve essere fatto in un ambiente sicuro e protetto durante tutto il ciclo di vita del software (PC, rete in cui si lavora, ambienti di sviluppo, test, produzione);

3. [SYS/OPS] [SD] Compilatori, editor ed altri strumenti di sviluppo non devono essere presenti nei sistemi di produzione in cui l’applicazione risiede;

4. [SD] [SYS/OPS] [PM/SA] Le configurazioni dell’applicazione nei sistemi di produzione devono essere differenti rispetto a quelle utilizzate nei sistemi di sviluppo e test;

5. [SD] [SYS/OPS] I sorgenti dell’applicazione e delle librerie correlate, fatta eccezione per i linguaggi interpretati, non devono risiedere in chiaro all’interno dei sistemi di esercizio, bensì sotto forma di oggetti compilati. Nel caso di linguaggi interpretati, il sorgente dell’applicazione che risiede nei sistemi di esercizio deve essere offuscato. Una copia non offuscata deve comunque sempre essere conservata su un supporto diverso (es. copia su supporto CD o DVD).

6. Compilazione

1. [SD] La compilazione dei sorgenti deve prevedere una verifica di eventuali messaggi di Warning;

2. [SD] la compilazione dei sorgenti deve essere effettuata con un compilatore/pre-processore condiviso da tutto il gruppo di lavoro ed adeguato per il target cliente;

3. [SD] la compilazione dei sorgenti che produce il pacchetto di delivery deve essere effettuata dalla pipeline preposta.

7. Sviluppo del codice

7.1 Cross site scripting

Una pagina HTML può essere vista come un template con la possibilità di occupare degli "slot" con codice e dati non autentici e non verificati. XSS è una delle issue di sicurezza più frequenti secondo OWASP Top 10. Prevenire cross site scripting significa separare dati non autenticati dal contenuto del browser attivo. Questo può essere raggiunto con diverse modalità:

1. [SD] [FE] Utilizzare framework di sviluppo che automaticamente escludono XSS by design;

2. [SD] [FE] Effettuare l'escaping dei dati provenienti da richieste http/S "non autenticate" contenenti HTML in output (body, attribute, JavaScript, CSS, or URL). Allo stesso modo, effettuare l'escaping dell'input inserito dall'utente prima che questo venga aggiunto al codice HTML. Il documento OWASP Cheat Sheet XSS Prevention (opens in a new tab) contiene dettagli tecnici su come effettuare data escaping;

3. [SD] [FE] Applicare un encoding context-sensitive quando si modifica il DOM lato client è in opposizione al DOM XSS. Quando non può essere evitato devono essere applicate alle API del browser delle tecniche di escaping context sensitive simili come descritto in OWASP Cheat Sheet DOM based XSS Prevention (opens in a new tab).

7.2 Input Data Validation

[SD] L’applicazione deve assicurare, attraverso opportuni meccanismi di convalida, che tutti i parametri in input specificati dall’utente siano congruenti a quanto atteso.

In particolare:

1. [SD] Sui dati acquisiti in ingresso, l’applicazione deve prevedere l’implementazione di meccanismi di controllo che limitino il set di caratteri o valori, inseribili dall’utente, a quelli congruenti rispetto ai campi richiesti e/o alle Form di pertinenza, al fine di identificare ed annullare gli effetti dei seguenti errori:

   • [SD] Valori non pertinenti (es. immissione di caratteri non numerici nel campo anno di nascita);
   • [SD] Caratteri invalidi negli Stream (es. canali di trasmissione tra la sorgente e la destinazione attraverso il quale fluiscono i dati) o nei Data Field (es. entità all’interno delle quali sono archiviati i dati);
   • [SD] Dati mancanti o incompleti;
   • [SD] Limite del minimo volume di dati richiesti non soddisfatto;
   • [SD] Limite del massimo volume di dati acquisibile in ingresso raggiunto;
   • [SD] Una buona strategia di approccio all'Input Data Validation è suggerita da OWASP QUI (opens in a new tab).

2. [SD] I caratteri speciali, se presenti e/o richiesti in Input, sono da considerarsi pericolosi in quanto innescano diverse vulnerabilità poiché la loro combinazione non può essere considerata semplice testo. Di seguito qualche esempio di possibile combinazione:

   • < > Identificano Tag HTML;
   • ! | & ; Esecuzione comandi;
   • ▪ ' “ % Database Queries;
   • ? $ @ Programmi e Script;
   • ( ) [] Programmi e Script;
   • ../ File System Paths.

3. [SD] Inoltre, i seguenti caratteri speciali devono essere identificati e neutralizzati con tecniche di Escaping (i caratteri pericolosi devono essere sempre convertiti prima del salvataggio):

   ; | ! ' “ - \* % / < > ? $ @ : ( ) [] . `

   Di seguito alcuni esempi:

   • < Viene sostituito con <
   • > Viene sostituito con >
   • # Viene sostituito con #
   • & Viene sostituito con &
   • ( Viene sostituito con (
   • ) Viene sostituito con )

4. [SD] La convalida dell’input utente non deve essere svolta esclusivamente lato Client;

5. [MOB] Nel caso di sviluppo mobile Android per poter visualizzare pagine html che contengono js, lo sviluppatore deve esplicitamente autorizzare la webview tramite l’apposito metodo WebSettings.setJavascriptEnabled(..) (lo stesso vale per altre funzionalità legate al mondo frontend web).

7.3 Utilizzo funzioni di gestione delle stringhe

[SD] Tutti gli Input forniti dall’utente e processati dall’applicazione devono passare per funzioni sicure di gestione delle stringhe che ne prevedono il Bound Checking (analisi finalizzate a scoprire se una variabile è all'interno dei suoi limiti prima di essere utilizzata). L’applicazione deve risultare immune da problematiche di tipo:

1. [SD] Stack Overflow: avviene quando è richiesto l'uso di una quantità troppo elevata di memoria nello Stack (allocazione di memoria per l'utilizzo di un programma durante la propria esecuzione);

2. [SD] Heap Overflow: avviene nell'area dati della Heap, dove la memoria è allocata in modo dinamico dalle applicazioni Run Time (ovvero in esecuzione) e tipicamente contiene dati dei programmi utente;

3. [MOB] In ambito mobile iOS e Android hanno sistemi automatici per la protezione in caso di memory Overflow.

7.4 Specifica del formato delle stringhe

[SD] Nei sorgenti dell’applicazione, il formato delle stringhe deve essere sempre specificato nei parametri delle funzioni che lo prevedono e mai dato per assunto. L’applicazione deve risultare immune da problematiche di tipo Format String Overflow. Vedi OWASP (opens in a new tab).

7.5 Casting e variabili numeriche

[SD] L’Input utente deve essere filtrato in modo che alle variabili o strutture dati interne dell’applicazione non sia possibile assegnare valori negativi (es. dichiarando Array come Signed Integer) ad eccezione dei casi previsti e per i quali sia stata pianificata la gestione. In fase di comparazione di due variabili numeriche dove il contenuto di almeno una deriva da Input utente, il Casting o l’assegnazione di un valore da una variabile all’altra deve avvenire in base alla stessa tipologia (es. assegnare un valore intero a una variabile di tipo Short è un errore).

[SD] L’applicazione deve risultare immune da problematiche di tipo Integer Overflow, cambi di segno, troncamento di valori numerici o altri errori di programmazione logico-computazionali.

7.6 Gestione dell’output e error handling

1. [SD] L’applicazione deve fornire in Output solamente le informazioni rilevanti all’uso delle richieste avanzate dagli utenti, rendendo vana la possibilità di qualsiasi tipo di Information Gathering o Information Disclosure non autorizzato;

2. [SD] Garantire che l'applicazione, in caso di risorse inesistenti o disabilitate, restituisca risposte generiche ogni qualvolta possibile.

7.7 Insecure deserialization

[SD] Le API e quindi le applicazioni diventano vulnerabili se deserializzano oggetti compromessi da un attaccante. Vedi OWASP (opens in a new tab)

[SD] L'unico pattern architetturale di sicurezza è di NON ACCETTARE oggetti serializzati da sorgenti non autorizzate/autenticate oppure utilizzare strumenti di serializzazione che permettono esclusivamente tipi di dati primitivi.

[SD] Nel caso questo non sia possibile fare riferimento al OWASP Top 10 - Insecure Deserialization - How to Prevent.

7.8 Logging

1. [PM/SA] [SD] Adottare politiche di logging condivise dal gruppo di lavoro;

2. [PM/SA] [SD] Mappare i codici d'errore e documentarli;

3. [PM/SA] [SD] Esporre a client o terze parti messaggi d'errori codificati, non parlanti;

4. [PM/SA] [SD] L’utilizzo di framework o snippet di codice “preconfezionato/pubblico” ci permette di accelerare il lavoro di sviluppo di un’applicazione web; per contro tutti possono utilizzare lo snippet o il framework. Evitare messaggi d'errore o alert visualizzati a client che possano avantaggiare attacchi informatici. Evitare log a debug in produzione e prediligere error codes codificati.

7.9 Cross-site request forgery

1. [PM/SA] [SD] Questa casistica riguarda processi che sono vulnerabili a cross-site request forgery (CSRF or XSRF). La mitigazione prevede che tutte le richieste di cambio di stato autenticate includano un elemento aggiuntivo di secret payload (canary or CSRF token) conosciuto solamente dal sito web legittimo e dal browser e sia protetto in transito tramite SSL/TLS;

7.10 Schemi di sicurezza e crittografia

Per quanto riguarda gli schemi di sicurezza e i controlli crittografici occorre adottare le seguenti regole:

1. [SD] L’utilizzo della codifica Base64 non va usato come tecnica di cifratura, può essere utilizzato invece per l'encoding dei dati, delle stringhe o degli URL cifrati;

2. [MOB] Si suggerisce di utilizzare i sistemi di crittografia/hashing forniti dalla piattaforma (es. iOS, Android);

3. [PM/SA] [SD] Gli schemi di sicurezza devono essere semplici e standardizzati: è vietata la costruzione di schemi non standard di crittografia o e/o gestione delle chiavi;

4. [SD] Non inserire nel codice "hard coded" chiavi di accesso, indirizzi IP o qualsiasi altra informazione sensibile come nomi e cognomi, anche solo in forma di commento.

7.11 Gestione dei cookie

[PM/SA] [FE] Un tipo di dato personale che una applicazione web deve sempre gestire è il cosiddetto "cookie". I Cookie sono costituiti da porzioni di codice installate all'interno del browser che assistono il Titolare nell’erogazione del Servizio in base alle finalità descritte. Tutti i cookie utilizzati vanno indicati nell’informativa, specificando anche i tempi di conservazione dei dati. Inoltre, ad eccezione dei cookie con finalità tecnica, l’installazione dei Cookie necessita del consenso preventivo e inequivocabile dell'Utente.

[PM/SA] [FE] Le funzionalità relative alla gestione dei cookie devono minimizzarne l'utilizzo rispetto alle specifiche funzionali del singolo progetto. Inoltre deve sempre essere messa a disposizione la funzionalità di modifica o di revoca del consenso, che viene attivata nei casi previsti dal titolare. È obbligatorio tenere costantemente aggiornata la documentazione delle scelte compiute dall’utente. Per la memorizzazione delle azioni e delle scelte rimesse all’utente il gestore del sito web può avvalersi o di appositi cookie tecnici o anche di ulteriori modalità che la tecnologia dovesse rendere disponibili.

Sono inoltre applicate alcune misure di tipo tecnico:

1. [PM/SA] [SD] Nelle applicazioni Web, i cookie di sessione applicativa devono essere cifrati, non persistenti, avere il flag Secure attivato e l’attributo HttpOnly impostato;

2. [PM/SA] [SD] Un cookie non deve contenere informazioni critiche quali password o essere composto da parti predicibili come User ID o valori elaborati basandosi su algoritmi sequenziali;

3. [PM/SA] [SD] L’identificatore della sessione nel cookie deve avere un’entropia pari almeno a 128 bit;

4. [PM/SA] [SD] Nelle applicazioni Web, ciascun cookie generato deve essere soggetto ad un tempo di scadenza oltre il quale non deve più essere considerato valido.

8. Sviluppo software e trattamento dati

[PM/SA] Prima di descrivere specifiche misure da adottare a livello di sviluppo software va chiarito che è a carico del Titolare del trattamento consentire ai soggetti interessati di effettuare una scelta libera, specifica e informata.

Le seguenti misure vanno visionate dal capo progetto (PM/SA) e verificate con il 'Titolare del trattamento' ad inizio progetto.

1. [PM/SA] Determinare se l'elaborazione si basa su una base giuridica diversa dal consenso;

2. [PM/SA] Determinare i mezzi pratici da attuare per ottenere il consenso degli interessati;

3. [PM/SA] Assicurare che il consenso sia ottenuto prima che inizi l'elaborazione;

4. [PM/SA] Assicurare che il consenso sia ottenuto liberamente;

5. [PM/SA] Assicurare che il consenso sia ottenuto in modo notificato e trasparente in termini di finalità del trattamento;

6. [PM/SA] Assicurare che il consenso sia ottenuto per uno scopo specifico.

[PM/SA] E’ inoltre a carico del titolare del trattamento l’onere della cosiddetta minimizzazione del trattamento limitando la gestione di dati personali a ciò che è strettamente necessario per raggiungere lo scopo definito:

1. Comprovare che i dati personali siano sufficienti, pertinenti e non eccessivi rispetto all’intento, altrimenti, non raccogliere i dati;

2. Comprovare che i dati personali non rivelino (direttamente o indirettamente) l'origine razziale o etnica, le opinioni politiche, filosofiche o religiose, l'appartenenza sindacale, le informazioni sulla salute o le informazioni sulla vita sessuale di un individuo, tranne che per circostanze eccezionali;

3. Comprovare che i dati personali non si riferiscono a reati, sentenze penali o misure di sicurezza;

4. Limitare la trasmissione di documenti elettronici contenenti dati personali allo stretto necessario;

5. Eliminare i dati personali che non sono più utili o le richieste di un soggetto dal sistema in esercizio o dai backup, se necessario.

[PM/SA] Il software destinato al trattamento di dati personali deve essere predisposto per consentire al Titolare del Trattamento di garantire i diritti degli interessati, sempreché tali diritti non siano in contrasto con le finalità del trattamento. Nel seguito sono descritte misure di sicurezza base relative a 5 diritti degli interessati:oblio, portabilità, trasparenza, rettifica, esattezza.

Azioni di tipo sistemistico e organizzativo non sono pertinenti con l'attività di sviluppo software effettuata da Intesys in nuovi progetti o major release.

8.1 Scadenza

È a carico del Titolare del trattamento ridurre l’impatto dei rischi assicurando che i dati personali non vengano mantenuti per più di quanto necessario.

Il software sviluppato deve prevedere:

1. [PM/SA] [SD] Per ogni tabella che contiene dati personali almeno la colonna [data creazione] e [data ultima modifica];

2. [PM/SA] Nel caso il titolare del trattamento intenda gestire puntualmente la scadenza di conservazione va sviluppata una procedura (manuale a meno di diverse disposizioni) in grado di eliminare i dati personali implicati rimuovendo tutte le righe con data di creazione antecedente ad una data prefissata.

8.2 Oblio (cancellazione totale)

[PM/SA] [SD] Il software sviluppato prevede sempre una funzione "oblio" che permette di cancellare dal database TUTTI i dati personali relativi ad una persona fisica ivi contenuti. Per realizzare questa funzione, in fase di progetto del DB vengono esplicitamente identificate le tabelle che utilizzano dati personali e vengono precostruire le query di "delete" dei dati personali comprese ulteriori eventuali query necessarie a mantenere l'integrità referenziale.

8.3 Portabilità

[PM/SA] [SD] Il software sviluppato prevede sempre di mettere a disposizione delle query (o delle precise procedure software) per estrarre tutti i dati personali di una singola persona fisica

8.4 Trasparenza (informazione e accesso ai propri dati)

[PM/SA] [SD] Il software sviluppato prevede sempre una funzione che permette all'interessato di poter vedere quali sono i propri dati personali trattati o che permette all'operatore di estrarli agevolmente senza errori e ambiguità. Normalmente vengono messe a disposizione delle query (o delle precise procedure software) per estrarre tutti i dati personali di una singola persona fisica.

L’implementazione è del tutto simile a quella per il punto “Portabilità”.

8.5 Rettifica (modifica/cancellazione parziale)

[PM/SA] [SD] Non vengono previste procedure software o query già pronte. Non vengono sviluppate interfacce "self-service" di rettifica. Il titolare del trattamento valuterà quali potranno esser le modalità più opportune. Il software garantisce, attraverso la documentazione, la possibilità di effettuare le modifiche in modo coerente con le funzionalità dell'applicativo e in modo da ottemperare le eventuali richieste dell'interessato

8.6 Esattezza dei dati

[PM/SA] [SD] Deve essere minimizzata la probabilità di inserire dati personali errati o modificare erroneamente dati personali. Il software deve quindi garantire adeguati controlli e facilitazioni per gli incaricati in modo da minimizzare il rischio di imputazione errata. Per quanto possibile vengono inseriti controlli sintattici e semantici sui campi, facilità e coerenza d'uso delle form di gestione dati, verifiche di completezza e coerenza dei dati (es. codice fiscale o indirizzi), eliminazione di doppie imputazioni e doppie registrazioni. Sono utilizzate sempre funzioni di validazione dei dati: tipo, lunghezza, valore atteso, range dei valori possibili, scostamento valore rispetto al precedente, obbligatorietà, selezione da valori predefiniti.

8.7 Protezione dei dati personali

Il Regolamento (UE) 679/2106 in materia di protezione dei dati personali (di seguito, il Regolamento) suggerisce che il software che tratta dati personali debba adottare sistemi idonei per la registrazione delle attività che gli utenti effettuano secondo criteri differenziati in base al tipo di trattamento ed al rischio della libertà e dei diritti dei diritti degli interessati.

[PM/SA] [SD] L’implementazione (e la precedente fase di progettazione) dell’applicazione devono assicurare una corretta e chiara gestione degli errori e delle eccezioni con registrazioni su Log applicativo. Le registrazioni devono comprendere almeno tre elementi: il riferimento temporale, la descrizione dell'operazione che le ha generato la registrazione, l'identificativo dell'utente che ha effettuato l'operazione. Tutti i log sono generati in un formato compatibile con sistemi di centralizzazione e monitoring (Log Management Systems - LMS).

9. Autenticazione e autorizzazione

9.1 Funzioni di gestione delle credenziali di accesso

1. [PM/SA] [SD] È sempre preferibile che la gestione delle credenziali di accesso all’applicazione sia effettuata dal sistema di autenticazione di dominio afferente al relativo ambiente in cui deve essere eseguita (es. Server LDAP, SSO, ecc.);

2. [PM/SA] [SD] Quando questo non è possibile, l’applicazione dovrà gestire le credenziali di accesso con criteri adeguati alle caratteristiche dei dati gestiti;

In particolare:

3. [SD] I dati di accesso ai database o a sistemi di altra natura (es. User ID, Password, nome Database, ecc.) non devono mai essere inseriti all'interno del codice sorgente;

4. [SD] [SYS/OPS] Attivare logging sugli errori di accesso;

5. [SD] Le credenziali non devono mai apparire in forma non cifrata;

6. [SD] Le chiavi di cifratura non devono essere mai inserite staticamente nel codice;

7. [PM/SA] [SD] Il codice utente (User ID) deve essere univoco e l’applicazione deve rifiutare eventuali User ID uguali.

9.2 Trasmissione delle password in rete

[PM/SA] [SD] Le trasmissioni devono avvenire esclusivamente su canali sicuri HTTPS. Nessuna misura di sicurezza attivata di default deve essere disattivata.

9.3 Autenticazione: procedura di accesso all’applicazione

[PM/SA] [SD] La procedura di accesso e Log-On dell’applicazione deve ridurre al minimo le informazioni fornite agli utenti non ancora autenticati e prevedere determinati comportamenti.

In particolare:

1. [SD] Non deve fornire alcuna chiara indicazione sui ruoli e sui permessi assegnati ad un utente fin quando il processo di autenticazione non viene completato;

2. [PM/SA] [SD] Deve prevedere il mascheramento della password digitata dall’utente non rendendola visibile o nascondendola attraverso simboli (es. asterischi);

3. [PM/SA] [SD] Non deve trasmettere la password in chiaro nella rete (per le applicazioni di frontend è sufficiente che la password venga inviata tramite protocollo HTTPS);

4. [SD] Deve processare le informazioni fornite dall’utente per l’accesso solo quando sono complete;

5. [SD] L’autenticazione non deve mai essere un processo convalidato lato Client.

9.4 Autorizzazione: assegnazioni dei privilegi all’utente

Per quanto riguarda l’assegnazione dei privilegi all’utente occorre adottare le seguenti regole:

1. [PM/SA] [SD] Gli utenti che dispongono di credenziali di accesso all’applicazione devono essere autorizzati ad accedere solo a dati e funzioni di propria competenza relativi al proprio incarico;

2. [SD] L’applicazione deve sempre operare un controllo sui reali privilegi d’accesso dell’utente prima di autorizzare qualsiasi operazione in lettura, scrittura, rimozione o esecuzione;

3. [SD] L’autorizzazione non deve mai essere un processo convalidato lato Client;

4. [SD] L’applicazione non deve essere mai rilasciata con credenziali di utente standard di tipo amministrativo/operativo o con account protetti tramite password di default.

9.5 Gestione delle sessioni

Per quanto riguarda la gestione delle sessioni occorre adottare le seguenti regole:

1. [SD] Quando un utente ha effettuato il Log-Out, la relativa sessione deve essere invalidata:

   • [SD] Sul Server, sganciandola nella Entry Table delle sessioni attive;

   • [SD] [FE] Sul Client (es. rimuovendo il cookie o svuotando il suo contenuto).

2. [SD] La sessione deve avere sempre una scadenza temporale;

9.6 Controllo degli accessi

[SD] Il controllo dell'accesso è efficace se applicato tramite codice sicuro server-side o su server-less API. Devono quindi essere applicate le seguenti azioni preventive:

1. [SD] Ad eccezione di accessi pubblici: deny by default;

2. [SD] [FE] Implementare i meccanismi di controllo dell'accesso e riutilizzarli in tutta l'applicazione.

10 Version control system

1. [PM/SA] [SD] Utilizzare strumenti di versioning per il codice sorgente (es. Git/GitLab);

2. [PM/SA] [SD] Gestire i commit delle modifiche al codice sorgente con adeguati commenti e riferimenti ai ticket associati (jira);

3. [PM/SA] [SD] Utilizzare politiche di gestione dei branch condivise nel team e ispirate a best practice (es. GitFlow);

4. [PM/SA] [SD] Taggare release del software e versionare i pacchetti consegnati al cliente;

5. [PM/SA] [SD] Seguire modalità di versioning condivisa e ispirata a best practice (es. Semantic Versioning);

6. [PM/SA] [SD] Seguire processi aziendali di autorizzazione (PM) e autenticazione (AZIENDA) controllata ai repository da parte degli sviluppatori.