Linee Guida tecnologie e standard per la sicurezza dell’interoperabilità tramite API dei sistemi informatici

Tecnologie e standard per la sicurezza dell’interoperabilità tramite API dei sistemi informatici

Le Linee guida AgID definiscono le tecnologie e gli standard di sicurezza da impiegare nello scambio di dati e servizi digitali tra sistemi informatici delle pubbliche amministrazioni e tra queste e soggetti privati, quando l’interoperabilità avviene tramite API. Il documento si inserisce nel Modello di Interoperabilità delle PA (ModI) e individua obblighi e raccomandazioni per garantire autenticazione, integrità, riservatezza e riconoscimento reciproco dei soggetti coinvolti.

Ambito di applicazione e destinatari

Le Linee guida sono adottate ai sensi dell’art. 71 CAD e si fondano sulla disciplina del ModI richiamata dall’art. 73, comma 3-ter, lett. b), e dall’art. 51 CAD. L’ambito è quello delle interazioni tra sistemi informatici della PA e, più in generale, tra soggetti pubblici e privati che si scambiano dati o integrano processi tramite API.

I destinatari sono:

• i soggetti di cui all’art. 2, comma 2, CAD, chiamati ad attuare le Linee guida nei propri sistemi informatici che fruiscono o erogano dati e/o servizi digitali tramite API;
• i soggetti privati che devono interoperare con la PA tramite API per fruire di dati e servizi digitali.

Il documento distingue i ruoli di:

• erogatore, che mette a disposizione e-service;
• fruitore, che utilizza i servizi esposti;
• dominio di interoperabilità, inteso come il contesto in cui più soggetti scambiano dati o integrano processi tramite API, eventualmente regolato da accordi conformi al ModI.

Struttura e natura degli allegati

Le Linee guida contengono una parte stabile e allegati tecnici aggiornabili. Gli allegati richiamati riguardano in particolare:

• lo standard Transport Layer Security (TLS);
• gli algoritmi per XML Canonicalization, Digest and signature public key SOAP e Digest and signature public key REST.

La struttura a strati consente l’aggiornamento degli aspetti più sensibili all’evoluzione tecnologica, nel quadro delle funzioni di indirizzo, vigilanza e controllo di AgID in materia di digitalizzazione, sicurezza informatica e interoperabilità.

Sicurezza a livello di trasporto

Per la sicurezza del canale di comunicazione le interazioni devono avvenire tramite HTTPS (HTTP over TLS). La prescrizione è finalizzata a garantire:

• autenticazione;
• integrità dei dati;
• confidenzialità.

I soggetti destinatari devono utilizzare la versione TLS e le cipher suite indicate nell’allegato dedicato. Le indicazioni tecniche possono essere aggiornate periodicamente e, in presenza di vulnerabilità di nuova scoperta, possono essere emanati avvisi di sicurezza specifici.

Sicurezza a livello applicativo: tecnologie e standard

Il livello applicativo comprende gli standard e le best practice usati per la comunicazione human-to-machine e machine-to-machine. Il ModI individua due tecnologie di riferimento:

• REST;
• SOAP.

Per assicurare la sicurezza delle transazioni tramite API, i soggetti destinatari devono utilizzare gli standard indicati nel documento.

REST

Nell’ambito REST il documento richiama, per la sicurezza dei messaggi:

• JSON;
• JWS;
• JWK;
• JWE;
• JWT;
• JWA;
• OAuth 2.0.

JSON è richiamato come formato di interscambio; le Linee guida segnalano, in chiave prudenziale, l’opportunità di limitare l’espressività della notazione in alcuni contesti e richiamano raccomandazioni su sottoinsiemi interoperabili e valori strutturati per HTTP.

JWS, JWK, JWE, JWT e JWA sono richiamati come specifiche JSON-based per la firma, la gestione delle chiavi, la cifratura e la protezione dei messaggi. In particolare:

• JWS garantisce l’integrità del contenuto firmato;
• JWK descrive chiavi crittografiche associate agli algoritmi JSON Web;
• JWE disciplina il contenuto cifrato;
• JWT veicola asserzioni e può essere firmato e/o cifrato;
• JWA individua gli algoritmi da utilizzare con JWS e JWE.

Per i JWT è imposto il rispetto delle indicazioni di sicurezza dell’RFC 8725.

Per OAuth 2.0 il documento chiarisce i ruoli di resource owner, client, authorization server e resource server. Nel contesto machine-to-machine risultano applicabili il Resource Owner Password Credentials Grant e il Client Credentials Grant, ma il primo non deve essere usato perché implica la cessione a terzi delle credenziali.

SOAP

Per SOAP il documento richiama:

• XML;
• XML-canonicalization;
• XML-signature;
• XML-encryption;
• WS-Security.

XML è indicato come linguaggio di markup per la codifica dei documenti; XML-canonicalization serve a ottenere una forma canonica del documento, fondamentale per la verifica e la produzione delle firme; XML-signature disciplina la rappresentazione della firma digitale su documenti XML; XML-encryption definisce la cifratura e la rappresentazione dei dati cifrati; WS-Security descrive i meccanismi per proteggere i messaggi SOAP mediante integrità, riservatezza e autenticazione a livello di messaggio.

WS-Security richiama, in particolare, la possibilità di utilizzare token di sicurezza quali:

• certificati X.509;
• asserzioni SAML.

Certificati digitali e costruzione del trust

Le tecnologie indicate si fondano sulla crittografia asimmetrica e sullo standard ITU-T X.509. La sicurezza dell’interoperabilità richiede la costituzione di un trust tra erogatore e fruitore, cioè il riconoscimento reciproco della validità dei certificati digitali usati per le comunicazioni via API.

Le linee guida richiamano, per l’uso dei certificati, le regole tecniche AgID sui certificati elettronici qualificati, firme e sigilli elettronici qualificati e validazioni temporali, nonché le raccomandazioni sui certificati qualificati di sigillo elettronico e di autenticazione di siti web.

Tipologie di certificati utilizzabili

La tipologia di certificato da usare dipende dal livello di sicurezza:

• per la sicurezza di canale si utilizzano Website Authentication Certificates o certificati TLS, idonei ad autenticare server e client e a cifrare le comunicazioni;
• per la sicurezza a livello applicativo si utilizzano Electronic Seal Certificates, che identificano il soggetto giuridico e supportano la verifica di origine, correttezza e integrità dei messaggi.

Popolamento degli OID per le pubbliche amministrazioni

Per consentire la verifica automatizzata della persona giuridica associata al certificato X.509, le PA devono curare il popolamento di specifici OID:

• OID 2.5.4.97 organizationIdentifier: deve essere valorizzato con il codice fiscale della persona giuridica nella forma CF:IT-<codice_fiscale>; in alternativa, per le sole PA, con il codice IPA nella forma PA:IT-<codice IPA dell’ente>;
• OID 2.5.4.11 organizationalUnitName: se il certificato è riferito a una unità organizzativa o a una area organizzativa omogenea, deve contenere rispettivamente IPAIT - UO_<Codice_uni_uo> oppure IPAIT - AOO_<Codice_uni_aoo>.

La verifica dell’associazione del certificato a una PA si effettua consultando l’IPA e controllando la corrispondenza tra i dati del certificato e le informazioni presenti nell’elenco, secondo i passaggi descritti dalle Linee guida.

Modalità di emissione dei certificati digitali

Le Linee guida contemplano due modelli alternativi:

1. certificati emessi da CAQ eIDAS;
2. certificati emessi all’interno di domini di interoperabilità specifici.

Nel primo caso, gli erogatori devono accettare i certificati qualificati emessi da una CAQ eIDAS per autenticare i fruitori e devono verificarne la validità, compresa l’eventuale revoca. La frequenza di validazione è definita dalle parti, nel rispetto della normativa vigente e tenendo conto degli impatti di sicurezza e prestazionali.

Nel secondo caso, all’interno di un dominio di interoperabilità, i soggetti possono individuare uno o più soggetti abilitati all’emissione di certificati digitali, ossia una CA del dominio. Le regole del dominio devono disciplinare:

• il processo di emissione;
• la revoca;
• la distribuzione dei certificati;
• le modalità di richiesta del certificato da parte del soggetto richiedente;
• le verifiche di identificazione svolte dalla CA.

Gli erogatori devono accettare i certificati emessi dalla CA del dominio e verificarne la validità, compresa la revoca.

Per la revoca, le Linee guida raccomandano l’uso di:

• OCSP;
• CRL.

Principi per la scelta della modalità di emissione

La scelta tra certificati CAQ eIDAS e certificati emessi nel dominio di interoperabilità è rimessa ai soggetti del dominio, ma deve rispettare i principi indicati dalle Linee guida. In particolare, deve essere considerata l’economicità, efficacia ed efficienza della soluzione, comparando i costi di emissione tramite CAQ con i costi di gestione dell’infrastruttura interna del dominio.

Inoltre, quando i dati scambiati tramite API producono effetti verso soggetti esterni al dominio di interoperabilità, oppure in presenza di interoperabilità transfrontaliera con altri Stati membri, deve essere utilizzata la modalità basata su CAQ eIDAS, per garantire l’accettazione dei certificati digitali emessi.

Quadro degli obblighi principali

In termini operativi, il documento impone o richiede in particolare che:

• le comunicazioni API avvengano tramite HTTPS/TLS;
• siano usate le versioni TLS e le cipher suite indicate da AgID;
• siano adottati gli standard previsti per REST e SOAP;
• i JWT rispettino le indicazioni di sicurezza dell’RFC 8725;
• il grant type Resource Owner Password Credentials non sia utilizzato;
• i certificati delle PA rechino i corretti OID e siano verificabili tramite IPA;
• gli erogatori accettino e verifichino i certificati qualificati CAQ eIDAS;
• gli erogatori accettino e verifichino anche i certificati eventualmente emessi dalla CA del dominio di interoperabilità;
• la revoca sia gestita tramite strumenti adeguati, preferibilmente OCSP o CRL;
• in caso di impatto su soggetti esterni o di interoperabilità transfrontaliera si ricorra ai certificati CAQ eIDAS.

Le Linee guida costituiscono quindi una cornice vincolante per l’implementazione sicura delle API nella PA, integrando le scelte tecnologiche con requisiti giuridici, organizzativi e di fiducia reciproca tra i soggetti interoperanti.