Linee Guida Identità e Autenticazione Cittadino EA-LING Data Versione Stato

(1)

EA-LING-SIC-Identità e Autenticazione Cittadino_v1.0.docx

[email protected] | https://comunemilano.sharepoint.com/sites/EnterpriseArchitecture

Direzione Innovazione Tecnologica e Digitale- Comune di Milano – Documento rilasciato con licenza CC BY 4.0 1 / 10

Linee Guida – Identità e Autenticazione Cittadino

EA-LING

^Data ^Versione ^Stato

Enterprise Architecture

Linee Guida 18/02/2022 1.0 Definitivo

1 Matrice tecnologica di riferimento

Tutte le applicazioni e servizi per il cittadino pubblicati sul portale del Comune utilizzano la piattaforma denominata CIAM dedicata a fornire servizi di autenticazione e autorizzazione. La piattaforma si basa su ForgeRock Identity Management, Access Management e Directory Services per gestire l’autenticazione e autorizzazione federativa in SSO sia per applicazioni web che mobile.

CIAM permette in maniera integrata di gestire l’autenticazione alle seguenti tipologie di utenti:

• Cittadino con credenziali SPID e CIE

• Credenziali rilasciate dal CdM

Non è consentito sviluppare nuove soluzioni che coinvolgano tecnologie categorizzate come “non disponibile per nuovi progetti”. Adottare solo tecnologie che rientrino tra quelle “Supportate” e “Preferite”. Eventuali eccezioni dovranno essere preventivamente validate dalla Direzione ITED.

2 Requisiti di autenticazione e controllo di accesso

Il Comune fornisce i servizi centralizzati per la gestione di identità federata che consentono di condividere le informazioni degli utenti alle applicazioni in Single Sign-On senza che queste debbano mantenere utenze e password nel proprio contesto.

L’applicazione non deve gestire localmente (es. attraverso un database destinato a contenere utenze e password applicative) le credenziali d’accesso, ma deve utilizzare i repository e servizi centralizzati messi a disposizione dalla Direzione Sistemi Informativi;

(2)

I Servizi di Identity centralizzati supportano i protocolli di autenticazione OpenID Connect/OAuth 2.0, SAML 2.0 e sarà cura del fornitore recepire le linee guida e concordare con Direzione Sistemi Informativi quale verrà utilizzato e quali informazioni necessita la applicazione.

La piattaforma CIAM agisce come IdP (Identity Provider) / OP (OpenID provider) nel fornire le informazioni dell’ utenza mentre la applicazione agisce come SP (Service Provider) / RP (Relying Party) riconosciuto ed autorizzato ad utilizzare queste informazioni per fornire accessi al contesto applicativo.

2.1 Autenticazione Cittadino

I cittadini secondo la normativa si autenticano con SPID e CIE per accedere ai servizi del Comune.

Il Sistema di autenticazione CIAM è federato con gli Identity Provider SPID e CIE - Ministero dell’Interno che gestiscono la fase di login e ritornano le informazioni dell’evento di autenticazione. Attualmente lo schema di autenticazione federato SSO è basato sul protocollo SAML 2.0.

I Rappresentante legale azienda con credenziali rilasciate dal CdM vengono autenticati direttamente da CIAM che ha in gestione le credenziali verificate sul registro Infocamere.

Il servizio di autenticazione CIAM agisce come IdP (SAML 2.0) e OP (OpenID Provider) nei confronti dell’applicazione definita come SP / RP. La applicazione e Il sistema di autenticazione centralizzato comunicano fra loro e creando una relazione di trust.

L’applicazione dovrà supportare ambedue gli scenari SP/RP Initiated (utente accede alla risorsa) o IdP/OP Initiated (utente accede al servizio di autenticazione).

2.1.1 Autenticazione OIDC

OpenID Connect (OIDC) è il protocollo costruito su OAuth2.0 per gestire l’autenticazione degli utenti su servizio centralizzato OP e restituire all’applicazione RP le attestazioni (informazioni dell’utente) basato su REST API. OAuth 2.0 è il framework basato su token da utilizzare per autorizzare le applicazioni a chiamare le API (rif. EA-LING-INT-API e Interoperabilità).

OIDC è il protocollo di autenticazione preferenziale per lo sviluppo di applicazioni Web e Mobile.

L’applicazione viene integrata con la piattaforma CIAM mediante l’uso del protocollo OpenID Connect.

Durante la fase di autenticazione verrà rilasciato un token di autenticazione contenente le informazioni relative all’identificazione dell’utente nel formato “variabile=valore”.

Quando un utente accede a un'applicazione, questa reindirizza il browser dell'utente al server di autorizzazione OpenID Provider che interagisce con l'utente per autenticarlo (supponendo che non abbia già effettuato l'accesso). Dopo l'autenticazione, il browser dell'utente viene reindirizzato all'applicazione.

(3)

L'applicazione può richiedere che le informazioni relative all’evento di autenticazione (asserzioni) vengano restituite in un token di sicurezza denominato ID Token. In alternativa, può richiedere un token di accesso OAuth 2.0 e utilizzarlo per chiamare l'endpoint UserInfo dell’ OpenID provider per ottenere le asserzioni.

Poiché OIDC su basa su OAuth 2.0, un'applicazione può utilizzare un provider OpenID sia per l'autenticazione dell'utente che per l'autorizzazione a chiamare l'API del OpenID provider.

ID Token sono codificati nel formato JSON Web Token (JWT) e sono utilizzati per passare le asserzioni relative all’evento di autenticazione e informazioni necessarie all’applicazione sull’utente autenticato. L’OpenID Provider firma il JWT secondo lo standard JSON Web Signature (JWS). L’applicazione è in grado di validare la firma e verificare l’integrità del dato.

Il flusso da utilizzare per l’integrazione della applicazione è Authorization Code Flow.

Diagramma di flusso di autenticazione di un RP con grant type Authorization Code Flow

Authorization Code Flow. consente di specificare PKCE Challenge con la richiesta di autenticazione (passo 2).

Se il Challenge è presente, è necessario specificare un PKCE Verifier con la richiesta token (passo 3). PKCE protegge dagli attacchi di intercettazione del codice di autorizzazione.

2.1.2 Autenticazione SAML

Security Assertion Markup Language (SAML) è un protocollo per lo scambio di dati di autenticazione e autorizzazione (dette asserzioni) tra domini di sicurezza distinti, tipicamente un identity provider (IdP) e un service provider (SP). Il formato delle asserzioni SAML è basato su XML. Questo protocollo consente di gestire cross-domain single sign-on (SSO) l’identità federata basata su SOAP API.

SAML 2.0 è supportato per applicazioni web che già supportano questo protocollo di autenticazione.

(4)

Diagramma del flusso di l’autenticazione ad un SP di tipo SP-initiated

L’applicazione viene federata con la piattaforma CIAM mediante l’uso del protocollo SAML 2.0. Durante la fase di autenticazione verrà rilasciato un token di autenticazione contenente le informazioni relative all’identificazione dell’utente nel formato “variabile=valore”.

A differenza rispetto OIDC, Il formato delle asserzioni SAML è basato su XML. I metadati sono disponibili al seguente URL:

https://sso.comune.milano.it/openam/saml2/jsp/exportmetadata.jsp?entityid=IDP_CdM&realm=/Servizi 2.1.3 Autenticazione mediante variabili HTTP Header

L’applicazione integrata non è raggiungibile direttamente su internet ma solo attraverso il reverse proxy dell’infrastruttura CIAM. Questo meccanismo va utilizzato solo nel caso di impossibilità di integrarsi nelle modalità precedenti.

Architettura logica di integrazione di nuovi servizi tramite il servizio di Reverse Proxy

(5)

L'applicazione integrata è raggiungibile al seguente URL: https://servizicoll.comune.milano.it/applicazione. Il reverse proxy si occupa di gestire l’evento di autenticazione tramite l’ Access Manager e redirige l’utente all’applicazione una volta autenticato. L’applicazione verifica le informazioni ricevute nell’ HTTP Header nel formato “variabile=valore” quali l’identificativo utente, cognome, nome, codice fiscale, mail, etc..

2.2 Servizi messi a disposizione dalla Direzione

La Direzione Sistemi Informativi e Agenda Digitale mette a disposizione delle varie piattaforme applicative una serie di strumenti per assolvere alle seguenti funzionalità:

• Servizio di Autenticazione del Cittadino : integrazione nel contesto del Comune della identità federata in SSO con gli Identy Provider SPID e CIE tramite la piattaforma CIAM.

• Servizio di Autenticazione credenziali gestite da CIAM (include al momento le credenziali azienda)

• Servizio di Reverse Proxy : componente di CIAM per rendere completamente demandato da parte della applicazione il servizio di autenticazione.

La Direzione Sistemi Informativi fornirà supporto e documentazione al fornitore per l’integrazione della applicazione ai servizi centralizzati CIAM, nonché le verifiche in ambiente di collaudo.

2.3 Requisiti relativi al codice identificativo dell’utente

• L’applicazione deve verificare che l'identificativo utente sia un codice univoco nell’ambito dell’applicazione;

• Un identificativo utente deve essere assegnato in maniera univoca ad una sola persona fisica e le utenze di gruppo non devono essere ammesse. Ogni utente è responsabile delle azioni compiute con l’utenza ad esso assegnata sul sistema; per questo motivo le credenziali non devono essere condivise con nessuno;

• L’applicazione, ed il sistema che la ospita, dovrebbero impedire l’impiego di utenze amministrative per l’esecuzione di procedure automatizzate;

2.4 Requisiti relativi al controllo degli accessi al sistema

• L’accesso all’applicazione deve avvenire previa autenticazione effettuata mediante l’utilizzo di credenziali d’accesso costituite almeno da username e password.

• Deve essere utilizzato un sistema SSO per assolvere al processo di autenticazione.

• Il processo di autenticazione e autorizzazione deve essere effettuato con successo prima che l’utente possa interagire con le funzionalità che implementano l’accesso o la manipolazione dei dati a prescindere dalla tipologia di appartenenza.

• Ogni volta che vengono effettuate operazioni di modifica e cancellazione sui dati tutelati dalla normativa vigente in materia di sicurezza informatica e privacy, l’applicazione deve verificare le credenziali d’accesso per confermare l’identità dell’utente.

2.5 Requisiti relativi alla protezione delle credenziali d’accesso

• L’applicazione non deve per nessuna ragione conservare in chiaro le credenziali di autenticazione. È vietato inoltre trasmettere in chiaro sulla rete le credenziali d’accesso.

• Il processo di autenticazione sia per le utenze personali che del tipo machine to machine, a prescindere dal protocollo utilizzato, deve essere protetta mediante cifratura del canale di comunicazione. La cifratura del canale di comunicazione ai servizi di autenticazione si basa su HTTPS protocollo TLS 1.2 o superiore.

(6)

• La firma per le asserzioni deve basarsi su crittografica asimmetrica. L’algoritmo utilizzato per firmare le asserzioni è RSA-SHA256. Il SP/RP deve utilizzare il medesimo algoritmo in ricezione.

2.6 Requisiti relativi ai profili autorizzativi

• L’applicazione deve associare un profilo di autorizzazione per ciascuna utenza applicativa. Il profilo deve essere attribuito in fase di creazione dell’utenza.

• È possibile e preferenziale la gestione centralizzata dei profili applicativi mediante mappatura su gruppi gestiti da CIAM mappati con ruoli nel contesto applicativo.

• I profili autorizzativi impiegati dall’applicazione devono essere definiti in modo circoscritto, basato sui dati cui possono accedere, secondo il principio del "least privilege": deve essere consentito l’accesso solo ed esclusivamente all’insieme di dati strettamente necessari a svolgere le funzioni cui si è abilitati nel proprio ambito di competenza e coerentemente con le finalità per cui il profilo è stato previsto.

• L’assegnazione di un profilo autorizzativo ad un utente deve essere effettuata seguendo i principi del

“least privilege” e “need to know”¹.

• L’applicazione deve consentire la ricerca e la produzione di report contenenti le utenze utilizzate ed i relativi profili ad esse associate.

• L’applicazione deve consentire la modifica dei profili utente, in termini di privilegi e accesso al dato, e delle relative associazioni. Deve inoltre tenere traccia di tali modifiche, di quando sono state effettuate e da chi.

2.7 Doveri dell’appaltatore

• L’applicazione non deve essere rilasciata da chi la sviluppa, con account utente standard di tipo amministrativo/operativo o con account protetti tramite password di default.

• L’applicazione sviluppata non deve impiegare meccanismi di autenticazione con chiave condivisa (altrimenti detti pre-shared secret).

• L’applicazione deve implementare un meccanismo di access control adeguato. Tutte le operazioni svolte dagli utenti e le fasi di autorizzazione e assegnazione dei permessi devono essere subordinate alla policy standard : “Ogni azione è negata se non espressamente consentita”.

• L’applicazione non deve assegnare alcun privilegio/permesso all’utente fin quando il processo di autenticazione e autorizzazione non è stato completato.

• Nelle applicazioni web i cookie di sessione applicativa devono essere cifrati, non persistent, avere il flag secure attivato e l’attributo HttpOnly impostato.

• Un cookie non deve contenere informazioni critiche quali password o essere composto da parti predicibili come username o valori elaborati basandosi su algoritmi sequenziali. L’identificatore della sessione nel cookie deve avere un’entropia pari almeno a 128 bit.

• Nelle applicazioni web, ciascun cookie generato deve essere soggetto a un tempo di scadenza oltre il quale non deve più essere considerato valido.

• Quando un utente ha effettuato il log-out, la sessione relativa deve essere invalidata sia sul server (sganciandola nella Entry Table delle sessioni attive) che sul client (ad esempio rimuovendo il cookie o svuotando il suo contenuto).

• L’applicazione deve prevedere il rilascio della sessione utente dopo un certo periodo configurabile di inattività della sessione stessa.

• È vietata l’implementazione della sicurezza attraverso l’oscuramento delle funzioni a livello di presentazione. È obbligatorio invece isolare e rendere inutilizzabili le funzioni che non devono essere

1 Il principio del “need to know” stabilisce che, anche se si ha i diritti per accedere ad una informazione, vi si possa accedere solo se questo è necessario per portare a termine il proprio lavoro. È una misura atta ad evitare abusi di attività di consultazione di dati.

(7)

rese accessibili agli utenti, direttamente a livello logico (es: imponendo la consultazione del token della sessione per determinarne i reali privilegi di esecuzione).

• Tutte le sessioni riconducibili all’applicazione, svolte dalle utenze operative/amministrative, devono essere, oltre che supportate da meccanismi di tracciamento idonei, anche cifrate con algoritmi crittografici. In questo modo si garantisce il non ripudio delle singole sessioni. Deve cioè essere possibile determinare con esattezza se un evento si è verificato o meno.

• È dovere dell’appaltatore modificare periodicamente le password delle eventuali utenze di servizio utilizzate in caso che il contratto preveda l’esercizio dei sistemi.

3 Vulnerabilità nei meccanismi di autenticazione e autorizzazione

Nei paragrafi seguenti sono riportati alcuni esempi di pratiche insicure e le carenze relative ai meccanismi di autenticazione e autorizzazione. Ulteriori esempi sono pubblicati nella linea guida per lo sviluppo sicuro dell’

Agid.

3.1 Meccanismi di sicurezza delegati al Client

Nelle architetture software ispirate al paradigma client–server, i meccanismi di sicurezza possono essere realizzati sul client, sul server o su entrambe le tipologie di sistemi. Poiché i client sono generalmente sotto il controllo esterno, realizzare meccanismi di sicurezza esclusivamente sui client, senza effettuare le dovute verifiche lato server, offre di fatto la possibilità ad un attaccante di superare i meccanismi stessi. Tale pratica di programmazione è dunque vietata al fine di garantire la sicurezza dei sistemi e delle informazioni.

ESEMPIO DI PRATICA INSICURA

Si consideri un’applicazione WEB che utilizza i cookie HTTP per trasferire le informazioni relative allo stato delle variabili interne dell’applicazione. Di seguito viene riportato l’estratto di una risposta HTTP generata da un ipotetico sito di prenotazione sanitaria online, in cui il server invia al client tre cookie:

HTTP/1.1 302 Found Location: /prenota.php

Set–Cookie: IdSessione=18112013–1100 Set–Cookie: Username=mario

Set–Cookie: PrezzoTicket=100

All’interno della risposta sono impostati tre cookie con le seguenti informazioni

• IdSessione: il codice identificativo della sessione corrente;

• Username: il nome dell’utente che ha in carico l’idSessione;

• PrezzoTicket: il prezzo del ticket per la prestazione sanitaria da prenotare.

I cookie, ed in generale il traffico inviato dal browser web al server, può essere manipolato da un attaccante utilizzando ad esempio un web proxy o altri sistemi di modifica del traffico in line. Pertanto, se il server non effettua una validazione dei dati ricevuti dal client e un agente di minaccia modifica il contenuto dei cookie, il prezzo della prenotazione stabilito dall’applicazione potrà essere modificato arbitrariamente. Di seguito è riportato un esempio di richiesta ipotetica per portare a termine l’attacco.

(8)

Direzione Innovazione Tecnologica e Digitale- Comune di Milano – Documento rilasciato con licenza CC BY 4.0 8 / 10 POST /pagaticket.php HTTP/1.1

Host: cookietest.com

Cookie: IdSessione=18112013–1100; Username=mario; PrezzoTicket=1 Content–Length: 23

conferma=1

Questa vulnerabilità si manifesta generalmente in tutte le componenti client-side utilizzate senza controlli applicativi server-side. Atri casi, nel campo delle applicazioni web, in cui la mancanza di meccanismi di sicurezza server-side può essere sfruttata da un agente di minaccia al fine di manipolare il traffico ed effettuare operazioni malevole, sono di seguito riportate:

• Dati inviati tramite i campi delle hidden form (POST);

• Dati inviati tramite parametri nella URL (GET);

• L’utilizzo dell’header HTTP Referer quale unico metodo per verificare che la pagina da cui proviene l’utente sia quella attesa dall’applicazione;

• Manipolazione di eventuali dati offuscati, ad esempio il campo ViewState utilizzato dalle applicazioni web .NET, nei casi in cui questo non sia protetto adeguatamente con l’ausilio della crittografia;

• Elusione di meccanismi di sicurezza esclusivamente lato client, generalmente realizzati con codice Javascript.

Si fa presente che anche altre soluzioni client-side, realizzate in Java, Flash, ActiveX o C#, sono comunque soggette ad attacchi di questa natura. In questi casi il browser scarica ed esegue localmente codice che, con tecniche e livelli di difficoltà diversi, può essere comunque manipolato.

CONTROMISURE

La validazione di tutti i dati ed i meccanismi di autenticazione e autorizzazione DEVONO essere sempre implementati server-side.

Occorre validare sempre le informazioni trasmesse dal client in quanto, per loro natura, sono considerate non fidate. I meccanismi di validazione lato client possono essere utilizzati al fine di migliorare l’usabilità e la user experience, consentendo tempi di risposta rapidi senza necessità di comunicazione verso il server;

poiché i dati sono manipolabili è obbligatorio però validare i dati anche lato server. L’unica modalità sicura di validazione dell’input ricevuto dai client è sui server, di cui si ha il completo controllo.

Occorre inoltre delegare il meccanismo di autenticazione e autorizzazione a componenti server side; per nessuna ragione l’accesso ad aree riservate, ad informazioni sensibili o ad operazioni dispositive deve essere consentito sulla base esclusiva di controlli client-side.

3.2 Autenticazione non sicura

Il processo di autenticazione è fondamentale nella gestione della sicurezza applicativa poiché è quello che consente all’applicazione di riconoscere un utente legittimo del sistema. Il processo di autenticazione costituisce, insieme al processo di autorizzazione, la prima linea di difesa delle applicazioni contro l’utilizzo non lecito delle risorse disponibili, e di fatto costituisce frequentemente l’anello debole tramite il quale un agente di minaccia può riuscire a guadagnare un accesso altrimenti non consentito.

L’autenticazione può essere realizzata utilizzando diverse soluzioni, tra cui ad esempio:

• Credenziali d’accesso costituite dalla coppia nome utente e password;

• Certificati SSL e/o Smart card;

• Codici identificativi e token fisici.

Saranno discusse nel seguito alcune debolezze tipiche della soluzione di autenticazione più diffusa, basata sulla conoscenza di nome utente e password. Si noti che tali debolezze hanno degli impatti, nel caso in cui i

(9)

sistemi trattino dati personali e/o sensibili anche con la normativa di riferimento in materia di sicurezza informatica e privacy:

• Password deboli: molte applicazioni non effettuano alcun controllo sulla robustezza delle password, consentendo l’utilizzo di password molto brevi, vuote, uguali a nomi o termini presenti in dizionari, uguali al nome utente o configurate a valori di default noti;

• Funzionalità di rinnovo password accessibile senza autenticazione: l’applicazione offre una funzionalità di rinnovo della password accessibile senza autenticazione. Questa criticità consente ad un agente di minaccia di tentare di ricavare credenziali d’accesso valide;

• Procedura di login soggetta ad attacchi di tipo brute force: l’applicazione consente un numero illimitato di tentativi di autenticazione, che un agente di minaccia può sfruttare al fine di ricavare delle credenziali d’accesso valide;

• Procedura di login soggette a Denial Of Service: l’applicazione procede al blocco degli account dopo un determinato numero di tentativi di login errati. Un agente di minaccia può quindi effettuare un numero sufficiente di login su un ampio numero di account, impedendo ai legittimi proprietari l’accesso ai servizi;

• Meccanismi di protezione non omogenei: le contromisure non sono implementate in modo uniforme; ad esempio, le misure atte a contrastare gli attacchi di tipo brute force sono implementate correttamente nella pagina di login principale, ma non sono presenti nella pagina di recupero o di rinnovo password.

3.3 Autorizzazione non sicura

L’autorizzazione è il processo tramite il quale l’applicazione determina se un utente, autenticato o meno, può accedere ad una determinata risorsa. È pertanto un meccanismo di sicurezza fondamentale per gestire gli accessi alle risorse. Un meccanismo di autorizzazione non sicuro può permettere ad un agente di minaccia di compromettere l’intera applicazione tramite il controllo di funzionalità con capacità amministrazione, e di accedere a dati appartenenti ad altri utenti.

ESEMPI DI PRATICA INSICURA

Di seguito sono riportati alcuni esempi di processi di autorizzazione non sicuri.

• Funzionalità non protette: appartengono a questa categoria le funzionalità, anche con privilegi di amministrazione, che sono “protette” unicamente dalla posizione “segreta” dell’URL che ne consente l’accesso. Si consideri ad esempio la seguente URL di accesso a funzionalità di

amministrazione dell’applicazione:

https://www.comune.milano.it/secure/f8a0usfaoa/AdminMenu.jsp;

• File statici: in alcuni casi, la richiesta di risorse protette è effettuata mediante l’accesso diretto alle risorse stesse, senza che l’applicazione effettui i dovuti controlli di autorizzazione; pertanto, una volta dedotta la logica con cui sono assegnate le URL, sarà possibile effettuare l’accesso diretto alle risorse.

Si ipotizzi, ad esempio, un sistema che consenta il download di un file utente mediante la URL:

https://www.comune.milano.it/download/20131010-PRNFNC54H26C532R.pdf. Il nome del file contiene due informazioni apparentemente predicibili, la data in cui è stato generato il file ed il codice fiscale dell’utente; notata e verificata questa condizione, sarà possibile scaricare i file di altri utenti senza disporre di alcuna autorizzazione;

• Autorizzazione basata su client: alcune applicazioni basano l’autorizzazione unicamente sulle informazioni ricevute dai client. All’utente viene associato un profilo al momento dell’autenticazione, comunicato al client, e successivamente questo invia al server il proprio profilo tramite cookie, parametri nella URL, o hidden form. Ad esempio, un amministratore può essere ridirezionato verso

(10)

una URL del genere: https://www.comune.milano.it/login/home.jsp?admin=true mentre gli utenti senza privilegi non contengono il parametro ^admin=true nella URL, o ne contengono uno diverso. In tal caso, un utente che desideri acquisire privilegi di amministratore potrà semplicemente modificare la propria URL e renderla uguale a quella degli amministratori.

CONTROMISURE

Occorre valutare esplicitamente e documentare i requisiti di autorizzazione per ogni funzionalità dell’applicazione, evidenziando gli utenti che possono utilizzare la funzionalità e a quali risorse questi possano accedere. In fase di progettazione bisogna cercare di semplificare lo schema autorizzativo al fine di prevenire criticità dovute all’implementazione della logica del meccanismo di autorizzazione.

Occorre centralizzare le scelte relative al processo di autorizzazione e alle politiche che lo regolamentano all’interno di un singolo componente dell’applicazione. Bisogna fare in modo che ciascuna richiesta destinata alle funzionalità dell’applicativo sia vagliata e validata per mezzo di questo componente. È’ fondamentale verificare che non vi siano eccezioni, poiché una sola di esse potrebbe compromettere la sicurezza dell’applicazione.

Occorre validare sempre le informazioni relative all’autorizzazione ricevute dai client con le informazioni presenti lato server.

Occorre evitare l’accesso diretto a risorse statiche: le risorse statiche devono essere offerte tramite pagine dinamiche che implementano i dovuti controlli di autorizzazione.

Occorre valutare la possibilità di inserire vincoli ulteriori, come restringere l’accesso sulla base dell’indirizzo IP o una fase di autenticazione/autorizzazione aggiuntiva.

Occorre registrare su file di log gli eventi “sensibili” quali l’accesso a informazioni o funzionalità riservate.

4 Riferimenti e linee di indirizzo normativo

Misure minime per la sicurezza ICT per le pubbliche amministrazioni - CIRCOLARE 18 aprile 2017, n. 2/2017 AgID - Linee guida per lo sviluppo del software sicuro, 6 maggio 2020

AgID - Linee Guida Tecnologie e standard per la sicurezza dell’interoperabilità tramite API dei sistemi informatici, 21 maggio 2021

Raccomandazioni AgID in merito allo standard Transport Layer Security (TLS), 3 novembre 2020 Regolamento AgID recante le regole tecniche dello SPID

Linee Guida OpenID Connect in SPID, 24 novembre 2021

CIE Manuale Tecnico per gli erogatori di servizi pubblici e privati 21 giugno 2021