uwzględniając Traktat o funkcjonowaniu Unii Europejskiej, w szczególności jego art. 192 ust. 1 w związku z art. 218 ust. 9,
uwzględniając wniosek Komisji Europejskiej,
(1) Umowa między Unią Europejską a Konfederacją Szwajcarską w sprawie powiązania ich systemów handlu uprawnieniami do emisji gazów cieplarnianych 1 (zwana dalej "umową") została podpisana w dniu 23 listopada 2017 r. zgodnie z decyzją Rady (UE) 2017/2240 2 .
(2) Umowa została zawarta decyzją Rady (UE) 2018/219 3 i weszła w życie w dniu 1 stycznia 2020 r.
(3) Zgodnie z art. 12 ust. 3 umowy Wspólny Komitet może przyjmować decyzje, które z chwilą ich wejścia w życie są wiążące dla Stron.
(4) Art. 13 ust. 2 umowy przewiduje, że Wspólny Komitet może dokonać zmian w załącznikach do umowy.
(5) Art. 3 ust. 6 i 7 stanowią, że wspólne procedury operacyjne i normy techniczne powiązania powinny stać się skuteczne z chwilą ich przyjęcia w drodze decyzji Wspólnego Komitetu. Decyzją nr 1/2020 4 i 2/2020 5 Wspólny Komitet przyjął odpowiednio wspólne procedury operacyjne i normy techniczne powiązania.
(6) Należy zmienić załącznik II do umowy, aby odzwierciedlić zmiany powiązania rejestrów między unijnym systemem handlu uprawnieniami do emisji a szwajcarskim systemem handlu uprawnieniami do emisji oraz dostosować przepisy załącznika II w świetle rozwoju technologicznego. Aby zapewnić spójność wspólnych procedur operacyjnych i norm technicznych powiązania z załącznikiem II, dokumenty te również należy zmienić.
(7) Wspólny Komitet ma przyjąć decyzję w odniesieniu do zmiany załącznika II do umowy, oraz zmiany wspólnych procedur operacyjnych i norm technicznych powiązania, podczas swojego siódmego posiedzenia lub wcześniej w drodze procedury pisemnej zgodnie z art. 8 ust. 4 regulaminu wewnętrznego Wspólnego Komitetu 6 .
(8) Należy ustalić stanowisko, jakie ma zostać zajęte w imieniu Unii w ramach Wspólnego Komitetu w odniesieniu do zmiany załącznika II do umowy, oraz zmiany wspólnych procedur operacyjnych i norm technicznych powiązania, gdyż jego decyzja będzie wiążąca dla Unii,
(9) Stanowisko Unii w ramach Wspólnego Komitetu powinno opierać się na dołączonym projekcie decyzji,
PRZYJMUJE NINIEJSZĄ DECYZJĘ:
Stanowisko, jakie ma zostać zajęte w imieniu Unii na siódmym posiedzeniu Wspólnego Komitetu lub wcześniej w drodze procedury pisemnej zgodnie z art. 8 ust. 4 regulaminu wewnętrznego Wspólnego Komitetu, oparte jest na projekcie decyzji Wspólnego Komitetu dołączonym do niniejszej decyzji.
Niniejsza decyzja wchodzi w życie z dniem jej przyjęcia.
w odniesieniu do zmiany załącznika II do umowy oraz wspólnych procedur operacyjnych i norm technicznych powiązania
WSPÓLNY KOMITET,
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 7 (zwaną dalej "umową"), w szczególności jej art. 9 i art. 13 ust. 2,
a także mając na uwadze, co następuje:
PRZYJMUJE NINIEJSZĄ DECYZJĘ:
Niniejsza decyzja wchodzi w życie z dniem jej przyjęcia.
Sporządzono w ....
ZAŁĄCZNIKI
"ZAŁĄCZNIK II
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łcane 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 realizację 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żliwia uczestnikom rynku działanie tak, jakby byli na jednym rynku, z zastrzeżeniem jedynie indywidualnych przepisów wykonawczych stron.
W normach technicznych powiązania określa się:
– architekturę łącza komunikacyjnego,
– komunikację między SSTL a EUTL,
– bezpieczeństwo przesyłania danych,
– wykaz funkcji (transakcje, uzgodnienia itp.),
– definicję warstwy transportowej,
– wymogi rejestracji danych,
– ustalenia operacyjne (centrum informacyjne, wsparcie),
– plan aktywacji komunikacji i procedurę testowania,
– procedurę testowania bezpieczeństwa.
W normach technicznych powiązania określa się, że administratorzy podejmują wszystkie rozsądne kroki w celu zapewnienia, aby SSTL, EUTL oraz łącze funkcjonowały 24 godziny na dobę, oraz 7 dni w tygodniu, a wszelkie zakłócenia w funkcjonowaniu SSTL, EUTL oraz łącza były ograniczone do minimum.
W normach technicznych powiązania określa się dodatkowe wymogi bezpieczeństwa dla rejestru Szwajcarii, SSTL, rejestru Unii oraz EUTL, a same normy techniczne powiązania odnotowuje się w »planie zarządzania bezpieczeństwem«. W szczególności w normach technicznych powiązania określa się, że:
– jeżeli istnieje podejrzenie, że bezpieczeństwo rejestru Szwajcarii, SSTL, rejestru Unii lub EUTL zostało naruszone, obie strony natychmiast przekazują sobie te informacje oraz zawieszają powiązanie między SSTL i EUTL,
– w przypadku naruszenia bezpieczeństwa strony zobowiązują się do natychmiastowej wymiany informacji na ten temat. W takim zakresie, w jakim dostępne są szczegóły techniczne, w ciągu 24 godzin od uznania incydentu związanego z bezpieczeństwem za naruszenie bezpieczeństwa, sprawozdanie, w którym opisano incydent (datę, przyczynę, skutek, środki zaradcze), udostępnia się administratorowi rejestru Szwajcarii oraz centralnemu administratorowi Unii.
Procedura testowania bezpieczeństwa określona w normach technicznych powiązania musi zakończyć się przed ustanowieniem łącza komunikacyjnego między SSTL a EUTL oraz w każdym przypadku, gdy wymagana jest nowa wersja lub nowe wydanie SSTL lub EUTL.
Normy techniczne powiązania zapewniają, oprócz środowiska produkcyjnego, dwa dodatkowe środowiska testowe: środowisko testowe dla twórców oprogramowania i środowisko akceptacyjne.
Za pośrednictwem administratora rejestru Szwajcarii i centralnego administratora Unii strony przedstawiają dowody na to, że w ciągu ostatnich 12 miesięcy przeprowadzono niezależną ocenę ich systemów zgodnie z wymogami bezpieczeństwa określonymi w normach technicznych powiązania. Testowanie bezpieczeństwa, w szczególności testy penetracyjne, przeprowadza się na wszystkich głównych nowo wydanych wersjach oprogramowania zgodnie z wymogami bezpieczeństwa określonymi w normach technicznych powiązania. Testów penetracyjnych nie może przeprowadzić twórca oprogramowania ani podwykonawca twórcy oprogramowania.".
WSPÓLNE PROCEDURY OPERACYJNE ZGODNIE Z ART. 3 UST. 6 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
1. SŁOWNICZEK
2. WPROWADZENIE
2.1. Zakres
2.2. Adresaci
3. PODEJŚCIE I NORMY
4. ZARZĄDZANIE INCYDENTAMI
4.1. Wykrywanie i rejestracja incydentów
4.2. Klasyfikacja i wstępne wsparcie
4.3. Badanie i diagnoza
4.4. Rozwiązanie i przywrócenie do stanu używalności
4.5. Zamknięcie incydentu
5. ZARZĄDZANIE PROBLEMAMI
5.1. Identyfikacja i rejestracja problemu
5.2. Określanie priorytetu problemów
5.3. Badanie i diagnoza problemu
5.4. Naprawienie
5.5. Zamknięcie problemu
6. REALIZACJA WNIOSKÓW
6.1. Wszczęcie procedury dotyczącej wniosku
6.2. Rejestracja i analiza wniosku
6.3. Zatwierdzenie wniosku
6.4. Realizacja wniosków
6.5. Przekazanie wniosku
6.6. Przegląd realizacji wniosku
6.7. Zamknięcie wniosku
7. ZARZĄDZANIE ZMIANĄ
7.1. Wniosek o zmianę
7.2. Ocena i planowanie zmiany
7.3. Zatwierdzanie zmiany
7.4. Wdrożenie zmiany
8. ZARZĄDZANIE WERSJAMI
8.1. Planowanie wersji
8.2. Tworzenie i testowanie pakietu wersji
8.3. Przygotowanie wdrożenia
8.4. Cofnięcie wersji
8.5. Przegląd i zamknięcie wersji
9. ZARZĄDZANIE INCYDENTAMI ZWIĄZANYMI Z BEZPIECZEŃSTWEM INFORMACJI
9.1. Kategoryzacja incydentów związanych z bezpieczeństwem informacji
9.2. Postępowanie z incydentami związanymi z bezpieczeństwem informacji
9.3. Identyfikacja incydentów związanych z bezpieczeństwem informacji
9.4. Analiza incydentów związanych z bezpieczeństwem informacji
9.5. Ocena wagi incydentu związanego z bezpieczeństwem informacji, przekazywanie go i związana z nim sprawozdawczość
9.6. Sprawozdawczość dotycząca reakcji na incydent związany z bezpieczeństwem informacji
9.7. Monitorowanie, budowanie zdolności i stałe dążenie do doskonałości
10. ZARZĄDZANIE BEZPIECZEŃSTWEM INFORMACJI
10.1. Identyfikacja danych szczególnie chronionych
10.2. Poziomy wrażliwości zasobów informacyjnych
10.3. Przypisywanie zasobów informacyjnych do właściciela
10.4. Rejestracja danych szczególnie chronionych
10.5. Postępowanie z danymi szczególnie chronionymi
10.6. Postępowanie z danymi szczególnie chronionymi
10.7. Zarządzanie certyfikatami/kluczami
Tabela 1-1 Akronimy i definicje
| Akronim/termin | Definicja |
| Centrum certyfikacji | Podmiot, który wydaje certyfikaty elektroniczne. |
| CH | Konfederacja Szwajcarska |
| ETS | System handlu emisjami |
| UE | Unia Europejska |
| IMT | Zespół ds. zarządzania incydentami |
| Zasób informacyjny | Informacja, która ma wartość dla przedsiębiorstwa lub organizacji. |
| IT | Technologia informacyjna |
| ITIL | Information Technology Infrastructure Library - Biblioteka dokumentów dotyczących zarządzania infrastrukturą IT. |
| ITSM | Zarządzanie usługami informatycznymi |
| LTS | Normy techniczne powiązania |
| Rejestr | System rejestracji uprawnień przyznanych na podstawie ETS, służący do śledzenia własności uprawnień utrzymywanych na kontach elektronicznych. |
| RFC | Wniosek o zmianę |
| SIL | Wykaz danych szczególnie chronionych |
| SR | Wniosek o usługę |
| Wiki | Strona internetowa umożliwiająca użytkownikom wymianę informacji i wiedzy w drodze dodawania lub dostosowywania treści bezpośrednio przez przeglądarkę internetową. |
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 do maja 2020 r. lub możliwie szybko po tej dacie, 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. 6 Umowy administrator rejestru Szwajcarii i centralny administrator Unii określają wspólne procedury operacyjne związane z kwestiami technicznymi lub innymi kwestiami, które są niezbędne dla funkcjonowania powiązania, uwzględniając priorytety zawarte w prawodawstwie krajowym. Wspólne procedury operacyjne opracowane przez administratorów staną się skuteczne z chwilą ich przyjęcia w drodze decyzji Wspólnego Komitetu.
Wspólne procedury operacyjne zostały przyjęte przez Wspólny Komitet w drodze jego decyzji nr 1/2020, Zaktualizowane wspólne procedury operacyjne 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 porozumienie Stron Umowy w kwestii ustanowienia podstaw proceduralnych powiązania między rejestrami EU ETS i ETS Szwajcarii. Chociaż nakreślono w nim ogólne wymogi proceduralne dotyczące operacji, do uruchomienia powiązania potrzebne będą dalsze wytyczne techniczne.
Jeżeli chodzi o jego prawidłowe funkcjonowanie, powiązanie będzie wymagało specyfikacji technicznych do dalszego jego uruchomienia. Zgodnie z art. 3 ust. 7 Umowy kwestie te szczegółowo opisano w dokumencie dotyczącym norm technicznych powiązania, który ma być przyjęty w drodze odrębnej decyzji Wspólnego Komitetu.
Wspólne procedury operacyjne mają na celu zapewnienie, aby usługi informatyczne związane z funkcjonowaniem powiązania między rejestrami EU ETS i ETS Szwajcarii były świadczone skutecznie i sprawnie, szczególnie jeżeli chodzi o realizację wniosków o usługę, usuwanie awarii usług, naprawianie problemów, jak również realizację rutynowych zadań operacyjnych zgodnie z międzynarodowymi normami zarządzania usługami informatycznymi.
W przypadku stałego powiązania rejestrów rozwiązania potrzebne będą jedynie następujące zawarte w niniejszym dokumencie wspólne procedury operacyjne:
Niniejsze wspólne procedury operacyjne skierowane są do zespołów wsparcia technicznego rejestrów UE i Szwajcarii.
Poniższe zasady mają zastosowanie do wszystkich wspólnych procedur operacyjnych:
| Kolejne szczeble | UE | CH |
| Pierwszy szczebel | Unijne centrum obsługi | Szwajcarskie centrum obsługi |
| Drugi szczebel | Unijny kierownik ds. operacji (EU Operations Manager) | Szwajcarski kierownik ds. aplikacji rejestru (CH Registry Application Manager) |
| Trzeci szczebel | Wspólny Komitet (może przekazać ten obowiązek zgodnie z art. 12 ust. 5 umowy) | |
| Czwarty szczebel | Wspólny Komitet, jeżeli na trzecim szczeblu przekazano ten obowiązek | |
Proces zarządzania incydentami ma na celu jak najszybsze przywrócenie po incydencie usług informatycznych do normalnego poziomu usług przy jak najmniejszym zakłóceniu działalności.
W ramach zarządzania incydentami należy również zawsze rejestrować incydenty na potrzeby sprawozdawczości oraz współpracować z innymi procesami, aby stale dążyć do usprawnienia.
W ogólnej perspektywie zarządzanie incydentami składa się z następujących działań:
Na wszystkich etapach cyklu życia incydentu proces zarządzania incydentami odpowiada za ciągłe zarządzanie własnością, monitorowanie, śledzenie i komunikację.
Incydent może zostać wykryty przez zespół wsparcia, automatyczne narzędzia monitorujące lub personel techniczny wykonujący rutynowe działania kontrolne.
Po wykryciu incydent musi zostać zarejestrowany i opatrzony niepowtarzalnym identyfikatorem, który umożliwia odpowiednie śledzenie i monitorowanie incydentu. Niepowtarzalnym identyfikatorem incydentu jest identyfikator przydzielony w ramach wspólnego systemu zgłaszania przez centrum obsługi Strony (UE albo Szwajcarii), która poinformowała o incydencie, i musi on być stosowany w całej komunikacji związanej z tym incydentem.
W przypadku wszystkich incydentów punktem kontaktowym powinno być centrum obsługi Strony, która zarejestrowała zgłoszenie.
Klasyfikacja incydentu ma na celu zrozumienie, którego systemu lub której usługi incydent dotyczy i w jakim stopniu, oraz ich identyfikację. Jeżeli klasyfikacja ma być skuteczna, powinna już za pierwszym razem przydzielić incydent do właściwego zasobu, aby przyspieszyć jego rozwiązanie.
W ramach etapu klasyfikacji należy nadać incydentowi kategorię i priorytet, uwzględniając jego wpływ i pilność, aby został rozwiązany w terminie odpowiadającym temu priorytetowi.
Jeżeli incydent może mieć skutki dla poufności lub integralności danych szczególnie chronionych lub skutki dla dostępności systemu, dany incydent określa się również jako incydent związany z bezpieczeństwem informacji i zarządza się nim zgodnie z procesem określonym w rozdziale "Zarządzanie incydentami związanymi z bezpieczeństwem informacji" niniejszego dokumentu.
Jeżeli jest to możliwe, centrum obsługi, które zarejestrowało zgłoszenie, przeprowadza wstępną diagnozę. W tym celu centrum obsługi sprawdzi, czy incydent jest znanym błędem. Jeżeli tak, to sposób rozwiązania lub obejścia problemu jest już znany i udokumentowany.
Jeżeli centrum obsługi uda się rozwiązać incydent, to zamyka incydent na tym etapie, ponieważ główny cel zarządzania incydentami został spełniony (a mianowicie szybkie przywrócenie działania usługi u użytkownika końcowego). Jeżeli nie, to centrum obsługi przekaże incydent do odpowiedniego zespołu ds. rozwiązywania problemów celem dalszego zbadania i zdiagnozowania.
Badanie i diagnozę incydentu przeprowadza się, jeżeli centrum obsługi nie było w stanie rozwiązać incydentu w ramach wstępnej diagnozy i w związku z tym przekazało problem na wyższy szczebel. Przekazanie incydentu jest pełnoprawną częścią procesu badania i diagnozy.
Częstą praktyką stosowaną na etapie badania i diagnozy jest próba odtworzenia incydentu w warunkach kontrolowanych. Ważnym elementem badania i diagnozy incydentu jest zrozumienie właściwej kolejności wydarzeń, które doprowadziły do incydentu.
Przekazanie oznacza uznanie, że incydentu nie da się rozwiązać na obecnym szczeblu wsparcia technicznego i musi on zostać przekazany do grupy wsparcia wyższego szczebla lub do drugiej Strony. Przekazanie może się odbyć na dwa sposoby: poziomo (funkcjonalnie) lub pionowo (hierarchicznie).
Centrum obsługi, które zarejestrowało incydent i uruchomiło procedurę zarządzania nim, jest odpowiedzialne za przekazanie incydentu do odpowiedniego zasobu i za śledzenie ogólnego statusu incydentu i monitorowanie, do kogo jest przypisany.
Strona, której przypisano incydent, jest odpowiedzialna za zapewnienie, aby działania, o które wnioskowano, zostały przeprowadzone terminowo, oraz za przesłanie informacji zwrotnej do centrum obsługi swojej Strony.
Rozwiązanie incydentu i przywrócenie do stanu używalności przeprowadza się po pełnym zrozumieniu incydentu. Znalezienie rozwiązania incydentu oznacza, że zidentyfikowano sposób naprawienia problemu. Faktyczne zastosowanie rozwiązania to etap przywrócenia do stanu używalności.
Gdy odpowiednie zasoby usuną awarię usługi, incydent przekazuje się z powrotem do odpowiedniego centrum obsługi, które zarejestrowało incydent, aby to centrum obsługi potwierdziło użytkownikowi, który zgłosił incydent, że błąd został naprawiony i że incydent można zamknąć. Ustalenia z prac nad incydentem należy zarejestrować na przyszłe potrzeby.
Przywrócenia do stanu używalności może dokonać zespół wsparcia informatycznego lub użytkownik końcowy po otrzymaniu odpowiednich instrukcji.
Zamknięcie to ostatni etap procesu zarządzania incydentami i odbywa się wkrótce po rozwiązaniu incydentu.
Spośród działań, które należy przeprowadzić na etapie zamknięcia, najważniejsze są następujące:
Incydent jest oficjalnie zamknięty po przeprowadzeniu etapu zamknięcia incydentu przez centrum obsługi i poinformowaniu o tym drugiej Strony.
Jeżeli incydent został zamknięty, już się go nie otwiera. Jeżeli niedługo później incydent powtórzy się, nie otwiera się ponownie pierwotnego incydentu, ale rejestruje się nowy.
Jeżeli zarówno unijne, jak i szwajcarskie centrum obsługi śledzi dany incydent, ostateczne zamknięcie jest obowiązkiem centrum obsługi, które zarejestrowało zgłoszenie.
Niniejsza procedura dotyczy sytuacji, gdy zidentyfikowano problem, a tym samym uruchomiono proces zarządzania problemami. Zarządzanie problemami skupia się na poprawie jakości i redukcji liczby zgłaszanych incydentów. Jeden problem może być przyczyną jednego incydentu lub większej ich liczby. Gdy incydent zostanie zgłoszony, celem zarządzania incydentami jest jak najszybsze przywrócenie działania usługi, co może obejmować zastosowanie obejść. Po zarejestrowaniu problemu należy zbadać jego podstawową przyczynę, aby wskazać zmiany, których wprowadzenie zapewni, aby problem i powiązane z nim incydenty nie występowały już więcej.
W zależności od Strony, która utworzyła zgłoszenie, punktem kontaktowym w kwestiach dotyczących danego problemu będzie albo unijne, albo szwajcarskie centrum obsługi.
Niepowtarzalnym identyfikatorem problemu jest identyfikator przydzielony przez narzędzie zarządzania usługami informatycznymi (ITSM). Musi on być stosowany w całej komunikacji związanej z tym problemem.
Procedura zarządzania problemem może zostać uruchomiona w wyniku incydentu lub rozpoczęta z własnej inicjatywy celem naprawienia problemów wykrytych w systemie w dowolnym momencie.
Tak samo jak w przypadku incydentów problemom można nadać kategorię odpowiednią dla ich wagi i priorytetu, aby ułatwić ich śledzenie, uwzględniając wpływ powiązanych incydentów i częstotliwość ich występowania.
Każda ze Stron może zgłosić problem, a centrum obsługi Strony, która rozpoczyna proces, będzie odpowiedzialne za zarejestrowanie problemu, przypisanie go do odpowiedniego zasobu i śledzenie ogólnego statusu problemu.
Zespół ds. rozwiązywania problemów, któremu przekazano problem, ma obowiązek zająć się tym problemem w stosownym terminie i komunikować się z centrum obsługi.
Jeżeli zostaną do tego wezwane, obie Strony odpowiadają za zapewnienie, aby przydzielone działania zostały przeprowadzone, oraz za przesłanie informacji zwrotnej do centrum obsługi swojej Strony.
Zespół ds. rozwiązywania problemów, któremu przydzielono problem, odpowiada za naprawienie tego problemu i za przesłanie stosownych informacji do centrum obsługi swojej Strony.
Ustalenia z prac nad problemem należy zarejestrować na przyszłe potrzeby.
Problem jest oficjalnie zamknięty, gdy zostanie naprawiony dzięki wprowadzeniu zmiany. Etap zamknięcia problemu przeprowadza centrum obsługi, które zarejestrowało problem i poinformowało centrum obsługi drugiej Strony.
Proces realizacji wniosków obejmuje kompleksowe zarządzanie wnioskiem dotyczącym nowej lub istniejącej usługi od momentu rejestracji i zatwierdzenia do zamknięcia. Wnioski o usługę to zazwyczaj niewielkie, określone wcześniej, powtarzalne, częste, uprzednio zatwierdzone wnioski o charakterze proceduralnym.
Poniżej przedstawiono najważniejsze działania, które należy przeprowadzić:
Unijne lub szwajcarskie centrum obsługi otrzymuje informacje dotyczące wniosku o usługę pocztą elektroniczną, telefonicznie, za pośrednictwem narzędzia zarządzania usługami informatycznymi (ITSM) lub jakiegokolwiek innego uzgodnionego kanału komunikacji.
W przypadku wszystkich wniosków o usługę punktem kontaktowym będzie unijne albo szwajcarskie centrum obsługi, w zależności od Strony, która zgłosiła wniosek o usługę. Odpowiednie centrum obsługi będzie odpowiedzialne za rejestrację i analizę wniosku o usługę z dochowaniem należytej staranności.
Pracownik centrum obsługi Strony, która zgłosiła wniosek o usługę, sprawdza, czy konieczne jest uzyskanie jakiejkolwiek zgody od drugiej Strony, a jeżeli tak, rozpoczyna proces ich uzyskania. Jeżeli wniosek o usługę nie zostanie zatwierdzony, centrum obsługi odpowiednio aktualizuje i zamyka zgłoszenie.
Niniejszy etap dotyczy skutecznego i sprawnego rozpatrywania wniosków o usługę. Rozróżnia się następujące przypadki:
Po realizacji wniosku o usługę, nadaje mu się status wskazujący, że został rozpatrzony.
W razie potrzeby centrum obsługi może przekazać nierozpatrzony wniosek o usługę do odpowiedniego zasobu (osoby trzeciej).
Wnioski przekazuje się do odpowiednich osób trzecich, tj. wnioski otrzymane przez unijne centrum obsługi muszą przejść przez szwajcarskie centrum obsługi, zanim zostaną przekazane do szwajcarskiej osoby trzeciej - i odwrotnie.
Osoba trzecia, której przekazano wniosek o usługę, ma obowiązek zająć się wnioskiem o usługę terminowo i komunikować się z centrum obsługi, które przekazało wniosek o usługę.
Centrum obsługi, które zarejestrowało wniosek o usługę, jest odpowiedzialne za śledzenie ogólnego statusu wniosku o usługę i monitorowanie, do kogo jest przypisany.
Właściwe centrum obsługi przedkłada zapis wniosku o usługę do ostatecznej kontroli jakości przed zamknięciem wniosku. Ma to na celu upewnienie się, że wniosek o usługę został faktycznie zrealizowany i że dostarczono w odpowiednim stopniu szczegółowości wszystkie informacje niezbędne do opisania cyklu życia wniosku. Ustalenia z prac nad wnioskiem należy ponadto zarejestrować na przyszłe potrzeby.
Jeżeli Strony, którym przypisano wniosek, zgadzają się, że wniosek o usługę został zrealizowany i wnioskodawca uważa sprawę za rozwiązaną, należy nadać wnioskowi status "zamknięty".
Wniosek o usługę jest formalnie zamknięty, gdy centrum obsługi, które zarejestrowało wniosek o usługę, przeprowadziło etap zamknięcia wniosku i poinformowało centrum obsługi drugiej Strony.
Celem procesu jest zapewnienie stosowania standaryzowanych metod i procedur do sprawnego i szybkiego zarządzania wszystkimi zmianami dotyczącymi kontroli infrastruktury informatycznej, aby zminimalizować liczbę incydentów i ich wpływ na usługę. Zmiany w infrastrukturze informatycznej mogą powstać w reakcji na problemy lub na wymogi narzucone z zewnątrz, na przykład zmiany w przepisach, lub mogą zostać aktywnie wprowadzone w wyniku dążenia do osiągnięcia większej sprawności i skuteczności lub w celu umożliwienia bądź odzwierciedlenia inicjatyw dotyczących funkcjonowania.
Proces zarządzania zmianami obejmuje szereg różnych działań, w ramach których zbiera się wszystkie informacje szczegółowe dotyczące wniosku o zmianę na potrzeby przyszłego śledzenia. Procesy te zapewniają, aby zmiana została zatwierdzona i przetestowana przed przekazaniem jej do wdrożenia. Za skuteczne wdrożenie odpowiada proces zarządzania wersjami.
Wniosek o zmianę przedkłada się zespołowi zarządzania zmianą do sprawdzenia i zatwierdzenia. W przypadku wszystkich wniosków o zmianę punktem kontaktowym będzie unijne albo szwajcarskie centrum obsługi w zależności od Strony, która zgłosiła wniosek. Odpowiednie centrum obsługi będzie odpowiedzialne za rejestrację i analizę wniosku o zmianę z dochowaniem należytej staranności.
Wnioski o zmianę mogą powstać w wyniku:
Niniejszy etap obejmuje działania dotyczące oceny i planowania zmiany. Uwzględnia on działania dotyczące określania priorytetów i planowania służące zminimalizowaniu ryzyka i wpływu.
Jeżeli wdrożenie wniosku o zmianę ma skutki zarówno dla UE, jak i Szwajcarii, Strona, która zarejestrowała wniosek o zmianę, weryfikuje ocenę i plan zmiany z drugą Stroną.
Każdy zarejestrowany wniosek o zmianę musi zostać zatwierdzony na odpowiednim szczeblu.
Zmiany wdraża się w ramach procesu zarządzania wersjami. Zespoły ds. zarządzania wersjami obu Stron stosują swoje własne procesy, które obejmują planowanie i testowanie. Przeglądu zmiany dokonuje się po zakończeniu wdrażania. W celu zapewnienia, aby wszystko poszło zgodnie z planem, obowiązujący proces zarządzania zmianami jest stale poddawany przeglądowi i aktualizowany w razie konieczności.
Wersja to jedna lub większa liczba zmian w usłudze informatycznej zebranych w planie wersji, które muszą zostać razem zatwierdzone, przygotowane, stworzone, przetestowane i wdrożone. Jedna wersja może oznaczać poprawkę błędu, zmianę w sprzęcie lub w innych komponentach, zmiany w oprogramowaniu, aktualizacje aplikacji, zmiany w dokumentacji lub w procesach. Zawartość każdej wersji organizuje się, testuje i wdraża jako jedną całość.
Zarządzanie wersjami ma na celu planowanie, tworzenie, testowanie i sprawdzanie oraz zapewnianie zdolności do świadczenia zaprojektowanych usług, które spełnią wymogi zainteresowanych stron i pozwolą osiągnąć zamierzone cele. Kryteria akceptacji wszelkich zmian w usłudze zostaną określone i udokumentowane podczas etapu koordynacji projektu i przekazane do zespołów zarządzania wersjami.
Wersja zazwyczaj składa się z szeregu poprawek służących rozwiązaniu problemu i usprawnieniu usługi. Obejmuje nowe lub zmienione oprogramowanie oraz wszelki nowy lub zmieniony sprzęt niezbędne do wdrożenia zatwierdzonych zmian.
Pierwszy etap procesu polega na przypisaniu zatwierdzonych zmian do pakietów wersji oraz określeniu zakresu i zawartości wersji. W oparciu o te informacje w podprocesie planowania wersji opracowuje się harmonogram tworzenia, testowania i wdrożenia wersji.
W planowaniu należy określić:
Strony informują się nawzajem o swoich planach dotyczących wersji i planowych pracach konserwacyjnych. Jeżeli dana wersja dotyczy zarówno UE, jak i Szwajcarii, Strony koordynują swoje plany i ustalają wspólny termin prac konserwacyjnych.
Etap tworzenia i testowania w ramach procesu zarządzania wersjami polega na określeniu metody służącej do wykonania wersji lub pakietu wersji oraz do utrzymania środowisk kontrolowanych przed zmianą środowiska produkcyjnego, a także testowania wszystkich zmian we wszystkich wdrożonych środowiskach.
Jeżeli dana wersja dotyczy zarówno UE, jak i Szwajcarii, Strony koordynują swoje plany dostarczenia i testy. Obejmuje to następujące aspekty:
Wraz z zakończeniem tego podprocesu wszystkie niezbędne elementy wersji są gotowe do przejścia do etapu wdrożenia do środowiska produkcyjnego.
Podproces przygotowania zapewnia, aby plany komunikacji zostały poprawnie określone, a powiadomienia przygotowane do wysłania do wszystkich zainteresowanych stron i użytkowników końcowych, na których zmiany będą miały wpływ, oraz aby wersja była zintegrowana z procesem zarządzania zmianami w celu zapewnienia, aby wszystkie zmiany dokonywały się w sposób kontrolowany i po zatwierdzeniu przez odpowiednie fora.
Jeżeli dana wersja dotyczy zarówno UE, jak i Szwajcarii, Strony koordynują następujące działania:
Jeżeli wdrożenie nie powiodło się lub podczas testów ustalono, że wdrożenie było nieskuteczne lub nie spełniło uzgodnionych kryteriów akceptacji/jakości, zespoły ds. zarządzania wersjami obu Stron muszą cofnąć zmiany i przywrócić poprzedni stan. Należy poinformować wszystkie niezbędne zainteresowane strony, w tym użytkowników końcowych, na których zmiany wpłyną lub których dotyczyły. Z zastrzeżeniem zatwierdzenia proces można rozpocząć od nowa na którymkolwiek z poprzednich etapów.
Przegląd wdrożenia powinien obejmować następujące działania:
Zarządzanie incydentami związanymi z bezpieczeństwem informacji to proces postępowania z incydentami związanymi z bezpieczeństwem informacji w celu umożliwienia przekazania informacji o incydencie zainteresowanym stronom, których incydent dotyczy; oceny incydentu i ustalenia jego priorytetu; oraz reakcji na incydent służącej rozstrzygnięciu kwestii wszelkich faktycznych, podejrzewanych lub możliwych przypadków naruszenia poufności, dostępności lub integralności szczególnie chronionych zasobów informacyjnych.
Wszystkie incydenty, które wpływają na powiązanie między rejestrem Unii i rejestrem Szwajcarii, analizuje się pod kątem ustalenia, czy nastąpiło naruszenie poufności, integralności lub dostępności jakichkolwiek danych szczególnie chronionych, które wpisano do wykazu danych szczególnie chronionych.
Jeżeli doszło do naruszenia, incydent określa się jako incydent związany z bezpieczeństwem informacji, natychmiast rejestruje się go w narzędziu zarządzania usługami informatycznymi (ITSM) i postępuje się z nim zgodnie z procedurą stosowaną w takim przypadku.
Incydenty związane z bezpieczeństwem informacji należą do obowiązków trzeciego szczebla i ich rozwiązaniem zajmuje się specjalny zespół ds. zarządzania incydentami.
Zespół ds. zarządzania incydentami odpowiada za:
W procesie zarządzania bezpieczeństwem informacji wszystkie informacje dotyczące incydentów klasyfikuje się jako dane o najwyższym poziomie wrażliwości, ale w żadnym wypadku nie niższym niż SENSITIVE: ETS.
W przypadku trwającego postępowania lub słabego punktu, który można nieuczciwie wykorzystać, oraz do momentu jego naprawienia informacje klasyfikuje się jako SPECIAL HANDLING: ETS Critical.
W zależności od rodzaju zdarzenia związanego z bezpieczeństwem, osoba odpowiedzialna za bezpieczeństwo informacji określa odpowiednie organizacje w celu podjęcia z nimi współpracy i włączenia ich do zespołu ds. zarządzania incydentami.
Zespół ds. zarządzania incydentami działa w porozumieniu ze wszystkimi zaangażowanymi organizacjami i odpowiednimi członkami ich zespołów, w zależności od przypadku, w celu zbadania incydentu. Podczas analizy ustala się skalę utraty poufności, integralności lub dostępności zasobu i ocenia się skutki dla wszystkich organizacji, których incydent dotyczy. Następnie określa się działania wstępne i następcze mające na celu rozwiązanie incydentu i zarządzanie jego wpływem, w tym wpływ tych działań na zasoby.
Po określeniu charakteru każdego nowego incydentu jako incydentu związanego z bezpieczeństwem informacji zespół ds. zarządzania incydentami ocenia jego wagę i rozpoczyna najpilniejsze niezbędne działania zgodnie z wagą incydentu.
Zespół ds. zarządzania incydentami uwzględnia rezultaty działań służących ograniczeniu skutków incydentu i przywróceniu do stanu używalności w sprawozdaniu dotyczącym reakcji na incydent związany z bezpieczeństwem informacji. Sprawozdanie przekazuje się na trzeci szczebel za pośrednictwem zabezpieczonej poczty elektronicznej lub innych wspólnie przyjętych metod bezpiecznej komunikacji.
Odpowiedzialna Strona zapoznaje się z rezultatami działań służących ograniczeniu skutków incydentu i przywróceniu do stanu używalności oraz:
Zespół ds. zarządzania incydentami powinien uwzględnić w sprawozdaniu dotyczącym incydentu związanego z bezpieczeństwem informacji - stosując bezpieczne metody - istotne dane szczegółowe, aby zapewnić spójną rejestrację i komunikację oraz umożliwić podjęcie szybkich i odpowiednich działań służących ograniczeniu skutków incydentu. Po zakończeniu prac nad sprawozdaniem zespół ds. zarządzania incydentami przedstawia w odpowiednim terminie sprawozdanie końcowe dotyczące incydentu związanego z bezpieczeństwem informacji.
Zespół ds. zarządzania incydentami przekaże sprawozdania dotyczące wszystkich incydentów związanych z bezpieczeństwem informacji na trzeci szczebel. Sprawozdania zostaną wykorzystane na tym szczeblu do ustalenia:
Zarządzanie bezpieczeństwem informacji ma na celu zapewnienie poufności, integralności i dostępności należących do danej organizacji niejawnych informacji, danych i usług informatycznych. Poza elementami technicznymi, w tym informacjami dotyczącymi ich budowy i testów (zob. normy techniczne powiązania), do spełnienia wymogów w zakresie bezpieczeństwa dotyczących stałego powiązania rejestrów konieczne są następujące wspólne procedury operacyjne.
Wrażliwość elementu danych ocenia się poprzez ustalenie, jaki wpływ na działalność (na przykład straty finansowe, utrata wizerunku, naruszenie przepisów...) miałoby naruszenie bezpieczeństwa związane z takimi danymi.
Szczególnie chronione zasoby informacyjne identyfikuje się na podstawie wpływu, jaki mają na powiązanie.
Poziom wrażliwości tych danych ocenia się zgodnie ze skalą wrażliwości obowiązującą w przypadku tego powiązania i opisaną szczegółowo w sekcji niniejszego dokumentu zatytułowanej "Postępowanie z incydentami związanymi z bezpieczeństwem informacji".
Po identyfikacji zasobu informacyjnego klasyfikuje go się za pomocą następujących zasad:
Wszystkie zasoby informacyjne powinny być przypisane do określonego właściciela. Zasoby informacyjne ETS należące do powiązania między EUTL i SSTL lub z nim związane powinny zostać zawarte we wspólnym wykazie zasobów utrzymywanym przez obie Strony. Zasoby informacyjne ETS poza powiązaniem między EUTL i SSTL powinny zostać zawarte w wykazie zasobów utrzymywanym przez odpowiednią Stronę.
Strony uzgodnią, kto jest właścicielem każdego zasobu informacyjnego należącego do powiązania między EUTL i SSTL lub z nim związanego. Właściciel zasobu informacyjnego odpowiada za ocenę jego wrażliwości.
Właściciel powinien posiadać poziom uprzywilejowania stosowny do wartości przypisanego mu zasobu lub przypisanych mu zasobów. Należy uzgodnić i sformalizować odpowiedzialność właściciela za zasób lub zasoby oraz obowiązek utrzymywania wymaganego poziomu poufności, integralności i dostępności.
Wszystkie dane szczególnie chronione rejestruje się w wykazie danych szczególnie chronionych.
W stosownych przypadkach uwzględnia się i rejestruje w wykazie danych szczególnie chronionych agregację danych szczególnie chronionych, która mogłaby wywołać większy wpływ niż pojedynczy element danych (na przykład zbiór danych przechowywanych w bazie danych systemu).
Wykaz danych szczególnie chronionych nie jest niezmienny. Zagrożenia, luki w zabezpieczeniach, prawdopodobieństwo lub skutki incydentów związanych z bezpieczeństwem informacji powiązane z tymi zasobami mogą się zmienić bez ostrzeżenia, a do działalności systemów rejestrów mogą zostać wprowadzone nowe zasoby.
W związku z tym dokonuje się regularnego przeglądu wykazu danych szczególnie chronionych i natychmiast rejestruje się w nim wszelkie nowe dane zidentyfikowane jako szczególnie chronione.
Każdy zapis w wykazie danych szczególnie chronionych obejmuje co najmniej następujące informacje:
Podczas przetwarzania poza powiązaniem między rejestrem Unii i rejestrem Szwajcarii z danymi szczególnie chronionymi postępuje się zgodnie z instrukcjami postępowania z informacjami.
Z danymi szczególnie chronionymi przetwarzanymi w ramach powiązania między rejestrem Unii i rejestrem Szwajcarii postępuje się zgodnie z wymogami Stron dotyczącymi bezpieczeństwa.
Celem zarządzania dostępem jest przyznawanie upoważnionym użytkownikom praw do korzystania z usługi oraz uniemożliwienie dostępu użytkownikom nieupoważnionym. Zarządzanie dostępem jest czasem jest nazywane "zarządzaniem prawami" lub "zarządzaniem tożsamością".
W przypadku stałego powiązania rejestrów i jego działania obie Strony muszą posiadać dostęp do następujących elementów:
Administrator rejestru Szwajcarii i centralny administrator Unii zapewniają, aby prawa dostępu były aktualne, oraz pełnią rolę punktów kontaktowych dla swoich Stron w odniesieniu do działań związanych z zarządzaniem dostępem. Wnioski o dostęp rozpatruje się zgodnie z procedurami realizacji wniosków.
Każda ze Stron odpowiada za zarządzanie własnymi certyfikatami/kluczami (generowanie, rejestracja, przechowywanie, instalacja, stosowanie, odnawianie, cofanie, tworzenie kopii zapasowej i odzyskiwanie certyfikatów/kluczy). Jak określono w normach technicznych powiązania, stosuje się jedynie certyfikaty elektroniczne wydane przez centrum certyfikacji uznawane przez obie Strony. Postępowanie z certyfikatami/kluczami i ich przechowywanie muszą być zgodnie z przepisami zawartymi w instrukcjach postępowania z informacjami.
Strony koordynują między sobą wszelkie cofnięcie lub odnowienie certyfikatów i kluczy. Odbywa się to zgodnie z procedurami realizacji wniosków.
Administrator rejestru Szwajcarii i centralny administrator Unii wymienią się certyfikatami/kluczami za pośrednictwem zabezpieczonych środków komunikacji zgodnie z przepisami określonymi w instrukcjach postępowania z informacjami.
Wszelka weryfikacja certyfikatów/kluczy dokonywana jakąkolwiek metodą pomiędzy Stronami odbędzie się w sposób pozapasmowy.
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
1 SŁOWNICZEK
2 WPROWADZENIE
2.1 Zakres
2.2 Adresaci
3 PRZEPISY OGÓLNE
3.1 Architektura łącza komunikacyjnego
3.1.1 Wymiana wiadomości
3.1.2 Wiadomość XML - opis wysokiego poziomu
3.1.3 Okna przyjmowania
3.1.4 Przepływy wiadomości związanych z transakcją
3.2 Bezpieczeństwo przesyłania danych
3.2.1 Zapora sieciowa i połączenie międzysieciowe
3.2.2 Wirtualna sieć prywatna (VPN)
3.2.3 Wdrażanie IPSec
3.2.4 Protokół bezpiecznego przekazywania wymiany wiadomości
3.2.5 Szyfrowanie i podpisywanie w formacie XML
3.2.6 Klucze kryptograficzne
3.3 Wykaz funkcji w ramach powiązania
3.3.1 Transakcje handlowe
3.3.2 Protokół uzgadniania
3.3.3 Wiadomość testowa
3.4 Standardy usług sieciowych
3.5 Konkretna definicja usług sieciowych
4 PRZEPISY DOTYCZĄCE DOSTĘPNOŚCI
4.1 Opracowywanie dostępności komunikacji
4.2 Plan dotyczący inicjowania, komunikacji, ponownej aktywacji oraz testów
4.2.1 Testy wewnętrznej infrastruktury z zakresu technologii informacyjno-komunikacyjnych
4.2.2 Testy komunikacji
4.2.3 Testy całego systemu (koniec-koniec)
4.2.4 Testy bezpieczeństwa
4.3 Środowisko akceptacyjne/testowe
5 PRZEPISY DOTYCZĄCE POUFNOŚCI I INTEGRALNOŚCI
5.1 Infrastruktura testowania bezpieczeństwa
5.2 Przepisy dotyczące zawieszenia i ponownej aktywacji powiązania
5.3 Przepisy dotyczące naruszenia bezpieczeństwa
5.4 Wytyczne dotyczące testowania bezpieczeństwa
5.4.1 Oprogramowanie
5.4.2 Infrastruktura
5.5 Przepisy dotyczące oceny ryzyka
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 |
| 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 | Protokół 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 maju 2020 r. lub możliwie szybko po tej dacie, 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 1/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: - protokół bezpiecznego przekazywania wymiany wiadomości,
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. |
Wiadomość XML obejmuje jeden z następujących elementów:
Każda wiadomość zawiera nagłówek z: - nazwą systemu ETS pochodzenia,
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. |
Transakcje wychodzące
Odzwierciedla to perspektywę ETS przekazującego uprawnienie. Ten konkretny przepływ zobrazowano na kolejnym schemacie sekwencji.
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:
Na schemacie tym przedstawiono:
Protokół
Cykl wiadomości związanych z transakcją obejmuje jedynie dwie wiadomości:
Status transakcji
| 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:
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.
Wszelka komunikacja między Stronami jest zabezpieczana z wykorzystaniem technologii wirtualnej sici 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.
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.
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.
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.
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.
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.
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. |
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.
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.
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.
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.
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:
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 IPi 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. |
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).
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:
W ciągu pierwszych 5 miesięcy obowiązywania mechanizmu konsultacji społecznych projektów ustaw udział w nich wzięły 24 323 osoby. Najpopularniejszym projektem w konsultacjach była nowelizacja ustawy o broni i amunicji. W jego konsultacjach głos zabrało 8298 osób. Podczas pierwszych 14 miesięcy X kadencji Sejmu RP (2023–2024) jedynie 17 proc. uchwalonych ustaw zainicjowali posłowie. Aż 4 uchwalone ustawy miały źródła w projektach obywatelskich w ciągu 14 miesięcy Sejmu X kadencji – to najważniejsze skutki reformy Regulaminu Sejmu z 26 lipca 2024 r.
Grażyna J. Leśniak 24.04.2025
Senat bez poprawek przyjął w środę ustawę, która obniża składkę zdrowotną dla przedsiębiorców. Zmiana, która wejdzie w życie 1 stycznia 2026 roku, ma kosztować budżet państwa 4,6 mld zł. Według szacunków Ministerstwo Finansów na reformie ma skorzystać około 2,5 mln przedsiębiorców. Teraz ustawa trafi do prezydenta Andrzaja Dudy.
Grażyna J. Leśniak 23.04.2025
Rada Ministrów przyjęła we wtorek, 22 kwietnia, projekt ustawy o zmianie ustawy – Prawo geologiczne i górnicze, przedłożony przez minister przemysłu. Chodzi o wyznaczenie podmiotu, który będzie odpowiedzialny za monitorowanie i egzekwowanie przepisów w tej sprawie. Nowe regulacje dotyczą m.in. dokładności pomiarów, monitorowania oraz raportowania emisji metanu.
Krzysztof Koślicki 22.04.2025
Na wtorkowym posiedzeniu rząd przyjął przepisy zmieniające rozporządzenie w sprawie zakazu stosowania materiału siewnego odmian kukurydzy MON 810, przedłożone przez ministra rolnictwa i rozwoju wsi. Celem nowelizacji jest aktualizacja listy odmian genetycznie zmodyfikowanej kukurydzy, tak aby zakazać stosowania w Polsce upraw, które znajdują się w swobodnym obrocie na terytorium 10 państw Unii Europejskiej.
Krzysztof Koślicki 22.04.2025
Od 18 kwietnia policja oraz żandarmeria wojskowa będą mogły karać tych, którzy bez zezwolenia m.in. fotografują i filmują szczególnie ważne dla bezpieczeństwa lub obronności państwa obiekty resortu obrony narodowej, obiekty infrastruktury krytycznej oraz ruchomości. Obiekty te zostaną specjalnie oznaczone.
Robert Horbaczewski 17.04.2025
Kompleksową modernizację instytucji polskiego rynku pracy poprzez udoskonalenie funkcjonowania publicznych służb zatrudnienia oraz form aktywizacji zawodowej i podnoszenia umiejętności kadr gospodarki przewiduje podpisana w czwartek przez prezydenta Andrzeja Dudę ustawa z dnia 20 marca 2025 r. o rynku pracy i służbach zatrudnienia. Ustawa, co do zasady, wejdzie w życie pierwszego dnia miesiąca następującego po upływie 14 dni od dnia ogłoszenia.
Grażyna J. Leśniak 11.04.2025| Identyfikator: | Dz.U.UE.L.2024.1873 |
| Rodzaj: | Decyzja |
| Tytuł: | Decyzja 2024/1873 w sprawie stanowiska, jakie ma być zajęte w imieniu Unii Europejskiej w ramach 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 cieplarnianych, w odniesieniu do zmiany załącznika II do umowy, oraz wspólnych procedur operacyjnych i norm technicznych powiązaniaTekst mający znaczenie dla EOG |
| Data aktu: | 24/06/2024 |
| Data ogłoszenia: | 05/07/2024 |
