PRILOG

Tehnički standardi za povezivanje (LTS) u skladu s člankom 3. stavkom 7. Sporazuma između Europske unije i Švicarske Konfederacije o povezivanju njihovih sustava trgovanja emisijama stakleničkih plinova

Standardi za privremeno rješenje

1.   Pojmovnik

Tablica 1.1.

Poslovne pokrate i definicije

Pokrata/termin	Definicija
Emisijska jedinica	Dopuštenje za ispuštanje jedne tone ekvivalenta ugljikova dioksida tijekom određenog razdoblja, valjano samo za ispunjavanje zahtjeva u okviru ETS-a EU-a ili ETS-a Švicarske
CH	Švicarska Konfederacija
CHU	Švicarske opće emisijske jedinice (termin „CHU2” upotrebljava se kao pokrata za emisijske jedinice CHU za 2. obvezujuće razdoblje)
CHUA	Švicarske emisijske jedinice za zrakoplovstvo
COP	Zajednički operativni postupci koje su zajednički oblikovale stranke Sporazuma kako bi veza između ETS-a EU-a i ETS-a Švicarske postala operativna
ETR	Registar trgovanja emisijama
ETS	Sustav trgovanja emisijama
EU	Europska unija
EUA	Opća emisijska jedinica EU-a
EUAA	Emisijska jedinica EU-a za zrakoplovstvo
EUCR	Konsolidirani registar Europske unije
EUTL	Dnevnik transakcija Europske unije
Registar	Sustav za obračunavanje emisijskih jedinica izdanih u okviru ETS-a, u kojem se prati vlasništvo nad emisijskim jedinicama koje se drže na elektroničkim računima
SSTL	Švicarski dopunski dnevnik transakcija
Transakcija	Postupak u registru koji uključuje prijenos emisijskih jedinica s jednog računa na drugi
Sustav dnevnika transakcija	U dnevniku transakcija bilježe se sve predložene transakcije iz jednog registra u drugi.

Tablica 1.2.

Tehničke pokrate i definicije

Pokrata	Definicija
Asimetrična kriptografija	Upotrebljava javne i privatne ključeve za šifriranje i dešifriranje podataka
Certifikacijsko tijelo	Subjekt koji izdaje digitalne certifikate
Kriptografski ključ	Informacija koja određuje funkcionalni rezultat kriptografskog algoritma
Dešifriranje	Proces obrnut od šifriranja
Digitalni potpis	Matematička tehnika koja se upotrebljava za potvrđivanje autentičnosti i cjelovitosti poruke, softvera ili digitalnog dokumenta
Šifriranje	Postupak pretvaranja informacija ili podataka u kôd, posebno kako bi se spriječio neovlašten pristup
Unos datoteke	Proces čitanja datoteke
Vatrozid	Uređaj ili softver za sigurnost mreže koji prati i kontrolira ulazni i izlazni mrežni promet na temelju unaprijed utvrđenih pravila
Praćenje rada sustava	Signal koji se generira u pravilnim vremenskim razmacima (prati ga hardver ili softver) kao pokazatelj normalnog rada ili za usklađivanje drugih dijelova računalnog sustava
IPSec	Sigurnost internetskog protokola. Skup mrežnih protokola koji autentificira i šifrira pakete podataka kako bi se omogućila sigurna šifrirana komunikacija između dvaju računala putem mreže internetskog protokola.
Testiranje na probijanje	Praksa testiranja računalnog sustava, mreže ili mrežne aplikacije kako bi se pronašli sigurnosni nedostaci koje bi napadač mogao iskoristiti
Postupak usklađivanja	Postupak osiguravanja usklađenosti dvaju skupova zapisa
VPN	Virtualna privatna mreža
XML	Proširivi jezik za označivanje podataka. Dizajnerima omogućava da izrade vlastite prilagođene oznake, čime se omogućava definiranje, prijenos, potvrđivanje i tumačenje podataka među aplikacijama i među organizacijama.

2.   Uvod

Sporazumom između Europske unije i Švicarske Konfederacije o povezivanju njihovih sustava trgovanja emisijama stakleničkih plinova od 23. studenoga 2017. („Sporazum”) omogućava se međusobno priznavanje emisijskih jedinica koje se mogu iskoristiti za ispunjenje obveze u okviru sustava trgovanja emisijskim jedinicama stakleničkih plinova Europske unije (ETS EU-a) ili sustava trgovanja emisijskim jedinicama Švicarske (ETS Švicarske). Kako bi veza između ETS-a EU-a i ETS-a Švicarske postala operativna, uspostavlja se izravna veza između Dnevnika transakcija Europske unije (EUTL) u okviru registra Unije i Švicarskog dopunskog dnevnika transakcija (SSTL) u okviru švicarskog registra, čime će se omogućiti prijenos emisijskih jedinica izdanih u okviru tih ETS-ova iz jednog registra u drugi (članak 3. stavak 2. Sporazuma). Kako bi veza između ETS-a EU-a i ETS-a Švicarske postala operativna, od svibnja 2020. ili što je prije moguće nakon toga primjenjuje se privremeno rješenje. Stranke surađuju kako bi privremeno rješenje što prije zamijenile trajnom vezom između registara (Prilog II. Sporazumu).

U skladu s člankom 3. stavkom 7. Sporazuma, administrator švicarskog registra i središnji administrator Unije izrađuju tehničke standarde za povezivanje (LTS), koji se temelje na načelima iz Priloga II. Sporazumu i u kojima se opisuju detaljni zahtjevi za uspostavu pouzdane i sigurne veze između SSTL-a i EUTL-a. Tehnički standardi za povezivanje koje izrade administratori počinju proizvoditi učinke kad se donesu odlukom Zajedničkog odbora.

Kako je navedeno u ovom dokumentu, tehničke standarde za povezivanje donosi Zajednički odbor Odlukom br. 2/2020. Tom odlukom Zajednički odbor zatražit će da administrator švicarskog registra i središnji administrator Unije izrade daljnje tehničke smjernice kako bi veza postala operativna i kako bi se osiguralo da se smjernice stalno prilagođavaju tehničkom napretku i novim zahtjevima u pogledu sigurnosti i zaštite veze te njezinog djelotvornog i učinkovitog funkcioniranja.

2.1.   Područje primjene

Ovaj dokument predstavlja zajednički dogovor stranaka Sporazuma u pogledu utvrđivanja tehničkih temelja veze između registara ETS-a EU-a i ETS-a Švicarske. Iako se u njemu navode osnovne tehničke specifikacije u pogledu arhitektonskih, uslužnih i sigurnosnih zahtjeva, bit će potrebne daljnje detaljne smjernice kako bi veza postala operativna.

Za daljnje pravilno funkcioniranje veze bit će potrebno utvrditi procese i postupke. U skladu s člankom 3. stavkom 6. Sporazuma ta su pitanja detaljno razrađena u dokumentu o zajedničkim operativnim postupcima (COP), koji treba biti zasebno donesen odlukom Zajedničkog odbora.

2.2.   Adresati

Ovaj je dokument upućen administratoru švicarskog registra i središnjem administratoru Unije.

3.   Opće odredbe

3.1.   Struktura komunikacijske veze

Svrha je ovog odjeljka opisati opću strukturu za postizanje operativnosti veze između ETS-a EU-a i ETS-a Švicarske te njezine različite sastavne dijelove.

Budući da je sigurnost ključna u utvrđivanju strukture veze između registara, poduzete su sve mjere kako bi se postigla stabilna struktura. Iako će se predviđena trajna veza između registara temeljiti na mrežnim uslugama, u privremenom rješenju upotrebljavat će se mehanizam razmjene datoteka.

Tehničko rješenje koristi:

—	protokol za sigurnu razmjenu poruka,

—	poruke u XML-u,

—	digitalni potpis i šifriranje na temelju XML-a,

—	uređaj za VPN ili jednakovrijednu mrežu za siguran prijenos podataka.

3.1.1.   Razmjena poruka

Komunikacija između registra Unije i švicarskog registra temeljit će se na mehanizmu razmjene poruka sigurnim kanalima. Svaka strana oslanjat će se na vlastiti repozitorij primljenih poruka.

Obje stranke vode evidenciju primljenih poruka zajedno s pojedinostima o obradi.

Pogreške ili neočekivani status potrebno je prijaviti kao upozorenje te bi trebalo uspostaviti osobni kontakt između timova za potporu.

S pogreškama i neočekivanim događajima postupat će se u skladu s operativnim postupcima utvrđenima u postupku upravljanja incidentima u okviru zajedničkih operativnih postupaka.

3.1.2.   Poruka u XML-u – Detaljan opis

Poruka u XML-u sadržava jedno od sljedećeg:

—	jedan ili više zahtjeva za transakciju i/ili jedan ili više odgovora na transakciju,

—	jednu operaciju/odgovor povezan s usklađivanjem,

—	jednu testnu poruku.

Svaka poruka sadrži zaglavlje s:

—	ETS-om iz kojeg dolazi,

—	rednim brojem.

3.1.3.   Prozori za unos

Privremeno rješenje temelji se na unaprijed definiranim prozorima za unos, nakon kojih slijedi niz imenovanih radnji. Zahtjevi za transakcije zaprimljeni putem veze unose se samo u unaprijed utvrđenim intervalima. Prozori za unos uključuju tehničku potvrdu izlaznih i ulaznih transakcija. Osim toga, usklađivanje se može provoditi svakodnevno i može se aktivirati ručno.

Promjene učestalosti i/ili vremena bilo koje od tih radnji provodit će se u skladu s operativnim postupcima utvrđenima u postupku ispunjavanja zahtjeva u okviru zajedničkih operativnih postupaka.

3.1.4.   Tokovi transakcijskih poruka

Izlazne transakcije

Postupak je opisan iz perspektive ETS-a pošiljatelja. Na prethodnoj su shemi prikazani svi specifični tokovi izlaznih transakcija.

Glavni tok „Uobičajena transakcija” (s koracima navedenima u prethodnom grafičkom prikazu):

(a)	kad je riječ o ETS-u pošiljatelju, zahtjev za transakciju šalje se iz registra u Dnevnik transakcija nakon što se završe sve poslovne odgode (prema potrebi 24 sata);

(b)	Dnevnik transakcija potvrđuje zahtjev za transakciju;

(c)	zahtjev za transakciju šalje se u odredišni ETS;

(d)	odgovor o prihvaćanju šalje se u registar ishodišnog ETS-a;

(e)	odredišni ETS potvrđuje zahtjev za transakciju;

(f)	odredišni ETS šalje odgovor o prihvaćanju u Dnevnik transakcija ishodišnog ETS-a;

(g)	Dnevnik transakcija šalje odgovor o prihvaćanju u registar.

Alternativni tok „Odbijanje Dnevnika transakcija” (s koracima navedenima u prethodnom grafičkom prikazu, počevši također od točke a)):

(a)	zahtjev za transakciju šalje se u ishodišnom ETS-u iz registra u Dnevnik transakcija nakon što se završe sve poslovne odgode (prema potrebi 24 sata);

nakon čega slijedi:

(b)	Dnevnik transakcija ne potvrđuje zahtjev;

(c)	poruka o odbijanju zahtjeva šalje se u ishodišni registar.

Alternativni tok „Odbijanje ETS-a” (s koracima navedenima u prethodnom grafičkom prikazu, počevši također od točke a)):

(a)	zahtjev za transakciju šalje se u ishodišnom ETS-u iz registra u Dnevnik transakcija nakon što se završe sve poslovne odgode (prema potrebi 24 sata);

(b)	Dnevnik transakcija potvrđuje transakciju;

(c)	zahtjev za transakciju šalje se u odredišni ETS;

(d)	poruka o prihvaćanju šalje se u registar ishodišnog ETS-a;

nakon čega slijedi:

(e)	u Dnevniku transakcija u okviru ETS-a primatelja transakcija se ne potvrđuje;

(f)	ETS primatelj šalje odgovor o odbijanju u Dnevnik transakcija ETS-a pošiljatelja;

(g)	Dnevnik transakcija šalje odbijanje u registar.

Ulazne transakcije

Postupak je opisan iz perspektive ETS-a primatelja. Specifični tok prikazan je na shemi.

Na shemi se prikazuje sljedeće:

1.	kad Dnevnik transakcija u okviru ETS-a primatelja potvrdi zahtjev, šalje poruku o prihvaćanju ETS-u pošiljatelju i poruku o dovršetku transakcije registru ETS-a primatelja;

2.	ako je ulazni zahtjev odbijen u Dnevniku transakcija primatelja, zahtjev za transakciju ne šalje se registru ETS-a primatelja.

Protokol

Ciklus poruka o transakciji uključuje samo dvije poruke:

—	ETS pošiljatelj ETS primatelj: prijedlog transakcije,

—	ETS primatelj ETS pošiljatelj: odgovor o transakciji, koja se prihvaća ili odbija (uključujući razlog odbijanja): — prihvaćeno: transakcija je dovršena, — odbijeno: transakcija je prekinuta.

Status transakcije

—	U ETS-u pošiljatelju transakcija će imati status „predloženo” kad se pošalje zahtjev za tu transakciju.

—	U ETS-u primatelju transakcija će imati status „predloženo” nakon primitka i tijekom obrade zahtjeva.

—	U ETS-u primatelju transakcija će dobiti status „dovršeno”/„prekinuto” nakon obrade zahtjeva. ETS primatelj zatim šalje odgovarajuću poruku o prihvaćanju/odbijanju.

—	U ETS-u pošiljatelju transakcija dobiva status „dovršeno”/„prekinuto” nakon primitka i obrade poruke o prihvaćanju/odbijanju.

—	Ako ne bude nikakvog odgovora, status transakcije u ETS-u pošiljatelju ostat će „predloženo”.

—	Transakcije koje zadrže status „predloženo” dulje od 30 minuta označavaju se u ETS-u primatelju kao prekinute.

Incidenti povezani s transakcijama rješavat će se u skladu s operativnim postupcima utvrđenima u postupku upravljanja incidentima u okviru zajedničkih operativnih postupaka.

3.2.   Sigurnost prijenosa podataka

Na podatke o prijenosu primjenjivat će se četiri razine zaštite:

1.	kontrola pristupa mreži: vatrozid i sloj međumrežne povezanosti;

2.	šifriranje na razini prijenosa: VPN ili jednakovrijedna mrežu za siguran prijenos podataka;

3.	šifriranje na razini sesije: protokol za sigurnu razmjenu poruka;

4.	šifriranje na razini aplikacije: šifriranje i potpis sadržaja u XML-u.

3.2.1.   Vatrozid i međumrežna povezanost

Veza se uspostavlja putem mreže zaštićene hardverskim vatrozidom. Vatrozid mora biti konfiguriran tako da se samo „registrirani” klijenti mogu spajati na poslužitelj za VPN.

3.2.2.   Virtualna privatna mreža (VPN)

Sva komunikacija između stranaka zaštićena je tehnologijom za siguran prijenos podataka. Za virtualnu privatnu mrežu (VPN), infrastruktura bi se trebala temeljiti na hardveru ili virtualnim uređajima. Tehnologije VPN-a pružaju mogućnost „tunela” kroz mrežu kao što je internet od jedne do druge točke, štiteći pritom svu komunikaciju. Prije stvaranja tunela VPN-a potencijalnom krajnjem klijentu izdaje se digitalni certifikat, čime se tom klijentu omogućava da dostavi dokaz identiteta tijekom pregovora o spajanju. Svaka je stranka odgovorna za ugradnju certifikata u svoju krajnju točku VPN-a. Upotrebom digitalnih certifikata svaki krajnji poslužitelj VPN-a pristupit će središnjem tijelu kako bi se utvrdili podaci za autentifikaciju. Tijekom postupka stvaranja tunela pregovara se o šifriranju, čime se osigurava zaštita sve komunikacije putem tunela.

Krajnje točke VPN-a klijenata moraju biti konfigurirane tako da trajno održavaju tunel VPN-a kako bi u svakom trenutku bila moguća pouzdana dvosmjerna komunikacija između stranaka u stvarnom vremenu.

Bilo koje drugo jednakovrijedno rješenje mora biti u skladu s navedenim načelima.

3.2.3.   Provedba IPSec-a

Ako se upotrebljava VPN, protokolom IPSec za oblikovanje infrastrukture VPN-a između lokacija krajnjih korisnika osigurat će se autentifikacija te cjelovitost i šifriranje podataka između lokacija krajnjih korisnika. Konfiguracije IPSec VPN-a osiguravaju pravilnu autentifikaciju između dviju krajnjih točaka povezanih VPN-om. Stranke identificiraju i autentificiraju udaljenog klijenta putem veze IPSec upotrebom digitalnih certifikata koje dostavlja certifikacijsko tijelo koje priznaje druga strana.

IPsec osigurava i cjelovitost podataka u svoj komunikaciji koja se prenosi kroz tunel VPN-a. Podatkovni paketi raspršuju se (eng. hash) i potpisuju upotrebom podataka za autentifikaciju koje je utvrdio VPN. Povjerljivost podataka osigurava se i omogućavanjem šifriranja IPSec.

3.2.4.   Protokol za sigurnu razmjenu poruka

Privremeno rješenje temelji se na više slojeva šifriranja kako bi se postigla sigurna razmjena podataka između stranaka. Oba sustava i njihova različita okruženja međusobno su povezana na razini mreže s pomoću tunela VPN-a ili jednakovrijednih mreža za siguran prijenos podataka. Na razini aplikacije datoteke se prenose putem protokola za sigurnu razmjenu poruka na razini sesije.

3.2.5.   Šifriranje i potpis sadržaja u XML-u

Potpisivanje i šifriranje u XML datotekama odvijaju se na dvije razine. Svaki zahtjev za transakciju, odgovor na transakciju i poruka o usklađivanju pojedinačno se digitalno potpisuju.

U drugom se koraku svaki podelement elementa „poruka” pojedinačno šifrira.

Uz to, kako bi se osiguralo da poruka bude cjelovita i da cijela poruka ne bude odbačena, u trećem se koraku digitalno potpisuje korijenski element poruke. Tako se dobiva visoka razina zaštite ugrađenih podataka u XML-u. U tehničkoj provedbi poštuju se standardi konzorcija World Wide Web.

Za dešifriranje i provjeru poruke postupak se provodi obrnutim redoslijedom.

3.2.6.   Kriptografski ključevi

Kriptografija javnih ključeva upotrebljavat će se za šifriranje i potpisivanje.

Za poseban slučaj IPSec-a upotrebljava se digitalni certifikat koji je izdalo certifikacijsko tijelo koje ima povjerenje obiju stranaka. To certifikacijsko tijelo provjerava identitet nositelja certifikata i izdaje certifikate koji se upotrebljavaju za točnu identifikaciju organizacije i uspostavu kanala za sigurnu podatkovnu komunikaciju između stranaka.

Kriptografski ključevi upotrebljavaju se za potpisivanje i šifriranje komunikacijskih kanala i podatkovnih datoteka. Javne certifikate u digitalnom obliku stranke razmjenjuju sigurnim kanalima, a provjeravaju se drugim putem (eng. out of band). Taj je postupak dio postupka upravljanja sigurnošću informacija u okviru zajedničkih operativnih postupaka.

3.3.   Popis funkcija u okviru veze

Veza određuje sustav prijenosa za niz funkcija kojima se provode poslovni procesi koji proizlaze iz Sporazuma. Veza uključuje i specifikaciju za postupak usklađivanja i za testne poruke koje će omogućiti praćenje rada sustava.

3.3.1.   Poslovne transakcije

Iz poslovne perspektive veza omogućava četiri (4) vrste zahtjeva za transakciju:

—

vanjski prijenos: — nakon stupanja na snagu povezivanja ETS-ova, emisijske jedinice EU-a i Švicarske zamjenjive su i stoga u potpunosti prenosive između stranaka, — prijenos putem veze uključivat će račun pošiljatelj u jednom ETS-u i račun primatelj u drugome, — prijenos može uključivati bilo koju količinu četiriju (4) vrsta jedinica: — švicarskih općih emisijskih jedinica (CHU), — švicarskih emisijskih jedinica za zrakoplovstvo (CHUA), — općih emisijskih jedinica EU-a (EUA), — emisijskih jedinica EU-a za zrakoplovstvo (EUAA),

—	međunarodnu dodjelu: operatori zrakoplova za koje je nadležan jedan ETS, a imaju obveze prema drugom ETS-u i imaju pravo na besplatne emisijske jedinice iz tog drugog ETS-a dobit će besplatne emisijske jedinice za zrakoplovstvo iz drugog ETS-a putem transakcije za međunarodnu dodjelu,

—	poništavanje međunarodne dodjele: ta će transakcija biti izvršena ako se besplatne emisijske jedinice koje je drugi ETS dodijelio vlasničkom računu operatora zrakoplova moraju u potpunosti poništiti,

—	povrat viška dodijeljenih jedinica: slično poništenju, ali u slučajevima kad dodjela ne treba biti u potpunosti poništena, već se ETS-u koji je izvršio dodjelu treba vratiti samo višak dodijeljenih emisijskih jedinica.

3.3.2.   Protokol o usklađivanju

Usklađivanje će se provoditi tek nakon zatvaranja prozora za unos, potvrđivanje i obradu poruka.

Usklađivanje je sastavni dio mjera zaštite i ujednačenosti povezivanja. Stranke će se prije izrade rasporeda usuglasiti o točnom vremenu usklađivanja. Dnevno planirano usklađivanje može se provoditi ako se o tome slože obje stranke. Nakon svakog unosa provest će se barem jedno planirano usklađivanje.

U svakom slučaju, svaka stranka može u bilo kojem trenutku pokrenuti ručno usklađivanje.

Vrijeme i učestalost planiranog usklađivanja mijenjat će se u skladu s operativnim postupcima utvrđenima u postupku ispunjavanja zahtjeva u okviru zajedničkih operativnih postupaka.

3.3.3.   Testna poruka

Svrha testne poruke jest testirati komunikaciju između krajnjih korisnika. Poruka će sadržavati podatke koji će je identificirati kao testnu i druga će strana nakon primitka odgovoriti na nju.

3.4.   Standardi za mrežne usluge

Mrežne usluge neće se upotrebljavati u okviru privremenog rješenja. Međutim, treba napomenuti da će oblik i format poruka u XML-u u velikoj mjeri ostati nepromijenjeni. Kad se u budućnosti uvede trajna veza između registara, mrežne usluge trebale bi omogućiti razmjenu poruka u XML-u u stvarnom vremenu.

3.5.   Posebna definicija mrežnih usluga

Ovaj odjeljak nije primjenjiv na privremeno rješenje. Kako je navedeno u prethodnom odjeljku, mrežne usluge upotrebljavat će se samo u okviru buduće trajne veze između registara.

3.6.   Zahtjevi u pogledu bilježenja podataka

Kako bi obje stranke raspolagale točnim i dosljednim informacijama te kako bi se pružili alati za rješavanje nedosljednosti putem postupka usklađivanja, obje stranke čuvaju četiri (4) vrste podataka:

—	dnevnike transakcija,

—	dnevnike usklađivanja,

—	arhivu poruka,

—	dnevnike unutarnje revizije.

Svi navedeni podaci čuvaju se najmanje tri (3) mjeseca za potrebe otklanjanja problema, a njihovo daljnje čuvanje ovisit će o primjenjivom pravu svake stranke za potrebe revizije. Datoteke s podacima starije od tri (3) mjeseca mogu se pohraniti na sigurnu lokaciju u neovisnom IT sustavu pod uvjetom da ih se može dobiti ili im se može pristupiti u razumnom roku.

Dnevnici transakcija

Podsustavi EUTL-a i SSTL-a sadržavaju provedbu dnevnika transakcija.

Točnije, u dnevnicima transakcija evidentirat će se svaka predložena transakcija poslana drugom ETS-u. Svaki zapis uključuje sva polja sadržaja transakcije i naknadni ishod transakcije (odgovor ETS-a primatelja). U dnevnicima transakcija evidentirat će se i ulazne transakcije, kao i odgovori poslani ishodišnom ETS-u.

Dnevnici usklađivanja

U dnevniku usklađivanja evidentira se svaka poruka o usklađivanju koju su razmijenile stranke, uključujući identifikacijsku oznaku usklađivanja, vremenski žig i rezultat usklađivanja: status usklađivanja „Uspješno” ili „Nepodudarnosti”. Poruke o usklađivanju dio su poruka koje se razmjenjuju u okviru privremenog rješenja.

Svaka stranka u dnevniku usklađivanja evidentira svaki zahtjev i svoj odgovor. Iako se informacije u dnevniku usklađivanja ne dijele izravno u okviru samog usklađivanja, pristup tim informacijama može biti nužan kako bi se uklonile nepodudarnosti.

Arhiva poruka

Obje stranke moraju pohraniti kopiju razmijenjenih podataka (XML datoteke), poslanih i primljenih, uz navod jesu li te poruke u XML-u bile ispravne u svojem formatu.

Arhiva se uglavnom čuva za potrebe revizije, kako bi postojali dokazi o tome što je poslano drugoj stranci i primljeno od nje. S obzirom na to, osim datoteka potrebno je pohraniti i povezane certifikate.

U tim će se datotekama nalaziti i dodatne informacije za otklanjanje problema.

Dnevnik unutarnje revizije

Svaka stranka samostalno definira i upotrebljava te dnevnike.

3.7.   Operativni zahtjevi

Razmjena podataka između dvaju sustava u privremenom rješenju nije u potpunosti neovisna, što znači da su potrebni operatori i postupci da bi veza bila operativna.

4.   Odredbe o dostupnosti

4.1.   Oblikovanje dostupnosti komunikacije

Struktura privremenog rješenja u osnovi je infrastruktura i softver IKT-a koji omogućavaju komunikaciju između ETS-a Švicarske i ETS-a EU-a. Osiguravanje visoke razine dostupnosti, cjelovitosti i povjerljivosti tog toka podataka stoga postaje ključan aspekt koji treba uzeti u obzir pri oblikovanju privremenog rješenja i trajne veze između registara. Budući da je riječ o projektu u kojem infrastruktura IKT-a, namjenski izrađen softver i procesi imaju važnu ulogu, sva se ta tri elementa moraju uzeti u obzir kako bi se oblikovao otporan sustav.

Otpornost infrastrukture IKT-a

U poglavlju o općim odredbama u ovom dokumentu detaljno su opisani strukturni sastavni dijelovi. Kad je riječ o infrastrukturi IKT-a, privremenim povezivanjem uspostavlja se otporna mreža VPN (ili jednakovrijedna mreža) u kojoj se stvaraju tuneli za sigurnu komunikaciju, preko kojih se može odvijati sigurna razmjena poruka. Drugi infrastrukturni elementi konfigurirani su kao visokodostupni i/ili se oslanjaju na zamjenske mehanizme.

Otpornost namjenskog softvera

Namjenski izrađeni softverski moduli povećavaju otpornost tako što pokušavaju uspostaviti komunikaciju s drugom stranom tijekom određenog vremenskog razdoblja ako ona zbog bilo kojeg razloga nije dostupna.

Otpornost usluga

U privremenom se rješenju razmjena podataka između stranaka odvija u unaprijed utvrđenim vremenskim terminima tijekom cijele godine. Za neke od koraka u planiranoj razmjeni podataka potrebna je ručna intervencija operatora sustava i/ili administratora registara. S obzirom na to te kako bi se povećala dostupnost i uspjeh razmjena:

—	u okviru operativnih postupaka predviđena su dulja vremenska razdoblja za provedbu svake faze,

—	softverski moduli za privremeno rješenje provode asinkronu komunikaciju,

—	postupkom automatskog usklađivanja otkrit će se postoje li problemi pri unosu podatkovnih datoteka na bilo kojoj strani,

—

postupci praćenja (infrastruktura IKT-a i namjenski softverski moduli) uzimaju se u obzir i pokreću postupke upravljanja incidentima (kako su definirani u dokumentu o zajedničkim operativnim postupcima). Ti postupci, čiji je cilj brža ponovna uspostava normalnog rada nakon incidenata, ključni su za osiguravanje visokih omjera dostupnosti.

4.2.   Plan pokretanja, komunikacije, ponovne aktivacije i testiranja

Svi elementi uključeni u strukturu privremenog rješenja prolaze niz pojedinačnih i kolektivnih testova kako bi se potvrdilo da je platforma spremna na razini infrastrukture IKT-a i informacijskog sustava. Ti su operativni testovi obvezni svaki put kad se na platformi privremenom rješenju status promijeni iz suspendiranog u operativni.

Za aktivaciju operativnog statusa veze potrebna je uspješna provedba unaprijed definiranog plana testiranja. Time se potvrđuje da je svaki registar najprije proveo niz internih testova, nakon čega je uslijedila potvrda povezivosti između krajnjih korisnika prije početka podnošenja proizvodnih transakcija između stranaka.

U planu testiranja treba navesti opću strategiju testiranja i pojedinosti o infrastrukturi za testiranje. Konkretno, svaki element u svakom testnom bloku trebao bi uključivati:

—	kriterije i alate za testiranje,

—	uloge dodijeljene za provođenje testiranja,

—	očekivane rezultate (pozitivne i negativne),

—	raspored testiranja,

—	evidenciju zahtjeva u pogledu rezultata testiranja,

—	dokumentaciju o otklanjanju problema,

—	odredbe o upućivanju na više razine.

Kao proces, testiranja aktivacije operativnog statusa mogu se podijeliti na četiri (4) konceptualna bloka ili faze, kako je navedeno u nastavku.

4.2.1.   Interna testiranja infrastrukture IKT-a

Ta bi testiranja svaka stranka trebala provoditi i/ili provjeravati pojedinačno.

Svaki element infrastrukture IKT-a sa svake strane testira se pojedinačno. To uključuje svaku pojedinu komponentu infrastrukture. Ta se testiranja mogu provoditi automatski ili ručno, ali se njima mora provjeriti je li svaki element infrastrukture operativan.

4.2.2.   Komunikacijska testiranja

Ta testiranja započinje svaka stranka pojedinačno, a za dovršetak je potrebna suradnja druge strane.

Nakon što pojedini elementi postanu operativni, potrebno je testirati komunikacijske kanale između dvaju registara. U tu svrhu svaka stranka provjerava je li omogućen pristup internetu, jesu li uspostavljeni tuneli VPN-a (ili jednakovrijedne mreže za siguran prijenos) te postoji li IP povezanost između lokacija krajnjih korisnika. Druga strana zatim treba potvrditi dostupnost lokalnih i udaljenih infrastrukturnih elemenata i IP povezanost.

4.2.3.   Testiranja cijelog sustava

Ta bi se ispitivanja trebala provoditi na obje strane, a rezultati dijeliti s drugom strankom.

Nakon što se testiraju komunikacijski kanali i svaki pojedini sastavni dio obaju registara, svaka strana priprema niz simuliranih transakcija i usklađivanja reprezentativnih za sve funkcije koje se provode putem veze.

4.2.4.   Sigurnosna testiranja

Ta bi testiranja obje stranke trebale provesti i/ili pokrenuti sa svoje strane kako je detaljno opisano u odjeljcima 5.4. „Smjernice za testiranje sigurnosti” i 5.5. „Odredbe o procjeni rizika”.

Tek se nakon završetka svake od četiri faze/bloka s predvidivim rezultatima može smatrati da je privremena veza operativna.

Resursi za testiranje

Svaka stranka računa na posebne resurse za testiranje (posebni softver i hardver za infrastrukturu IKT-a) i u svojem sustavu razvija funkcije testiranja kako bi poduprla ručno i kontinuirano potvrđivanje platforme. Administratori registara u svakom trenutku mogu provesti ručna pojedinačna ili kooperativna testiranja. Operativni status aktivira se ručno.

Isto je tako predviđeno da platforma redovito provodi automatske provjere. Cilj je tih provjera povećati dostupnost platforme ranim otkrivanjem mogućih problema povezanih s infrastrukturom ili softverom. Plan praćenja platforme sastoji se od dva elementa:

—	praćenja infrastrukture IKT-a: infrastrukturu će sa svake strane pratiti pružatelji usluga infrastrukture IKT-a. Automatskim testiranjima bit će obuhvaćeni različiti infrastrukturni elementi i dostupnost komunikacijskih kanala,

—	praćenja aplikacija: privremeni softverski moduli za povezivanje pratit će komunikaciju u sustavu na razini aplikacija (ručno i/ili u redovitim vremenskim razmacima), čime će se testirati dostupnost povezivanja krajnjih korisnika simuliranjem nekih transakcija preko veze.

4.3.   Okruženja za prihvaćanje/testiranje

Struktura registra Unije i registra Švicarske sastoji se od sljedeća tri okruženja:

—	proizvodnja (PROD): u tom se okruženju nalaze stvarni podaci i obrađuju stvarne transakcije,

—	prihvaćanje (ACC): u tom se okruženju nalaze podaci koji nisu stvarni ili koji su anonimizirani i reprezentativni. U tom okruženju operatori sustava obiju stranaka potvrđuju nova izdanja,

—	testiranje (TEST): u tom se okruženju nalaze podaci koji nisu stvarni ili koji su anonimizirani i reprezentativni. Tom okruženju mogu pristupiti samo administratori registara te bi ga obje stranke trebale koristiti za provođenje integracijskih testova.

Osim VPN-a (ili ekvivalentne mreže), navedena tri okruženja potpuno su neovisna jedno o drugome, što znači da su im hardver, softver, baze podataka, virtualna okruženja, IP adrese i ulazi uspostavljeni i djeluju neovisno jedni o drugima.

Kad je riječ o planu VPN-a, on se uspostavlja u dva različita okruženja, jednome za PROD i drugome neovisnome za ACC i TEST.

5.   Odredbe o povjerljivosti i cjelovitosti

Sigurnosnim mehanizmima i postupcima predviđena je metoda s dvije osobe (načelo 4 oka) za operacije koje se odvijaju u vezi između registra Unije i švicarskog registra. Metoda s dvije osobe primjenjuje se kad god je to potrebno. Međutim, možda nije primjenjiva na sve korake koje poduzimaju administratori registara.

Sigurnosni zahtjevi razmatraju se i primjenjuju u planu upravljanja sigurnošću, koji uključuje i procese povezane s rješavanjem sigurnosnih incidenata nakon moguće povrede sigurnosti. Operativni dio tih procesa opisan je u zajedničkim operativnim postupcima.

5.1.   Infrastruktura za testiranje sigurnosti

Svaka se stranka obvezuje uspostaviti infrastrukturu za testiranje sigurnosti (upotrebom zajedničkog softvera i hardvera koji se upotrebljavaju za otkrivanje nedostataka u fazama razvoja i rada):

—	odvojeno od proizvodnog okruženja,

—	ako sigurnost analizira tim neovisan o razvoju i radu sustava.

Svaka se stranka obvezuje provesti statičku i dinamičku analizu.

U slučaju dinamičke analize (kao što je testiranje na probijanje), obje se stranke obvezuju da će evaluacije u pravilu ograničavati na okruženja za testiranje i prihvaćanje (kako je definirano u odjeljku 4.3. „Okruženja za prihvaćanje/testiranje”). Iznimke od tog načela trebaju odobriti obje stranke.

Prije uvođenja u proizvodno okruženje svaki softverski modul veze (kako je definirano u odjeljku 3.1. „Struktura komunikacijske veze”) testira se u pogledu sigurnosti.

Infrastruktura za testiranje mora biti odvojena i na razini mreže i na razini infrastrukture od one za proizvodnju. Sigurnosna testiranja koja su potrebna radi provjere usklađenosti sa zahtjevima u pogledu sigurnosti provode se unutar infrastrukture za testiranje.

5.2.   Odredbe o suspenziji i ponovnoj aktivaciji veze

Ako se posumnja da je sigurnost švicarskog registra, SSTL-a, registra Unije ili EUTL-a ugrožena, predmetna stranka odmah o tome obavješćuje drugu stranku te suspendira vezu između SSTL-a i EUTL-a.

Postupci razmjene informacija te odlučivanja o suspenziji i ponovnoj aktivaciji dio su procesa ispunjavanja zahtjeva u okviru zajedničkih operativnih postupaka.

Suspenzije

Do suspenzije veze između registara u skladu s Prilogom II. Sporazumu može doći zbog:

—	administrativnih razloga (održavanje itd.) – tada se radi o planiranoj suspenziji,

—	razloga povezanih sa sigurnošću (ili kvarom informatičke infrastrukture) – tada se radi o neplaniranoj suspenziji.

U hitnim slučajevima svaka stranka obavješćuje drugu stranku i jednostrano suspendira vezu između registara.

Ako se donese odluka o suspenziji veze između registara, svaka će stranka osigurati prekid veze na razini mreže (blokiranjem nekih ili svih ulaznih i izlaznih povezivanja).

Odluka o suspenziji veze između registara, bez obzira na to je li planirana ili neplanirana, donosi se u skladu s postupkom upravljanja izmjenama ili upravljanja incidentima u području sigurnosti u okviru zajedničkih operativnih postupaka.

Ponovna aktivacija komunikacije

Odluka o ponovnoj aktivaciji veze između registara donosi se kako je detaljno opisano u zajedničkim operativnim postupcima, ali u svakom slučaju tek nakon uspješnog završetka testiranja sigurnosti kako je navedeno u odjeljcima 5.4. „Smjernice za testiranje sigurnosti” i 4.2. „Plan pokretanja, komunikacije, ponovne aktivacije i testiranja”.

5.3.   Odredbe o povredama sigurnosti

Povreda sigurnosti smatra se incidentom u području sigurnosti koji utječe na povjerljivost i cjelovitost osjetljivih informacija i/ili dostupnost sustava u kojem se one obrađuju.

Osjetljive informacije navedene su na popisu osjetljivih informacija i može ih se obrađivati u sustavu ili bilo kojem njegovu povezanom dijelu.

Informacije koje su izravno povezane s povredom sigurnosti smatrat će se osjetljivima, bit će označene kao „ETS KRITIČNO” i s njima će se postupati u skladu s uputama o postupanju, osim ako je određeno drukčije.

Svaka povreda sigurnosti obrađivat će se u skladu s poglavljem „Upravljanje incidentima u području sigurnosti” u okviru zajedničkih operativnih postupaka.

5.4.   Smjernice za testiranje sigurnosti

5.4.1.   Softver

Testiranje sigurnosti, uključujući testiranje na probijanje ako je primjenjivo, provodi se barem na svim većim novim izdanjima softvera u skladu sa sigurnosnim zahtjevima utvrđenima u tehničkim standardima za povezivanje kako bi se procijenila sigurnost povezivanja i povezani rizici.

Ako u posljednjih 12 mjeseci nije bilo velikog novog izdanja, provodi se testiranje sigurnosti postojećeg sustava uzimajući u obzir razvoj kiberprijetnji u posljednjih 12 mjeseci.

Testiranje sigurnosti veze između registara provodi se u okruženju za prihvaćanje i, ako je potrebno, u proizvodnom okruženju te uz koordinaciju i uzajamnu suglasnost obiju stranaka.

Testiranjem mrežnih aplikacija poštovat će se međunarodni otvoreni standardi poput onih razvijenih u okviru projekta OWASP (eng. Open Web Application Security Project).

5.4.2.   Infrastruktura

Infrastruktura koja podupire proizvodni sustav redovito se pregledava kako bi se nedostaci otkrili (najmanje jednom mjesečno) i otkriveni nedostaci uklonili. Testiranje se provodi u skladu s metodom opisanom u odjeljku 5.4.1., uz upotrebu ažurirane baze podataka o nedostacima.

5.5.   Odredbe o procjeni rizika

Ako je testiranje na probijanje primjenjivo, mora se uključiti u testiranje sigurnosti.

Svaka stranka može sklopiti ugovor sa specijaliziranim poduzećem za testiranje sigurnosti, pod uvjetom da to poduzeće:

—	raspolaže vještinama i iskustvom za takvo testiranje sigurnosti,

—	ne izvješćuje izravno razvojnog inženjera ni njegova podizvođača niti je uključeno u razvoj softvera za vezu niti je podizvođač razvojnog inženjera,

—	ima potpisan ugovor o povjerljivosti podataka kako bi rezultati ostali povjerljivi i kako bi se njima postupalo na razini „ETS KRITIČNO” u skladu s uputama o postupanju.