CELEX:32024D1873: Decizia (UE) 2024/1873 a Consiliului din 24 iunie 2024 privind poziția care urmează să fie adoptată în numele Uniunii Europene în cadrul comitetului mixt constituit prin Acordul dintre Uniunea Europeană și Confederația Elvețiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră, în ceea ce privește modificarea anexei II la acord și a procedeelor comune de funcționare și a standardelor tehnice de creare a legăturiiText cu relevanță pentru SEE.

ANEXA I

ANEXA II

PROCEDEELE COMUNE DE FUNCȚIONARE ÎN TEMEIUL ARTICOLULUI 3 ALINEATUL (6) DIN ACORDUL DINTRE UNIUNEA EUROPEANĂ ȘI CONFEDERAȚIA ELVEȚIANĂ PENTRU CREAREA UNEI LEGĂTURI ÎNTRE RESPECTIVELE LOR SCHEME DE COMERCIALIZARE A CERTIFICATELOR DE EMISII DE GAZE CU EFECT DE SERĂ

Proceduri pentru legătura permanentă între registre

Cuprins

1.   GLOSAR

Tabelul 1-1 Acronime și definiții

2.   INTRODUCERE

Acordul dintre Uniunea Europeană și Confederația Elvețiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 23 noiembrie 2017 (denumit în continuare „acordul”) prevede recunoașterea reciprocă a certificatelor de emisii care pot fi utilizate pentru asigurarea conformității în cadrul sistemului de comercializare a certificatelor de emisii (denumit în continuare „EU ETS”) sau în cadrul sistemului Elveției de comercializare a certificatelor de emisii (denumit în continuare „ETS-ul Elveției”). În vederea activării legăturii dintre EU ETS și ETS-ul Elveției, se va crea o legătură directă între Registrul de tranzacții al Uniunii Europene (EUTL) din cadrul registrului Uniunii și Registrul suplimentar de tranzacții al Elveției (SSTL) din cadrul registrului elvețian, ceea ce va permite transferul dintr-un registru în altul al certificatelor de emisii emise în cadrul oricăruia dintre ETS-uri [articolul 3 alineatul (2) din acord]. Pentru a operaționaliza legătura dintre EU ETS și ETS-ul Elveției, în 2020 a fost pusă în aplicare o soluție provizorie. Începând din 2023, legătura dintre cele două sisteme de comercializare a certificatelor de emisii se va transforma treptat într-o legătură permanentă între registre, a cărei implementare este preconizată a avea loc cel târziu în 2024, care va permite funcționarea piețelor legate în ceea ce privește beneficiile oferite de lichiditatea pieței și de executarea tranzacțiilor între cele două sisteme conectate într-un mod echivalent cu o piață formată din două sisteme și care va permite participanților la piață să acționeze ca și cum ar fi pe o singură piață, sub rezerva unor dispoziții de reglementare individuale ale părților (Anexa II la acord).

În temeiul articolului 3 alineatul (6) din acord, administratorul registrului elvețian și administratorul central al Uniunii stabilesc procedeele comune de funcționare pentru aspectele tehnice sau alte aspecte care sunt necesare pentru funcționarea legăturii, ținând cont de prioritățile din legislația națională. Procedeele comune de funcționare elaborate de administratori produc efecte după ce sunt adoptate prin decizia comitetului mixt.

Procedeele comune de funcționare au fost adoptate de comitetul mixt prin Decizia nr. 1/2020. Procedeele comune de funcționare actualizate, astfel cum sunt specificate în prezentul document, vor fi adoptate prin Decizia nr. 1/2024 a comitetului mixt. În conformitate cu prezenta decizie și cu solicitările Comitetului mixt, administratorul registrului elvețian și administratorul central al Uniunii au elaborat și vor actualiza orientări tehnice suplimentare pentru activarea legăturii și pentru a garanta că acestea sunt adaptate permanent la progresul tehnic și la noile cerințe privind siguranța și securitatea legăturii și funcționarea efectivă și eficientă a acesteia.

2.1.   Domeniul de aplicare

Prezentul document reprezintă înțelegerea comună dintre părțile la acord cu privire la stabilirea fundamentelor procedurale ale legăturii dintre registrele EU ETS și ETS-ul Elveției. Acesta prezintă cerințele procedurale generale în ceea ce privește operațiunile, însă vor fi necesare unele orientări tehnice suplimentare pentru activarea legăturii.

Pentru funcționarea corespunzătoare, legătura va necesita specificații tehnice pentru operaționalizarea în continuare a acesteia. În temeiul articolului 3 alineatul (7) din acord, aceste aspecte sunt prezentate în detaliu în documentul privind standardele tehnice de creare a legăturii (LTS), care urmează să fie adoptat separat prin decizia comitetului mixt.

Obiectivul procedeelor comune de funcționare este de a asigura prestarea efectivă și eficientă a serviciilor IT asociate cu funcționarea legăturii dintre registrele EU ETS și ETS al Elveției, în special în ceea ce privește soluționarea cererilor de servicii, rezolvarea cazurilor de întrerupere a serviciului, remedierea problemelor, precum și îndeplinirea sarcinilor operaționale de rutină în conformitate cu standardele internaționale privind gestionarea serviciilor IT.

Pentru legătura permanentă între registre, vor fi necesare doar următoarele procedee comune de funcționare, incluse în prezentul document:

2.2.   Destinatari

Beneficiarii vizați ai prezentelor procedee comune de funcționare sunt echipele de asistență ale registrelor din UE și Elveția.

3.   ABORDARE ȘI STANDARDE

Următorul principiu se aplică tuturor procedeelor comune de funcționare:

4.   GESTIONAREA INCIDENTELOR

Obiectivul procesului de gestionare a incidentelor este de a readuce serviciile IT la un nivel normal cât mai repede posibil și cu o perturbare minimă a activității în urma producerii unui incident.

În cadrul procesului de gestionare a incidentelor ar trebui, de asemenea, să se țină o evidență a incidentelor în scopul raportării, care să fie integrată în alte procese pentru favorizarea unei îmbunătățiri continue.

În general, procesul de gestionare a incidentelor cuprinde următoarele activități:

Pe parcursul ciclului de viață al unui incident, procesul de gestionare a incidentelor este responsabil pentru gestionarea permanentă a drepturilor de proprietate, pentru monitorizare, urmărire și comunicare.

4.1.   Identificarea și înregistrarea incidentelor

Un incident poate fi identificat de un grup de asistență, prin intermediul unor instrumente de monitorizare automatizate sau de către personalul tehnic care asigură supravegherea de rutină.

Odată identificat, un incident trebuie înregistrat, fiindu-i atribuit un identificator unic care permite urmărirea și monitorizarea corespunzătoare a acestuia. Identificatorul unic al unui incident este identificatorul atribuit în sistemul comun de tichete de către serviciul de asistență al părții (fie UE, fie CH) care a semnalat incidentul și trebuie utilizat în toate comunicările referitoare la respectivul incident.

Pentru toate incidentele, punctul de contact ar trebui să fie serviciul de asistență al părții care a introdus tichetul.

4.2.   Clasificarea și asistența inițială

Clasificarea incidentelor are ca scop înțelegerea și identificarea sistemului și/sau a serviciului afectat de un incident și a măsurii în care este afectat acesta. Pentru a fi eficientă, clasificarea ar trebui să direcționeze de prima dată soluționarea incidentului către resursa corectă, pentru a accelera rezolvarea acestuia.

Faza de clasificare ar trebui să includă clasificarea și ierarhizarea incidentului în funcție de impactul și de nivelul de urgență al acestuia, pentru a fi tratat în intervalul de timp stabilit în funcție de priorități.

Dacă incidentul are un potențial impact asupra confidențialității sau integrității datelor sensibile și/sau are un impact asupra disponibilității sistemului, este, de asemenea, declarat drept incident de securitate și, ulterior, va fi gestionat conform procesului definit în capitolul „Gestionarea incidentelor de securitate” din prezentul document.

Dacă este posibil, serviciul de asistență care a introdus tichetul efectuează o diagnosticare inițială. În acest scop, serviciul de asistență va analiza dacă incidentul reprezintă o eroare cunoscută. În caz afirmativ, calea de rezolvare sau soluția alternativă este deja cunoscută și documentată.

Dacă serviciul de asistență reușește să rezolve incidentul, atunci va închide efectiv incidentul în această fază, întrucât scopul principal al procesului de gestionare a incidentelor a fost atins (și anume restaurarea rapidă a serviciului pentru utilizatorul final). În caz contrar, serviciul de asistență va transmite incidentul grupului de rezolvare corespunzător pentru o investigare și o diagnosticare suplimentare.

4.3.   Investigarea și diagnosticarea

Procesul de investigare și diagnosticare a incidentelor se aplică atunci când un incident nu poate fi rezolvat de către serviciul de asistență în cadrul diagnosticării inițiale și, prin urmare, este transmis în mod corespunzător. Transmiterea incidentelor constituie o parte integrantă din procesul de investigare și diagnosticare.

O practică comună în faza de investigare și diagnosticare este încercarea de a recrea incidentul în condiții controlate. Atunci când se efectuează investigarea și diagnosticarea incidentului, este important să se înțeleagă ordinea corectă a evenimentelor care au cauzat incidentul.

Transmiterea reprezintă recunoașterea faptului că un incident nu poate fi rezolvat la nivelul curent de asistență și trebuie transmis unui grup de asistență de nivel superior sau celeilalte părți. Transmiterea poate urma două căi: orizontală (funcțională) sau verticală (ierarhică).

Serviciul de asistență care a înregistrat și a declanșat incidentul este responsabil pentru transmiterea acestuia către resursa corespunzătoare și pentru urmărirea stadiului general și atribuirea incidentului.

Partea căreia i s-a atribuit incidentul este responsabilă pentru asigurarea efectuării în timp util a acțiunilor solicitate și pentru furnizarea de feedbackuri propriului serviciu de asistență.

4.4.   Rezolvarea și restabilirea sistemului

Rezolvarea incidentului și restabilirea sistemului se efectuează după înțelegerea în totalitate a acestuia. Găsirea unei soluții de rezolvare a unui incident înseamnă că a fost identificată o modalitate de a remedia problema. Aplicarea soluției de rezolvare reprezintă faza de restabilire a sistemului.

După remedierea întreruperii serviciului de către resursele corespunzătoare, incidentul este redirecționat către serviciul de asistență competent care a înregistrat incidentul și serviciul respectiv confirmă, împreună cu inițiatorul incidentului, că eroarea a fost remediată și că incidentul poate fi închis. Elementele identificate în timpul procesării incidentului trebuie înregistrate pentru a fi utilizate ulterior.

Restabilirea sistemului poate fi efectuată de către personalul de asistență IT sau prin punerea la dispoziția utilizatorului final a unui set de instrucțiuni care trebuie urmate.

4.5.   Închiderea incidentului

Închiderea este ultima etapă a procesului de gestionare a incidentelor și se efectuează la scurt timp după rezolvarea acestora.

Printre activitățile din lista de verificare care trebuie desfășurate în faza de închidere, se evidențiază următoarele:

Un incident este închis în mod oficial după executarea fazei de închidere a incidentului de către serviciul de asistență și după informarea în acest sens a celeilalte părți.

Odată închis un incident, acesta nu mai este redeschis. Dacă un incident reapare într-un interval scurt de timp, incidentul inițial nu este redeschis, ci trebuie înregistrat un nou incident.

Dacă incidentul este urmărit atât de serviciul de asistență al UE, cât și de cel al CH, responsabilitatea închiderii finale a acestuia îi revine serviciului de asistență care a introdus tichetul.

5.   GESTIONAREA PROBLEMELOR

Această procedură ar trebui urmată ori de câte ori este identificată o problemă și se declanșează procesul de gestionare a problemelor. Procesul de gestionare a problemelor se axează pe îmbunătățirea calității și pe reducerea volumului de incidente semnalate. O problemă poate fi cauza unuia sau a mai multor incidente. Atunci când este raportat un incident, obiectivul procesului de gestionare a incidentelor este de a restabili serviciul cât mai repede posibil, ceea ce poate implica soluții alternative. Atunci când se creează o problemă, obiectivul este de a investiga cauza principală a problemei pentru a identifica o modificare care să garanteze faptul că problema și incidentele conexe nu vor mai apărea.

5.1.   Identificarea și înregistrarea problemelor

În funcție de partea care a introdus tichetul, fie serviciul de asistență al UE, fie cel al CH va fi punctul de contact pentru aspectele legate de problema în cauză.

Identificatorul unic al unei probleme reprezintă identificatorul atribuit de echipa de gestionare a serviciilor IT (ITSM). Acesta trebuie utilizat în toate comunicările referitoare la respectiva problemă.

O problemă poate fi declanșată de un incident sau poate fi deschisă din proprie inițiativă pentru a remedia problemele descoperite în cadrul sistemului în orice moment.

5.2.   Ierarhizarea problemelor

Problemele pot fi clasificate în funcție de gravitatea și prioritatea acestora, în același mod ca incidentele, pentru a facilita urmărirea lor, luând în considerare impactul incidentelor asociate și frecvența de apariție a acestora.

5.3.   Investigarea și diagnosticarea problemelor

Fiecare parte poate semnala o problemă, iar serviciul de asistență al părții inițiatoare va fi responsabil pentru înregistrarea problemei, pentru atribuirea acesteia resursei corespunzătoare și pentru monitorizarea stadiului general al problemei.

Grupul de rezolvare căruia i-a fost transmisă problema este responsabil pentru gestionarea în timp util a acesteia și pentru comunicarea cu serviciul de asistență.

La cerere, ambele părți sunt responsabile pentru asigurarea executării acțiunilor atribuite și pentru transmiterea de feedbackuri propriului serviciu de asistență.

5.4.   Rezoluția

Grupul de rezolvare căruia i se atribuie problema este responsabil pentru soluționarea acesteia și pentru furnizarea de informații relevante propriului serviciu de asistență.

Elementele identificate în timpul procesării problemei trebuie înregistrate pentru a fi utilizate ulterior.

5.5.   Închiderea problemei

O problemă este închisă oficial după soluționarea sa prin implementarea modificării. Faza de închidere a problemei va fi executată de serviciul de asistență care a semnalat problema și a informat în acest sens serviciul de asistență al celeilalte părți.

6.   SOLUȚIONAREA CERERILOR

Procesul de soluționare a cererilor reprezintă gestionarea integrală a unei cereri vizând un serviciu nou sau existent din momentul înregistrării și aprobării acesteia și până la închiderea sa. Cererile de servicii sunt de obicei solicitări minore, predefinite, repetabile, frecvente, aprobate în prealabil și procedurale.

Principalele etape care trebuie parcurse sunt enumerate mai jos.

6.1.   Inițierea cererii

Informațiile cu privire la o cerere de servicii sunt transmise către serviciul de asistență al UE sau al CH prin e-mail, telefon sau prin instrumentul de gestionare a serviciilor IT (ITSM) sau prin orice alt canal de comunicare convenit.

6.2.   Înregistrarea și analiza cererilor

Pentru toate cererile de servicii, punctul de contact ar trebui să fie serviciul de asistență al UE sau al CH, în funcție de partea care a transmis cererea de servicii. Respectivul serviciu de asistență va fi responsabil pentru înregistrarea și analizarea cererii de servicii cu diligența corespunzătoare.

6.3.   Aprobarea cererilor

Agentul din cadrul serviciului de asistență al părții care a transmis cererea de servicii verifică dacă sunt necesare aprobări din partea celeilalte părți și, dacă este cazul, face demersurile necesare pentru obținerea acestora. Dacă cererea de servicii nu este aprobată, serviciul de asistență actualizează și închide tichetul.

6.4.   Soluționarea cererilor

Această etapă se referă la gestionarea efectivă și eficientă a cererilor de servicii. Trebuie să se facă distincție între următoarele cazuri:

Când cererea de servicii a fost soluționată, stadiul acesteia trebuie modificat în „Rezolvată”.

6.5.   Transmiterea cererilor

Serviciul de asistență poate transmite cererea de servicii nesoluționată către resursa corespunzătoare (o terță parte), dacă este necesar.

Transmiterile sunt efectuate către părțile terțe corespunzătoare, și anume serviciul de asistență al UE va trebui să apeleze la serviciul de asistență al CH pentru transmiterea către o terță parte a CH și viceversa.

Terța parte către care a fost transmisă cererea de servicii este responsabilă pentru gestionarea în timp util a cererii de servicii și pentru comunicarea cu serviciul de asistență care a transmis cererea de servicii.

Serviciul de asistență care a înregistrat cererea de servicii este responsabil pentru monitorizarea stadiului general și atribuirea unei cereri de servicii.

6.6.   Verificarea procesului de soluționare a cererii

Serviciul de asistență responsabil supune evidențele privind cererea de servicii unui control al calității final înainte de închiderea cererii. Scopul este de a se asigura că cererea de servicii este efectiv prelucrată și că toate informațiile necesare pentru descrierea ciclului de viață al cererii sunt suficient de detaliate. În plus, elementele identificate în timpul prelucrării cererii trebuie înregistrate pentru a fi utilizate ulterior.

6.7.   Închiderea cererii

Dacă părțile desemnate sunt de acord cu faptul că cererea de servicii a fost soluționată și solicitantul consideră cazul rezolvat, stadiul cererii devine „Închisă”.

O cerere de servicii este oficial închisă după ce serviciul de asistență care a înregistrat cererea de servicii a executat faza de închidere a acesteia și a informat în acest sens serviciul de asistență al celeilalte părți.

7.   GESTIONAREA MODIFICĂRILOR

Obiectivul acestui proces de a asigura faptul că sunt utilizate metode și proceduri standardizate pentru o gestionare eficientă și promptă a tuturor modificărilor legate de controlul infrastructurii IT, în scopul reducerii la minimum a numărului și a impactului oricăror incidente conexe asupra serviciului. Modificări ale infrastructurii IT pot apărea reactiv ca răspuns la probleme sau cerințe impuse din exterior, de exemplu, modificări legislative, sau proactiv, rezultate din încercarea de a îmbunătăți eficiența și eficacitatea ori pentru a permite sau a reflecta inițiative antreprenoriale.

Procesul de gestionare a modificărilor include diferite etape care surprind fiecare detaliu cu privire la o cerere de modificare în vederea monitorizării ulterioare. Aceste procese asigură faptul că modificarea este validată și testată înainte de a fi implementată. Procesul de gestionare a versiunilor este responsabil pentru implementarea cu succes a acestora.

7.1.   Cererea de modificare

O cerere de modificare (RFC) este prezentată echipei de gestionare a modificărilor, pentru validare și aprobare. Pentru toate cererile de modificare, punctul de contact ar trebui să fie serviciul de asistență al UE sau al CH, în funcție de partea care a transmis cererea. Respectivul serviciu de asistență va fi responsabil pentru înregistrarea și analizarea cererii cu diligența corespunzătoare.

Cererile de modificare pot fi determinate de:

7.2.   Evaluarea și planificarea modificărilor

Această etapă implică activitățile de evaluare și de planificare a modificărilor. Aceasta include activități de ierarhizare și de planificare pentru a reduce la minimum riscul și impactul.

Dacă implementarea cererii de modificare afectează atât UE, cât și CH, partea care a înregistrat cererea de modificare verifică împreună cu cealaltă parte procesul de evaluare și de planificare a modificărilor.

7.3.   Aprobările modificărilor

Orice cerere de modificare înregistrată trebuie să fie aprobată de nivelul de transmitere competent.

7.4.   Implementarea modificărilor

Implementarea modificărilor este operată în cadrul procesului de gestionare a versiunilor. Echipele de gestionare a versiunilor ale ambelor părți urmează propriile procese care implică planificarea și testarea. Revizuirea modificărilor se efectuează după ce modificarea a fost implementată. Pentru a asigura aplicarea modificărilor conform planului, procesul de gestionare a modificărilor este revizuit și actualizat în mod constant, dacă este necesar.

8.   GESTIONAREA VERSIUNILOR

O versiune reprezintă una sau mai multe modificări ale unui serviciu IT, incluse într-un plan de lansare a versiunii, care vor trebui autorizate, pregătite, concepute, testate și implementate în același timp. O versiune poate reprezenta remedierea unor erori, o modificare a hardware-ului sau a altor componente, modificări ale software-ului, actualizări ale versiunilor de aplicații, modificări ale documentației și/sau ale unor procese. Conținutul fiecărei versiuni este gestionat, testat și implementat ca un tot unitar.

Procesul de gestionare a versiunilor vizează planificarea, conceperea, testarea și validarea, precum și asigurarea capacității de furnizare a serviciilor concepute, care să răspundă cerințelor părților interesate și să îndeplinească obiectivele propuse. Criteriile de acceptare pentru toate modificările aduse serviciului vor fi definite și documentate pe parcursul etapei de coordonare a procesului de concepere și vor fi furnizate echipelor de gestionare a versiunilor.

Versiunea va consta, în mod obișnuit, dintr-o serie de soluționări de probleme și de îmbunătățiri aduse unui serviciu. Aceasta conține software-ul nou sau modificat necesar și orice hardware nou sau modificat necesar pentru implementarea modificărilor aprobate.

8.1.   Planificarea versiunii

Prima etapă a procesului include alocarea modificărilor autorizate pachetelor de versiuni și definirea domeniului de aplicare și a conținutului versiunilor. Pe baza acestor informații, în cadrul subprocesului de planificare a versiunilor se elaborează un calendar pentru conceperea, testarea și implementarea versiunii.

În cadrul planificării ar trebui definite următoarele:

Ambele părți se informează reciproc cu privire la perioadele de planificare și de întreținere a versiunii. Dacă o versiune afectează atât UE, cât și CH, acestea coordonează etapa de planificare și definesc o perioadă comună pentru întreținere.

8.2.   Conceperea și testarea pachetului de versiuni

Etapa de concepere și de testare a procesului de gestionare a versiunilor stabilește abordarea privind executarea versiunii sau a pachetului de versiuni și menținerea mediilor controlate înainte de modificarea producției, precum și testarea tuturor modificărilor din toate mediile lansate.

Dacă o versiune afectează atât UE, cât și CH, acestea coordonează planurile de livrare și testele. Acestea includ următoarele aspecte:

La finalul acestui subproces, toate componentele necesare ale versiunii sunt pregătite pentru faza de implementare concretă.

8.3.   Pregătirea implementării

Subprocesul de pregătire asigură faptul că planurile de comunicare sunt corect definite, că notificările pot fi trimise tuturor părților interesate și utilizatorilor finali afectați și că versiunea este integrată în procesul de gestionare a modificărilor pentru a asigura faptul că toate modificările sunt efectuate într-un mod controlat și sunt aprobate de forurile competente.

Dacă o versiune afectează atât UE, cât și CH, acestea coordonează următoarele activități:

8.4.   Readucerea versiunii la starea anterioară

În cazul unei implementări nereușite sau în cazul în care, pe parcursul testării, s-a constatat că implementarea a fost nereușită sau nu a îndeplinit criteriile de acceptare/calitate convenite, echipele de gestionare a versiunii ale ambelor părți vor trebui să readucă versiunea la starea anterioară. Toate părțile interesate relevante vor trebui informate, inclusiv utilizatorii finali afectați/vizați. În așteptarea aprobării, procesul poate reporni în oricare dintre etapele anterioare.

8.5.   Evaluarea și finalizarea versiunii

În evaluarea implementării unei versiuni ar trebui incluse următoarele activități:

9.   GESTIONAREA INCIDENTELOR DE SECURITATE

Gestionarea incidentelor de securitate este un proces de gestionare a incidentelor de securitate pentru a permite comunicarea incidentelor părților interesate potențial afectate, evaluarea și ierarhizarea incidentelor și răspunsul la incidente în vederea soluționării oricărei încălcări reale, suspectate sau potențiale a confidențialității, a disponibilității sau a integrității activelor informaționale sensibile.

9.1.   Clasificarea incidentelor de securitate a informațiilor

Toate incidentele care afectează legătura dintre registrul Uniunii și registrul elvețian sunt analizate pentru a stabili o posibilă încălcare a confidențialității, a integrității sau a disponibilității oricărei informații sensibile înregistrate în Evidența informațiilor sensibile (SIL).

În acest caz, incidentul este caracterizat ca incident de securitate a informațiilor, este înregistrat imediat în instrumentul de gestionare a serviciilor IT (ITSM) și gestionat ca atare.

9.2.   Gestionarea incidentelor de securitate a informațiilor

Incidentele de securitate se află în responsabilitatea celui de al treilea nivel de transmitere, iar de rezolvarea acestora se va ocupa o echipă specială de gestionare a incidentelor (IMT).

IMT este responsabilă cu:

În cadrul procesului de management al securității informațiilor, toate informațiile referitoare la incidente sunt clasificate la cel mai înalt nivel de sensibilitate a informațiilor, dar în orice caz nu la un nivel mai mic decât nivelul SENSITIVE: ETS.

În cazul unei investigări în curs și/sau al unui punct slab care ar putea fi exploatat și până la remedierea acestuia, informațiile sunt clasificate drept SPECIAL HANDLING: ETS Critical.

9.3.   Identificarea incidentelor de securitate

În funcție de tipul de eveniment de securitate, responsabilul cu securitatea informațiilor stabilește organizațiile competente care trebuie implicate și care vor face parte din echipa de gestionare a incidentelor.

9.4.   Analiza incidentelor de securitate

IMT asigură legătura cu toate organizațiile implicate și, după caz, cu membrii relevanți ai echipelor acestora în vederea analizării incidentului. În cadrul analizei, se identifică amploarea pierderii confidențialității, integrității sau disponibilității unui activ și se evaluează consecințele pentru toate organizațiile afectate. În continuare, sunt definite măsurile inițiale și subsecvente pentru rezolvarea incidentului și gestionarea impactului acestuia, inclusiv a impactului acestor măsuri asupra resurselor.

9.5.   Evaluarea gravității incidentelor de securitate, transmiterea și raportarea acestora

IMT evaluează gravitatea fiecărui incident de securitate nou după încadrarea acestuia ca incident de securitate și ia imediat măsurile necesare în funcție de gravitatea acestuia.

9.6.   Raportarea răspunsurilor la incidentele de securitate

IMT include în raportul de răspuns la incidentele de securitate a informațiilor rezultatele privind izolarea incidentului și restabilirea sistemului. Raportul este transmis până la nivelul al treilea de transmitere prin intermediul unui e-mail securizat sau prin intermediul altor mijloace de comunicare securizate, acceptate de ambele părți.

Partea responsabilă analizează rezultatele privind izolarea incidentului și restabilirea sistemului și:

În raportul privind incidentele de securitate a informațiilor, IMT ar trebui să includă – într-o manieră securizată – detalii relevante pentru a asigura înregistrarea coerentă și comunicarea și pentru a permite luarea unor măsuri prompte și adecvate pentru izolarea incidentului. După finalizarea acestuia, IMT transmite în timp util raportul final privind incidentul de securitate a informațiilor.

9.7.   Monitorizarea, consolidarea capacităților și îmbunătățirea continuă

IMT va furniza rapoarte pentru toate incidentele de securitate până la nivelul al treilea de transmitere. Rapoartele vor fi utilizate la acest nivel de transmitere pentru a stabili următoarele:

10.   MANAGEMENTUL SECURITĂȚII INFORMAȚIILOR

Managementul securității informațiilor vizează asigurarea confidențialității, a integrității și a disponibilității informațiilor și datelor clasificate, precum și a serviciilor IT ale unei organizații. Pe lângă componentele tehnice, inclusiv conceperea și testarea acestora (a se vedea LTS), sunt necesare următoarele procedee comune de funcționare în vederea îndeplinirii cerințelor de securitate pentru legătura permanentă între registre.

10.1.   Identificarea informațiilor sensibile

Nivelul de sensibilitate al unei informații este evaluat prin stabilirea nivelului impactului asupra activității (de exemplu, pierderi financiare, afectarea imaginii, încălcări ale legii etc.) pe care l-ar putea avea o încălcare a securității respectivelor informații.

Activele informaționale sensibile sunt identificate pe baza impactului lor asupra legăturii.

Nivelul de sensibilitate al acestor informații este evaluat în funcție de scala de sensibilitate aplicabilă pentru această legătură și este prezentat în detaliu în secțiunea „Gestionarea incidentelor de securitate a informațiilor” din prezentul document.

10.2.   Nivelurile de sensibilitate ale activelor informaționale

După identificarea sa, activul informațional este clasificat aplicând următoarele reguli:

10.3.   Desemnarea proprietarului activelor informaționale

Toate activele informaționale ar trebui să aibă un proprietar desemnat. Activele informaționale ale ETS, care aparțin legăturii dintre EUTL și SSTL sau se referă la aceasta ar trebui incluse într-o listă comună de inventariere a activelor, menținută de ambele părți. Activele informaționale ale ETS din afara legăturii dintre EUTL și SSTL ar trebui incluse într-o listă de inventariere a activelor, menținută de partea corespunzătoare.

Dreptul de proprietate asupra fiecărui activ informațional care aparține legăturii dintre EUTL și SSTL sau se referă la aceasta va fi convenit de către părți. Proprietarul unui activ informațional este responsabil pentru evaluarea nivelului de sensibilitate al acestuia.

Proprietarul ar trebui să aibă un nivel de responsabilitate corespunzător valorii activului (activelor) atribuit(e). Responsabilitatea proprietarului în ceea ce privește activul (activele), precum și obligația acestuia de a menține nivelul de confidențialitate, integritate și disponibilitate necesare ar trebui să fie convenite și oficializate.

10.4.   Înregistrarea informațiilor sensibile

Toate informațiile sensibile sunt înregistrate în Evidența informațiilor sensibile (SIL).

Dacă este cazul, agregarea unor informații sensibile care ar putea avea un impact mai mare decât impactul unei singure informații trebuie luată în considerare și înregistrată în SIL (de exemplu, un set de informații stocate în baza de date a sistemului).

SIL nu este statică. Amenințările, vulnerabilitățile, probabilitatea sau consecințele incidentelor de securitate legate de active se pot schimba fără nicio indicație și pot fi introduse active noi în operarea sistemele registrelor.

Prin urmare, SIL trebuie revizuită periodic și toate informațiile noi considerate ca fiind sensibile trebuie înregistrate imediat în SIL.

SIL conține cel puțin următoarele informații pentru fiecare înregistrare:

10.5.   Gestionarea informațiilor sensibile

Atunci când sunt prelucrate în afara legăturii dintre registrul Uniunii și registrul elvețian, informațiile sensibile sunt gestionate în conformitate cu Instrucțiunile de gestionare.

Informațiile sensibile prelucrate prin intermediul legăturii dintre registrul Uniunii și registrul elvețian sunt gestionate de către părți în conformitate cu cerințele în materie de securitate.

10.6.   Gestionarea accesului

Obiectivul procesului de management al accesului este de a acorda utilizatorilor autorizați dreptul de a utiliza un serviciu, împiedicând în același timp accesul utilizatorilor neautorizați. Managementul accesului este uneori denumit și „managementul drepturilor” sau „managementul identității”.

Pentru legătura permanentă între registre și funcționarea acesteia, ambele părți au nevoie de acces la următoarele componente:

Administratorul registrului elvețian și administratorul central al Uniunii se asigură că accesurile sunt actualizate și funcționează ca puncte de contact pentru părțile lor în cadrul activităților de management al accesului. Cererile de acces sunt gestionate conform procedurilor de soluționare a cererilor.

10.7.   Gestionarea certificatelor/cheilor

Fiecare parte răspunde de gestionarea propriilor certificate/chei (generare, înregistrare, stocare, instalare, utilizare, reînnoire, revocare, realizarea de copii de rezervă și recuperarea certificatelor/cheilor). Conform standardelor tehnice de creare a legăturii (LTS), se utilizează numai certificate digitale emise de o autoritate de certificare (CA) acceptată de ambele părți. Gestionarea și stocarea certificatelor/cheilor trebuie să respecte dispozițiile din Instrucțiunile de gestionare.

Orice revocare și/sau reînnoire a certificatelor și a cheilor este coordonată de ambele părți. Aceasta se realizează conform procedurilor de soluționare a cererilor.

Administratorul registrului elvețian și administratorul central al Uniunii vor face schimb de certificate/chei prin mijloace de comunicare securizate în conformitate cu dispozițiile din Instrucțiunile de gestionare.

Orice verificare a certificatelor/cheilor prin orice mijloc între părți se va realiza în afara benzii.

ANEXA III

STANDARDE TEHNICE DE CREARE A LEGĂTURII (LTS) ÎN TEMEIUL ARTICOLULUI 3 ALINEATUL (7) DIN ACORDUL DINTRE UNIUNEA EUROPEANĂ ȘI CONFEDERAȚIA ELVEȚIANĂ PENTRU CREAREA UNEI LEGĂTURI ÎNTRE RESPECTIVELE LOR SCHEME DE COMERCIALIZARE A CERTIFICATELOR DE EMISII DE GAZE CU EFECT DE SERĂ

Standarde pentru legătura permanentă între registre

Cuprins

1.   GLOSAR

Tabelul 1-1 Acronime și definiții comerciale

Tabelul 1-2 Acronime și definiții tehnice

2.   INTRODUCERE

Acordul dintre Uniunea Europeană și Confederația Elvețiană pentru crearea unei legături între respectivele lor scheme de comercializare a certificatelor de emisii de gaze cu efect de seră din 23 noiembrie 2017 (denumit în continuare „acordul”) prevede recunoașterea reciprocă a certificatelor de emisii care pot fi utilizate pentru asigurarea conformității în cadrul sistemului de comercializare a certificatelor de emisii (denumit în continuare „EU ETS”) sau în cadrul sistemului Elveției de comercializare a certificatelor de emisii (denumit în continuare ETS-ul Elveției). În vederea activării legăturii dintre EU ETS și ETS-ul Elveției, se va crea o legătură directă între Registrul de tranzacții al Uniunii Europene (EUTL) din cadrul registrului Uniunii și Registrul suplimentar de tranzacții al Elveției (SSTL) din cadrul registrului elvețian, ceea ce va permite transferul dintr-un registru în altul al certificatelor de emisii emise în cadrul oricăruia dintre ETS-uri [articolul 3 alineatul (2) din acord]. Pentru a operaționaliza legătura dintre EU ETS și ETS-ul Elveției, în 2020 a fost pusă în aplicare o soluție provizorie. Începând din 2023, legătura dintre cele două sisteme de comercializare a certificatelor de emisii se va transforma treptat într-o legătură permanentă între registre, a cărei implementare este preconizată a avea loc cel târziu în 2024, care va permite funcționarea piețelor legate în ceea ce privește beneficiile oferite de lichiditatea pieței și de executarea tranzacțiilor între cele două sisteme conectate într-un mod echivalent cu o piață formată din două sisteme și care va permite participanților la piață să acționeze ca și cum ar fi pe o singură piață, sub rezerva unor dispoziții de reglementare individuale ale părților (anexa II la acord).

În conformitate cu articolul 3 alineatul (7) din acord, administratorul registrului elvețian și administratorul central al Uniunii stabilesc standardele tehnice de creare a legăturii (LTS) pe baza principiilor prevăzute în anexa II la acord, în care sunt descrise în detaliu cerințele pentru stabilirea unei legături robuste și securizate între SSTL și EUTL. Standardele tehnice de creare a legăturii elaborate de administratori produc efecte după ce sunt adoptate printr-o decizie a comitetului mixt.

LTS a fost adoptată de comitetul mixt prin Decizia nr. 2/2020. Procedeele comune de funcționare actualizate, astfel cum sunt specificate în prezentul document, vor fi adoptate prin Decizia nr. 1/2024 a comitetului mixt. În conformitate cu prezenta decizie și cu solicitările Comitetului mixt, administratorul registrului elvețian și administratorul central al Uniunii au elaborat și vor actualiza orientări tehnice suplimentare pentru activarea legăturii și pentru a garanta că acestea sunt adaptate permanent la progresul tehnic și la noile cerințe privind siguranța și securitatea legăturii și funcționarea efectivă și eficientă a acesteia.

2.1.   Domeniul de aplicare

Prezentul document reprezintă înțelegerea comună între părțile la acord cu privire la stabilirea fundamentelor tehnice ale legăturii dintre registrele EU ETS și ETS-ul Elveției. Deși documentul pune bazele specificațiilor tehnice în ceea ce privește cerințele privind arhitectura, serviciile și securitatea, vor fi necesare unele orientări suplimentare detaliate pentru activarea legăturii.

Pentru funcționarea sa corespunzătoare, legătura va necesita procese și procedee pentru operaționalizarea în continuare a acesteia. În conformitate cu articolul 3 alineatul (6) din acord, aceste aspecte sunt prezentate în detaliu într-un document separat privind procedeele comune de funcționare, care urmează să fie adoptat separat prin decizia comitetului mixt.

2.2.   Destinatari

Prezentul document se adresează administratorului registrului elvețian și administratorului central al Uniunii.

3.   DISPOZIȚII GENERALE

3.1.   Arhitectura legăturii de comunicare

Scopul prezentei secțiuni este de a oferi o descriere a arhitecturii generale a activării legăturii dintre EU ETS și ETS-ul Elveției și a diferitelor componente implicate în aceasta.

Având în vedere faptul că securitatea reprezintă un element-cheie pentru definirea arhitecturii legăturii dintre registre, au fost luate toate măsurile pentru crearea unei arhitecturi robuste. Legătura permanentă între registre utilizează un mecanism de schimb de fișiere, ca implementare a unei conexiuni securizate Air Gap.

Soluția tehnică utilizează:

3.1.1.   Schimbul de mesaje

Comunicarea dintre registrul Uniunii și registrul elvețian se bazează pe un mecanism de schimb de mesaje prin intermediul unor canale securizate. Fiecare parte se bazează pe propriul sistem de colectare a mesajelor primite.

Ambele părți țin o evidență a mesajelor primite, împreună cu detaliile procesărilor.

Erorile sau situațiile neașteptate trebuie raportate, sub formă de alerte, și ar trebui să aibă loc contactul uman între echipele de asistență.

3.1.2.   Mesaj XML – Descriere de nivel înalt

Un mesaj XML conține unul dintre următoarele elemente:

Fiecare mesaj conține un antet care include:

3.1.3.   Ferestre de ingerare (Ingestion Windows)

Legătura permanentă între registre se bazează pe ferestre de ingerare predefinite care sunt urmate de un set de evenimente cu nume. Cererile de tranzacții primite prin intermediul legăturii vor fi ingerate numai la intervale predefinite. Ferestrele de ingerare includ o validare tehnică pentru tranzacțiile efectuate și primite. În plus, reconcilierile pot fi derulate zilnic și declanșate manual.

3.1.4.   Fluxurile de mesaje privind tranzacțiile

Tranzacțiile efectuate

Reflectă punctul de vedere al ETS-ului care efectuează transferul. Fluxul specific este prezentat în următoarea diagramă de secvență:

Fluxul principal prezintă următoarele etape (la fel ca în desenul de mai sus):

Flux alternativ „Respingerea registrului de tranzacții” [astfel cum este indicat în desenul de mai sus, începând de la litera (a) din fluxul principal]:

Debit alternativ „Respingere ETS” [astfel cum este prezentat în desenul de mai sus, începând de la litera (d) în fluxul principal]:

Tranzacțiile primite

Aceasta reflectă punctul de vedere al ETS-ului de destinație. Fluxul specific este prezentat în următoarea diagramă de secvență:

În diagramă se indică următoarele:

Protocol

Ciclul mesajelor privind tranzacțiile implică doar două mesaje:

Stadiul tranzacției

3.2.   Securitatea transferurilor de date

Datele aflate în tranzit vor face obiectul a patru niveluri de securitate:

3.2.1.   Firewall și interconectarea între rețele

Legătura este stabilită prin intermediul unei rețele protejate de un firewall pe bază de hardware. Firewall-ul este configurat cu reguli potrivit cărora doar clienții „înregistrați” să se poată conecta la serverul VPN.

3.2.2.   Rețea virtuală privată (VPN)

Toate comunicările dintre părți sunt protejate cu ajutorul unei tehnologii cu rețea virtuală privată (VPN). Tehnologiile VPN oferă posibilitatea „transportului” dintr-un punct în altul printr-o rețea precum internetul, protejând toate comunicațiile. Înainte de crearea tunelului VPN, un certificat digital este transmis către punctul final al unui potențial client, permițând clientului să furnizeze dovada identității pe parcursul negocierii legăturii. Fiecare parte este responsabilă pentru instalarea certificatului în propriul punct final VPN. Utilizând certificate digitale, fiecare server VPN final va accesa o autoritate centrală pentru a negocia acreditările de autentificare. Pe parcursul procesului de creare a tunelului, se negociază criptarea, asigurând protejarea tuturor comunicațiilor efectuate prin intermediul tunelului.

Punctele finale VPN ale clienților sunt configurate pentru a menține în permanență tunelul VPN, pentru a permite în orice moment o comunicare fiabilă, bidirecțională și în timp real între părți.

În general, Uniunea Europeană utilizează serviciile transeuropene securizate de telematică între administrații (STESTA) ca rețea privată bazată pe IP. Prin urmare, această rețea este adecvată și pentru legătura permanentă între registre.

3.2.3.   Implementarea IPSec

Utilizarea protocolului IPSec pentru formarea infrastructurii VPN site-to-site va asigura autentificarea site-to-site, integritatea datelor și criptarea acestora. Configurațiile VPN care includ protocoale IPSec asigură o autentificare corectă între două puncte finale în cazul unei conexiuni VPN. Părțile vor identifica și autentifica clientul de la distanță prin conexiunea IPSec utilizând un certificat digital emis de o autoritate de certificare recunoscută de cealaltă parte.

Protocolul IPSec asigură, de asemenea, integritatea datelor pentru toate comunicațiile efectuate prin intermediul tunelului VPN. Pachetele de date sunt trunchiate și semnate utilizând informațiile de autentificare stabilite prin VPN. Confidențialitatea datelor este asigurată și prin activarea criptării IPSec.

3.2.4.   Protocol de transfer securizat pentru schimburile de mesaje

Legătura permanentă între registre se bazează pe mai multe niveluri de criptare pentru schimbul securizat de date între părți. Ambele sisteme și mediile lor diferite sunt interconectate la nivelul rețelei prin intermediul unor tuneluri VPN. La nivel de aplicație, fișierele sunt transferate cu ajutorul unui protocol de transfer securizat pentru schimburile de mesaje la nivel de sesiune.

3.2.5.   Criptare și semnătură bazate pe XML

În fișierele XML, semnarea și criptarea se realizează la două niveluri. Fiecare cerere de tranzacție, răspuns la o tranzacție și mesaj de reconciliere se semnează digital, în mod individual.

Într-o a doua etapă, fiecare subelement al elementului „mesaj” este criptat individual.

În plus, ca o a treia etapă și pentru a asigura integritatea și non-repudierea întregului mesaj, mesajul elementului rădăcină este semnat digital. Acesta conduce la un nivel ridicat de protecție pentru datele încorporate în format XML. Implementarea tehnică respectă standardele consorțiului World Wide Web.

Pentru a decripta și a verifica mesajul, procesul este efectuat în ordine inversă.

3.2.6.   Chei criptografice

Criptografia cu chei publice va fi utilizată pentru criptare și semnare.

Pentru cazul specific al IPSec, se va utiliza un certificat digital emis de o autoritate de certificare (CA) acceptată de ambele părți. Respectiva autoritate de certificare verifică identitatea deținătorului certificatului și emite certificate care sunt utilizate pentru a identifica pozitiv o organizație și a configura canale de comunicații de date securizate între părți.

3.3.   Lista funcțiilor în cadrul legăturii

Legătura specifică sistemul de transmisie pentru o serie de funcții care implementează procesele comerciale prevăzute în acord. Legătura include, de asemenea, specificația pentru procesul de reconciliere și pentru mesajele test care vor permite implementarea unei monitorizări a ritmicității.

3.3.1.   Tranzacțiile comerciale

Din perspectivă comercială, legătura include patru (4) tipuri de cereri de tranzacții:

3.3.2.   Protocolul reconcilierilor

Reconcilierile vor avea loc numai după închiderea ferestrei pentru ingerarea, validarea și procesarea mesajelor.

Reconcilierile sunt o parte integrantă a măsurilor privind securitatea și coerența legăturii. Ambele părți vor conveni asupra momentului exact al reconcilierii înainte de elaborarea oricărui calendar. O reconciliere zilnică programată se poate realiza doar cu acordul ambelor părți. Cel puțin o reconciliere programată va fi executată în orice caz după efectuarea operațiunii de ingerare.

În orice caz, oricare dintre părți poate să inițieze în orice moment reconcilieri manuale.

3.3.3.   Mesaj test

Un mesaj test este prevăzut pentru a testa comunicarea de la un capăt la celălalt capăt. Mesajul va conține date care vor identifica mesajul drept test și va primi un răspuns după primirea sa la celălalt capăt.

3.4.   Cerințe privind înregistrarea datelor

Pentru a răspunde nevoii ambelor părți de a păstra informații corecte și coerente și de a furniza instrumente care să fie utilizate în cadrul procesului de reconciliere pentru remedierea neconcordanțelor, sunt păstrate patru (4) tipuri de evidențe de date de către ambele părți:

Toate datele din registrele respective sunt păstrate pentru o perioadă de cel puțin trei (3) luni în scopul efectuării operațiunilor de depanare, iar păstrarea lor ulterioară va depinde de legislația privind efectuarea auditurilor, aplicabilă la fiecare capăt. Fișierele-jurnal mai vechi de trei (3) luni pot fi arhivate într-o locație securizată într-un sistem IT independent atât timp cât acestea pot fi preluate sau accesate într-o perioadă rezonabilă.

Registrele de tranzacții

Subsistemele EUTL și SSTL sunt implementări ale registrelor de tranzacții.

Mai exact, registrele de tranzacții vor ține o evidență a fiecărei tranzacții propuse trimise celuilalt ETS. Fiecare evidență include toate câmpurile conținutului tranzacției și rezultatul ulterior al tranzacției (răspunsul ETS-ului de destinație). Registrele de tranzacții vor ține și o evidență a tranzacțiilor efectuate, precum și răspunsul trimis ETS-ului de origine.

Registrele de reconcilieri

Registrul de reconcilieri include o evidență a fiecărui mesaj de reconciliere transmis între cele două părți, inclusiv ID-ul reconcilierii, marcajul temporal și rezultatul reconcilierii: Stadiul reconcilierii „Reușită” sau „Discrepanțe”. În cadrul legăturii permanente între registre, mesajele de reconciliere fac parte integrantă din mesajele schimbate și, prin urmare, sunt stocate astfel cum se descrie în secțiunea „Arhiva de mesaje”.

Ambele părți înregistrează fiecare cerere și răspunsul aferent în Registrul de reconcilieri. Cu toate că informațiile din Registrul de reconcilieri nu sunt partajate în mod direct ca parte a reconcilierii în sine, poate fi necesar accesul la respectivele informații pentru a remedia neconcordanțele.

Arhiva de mesaje

Ambele părți au obligația de a arhiva o copie a datelor partajate (fișierele XML), trimise și primite, indiferent dacă respectivele date sau mesajele XML au fost corecte în formatul lor sau nu.

Scopul principal al arhivării este de a avea dovada mesajelor trimise celeilalte părți și primite de la cealaltă parte, pe care să o prezinte în cursul unui audit. În acest scop, împreună cu fișierele, trebuie să fie arhivate și certificatele aferente.

Fișierele respective vor oferi, de asemenea, informații suplimentare pentru operațiunile de depanare.

Registrele de evidență a auditurilor interne

Aceste registre sunt definite și utilizate individual de către fiecare parte.

3.5.   Cerințele operaționale

Schimbul de date între cele două sisteme nu este complet autonom în cadrul legăturii permanente între registre, ceea ce înseamnă că este nevoie de operatori și de proceduri pentru activarea legăturii. Mai multe roluri și instrumente sunt detaliate în acest scop în cadrul acestui proces.

4.   DISPOZIȚII PRIVIND DISPONIBILITATEA

4.1.   Proiectarea disponibilității comunicațiilor

Arhitectura legăturii permanente între registre este în esență o infrastructură și un software TIC care permite comunicarea între ETS-ul Elveției și EU ETS. Prin urmare, asigurarea unor niveluri ridicate de disponibilitate, integritate și confidențialitate a acestui flux de date devine un aspect esențial de luat în considerare pentru proiectarea legăturii permanente între registre. Fiind un proiect în care infrastructura TIC, software-ul personalizat și procesele joacă un rol fundamental, toate cele trei elemente trebuie luate în considerare pentru proiectarea unui sistem rezilient.

Reziliența infrastructurii TIC

În capitolul privind dispozițiile generale din prezentul document sunt descrise în detaliu elementele constitutive ale arhitecturii. În ceea ce privește infrastructura TIC, legătura permanentă între registre instituie o rețea VPN rezilientă care creează tuneluri de comunicare securizate prin intermediul cărora se pot realiza schimburi de mesaje securizate. Alte elemente de infrastructură sunt configurate cu un grad ridicat de disponibilitate și/sau se bazează pe mecanisme de rezervă.

Reziliența software-ului personalizat

Modulele software personalizate dezvoltate îmbunătățesc reziliența prin reluarea comunicării cu celălalt capăt pentru o anumită perioadă, în cazul în care aceasta nu este disponibilă din anumite motive.

Reziliența serviciilor

În legătura permanentă între registre, schimburile de date dintre părți au loc la intervale predefinite. Unele dintre etapele necesare pentru schimburile de date programate în prealabil necesită intervenția manuală a operatorilor sistemului și/sau a administratorilor registrelor. Luând în considerare acest aspect și pentru a spori gradul de disponibilitate și de reușită a schimburilor:

4.2.   Planul de inițializare, comunicare, reactivare și testare

Toate elementele diferite implicate în arhitectura legăturii permanente între registre fac obiectul unei serii de teste individuale și colective în vederea confirmării faptului că platforma este pregătită la nivelul infrastructurii TIC și a sistemului de informații. Aceste teste de funcționare reprezintă o condiție obligatorie de fiecare dată când platforma tranzitează legătura permanentă între registre de la stadiul de „suspendată” la stadiul de „funcțională”.

Activarea stadiului funcțional al legăturii necesită apoi executarea cu succes a unui plan de testare predefinit. Acesta confirmă faptul că fiecare registru a efectuat mai întâi un set de teste interne, urmat de validarea conectivității între utilizatorii finali înainte de a începe tranzacțiile de producție între cele două părți.

În planul de testare ar trebui să se menționeze strategia generală de testare și detalii privind infrastructura de testare. Planul de testare ar trebui să includă, în special, pentru fiecare element al fiecărui bloc de testare:

Ca proces, testele de activare a stadiului funcțional pot fi împărțite în patru (4) blocuri sau faze conceptuale:

4.2.1.   Testele interne pentru infrastructura TIC

Testele respective trebuie efectuate și/sau verificate individual de către administratorii registrelor la fiecare capăt.

Fiecare element al infrastructurii TIC de la fiecare capăt este testat individual. Acestea includ fiecare componentă a infrastructurii. Aceste teste pot fi executate automat sau manual, însă trebuie să verifice funcționalitatea fiecărui element al infrastructurii.

4.2.2.   Testele de comunicare

Testele respective sunt declanșate individual de către fiecare parte și pentru finalizarea lor este necesară cooperarea celuilalt capăt.

Atunci când fiecare element în parte este funcțional, trebuie testate canalele de comunicare între cele două registre. În acest scop, fiecare parte verifică dacă accesul la internet funcționează, dacă tunelurile VPN sunt stabilite și dacă există conectivitate IP site-to-site. Accesibilitatea elementelor de infrastructură locale și la distanță și conectivitatea IP ar trebui apoi confirmate la celălalt capăt.

4.2.3.   Teste pentru întregul sistem (de la un capăt la celălalt capăt)

Aceste teste trebuie executate la fiecare capăt, iar rezultatele sunt partajate cu cealaltă parte.

După ce au fost testate canalele de comunicare și fiecare componentă a ambelor registre, fiecare capăt va pregăti o serie de simulări de tranzacții și de reconcilieri, reprezentative pentru toate funcțiile care urmează să fie implementate în cadrul legăturii.

4.2.4.   Testele de securitate

Aceste teste trebuie efectuate și/sau declanșate de administratorii registrelor la fiecare capăt și conform specificațiilor prevăzute în secțiunile 5.4, „Orientări privind testarea securității”, și 5.5, „Dispoziții privind evaluarea riscurilor”.

Numai după ce fiecare dintre cele patru faze/blocuri s-a încheiat cu rezultatele scontate, registrul permanent poate fi considerat funcțional.

Resurse de testare

Fiecare parte se bazează pe resurse de testare specifice (software și hardware specifice infrastructurii TIC) și dezvoltă funcții de testare în sistemele lor corespunzătoare pentru a susține validarea manuală și continuă a platformei. Procedurile de testare manuale individuale sau cooperative pot fi executate în orice moment de către administratorii registrelor. Activarea stadiului de funcționare este un proces manual în sine.

Se prevede, de asemenea, ca platforma să efectueze verificări automate la intervale regulate. Aceste verificări vizează creșterea disponibilității platformei prin detectarea din timp a potențialelor probleme legate de infrastructură sau de software. Acest plan de monitorizare a platformei este alcătuit din două elemente:

4.3.   Mediile de acceptare/de testare

Arhitectura registrului Uniunii și a registrului Elveției constă în următoarele trei medii:

Cu excepția VPN, cele trei medii sunt complet independente unele de altele; cu alte cuvinte, hardware-ul, software-ul, bazele de date, mediile virtuale, adresele IP și porturile sunt configurate și funcționează independent unele de altele.

În ceea ce privește configurația VPN, comunicarea dintre cele trei medii trebuie să fie complet independentă, ceea ce este asigurat prin utilizarea STESTA.

5.   DISPOZIȚII PRIVIND CONFIDENȚIALITATEA ȘI INTEGRITATEA

Mecanismele și procedurile de securitate prevăd o metodă pentru două persoane (principiul „celor patru ochi”) pentru operațiunile desfășurate în cadrul legăturii dintre registrul Uniunii și registrul elvețian. Metoda pentru două persoane se aplică ori de câte ori este necesar. Cu toate acestea, nu se poate aplica tuturor etapelor parcurse de administratorii registrelor.

Cerințele de securitate sunt luate în considerare și abordate în planul de gestionare a securității, care include, de asemenea, procese legate de gestionarea incidentelor de securitate ca urmare a unei eventuale încălcări a securității. Partea operațională a acestor procese este descrisă în procedeele comune de funcționare.

5.1.   Infrastructura de testare a securității

Fiecare parte se angajează să creeze o infrastructură de testare a securității (prin utilizarea software-ului și hardware-ului comune utilizate pentru detectarea vulnerabilităților în fazele de dezvoltare și de funcționare):

Fiecare parte se angajează să efectueze atât analize statice, cât și analize dinamice.

În cazul unei analize dinamice (cum ar fi testul de rezistență la intruziuni), ambele părți se angajează să restricționeze evaluările în mod obișnuit la mediile de testare și de acceptare (astfel cum sunt definite în secțiunea 4.3, „Medii de acceptare/de testare”). Excepțiile de la această politică fac obiectul aprobării de către ambele părți.

Înainte de implementarea în mediul de producție, se testează securitatea fiecărui modul software al legăturii (astfel cum este definit în secțiunea 3.4, „Arhitectura legăturii de comunicare”).

Infrastructura de testare trebuie să fie separată de cea de producție, atât la nivel de rețea, cât și la nivel de infrastructură. Infrastructura de testare este cea în care se efectuează testele de securitate necesare pentru a verifica respectarea cerințelor de securitate.

5.2.   Dispoziții privind suspendarea și reactivarea legăturii

Atunci când există suspiciunea că securitatea registrului elvețian, a SSTL, a registrului Uniunii sau a EUTL a fost compromisă, fiecare parte o informează imediat pe cealaltă și suspendă legătura dintre SSTL și EUTL;

Suspendări

Suspendarea legăturii între registre în conformitate cu anexa II la acord se poate produce în următoarele situații:

În caz de urgență, oricare dintre părți va informa cealaltă parte și va suspenda unilateral legătura între registre.

Dacă se ia decizia de a suspenda legătura între registre, atunci fiecare parte se va asigura că legătura este întreruptă la nivel de rețea (prin blocarea părților sau a tuturor conexiunilor de intrare și de ieșire).

Reactivarea comunicării

O decizie de reactivare a legăturii între registre va fi luată în modul prezentat în detaliu în procedeele comune de funcționare și, în orice caz, înainte de finalizarea cu succes a procedurilor de testare a securității, astfel cum sunt prezentate în detaliu în secțiunile 5.4, „Orientări privind testările de securitate”, și 4.2, „Planul de inițializare, comunicare, reactivare și testare”.

5.3.   Dispoziții privind încălcarea securității

O încălcare a securității este considerată un incident de securitate care afectează confidențialitatea și integritatea oricăror informații sensibile și/sau disponibilitatea sistemului care le gestionează.

Informațiile sensibile sunt menționate în Evidența informațiilor sensibile și pot fi gestionate în cadrul sistemului sau în cadrul oricărei componente conexe a sistemului.

Informațiile direct legate de încălcarea securității vor fi considerate sensibile, marcate cu mențiunea „SPECIAL HANDLING: ETS critical
” și gestionat în conformitate cu instrucțiunile de gestionare, cu excepția cazului în care se specifică altfel.

5.4.   Orientări privind testarea securității

5.4.1.   Software

Testarea securității, inclusiv testul de rezistență la intruziuni, dacă este cazul, se efectuează cel puțin pe toate noile versiuni importante ale software-ului, în conformitate cu cerințele de securitate prevăzute în standardele tehnice de creare a legăturii, pentru a evalua securitatea legăturii și riscurile aferente.

Dacă în ultimele 12 luni nu s-a produs nicio versiune importantă, se efectuează testul de securitate în sistemul curent, luând în considerare evoluția amenințărilor cibernetice din cursul ultimelor 12 luni.

Testarea securității legăturii între registre se efectuează în mediul de acceptare și, dacă este necesar, în mediul de producție și cu coordonarea și acordul reciproc ale ambelor părți.

Testarea aplicațiilor web va respecta standardele internaționale deschise, cum ar fi cele elaborare de fundația Open Web Application Security Project (OWASP).

5.4.2.   Infrastructură

Infrastructura care susține sistemul de producție este scanată în mod regulat împotriva vulnerabilităților (cel puțin o dată pe lună), iar vulnerabilitățile detectate sunt remediate pe baza aceluiași principiu definit în secțiunea precedentă, utilizând o bază de date actualizată a vulnerabilităților.

5.5.   Dispoziții privind evaluarea riscurilor

Dacă testul de rezistență la intruziuni este aplicabil, acesta trebuie inclus în testarea securității.

Fiecare parte poate contracta o societate specializată pentru efectuarea testelor de securitate, cu condiția ca respectiva societate: