Accordo del 23 novembre 2017
Traduzione
Accordo del 23 novembre 2017
tra la Confederazione Svizzera e l’Unione europea
concernente il collegamento dei rispettivi sistemi di scambio di quote di emissione di gas a effetto serra
Decisione n. 2/2020
del comitato misto istituito dall’Accordo relativa alla modifica
degli allegati I e II dell’Accordo e all’adozione delle norme tecniche di collegamento (NTC)
Conclusa il 5 novembre 2020 Entrata in vigore il 5 novembre 2020
Il comitato misto,
visto l’accordo tra l’Unione europea e la Confederazione Svizzera concernente il collegamento dei rispettivi sistemi di scambio di quote di emissione dei gas a effetto serra1 («accordo»), in particolare l’articolo 3 paragrafo 7 e l’articolo 13 paragrafo 2,
considerando quanto segue:
(1) La decisione n. 2/2019 del comitato misto, del 5 dicembre 20192, ha modifi- cato gli allegati I e II dell’accordo soddisfacendo in tal modo le condizioni per il collegamento di cui all’accordo.
(2) A seguito dell’adozione della decisione n. 2/2019 del comitato misto e a norma dell’articolo 21 paragrafo 3 dell’accordo, le Parti contraenti hanno scambiato i loro strumenti di ratifica o di approvazione, in quanto ritengono soddisfatte tutte le condizioni per il collegamento previste nell’accordo.
(3) A norma dell’articolo 21 paragrafo 4 dell’accordo, quest’ultimo è entrato in vigore il 1° gennaio 2020.
(4) È opportuno modificare l’allegato I dell’accordo conformemente all’arti- colo 13 paragrafo 2 dell’accordo per garantire un’agevole transizione nell’amministrazione degli operatori aerei assegnati per la prima volta alla
1 RS 0.814.011.268; GU L 322 del 7.12.2017, pag. 3.
2 Decisione n. 2/2019 del comitato misto istituito dall’accordo tra l’Unione europea e la Confederazione Svizzera concernente il collegamento dei rispettivi sistemi di scambio di quote di emissioni di gas a effetto serra, del 5 dicembre 2019, che modifica gli allegati I e II dell’accordo tra l’Unione europea e la Confederazione Svizzera concernente il colle- gamento dei rispettivi sistemi di scambio di quote di emissione dei gas a effetto serra (RU 2020 369) (GU L 314 del 29.9.2020, pag. 68).
Svizzera dopo l’entrata in vigore dell’accordo conformemente all’Allegato I Parte B Numero 17, tenendo conto dei progressi compiuti nell’istituzione di tale collegamento.
(5) Per tenere conto dei recenti sviluppi e garantire un maggiore livello di fles- sibilità nell’istituire il collegamento dei registri richiesto dall’accordo, l’alle- gato II dell’accordo dovrebbe essere modificato conformemente all’arti- colo 13 paragrafo 2 dell’accordo per fornire un ventaglio più ampio ma equivalente di tecnologie per istituire il collegamento tra i registri.
(6) A norma dell’articolo 3 paragrafo 7 dell’accordo, l’amministratore del regi- stro della Svizzera e l’amministratore centrale dell’Unione elaborano norme tecniche di collegamento (NTC) basate sui principi di cui all’allegato II dell’accordo. Le NTC dovrebbero descrivere le esigenze per l’istituzione di una connessione solida e sicura tra il libro di bordo elettronico supplementa- re della Svizzera (SSTL) e il catalogo delle operazioni dell’Unione europea (EUTL). Le NTC dovrebbero entrare in vigore una volta adottate con deci- sione del comitato misto.
(7) A norma dell’articolo 13 paragrafo 1 dell’accordo, il comitato misto dovreb- be stabilire orientamenti tecnici per garantire la corretta attuazione dell’accordo, anche per quanto riguarda l’istituzione di un collegamento so- lido e sicuro tra l’SSTL e l’EUTL. Gli orientamenti tecnici possono essere elaborati da un gruppo di lavoro istituito a norma dell’articolo 12 paragra- fo 5 dell’accordo. Del gruppo di lavoro dovrebbero far parte quanto meno l’amministratore del registro svizzero e l’amministratore centrale dell’Unio- ne e il gruppo di lavoro dovrebbe assistere il comitato misto nell’esercizio delle sue funzioni a norma dell’articolo 13 dell’accordo.
(8) Data la natura tecnica degli orientamenti e la necessità di adeguarli agli svi- luppi in corso, gli orientamenti tecnici elaborati dall’amministratore del registro svizzero e dall’amministratore centrale dell’Unione dovrebbero es- sere trasmessi al comitato misto per informazione o, se del caso, approva- zione,
ha adottato la presente decisione:
Art. 1
Nella parte B dell’allegato I dell’accordo, il secondo comma del punto 17 è sostitui- to dal seguente:
«Gli operatori aerei assegnati alla Svizzera per la prima volta dopo l’entrata in vigore del presente accordo sono amministrati dalla Svizzera dopo il 30 aprile dell’anno di assegnazione e una volta che il collegamento provvisorio dei registri diventa operativo.».
Art. 2
Il quarto comma dell’allegato II dell’accordo è sostituito dal seguente:
«Le NTC precisano che le comunicazioni tra l’SSTL e l’EUTL costituiscono scambi sicuri di messaggi di servizi web basati sulle tecnologie seguenti∗ o su tecnologie equivalenti:
– servizi web tramite SOAP (Simple Object Access Protocol);
– rete privata virtuale (Virtual Private Network) basata su hardware;
– linguaggio di marcatura estensibile XML (Extensible Markup Language);
– firma digitale; e
– protocolli temporali di rete (Network Time Protocols).
* Tali tecnologie sono attualmente utilizzate per stabilire un collegamento tra il registro dell’Unione e il catalogo internazionale delle operazioni, nonché tra il registro della Svizzera e il catalogo internazionale delle operazioni.».
Art. 3
Sono adottate le norme tecniche di collegamento (NTC) allegate alla presente deci- sione.
Art. 4
A norma dell’articolo 12 paragrafo 5 dell’accordo è istituito un gruppo di lavoro. Esso assiste il comitato misto al fine di garantire la corretta attuazione dell’accordo, compresa l’elaborazione di orientamenti tecnici per l’attuazione delle NTC.
Il gruppo di lavoro comprende almeno l’amministratore del registro della Svizzera e l’amministratore centrale dell’Unione
Art. 5
La presente decisione entra in vigore il giorno della sua adozione.
Fatta a Bruxelles, il 5 novembre 2020.
Per il comitato misto | ||
La segretaria per l’Unione europea: Xxxx-Xxxxxxxxx Xxxxxx | La presidente: Xxxxxxx Xxxxx | Xx segretaria per la Svizzera: Xxxxxxxx Xxxxxxx |
Allegato
Norme tecniche di collegamento (NTC)
a norma dell’articolo 3 paragrafo 7 dell’accordo tra l’Unione europea e la Confederazione Svizzera concernente il collegamento dei rispettivi sistemi
di scambio di quote di emissione di gas a effetto serra
Norme per la soluzione provvisoria
1. Glossario
Tabella 1-1 Acronimi, termini e definizioni del settore
Acronimo/termine | Definizione |
Quota di emissione | Il diritto di emettere una tonnellata di biossido di carbonio equivalente per un periodo determinato, valido unicamente per rispettare gli obblighi dell’ETS dell’UE o dell’ETS della Svizzera |
CH | Confederazione Svizzera |
CHU | Quote generiche della Svizzera (per le quote CHU del secondo periodo di impegno si utilizza l’acronimo «CHU2») |
CHUA | Quota svizzera assegnata al trasporto aereo |
POC | Procedure operative comuni elaborate congiuntamente dalle Parti contraenti dell’accordo per rendere operativo il collegamento tra l’ETS dell’UE e l’ETS della Svizzera |
ETR (Emissions Trading registry) | Registro dello scambio di quote di emissione |
ETS (Emission Trading system) | Sistema di scambio di quote di emissione |
UE | Unione europea |
EUA | Quota generale dell’UE |
EUAA | Quota di emissione del trasporto aereo dell’UE |
EUCR | Registro consolidato dell’Unione europea |
EUTL | Catalogo delle operazioni dell’Unione europea |
Registro | Un sistema contabile per le quote rilasciate nell’ambito dell’ETS, che tiene traccia della titolarità delle quote detenute in conti elettronici |
SSTL | Libro di bordo elettronico supplementare della Svizzera |
Acronimo/termine | Definizione |
Operazione | Un processo in un registro che include il trasferimento di una quota da un conto a un altro conto |
Sistema di catalogo delle operazioni | Il catalogo delle operazioni contiene la registrazione di tutte le operazioni proposte inviate da un registro all’altro registro. |
Tabella 1-2 Acronimi, termini e definizioni tecnici
Acronimo/Termine | Definizione |
Crittografia asimmetrica | Xxxxxxxx chiavi pubbliche e private per cifrare e decifrare i dati. |
Autorità di certificazione (AC) | Organismo che rilascia certificati digitali |
Chiave crittografica | Un’informazione che determina il risultato funzionale di un algoritmo crittografico. |
Decifratura | Processo inverso della cifratura. |
Firma digitale | Tecnica matematica usata per convalidare l’autenticità e l’integrità di un messaggio, un software o un documento elettronico. |
Cifratura | Il processo di conversione di informazioni o dati in un codice, in particolare per impedire l’accesso non autorizzato. |
Immissione di file | Il processo di lettura di un file. |
Firewall | Apparecchio o software per la sicurezza delle reti che monitora e controlla il traffico in entrata e in uscita in base a regole predeterminate. |
Monitoraggio «Heartbeat» (strumento di diagnostica continua) | Segnale periodico generato e monitorato da hardware o software per indicare il funzionamento normale o per sincronizzare altre parti di un sistema informatico. |
IPSec | Sicurezza IP. Suite di protocolli di reti che autentifica e cripta i pacchetti di dati per fornire una comunicazione cifrata sicura tra due computer su una rete IP. |
Test di penetrazione | Pratica che consiste nel testare un sistema informatico, una rete o un’applicazione web per individuare le vulnerabilità in materia di sicurezza che l’autore di un attacco potrebbe sfruttare. |
Processo di riconciliazione | Processo che mira a garantire la concordanza di due insiemi di registrazioni. |
Acronimo/Termine | Definizione |
VPN | Rete privata virtuale (Virtual Private Network). |
XML | Linguaggio di marcatura estensibile (Extensible Mark-up Language). Questo linguaggio permette ai progettisti di creare tag personalizzati, che consentono la definizione, la trasmissione, la convalida e l’interpretazione di dati tra applicazioni e tra organizzazioni. |
2. Introduzione
L’accordo tra l’Unione europea e la Confederazione svizzera del 23 novembre 2017 concernente il collegamento dei rispettivi sistemi di scambio di quote di emissione di gas a effetto serra, («accordo») prevede il riconoscimento reciproco delle quote di emissione che possono essere utilizzate per conformarsi al sistema di scambio di quote di emissione dell’Unione europea («EU ETS») o al sistema di scambio di quote di emissione della Svizzera («ETS della Svizzera»). Per rendere operativo il collegamento tra l’EU ETS e l’ETS della Svizzera, sarà stabilito un collegamento diretto tra il catalogo delle operazioni dell’Unione europea (EUTL) del registro dell’Unione e il libro di bordo elettronico supplementare della Svizzera (SSTL) del registro svizzero in modo tale da consentire il trasferimento da un registro all’altro delle quote di emissioni rilasciate nell’ambito dei due ETS (art. 3 par. 2 dell’ac- cordo). Per rendere operativo il collegamento tra l’EU ETS e l’ETS della Svizzera, nel maggio 2020 o il prima possibile dopo tale data sarà predisposta una soluzione provvisoria. Le Parti contraenti cooperano per sostituire al più presto la soluzione provvisoria con un collegamento permanente dei registri (allegato II dell’accordo).
A norma dell’articolo 3 paragrafo 7 dell’accordo, l’amministratore del registro della Svizzera e l’amministratore centrale dell’Unione stabiliscono norme tecniche di collegamento (NTC) basate sui principi di cui all’allegato II dell’accordo, descri- vendo in dettaglio le disposizioni per l’istituzione di una connessione solida e sicura tra l’SSTL e l’EUTL. Le NTC elaborate dagli amministratori entrano in vigore una volta adottate con decisione del comitato misto.
Come indicato nel presente documento, le NTC sono adottate dal comitato misto con la decisione n. 2/2020. Conformemente alla presente decisione, il comitato misto chiede all’amministratore del registro della Svizzera e all’amministratore centrale dell’Unione di elaborare ulteriori orientamenti tecnici per rendere operativo il colle- gamento e di garantire che tali orientamenti siano costantemente adattati al progres- so tecnico e alle nuove prescrizioni relative alla sicurezza interna ed esterna del collegamento e al suo funzionamento efficace ed efficiente.
2.1. Ambito di applicazione
Il presente documento rappresenta l’intesa comune tra le Parti contraenti dell’ac- cordo per quanto riguarda la definizione delle procedure di base del collegamento tra i registri dell’EU ETS e l’ETS della Svizzera. Descrive a grandi linee la base di riferimento per le specifiche tecniche in termini di requisiti di architettura, servizio e sicurezza, ma saranno necessari ulteriori orientamenti tecnici per rendere operativo il collegamento.
Per il corretto funzionamento del collegamento, occorreranno processi e procedure che ne rafforzino l’operatività. A norma dell’articolo 3 paragrafo 6 dell’accordo, tali aspetti sono trattati dettagliatamente in un documento separato relativo alle procedu- re operative comuni (POC), che deve essere adottato separatamente mediante deci- sione del comitato misto.
2.2. Destinatari
I destinatari del presente documento sono l’amministratore del registro svizzero e l’amministratore centrale dell’Unione.
3. Disposizioni generali
3.1. Architettura del collegamento di comunicazione
Lo scopo della presente sezione è fornire una descrizione dell’architettura generale per la messa in opera del collegamento tra l’UE ETS e l’ETS della Svizzera e le diverse componenti coinvolte.
Poiché la sicurezza è un elemento fondamentale della definizione dell’architettura del collegamento tra i registri, sono state adottate tutte le misure per disporre di un’architettura solida. Il futuro collegamento permanente tra i registri si baserà su servizi web, la soluzione provvisoria utilizzerà invece un meccanismo per lo scam- bio di file.
La soluzione tecnica utilizza:
– un protocollo di trasferimento sicuro per lo scambio di messaggi;
– messaggi XML;
– la firma digitale e la cifratura basate su XLM;
– un dispositivo VPN o una rete di trasporto di dati sicura equivalente.
3.1.1. Scambio di messaggi
La comunicazione tra il registro dell’Unione e il registro svizzero si baserà su un meccanismo di scambio di messaggi attraverso canali protetti. Ciascuna parte di- sporrà del proprio archivio di messaggi ricevuti.
Entrambe le Parti contraenti conservano un registro dei messaggi ricevuti, unitamen- te ai dettagli relativi al trattamento.
Occorre segnalare gli errori o uno stato non previsto come avvisi e le squadre di sostegno dovrebbero contattarsi.
Gli errori e gli eventi imprevisti saranno trattati nel rispetto delle procedure ope- rative stabilite nel processo di gestione degli incidenti delle POC.
3.1.2. Messaggi XML – Descrizione di alto livello
Un messaggio XML contiene uno degli elementi seguenti:
– una o più richieste di operazioni e/o una o più risposte a operazioni;
– un’operazione/una risposta relativa alla procedura di conciliazione;
– un messaggio di prova.
Ciascun messaggio contiene un’intestazione che riporta le seguenti informazioni:
– il sistema ETS da cui proviene (ETS di origine);
– il numero di sequenza.
3.1.3. Finestre di immissione
La soluzione provvisoria si basa su finestre predefinite di immissione, seguite da una serie di eventi designati. Le richieste di operazioni ricevute attraverso il collegamen- to possono essere immesse solo a intervalli prestabiliti. Le finestre di immissione comprendono una convalida tecnica per le operazioni in entrata e in uscita. Inoltre, le riconciliazioni possono essere effettuate su base giornaliera e possono essere avviate manualmente.
Le modifiche nella frequenza/tempistica di tutti questi eventi saranno trattate nel rispetto delle procedure operative stabilite nel processo di gestione degli incidenti delle POC.
3.1.4. Flussi di messaggi delle operazioni
Operazioni in uscita
Queste operazioni riflettono il punto di vista dell’ETS di origine. Il grafico della sequenza illustra tutti i flussi specifici di operazioni in uscita.
Flusso principale «Operazione normale» (le cui fasi sono indicate nel grafico di cui sopra):
a) nell’ETS di origine la richiesta di operazione è inviata dal registro al catalogo delle operazioni, una volta terminati tutti i tempi di attesa di lavoro (24 ore, se del caso);
b) il catalogo delle operazioni convalida la richiesta di operazione;
c) la richiesta di operazione è inviata all’ETS destinatario;
d) la risposta di accettazione è inviata al registro ETS di origine;
e) l’ETS destinatario convalida la richiesta di operazione;
f) l’ETS destinatario invia la risposta di accettazione al catalogo delle operazioni dell’ETS di origine;
g) il catalogo delle operazioni invia la risposta di accettazione al registro.
Flusso alternativo «Rifiuto del catalogo delle transazioni» (le cui fasi sono indicate nel grafico, partendo dalla lettera a):
a) nell’ETS di origine la richiesta di operazione è inviata dal registro al catalo- go delle operazioni, una volta trascorsi tutti i tempi di attesa di lavoro (24 ore, se del caso).
In seguito:
b) il catalogo delle operazioni non convalida la richiesta;
c) il messaggio di rifiuto è inviato al registro di origine.
Flusso alternativo «Rifiuto da parte dell’ETS» (le cui fasi sono indicate nel grafico, partendo dalla lettera a):
a) nell’ETS di origine la richiesta di operazione è inviata dal registro al catalo- go delle operazioni, una volta trascorsi tutti i tempi di attesa di lavoro (24 ore, se del caso);
b) il catalogo delle operazioni convalida l’operazione;
c) la richiesta di operazione è inviata all’ETS destinatario;
d) il messaggio di accettazione è inviato al registro dell’ETS di origine. In seguito:
e) il catalogo delle operazioni dell’ETS destinatario non convalida l’opera- zione;
f) l’ETS destinatario invia la risposta di rifiuto al catalogo delle operazioni dell’ETS di origine;
g) il catalogo delle operazioni trasmette il rifiuto al registro.
Operazioni in entrata
Queste operazioni riflettono il punto di vista dell’ETS destinatario. Il flusso specifi- co è illustrato nel seguente grafico della sequenza:
Il grafico indica:
1. quando il catalogo delle operazioni dell’ETS destinatario convalida la richie- sta, invia il messaggio di accettazione all’ETS di origine e un messaggio
«operazione completata» («transaction completed») al registro dell’ETS de- stinatario;
2. quando una richiesta in entrata viene rifiutata nel catalogo delle operazioni del destinatario, la richiesta di operazione non è inviata al registro dell’ETS destinatario.
Protocollo
Il ciclo dei messaggi delle operazioni comporta solo due messaggi:
– proposta di operazione dall’ETS di origine 🡪 all’ETS destinatario;
– risposta dell’ETS destinatario 🡪 all’ETS di origine circa l’operazione: accettata («accepted») o rifiutata («rejected») (indicando il motivo del rifi- uto):
– accettata: l’operazione è completata,
– rifiutata: l’operazione è interrotta («terminated»).
Status delle operazioni
– Lo status dell’operazione dell’ETS di origine sarà impostato su «proposto» («proposed») al momento dell’invio della richiesta.
– Lo status dell’operazione dell’ETS destinatario sarà impostato su «proposto» («proposed») dopo il ricevimento della richiesta e nel corso del suo tratta- mento.
– Lo status dell’operazione dell’ETS destinatario sarà impostato su «completa- to»/«interrotto» («completed»/«terminated») al termine del trattamento della proposta. L’ETS destinatario invierà quindi il messaggio di accettazio- ne/rifiuto corrispondente.
– Lo status dell’operazione dell’ETS di origine sarà impostato su «completa- to»/«interrotto» («completed»/«terminated») dopo il ricevimento del mes- saggio di accettazione/rifiuto e nel corso del suo trattamento.
– Nell’ETS di origine lo statuto dell’operazione rimane su «proposto» («pro- posed») fino a quando non arriva una risposta.
– Lo status dell’operazione dell’ETS destinatario sarà impostato su «interrot- to» («terminated») se rimane per oltre 30 minuti su «proposto».
Gli incidenti relativi alle operazioni saranno trattati nel rispetto delle procedure operative stabilite nel processo di gestione degli incidenti delle POC.
3.2. Sicurezza del trasferimento dei dati
I dati in transito sono soggetti a quattro livelli di sicurezza:
1) controllo dell’accesso alla rete: firewall e strato dell’interconnessione di rete;
2) cifratura a livello di trasporto: una VPN o una rete di trasporto di dati sicura equivalente;
3) cifratura a livello di sessione: protocollo di trasferimento per lo scambio sicuro di messaggi;
4) cifratura a livello di applicazione: cifratura XLM del contenuto e firma.
3.2.1. Firewall e interconnessione della rete
Il collegamento è stabilito mediante una rete protetta da un firewall hardware. Il firewall è configurato secondo norme che permettono unicamente ai clienti «regi- strati» di effettuare collegamenti con il server VPN.
3.2.2. Rete privata virtuale (Virtual Private Network – VPN)
Tutte le comunicazioni tra le Parti contraenti sono protette mediante una tecnologia di trasporto di dati sicura. Nel caso di una rete privata virtuale (VPN), l’infrastruttura dovrebbe essere basata su dispositivi hardware o virtuali. Le tecnologie VPN con- sentono di trasportare informazioni da un punto a un altro punto attraverso un canale sicuro (tunnel) su una rete, come l’Internet, proteggendo l’insieme delle comunica- zioni. Prima della creazione del tunnel VPN, un certificato digitale è rilasciato al punto finale del potenziale cliente, consentendo a quest’ultimo di fornire la prova della sua identità durante la negoziazione della connessione. Ciascuna Parte con- traente è responsabile dell’installazione del certificato nel proprio punto finale VPN. Utilizzando certificati digitali, ogni server finale VPN avrà accesso a un servizio centrale per negoziare le credenziali di autenticazione. Durante la creazione del tunnel, viene negoziata la cifratura, che garantisce la protezione di tutte le comuni- cazioni che transitano nel tunnel.
I punti finali VPN dei clienti sono configurati in modo che il tunnel resti sempre aperto al fine di consentire in qualsiasi momento una comunicazione affidabile e bidirezionale tra le Parti contraenti.
Qualsiasi altra soluzione equivalente deve rispettare i principi summenzionati.
3.2.3. Attuazione dell’IPSec
Quando si ricorre a una soluzione VPN, l’utilizzo del protocollo IPSec per istituire l’infrastruttura VPN da sito a sito consentirà l’autenticazione da sito a sito, l’integrità dei dati e la cifratura dei dati. Le configurazioni VPN IPSec garantiscono un’autenticazione regolamentare tra due punti finali in un collegamento VPN. Le Parti contraenti individuano e autenticano il cliente remoto tramite la connessione IPSec utilizzando i certificati digitali forniti da un’autorità di certificazione ricono- sciuta dall’altra parte.
L’IPsec garantisce inoltre l’integrità dei dati di tutte le comunicazioni che transitano nel tunnel VPN. I pacchetti di dati sono sottoposti alla tecnica crittografica Hash e firmati utilizzando le informazioni di autenticazione allestite dalla VPN. Anche la riservatezza dei dati è garantita mediante la cifratura IPSec.
3.2.4. Protocollo di trasferimento per lo scambio sicuro di messaggi
La soluzione provvisoria ricorre a una cifratura a più livelli che consente lo scambio sicuro di dati tra le Parti contraenti. I due sistemi e i loro diversi ambienti sono interconnessi a livello di rete mediante tunnel VPN o reti di trasporto di dati sicure equivalenti. A livello di applicazione i file sono trasferiti mediante un protocollo di trasferimento per lo scambio sicuro di messaggi a livello di sessione.
3.2.5. Cifratura XLM e firma
Nei file XML, la firma e la cifratura sono effettuate su due livelli. Ogni richiesta di operazione, risposta di operazione e messaggio di riconciliazione sono firmati singo- larmente elettronicamente.
In una seconda fase, ogni sottoelemento dell’elemento «messaggio» è criptato singo- larmente.
Inoltre, nella terza fase, per garantire l’integrità e la non disconoscibilità dell’intero messaggio, l’elemento radice del messaggio è firmato elettronicamente. Ne conse- gue un elevato livello di protezione dei dati XML incorporati. L’esecuzione tecnica rispetta le norme del Consorzio mondiale del Web (W3C).
Per decifrare e verificare il messaggio, si segue lo stesso processo in ordine inverso.
3.2.6. Chiavi crittografiche
Per la cifratura e la firma si utilizzerà la crittografia a chiave pubblica.
Nel caso specifico dell’IPSec, viene utilizzato un certificato digitale rilasciato da un’autorità di certificazione (AC) ritenuta affidabile da entrambe le Parti contraenti. L’AC in questione verifica l’identità del titolare del certificato e rilascia certificati che sono utilizzati per identificare formalmente un’organizzazione e istituire canali sicuri di comunicazione di dati tra le Parti contraenti.
Le chiavi crittografiche sono usate per firmare e criptare canali di comunicazio- ne e file di dati. Le Parti contraenti si scambiano per via elettronica, attraverso canali protetti, i certificati pubblici che vengono verificati fuori banda. Questa procedura è parte integrante del processo di gestione della sicurezza delle infor- mazioni delle POC.
3.3. Elenco delle funzioni nell’ambito del collegamento
Il collegamento comprende le specifiche del sistema di trasmissione per una serie di funzioni che attuano i processi «business» derivanti dall’accordo. Il collegamento include anche le specifiche per il processo di riconciliazione e i messaggi di prova che consentiranno l’attuazione di un sistema di monitoraggio Heartbeat.
3.3.1. Operazioni «business»
Dal punto di vista «business», nell’ambito del collegamento sono previsti quattro (4) tipi di richieste di operazioni:
– trasferimenti esterni:
– dopo l’entrata in funzione del collegamento dei sistemi ETS, le quote dell’UE e le quote della Svizzera sono fungibili e dunque totalmente trasferibili tra le Parti contraenti;
– un trasferimento effettuato tramite il collegamento presuppone un conto di origine su un ETS e un conto destinatario sull’altro ETS;
– il trasferimento può riguardare qualsiasi quantità dei quattro (4) tipi di quote:
– quote generiche della Svizzera (CHU),
– quote assegnate al trasporto aereo della Svizzera (CHUA),
– quote generiche dell’UE (EUA),
– quote assegnate al trasporto aereo UE (EUAA).
– Assegnazione internazionale:
gli operatori aerei amministrati da un ETS che hanno degli obblighi nei con- fronti dell’altro ETS e hanno il diritto di ricevere quote a titolo gratuito da questo secondo ETS, riceveranno gratuitamente quote di trasporto aereo da quest’ultimo, mediante un’operazione di assegnazione internazionale.
– Annullamento di un’assegnazione internazionale:
questa operazione viene effettuata qualora occorra annullare l’insieme delle quote assegnate a titolo gratuito versate sul conto di deposito di un operatore aereo dall’altro ETS.
– Restituzione di quote in eccesso:
procedura analoga a quella dell’annullamento, ma in cui non occorre annul- lare tutte le quote assegnate poiché all’ETS che le ha assegnate devono esse- re restituite solo le quote in eccesso.
3.3.2. Protocollo di riconciliazione
Le riconciliazioni avvengono unicamente solo dopo la chiusura delle finestre per l’immissione, la convalida e il trattamento dei messaggi.
Le riconciliazioni sono parte integrante delle misure di sicurezza e di coerenza del collegamento. Le Parti contraenti concorderanno l’esatta tempistica delle riconcilia- zioni prima di stabilire un calendario. Con l’accordo di entrambe le Parti contraenti si possono effettuare riconciliazioni giornaliere programmate. Dopo ciascuna immis- sione sarà effettuata almeno una riconciliazione programmata.
In ogni caso, ciascuna Parte contraente può procedere in qualsiasi momento a ricon- ciliazioni manuali.
Le modifiche della tempistica e della frequenza delle riconciliazioni programma- te saranno trattate nel rispetto delle procedure operative stabilite nel processo di gestione degli incidenti delle POC.
3.3.3. Messaggio di prova
Per verificare la comunicazione end-to-end è previsto un messaggio di prova. Il messaggio conterrà dati che lo identificheranno come messaggio di prova e, una volta pervenuto all’altra estremità, quest’ultima invierà una risposta.
3.4. Norme per i servizi web
Nella soluzione provvisoria non saranno utilizzati servizi web. È opportuno notare, tuttavia, che la forma e il formato dei messaggi XML rimarranno in gran parte immutati. Con l’introduzione del collegamento permanente dei registri in futuro, i servizi web dovrebbero consentire lo scambio di messaggi XML in tempo reale.
3.5. Definizione specifica dei servizi web
Questa sezione non riguarda la soluzione provvisoria. Come indicato nella sezione precedente, i servizi web saranno utilizzati solo nel futuro collegamento permanente dei registri.
3.6. Requisiti relativi alla registrazione dei dati
Per rispondere all’esigenza di entrambe le Parti contraenti di garantire l’accuratezza e la coerenza delle informazioni e per fornire loro strumenti da utilizzare nel proces- so di riconciliazione per eliminare le incoerenze, entrambe le Parti contraenti con- servano quattro (4) tipi di registrazioni di dati:
– cataloghi delle operazioni;
– cataloghi delle riconciliazioni;
– archivio dei messaggi;
– cataloghi degli audit interni.
Tutti i dati di questi cataloghi dovranno essere conservati almeno per tre (3) mesi ai fini della risoluzione di problemi; la loro ulteriore conservazione è determinata dal diritto delle Parti contraenti vigente in materia di audit. I file dei cataloghi che risal- gono a più di tre (3) mesi possono essere archiviati in un sistema informatico indi-
pendente sicuro, a condizione che possano essere recuperati o vi si possa accedere entro un termine ragionevole.
Cataloghi delle operazioni
I cataloghi delle operazioni sono attuati nei sottosistemi EUTL e SSTL.
Più specificamente, i cataloghi delle operazioni registrano ogni operazione proposta inviata all’altro ETS. Ciascuna registrazione contiene tutti i campi relativi al conte- nuto dell’operazione e al suo risultato (la risposta dell’ETS destinatario). I cataloghi delle operazioni registrano le operazioni in entrata e le risposte inviate all’ETS di origine.
Cataloghi delle riconciliazioni
Il catalogo delle riconciliazioni contiene la registrazione di tutti i messaggi di ricon- ciliazione scambiati tra le due Parti contraenti, ivi compresi l’identificatore, la mar- catura temporale e il risultato della riconciliazione: status della riconciliazione
«superata» («pass») o «discrepanze» («discrepancies»). Nella soluzione provvisoria i messaggi di riconciliazione fanno parte integrante dei messaggi scambiati.
Entrambe le Parti contraenti registrano le singole richieste e le relative risposte nel catalogo delle riconciliazioni. Anche se le informazioni contenute in questo catalogo non sono condivise direttamente nell’ambito della procedura di conciliazione vera e propria, l’accesso a tali informazioni potrebbe essere necessario per eliminare le incoerenze.
Archivio dei messaggi
Entrambe le Parti contraenti sono tenute ad archiviare una copia dei dati scambiati (file XLM), inviati e ricevuti, indicando se il formato di questi messaggi XLM è corretto.
Questo archivio è utilizzato principalmente a fini di audit, per disporre di una prova di quello che è stato inviato e ricevuto da entrambe le Parti contraenti. In quest’ot- tica, insieme ai file, occorre archiviare anche i relativi certificati.
Questi file forniscono inoltre informazioni aggiuntive ai fini della soluzione di eventuali problemi.
Catalogo degli audit interni
Questi cataloghi sono predisposti e utilizzati da ciascuna Parte contraente separata- mente.
3.7. Requisiti operativi
Nella soluzione provvisoria lo scambio di dati tra i due sistemi non è totalmente autonomo: sono infatti necessari operatori e procedure per rendere operativo il colle- gamento.
4. Disposizioni relative alla disponibilità
4.1. Progettazione della disponibilità delle comunicazioni
Fondamentalmente l’architettura della soluzione provvisoria consiste in un’infrastruttura TIC e un software che consentono la comunicazione tra l’ETS della Svizzera e l’EU ETS. Garantire livelli elevati di disponibilità, integrità e riservatezza per questo flusso di dati diventa pertanto un aspetto essenziale di cui tenere conto nella progettazione della soluzione provvisoria e del collegamento permanente dei registri. Trattandosi di un progetto nel quale l’infrastruttura TIC, il software persona- lizzato e i processi svolgono un ruolo fondamentale, per progettare un sistema resi- liente occorre tenere conto di questi tre elementi.
Resilienza dell’infrastruttura TIC
Il capitolo sulle disposizioni generali del presente documento descrive in dettaglio gli elementi costitutivi dell’architettura. Per quanto riguarda l’infrastruttura TIC, nell’ambito del collegamento provvisorio, è stata istituita una rete VPN resiliente (o una rete equivalente) che crea dei tunnel di comunicazione sicuri mediante i quali i messaggi possono essere scambiati in modo sicuro. Altri elementi dell’infrastruttura sono configurati in alta disponibilità e/o sono dotati di meccanismi di riserva.
Resilienza dei software personalizzati
I moduli software personalizzati consentono di potenziare la resilienza in quanto, per un determinato periodo di tempo, tentano di ristabilire la comunicazione con l’altro servizio quando, per un motivo qualsiasi, questo non è disponibile.
Resilienza dei servizi
Nella soluzione provvisoria, gli scambi di dati tra le Parti contraenti avvengono a intervalli predefiniti nel corso dell’anno. Alcune delle fasi necessarie per gli scambi di dati preprogrammati richiedono l’intervento manuale dei gestori dei sistemi e/o degli amministratori dei registri. Tenendo conto di questo aspetto e per aumentare la disponibilità e l’adeguato svolgimento degli scambi:
– le procedure operative prevedono finestre temporali significative per l’ese- cuzione di ogni tappa;
– i moduli software per la soluzione provvisoria attuano una comunicazione asincrona;
– il processo automatico di riconciliazione individuerà eventuali problemi nell’immissione dei file di dati in entrambe le parti;
– i processi di monitoraggio (infrastruttura TIC e moduli software personaliz- zati) sono considerati nelle procedure di gestione degli incidenti e attivano queste procedure (definite nel documento relativo alle procedure operative comuni). Le procedure volte a ridurre il tempo necessario per ripristinare il normale funzionamento a seguito di incidenti sono fondamentali per garanti- re tassi di disponibilità elevati.
4.2. Piano di attivazione, comunicazione, riattivazione e prove
Tutti i diversi elementi dell’architettura della soluzione provvisoria devono superare una serie di prove individuali e collettive destinate a verificare che la piattaforma è pronta a livello dell’infrastruttura TIC e del sistema di informazione. Questi test ope- rativi costituiscono una condizione preliminare obbligatoria ogni volta che la solu- zione provvisoria passa dallo status «sospeso» («suspended») allo status «operativo» («operational»).
L’attivazione dello status operativo del collegamento presuppone l’adeguata esecu- zione di un piano di prove predefinito. Ciò consente di verificare che per ciascun registro è stata effettuata dapprima una serie di prove interne, seguita dalla convalida della connettività «end-to-end», prima di iniziare a trasmettere operazioni vere e proprie tra le due Parti contraenti.
Il piano delle prove dovrebbe menzionare la strategia di prove generale e informa- zioni dettagliate sull’infrastruttura per le prove. In particolare, per ciascun elemento di ogni blocco di prova occorre disporre degli elementi seguenti:
– i criteri e gli strumenti di prova;
– i ruoli assegnati in vista dell’esecuzione delle prove;
– i risultati attesi (positivi e negativi);
– il calendario delle prove;
– la registrazione dei requisiti relativi ai risultati delle prove;
– la documentazione relativa alla risoluzione dei problemi;
– le disposizioni relative ai livelli successivi di intervento.
Il processo delle prove di attivazione dello status operativo potrebbe essere suddivi- so in quattro (4) blocchi o fasi concettuali:
4.2.1. Prove dell’infrastruttura TIC in interno
Queste prove devono essere eseguite e/o verificate individualmente da entrambe le Parti contraenti a ogni estremità.
Ogni elemento dell’infrastruttura TIC deve essere testato individualmente in en- trambe le estremità. Ciò vale anche per ogni singola componente dell’infrastruttura. Queste prove possono essere eseguite automaticamente o manualmente ma devono consentire di verificare che ogni elemento dell’infrastruttura è operativo.
4.2.2. Prove di comunicazione
Queste prove devono essere attivate da ciascuna Parte contraente individualmente e la conclusione delle prove richiede la cooperazione dell’altra estremità.
Una volta resi operativi i singoli elementi, i canali di comunicazione tra i due registri devono essere testati. A tal fine, ciascuna Parte contraente verifica che l’accesso a
Internet funzioni, che siano predisposti i tunnel VPN (o altre reti di trasporto sicure equivalenti) e che sia stabilita la connettività IP da sito a sito. L’accessibilità degli elementi di infrastruttura locali e remoti e la connettività IP dovrebbero quindi essere confermati all’altra estremità.
4.2.3. Prove sull’intero sistema (end-to-end)
Queste prove devono essere effettuate a entrambe le estremità e i risultati devono essere comunicati all’altra Parte contraente.
Una volta testati i canali di comunicazione e ciascuna singola componente di en- trambi i registri, ogni estremità deve predisporre una serie di operazioni simulate e di riconciliazione che siano rappresentative di tutte le funzioni da attuare nell’ambito del collegamento.
4.2.4. Prove di sicurezza
Queste prove devono essere effettuate e/o attivate da entrambe le Parti contraenti all’estremità corrispondente seguendo le indicazioni di cui alle sezioni 5.4 «Linee guida in materia di prove di sicurezza» e 5.5 «Disposizioni in materia di valutazione dei rischi».
Solo dopo la fine delle quattro fasi/blocchi con esiti prevedibili, si può ritenere che il collegamento provvisorio sia operativo.
Risorse destinate alle prove
Ciascuna Parte contraente si avvale di risorse specifiche destinate alle prove (soft- ware e hardware specifici delle infrastrutture TIC) e mette a punto funzioni di prova nel proprio sistema al fine di agevolare la convalida manuale e continua della piatta- forma. Le procedure di prova manuali, effettuate individualmente o in cooperazione, possono essere eseguite in qualsiasi momento dagli amministratori dei registri. L’attivazione dello status operativo è un processo manuale in sé.
È previsto inoltre che la piattaforma effettui controlli automatici a intervalli regolari che mirano a incrementare la disponibilità della piattaforma individuando rapida- mente eventuali problemi a livello di infrastruttura o di software. Il piano di monito- raggio della piattaforma è costituito da due elementi:
– monitoraggio delle infrastrutture TIC: a entrambe le estremità l’infrastruttura sarà monitorata dai fornitori di servizi di infrastruttura TIC. Le prove automatiche riguarderanno i diversi elementi dell’infrastruttura e la disponi- bilità dei canali di comunicazione;
– monitoraggio delle applicazioni: i moduli software del collegamento prov- visorio effettueranno il monitoraggio del sistema di comunicazione a livello di applicazione (manualmente e/o a intervalli regolari) che consentirà di verificare la disponibilità end-to-end del collegamento simulando alcune operazioni.
4.3. Ambienti di accettazione/prova
L’architettura del registro dell’Unione e del registro della Svizzera prevede i tre ambienti seguenti:
– produzione (PROD): questo ambiente contiene dati reali e tratta operazioni effettive;
– accettazione (ACC): questo ambiente contiene dati rappresentativi, fittizi o anonimizzati. Si tratta dell’ambiente in cui i gestori dei sistemi di entrambe le Parti contraenti convalidano i nuovi rilasci di versioni;
– prova (TEST): questo ambiente contiene dati rappresentativi, fittizi o ano- nimizzati. L’accesso è limitato agli amministratori dei registri e l’ambiente è destinato a essere utilizzato da entrambe le Parti contraenti per effettuare prove di integrazione.
A eccezione della VPN (o di una rete equivalente), i tre ambienti sono totalmente indipendenti l’uno dall’altro: l’hardware, il software, le basi di dati, gli ambienti virtuali, gli indirizzi IP e le porte sono configurati e funzionano in modo indipenden- te gli uni dagli altri.
La VPN è caratterizzata da due configurazioni per due ambienti diversi, una per l’ambiente PROD e un’altra indipendente per gli ambienti ACC e TEST.
5. Disposizioni in materia di riservatezza e integrità
I meccanismi e le procedure di sicurezza prevedono un metodo con due persone («principio del doppio controllo») per le operazioni effettuate nell’ambito del colle- gamento tra il registro dell’Unione e il registro svizzero. Il metodo del doppio con- trollo si applica ogniqualvolta sia necessario, ma probabilmente non a tutte le azioni intraprese dagli amministratori dei registri.
I requisiti di sicurezza sono esaminati e trattati nel piano di gestione della sicurezza, che comprende anche i processi relativi alla gestione degli incidenti di sicurezza a seguito di un’eventuale violazione della sicurezza. La parte operativa di questi processi è descritta nelle POC.
5.1. Infrastruttura per le prove di sicurezza
Ciascuna Parte contraente si impegna a predisporre un’infrastruttura destinata alle prove di sicurezza (avvalendosi dell’insieme comune di software e hardware utiliz- zati per individuare le vulnerabilità nella fase di sviluppo e funzionamento):
– separata dall’ambiente di produzione;
– in cui la sicurezza è analizzata da un’équipe indipendente dallo sviluppo e dal funzionamento del sistema.
Le Parti contraenti si impegnano a effettuare analisi sia statiche che dinamiche.
Nel caso di analisi dinamiche (come i test di penetrazione), entrambe le Parti con- traenti si impegnano di norma a limitare le valutazioni agli ambienti di prova e di accettazione (definiti nella sezione 4.3 «Ambienti di accettazione/prova»). Le even- tuali deroghe sono soggette all’approvazione di entrambe le Parti contraenti.
Prima di essere utilizzato nell’ambiente di produzione, ogni modulo di software del collegamento (definito nella sezione 3.1 «Architettura del collegamento di comuni- cazione») è sottoposto a prove di sicurezza.
L’infrastruttura per le prove deve essere separata sia a livello di rete che di infra- struttura dall’infrastruttura di produzione. Le prove di sicurezza necessarie per veri- ficare la conformità ai requisiti di sicurezza sono effettuate nell’ambito dell’infra- struttura per le prove.
5.2. Disposizioni relative alla sospensione e alla riattivazione del collegamento
Qualora si sospetti che la sicurezza del registro svizzero, dell’SSTL, del registro dell’Unione o dell’EUTL sia stata compromessa, ciascuna Parte contraente informa l’altra Parte contraente immediatamente e sospende il collegamento tra l’SSTL e l’EUTL.
Le procedure per la condivisione delle informazioni, per la decisione di sospen- dere e per la decisione di riattivare fanno parte del processo per il disbrigo delle richieste delle POC.
Sospensioni
La sospensione del collegamento dei registri conformemente all’allegato II dell’ac- cordo può avvenire per:
– ragioni amministrative (per esempio, manutenzione), programmate;
– ragioni di sicurezza (o guasti dell’infrastruttura IT), non previste.
In caso di emergenza, ciascuna Parte contraente informa l’altra Parte contraente e sospende unilateralmente il collegamento dei registri.
Se si decide di sospendere il collegamento dei registri, ciascuna Parte contraente provvederà a interrompere il collegamento a livello di rete (bloccando in parte o in toto le connessioni in entrata e in uscita).
La decisione di sospendere il collegamento dei registri, sia essa programmata o no, sarà adottata secondo la procedura per la gestione delle modifiche o la procedura per la gestione degli incidenti di sicurezza delle POC.
Riattivazione della comunicazione
Una decisione di riattivazione del collegamento dei registri sarà adottata come specificato nelle POC e, in ogni caso, non potrà essere attuata prima di aver portato a termine con successo le procedure riguardanti prove di sicurezza, come specificato nelle sezioni 5.4 «Linee guida in materia di prove di sicurezza» e 4.2 «Piano di attivazione, comunicazione, riattivazione e prove».
5.3. Disposizioni in materia di violazioni della sicurezza
Una violazione della sicurezza è considerata un incidente di sicurezza che incide sulla riservatezza e l’integrità delle informazioni riservate e/o sulla disponibilità del sistema di trattamento di tali informazioni.
Le informazioni riservate sono identificate nell’elenco delle informazioni riservate e possono essere trattate nel sistema o in qualsiasi parte del sistema a esso correlata.
Le informazioni direttamente connesse alla violazione della sicurezza saranno con- siderate riservate, contrassegnate come informazioni ETS riservatissime (ETS CRITICAL) e trattate secondo le istruzioni di trattamento, salvo diversamente speci- ficato.
Tutte le violazioni della sicurezza saranno gestite secondo le procedure di cui al capitolo «Gestione degli incidenti di sicurezza» delle POC.
5.4. Linee guida in materia di prove di sicurezza
5.4.1. Software
Le prove di sicurezza, compresi gli eventuali test di penetrazione, devono essere eseguite quanto meno per tutti i nuovi principali rilasci di versioni del software, conformemente alle disposizioni in materia di sicurezza definiti nelle NTC, al fine di valutare la sicurezza del collegamento e i relativi rischi.
Se negli ultimi 12 mesi non è stato effettuato nessun rilascio importante di nuove versioni, è necessario effettuare prove di sicurezza sul sistema attuale, tenendo conto dell’evoluzione delle minacce informatiche verificatesi negli ultimi 12 mesi.
Le prove di sicurezza del collegamento del registro saranno effettuate nell’ambiente di accettazione e, se necessario, nell’ambiente di produzione, in coordinamento e con l’accordo di entrambe le Parti contraenti.
Le prove sulle applicazioni web saranno eseguite conformemente agli standard aperti internazionali come quelli messi a punto dall’OWASP (Open Web Applica- tion Security Project).
5.4.2. Infrastruttura
Le infrastrutture alla base del sistema di produzione devono essere controllate perio- dicamente (almeno una volta al mese) al fine di individuare eventuali vulnerabilità. Le prove devono essere effettuate secondo il metodo di cui alla sezione 5.4.1, utiliz- zando una banca dati aggiornata relativa alle vulnerabilità.
5.5. Disposizioni in materia di valutazione dei rischi
Se occorre effettuare test di penetrazione, questi devono essere inclusi nelle prove di sicurezza.
Ogni Parte contraente può affidare a una società specializzata l’esecuzione di prove di sicurezza, a condizione che questa:
– vanti competenze ed esperienza in questo settore;
– non faccia riferimento direttamente allo sviluppatore e/o al suo contraente, e non sia coinvolta nello sviluppo del software del collegamento né sia una subappaltatrice dello sviluppatore;
– abbia firmato un accordo di non divulgazione con cui si impegna a garantire la riservatezza dei risultati e a trattarli quali informazioni ETS riservatissime (ETS CRITICAL) conformemente alle istruzioni di trattamento.