Decyzja 2020/2 w sprawie zmiany załącznika I i II do umowy oraz przyjęcia norm technicznych powiązania
DECYZJA nr 2/2020 WSPÓLNEGO KOMITETU USTANOWIONEGO NA MOCY UMOWY MIĘDZY UNIĄ EUROPEJSKĄ A KONFEDERACJĄ SZWAJCARSKĄ W SPRAWIE POWIĄZANIA ICH SYSTEMÓW HANDLU UPRAWNIENIAMI DO EMISJI GAZÓW CIEPLARNIANYCHz dnia 5 listopada 2020 r.w sprawie zmiany załącznika I i II do umowy oraz przyjęcia norm technicznych powiązania [2021/ 1034]
uwzględniając Umowę między Unią Europejską a Konfederacją Szwajcarską w sprawie powiązania ich systemów handlu uprawnieniami do emisji gazów cieplarnianych 1 ("umowa"), w szczególności jej art. 3 ust. 7 i art. 13 ust. 2,
(1) W decyzji nr 2/2019 Wspólnego Komitetu z dnia 5 grudnia 2019 r. 2 zmieniono załączniki I i II do umowy, tym samym spełniając warunki wymagane do ustanowienia powiązania, które określono w umowie.
(2) W następstwie przyjęcia decyzji nr 2/2019 Wspólnego Komitetu i na podstawie art. 21 ust. 3 umowy strony wymieniły się swoimi instrumentami ratyfikacji lub zatwierdzenia, ponieważ uznały, że spełnione zostały wszystkie warunki wymagane do ustanowienia powiązania, które określono w umowie.
(3) Zgodnie z art. 21 ust. 4 umowy weszła ona w życie dnia 1 stycznia 2020 r.
(4) Załącznik I do umowy należy zmienić zgodnie z art. 13 ust. 2 umowy w celu zapewnienia sprawnej zmiany administrowania operatorami statków powietrznych przypisanymi Szwajcarii po raz pierwszy, biorąc pod uwagę postępy poczynione w ustanawianiu powiązania rejestrów.
(5) Aby uwzględnić najnowsze zmiany i zapewnić wyższy poziom elastyczności na potrzeby ustanowienia powiązania rejestrów wymaganego na mocy umowy, należy zmienić załącznik II do umowy zgodnie z art. 13 ust. 2 umowy celem zapewnienia większego, ale równoważnego zestawu technologii służących utworzeniu powiązania rejestrów.
(6) Na podstawie art. 3 ust. 7 umowy administrator rejestru Szwajcarii i centralny administrator Unii powinni opracować normy techniczne powiązania oparte na zasadach określonych w załączniku II do umowy. W normach technicznych powiązania należy opisać szczegółowe wymogi ustanowienia solidnego i bezpiecznego połączenia między dodatkowym dziennikiem transakcji Szwajcarii (SSTL) a dziennikiem transakcji Unii Europejskiej (EUTL). Normy techniczne powiązania powinny stać się skuteczne z chwilą ich przyjęcia w drodze decyzji Wspólnego Komitetu.
(7) Zgodnie z art. 13 ust. 1 umowy Wspólny Komitet powinien uzgodnić wytyczne techniczne celem zapewnienia prawidłowego wykonania umowy, w tym wytyczne techniczne dotyczące ustanowienia solidnego i bezpiecznego połączenia między SSTL a EUTL. Wytyczne techniczne można opracować w ramach grupy roboczej utworzonej na podstawie art. 12 ust. 5 umowy. Grupa robocza powinna składać się co najmniej z administratora rejestru Szwajcarii i centralnego administratora Unii i powinna wspierać Wspólny Komitet w wykonywaniu jego funkcji na mocy art. 13 umowy.
(8) Z uwagi na techniczny charakter wytycznych i konieczność dostosowania ich do bieżących zmian wytyczne techniczne przygotowane przez administratora rejestru Szwajcarii i centralnego administratora Unii powinny zostać przedłożone Wspólnemu Komitetowi w celach informacyjnych lub, w stosownych przypadkach, w celu zatwierdzenia,
PRZYJMUJE NINIEJSZĄ DECYZJĘ:
Akapit drugi pkt 17 część B załącznika I do umowy otrzymuje brzmienie:
"Operatorzy statków powietrznych przypisani Szwajcarii po raz pierwszy po wejściu w życie niniejszej Umowy są administrowani przez Szwajcarię po dniu 30 kwietnia roku przypisania i po uruchomieniu tymczasowego powiązania rejestrów.".
Akapit czwarty załącznika II do umowy otrzymuje brzmienie:
"Normy techniczne powiązania wskazują, że komunikacja między SSTL a EUTL polega na bezpiecznej wymianie wiadomości usług sieciowych przy zastosowaniu następujących technologii (*) lub równoważnych:
– usług sieciowych wykorzystujących SOAP (ang. Simple Object Access Protocol),
– sprzętowej wirtualnej sieci prywatnej (VPN),
– XML (Extensible Markup Language),
– podpisu cyfrowego, oraz
– protokołów synchronizacji czasu.
(*) Technologie te obecnie stosuje się do tworzenia połączenia między rejestrem Unii a międzynarodowym dziennikiem transakcji, a także między rejestrem Szwajcarii a międzynarodowym dziennikiem transakcji.".
Niniejszym przyjmuje się normy techniczne powiązania załączone do niniejszej decyzji.
Niniejszym tworzy się grupę roboczą na mocy art. 12 ust. 5 umowy. Grupa robocza wspiera Wspólny Komitet w zapewnieniu prawidłowego wykonania umowy, w tym w przygotowaniu wytycznych technicznych dotyczących wdrożenia norm technicznych powiazania.
Grupa robocza składa się co najmniej z administratora rejestru Szwajcarii i centralnego administratora Unii.
Niniejsza decyzja wchodzi w życie z dniem jej przyjęcia.
| W imieniu Wspólnego Komitetu | Sekretarz ze strony Unii | Przewodniczący |
| Sekretarz ze strony Szwajcarii | Europejskiej | CarolineBAUMANN |
| Maja-Alexandra DITTEL | BeatrizYORDI |
ZAŁĄCZNIK 3 NORMY TECHNICZNE POWIĄZANIA ZGODNIE Z ART. 3 UST. 7 UMOWY MIĘDZY UNIĄ EUROPEJSKĄ A KONFEDERACJĄ SZWAJCARSKĄ W SPRAWIE POWIĄZANIA ICH SYSTEMÓW HANDLU UPRAWNIENIAMI DO EMISJI GAZÓW CIEPLARNIANYCH
NORMY TECHNICZNE POWIĄZANIA ZGODNIE Z ART. 3 UST. 7 UMOWY MIĘDZY UNIĄ EUROPEJSKĄ A KONFEDERACJĄ SZWAJCARSKĄ W SPRAWIE POWIĄZANIA ICH SYSTEMÓW HANDLU UPRAWNIENIAMI DO EMISJI GAZÓW CIEPLARNIANYCH
Spis treści
Tabela 1-1
Akronimy i definicje branżowe
| Akronim/termin | Definicja |
| Uprawnienie | Uprawnienie do emisji jednej tony ekwiwalentu dwutlenku węgla w określonym okresie, które jest ważne jedynie na potrzeby spełnienia wymogów w ramach EU ETS lub ETS Szwajcarii. |
| CH | Konfederacja Szwajcarska |
| CHU | Szwajcarskie stacjonarne uprawnienia do emisji, zwane również "CHU2" (termin ten jest stosowany jako skrót od 2 okresu rozliczeniowego protokołu z Kioto). |
| CHUA | Szwajcarskie uprawnienie do emisji lotniczych |
| COP | Wspólne procedury operacyjne. Procedury opracowane wspólnie przez Strony Umowy w celu uruchomienia powiązania między EU ETS a ETS Szwajcarii. |
| ETR | Rejestr handlu emisjami |
| ETS | System handlu emisjami |
| UE | Unia Europejska |
| EUA | Unijne uprawnienie do emisji ogólnych |
| EUAA | Unijne uprawnienie do emisji lotniczych |
| EUCR | Skonsolidowany rejestr Unii Europejskiej |
| EUTL | Dziennik transakcji Unii Europejskiej |
| Rejestr | System rejestracji uprawnień przyznanych na podstawie ETS służący do śledzenia własności uprawnień utrzymywanych na rachunkach elektronicznych. |
| SSTL | Dodatkowy dziennik transakcji Szwajcarii |
| Transakcja | Proces w rejestrze dotyczący przekazywania uprawnienia z jednego rachunku na inny. |
| System dziennika transakcji | Dziennik transakcji zawiera zapis każdej propozycji transakcji wysyłanej z jednego rejestru do drugiego. |
Tabela 1-2
Techniczne akronimy i definicje
| Akronim | Definicja |
| Kryptografia asymetryczna | Wykorzystuje klucze publiczne i prywatne do zaszyfrowania i odszyfrowania danych. |
| Centrum certyfikacji | Podmiot, który wydaje certyfikaty elektroniczne. |
| Klucz kryptograficzny | Informacja, która określa wynik funkcjonalny algorytmu kryptograficznego. |
| Odszyfrowywanie | Proces odwrotny do szyfrowania. |
| Podpis cyfrowy | Technika matematyczna stosowana do sprawdzania autentyczności i integralności wiadomości, oprogramowania lub dokumentu elektronicznego. |
| Szyfrowanie | Proces przekształcenia informacji lub danych w kod, w szczególności aby uniemożliwić dostęp osobom nieupoważnionym. |
| Przyjmowanie pliku | Proces odczytywania pliku |
| Akronim | Definicja |
| Zapora sieciowa | Urządzenie lub oprogramowanie bezpieczeństwa monitorujące i kontrolujące przychodzący i wychodzący ruch sieciowy na podstawie wcześniej określonych reguł. |
| Monitorowanie pulsu | Okresowy sygnał generowany i monitorowany przez sprzęt lub oprogramowanie celem wskazania normalnego funkcjonowania lub zsynchronizowania innych części systemu komputerowego. |
| IPSec | IP SECurity. Zestaw protokołów sieciowych, które uwierzytelniają i szyfrują pakiety danych w celu zapewnienia bezpiecznej szyfrowanej komunikacji między dwoma komputerami za pośrednictwem sieci protokołu internetowego. |
| Testy penetracyjne | Praktyka testowania systemu komputerowego, sieci lub aplikacji internetowej służąca znalezieniu luk w zabezpieczeniach, które mógłby wykorzystać atakujący. |
| Proces uzgadniania | Proces zapewniania, aby dwa zbiory wpisów były zgodne. |
| VPN | Wirtualna sieć prywatna |
| XML | Rozszerzalny język znaczników. Pozwala programistom na stworzenie własnych niestandardowych znaczników umożliwiających określanie, przesyłanie, sprawdzanie i interpretowanie danych między aplikacjami i między organizacjami. |
Umowa między Unią Europejską a Konfederacją Szwajcarską w sprawie powiązania ich systemów handlu uprawnieniami do emisji gazów cieplarnianych z dnia 23 listopada 2017 r. (zwana dalej "Umową") przewiduje wzajemne uznawanie uprawnień do emisji, które można wykorzystać na potrzeby dostosowania się do wymogów systemu handlu uprawnieniami do emisji Unii Europejskiej (zwanego dalej "EU ETS") lub systemu handlu uprawnieniami do emisji Szwajcarii (zwanego dalej "ETS Szwajcarii"). W celu uruchomienia powiązania między EU ETS a ETS Szwajcarii ustanowione zostanie bezpośrednie powiązanie między dziennikiem transakcji Unii Europejskiej (EUTL) rejestru Unii a dodatkowym dziennikiem transakcji Szwajcarii (SSTL) rejestru Szwajcarii, co umożliwi bezpośrednie przekazywanie między rejestrami uprawnień do emisji wydanych w ramach któregokolwiek z ETS (art. 3 ust. 2 Umowy). W celu uruchomienia powiązania między EU ETS i ETS Szwajcarii w 2020 r. wdrożono tymczasowe rozwiązanie. Od 2023 r. powiązanie rejestrów między dwoma systemami handlu uprawnieniami do emisji będzie stopniowo przekształcać się w stałe powiązanie rejestrów, które ma zostać wdrożone nie później niż w 2024 r., co umożliwi funkcjonowanie powiązanych rynków w odniesieniu do korzyści płynących z płynności rynku i realizacji transakcji między dwoma powiązanymi systemami w sposób równoważny jednemu rynkowi składającemu się z dwóch systemów i który umożliwi uczestnikom rynku działanie tak, jakby działali na jednym rynku, z zastrzeżeniem wyłącznie indywidualnych przepisów regulacyjnych Stron (załącznik II do Umowy).
Zgodnie z art. 3 ust. 7 Umowy administrator rejestru Szwajcarii i centralny administrator Unii opracowują normy techniczne powiązania oparte na zasadach określonych w załączniku II do Umowy, opisując szczegółowe wymogi ustanowienia solidnego i bezpiecznego połączenia między SSTL i EUTL. Normy techniczne powiązania opracowane przez administratorów staną się skuteczne z chwilą ich przyjęcia w drodze decyzji Wspólnego Komitetu.
Normy techniczne powiązania zostały przyjęte przez Wspólny Komitet w drodze jego decyzji nr 2/2020. Zaktualizowane normy techniczne powiązania w formie przedstawionej w niniejszym dokumencie, mają zostać przyjęte przez Wspólny Komitet w drodze jego decyzji nr 1/2024. Zgodnie z tą decyzją i wnioskami Wspólnego Komitetu administrator rejestru szwajcarskiego i centralny administrator Unii opracowali i zaktualizują dalsze wytyczne techniczne celem uruchomienia powiązania oraz o zapewnienie, aby były one stale dostosowywane do postępu technicznego i nowych wymogów związanych z bezpieczeństwem i ochroną tego powiązania oraz jego skutecznym i sprawnym funkcjonowaniem.
Niniejszy dokument odzwierciedla wspólne rozumienie Stron Umowy w kwestii ustanowienia technicznych podstaw powiązania między rejestrami EU ETS i ETS Szwajcarii. Chociaż nakreślono w nim podstawę specyfikacji technicznych pod względem wymogów dotyczących architektury, obsługi i bezpieczeństwa, do uruchomienia powiązania potrzebne będą dalsze szczegółowe wytyczne.
Jeżeli chodzi o jego prawidłowe funkcjonowanie, powiązanie będzie wymagało procesów i procedur do dalszego jego uruchomienia. Zgodnie z art. 3 ust. 6 Umowy kwestie te szczegółowo opisano w osobnym dokumencie na temat wspólnych procedur operacyjnych, który ma być przyjęty w drodze odrębnej decyzji Wspólnego Komitetu.
Niniejszy dokument skierowany jest do administratora rejestru Szwajcarii i centralnego administratora Unii.
Celem niniejszej sekcji jest przedstawienie opisu ogólnej architektury uruchomienia powiązania między EU ETS i ETS Szwajcarii oraz związanych z tym poszczególnych komponentów.
Ponieważ bezpieczeństwo jest podstawową częścią określenia architektury powiązania rejestrów, wprowadzono wszelkie środki mające na celu zapewnienie solidnej architektury. Stałe powiązanie rejestrów wykorzystuje mechanizm wymiany plików, jako implementację bezpiecznego połączenia Air Gap.
Rozwiązanie techniczne wykorzystuje:
Podstawą komunikacji między rejestrem Unii a rejestrem Szwajcarii będzie mechanizm wymiany wiadomości za pośrednictwem bezpiecznych kanałów. Każdy koniec będzie opierał się na własnym repozytorium otrzymanych wiadomości.
Obie Strony będą prowadzić dziennik otrzymywanych wiadomości wraz ze szczegółowymi informacjami dotyczącymi przetwarzania.
Błędy lub nieoczekiwany status wymagają zgłoszenia jako w postaci ostrzeżenia oraz kontaktu między osobami należącymi do zespołów wsparcia.
Błędy i nieoczekiwane zdarzenia będą obsługiwane z zachowaniem procedur operacyjnych określonych w sekcji wspólnych procedur operacyjnych poświęconej procesowi zarządzania incydentami.
3.1.2. Wiadomość XML - opis wysokiego poziomu
Wiadomość XML obejmuje jeden z następujących elementów:
Każda wiadomość zawiera nagłówek z:
3.1.3. Okna przyjmowania
Stałe powiązanie rejestrów opiera się na wcześniej określonych oknach przyjmowania, po których następuje seria nazwanych zdarzeń. Wnioski o transakcje otrzymane za pośrednictwem powiązania zostaną przyjęte wyłącznie w uprzednio ustalonych odstępach. Okna przyjmowania wiążą się ze sprawdzeniem wychodzących i przychodzących transakcji pod względem technicznym. Ponadto uzgodnienia można prowadzić codziennie i inicjować ręcznie.
Zmiany częstotliwości lub terminów każdego z tych zdarzeń będą obsługiwane z zachowaniem procedur operacyjnych określonych w sekcji wspólnych procedur operacyjnych poświęconej procesowi realizacji wniosków.
3.1.4. Przepływy wiadomości związanych z transakcją.
Transakcje wychodzące
Odzwierciedla to perspektywę ETS przekazującego uprawnienie. Ten konkretny przepływ zobrazowano na kolejnym schemacie sekwencji:
I
Główny przepływ pokazuje następujące kroki (jak na powyższym rysunku):
Alternatywny przepływ "odrzucenie przez dziennik transakcji" (jak na powyższym rysunku, począwszy od pkt a) w przepływie głównym)):
Alternatywny przepływ "odrzucenie przez ETS" (jak na powyższym rysunku, począwszy od pkt d) w przepływie głównym):
Transakcje przychodzące
Odzwierciedla to perspektywę ETS nabywającego uprawnienie. Ten konkretny przepływ zobrazowano na kolejnym schemacie sekwencji:
I
Na schemacie tym przedstawiono:
Protokół
Cykl wiadomości związanych z transakcją obejmuje jedynie dwie wiadomości:
Status transakcji
i w czasie jego rozpatrywania,
Incydenty związane z transakcjami będą obsługiwane z zachowaniem procedur operacyjnych określonych w sekcji wspólnych procedur operacyjnych poświęconej procesowi zarządzania incydentami.
Przekazywane dane będą podlegać czterem poziomom bezpieczeństwa:
3.2.1. Zapora sieciowa i połączenie międzysieciowe
Powiązanie ustanawia się za pośrednictwem sieci zabezpieczonej sprzętową zaporą sieciową. Zaporę sieciową konfiguruje się za pomocą reguł w taki sposób, aby wyłącznie "zarejestrowani" klienci mogli połączyć się z serwerem VPN.
3.2.2. Wirtualna sieć prywatna (VPN)
Wszelka komunikacja między Stronami jest zabezpieczana z wykorzystaniem technologii wirtualnej sieci prywatnej (VPN). W przypadku wirtualnej sieci prywatnej (VPN) infrastruktura powinna opierać się na urządzeniach sprzętowych lub wirtualnych. Technologie VPN zapewniają możliwość "tworzenia korytarza" przez sieć taką jak internet z jednego punktu do drugiego, zabezpieczającego wszelką komunikację. Przed stworzeniem korytarza VPN wydawany jest certyfikat elektroniczny dla punktu końcowego potencjalnego klienta, co pozwala klientowi na dostarczenie potwierdzenia tożsamości w trakcie negocjowania połączenia. Każda ze Stron jest odpowiedzialna za zainstalowanie certyfikatu w swoim punkcie końcowym VPN. Korzystając z certyfikatu elektronicznego, każdy końcowy serwer VPN uzyska dostęp do centrum certyfikacji w celu negocjowania danych uwierzytelniających. Podczas procesu tworzenia korytarza negocjowane jest szyfrowanie, zapewniające, aby wszelka komunikacja za pośrednictwem korytarza była zabezpieczona.
Punkty końcowe klienta VPN konfiguruje się, aby na stałe utrzymać korytarz VPN w celu umożliwienia niezawodnej, dwustronnej komunikacji między Stronami w czasie rzeczywistym w dowolnym momencie.
Ogólnie rzecz biorąc, Unia Europejska korzysta z połączenia z zabezpieczoną transeuropejską telematyczną siecią komunikacyjną między administracjami (STESTA) jako prywatnej sieci opartej na protokole IP. W związku z tym sieć ta nadaje się również do stałego połączenia rejestrów.
3.2.3. Wdrażanie IPSec
W przypadku korzystania z rozwiązania VPN, stosowanie protokołu IPSec celem utworzenia międzylokacyjnej infrastruktury VPN zapewni międzylokacyjne uwierzytelnianie, integrację i szyfrowanie danych. Konfiguracje IPSec w VPN zapewniają właściwe uwierzytelnianie między dwoma punktami końcowymi połączenia VPN. Strony zidentyfikują i uwierzytelnią zdalnego klienta za pośrednictwem połączenia IPSec, korzystając z certyfikatów elektronicznych wydanych przez centrum certyfikacji i uznawanych przez drugi koniec.
IPSec zapewnia również integralność danych wszelkiej komunikacji prowadzonej za pośrednictwem korytarza VPN. Pakiety danych są skracane i podpisywane z wykorzystaniem informacji uwierzytelniających ustanowionych przez VPN. Poufność danych jest zapewniana w podobny sposób - poprzez umożliwienie szyfrowania IPSec.
3.2.4. Protokół bezpiecznego przekazywania wymiany wiadomości
Stałe powiązanie rejestrów opiera się na wielu warstwach szyfrowania służących bezpiecznej wymianie danych między Stronami. Oba systemy i ich różne środowiska są wzajemnie powiązane na poziomie sieci za pomocą korytarzy VPN. Na poziomie aplikacji pliki są przekazywane z wykorzystaniem protokołu bezpiecznego przekazywania wymiany wiadomości na poziomie sesji.
3.2.5. Szyfrowanie i podpisywanie w formacie XML
W ramach plików XML podpisywanie i szyfrowanie odbywa się na dwóch poziomach. Każdy wniosek o transakcję, odpowiedź na wniosek o transakcję oraz komunikat dotyczący uzgodnienia są elektronicznie podpisywane indywidualnie.
Na drugim etapie każdy element podrzędny elementu "wiadomość" jest indywidualnie szyfrowany.
Ponadto, jako trzeci etap oraz w celu zapewnienia integralności i niezaprzeczalności całej wiadomości, wiadomość będąca elementem podstawowym jest podpisywana elektronicznie. Skutkuje to wysokim poziomem zabezpieczenia danych opartych na formacie XML. Przy technicznym wdrożeniu przestrzega się norm ustanowionych przez konsorcjum World Wide Web.
Aby odszyfrować i zweryfikować wiadomość proces jest wykonywany w odwrotnej kolejności.
3.2.6. Klucze kryptograficzne
Do celów szyfrowania i podpisywania stosowana będzie kryptografia wykorzystująca klucz publiczny.
W szczególnym przypadku IPSec korzysta się z certyfikatu elektronicznego wydanego przez centrum certyfikacji i uznawanego przez obie Strony. To centrum certyfikacji weryfikuje tożsamość posiadacza certyfikatu i wydaje certyfikaty, które są wykorzystywane do niepodważalnej identyfikacji organizacji i ustanowienia kanałów bezpiecznej transmisji danych między Stronami.
Z kluczy kryptograficznych korzysta się do podpisywania i szyfrowania kanałów komunikacji i plików z danymi. Publiczne certyfikaty są elektronicznie wymieniane między Stronami z wykorzystaniem bezpiecznych kanałów i weryfikowane w sposób pozapasmowy. Procedura ta stanowi integralną część procesu zarządzania bezpieczeństwem informacji określonego we wspólnych procedurach operacyjnych.
Powiązanie określa system przesyłania szeregu funkcji realizujących procesy biznesowe wynikające z Umowy. Powiązanie obejmuje również specyfikację procesu uzgadniania oraz wiadomości testowych, które umożliwią wdrożenie monitorowania pulsu.
3.3.1. Transakcje handlowe
Z perspektywy handlowej powiązanie uwzględnia cztery (4) rodzaje wniosków o transakcję.
Operatorzy statku powietrznego administrowani za pośrednictwem jednego ETS mający obowiązki wobec drugiego ETS oraz uprawnieni do otrzymania bezpłatnych uprawnień od tego drugiego ETS otrzymają bezpłatne uprawnienia do emisji lotniczych od tego drugiego ETS w drodze transakcji przydziału międzynarodowego.
Transakcja ta będzie miała miejsce w przypadku, w którym przydział bezpłatnych uprawnień do rachunku posiadania operatora statku powietrznego w ramach drugiego ETS będzie musiał zostać cofnięty w całości.
Podobny do cofnięcia, ale w przypadku gdy przydział nie musi być w pełni cofnięty i konieczne jest zwrócenie do przydzielającego ETS jedynie uprawnień przydzielonych w nadmiarze.
3.3.2. Protokół uzgadniania
Uzgodnienia będą mieć miejsce dopiero po zamknięciu okien przyjmowania, zatwierdzania i przetwarzania wiadomości.
Uzgodnienia stanowią integralną część środków służących zachowaniu bezpieczeństwa i spójności powiązania. Obie Strony ustalą dokładne terminy uzgodnień przed sporządzeniem harmonogramu. Zaplanowane codzienne uzgodnienia mogą się odbywać, jeżeli obie Strony wyrażą na nie zgodę. Co najmniej jedno zaplanowane uzgodnienie będzie wykonywane po każdym przeprowadzeniu przyjęcia.
Mimo to każda ze Stron może rozpocząć ręczne uzgodnienia w dowolnym momencie.
Zmiany terminów i częstotliwości zaplanowanych uzgodnień będą obsługiwane z zachowaniem procedur operacyjnych określonych w sekcji wspólnych procedur operacyjnych poświęconej procesowi realizacji wniosków.
3.3.3. Wiadomość testowa
Wiadomość testowa ma służyć testowaniu łączności typu koniec-koniec. Wiadomość będzie zawierać dane, które wskażą, że jest to wiadomość testowa, i po otrzymaniu jej przez drugi koniec zostanie przesłana na nią odpowiedź.
Aby wesprzeć konieczność zachowywania przez obie Strony odpowiednich i spójnych informacji oraz zapewnić narzędzia do wykorzystania w procesie uzgadniania służące do usunięcia niespójności, obie Strony będą prowadzić cztery (4) rodzaje dzienników danych:
Wszelkie dane w tych dziennikach muszą być przechowywane przez okres co najmniej trzech (3) miesięcy do celów rozwiązywania problemów, a ich dalsze zachowanie będzie zależeć od mającego zastosowanie prawa na każdym końcu na potrzeby przeprowadzenia audytu. Pliki dziennika starsze niż trzy (3) miesiące można zarchiwizować w bezpiecznej lokalizacji w niezależnym systemie informatycznym, o ile ich wyszukanie lub uzyskanie do nich dostępu będzie możliwe w rozsądnym czasie.
Dzienniki transakcji
Zarówno podsystem EUTL, jak i podsystem SSTL, obejmuje wdrożenie dzienników transakcji.
Dokładniej rzecz ujmując, w dziennikach transakcji będzie rejestrowana każda propozycja transakcji wysyłana do drugiego ETS. Każdy zapis zawiera wszystkie pola treści transakcji oraz późniejszy wynik transakcji (odpowiedź ETS otrzymującego propozycję). W dziennikach transakcji będą rejestrowane również transakcje przychodzące, a także odpowiedzi wysyłane do ETS pochodzenia.
Dzienniki uzgadniania
Dziennik uzgadniania zawiera zapis każdego komunikatu dotyczącego uzgodnienia wymienionego między obiema Stronami, w tym identyfikator uzgodnienia, znacznik czasowy i wynik uzgodnienia: status uzgodnienia "przyjęte" lub "rozbieżne". W ramach stałego powiązania rejestrów komunikaty dotyczące uzgodnienia stanowią integralną część wymienianych wiadomości i w związku z tym są przechowywane zgodnie z opisem w sekcji "Archiwum wiadomości".
Obie Strony rejestrują każdy wniosek i odpowiedź w dzienniku uzgadniania. Chociaż informacje zamieszczane w dzienniku uzgadniania nie są udostępniane bezpośrednio jako część samego uzgodnienia, dostęp do tych informacji może być konieczny, aby rozstrzygnąć niespójności.
Archiwum wiadomości
Wymaga się, aby obie Strony archiwizowały kopie wymienianych danych (pliki XML), wysyłanych i otrzymywanych oraz fakt, czy dane te lub wiadomości XML miały odpowiedni format.
Archiwum ma służyć głównie do celów przeprowadzania audytu - posiadania dowodu tego, co zostało wysłane drugiej Stronie i od niej otrzymane. W tym kontekście wraz z plikami należy archiwizować również powiązane z nimi certyfikaty.
Pliki te dostarczą także dodatkowych informacji na potrzeby rozwiązywania problemów.
Ścieżki audytu wewnętrznego
Dzienniki te są określane i stosowane przez Strony we własnym zakresie.
Wymiana danych między obydwoma systemami w ramach stałego powiazania rejestrów nie jest w pełni niezależna, co oznacza, że do uruchomienia powiązania wymaga operatorów i procedur. W tym celu szczegółowo opisano kilka ról i narzędzi.
Architekturę stałego powiazania rejestrów stanowią zasadniczo infrastruktura z zakresu technologii informacyjno- komunikacyjnych i oprogramowanie, które umożliwiają komunikację między ETS Szwajcarii i EU ETS. Zapewnienie wysokiego poziomu dostępności, integralności i poufności tego przepływu danych staje się zatem podstawowym aspektem, który należy uwzględnić przy opracowywaniu stałego powiązania rejestrów. W przypadku projektu, w którym infrastruktura z zakresu technologii informacyjno-komunikacyjnych, niestandardowe oprogramowanie oraz procesy odgrywają integralną rolę, należy wziąć pod uwagę wszystkie trzy elementy, aby opracować odporny system.
Odporność infrastruktury z zakresu technologii informacyjno-komunikacyjnych
Podstawowe elementy architektoniczne szczegółowo opisano w rozdziale niniejszego dokumentu dotyczącym przepisów ogólnych. Po stronie infrastruktury z zakresu technologii informacyjno-komunikacyjnych stałe powiazanie rejestrów ustanawia odporną sieć VPN tworzącą zabezpieczone korytarze komunikacji, za pośrednictwem których odbywa się bezpieczna wymiana wiadomości. Inne elementy infrastruktury są konfigurowane w wysokiej dostępności lub opierają się na mechanizmach rezerwowych.
Odporność niestandardowego oprogramowania
Niestandardowe moduły oprogramowania zwiększają odporność poprzez ponawianie próby nawiązania komunikacji z drugim końcem przez określony czas, jeżeli z jakiegoś powodu jest on niedostępny.
Odporność usługi
W ramach stałego powiazania rejestrów wymiana danych między Stronami odbywa się we wcześniej określonych przedziałach czasowych przez cały rok. Niektóre z etapów niezbędnych podczas uprzednio zaplanowanej wymiany danych wymagają ręcznej interwencji operatorów systemu lub administratorów rejestru. Biorąc ten aspekt pod uwagę oraz w celu zwiększenia dostępności i powodzenia wymiany:
Wszystkie poszczególne elementy związane z architekturą stałego powiazania rejestrów muszą przejść serię indywidualnych i wspólnych testów, aby potwierdzić, że platforma na poziomie infrastruktury z zakresu technologii informacyjno-komunikacyjnych oraz systemu informacyjnego jest gotowa. Przeprowadzenie tych testów operacyjnych jest obowiązkowym warunkiem wstępnym za każdym razem, gdy platforma zmienia status stałego powiazania rejestrów z zawieszonego na funkcjonujący.
Aktywacja statusu powiązania, który oznacza funkcjonowanie, wymaga zatem wykonania uprzednio określonego planu testów z powodzeniem. Musi to potwierdzić, że przed rozpoczęciem składania wniosków o transakcje dotyczące produkcji między obiema Stronami, każdy rejestr przeprowadził najpierw szereg wewnętrznych testów, a następnie zatwierdził łączność koniec-koniec.
W planie testów należy wskazać ogólną strategię testów oraz podać szczegółowe informacje na temat infrastruktury testowania. W szczególności w odniesieniu do każdego elementu we wszystkich blokach testów plan ten musi obejmować:
Jako proces, testy dotyczące aktywacji statusu oznaczającego funkcjonowanie można podzielić na cztery (4) konceptualne bloki lub etapy.
4.2.1. Testy wewnętrznej infrastruktury z zakresu technologii informacyjno-komunikacyjnych
Testy te mają być przeprowadzone lub poddane kontroli indywidualnie przez administratorów rejestru każdej ze Stron.
Wszystkie elementy infrastruktury z zakresu technologii informacyjno-komunikacyjnych na każdym końcu muszą być przetestowane indywidualnie. Obejmuje to każdy pojedynczy komponent infrastruktury. Testy te można wykonać automatycznie lub ręcznie, ale muszą one zweryfikować, czy każdy element infrastruktury funkcjonuje.
4.2.2. Testy komunikacji
Testy te są uruchamiane indywidualnie przez każdą ze Stron, a
Gdy poszczególne elementy funkcjonują, należy przetestować kanały komunikacji między obydwoma rejestrami. W tym celu każda Strona weryfikuje, czy dostęp do internetu działa, czy ustanowiono kanały VPN oraz czy istnieje międzylokacyjne połączenie IP. Następnie należy potwierdzić drugiemu końcowi, że elementy infrastruktury lokalnej i zdalnej oraz połączenie IP są możliwe do osiągnięcia.
4.2.3. Testy całego systemu (koniec-koniec)
Testy te wykonuje się na każdym końcu, a wyniki muszą być udostępnione drugiej Stronie.
Po przetestowaniu kanałów komunikacji i wszystkich poszczególnych komponentów obu rejestrów każdy koniec przygotowuje serię symulowanych transakcji i uzgodnień reprezentatywnych dla wszystkich funkcji, które mają zostać wdrożone w ramach powiązania.
4.2.4. Testy bezpieczeństwa
Testy te mają być przeprowadzone lub zainicjowane przez administratorów rejestru każdej ze Stron, jak wyszczególniono w sekcji 5.4 "Wytyczne testowania bezpieczeństwa" oraz 5.5 "Przepisy dotyczące oceny ryzyka".
Stałe powiązanie rejestrów można uznać za posiadające status oznaczający funkcjonowanie, dopiero gdy wszystkie cztery etapy/bloki zakończą się przewidywalnymi wynikami.
Zasoby testowania
Każda Strona polega na określonych zasobach testowania (konkretnej infrastrukturze oprogramowania i sprzętu z zakresu technologii informacyjno-komunikacyjnych) i opracowuje funkcje testowania w swoich odnośnych systemach w celu wsparcia ręcznego i nieustannego sprawdzania platformy. Administratorzy rejestru mogą przeprowadzić ręczne indywidualne lub wspólne procedury testowania w dowolnym momencie. Aktywacja statusu oznaczającego funkcjonowanie sama w sobie jest procesem ręcznym.
Podobnie przewidziano, że platforma dokonuje automatycznych kontroli w regularnych odstępach czasu. Kontrole te służą zwiększeniu dostępności platformy poprzez wczesne wykrywanie potencjalnych problemów z infrastrukturą lub oprogramowaniem. Ten program monitorowania platformy składa się z dwóch elementów:
Architektura rejestru Unii i rejestru Szwajcarii składa się z następujących trzech środowisk: - produkcyjnego: środowisko to przechowuje rzeczywiste dane i przetwarza rzeczywiste transakcje,
Z wyjątkiem VPN te trzy środowiska są w pełni niezależne od siebie, co oznacza, że sprzęt, oprogramowanie, bazy danych, środowiska wirtualne, adresy IP i porty są ustanawiane i funkcjonują niezależnie od siebie.
Jeżeli chodzi o strukturę VPN, komunikacja między trzema środowiskami musi być w pełni niezależna, co zapewnia wykorzystanie STESTA.
W ramach mechanizmów i procedur bezpieczeństwa przewidziano dwuosobową rolę (zasadę czworga oczu) odnoszącą się do operacji odbywających się za pośrednictwem powiązania między rejestrem Unii i rejestrem Szwajcarii. Dwuosobowa rola ma zastosowanie zawsze, gdy zajdzie taka potrzeba. Jednakże może nie mieć zastosowania do wszystkich kroków podejmowanych przez administratorów rejestru.
Wymogi bezpieczeństwa rozważa się i uwzględnia w planie zarządzania bezpieczeństwem, który obejmuje również procesy związane z obsługą incydentów dotyczących bezpieczeństwa w następstwie ewentualnego naruszenia bezpieczeństwa. Operacyjną część tych procesów opisano we wspólnych procedurach operacyjnych.
Każda Strona angażuje się w ustanowienie infrastruktury testowania bezpieczeństwa (korzystając ze wspólnego zestawu sprzętu i oprogramowania wykorzystywanego do wykrywania luk na etapie opracowywania i funkcjonowania):
Każda Strona zobowiązuje się do przeprowadzenia zarówno analizy statycznej, jak i dynamicznej.
W przypadku analizy dynamicznej (takiej jak testy penetracyjne) obie Strony zobowiązują się do ograniczenia ocen zazwyczaj do środowiska testowego i akceptacyjnego (jak określono w sekcji 4.3 "Środowisko akceptacyjne/testowe"). Odstępstwa od tej polityki podlegają wyrażeniu zgody przez obie Strony.
Przed wdrożeniem w środowisku produkcyjnym każdy moduł oprogramowania łącza (jak określono w sekcji 3.1 "Architektura łącza komunikacyjnego") testuje się pod względem bezpieczeństwa.
Infrastruktura testowa musi być oddzielona od infrastruktury produkcyjnej zarówno na poziomie sieci, jak i na poziomie infrastrukturalnym. Testy bezpieczeństwa wymagane do sprawdzenia zgodności z wymogami bezpieczeństwa przeprowadza się w ramach infrastruktury testowej.
W przypadku gdy istnieje podejrzenie, że bezpieczeństwo rejestru szwajcarskiego, SSTL, rejestru Unii lub EUTL zostało naruszone, którakolwiek ze Stron natychmiast przekazuje te informacje drugiej Stronie oraz zawiesza powiązanie między SSTL i EUTL.
Procedury dotyczące udostępnienia informacji, decyzji o zawieszeniu i decyzji o ponownej aktywacji są częścią procesu realizacji wniosku w ramach wspólnych procedur operacyjnych.
Zawieszenia
Zawieszenie powiązania rejestrów zgodnie z załącznikiem II do Umowy może mieć miejsce ze względu na:
W sytuacji awaryjnej którakolwiek ze Stron poinformuje drugą Stronę i jednostronnie zawiesi powiązanie rejestrów.
W przypadku podjęcia decyzji o zawieszeniu powiązania rejestrów, każda Strona w związku z tym zapewni, aby powiązanie zostało przerwane na poziomie sieci (poprzez zablokowanie części lub wszystkich połączeń przychodzących i wychodzących).
Decyzja o zawieszeniu powiązania rejestrów, planowanym lub nieplanowanym, zostanie podjęta zgodnie z procedurą zarządzania zmianą lub procedurą zarządzania incydentami związanymi z bezpieczeństwem informacji określoną we wspólnych procedurach operacyjnych.
Ponowna aktywacja komunikacji
Decyzja o ponownej aktywacji powiązania rejestrów zostanie podjęta w sposób określony we wspólnych procedurach operacyjnych i w żadnym wypadku nie nastąpi przed zakończeniem z powodzeniem procedur testowania bezpieczeństwa wyszczególnionych w sekcji 5.4 "Wytyczne testowania bezpieczeństwa" oraz 4.2 "Plan dotyczący inicjowania, komunikacji, ponownej aktywacji oraz testów".
Naruszenie bezpieczeństwa uznaje się za incydent związany z bezpieczeństwem mający wpływ na poufność i integralność informacji szczególnie chronionych lub dostępność przetwarzającego je systemu.
Informacje szczególnie chronione określono w wykazie informacji szczególnie chronionych i można je przetwarzać w systemie lub dowolnej powiązanej części systemu.
Informacje bezpośrednio związane z naruszeniem bezpieczeństwa zostaną uznane za szczególnie chronione, oznaczone jako "SPECIAL HANDLING: ETS Critical" i przetworzone zgodnie z instrukcjami przetwarzania, o ile nie ustanowiono inaczej.
Każde naruszenie bezpieczeństwa będzie rozwiązywane zgodnie z rozdziałem wspólnych procedur operacyjnych dotyczącym zarządzania incydentami związanymi z bezpieczeństwem informacji.
5.4.1. Oprogramowanie
Testowanie bezpieczeństwa, w tym w stosownych przypadkach testy penetracyjne, przeprowadza się przynajmniej na wszystkich głównych nowo wydanych wersjach oprogramowania zgodnie z wymogami bezpieczeństwa określonymi w normach technicznych powiązania, aby ocenić bezpieczeństwo powiązania i związane z nim ryzyko.
Jeżeli w ciągu ostatnich 12 miesięcy nie wydano głównej wersji, testowanie bezpieczeństwa przeprowadza się na obecnym systemie, biorąc pod uwagę rozwój zagrożeń dla cyberbezpieczeństwa, który nastąpił na przestrzeni ostatnich 12 miesięcy.
Testowania bezpieczeństwa powiązania rejestrów dokonuje się w środowisku akceptacyjnym i - jeżeli jest to wymagane - w środowisku produkcyjnym oraz przy koordynacji i wzajemnym porozumieniu obu Stron.
Testowanie aplikacji sieciowej odbędzie się z zachowaniem międzynarodowych standardów otwartych, takich jak standardy opracowane przez Projekt Bezpieczeństwa Aplikacji Sieci Otwartej (OWASP).
5.4.2. Infrastruktura
Infrastruktura wspierająca system produkcji musi być regularnie poddawana przeglądowi pod kątem luk (co najmniej raz w miesiącu), a wykryte luki muszą być naprawiane. Testowanie przeprowadza się zgodnie z metodą opisaną w sekcji 5.4.1, przy użyciu aktualnej bazy danych dotyczących luk.
Jeżeli stosowane są testy penetracyjne, muszą one zostać uwzględnione w testowaniu bezpieczeństwa.
Każda Strona może udzielić zamówienia na przeprowadzenia testowania bezpieczeństwa specjalizującemu się w tym przedsiębiorstwu, o ile przedsiębiorstwo to:
| Identyfikator: | Dz.U.UE.L.2021.226.16 |
| Rodzaj: | decyzja |
| Tytuł: | Decyzja 2020/2 w sprawie zmiany załącznika I i II do umowy oraz przyjęcia norm technicznych powiązania |
| Data aktu: | 2020-11-05 |
| Data ogłoszenia: | 2021-06-25 |
| Data wejścia w życie: | 2020-11-05 |