Wymagania bezpieczenstwa dla systemów transmisji danych SOWE/(ODM, EL), WIRE/UR.

Transkrypt

1 data: wersja: 7.5a plik: wymagania-ur0075a strona 1/12 Wymagania bezpieczenstwa dla systemów transmisji danych SOWE/(ODM, EL), WIRE/UR. Skrócona metryka dokumentu nazwa przedsiewziecia: Zamawiajacy Wykonawca Budowa systemu informatycznego wspomagajacego funkcje Polskie Sieci Elektroenergetyczne, ul. Mysia 2, Warszawa, Polskie Sieci Elektroenergetyczne Info Sp. z o.o., ul. Mysia 2, Warszawa Kierownik Projektu: Kazimierz Pietka nr wersji dokumentu: 7.5a faza przedsiewziecia: przygotowany przez: zatwierdzony przez: Wymagania bezpieczenstwa dla systemów transmisji danych SOWE/(ODM, EL), WIRE/UR. data dokumentu: Polskie Sieci Elektroenergetyczne - Info Sp. z o.o. data zatwierdzenia: Wojciech Lubczynski - Dyrektor Departamentu Telekomunikacji i Informatyki PSE S.A

2 data: wersja: 7.5a plik: wymagania-ur0075a strona 2/12 Metryka dokumentu Historia dokumentu Autor Nr wersji data Tresc zmian Winuel SA, HP Polska Propozycja dokumentu do zaakceptowania Winuel SA, HP Polska Uzupelnienie Winuel SA, HP Polska Wprowadzenia zmian i rozszerzenie zakresu Winuel SA, HP Polska Wprowadzenia zmian i rozszerzenie zakresu Winuel SA, HP Polska Wprowadzenia zmian i rozszerzenie zakresu Winuel SA, HP Polska Wprowadzenia zmian i rozszerzenie zakresu Polskie Sieci Elektroenergetyczne - Info Sp. z o.o. Polskie Sieci Elektroenergetyczne - Info Sp. z o.o. Polskie Sieci Elektroenergetyczne - Info Sp. z o.o Wprowadzenia zmian i rozszerzenie zakresu Wprowadzenia zmian i rozszerzenie zakresu 7.5a Wprowadzenia zmian i rozszerzenie zakresu Dane dotyczace dokumentu tytul dokumentu : Autor : nazwa calosci projektu : wersja : 7.5a poufnosc : Liczba kopii : 1. N/D Data publikacji : Termin waznosci : nazwa pliku i format : Streszczenie : Wymagania bezpieczenstwa dla systemów transmisji danych SOWE/(ODM, EL), WIRE/UR. Winuel SA, HP Polska, Polskie Sieci Elektroenergetyczne - Info Sp. z o.o. Budowa systemu Informatycznego OSP Do uzytku wewnetrznego PSE i Operatorów Rynku Bezterminowa kolejna wersja anuluje obecna wymagania-ur0075a.doc (Microsoft Word 97 SR-1) Dokument opisuje wymagania techniczne niezbedne do podlaczenia systemu SOWE/(ODM,EL), WIRE/UR do Systemu OSP. Niektóre uzyte w tekscie skróty ABOR - Administrator Bezpieczenstwa Operatora Rynku ABOSP - Administrator Bezpieczenstwa OSP WWZURB - Weryfikacja wymagan pod wzgledem bezpieczenstwa i zezwolenie na przylaczenie systemu informatycznego Operatora Rynku do systemu informatycznego OSP

3 data: wersja: 7.5a plik: wymagania-ur0075a strona 3/12 Spis tresci: 1 Wstep Warunki dostepu do systemu SOWE oraz WIRE Platforma sprzetowa Wymagania sieciowe Adresacja Serwera Ochrona Dostepu Polaczenie systemów OR z OSP Rodzaje styków sieciowych... 5 Styk Podstawowy Styk Zapasowy I Styk Zapasowy II Klasyfikacja Gateway a Adresacja serwerów do IPSec Warunki dostepu do aplikacji Archiwum Rynku Energii () Wymagania sprzetowe Wymagane oprogramowanie Wymagania sieciowe Zasady generowania kluczy publicznych i prywatnych dla uzytkowników i serwerów Procedury Bezpieczenstwa Zalecenia Organizacyjne Procedura WWZURB Procedura Zarzadzania Bezpieczenstwem Systemu OSP i Operatora Rynku Niektóre szczególowe zalecenia polityki bezpieczenstwa Zalecenia Techniczne...12

4 data: wersja: 7.5a plik: wymagania-ur0075a strona 4/12 1 Wstep Dokument przedstawia wymagania techniczne i organizacyjne, stawiane systemom SOWE/EL, SOWE/ODM, WIRE/UR, których spelnienie ma na celu zapewnic bezpieczna wymiane informacji z systemami informatycznymi w OSP (SOWE, WIRE). W dokumencie przedstawione zostaly wszystkie dopuszczalne konfiguracje zapewniajace bezpieczna wymiane informacji, oznacza to, ze konfiguracje inne niz przedstawione w dokumencie nie moga byc zaakceptowane jako infrastruktura stanowiaca dolaczenie do sieci. 2 Warunki dostepu do systemu SOWE oraz WIRE 2.1 Platforma sprzetowa W celu ochrony danych transmitowanych pomiedzy systemami wykorzystany bedzie mechanizm szyfrowania i autoryzacji z wykorzystaniem protokolu IPSec w trybie Transport. Tak przyjete zalozenie dopuszcza do stosowania nastepujace platformy sprzetowe: Producent Platforma System / Operacyjny Klucz Asymetryczny Klucz Symetryczny Rodzaj Tryb komunikacji IBM AIX Y N Serwer Transport Microsoft Windows 2000 N Y Serwer Transport Hewlett-Packard HP-UX Y Y Serwer Transport HP-UX IPSec/9000 UWAGA : Lista produktów i firm moze byc rozszerzona po wykonaniu testów przez Administratora Bezpieczenstwa OSP. 2.2 Wymagania sieciowe Konfiguracja serwera SOWE/(ODM,EL), WIRE/UR dla warstwy sieciowej musi spelniac wymagania : Adresacji adresacja serwera obejmuje adres IP, Ochrony Dostepu szyfrowanie i autoryzacja dostepu Adresacja Serwera Serwer podlaczony do systemu bedzie posiadal adres: Adres IP - nadawany przez Administratora Bezpieczenstwa Systemu OSP Ochrona Dostepu Ochrona dostepu komunikacji serwerów SOWE/(ODM,EL) i WIRE/UR bedzie realizowana poprzez autoryzacje i identyfikacje adresu IP oraz kluczy symetrycznych serwera, a takze na poziomie MQ Series, na podstawie nazwy kanalu i adresu IP. Adres IP musi byc przyporzadkowany jako podstawowy dla interfejsu w celu autoryzacji serwera Polaczenie systemów OR z OSP Systemy OR komunikuja sie z Systemem OSP wykorzystujac nastepujace drogi transmisji danych: 2 lacza 64 kbit sieci lub awaryjne lacze DialUp w przypadku awarii obu lacz sieci. Kazdy serwer powinien posiadac skonfigurowana droge do serwera SOWE OSP lub WIRE OSP. W przypadku awarii lacza podstawowego router znajdujacy sie u OR w Lanie SRGW automatycznie przelaczy ruch na lacze zapasowe, a gdy i to lacze nie dziala, zestawi polaczenie DialUp do access-servera znajdujacego sie u OSP.

5 Mo de mb an k Mo de mb an k dokument : data: wersja: 7.5a plik: wymagania-ur0075a strona 5/12 3 Rodzaje styków sieciowych Na routerach znajdujacych sie u Operatora Rynku w strefie SRGW skonfigurowane sa dwa routery wirtualne (jeden dla ruchu SOWE, drugi dla ruchu WIRE/WWW), na które powinien byc skierowany odpowiedni routing z a OR. W przypadku awarii któregos z lacz routery automatycznie przelacza ruch na dzialajace lacze, a w przypadku awarii obu lacz, zestawia polaczenie Dial-Up. Routery przylaczone do SRGW zakupuje OR, po uzgodnieniu warunków technicznych z Administratorem OSP. Jest mozliwa synchronizacja czasu serwerów OR z siecia. Powinno to nastepowac przy uzyciu protokolu NTP; serwerami czasu dla OR sa routery brzegowe sieci dolaczone do SRGW danego OR. LAN OR LAN SRGW router R1 OR router R2 OR siec router R1 OSP router R2 OSP LAN OSP router ISDN OR ISDN AccessServer AccessServer 3.1 Styk Podstawowy serwer STYK IPSec (Transport Mode) serwer router OR SOWE/ WIRE router OSP NT Strona OR Rys.1 Styk Podstawowy ExtranetVPN (Tunel Mode) Strona OSP EVPN

6 Mode mba nk dokument : data: wersja: 7.5a plik: wymagania-ur0075a strona 6/ Styk Zapasowy I Styk Zapasowy I odpowiada funkcjonalnie stykowi podstawowemu. Styk ten jest wykorzystywany w sytuacjach awaryjnych, w przypadku braku dostepnosci styku podstawowego. Schemat rozwiazania przedstawiony zostal ponizej. serwer STYK IPSec (Transport Mode) serwer router R2 SOWE/ WIRE router OSP Strona OR Strona OSP Rys.2 Styk Zapasowy I 3.3 Styk Zapasowy II Styk Zapasowy II odpowiada funkcjonalnie stykowi zapasowemu I, z ta róznica, ze wykorzystywane sa polaczenia komutowane ISDN. Ponadto jest to styk wykorzystywany w sytuacjach awaryjnych, przy braku dostepnosci Styku Podstawowego oraz Styku Zapasowego I. Schemat rozwiazania przedstawiono ponizej. serwer STYK IPSec (Transport Mode) serwer router ISDN ISDN AccessServer Strona OR Strona OSP Rys.3. Styk Zapasowy II 3.4 Klasyfikacja Gateway a Gateway znajdujacy sie w gestii Operatora Rynku moze byc urzadzeniem typu: Firewall (np. Checkpoint, PIX) zaleca sie ze wzgledów bezpieczenstwa Operatora Rynku. Router (np. CISCO) Oba typy urzadzen moga posiadac mechanizm NAT dla translacji adresów stacji roboczych ExtranetVPN z lokalnych adresów IP do adresów przydzielonych przez OSP.

7 data: wersja: 7.5a plik: wymagania-ur0075a strona 7/ Adresacja serwerów do IPSec Serwery SOWE i WIRE musza stosowac osobne, przyznane przez OSP adresy IP. Wszystkie pakiety IP wychodzace z serwera SOWE musza miec adres zródlowy IP dla SOWE/ODM/EL przyznany przez OSP. Analogicznie dotyczy to serwerów WIRE/UR. Adresy te nie moga podlegac translacji ze wzgledu na wlasciwosci protokolu IPSec (nie mozna stosowac NAT lub PAT). 4 Warunki dostepu do aplikacji Archiwum Rynku Energii () Dostep do bezpiecznego serwera WWW bedzie realizowany ze stacji roboczych klasy PC. Bezpieczenstwo wymiany informacji uzyskujemy poprzez szyfrowanie danych za pomoca technologii ExtranetVPN (AppGate) oraz autoryzacje poprzez karty RSA SecurID (dostepne w Pakiecie Bezpieczenstwa udostepnianym przez Polskie Sieci Elektroenergetyczne Info Sp. z o.o.). 4.1 Wymagania sprzetowe komputer PC, umozliwiajacy uruchomienie oprogramowania wymienionego w pkt. 4.2 karta SecurID firmy RSA Security Inc. 4.2 Wymagane oprogramowanie System operacyjny stacji roboczej - Windows NT 4.0 SP3 lub nowszy, Windows 2000, Windows 98/95 Oprogramowanie Praesidium ExtranetVPN AppGate Client wersja Wymagania sieciowe Stacje robocze moga korzystac z serwera WWW OSP wykorzystujac nastepujace drogi transmisji danych: 2 lacza 64 kbit sieci lub awaryjne lacze DialUp w przypadku awarii obu lacz sieci. Kazda stacja robocza powinna posiadac skonfigurowana droge do serwera WWW OSP. W przypadku awarii lacza podstawowego, routery znajdujace sie u OR automatycznie przelacza ruch na lacze zapasowe, a gdy i to lacze nie dziala, zestawia polaczenie DialUp do access-serwera znajdujacego sie u OSP. Adresy IP stosowane w sieci przez Operatorów Rynku przydziela Administrator Bezpieczenstwa OSP. Sa one przydzielane w momencie rejestracji nowego uzytkownika Archiwum. Pelnoprawnymi uzytkownikami Archiwum WIRE, zostaja reprezentanci OR, którzy pozytywnie przejda Procedure Zarzadzania Uprawnieniami Uzytkowników Archiwum WIRE. 5 Zasady generowania kluczy publicznych i prywatnych dla uzytkowników i serwerów. Do celów systemu SOWE i WIRE stosowane beda dwa typy par kluczy: Para kluczy dla serwera stosowana dla autoryzacji identyfikacji serwerów SOWE i WIRE w implementacji IPSec (GENEROWANA PRZEZ ABOSP) Para kluczy dla uzytkowników stosowana dla autoryzacji i identyfikacji uzytkownika korzystajacego z interfejsu WWW poprzez tunel ExtranetVPN (GENEROWANA PRZEZ ABOR).

8 data: wersja: 7.5a plik: wymagania-ur0075a strona 8/12 W obu przypadkach definiowalne sa nastepujace dane do generacji kluczy: Organizacja ORGANISATION (WYMAGANE) Departament - DEPARTAMENT Lokalizacja (miasto) LOCATION (WYMAGANE) Województwo - STATE Kraj -COUNTRY (WYMAGANE) Adres poczty elektronicznej ABOR (dla serwerów) a dla uzytkowników adres uzytkownika (WYMAGANE) Telefon ABOR (WYMAGANE) Klucz od dlugosci 1024bit (WYMAGANE) W przypadku kluczy i wniosków o certyfikacje kluczy publicznych dla uzytkowników musimy podac równiez dane : Imie i Nazwisko, a dla serwerów nazwe serwera. Wypelnienie tych pól jest wymagane. W oprogramowaniu ExtranetVPN client znajduje sie narzedzie do generowania kluczy i wniosku o certyfikacje klucza publicznego Certyficate Wizard. Klucze dla uzytkowników powinny byc generowane przez uzytkowników systemu OSP, które beda nastepnie podpisywane przez OSP. W przyszlosci zamierza sie dopuscic stosowanie certyfikatów kluczy publicznych trzecich stron zaufania w Polsce. 6 Procedury Bezpieczenstwa Bezpieczenstwo Systemu OSP jest uzaleznione od wszystkich elementów systemu, w tym takze od podlaczonych systemów i aplikacji Operatorów Rynku energii. W celu ograniczenia potencjalnych punktów zagrozen, bezpieczenstwo calosci podzielono na nastepujace aspekty: Organizacyjne okreslajace procedury i wymagania organizacyjne podlaczania i uruchamiania systemów u Operatorów Rynku Techniczne okreslajace narzedzia i mechanizmy ochrony danych - poufnosc, autoryzacja i niezaprzeczalnosc transakcji. 6.1 Zalecenia Organizacyjne Zalecenia organizacyjne specyfikuja zasady podlaczania systemów do Systemu OSP oraz procedury kontroli i dystrybucji informacji niezbednych do podlaczenia systemów Operatorów Rynku. Podstawowe elementy zalecen organizacyjnych to procedury: 1) Weryfikacja wymagan pod wzgledem bezpieczenstwa i zezwolenie na przylaczenie systemu informatycznego Operatora Rynku do systemu informatycznego OSP - WWZURB 2) Zarzadzanie Bezpieczenstwem Systemu OSP i Operatorów Rynku

9 data: wersja: 7.5a plik: wymagania-ur0075a strona 9/ Procedura WWZURB Procedura okresla proces skladania wniosku o podlaczenie systemu Operatora Rynku do Systemu OSP, rozpatrywanie wniosku pod wzgledem bezpieczenstwa, wymagania dotyczace personelu administracyjnego bezpieczenstwa u Operatora Rynku. W procedurze sa stosowane nastepujace formularze: W1 Wniosek o przylaczenie Systemu Operatora Rynku O1 Decyzja o przylaczeniu Systemu Operatora Rynku O2 Decyzja o odrzuceniu Wniosku o przylaczenie Systemu Operatora Rynku WWZURB Wypelnia Uczestnik Rynku Wyslanie Wniosku do Adminsitratora Bezpieczenstwa systemu OSP Wniosek o przylaczenie Systemu Uczestnika Rynku - Formularz W1 ABOSP Uzupelninie Weryfikacja Wniosku pod wzgledem Bezpieczenstwa Decyzja Zatwierdzenia Wniosku Odrzucenie Decyzja o odrzuceniu Wniosku o przyla czenie Systemu Operatra Rynku ABOSP Tak Koniec Wyslanie Decyzji Decyzja o przyla czenie Systemu Opertora Rynku Koniec

10 data: wersja: 7.5a plik: wymagania-ur0075a strona 10/ Procedura Zarzadzania Bezpieczenstwem Systemu OSP i Operatora Rynku Procedura okresla nastepujace reguly: Niezaprzeczalnosc transakcji - wszystkie komunikaty XML opisujace transakcje Rynku Energia musza byc podpisane przez uzytkownika jego kluczem prywatnym, w standardzie MD5. Dostawcy aplikacji musza zapewnic mozliwosc podpisywania transakcji w kolejnych wersjach systemów SOWE i WIRE. Poufnosc Transakcji komunikacja uzytkowników i aplikacji dzialajacych w ramach wspólpracy z system OSP jest szyfrowana kluczem sesyjnym 3DES. Dopuszcza sie w okresie przejsciowym do czasu uzyskania licencji lub niezbednych zezwolen stosowanie algorytmu DES. Identyfikacja i Autoryzacja Elementów Systemu Operatora Rynku i OSP wszystkie elementy beda jednoznacznie identyfikowane na nastepujacych warstwach : Uzytkownika - wszyscy uzytkownicy beda identyfikowani z wykorzystaniem unikalnych kart RSA SecurID oraz certyfikatu elektronicznego zgodnego z norma X.509 wersja 3. Uzytkownik bedzie mial przydzielony unikalny identyfikator user id, wspólny dla wymienionych elementów systemu: aplikacji, systemu operacyjnego, sieci, systemu autoryzacyjnego i certyfikatu X.509. Aplikacji wszystkie aplikacje operatorów rynku beda jednoznacznie identyfikowane na podstawie nazw kolejek MQ Series oraz klucza serwera aplikacyjnego. Sesji zestawianie sesji bedzie mozliwe tylko dla wskazanych portów TCP/UDP, po identyfikacji i autoryzacji przez warstwe Uzytkownika i warstwe Aplikacji. Sieci zestawianie polaczen sieciowych bedzie identyfikowane i autoryzowane na podstawie adresów IP i unikalnego klucza dla serwera aplikacyjnego. Wszystkie systemy, aplikacje i elementy bezpieczenstwa w ramach wspólpracy z Systemem OSP i siecia beda podlegac kontroli bezpieczenstwa przez ABOSP. Wszystkie zmiany konfiguracji urzadzen, serwerów, aplikacji wspólpracujacych z Systemem OSP wymagaja zatwierdzenia przez ABOSP. Systemy, w których stwierdzono niezgodnosc z polityka bezpieczenstwa Systemu OSP nie moga byc uzytkowane w ramach wspólpracy z Systemem OSP. Decyzje o dolaczeniu lub odlaczeniu systemu podejmuja osoby upowaznione przez OSP, na wniosek Administratora Bezpieczenstwa Systemu OSP. Osoby odpowiedzialne ze strony OSP zatwierdzaja wszystkie wnioski i dokumenty okreslone w procedurze WWZURB na wniosek Administratora Bezpieczenstwa Systemu OSP. Osoba odpowiedzialna za nadzorowanie, definiowanie i okreslanie zalecen do polityki bezpieczenstwa Systemu OSP jest Administrator Bezpieczenstwa ABOSP. W szczególnosci odpowiada on za: Nadzór nad bezpieczenstwem systemów i urzadzen podlaczonych do Systemu OSP, znajdujacych sie w gestii PSE. Nadzór polega na badaniu zgodnosci konfiguracji systemów i urzadzen z procedura Zarzadzanie Bezpieczenstwem Operatorów Rynku. Dystrybucje certyfikatów i kluczy pomiedzy Oficerami Bezpieczenstwa a OSP. Dystrybucje kluczy do identyfikacji i autoryzacji uzytkowników. Nadzór nad zasadami generowania kluczy prywatnych i publicznych dla uzytkowników Systemu OSP znajdujacych sie w PSE. Okreslanie zasad bezpiecznego przechowywania kluczy prywatnych oraz kluczy identyfikacyjnych w OSP.

11 data: wersja: 7.5a plik: wymagania-ur0075a strona 11/12 Operator Rynku energii wnioskujacy o przylaczenie do Systemu OSP wyznaczy osobe pelniaca funkcje Administratora Bezpieczenstwa Operatora Rynku - ABOR. Podlaczenie do Systemu OSP realizowane jest po rozpatrzeniu formularza W1 procedury WWZURB, na podstawie formularza O1. Administrator Bezpieczenstwa Operatora Rynku odpowiedzialny jest za: Nadzór nad bezpieczenstwem systemów i urzadzen podlaczonych do Systemu OSP znajdujacych sie w gestii Operatora Rynku. Nadzór polega na badaniu zgodnosci konfiguracji systemów i urzadzen z procedura Zarzadzanie Bezpieczenstwem Operatorów Rynku. Przekazywanie certyfikatów, kart SecurID, kluczy publicznych do certyfikacji pomiedzy Administratorem Bezpieczenstwa a uzytkownikami systemu. Dotyczy to w szczególnosci skladania formularzy W1 oraz dystrybucje kluczy do identyfikacji i autoryzacji uzytkowników. Nadzór nad zasadami generowania kluczy prywatnych i publicznych dla uzytkowników Systemu OSP znajdujacych sie u Operatora Rynku. Okreslanie zasad bezpiecznego przechowywania kluczy prywatnych oraz kluczy identyfikacyjnych Operatora Rynku. Dla wszystkich styków odpowiedzialnosc ABOSP za bezpieczenstwo konczy sie na urzadzeniach aktywnych sieci znajdujacych sie u Operatora Rynku Operatorzy Rynku po przejsciu procedury WWZURB uzyskuja dostep do informacji o sposobie zamawiania i uzyskiwania niezbednego oprogramowania, kluczy i certyfikatów. Klucze prywatne i publiczne uzytkownika, do celów autoryzacji komunikacji ExtranetVPN, beda generowane lokalnie na stacji uzytkownika, pod nadzorem osób odpowiedzialnych za bezpieczenstwo ABOSP lub ABOR. Wszystkie klucze publiczne beda certyfikowane przez System OSP. Kazdy uzytkownik bedzie posiadal: pare kluczy do podpisywania transakcji, pare kluczy do autoryzacji i szyfrowania komunikacji oraz karte SecurID. Wszystkie klucze, certyfikaty elektroniczne i hasla dostepu do kluczy beda wymieniane nie rzadziej niz raz w miesiacu. Wszystkie hasla musza byc dluzsze niz 8 znaków, musza zwierac znaki alfanumeryczne, w tym co najmniej jeden znak specjalny -!#$%^&*()_+-=[{]};: \ <>,.?/. Hasla nie moga sie powtarzac na przestrzeni roku. Systemy Operatorów Rynku powinny synchronizowac swoje wzorce czasu z Systemem OSP. Kazdy element systemu (w tym kazdy uzytkownik systemu) ma przydzielone uprawnienia i zasoby wg. zasady kazdemu wylacznie to co niezbedne. Nie dopuszcza sie mozliwosci udostepniania pelnego dostepu do poszczególnych serwerów, laczy, urzadzen czy zespolów elementów, kazdy uzytkownik korzysta wylacznie z indywidualnego konta z indywidualnie przydzielonymi uprawnieniami wynikajacymi z funkcji jakie pelni w systemie informatycznym lub jakie wynikaja z zalecen ABOSP. 7 Niektóre szczególowe zalecenia polityki bezpieczenstwa Konfiguracja srodowiska bezpieczenstwa wymaga spelnienia nastepujacych regul: 1. Wydzielenie funkcji administratora bezpieczenstwa w celu kontrolowania prawidlowosci konfiguracji infrastruktury bezpieczenstwa.

12 data: wersja: 7.5a plik: wymagania-ur0075a strona 12/12 2. Wnioskodawca musi wyznaczyc osobe odpowiedzialna za kontrole i konfiguracje systemu odpowiednik administratora bezpieczenstwa. 3. Wymiana kluczy pomiedzy PSE i operatorem odbywa sie bezpiecznym kanalem wymiany danych fizyczny nosnik przekazywany wyznaczonej osobie przez wnioskodawce. 4. Okresowo przeprowadzana bedzie kontrola konfiguracji systemów operatorów przez oficera bezpieczenstwa PSE. 5. Kazda zmiana konfiguracji systemów OSP lub OR wymaga weryfikacji pod wzgledem zgodnosci z polityka bezpieczenstwa. 6. Nie spelnienie norm polityki bezpieczenstwa systemów powoduje fizyczne odlaczenie systemu od sieci. 7. Podstawowym mechanizmem autoryzacji i identyfikacji uzytkowników systemu OSP jest mechanizm CRAM SecureID. 8. Podstawowym mechanizmem autoryzacji i identyfikacji systemów SOWE i WIRE jest klucz dostarczany przez OSP. 9. Wymiana kluczy jest realizowana nie rzadziej niz raz w miesiacu. 10. Kazdy uzytkownik systemu OSP i Operatorów rynku bedzie posiadal unikalny (identyczny) identyfikator który ma byc uzywany we wszystkich aplikacjach i systemach operacyjnych i autoryzacyjnych. 8 Zalecenia Techniczne Zalecenia techniczne specyfikuja wymagania jakie powinny spelniac systemy Operatora Rynku na bazie technologii i rozwiazan technicznych stosowanych w celu spelnienia zalecen organizacyjnych. Podstawowe elementy ochrony transakcji sa nastepujace: Dlugosc klucza prywatnego oraz publicznego w standardzie DSS nie mniejsza niz 512bitów. Mechanizm autoryzacji i szyfrowania komunikacji sieciowej serwer-serwer aplikacji zgodny ze standardem IPSec: RFC 2401 Security Architecture for the Internet Protocol RFC 2402 IP Authentication Header RFC 2403 The Use of HMAC-MD5-96 within ESP and AH RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH RFC 2405 The ESP DES-CBC Cipher Algorithm with Explicit IV RFC 2406 IP Encapsulating Security Payload RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP) RFC 2409 The Internet Key Exchange (IKE) RFC 2412 The OAKLEY Key Determination Protocol RFC 2451 The ESP CBC-Mode Cipher Algorithms Dynamiczna negocjacja kluczy sesyjnych do szyfrowania komunikacji sieciowej serwer-serwer aplikacji zgodna ze standardem IKE. Certyfikaty Elektroniczne zgodne ze standardem X.509 wersja 3. Protokól dostepu do repozytorium certyfikatów i kluczy publicznych w systemie OSP zgodny ze standardem LDAP port TCP/UDP 384. Mechanizm identyfikacji uzytkownika zgodny ze standardem stosowanym w systemie OSP. Algorytm szyfrowania 3DES. Protokól synchronizacja czasu zgodny ze standardem NTP.