Risultati
51 risultati
-
AGID
3. Indicazioni per AGID
Presidiare la tematica della sicurezza significa anche verificare che siano costantemente disponibili, per le amministrazioni, adeguati (e sicuri) strumenti di acquisizione di prodotti e servizi ICT. A tale scopo, AGID propone di tener conto anche di questo obiettivo nel pianificare, di concerto con la Consip, la tempistica delle gare che interessano sistemi e progetti critici sotto l’aspetto della sicurezza, evitando ad esempio situazioni in cui convenzioni e/o accordi quadro siano esauriti e i successivi non siano ancora disponibili perché le relative gare sono ancora da aggiudicare ...
-
AGID
1. Premessa
DR-1. ISO 22317 - Linee guida per Business Impact Analysis. https://www.iso.org/standard/50054.html. DR-2. ISO 27001 - Sistema di Gestione della Sicurezza delle Informazioni. https://www.iso.org/isoiec-27001-information-security.html. DR-3. ISO 31000 Risk Management. https://www.iso.org/iso-31000-risk-management.html. DR-4. Linee guida sviluppo software sicuro. https://www.agid.gov.it/it/sicurezza/cert-pa/linee-guida-sviluppo-del-software-sicuro. DR-5. Misure minime di sicurezza AGID. https://www.agid.gov.it/it/sicurezza/misure-minime-sicurezza-ict. DR-6. ISO 15408 Standard Common Criteria. https://www.iso.org/standard/50341.html ...
-
AGID
Linee guida sicurezza nel procurement ICT
La consultazione pubblica relativa al presente documento è attiva dal 14 maggio al 13 giugno 2019. Questo documento raccoglie il testo delle Linee guida sicurezza nel procurement ICT, disponibile per la consultazione pubblica ...
-
AGID
5. Appendice A – Requisiti di sicurezza eleggibili
Nelle tabelle che seguono sono elencati alcuni requisiti di sicurezza che le amministrazioni possono inserire nei propri capitolati di gara. L’elenco non è esaustivo, ha solo lo scopo di offrire alcuni esempi significativi e di favorire un lessico comune nell’esprimere requisiti di sicurezza. Per ragioni di sintesi, il testo di alcuni requisiti (ad esempio di R1) è stato generalizzato in modo da renderlo un modello per una “famiglia di requisiti”, da declinare ed eventualmente suddividere in più requisiti elementari, a seconda del contesto della singola acquisizione. R1. Il fornitore deve adottare al proprio interno le procedure e politiche di sicurezza definite dall’amministrazione committente, con particolare riferimento alle modalità di accesso ai sistemi dell’amministrazione, all’hardening (esempio installazione di soluzioni di end point security) dei dispositivi utilizzati dal fornitore, alla gestione dei dati dell’amministrazione. R2. Il fornitore deve possedere la certificazione ISO/IEC 27001 e mantenerla per tutta la durata della fornitura. R3. (alternativo al precedente) Anche se il fornitore non è certificato ISO/IEC 27001, almeno deve usare un Sistema di Gestione della Sicurezza delle Informazioni (SGSI) aggiornato nel tempo. R4. Il fornitore deve far eseguire annualmente un audit sul proprio sistema di sicurezza, a proprie spese e da una società specializzata scelta previa approvazione della stazione appaltante. NB: Qualora applicabile, tale attività si incrocia con il requisito R2 (le verifiche dell’Ente Certificatore hanno cadenza pressoché annuale). R5. L’amministrazione può, con un preavviso di 20 giorni solari, richiedere ulteriori attività di auditing secondo modalità concordate con il fornitore. Le risultanze di tali audit verranno comunicate all’amministrazione. R6. L’amministrazione, direttamente o tramite terzi incaricati, può eseguire verifiche relative alla conformità della prestazione dei servizi rispetto a quanto stabilito nel capitolato tecnico oltre che nell’offerta tecnica se migliorativa. R7. Il personale del fornitore che presta supporto operativo nell’ambito dei servizi di sicurezza dovrà possedere certificazione su specifici aspetti della sicurezza. R8. Il fornitore deve disporre di una struttura per la prevenzione e gestione degli incidenti informatici con il compito d’interfacciarsi con le analoghe strutture dell’amministrazione e con le strutture centrali a livello governativo. R9. Il fornitore deve dotarsi delle misure minime di sicurezza per limitare il rischio di attacchi informatici (riferimento DR-5). R10. Il SOC del fornitore deve sovrintendere alla gestione operativa e continuativa degli incidenti informatici sui servizi erogati nell’ambito della fornitura. R11. Il fornitore deve garantire il rispetto di quanto richiesto dalla normativa vigente in materia di sicurezza cibernetica, anche in riferimento ai contenuti del GDPR. R12. Sulle reti messe a disposizione dal fornitore devono essere presenti di dispositivi di sicurezza perimetrale con funzioni di sicurezza (ad esempio Firewall e sistemi di Network Detection ed Event & Log Monitoring, SIEM, ecc.) necessari a rilevare e contenere eventuali incidenti di sicurezza ICT e in grado di gestire gli IoC (Indicator of Compromise). R13. Il fornitore deve usare protocolli cifrati e meccanismi di autenticazione nell’ambito dei servizi erogati. R14. Qualora il fornitore subisca un attacco, in conseguenza del quale vengano compromessi sistemi del committente da lui gestiti, deve farsi carico delle bonifiche del caso, e riportare i sistemi in uno stato di assenza di vulnerabilità. R15. Il fornitore si impegna a trattare, trasferire e conservare le eventuali repliche dei dati oggetto di fornitura, ove autorizzate dalle amministrazioni, sempre all’interno del territorio dell’UE. R16. Il fornitore deve dare disponibilità a far parte di un Comitato di Direzione Tecnica, eventualmente aperto anche a soggetti terzi, che tratti il tema della sicurezza, sia nell’ottica di favorire la risoluzione di temi aperti sia per introdurre eventuali varianti al contratto per fronteggiare nuove minacce o altro. R17. Il fornitore deve condividere le informazioni necessarie al fine di garantire il corretto monitoraggio della qualità e della sicurezza, eventualmente pubblicando le stesse nel portale della fornitura. R18. Il fornitore si impegna a sottoscrivere una clausola di non divulgazione (NDA) sui dati e sulle informazioni dell’amministrazione. R19. Le soluzioni e i servizi di sicurezza proposti dal fornitore devono essere aggiornati dal punto di vista tecnologico, con riferimento all’evoluzione degli standard e del mercato; devono essere conformi alle normative e agli standard di riferimento applicabili; devono venire adeguati nel corso del contratto, senza oneri aggiuntivi, alle normative che l’UE o l’Italia rilasceranno in merito a servizi analoghi. R20. Il fornitore deve attenersi alla politica di sicurezza dell’amministrazione committente, con particolare riferimento all’accesso ai dati dell’amministrazione, che avverrà esclusivamente sui sistemi di sviluppo e test. R21. In fase di analisi, il fornitore deve definire le specifiche di sicurezza (non funzionali) a partire dai requisiti espressi dall’amministrazione. R22. In fase di progettazione codifica, il fornitore deve implementare le specifiche di sicurezza nel codice e nella struttura della basedati. R23. Al termine del progetto, il fornitore deve rilasciare tutta la documentazione necessaria all’amministrazione per gestire correttamente quanto rilasciato anche sotto l’aspetto della sicurezza. R24. Supporto di protocolli sicuri e cifrati (HTTPS, SSH v2, ecc.). R25. Filtraggio di indirizzi IP. R26. Supporto di protocolli di autenticazione (ad esempio RADIUS, IEEE 802.1X, ecc.). R27. Gestione di più profili con privilegi diversi. R28. Funzionalità di “richiesta creazione o cambio della password al primo accesso”. R29. Blocco dell’utenza dopo un numero definito (fisso o variabile) di tentativi falliti di accesso. R30. Gli accessi degli utenti devono essere registrati su un archivio (log) non cancellabile con il reset. R31. Gestione dei log di sistema (accessi, allarmi, ecc.). R32. Il fornitore (anche in collaborazione con il produttore della tecnologia) deve offrire processi, unità organizzative e strumenti dedicati alla gestione di vulnerabilità scoperte sui prodotti oggetto della fornitura. R33. Per gli apparati proposti deve essere disponibile documentazione tecnica (schede tecniche, manuali, guide operative) relativa alla corretta configurazione e gestione degli aspetti di sicurezza. R34. I meccanismi di autenticazione devono essere basati su meccanismi di crittografia asimmetrica, a chiave pubblica; la lunghezza delle chiavi va impostata sulla base della criticità della comunicazione da cifrare (ad esempio 256 bit per le meno critiche, 512 bit per le più critiche). La gestione e distribuzione delle chiavi e dei certificati è a carico del fornitore. R35. Autorizzazione: sulla base delle credenziali fornite dall’utente, si devono individuare i diritti e le autorizzazioni che l’utente possiede e permetterne l’accesso alle risorse limitatamente a tali autorizzazioni. R36. Confidenzialità nella trasmissione dei dati: le comunicazioni tra la componente di gestione remota centralizzata e la componente locale installata presso la sede dell’amministrazione devono essere cifrate. R37. Fornire meccanismi che permettano di garantire l’integrità di quanto trasmesso (ad esempio meccanismi di hashing). R38. Il fornitore deve descrivere nel dettaglio le soluzioni tecniche utilizzate (dispositivi hardware e software impiegato, modalità operative, politiche di sicurezza, …) per soddisfare i requisiti di sicurezza dell’amministrazione committente. R39. In fase di attivazione del servizio, il fornitore deve concordare con l’amministrazione le modalità operative e le politiche di sicurezza, i livelli di gravità degli incidenti, le attività e le contromisure che dovranno essere svolte per contrastare le minacce. R40. Il fornitore dovrà attenersi alle politiche di sicurezza definite dalla committente, con particolare riferimento alla definizione di ruoli e utenze per l’accesso ai sistemi gestiti. R41. In caso di necessità, da parte degli operatori, di accesso a Internet, il fornitore deve utilizzare un proxy centralizzato e dotato di configurazione coerente con la politica di sicurezza definita dall’amministrazione. R42. In caso di rilevazione di un incidente di gravità elevata (con scala da definire a inizio fornitura), il fornitore deve dare immediata notifica, tramite canali concordati con l’amministrazione, dell’incidente rilevato e delle azioni da intraprendere, al Responsabile della Sicurezza indicato dall’amministrazione e al CERT-PA. R43. Per ogni incidente di sicurezza, il fornitore s’impegna a consegnare all’amministrazione, entro il giorno successivo, un report che descriva la tipologia di attacco subito, le vulnerabilità sfruttate, la sequenza temporale degli eventi e le contromisure adottate. R44. Su richiesta dell’amministrazione, il fornitore deve consegnare i log di sistema generati dai dispositivi di sicurezza utilizzati, almeno in formato CSV o TXT. Tali log dovranno essere inviati all’amministrazione entro il giorno successivo a quello in cui è avvenuta la richiesta. R45. Il fornitore deve monitorare la pubblicazione di upgrade/patch/hotfix necessari a risolvere eventuali vulnerabilità presenti nei dispositivi utilizzati per erogare i servizi e nelle infrastrutture gestite. Entro il giorno successivo al rilascio dell’upgrade/patch/hotfix, il fornitore deve avviare una valutazione, da rilasciarsi entro un numero giorni da stabilirsi, propedeutica all’installazione delle stesse sui dispositivi di sicurezza, che ad esempio identifichi la possibilità di applicare la patch immediatamente, o la necessità di apportare MEV o integrazioni prima di procedere alle installazioni ...
-
AGID
4. Indicazioni per le centrali di committenza
Si premette che le indicazioni elencate nei paragrafi precedenti si applicano, in generale, anche alle centrali di committenza. In particolare, le azioni AP2, AP3 e AP4 sono da ritenersi obbligatorie, per le centrali di committenza, quando queste svolgano iniziative di acquisizione ICT nell’interesse di Ministeri, Enti centrali, Regioni e città metropolitane. In aggiunta, si ritiene che le centrali di committenza, per il ruolo che hanno nelle acquisizioni pubbliche di beni e servizi, possono fungere da enti attuatori di miglioramenti/evoluzioni per gli aspetti di sicurezza delle forniture ICT. Anche sulla base dei risultati della rilevazione citata al paragrafo precedente, si propone alle centrali di committenza di:. inserire clausole di compliance alle indicazioni in materia di sicurezza sulle gare in corso che passi attraverso anche i comitati di governo (per le gare che li prevedono);. prevedere, per le gare che comprendono gestione di sistemi o fornitura di servizi di sicurezza, non solo flussi informativi sugli eventi critici verso l’amministrazione contraente, ma anche verso il CERT-PA e gli altri organismi a presidio della sicurezza cibernetica;. per le gare che prevedono centri servizi o servizi web, qualora si ritenga applicabile la misura, verificare la sicurezza tramite vulnerability assessment e penetration test. Il governo di queste verifiche potrebbe essere a cura di un organismo centrale (CVCN, CERT-PA, altri) in collaborazione col comitato di governo della fornitura;. sensibilizzare i fornitori al fine di anticipare le tendenze e le possibili problematiche di sicurezza che possono presentarsi (consultazioni di mercato mirate alla sicurezza);. costruire, in accordo con ANAC, un elevato livello di cultura e formazione delle Commissioni di valutazione delle gare in ambito sicurezza (vedi paragrafo 2.2.4);. svolgere un ruolo di omogeneizzatore/armonizzatore degli approcci di sicurezza e delle tecnologie di sicurezza erogati nell’ambito delle forniture della PA ...
-
AGID
2. Indicazioni per le amministrazioni
Nella tabella che segue, le azioni illustrate nei paragrafi precedenti sono classificate in base all’impatto e alla “onerosità” delle stesse per le amministrazioni, vale a dire in base a quanto l’amministrazione deve investire, in impegno e risorse, per effettuarle. NB: i valori riportati nella colonna 2 della tabella sono tipici, nel senso che rappresentano - statisticamente - la situazione della grande maggioranza delle amministrazioni: non è tuttavia da escludere la possibilità che, in casi particolari, il livello di impatto effettivo di una o più azioni sia più alto o più basso del valore di colonna 2. Ad esempio, ove il personale di un’amministrazione sia già formato sui temi della sicurezza, l’azione AG1 potrà avere un livello di impatto basso; allo stesso modo, in situazioni ove ci sia un uso massiccio e poco disciplinato di dispositivi di proprietà del fornitore, l’azione A2 potrebbe avere livello di impatto medio o anche alto. Tabella 2.7 Impatto delle azioni per le amministrazioni. Azione. Livello di impatto. Note. AG1. Medio. Comporta attività di formazione. AG2. Basso. Solo modifiche organizzative. AG3. Basso. Solo modifiche organizzative, e una tantum. AG4. Alto. Comporta un assessment, potrebbe essere oneroso ove il patrimonio ICT dell’amministrazione sia esteso e le informazioni su di esso siano obsolete. AG5. Alto. Comporta attività di BIA e di RA. Possibile rivolgersi a società esterne. AG6. Basso. Azione una tantum. AG7. Basso. Azione una tantum. AP1. Basso. L’azione può essere facilitata usando strumenti come la tabella 3. AP2. Basso. L’azione può essere facilitata seguendo un processo di scelta strutturato come in figura 1. AP3. Basso. L’azione può essere facilitata usando le tabelle dell’Appendice A. AP4. Medio. Può comportare attività di formazione. A1. Basso. Modifiche organizzative e strutturazione di processi già presenti. A2. Basso. Essenzialmente modifiche organizzative. A3. Basso. Essenzialmente modifiche organizzative. A4. Basso. Essenzialmente modifiche organizzative. A5. Basso. Essenzialmente modifiche organizzative. A6. Basso. Modifiche organizzative e strutturazione di processi già presenti. A7. Basso. Modifiche organizzative e strutturazione di processi già presenti. A8. Medio. Prevede verifica di documenti, pertanto il livello d’impatto dipende dalla complessità di questi ultimi. A9. Basso. Essenzialmente modifiche organizzative. A10. Medio. Vedi note per AG4 e AG5. A11. Medio. Possibile l’uso di strumenti specifici. A12. Alto. Sono possibili costi aggiuntivi per manutenzione e aggiornamento di prodotti. A13. Alto. Può comportare l’acquisizione di servizi esterni. Come si nota dalla tabella, la maggior parte delle azioni sono di “basso impatto”, in quanto esse si configurano come semplici mutamenti organizzativi o strutturazione di processi già presenti. Dato il basso impatto, non si ravvisano motivi per cui le amministrazioni non possano attrezzarsi da subito per svolgere tale azioni. Potrebbero, al più, costituire eccezione P.A. di dimensioni estremamente ridotte, ad esempio piccolissimi comuni con personale minimo, che peraltro difficilmente intraprendono acquisizioni ICT critiche sotto l’aspetto della sicurezza. Le azioni di “medio impatto” prevedono investimenti sulle risorse interne dell’amministrazione, e potrebbero determinare necessità di incentivi, straordinari o meccanismi premianti per il personale. Pertanto le amministrazioni devono strutturarsi per svolgere queste azioni nei tempi e nelle modalità compatibili con il budget a disposizione, considerando comunque che i costi da sostenere sono interni, riguardando il personale, e non sono necessariamente da imputare alla spesa per l’informatica. Le azioni di “alto impatto” potrebbero coinvolgere risorse esterne all’amministrazioni (ad esempio monitori), per cui potrebbero determinare costi aggiuntivi (esterni, da imputare prevalentemente al settore informatico) per l’amministrazione stessa. Non si ritiene pertanto di poter imporre alle amministrazioni, di qualunque grandezza e tipologia, di svolgere obbligatoriamente da subito queste azioni. Le P.A. dovranno valutare tempi e modi per la loro progressiva adozione, ad esempio effettuandole in occasione di un’acquisizione ICT effettivamente critica, tenendo comunque conto che i costi esterni sostenuti rappresentano un investimento, che verrà ripagato già nel breve periodo dall’innalzamento della sicurezza complessiva e dunque dal minore rischio per l’amministrazione stessa. Le P.A. devono inoltre tener presente che, sebbene alcune azioni vadano ripetute nel tempo, l’impatto maggiore si ha la prima volta che esse vengono eseguite, mentre le successive (aggiornamento) il loro impatto è nettamente inferiore ...
-
AGID
11. Raccolta delle informazioni relative agli accessi e alle transazioni
L’Infrastruttura interoperabilità PDND fornisce il supporto per il tracciamento e l’osservazione delle interazioni tra Erogatori e Fruitori. L’Infrastruttura interoperabilità PDND colleziona alcune informazioni utili a misurare l’efficacia dell’interoperabilità nel tempo ma non ha lo scopo di verificare gli SLA concordati tra Erogatori e Fruitori. In particolare, l’articolo 50-ter, comma 2, stabilisce che l’Infrastruttura interoperabilità PDND rende possibile l’interoperabilità dei sistemi informativi e delle basi di dati anche mediante “la raccolta e conservazione delle informazioni relative agli accessi e alle transazioni effettuate suo tramite”. A tal fine, i servizi previsti includono:. successo/fallimento;. coordinate temporali;. tempi di risposta. Auditing: registrazione delle autorizzazioni (Voucher) rilasciate dalla Infrastruttura Interoperabilità PDND e richieste dai Fruitori. L’Infrastruttura interoperabilità conserva per ogni evento di autorizzazione almeno:. le coordinate temporali del rilascio del Voucher;. il riferimento all’Accordo di interoperabilità stipulato;. la finalità entro cui saranno realizzate le transazioni;. l’URL dell’API richiesta;. eventuali parametri con cui il Fruitore decora la richiesta di autorizzazione. Il Gestore dell’Infrastruttura interoperabilità PDND PUÒ implementare anche un servizio di Tracing, ossia un servizio di raccolta dei tracciati che descrivono l’andamento esclusivamente quantitativo delle transazioni avvenute tra ciascun Erogatore e ciascun Fruitore. Le informazioni raccolte mediante tale servizio - che non dovranno comprendere il contenuto informativo scambiato tra Erogatore e Fruitore - descriveranno il numero di transazioni intervenute tra Erogatore e Fruitore in un determinato arco di tempo. In caso di implementazione di tale servizio, il Gestore informa gli Aderenti c on il preavviso indicato nella Lettera di Adesione. In tal caso, gli Aderenti sono tenuti a depositare, con le modalità e le tempistiche che saranno indicate nella Lettera di Adesione, sulla Infrastruttura interoperabilità PDND i tracciati delle transazioni a cui hanno partecipato in qualità sia di Erogatore sia di Fruitore. Le informazioni depositate dagli Aderenti sull’Infrastruttura interoperabilità PDND DEVONO essere aggregate in base ai seguenti criteri:. Aderenti coinvolti nella transazione e loro ruolo;. e-service oggetto della transazione (endpoint);. esito della chiamata/risposta. Ulteriori criteri di aggregazione delle informazioni depositate dagli Aderenti sull’Infrastruttura interoperabilità PDND POSSONO essere definiti dal Gestore. L’obiettivo della Infrastruttura interoperabilità PDND resta ancorato alla realizzazione di un punto unico di raccolta di queste informazioni, non essendo tenuta a svolgere un compito di riconciliazione dei tracciati di una stessa transazione e provenienti da Aderenti diversi. ...
-
AGID
Linee Guida sull’infrastruttura tecnologica della Piattaforma Digitale Nazionale Dati per l’interoperabilità dei sistemi informativi e delle basi di dati
ai sensi dell’articolo 50-ter, comma 2 del CAD ...
-
AGID
1. Introduzione
Nell’ambito del modello di interoperabilità delle pubbliche amministrazioni (di seguito MoDI), le presenti Linee Guida (di seguito Linee Guida) concernono la Piattaforma Digitale Nazionale Dati (di seguito PDND) di cui all’articolo 50-ter del decreto legislativo 7 marzo 2005, n. 82 e s.m.i. recante il “Codice dell’amministrazione digitale” (di seguito CAD), avendo ad oggetto l’infrastruttura tecnologica per l’interoperabilità dei sistemi informativi e delle basi di dati (di seguito Infrastruttura interoperabilità PDND) di cui al comma 2 del medesimo articolo. Ai sensi dell’articolo 50-ter, comma 1 del CAD, la PDND è finalizzata a favorire la conoscenza e l’utilizzo del patrimonio informativo detenuto per finalità istituzionali dai soggetti di cui all’articolo 2, comma 2 del CAD nonché la condivisione dei dati tra i soggetti che hanno diritto di accedervi ai fini dell’attuazione dell’articolo 50 del CAD e della semplificazione degli adempimenti dei cittadini e delle imprese, in conformità alla disciplina vigente. Ai sensi dell’articolo 50-ter, comma 2 del CAD, l’Infrastruttura interoperabilità PDND rende possibile l’interoperabilità dei sistemi informativi e delle basi di dati dei soggetti interessati, mediante:. la raccolta e la conservazione delle informazioni relative agli accessi e alle transazioni effettuati suo tramite. Ai sensi dell’art. 50-ter, comma 2-bis, del CAD, il Presidente del Consiglio dei Ministri o il Ministro delegato per l’innovazione tecnologica e la transizione digitale, ultimati i test e le prove tecniche di corretto funzionamento della Infrastruttura interoperabilità PDND, fissa il termine entro il quale i soggetti di cui all’articolo 2, comma 2, del CAD saranno tenuti ad accreditarsi alla stessa, a sviluppare le interfacce e a rendere disponibili le proprie basi dati. Nel rispetto dell’art. 50-ter, comma 7, del CAD, resta inteso che i soggetti di cui all’articolo 2, comma 2, del CAD possono continuare a utilizzare anche i sistemi di interoperabilità già previsti dalla legislazione vigente, ossia i sistemi di interoperabilità esistenti prima dell’introduzione della normativa che ha istituito la Piattaforma Digitale Nazionale Dati. Le Linee Guida sono emanate ai sensi dell’articolo 50-ter, comma 2, ultimo periodo del CAD, che dispone quanto segue: “L’AgID, sentito il Garante per la protezione dei dati personali e acquisito il parere della Conferenza unificata, di cui all’articolo 8 del decreto legislativo 28 agosto 1997, n. 281, adotta linee guida con cui definisce gli standard tecnologici e criteri di sicurezza, di accessibilità, di disponibilità e di interoperabilità per la gestione della piattaforma nonché il Processo di accreditamento e di fruizione del catalogo API con i limiti e le condizioni di accesso volti ad assicurare il corretto trattamento dei dati personali ai sensi della normativa vigente”. Più in particolare, le Linee Guida individuano:. le modalità di sottoscrizione e conservazione degli accordi di interoperabilità tra i soggetti interessati, pubblici e privati;. le modalità con cui i soggetti interessati danno seguito alle reciproche transazioni per il tramite dell’Infrastruttura interoperabilità PDND in attuazione degli accordi di interoperabilità sottoscritti;. le modalità di raccolta e conservazione delle informazioni relative agli accessi e alle transazioni effettuate per il tramite dell’Infrastruttura interoperabilità PDND. ...
-
AGID
13. Disposizioni in materia di protezione dei dati personali
Per quanto concerne i trattamenti la cui titolarità è individuata in capo al Gestore, questi DEVE rendere, mediante l’Infrastruttura interoperabilità PDND, un’apposita informativa ai sensi degli articoli 12, 13 e 14 del GDPR. Ai fini della fruizione degli e-service, gli Aderenti, in sede di Accordo di interoperabilità, DEVONO darsi reciprocamente atto di aver preso visione delle rispettive informative sul trattamento dei dati personali. Il Gestore DEVE adottare misure organizzative adeguate a garantire l’esercizio dei diritti degli interessati. 13.4.1. Responsabili del trattamento e trasferimenti di dati personali. Nell’erogazione dei servizi e delle funzionalità previste dall’Infrastruttura interoperabilità PDND, il Gestore PUÒ fare ricorso a soggetti terzi, opportunamente nominati responsabili del trattamento secondo le modalità stabilite all’articolo 28 del GDPR. In tal caso, il Gestore DEVE privilegiare fornitori situati sul territorio nazionale e dell’Unione Europea. Laddove non sia possibile, il Gestore PUÒ ricorrere a responsabili situati in Paesi terzi, che offrano garanzie sufficienti a mettere in atto misure tecniche e organizzative adeguate alla sicurezza dei trattamenti e alla tutela dell’interessato, ponendo in tal caso una particolare attenzione all’adozione di misure tecniche e organizzative adeguate a impedire tracciamenti avulsi dalle finalità del trattamento e a evitare che terzi non autorizzati possano accedere ai dati personali, tenuto conto - ai sensi dell’articolo 32 del GDPR - dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche. In ogni caso, il Gestore DEVE istruire i responsabili del trattamento sulla necessità di conservare i dati personali all’interno dell’Unione Europea. Il Gestore DEVE, in ogni caso, rispettare le misure previste dal Capo V del GDPR. 13.4.2. Sicurezza del trattamento. Ai sensi del Considerando 83 e dell’articolo 32 del GDPR e nel rispetto del principio di responsabilizzazione, il Gestore DEVE implementare ogni misura tecnica e organizzativa adeguata a garantire un livello di sicurezza adeguato al rischio. Tali misure di sicurezza comprendono almeno:. la cifratura “in transit” e “data at rest” e l’anonimizzazione dei dati personali;. la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento;. la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;. prevedere all’interno dei processi condivisi un momento dedicato a verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento. Di seguito si evidenziano le “best practices” in tema di sicurezza del trattamento dei dati personali con riferimento al contesto oggetto delle presenti Linee guida. 13.4.2.1. Cifratura dei dati personali. Il Gestore DEVE trattare i dati implementando misure in grado di rendere incomprensibili i dati personali a chiunque non sia autorizzato ad accedervi:. determinando le componenti critiche su cui applicare misure di crittografia (“at rest”, es: dischi rigidi, file, ecc.; “in transit”, es: trasferimento da/verso un database, canali di comunicazione) in base a:. forma/posizione in cui sono memorizzati/resi disponibili i dati personali;. rischi individuati;. prestazioni richieste;. scegliendo il tipo di crittografia (simmetrica o asimmetrica) in base al contesto e ai rischi individuati;. adottando soluzioni di crittografia basate su algoritmi pubblici notoriamente forti;. definendo ulteriori misure per garantire la disponibilità, l’integrità e la riservatezza delle informazioni. 13.4.2.2. Anonimizzazione dei dati personali. Laddove possibile, il Gestore DEVE eliminare le caratteristiche che identificano i dati personali. In particolare DEVE:. determinare ciò che deve essere anonimo in base al contesto, alla forma in cui vengono memorizzati i dati personali (compresi i campi del database o estratti dai testi) e ai rischi individuati;. anonimizzare permanentemente i dati che richiedono tale criterio di protezione in base alla forma dei dati (inclusi database e record testuali) e ai rischi individuati;. se i dati non possono essere anonimizzati in modo permanente, scegliere strumenti (inclusi la cancellazione parziale, la cancellazione, la ricerca di hashing e l’indice) che rispondano innanzitutto alle esigenze funzionali ...
-
AGID
10. Trust Infrastruttura interoperabilità PDND e sistemi informatici degli Aderenti
Per il tramite delle funzionalità rese disponibili dall’Infrastruttura interoperabilità PDND è realizzato il trust machine-to-machine tra:. sistemi informatici degli Aderenti. Gli Aderenti DEVONO generare il materiale crittografico utilizzato nel trust. Gli Aderenti DEVONO assicurare la riservatezza del materiale crittografico adottando opportune misure di sicurezza che preservino l’utilizzo improprio dello stesso. Gli Aderenti DEVONO registrare e mantenere sull’Infrastruttura interoperabilità PDND il materiale crittografico pubblico utilizzato dai propri sistemi informatici che interagiranno con la Infrastruttura interoperabilità PDND e i sistemi informatici degli altri Aderenti. L’Infrastruttura interoperabilità PDND DEVE generare il materiale crittografico utilizzato dagli Aderenti per verificare i Voucher emessi dalla stessa infrastruttura. L’Infrastruttura interoperabilità PDND DEVE assicurare la riservatezza del materiale crittografico adottando opportune misure di sicurezza che preservino l’utilizzo improprio degli stessi. L’Infrastruttura interoperabilità PDND DEVE rendere disponibili agli Aderenti il materiale crittografico pubblico necessario alla verifica dei Voucher emessi dalla stessa infrastruttura. Per dare seguito alle transazioni tra Erogatore e Fruitore sulla base di un Accordo di Interoperabilità, i sistemi informatici degli stessi DEVONO realizzare i seguenti passi:. l’Infrastruttura interoperabilità PDND emette un Voucher, con validità temporale limitata, contenente le informazioni necessarie ad identificare il Fruitore e l’Accordo di Interoperabilità entro cui il Voucher è stato emesso, utilizzando il materiale crittografico a tal fine generato dalla stessa infrastruttura;. il sistema informatico del Fruitore utilizza il Voucher per richiedere accesso all’e-service pubblicato sul Catalogo API dall’Erogatore relativo all’Accordo di Interoperabilità entro cui le transazioni sono realizzate;. il sistema informatico dell’Erogatore ricevuto il Voucher, ne verifica l’emissione da parte dell’Infrastruttura interoperabilità PDND e la validità temporale e solo in caso di verifica positiva il sistema informatico dell’Erogatore applica le regole di autorizzazione associate allo specifico Accordo di interoperabilità, nella sua completa responsabilità, per abilitare l’accesso del sistema informatico del Fruitore e provvede a dare seguito alle transazioni per l’e-service richiesto. L’Erogatore al momento della definizione dell’Accordo di Interoperabilità PUÒ prevedere tra i Requisiti di Fruizione che il sistema informatico del Fruitore sia identificato direttamente al precedente passo 4. In questo caso il Fruitore utilizza, al precedente passo 3, il materiale crittografico registrato sull’Infrastruttura interoperabilità PDND per decorare il Voucher per permettere all’Erogatore di identificarlo. Le tecnologie utilizzate per l’implementazione dei Voucher che l’Infrastruttura interoperabilità PDND DEVE assicurare sono indicate nell’Allegato 3. Gli Aderenti DEVONO implementare i passi indicati in precedenza per il tramite dell’Infrastruttura interoperabilità PDND nelle modalità indicate nell’Allegato 3. ...
-
AGID
8. Gestione degli Accordi di Interoperabilità
Il MoDI e, in particolare, le [LG INTEROPERABILITÀ TECNICA], prevedono che gli Accordi di Interoperabilità permettano agli Erogatori e ai Fruitori di dichiarare la costituzione di una relazione di utilizzo degli e-service. Il processo di stipula di un Accordo di Interoperabilità, realizzato esclusivamente sulla Infrastruttura interoperabilità PDND, prevede i seguenti passaggi:. al momento dell’invio della richiesta di stipula dell’Accordo di Interoperabilità per lo specifico e-service, il Fruitore DEVE dichiarare, ove non effettuato precedentemente, il possesso degli attributi Dichiarati e/o indicare gli attributi Verificati, ove indicati fra i Requisiti di Fruizione stabiliti dall’Erogatore per quel determinato e-service;. l’Erogatore, prima di confermare la richiesta di stipula dell’Accordo di Interoperabilità per l’e-service individuato dal Fruitore, DEVE verificare il possesso da parte del Fruitore degli attributi Verificati, a meno che l’Erogatore abbia indicato, in sede di definizione dei Requisiti di Fruizione dell’e-service oggetto dell’Accordo di Interoperabilità, di accettare le verifiche realizzate da altri Erogatori e sussista tale ultima circostanza. Lo schema di Accordo di Interoperabilità che gli Erogatori DEVONO utilizzare per disciplinare le modalità di accesso e fruizione degli e-service pubblicati sul Catalogo API è presente nell’Allegato 4. Il procedimento di stipula di un Accordo di Interoperabilità è concluso a seguito della sua sottoscrizione con firma elettronica ai sensi del Regolamento eIDAS da parte del Fruitore e successivamente dell’Erogatore. ...