Załącznik nr 1 do umowy nr ... z dnia ................

OPIS PRZEDMIOTU ZAMÓWIENIA

1. Przedmiotem zamówienia jest: 1) dostawa 16 210 (słownie: szesnaście tysięcy dwieście dziesięć) licencji dla nazwanych

użytkowników Systemu, a także ich instalacja i konfiguracja,2) modernizacja i rozbudowa Systemu,3) udzielenie gwarancji na System i jego prawidłowe działanie, w tym na wszystkie produkty

będące efektem realizacji Przedmiotu Umowy,4) zapewnienie usługi wsparcia technicznego oraz utrzymania Systemu.

2. Zamawiający obecnie jest w posiadaniu Infrastruktury Klucza Publicznego (PKI) opartej o rozwiązania produkcji Comarch S.A. (Comarch CertificateAuthority, Comarch SmartCard 3.1 Comarch SmartCard Reader 3.1, Comarch eSign ver. eP, Comarch eVerify ver. eP) zwanego Centrum Certyfikacji, CA lub Systemem. Wskazane w OPZ parametry techniczne wynikają z konieczności zapewnienia kompatybilności zamawianych urządzeń i oprogramowania z możliwością wykorzystania pełnej funkcjonalności w ramach posiadanego systemu przez Zamawiającego. Na chwilę obecną system wdrożony w Sądzie Apelacyjnym we Wrocławiu zapewnia obsługę 3000 użytkowników, składających podpisy na 1017 centralnych jednostkach rejestrujących na salach rozpraw w sądach apelacyjnych, okręgowych i rejonowych oraz na 3000 stacji komputerowych w sekretariatach wydziałów karnych. Celem niniejszego postępowania o udzielenie zamówienia publicznego jest modernizacja i rozbudowa Centrum Certyfikacji w celu podniesienia niezawodności i wydajności posiadanego rozwiązania, rozszerzenia jego funkcjonalności oraz umożliwienia wydawania certyfikatów dla kolejnych użytkowników systemu.

3. W przypadku dostarczenia rozwiązania równoważnego, wymagana jest obsługa dotychczas wydanych certyfikatów oraz współpraca z oprogramowaniem posiadanym przez Zamawiającego, w którym wykorzystywane są podpisy elektroniczne: ReCourt oraz E-Karta (Moduł Obsługi Klienta Sądowego)

4. Ilekroć w niniejszej OPZ użyto do opisania przedmiotu zamówienia oznaczeń lub parametrów wskazujących konkretnego producenta, konkretny produkt lub wskazano znaki towarowe, patenty lub pochodzenie urządzeń, Zamawiający dopuszcza zastosowanie produktów równoważnych, przez które należy rozumieć produkty o parametrach nie gorszych od przedstawionych w OPZ, kompatybilne (współpracujące) z istniejącą Infrastrukturą Klucza Publicznego w tym samym zakresie, co produkty opisane w OPZ. Zastosowanie rozwiązania równoważnego nie ograniczy funkcjonalności posiadanego systemu przez Zamawiającego i nie będzie powodować konieczności ponoszenia dodatkowych kosztów dla Zamawiającego.

5. W przypadku zaoferowania w ofercie rozwiązań równoważnych, Wykonawca do oferty zobowiązany jest załączyć dokładny opis oferowanych produktów dla każdego z urządzeń równoważnych, z wyszczególnieniem właściwości technicznych i użytkowych, z którego wynikać będzie zachowanie warunków równoważności. Opisy te stanowią dokumenty, o których mowa w art. 25 ust. 1 pkt 2) ustawy.

6. Zamawiający informuje, że zgodnie z art. 30 ust. 5 ustawy, Wykonawca który powołuje się na rozwiązania równoważne do opisywanego przez Zamawiającego, jest obowiązany wykazać, że

oferowane przez niego dostawy spełniają wymagania określone przez Zamawiającego. W tym celu wypełnia formularz techniczny stanowiący załącznik nr 2 do SIWZ.

7. Zamawiający zastrzega sobie prawo przeprowadzenia testów poszczególnych funkcjonalności Systemu zgodnie z procedurą opisaną w niniejszym dokumencie.

8. Zamawiający wymaga aby komponenty (sprzęt oraz oprogramowanie) dostarczone w ramach postępowania posiadały przynajmniej trzyletni serwis producenta dostępny przez 5 dni w tygodniu, 8 godzin dziennie z czasem przystąpienia do usunięcia usterki najpóźniej następnego dnia roboczego po dniu zgłoszenia.

9. Całość oferowanych komponentów (sprzęt oraz oprogramowanie) musi pochodzić z autoryzowanego kanału sprzedaży producentów. Dostarczone urządzenia muszą być nowe (tzn. wyprodukowane nie dawniej niż 6 miesięcy przed ich dostarczeniem), nieużywane.

10. Warunki realizacji zamówienia określone są w projekcie umowy stanowiącym wzór umowy.11. Przedmiot zamówienia wg Wspólnego Słownika Zamówień: 30200000-1 urządzenia

komputerowe, 32420000-3 urządzenia sieciowe, 48700000-5 pakiety oprogramowania użytkowego, 50.00.00.00-5 Usługi naprawcze i konserwacyjne, 72267000-4 Usługi w zakresie konserwacji i napraw oprogramowania.

OPIS TECHNICZNY

I. Modernizacja i rozbudowa posiadanego Systemu.

Na chwilę obecną system wdrożony w Sądzie Apelacyjnym we Wrocławiu zapewnia obsługę 3000 użytkowników, składających podpisy na 1017 centralnych jednostkach rejestrujących na salach rozpraw w sądach apelacyjnych, okręgowych i rejonowych oraz na 3000 stacji komputerowych w sekretariatach wydziałów karnych. Wykonawca poprzez dostarczenie odpowiedniej liczby licencji w ramach niniejszego zamówienia umożliwi zwiększenie ilości obsługiwanych użytkowników o 16 210 osób. Po rozbudowie system Centrum Certyfikacji ma zapewnić obsługę 19 210 użytkowników składających podpisy na 13 000 stacji roboczych oraz umożliwiać łatwą dalszą rozbudowę do 45 000 użytkowników.

W ramach realizacji zamówienia Wykonawca dokona modernizacji i rozbudowy rozwiązania posiadanego przez Zamawiającego. Funkcjonalość Systemu zostanie rozbudowana o moduły OCSP oraz znakowania czasem, System zostanie skonfigurowany do pracy w trybie HA. Komponenty do podpisywania dokumentów i weryfikacji wytworzonego podpisu zostaną wzbogacone o interfejs graficzny. Rozwiązanie posiadane przez Zamawiającego zostanie dostosowane do pracy z nowymi wersjami systemów operacyjnych oraz wzbogacone o nowe funkcjonalności. W ramach wdrożenia rozwiązania Wykonawca przeprowadzi w siedzibie Zamawiającego minimum dwudniowe (2x7 godzin) warsztaty dla administratorów systemu (max. 10 osób).

Schemat oczekiwanej architektury systemu Centrum Certyfikacji przedstawia poniższy rysunek:

Poniżej przedstawiono opis poszczególnych komponentów systemu:1. OCSP Proxy 1 - komponent oprogramowania OCSP (ang. Online Certificate Status Protocol)

pośredniczący w komunikacji pomiędzy głównym modułem OCSP, a zewnętrznymi usługami korzystającymi z udostępnionej usługi OCSP. Komponent będzie zainstalowany na

udostępnionej przez Zamawiającego infrastrukturze wirtualnej. W celu zapewnienia mechanizmów wysokiej dostępności oprogramowanie będzie współpracowało z serwerem zapasowym OCSP Proxy 2 w trybie Active-Active.

2. OCSP Proxy 2 - komponent oprogramowania OCSP pośredniczący w komunikacji pomiędzy głównym modułem OCSP, a zewnętrznymi usługami korzystającymi z udostępnionej usługi OCSP. Komponent będzie zainstalowany na udostępnionej przez Zamawiającego infrastrukturze wirtualnej. W celu zapewnienia mechanizmów wysokiej dostępności oprogramowanie będzie współpracowało z serwerem zapasowym OCSP Proxy 1 w trybie Active-Active.

3. CA 1 / OCSP (IBM x3650M3)Instalacja głównego serwera CA oraz usługi OCSP. Wysoka dostępność CA oraz OCSP zostanie zapewniona poprzez mechanizm HA w trybie active-active. Oprogramowanie zostanie zainstalowane na serwerze fizycznym wykorzystywanym w aktualnej instalacji środowiska CA.

4. CA 2 / OCSP (IBM x3650M3)Zapasowa instalacja serwera CA oraz usługi OCSP. W celu zapewnienia wysokiej dostępności usług serwer będzie pracował w HA w trybie active-active. Do serwera zostanie podłączone urządzenie HSM, które będzie wykorzystane do zapewnienia mechanizmu zapasowego dla głównego urządzenia nShiled Connect 1500 posiadanego przez Zamawiającego. Konfiguracja nShileld Connect 1500 dotycząca kluczy CA zostanie powielona w urządzeniu zapasowym. W przypadku awarii głównego urządzenia HSM, serwer CA 2 / OCSP wraz z zapasowym HSM zapewni realizację wymaganej funkcjonalności. Oprogramowanie zostanie zainstalowane na serwerze fizycznym wykorzystywanym w aktualnej instalacji środowiska CA.

5. CA 3 (IBM x3650M3)Serwer odpowiedzialny za obsługę procedury challenge-response (wyzwanie-odpowiedź) do odblokowania PIN-u. Oprogramowanie zostanie zainstalowane na serwerze fizycznym wykorzystywanym w aktualnej instalacji środowiska CA.

6. DB 1 Główna instancja bazy danych systemu Centrum Certyfikacji. Wysoka dostępność zostanie zapewniona poprzez mechanizm HA w trybie active-active. Baza danych będzie zainstalowana w architekturze wirtualnej dostarczonej przez Zamawiającego.

7. DB 2Zapasowa instancja bazy danych systemu Centrum Certyfikacji. W celu zapewnienia wysokiej dostępności usług serwer będzie pracował w HA w trybie active-active. Baza danych będzie zainstalowana w architekturze wirtualnej dostarczonej przez Zamawiającego.

8. nShield ConnectGłówne urządzenie HSM systemu Centrum Certyfikacji wykorzystywanym w aktualnej instalacji środowiska. Aby zapewnić mechanizm HA konfiguracja urządzenia dotycząca kluczy zostanie powielona na zapasowym urządzeniu HSM, które w razie awarii głównego urządzenia zapewni wymagane funkcjonalności.

9. Load BalancerZamawiający posiada urządzenie load balancer firmy F5 Networks (z oprogramowaniem BIG-IP LTM). Aby zrealizować mechanizm HA w trybie active-active Systemu, wymagane będą zmiany konfiguracyjne urządzenia Load Balancer. Konfiguracja zostanie przeprowadzona przez Wykonawcę pod nadzorem Zamawiającego.

W celu zapewnienia zasobów pod dodatkowe maszyny wirtualne Wykonawca dostarczy dodatkowe kości pamięci RAM o pojemności 16 GB każda w liczbie 18 sztuk.

Parametry pojedynczej kości pamięci RAM:1. Dedykowane do serwera Dell PowerEdge R710 z procesorem Intel Xeon X5560 2,80 GHz2. Pojemność 16 GB3. DDR3 1333 RDIMM LV 2RX4 ECC

Wymagania szczegółowe dla zapasowego urządzenia HSM:1. Urządzenie musi dać się zainstalować w jednym z posiadanych przez Zamawiającego serwerów

(IBM x3650M3) – w slocie PCIe.2. Urządzenie musi posiadać czytnik kart pamięci (ang. Smart Card Reader) – dopuszczalne w

postaci dołączanego zewnętrznego urządzenia.3. Urządzenie musi obsługiwać co najmniej następujące algorytmy szyfrowania:

RSA (1024, 2048, 4096), Diffie-Hellman, DSA, El-Gamal, KCDSA, ECDSA, ECDH, AES, ARIA, Camellia, CAST, DES, RIPEMD160 HMAC, SEED, Triple DES

4. Urządzenie musi obsługiwać następujące funkcje haszujące (mieszające): SHA-1; SHA-2 (224, 256, 384, 512 bit)

5. Urządzenie musi obsługiwać następujące systemy operacyjne: MS Windows 2012 R2/2012/2008 R2/2008/2003 Linux Solaris IBM AIX HP-UX

6. Urządzenie musi spełniać następujące normy oraz posiadać certyfikaty: UL, CE, FCC RoHS, WEEE FIPS 140-2 Level 2/3, NIST SP 800-131A Common Criteria EAL4+

7. Urządzenie musi przetwarzać co najmniej 500 transakcji na sekundę (jako transakcję rozumie się ilość podpisów cyfrowych wykonanych algorytmem RSA z kluczem 1024 bitowym)

8. Urządzenie powinno mieć możliwość zarządzania za pomocą dwóch interfejsów: CLI (ang. Command Line Interface) oraz GUI (ang. Graphical User Interface),

9. Interfejs zarządzający powinien mieć możliwość definiowania tzw. ról użytkowników10. Urządzenie powinno posiadać obsługę protokołu SNMPv311. Urządzenie powinno umożliwiać aktualizowanie oprogramowanie do nowszych wersji,12. Średni czas bezawaryjnej pracy urządzenia powinien wynosić co najmniej 125 000 godzin.13. Urządzenie musi współpracować i umożliwiać konfigurację mechanizmu HA z HSM nShield

Connect 1500 firmy Thales posiadanym przez Zamawiającego.14. Urządzenie musi pochodzić z oficjalnego kanału dystrybucyjnego w Unii Europejskiej.

Wymagania szczegółowe dla modułu OCSP1. Moduł OCSP musi realizować protokół OCSP zgodnie ze standardem RFC 2560.2. Moduł OCSP musi umożliwiać obsługę wielu CCK (Centrów Certyfikacji Kluczy) w ramach jednej

instalacji oprogramowania. 3. Moduł OCSP musi umożliwiać wykorzystanie list CRL (Certificate Revocation List) jako źródła

informacji o unieważnieniach. 4. Moduł OCSP musi umożliwiać pobieranie list CRL (Certificate Revocation List) za pomocą LDAP,

HTTP, HTTPS oraz FTP.5. Moduł OCSP musi umożliwiać wykorzystanie bazy danych CCK jako źródła informacji o

unieważnieniach.6. Moduł OCSP musi umożliwiać synchronizację czasu z centralnym serwerem czasu NTP.7. Moduł OCSP musi współpracować z HSM za pośrednictwem interfejsu PKCS#11 lub CSP.8. Moduł OCSP musi zapewniać redundancję umożliwiającą automatyczne (bez konieczności

interwencji operatora) podniesienie swoich usług po przełączeniu na inny węzeł. System umożliwia także zmianę konfiguracji umożliwiającą wyłączenie automatycznego przełączania środowisk.

9. Moduł OCSP musi zapewniać wydajność umożliwiającą weryfikację co najmniej 100000 certyfikatów na godzinę.

10. Licencja modułu OCSP nie może ograniczać ilości klientów, zapytań oraz generowanych odpowiedzi.

Wymagania szczegółowe dla modułu znakowania czasem1. Moduł znakowania czasem musi umożliwiać wystawianie znaczników czasu zgodnie ze

standardem RFC 3161, korzystając z HTTPS jako protokołu transportowego. 2. Moduł znakowania czasem musi umożliwiać pobieranie list CRL za pomocą LDAP, HTTP, HTTPS

oraz FTP.3. Moduł znakowania czasem musi umożliwiać pracę z uwierzytelnieniem lub bez uwierzytelnienia

klientów. 4. Moduł znakowania czasem musi umożliwiać synchronizację czasu z centralnym serwerem czasu

NTP dostarczonym przez Wykonawcę. 5. Moduł znakowania czasem musi współpracować z HSM za pośrednictwem interfejsu PKCS#11 lub

CSP.

6. Moduł znakowania czasem musi zapewniać redundancję gwarantującą automatyczne (bez konieczności interwencji operatora) podniesienie swoich usług po przełączeniu na inny węzeł.

7. Moduł znakowania czasem musi zapewniać wydajność umożliwiającą oznakowanie czasem 10000 (dziesięciu tysięcy) dokumentów/komunikatów na godzinę.

8. Licencja modułu znakowania czasem nie ogranicza ilości wydawanych wydanych znaczników czasu i liczby klientów korzystających z modułu.

Wymagania szczegółowe dla serwera czasu rzeczywistego1. Serwer czasu musi być dostarczony w postaci sprzętowego serwera zapewniającego dostarczanie

jednolitego czasu dla innych elementów Systemu PKI, zgodnie z protokołem NTP v3 lub nowszym.2. Serwer czasu musi pobierać aktualny czas ze źródła czasu urzędowego w Polsce (UTC PL).3. Serwer czasu musi posiadać odbiornik GPS i umożliwiać ustawienie źródła czasu

międzynarodowego (UTC) jako czasu rezerwowego.4. Serwer czasu musi posiadać dokładność na poziomie nie gorszym niż 900 (dziewięćset)

milisekund przy braku źródła synchronizacji czasu przez okres 1 tygodnia. 5. Serwer czasu musi posiadać automatyczny system kontroli pracy modułu i stabilności czasu

umożliwiający wysyłanie powiadomień poprzez e-mail, SNMP. 6. Serwer czasu musi obsługiwać protokoły sieciowe TCP, UDP, IP v4, IP v6 7. Serwer czasu musi posiadać możliwość zarządzania przy pomocy protokołu HTTPS, SSH, SNMPv3.8. Serwer czasu musi posiadać co najmniej dwa interfejsy sieciowe. 9. Serwer czasu musi umożliwiać priorytetyzację źródeł czasu odniesienia. 10. Serwer czasu musi posiadać wydajność na poziomie co najmniej 5000 (pięć tysięcy) zapytań na

sekundę. 11. Serwer czasu musi pozwalać na instalacje w szafie RACK 19” i posiadać maksymalną wysokość 1U.12. Serwer czasu musi być wyposażony w zewnętrzną antenę GPS. 13. Wykonawca dokona instalacji urządzenia oraz anteny we wskazanym miejscu. Uruchomi oraz

skonfiguruje dostarczone urządzenie do poprawnej pracy w sieci. 14. Serwer czasu musi posiadać możliwość pracy w temperaturze od 0°C do 50°C15. Średni czas bezawaryjnej pracy urządzenia powinien wynosić co najmniej 280 000 godzin.16. Urządzenie musi być zasilane napięciem: 110-230VAC (50-60 Hz).17. Serwer musi być wyposażony w wyświetlacz umieszczony na froncie obudowy, umożliwiający

wyświetlenie informacji o stanie urządzenia.18. Urządzenie musi być chłodzone pasywne.

Wymagania dla modernizacji oprogramowania umożliwiającego podpisywanie dokumentów i weryfikację wytworzonego podpisu.Wykonawca rozbuduje posiadane przez Zamawiającego oprogramowanie o interfejs graficzny ułatwiający użytkownikowi podpisywanie dokumentów elektronicznych oraz weryfikację wytworzonego podpisu. Oprogramowanie musi pozwalać na wykorzystywanie znaczników czasu oraz dawać możliwość dostosowania do własnych potrzeb poprzez zastosowanie w konsoli użytkownika specyficznej grafiki, a także modyfikację komunikatów.Pozostałe wymagania:

Możliwość podpisania jednego lub kilku dokumentów równocześnie, Możliwość wyboru formatu podpisu - minimum XAdES i PAdES,

Możliwość wyboru typu podpisu – zewnętrzny, wewnętrzny, Możliwość użycia kart kryptograficznych i czytników kart innych dostawców, Możliwość eksportu wyników weryfikacji do pliku PDF, Oprogramowanie musi współpracować z wszystkimi systemami operacyjnymi z rodziny

Microsoft Windows dedykowanymi do pracy na serwerach i komputerach osobistych, począwszy od Windows XP, zarówno w wersjach 32 jaki i 64 bitowych oraz z systemami operacyjnymi Linux

W ramach licencji Zamawiający ma prawo udostępniać oprogramowanie weryfikujące wytworzony podpis elektroniczny każdemu podmiotowi, który zamierza zweryfikować podpis elektroniczny wytworzony przez Zamawiającego (licencja nieograniczona ilościowo, terytorialnie i terminowo).

Wymagania dla modernizacji systemu Centrum Certyfikacji.Wykonawca dostarczy rozwiązanie równoważne lub rozbuduje rozwiązanie posiadane przez Zamawiającego o poniższe funkcjonalności:

1. Dodanie raportów z możliwością eksportu do formatów minimum pdf, xlsx oraz csv:a. zestawienie listy użytkowników (ważnych certyfikatów) na wskazany dzień. Raport

powinien zawierać przynajmniej: imię, nazwisko, sąd, datę wystawienia, datę ważności i datę unieważnienia certyfikatu, status (ważny / unieważniony / zawieszony / wygasły). Raport musi być:i. globalny – dostępny dla Operatora CA i obejmujący wszystkie certyfikatyii. lokalny – dostępny dla Operatora RA i obejmujący jedynie certyfikaty wydane w

danym profilu.b. lista certyfikatów użytkowników wydanych w zadanym przedziale czasu (domyślnie

poprzedni miesiąc),c. lista certyfikatów unieważnionych w zadanym przedziale czasu (domyślnie poprzedni

miesiąc),d. lista certyfikatów wydanych w profilu Operatorzy RA w zadanym przedziale czasu

(domyślnie poprzedni miesiąc),e. lista certyfikatów unieważnionych w profilu Operatorzy RA w zadanym przedziale czasu

(domyślnie poprzedni miesiąc).f. Lista wniosków oczekujących na realizację z podziałem na rodzaj wniosku i profil, w

którym złożono wniosek,g. Liczba użytych znaczników czasu w zadanym okresie czasu (domyślnie poprzedni

miesiąc).2. Oprogramowanie, poprzez stronę web, musi umożliwiać składanie oraz obsługę

wniosków o: nowy certyfikat, odnowienie certyfikatu, zwieszenie, uchylenie zawieszenia oraz unieważnienie certyfikatu. Zawieszenie certyfikatu nie może trwać dłużej niż 7 dni. Certyfikat, który został zawieszony, może zostać następnie unieważniony lub jego zawieszenie może zostać uchylone. Po upływie 7 dnia od momentu zawieszenia, w przypadku braku uchylenia zawieszenia, certyfikat jest automatycznie unieważniany.

3. Współpraca z wszystkimi systemami operacyjnymi z rodziny Microsoft Windows dedykowanymi do pracy na serwerach i komputerach osobistych, począwszy od Windows XP, zarówno w wersjach 32 jaki i 64 bitowych,

4. Współpraca z przeglądarkami internetowymi:

a. Mozilla Firefox wersja 41 i nowszeb. Google Chrome wersja 45 i nowszec. Opera wersja 32 i nowszed. Microsoft Internet Explorer 8 i nowszee. Microsoft Edge wersja 20 i nowsze

5. Wsparcie dla SSL 3 oraz TLS 1.1 i TLS 1.26. Możliwość zatwierdzania kilku wniosków równocześnie (grupowe zatwierdzanie wniosków).7. Możliwość otrzymywania przez Operatorów RA powiadomień e-mail o zmianie statusu

wniosku oraz o zbliżającym się terminie wygaśnięcia certyfikatu.8. Personalizacja modułów systemu - możliwość dostosowania do własnych potrzeb poprzez

zastosowanie na stronach web specyficznej grafiki.

II. Wymagania dla dokumentacji powykonawczejDokumentacja musi zawierać pełen opis konfiguracji wdrożonego środowiska niezbędny do jego późniejszego odtworzenia, w tym: opis wykonanych instalacji technicznych, opis zainstalowanego sprzętu i oprogramowania wraz z informacjami o parametrach i sposobie konfiguracji, instrukcje techniczno-instalacyjne, instrukcje obsługi sprzętu i oprogramowania oraz inne dokumenty producentów.W ramach dokumentacji powykonawczej obowiązkowym jest stworzenie następujących procedur wraz z schematami blokowymi. Procedury te powinny być przygotowane per rola/stanowisko dla danych pracowników Zleceniodawcy, uczestniczących w danym procesie objętym procedurą. Procedury powinny być opracowane w zakresie operacji technicznych oraz operacji formalnych(np. podpis pod wnioskiem przez przełożonego):

1) procedura odnowienia głównego certyfikatu urzędów certyfikacji.2) procedura odwołania głównego certyfikatu urzędów certyfikacji.3) Procedura zawieszenia katy/certyfikatu4) Procedura uchylenia zawieszenia karty/certyfikatu,5) Procedura unieważnienia zawieszonej karty/certyfikatu6) procedura wydania karty/certyfikatu.7) procedura odwołania karty/certyfikatu.8) procedura zagubienia karty/certyfikatu.9) procedura kradzieży karty/certyfikatu.10) procedura wydania zastępczej karty/certyfikatu.11) procedura odnowienia/przedłużenia karty/certyfikatu.12) procedura awaryjnego wyłączenia/włączenia wszystkich elementów Systemu.13) procedura awaryjnego odzyskania danych przechowywanych na sprzętowych

komponentach bezpieczeństwa.14) procedura tworzenia kopii zapasowych oraz awaryjnego odtwarzania systemu Centrum

Certyfikacji.15) procedura monitorowania, przeglądu i konserwacji systemu Centrum Certyfikacji.16) procedura aktualizacji oprogramowania systemu Centrum Certyfikacji.

Dokumentacji zostanie opracowana w języku polskim, w jednym wydrukowanym egzemplarzu oraz w wersji elektronicznej w formacie doc/docx i formacie PDF (na nośniku CD/DVD). Wykonawca przeniesie na Zamawiającego całość majątkowych praw autorskich do stworzonej dokumentacji.

III. Wymagania dla usług gwarancyjnych i utrzymaniowych (serwis i wsparcie).1. Wykonawca udzieli gwarancji na prawidłowe działanie wszystkich komponentów systemu

(sprzętu oraz oprogramowania) wchodzących w skład Infrastruktury Klucza Publicznego będącej w posiadaniu Zamawiającego oraz dostarczonych przez Wykonawcę w ramach niniejszej Umowy na okres miniumum 36 miesięcy.

2. Usługa gwarancyjna obejmuje wszystkie wykryte podczas eksploatacji Systemu błędy tj. uszkodzenia, wady i nieprawidłowości w funkcjonowaniu Systemu.

3. W zakresie klasyfikacji błędów Systemu, ewidencji zgłoszeń, procedur odbioru, czasu realizacji zgłoszeń, naliczania kar umownych, odbioru usług mają zastosowanie odpowiednio zapisy rozdział III, pkt 7 niniejszego dokumentu.

4. Wykonawca będzie świadczył usługii wsparcia technicznego i serwisu dla Zamawiającego oraz dla Użytkowników Końcowych Systemu przez okres 36 (trzydzieści sześć) miesięcy począwszy od 1stycznia 2016 r.

5. W ramach usługi serwisu Wykonawca będzie realizował m.in. następujące zadania:a) administracja Systemem (konfiguracja, weryfikacja logów, itd.),b) przeprowadzanie okresowych aktualizacji wszystkich elementów Systemu,c) Modyfikacje Systemu zlecone przez Zamawiającego.

6. Usługa serwisu w zakresie Modyfikacji Systemu obejmie nie więcej niż 16 osobogodzin w miesiącu.

7. Zasady realizacji usługi wsparcia technicznego i serwisu.1) Ogólne zasady realizacji usługi:

a. Wykonawca świadczy usługę wsparcia technicznego i serwisu Systemu dla Zamawiającego oraz Użytkowników Końcowych

b. Usługa wsparcia technicznego i serwisu obejmuje:i. wszystkie komponenty Systemu,

ii. systemy operacyjne, w oparciu o które funkcjonuje System w infrastrukturze centralnej,

iii. zadania administracji wszystkimi komponentami Systemu,iv. obsługa kopii zapasowych baz danych Systemu i ich odtwarzania,v. usuwanie awarii Systemu oraz skutków awarii Systemu, sprzętu i

oprogramowania, a także wszelkich negatywnych skutków spowodowanych korzystaniem z błędnie działających wersji Systemu,

vi. usuwanie błędów w oprogramowaniu Systemu,vii. realizację konfiguracji Systemu,

viii. wytworzone Modyfikacje,ix. zadania optymalizacji funkcjonowania Systemu w uzgodnieniu z

Zamawiającym, obejmujące optymalizację kodu źródłowego Systemu, systemu baz danych w infrastrukturze centralnej, serwerów aplikacyjnych.

x. odtworzenie Systemu i przywrócenie do pełnej funkcjonalności po katastrofie, pod pojęciem katastrofy Zamawiający rozumie uszkodzenie lub

całkowite zniszczenie większości istniejącej infrastruktury systemowej, kiedy do przywrócenia sprawności Systemu niezbędne są działania związane z odtwarzaniem zniszczonych zasobów sprzętowych i danych,

xi. monitorowanie i rekomendowanie Zamawiającemu konieczność zainstalowania poprawek i nowych wersji, na poszczególnych elementach Systemu dla środowisk technologicznych w infrastrukturze centralnej, takich jak oprogramowania:

sieciowych systemów operacyjnych, aplikacyjne, bazodanowe, komunikacyjne (o ile system zawiera tego typu oprogramowanie), do prezentacji treści, oraz pozostałego oprogramowania technologicznego i narzędziowego

będącego w posiadaniu Zamawiającego, a niezbędnego do bezpiecznego działania Systemu,

a następnie ich wdrożenie w środowisku Zamawiającego.c. Realizacja usługi wsparcia technicznego i serwisu, poza Awarią, będzie wykonywana

w sposób niezakłócający normalnego funkcjonowania Użytkownika Końcowego pomiędzy godziną 7:00 a 18:00 w dni robocze.

d. Realizacja usługi wsparcia technicznego i serwisu będzie wykonywana z należytą starannością, zgodnie z wytworzoną w ramach realizacji systemu dokumentacją (w szczególności dokumentacją techniczną i eksploatacyjną) oraz zasadami współczesnej wiedzy technicznej.

e. Wykonawca zapewnia obsługę niemożliwych do zdiagnozowania i usunięcia w sposób zdalny (za pośrednictwem łącza VPN lub telefonicznie) błędów na miejscu u Użytkowników Końcowego lub u Zamawiającego przez specjalistę ze strony Wykonawcy.

2) Rodzaje kwalifikacji zgłoszeń oraz czas ich realizacji.Rodzaj problemu

Opis Czas reakcji Czas na usunięcie błędu

Awaria Zatrzymanie eksploatacji Systemu, utrata danych lub naruszenie ich spójności, w wyniku której niemożliwej jest prowadzenie bieżącej działalności Systemu. Za awarie uznawane jest również jednoczesne wystąpienie szeregu Błędów Krytycznych w przypadku kiedy można wykazać, że ich wystąpienie ma ten sam skutek.

2 godzina do 24 godzin od zgłoszenia przez Zamawiającego lub Użytkownika Końcowego.

Błąd Krytyczny

Błąd uniemożliwiający poprawne wykorzystanie Systemu lub jego istotnej funkcjonalności do realizacji procesów biznesowych. Zakłócenie pracy Systemu polegające na ograniczeniu realizacji lub uciążliwości w realizacji jednej z funkcji Systemu. Działanie Systemu prowadzące do otrzymywania błędnych wyników

2 godzina do dwóch dni roboczych od zgłoszenia przez Zamawiającego lub Użytkownika Końcowego

przetwarzania danych lub praca Systemu, niezgodna z dokumentacją.

Po udostępnieniu rozwiązania czasowego pozwalającego na realizację błędnie działającej usługi (wdrożeniu obejścia) błąd krytyczny staje się Błędem Niekrytycznym.

Błąd Niekrytyczny

Zakłócenie pracy Systemu mogące mieć wpływ na jego funkcjonalność, natomiast nieograniczające zdolności operacyjnych Systemu w obrębie obsługi i wspomagania procesów biznesowych, niebędące Awarią, ani Błędem Krytycznym.

Błędy drobne, błędy ergonomiczne lub kosmetyczne błędy (np. format pól, brak walidacji, literówki, błędne nazwy, konieczność zbędnych „kliknięć” w celu uzyskania pożądanego przez użytkownika rezultatu, itp.).

3 godziny do 7 dni roboczych od daty zgłoszenia przez Zamawiającego lub Użytkownika Końcowego

Konfiguracja 1. Dostosowanie Systemu z uwagi na: zmiany organizacyjno -

administracyjnych sądów, w tym w szczególności utworzenie nowego sądu, likwidacja sądu,

zmiany w środowisku teleinformatycznym Zamawiającego,

zmiany w konfiguracji sieci WAN w oparciu, o którą funkcjonuje System,

aktualizacje przeglądarek internetowych,

2. Instalacja poprawek i nowych wersji do środowiska technologicznego Systemu.

3. Analiza i przeciwdziałanie zagrożeniom wynikającym z podatności komponentów Systemu lub systemów operacyjnych w infrastrukturze centralnej na cyberprzestępczość.

4. Optymalizacja funkcjonowania Systemu w uzgodnieniu z Zamawiającym, obejmująca optymalizację kodu źródłowego Systemu, systemu baz danych w infrastrukturze centralnej, serwerów aplikacyjnych.

8 godzin w terminie ustalonym przez Zamawiającego w porozumieniu z Wykonawcą, w przypadku braku porozumienia Stron, termin realizacji zostanie ustalony samodzielnie przez Zamawiającego

3) Procedura realizacji zgłoszeń (Awaria, Błąd Krytyczny, Błąd Niekrytyczny, Konfiguracja)a. Zamawiający przewiduje następujące kanały komunikacji:

i. za pośrednictwem formatki ekranowej zgłoszenia w aplikacji Service Desk udostępnionej przez Zamawiającego,

ii. w przypadku zgłoszeń typu Awaria, dodatkowo telefonicznie na numer wskazany przez Wykonawcę.

b. Zgłoszenie przesłane przez Zamawiającego lub Użytkownika Końcowego po godz. 15.30 w dniu roboczym Wykonawca przyjmuje do realizacji następnego dnia roboczego o godz. 7.30.

c. Za moment zgłoszenia uznaje się datę i godzinę zarejestrowania zgłoszenia w aplikacji Service Desk.

d. Zamawiający kategoryzuje zgłoszenia na formularzu zgłoszenia zgodnie z kwalifikacją określoną w tabeli zawierającej rodzaje kwalifikacji zgłoszeń.

e. Zamawiający określa, które Błędy Niekrytyczne powinny być realizowane w pierwszej kolejności.

f. Prawidłowa realizacja zgłoszenia, musi być zweryfikowane i potwierdzona w testach akceptacyjnych przez Zamawiającego lub Użytkownika Końcowego. Czas poświęcony na weryfikację zgłoszenia nie jest wliczany w czas jego realizacji przez Wykonawcę.

g. Uwagi zgłoszone przez Użytkowników Końcowych bezpośrednio do Wykonawcy, dotyczące funkcjonowania i funkcjonalności, a skutkujące Modyfikacjami Systemu będą niezwłocznie, tj. nie później niż w ciągu 2 dni przekazywane do Zamawiającego za pośrednictwem Service Desku.

4) Procedura zgłaszania Zamawiającemu konieczności zainstalowania poprawek i nowych wersji poszczególnych elementów Systemu dla środowisk technologicznych.

a. Wykonawca przedstawia listę poprawek do zainstalowania do każdego środowiska technologicznego w cyklach kwartalnych. Zamawiający zawsze może żądać dodatkowego cyklu wykonania poprawek lecz nie więcej niż dwa razy na kwartał.

b. Zamawiający w terminie 7 dni roboczych od dnia dostarczenia listy poprawek do zainstalowania informuje Wykonawcę, które ze zgłoszonych poprawek będą podlegać realizacji.

c. Wykonawca przeprowadza wdrożenie poprawek podlegających realizacji w terminie 14 dni roboczych od dnia przekazania zatwierdzenia ich przez Zamawiającego.

d. Za nieterminowe wdrożenie poprawek podlegających realizacji naliczone zostaną kary umowne jak za Błąd Niekrytyczny.

5) Wykonawca przekazuje Zamawiającemu każdorazowo nową wersję Systemu za pomocą środków komunikacji elektronicznej zawierającą w szczególności:

i. numer wersji,ii. wersję instalacyjną Systemu,

iii. wykaz zmian w stosunku do poprzedniej wersji,iv. instrukcję użytkownika jeżeli wymagała aktualizacji ze szczególnym

uwzględnieniem sposobu postępowania w związku z wprowadzonymi zmianami a także skutkami zmian wersji oprogramowania od strony użytkowej;

v. zaktualizowaną dokumentację.

6) Procedura instalacji nowej wersji Systemua. Każdorazowo w przypadku powstania nowej wersji Systemu, jej instalacja na

środowisku produkcyjnym następuje na zlecenie Zamawiającego.b. Wykonawca, przez czas trwania Umowy, będzie prowadził ewidencję dostarczanych

wersji Systemu, zawierającą:i. numer kolejny,

ii. numer wersji,iii. datę zatwierdzenia wersji przez Zamawiającego / polecenie instalacji wersji,iv. datę instalacji wersji,v. skrótowy opis zmian, które wersja uwzględnia,

vi. ewentualne uwagi.c. Wykonawca przedstawia ewidencję, o której mowa w pkt b) na żądanie

Zamawiającego, nie później niż w ciągu siedmiu dni roboczych, w postaci elektronicznej i papierowej.

IV. Wymagania dla warsztatów. 1. W ramach wdrożenia rozwiązania Wykonawca przeprowadzi minimum dwudniowe (2x7

godzin) warsztaty dla administratorów systemu (max. 10 osób) obejmujące minimum: a. konfigurację urządzeń, b. przeprowadzanie procedur backupu i awaryjnego odtwarzania,c. konfigurację aplikacji,d. obsługę dostarczonego rozwiązania.

2. Wykonawca w porozumieniu z Zamawiającym ustali terminy warsztatów. Warsztaty odbędą się w dni robocze. W razie wątpliwości dotyczących ustalenia kwestii, o których mowa powyżej, za wiążące uznaje się stanowisko Zamawiającego.

3. Zamawiający przedstawi Wykonawcy imienną listę osób uczestniczących w warsztatach na 5 dni roboczych przed rozpoczęciem każdego dnia warsztatów.

4. Wykonawca przedstawi do akceptacji Zamawiającemu zakres merytoryczny warsztatów w terminie do 40 dni od dnia zawarcia Umowy. Zamawiający w terminie 14 dni dokonuje akceptacji zakresu merytorycznego warsztatów lub zgłasza do niego uwagi. Wykonawca zobowiązany jest do uwzględnienia uwag Zamawiającego w terminie 7 dni od dnia ich otrzymania.

5. Po każdym dniu warsztatów zostanie sporządzona przez Wykonawcę lista obecności z podpisem każdego obecnego uczestnika warsztatów.

6. Wykonawca obowiązany jest do przedłożenia Zamawiającemu imiennych list obecności obejmujących co najmniej: imię i nazwisko prowadzącego warsztaty, imiona i nazwiska osób uczestniczących w warsztatach, datę i miejsce, oraz podpisy uczestników.

7. Lista obecności podpisana przez wszystkich uczestników warsztatów jest jednym z warunków podpisania Protokołu Odbioru Końcowego przez Zamawiającego.

8. Warsztaty odbędą się w siedzibie Zamawiającego – Sąd Apelacyjny we Wrocławiu (ul. Namysłowska 8, 50-304 Wrocław). Zamawiający udostępni Wykonawcy na potrzeby przedmiotowych warsztatów sale konferencyjne o odpowiednich wymiarach wyposażone w rzutnik i ekran oraz miejsce dla Trenera (Trenerów).

V. Wymagania dla etapów realizacji przedmiotu umowy Realizowane w ramach Umowy prace mają doprowadzić do osiągnięcia pełnej wymaganej funkcjonalności Centrum Certyfikacji (CA). Prace obejmują:1. Dostawę, instalację i konfigurację komponentów infrastruktury wykorzystanej do budowy CA w

tym: licencje, zapasowe urządzenie HSM, serwer czasu rzeczywistego z zewnętrzną anteną GPS, pamięć RAM.

2. Modernizację i rozbudowę systemu CA – wdrożenie rozwiązania.3. Dostawę dokumentacji powykonawczej oraz przeprowadzenie warsztatów dla administratorów.4. Usługi gwarancyjne i utrzymaniowe.

Założono, że realizacja umowy odbędzie się w niżej opisanych etapach.ETAP I - dostawa 8105 licencji (do 28.12.2015 r.)ETAP II - dostawa 8105 licencji oraz instalacja, modernizacja i rozbudowa systemu wraz z dostawą dokumentacji powykonawczej oraz warsztatami dla administratorów (do 31.03.2016 r.)ETAP III - usługi utrzymaniowe (obejmuje okres o podpisania umowy do 31.12.2018 r.)

ZASADY PRZEPROWADZANIA TESTÓW

Testy będą polegać na wytworzeniu podpisu z użyciem kart i czytników będących w posiadaniu przez Zamawiającego oraz symulacji awarii jednego z elementów Systemu. Testy będą wykonywane przez wykwalifikowanych pracowników Zamawiającego na urządzeniach Zamawiającego, w systemach operacyjnych Windows i Linux.

Test obejmuje wykonanie następujących czynności:1. Zainstalowanie czytników i kart.2. Wydanie certyfikatu.3. Podpisanie wskazanych plików.4. Weryfikację podpisu.5. Unieważnienie certyfikatu.6. Symulacja awarii jednego z elementów Systemu.

Testy zostaną przeprowadzone pięciokrotnie. Poprawne, pięciokrotne bezbłędne wykonanie procedury (działanie prawidłowe) zostanie uznane jako spełniające warunek testów. Poniżej została opisana procedura testowa:1. Wydanie certyfikatu X.509 (klucz 2048 bit, funkcja skrótu SHA-2) na kartę podłączoną do stacji

roboczej za pośrednictwem czytnika, będących w posiadaniu Zamawiającego. Certyfikat będzie wydawany przez Centrum Certyfikacji (CA) Zamawiającego po wcześniejszej konfiguracji przeprowadzonej przez Wykonawcę.

2. Wykonanie podpisu cyfrowego kartą przygotowaną w punkcie pierwszym zgodnie z interfejsem opisanym dla komponentu podpisującego, będącego w posiadaniu Zamawiającego

3. Wykonanie podpisu cyfrowego kartą przygotowaną w punkcie pierwszym z wykorzystaniem interfejsu graficznego dostarczonego przez Wykonawcę.

4. Weryfikacja podpisu wykonanego w punkcie drugim posiadanym przez Zamawiającego oprogramowaniem weryfikującym w systemie operacyjnym Windows.

5. Weryfikacja podpisu wykonanego w punkcie drugim z wykorzystaniem interfejsu graficznego dostarczonego przez Wykonawcę w systemie operacyjnym Windows oraz w systemie operacyjnym Linux.

6. Weryfikacja podpisu wykonanego w punkcie trzecim z wykorzystaniem interfejsu graficznego dostarczonego przez Wykonawcę w systemie operacyjnym Windows oraz w systemie operacyjnym Linux.

7. Unieważnienie certyfikatu wydanego w punkcie pierwszym.8. Ponowna weryfikacji podpisu zgodnie z opisem z pkt 4, 5 i 6.9. Próba wykonania podpisu cyfrowego unieważnionym certyfikatem zgodnie z opisem z pkt 2 i 3.

Za działanie prawidłowe zostanie uznane takie działanie Systemu, które nie pozwoli na wykonanie podpisu nieważnym certyfikatem.

10. Symulacja awarii jednego z elementów Systemu polegająca na wyłączeniu jednego z serwerów lub jednego z HSM. Za działanie prawidłowe zostanie uznane takie działanie Systemu, które w przypadku wyłączenia jednego z elementów Systemu, nie wpłynie na funkcjonalność Systemu.

11. W przypadku niepowodzenia testów Wykonawca zobowiązany jest do odtworzenia pierwotnego działającego środowiska w czasie nie dłuższym niż 8 godzin.

OPIS KOMPONENTÓW WCHODZĄCYCH W SKŁAD INFRASTRUKTURY KLUCZA PUBLICZNEGO BĘDĄCEJ W POSIADANIU ZAMAWIAJĄCEGO

1. Specyfikacja oprogramowania oraz architektury posiadanego Systemu.Zamawiający jest obecnie w posiadaniu oprogramowania Comarch CertificateAuthority zwanego Centrum Certyfikacji (CA), umożliwiającym pełną implementację systemu opartego o Infrastrukturę Klucza Publicznego (PKI), czyli wydawanie certyfikatów zabezpieczających pocztę, serwery WWW, kanały komunikacyjne, uwierzytelnianie i autoryzację użytkowników oraz umożliwiających składanie podpisów elektronicznych. W ramach struktury PKI została wprowadzona struktura urzędów certyfikacji w postaci systemu głównego urzędu certyfikacji oraz systemu podrzędnych urzędów. Wszystkie certyfikaty użytkowników są wydane z poziomu podrzędnych urzędów certyfikacji.Zamawiający jest także w posiadaniu oprogramowania umożliwiającego podpisywanie dokumentów elektronicznych (komponent podpisujący Comarch eSign ver. eP - 13 300 licencji) oraz oprogramowania umożliwiającego weryfikacją wytworzonego podpisu (komponent weryfikujący Comarch eVerify ver. eP - licencja nieograniczona ilościowo, terytorialnie i terminowo; w ramach licencji Zamawiający ma prawo udostępniać oprogramowanie weryfikujące wytworzony podpis elektroniczny każdemu podmiotowi, który zamierza zweryfikować podpis elektroniczny wytworzony przez Zamawiającego).Zamawiający posiada także 16 800 kart mikroprocesorowych (Comarch SmartCard 3.1) wraz z klienckim oprogramowaniem pośredniczącym pozwalających na wykorzystanie w systemie CA oraz 10 004 czytniki kart ( Comarch SmartCard Reader 3.1).

Oprogramowanie Comarch CertificateAuthority składa się z czterech modułów:1. Moduł RA (Registration Authority), który służy użytkownikowi do składania wniosków o

certyfikaty,2. Moduł RA Operator (Registration Authority Operator), który służy do akceptacji wniosków,3. Moduł CA (Certificate Authority), który służy do wystawiania certyfikatów na podstawie

wniosków zaakceptowanych w RA Operator, a także do unieważniania i zawieszania wydanych certyfikatów.

4. Moduł CA Administrator (Certificate Authority Administrator), który służy do konfiguracji oprogramowania.

Dostęp do modułów 2, 3 i 4 możliwy jest tylko w przypadku posiadania odpowiedniego certyfikatu potwierdzającego tożsamość zdalnemu komputerowi.

Oprogramowanie posiada następujące cechy oraz funkcjonalności:1. obsługa certyfikatu w całym cyklu jego życia – od złożenia wniosku po wygaśnięcie lub

unieważnienie.2. wyszukiwanie wniosków o certyfikat według kryteriów statusu procesu certyfikacji oraz

innych cech jak nazwa właściciela klucza, data złożenia wniosku, 3. odrzucanie wniosków o certyfikat,4. zatwierdzanie wniosków o certyfikat

5. wydawanie certyfikatu,6. wyszukiwanie certyfikatów według kryteriów ważności (ważny, unieważniony,

przeterminowany, zawieszony), nazwy właściciela klucza (CN), daty ważności certyfikatu, profilu,

7. unieważnianie certyfikatów,8. zawieszanie certyfikatów,9. uchylanie zawieszenia10. generowanie nowej listy CRL,11. publikowanie certyfikatów w usłudze katalogowej,12. publikowanie CRL w usłudze katalogowej,13. tworzenie nowego CA (Urzędu Certyfikacji)14. definiowanie profili certyfikatów,15. odzyskiwanie certyfikatów wraz z kluczami,16. możliwość stworzenia rozbudowanej infrastruktury klucza publicznego (wiele rozproszonych

jednostek rejestracyjnych),17. współpraca ze sprzętowym modułem kryptograficznym (tzw. HSM) do przechowywania

kluczy szyfrujących chroniących informacje w systemie, a niezbędnych do jego działania, wewnątrz tego modułu.

18. współpraca z kartami mikroprocesorowymi,

Struktura systemu zamawiającego jest rozproszona, tzn. każdy z 377 sądów objętych systemem posiada własną usługę katalogową. Posiadany system umożliwia korzystanie z danych użytkowników zgromadzonych na serwerach katalogowych wszystkich 377 sądów oraz uwzględnia fakt, że w Active Directory w różnych sądach mogą występować takie same nazwy użytkowników.

W zakresie wspomagania pracy administratorów oraz operatorów odpowiedzialnych za wydawanie kart, posiadane przez Zamawiającego oprogramowanie umożliwia:

1. zarządzanie zawartością kart inteligentnych na podstawie definiowania profili,2. kilka metod wydawanie karty inteligentnej użytkownika:

a. nadzorowana (w obecności operatora),b. zatwierdzana (ze wstępnym przypisanie karty do użytkownika),c. samodzielna (przeprowadzona przez użytkownika).

3. Zmianę zawartości karty inteligentnej (tzw. aktualizacja profilu karty) bez konieczności przekazania karty operatorowi, przeprowadzana przez użytkownika na stacji roboczej po uprzednim wydaniu odpowiedniej dyspozycji aktualizacji profilu karty przez operatora w systemie.

4. Automatyczne tworzenie kopii zapasowych certyfikatów służących do szyfrowania danych, pozwalająca na ich odtworzenie w celu uzyskania dostępu do zaszyfrowanych danych w przypadku zgubienia lub zniszczenia karty inteligentnej. Funkcja ta nie ma zastosowanie do certyfikatów innego przeznaczenia (np. certyfikatów do podpisu cyfrowego), dla którego para kluczy została wygenerowana wewnątrz karty inteligentnej, ponieważ w takim przypadku klucz prywatny nigdy nie opuszcza bezpiecznego obszaru karty inteligentnej.

5. Definiowane przez administratora procedury określają, które z profili kart powinny być dostępne dla operatora wydającego kartę.

6. W przypadku wycofania karty, certyfikaty użytkownika umieszczane są na liście odwołanych certyfikatów urzędu certyfikacji CA.

7. Pełne zarządzanie zawartością karty w tym dodawaniem, odnawianiem, zawieszaniem, wznawianiem oraz unieważnianiem certyfikatów PKI wydanych użytkownikowi za pomocą systemu.

8. Odblokowanie PIN do karty za pomocą procedury challenge-response (wyzwanie – odpowiedź)

W zakresie samoobsługi użytkowników posiadane oprogramowanie umożliwia dostęp do Modułu RA za pomocą portalu webowego obsługującego składanie wniosków oraz aktualizowanie zawartości karty (po uprzednim wydaniu odpowiedniej dyspozycji zmiany profilu karty przez administratora).

Inne cechy systemu:1) Automatyczne powiadamianie o zbliżającym się terminie wygaśnięcia certyfikatów.2) Możliwość wdrożenia całego rozwiązanie w celu uzyskania wysokiej dostępności (High Availability)

i równoważenia obciążenia (load balancing),3) Współpraca z usługą katalogowa wiodących dostawców – bez konieczności rozszerzania schematu

usługi katalogowej: AD 2003/2008, IBM Tivoli, Novell eDir, RedHat, Siemens.4) Współpraca z następującymi systemami operacyjnymi:

Microsoft Windows Server 2003 SP1, R2 i SP2 (32-bity) Microsoft Windows Server 2008 (32/64-bity) dla następujących wersji: Windows Server 2008 Datacenter Windows Server 2008 Enterprise Windows Server 2008 Standard Windows Web Server 2008

5) Wspieranie następujących relacyjnych baz danych: Oracle 11g, Oracle Database server 10g, R2 Microsoft SQL Server 2008 Enterprise i Standard Microsoft SQL Server 2005 Enterprise, SP2

6) Wspieranie następujących urzędów certyfikacji (CA): Cybertrust® UniCERT™ with ARM, Entrust ® Authority Security Manager™ Microsoft Windows 2003 CA SP1, R2 I SP2 Windows 2008 CA oraz Windows 2008 R2 CA VeriSign® Managed PKI

7) Integracja ze sprzętowym modułem kryptograficznym następujących producentów: Thales (nCipher) SafeNet

8) Zapisywania certyfikatów na kartach inteligentnych Comarch SmartCard 3.1 z pomocą klienckiego oprogramowania pośredniczącego Comarch SmartCard Libraries 3.1 oraz możliwość dodania obsługi kart innych producentów.

W ramach aktualnie wykorzystywanego rozwiązania firmy Comarch Zamawiający posiada: 3 serwery firmy IBM model x3650M3 o konfiguracji: procesor Intel Xeon E5645, 16GB RAM,

(dyski HDD SAS: w dwóch serwerach 4x146GB, w jednym 2x146GB) z zainstalowanym systemem operacyjnym Microsoft Windows Server 2008 R2 Standard oraz kartami nToken pozwalającymi na bezpieczną komunikację z urządzeniem HSM. Aktualnie serwery pełnią następujące funkcje:

o serwer podstawowy (CA1), o serwer zapasowy (CA2) (w przypadku awarii przełączany ręcznie do pełnienia funkcji

serwera podstawowego, pomiędzy serwerem podstawowym, a zapasowym brak automatycznej synchronizacji) ,

o serwer recovery (obsługa challenge-response do odblokowywania PIN-u) (CA3). sprzętowe urządzenie HSM (Hardware Security Module) nShield Connect 1500 firmy Thales.

System korzysta z bazy danych Microsoft SQL Server 2012 Express, której instancja jest uruchomiana na zwirtualizowanym serwerze bazodanowym w infrastrukturze Sądu Apelacyjnego we Wrocławiu.

Architektura wdrożonego systemu przedstawiona jest na poniższym schemacie.

CA1, CA2, CA3 – Serwery na których zostało zainstalowane Comarch PKI: CA1-casawroc.as.sad, CA2-subcasawroc.as.sad, CA3 – carecovery.as.sadSQL Server – Microsoft SQL Server 2012 Express, relacyjna baza danychApache – serwer WWW (po jednym na CA1 i CA2) obsługujący:Składanie wniosków za pomocą formularzy (Moduł RA)Operacje na wnioskach: akceptacja / odrzucenie (Moduł RA Operator)Operację na certyfikatach: unieważnienie / zawieszenie / uchylenie zawieszenia (Moduł CA)Konfigurację oprogramowania (Moduł CA Administrator)Tomcat – serwer aplikacyjny obsługujący żądania http z uruchomioną aplikacją do automatycznego wystawiania certyfikatów. (po jednym na CA1 i CA2) netHSM – sprzętowy moduł kryptograficznynToken – sprzętowe urządzenie pozwalające na bezpieczną komunikację z urządzeniem netHSM (po jednym na CA1, CA2 i CA3)

Serwisy PKI:Zainstalowane na CA1SignService – serwis obsługujący sesje z urządzeniem netHSM oraz podpisujący żądania, NotificationDeamon – serwis wysyłający powiadomienia o wygaśnięciach certyfikatówCRL Service – serwis generujący okresowo listy CRLCAAPI Service – serwis wykorzystywany przez Tomcat, aplikacja z Tomcat-a wysyła wnioski do cpki-server’a a ten na podstawie wniosków odsyła podpisane certyfikatynShieldServer – serwis obsługujący żądania typu challenge – response pochodzące z aplikacji do alternatywnego odblokowania PIN-uComarchSmardCard – aplikacja wraz ze sterownikami do kart i czytników, wykorzystywana przez operatora, służąca do alternatywnego odblokowania PIN-u

Komponent sprzętowy do ochrony certyfikatu oraz klucza prywatnego ma postać karty inteligentnej wraz z czytnikami w standardzie USB. Na karcie składowany jest certyfikat wraz z kluczem prywatnym, który posłuży do podpisywania dokumentów. Komunikacja komponentu sprzętowego z systemem operacyjnym zapewnia klienckie oprogramowanie pośredniczące. W ramach struktury PKI wprowadzona została struktura urzędów certyfikacji w postaci systemu głównego urzędu certyfikacji oraz systemu urzędów podrzędnych. Wszystkie certyfikaty użytkowników wydane są z poziomu podrzędnych urzędów certyfikacji.

Na poniższym schemacie została przedstawiona struktura PKI:

Ministerstwo Sprawiedliwosci Root CA Główny urząd certyfikacji, wydający certyfikaty podrzędnych CA

Ministerstwo Sprawiedliwosci Operatorzy RACertyfikat CA wydającego certyfikaty dla operatorów RA, umożliwiających dostęp do panelu operatora RA

Ministerstwo Sprawiedliwosci Operatorzy CACertyfikat CA wydającego certyfikaty dla operatorów CA, umożliwiających dostęp do panelu operatora CA

Ministerstwo Sprawiedliwosci Adminstratorzy CACertyfikat CA wydającego certyfikaty dla administratorów CA, umożliwiających dostęp do panelu administratora CA

Ministerstwo Sprawiedliwosci Serwery CA Certyfikat CA wydającego certyfikaty dla serwerów www

CA ApelacjiCertyfikaty CA wydającego certyfikaty dla użytkowników w sądach z obszaru danej apelacji.

2. Specyfikacja dla sieciowego moduł bezpieczeństwa (ang. Hardware Security Modules) posiadanego przez Zamawiającego.

1. Urządzenie posiada podwójne, w pełni redundantne zasilanie (2 zasilacze typu Hot-Swap) oraz chłodzenie w celu zapewnienia ciągłości pracy w krytycznych systemach bezpieczeństwa przedsiębiorstwa;

2. Urządzenie jest zasilane napięciem: 100-240V AC (50-60 Hz);3. Urządzenie w celu przechowywania danych posiada dysk twardy typu Solid-State;4. Urządzenie ma wielkość 1U i posiada możliwość montażu w szafie teleinformatycznej typu RACK

19”;5. Urządzenie posiada 2 porty Gigabit Ethernet, dodatkowo przedni panel urządzenia posiada:

- czytnik kart pamięci (ang. Smart Card Reader);- port USB (ang. Universal Serial Bus);- diody ostrzegające o nieprawidłowym działaniu urządzenia (ang. Warning LED);- wyświetlacz typu LCD (ang. Liquid Crystal Display), w celu wykonania podstawowej konfiguracji oraz wyświetlania podstawowych informacji konfiguracyjnych urządzenia.

6. Waga urządzenia nie przekracza 12kg;7. Urządzenie obsługuje następujące algorytmu szyfrowania danych:

- RSA (1024, 2048, 4096 oraz 8192 bit);- Diffie-Hellman;- DSA;- El-Gamal;- KCDSA;- ECDSA;- ECDH;- AES;- ARIA;- Camellia;- CAST;- DES;- SEED;- Triple DES.

8. Urządzenie obsługuje następujące funkcje hashujące (mieszające):- SHA-1;- SHA-2 (224,256,384,512 bit);

9. Urządzenie obsługuje następujące systemy operacyjne: - Windows 2008 R2/2008/2003/Vista/XP; - Solaris;

- HP-UX;- AIX;- Linux.

10. Urządzenie spełnia następujące normy oraz posiada certyfikaty:- UL, CE, FCC;

- FIPS 140-2 Level 2/3, NIST SP 800-131A; - Common Criteria EAL4+.

- RoHS, WEEE11. Urządzenie jest w stanie przetworzyć 1500 transakcji na sekundę

(Transakcja rozumiana jest jako ilość podpisów cyfrowych wykonanych algorytmem RSA z kluczem 1024 bitowym);

12. Urządzenie wspiera do 20 klientów;13. Urządzenie ma możliwość zarządzania za pomocą dwóch interfejsów: CLI (ang. Command Line

Interface) oraz GUI (ang. Graphical User Interface)14. Interfejs zarządzający ma możliwość definiowania tzw. ról użytkowników;15. Urządzenie posiada obsługę protokołu SNMPv3;16. Urządzenie posiada oprogramowanie, które może aktualizować do nowszych wersji;17. Urządzenie posiada możliwość integracji z drugim takim samym urządzeniem w celu utworzenie

tzw. klastra oraz funkcji „Load-Balancing”.18. Średni czas bezawaryjnej pracy urządzenia wynosi 47 000 godzin.

3. Specyfikacja oprogramowania umożliwiającego podpisywanie dokumentów elektronicznych – komponent podpisujący Comarch eSign ver. eP

1 Realizacja podpisu Xades (wersja co najmniej 1.3.2) w trybie detached.2 Wykorzystanie CSP3 Komponent umożliwia podpisywanie dokumentów co najmniej w następujących

środowiskach: Microsoft Windows Multipoint Server 2011, Microsoft Windows Server 2003/2008/2012, Microsoft Windows XP/Vista/7 Linux

4 W aplikacji Recourt (system cyfrowej rejestracji rozpraw sądowych) komponent jest wywoływany przez interfejs:

o Uruchomienie (sposób wywołania) komponentu podpisu jest definiowane przez wybór zewnętrznej aplikacji (plik exe) oraz parametrów przekazywanych do aplikacji podpisującej (standardowo format z pełnymi ścieżkami -f:in1,in2 -d:out). Możliwe parametry to np:

ścieżka źródła (I) plik a (nagranie audio-wideo) źródła (in1) plik b (nagranie audio) źródła (in2) plik a ze ścieżką źródła (In1)

plik b ze ścieżką źródła (In2) katalog docelowy (out)

o Interfejs przekazuje do komponentu ścieżki do podpisywanych plików i/lub ścieżkę do katalogu z nagraniem np. SignerLauncher.exe -f:PELNA_SCIEZKA_PLIKU_OGG,PELNA_SCIEZKA_PLIKU_OGA -d:SCIEZKA_DO_KATALOGU_WYNIKOWEGO

o W wyniku działania komponentu w katalogu wynikowym powstają dwa pliki z podpisem. Nazwa pliku podpisu jest wyznaczana w ten sposób, że do nazwy podpisywanego pliku zostaje dodane rozszerzenie Xades

o Zewnętrzna aplikacja pośredniczy pomiędzy aplikacją Recourt, a komponentem podpisu, umożliwiając komunikowanie się różnych sposobów obsługi bibliotek do podpisu bez potrzeby zmian w Recourt.

o Konfiguracja/instalacja samego komponentu podpisu i jego bibliotek nie jest w żadnym stopniu zależna od aplikacji Recourt i odwrotnie. Każdy komponent podpisu jest konfigurowany osobno poza Recourt.

o Zewnętrzna aplikacja pośrednicząca zwraca kod powrotu odpowiedni dla udanego podpisu i odpowiedni dla błędu podpisu.

5 Jeżeli w schowku systemowym Windows jest jeden certyfikat użytkownika, ma on być domyślnie użyty do podpisu. W przypadku większej liczby certyfikatów, ma być zaprezentowana ich lista z możliwością wyboru konkretnego certyfikatu

6 Do wykonania podpisu wymagane jest podanie przez użytkownika numeru PIN zapisanego na karcie, przy czym numer ten podawany jest tylko raz. Oprogramowanie umożliwia podpisywanie wielu plików przy jednokrotnym podaniu numery PIN.

7 Oprogramowanie informuje użytkownika o postępie czynności wykonywanych przy podpisywaniu plików (pasek postępu oraz komunikaty).

8 Komponent prezentuje przy użyciu pasków postępu i statusu poszczególne etapy złożenia podpisu elektronicznego

9 Nie jest możliwe złożenie podpisu wygasłym bądź unieważnionym certyfikatem. Wygasłe bądź unieważnione certyfikaty nie są pokazywane użytkownikowi na liście wyboru.

10 Komponent umożliwia złożenie podpisu z wykorzystaniem certyfikatów wystawianych przez Infrastrukturę Klucza Publicznego będącą w posiadaniu Zamawiającego

4. Specyfikacja oprogramowania umożliwiającego weryfikację wytworzonego podpisu – Komponent weryfikujący podpis Comarch eVerify ver. eP

1 Oprogramowanie dostępne co najmniej na następujące platformy:o Microsoft Windows: XP, Vista, 7 (32 bit / 64 bit)o Windows MultiPoint Server 2011o Windows Server 2003/2008/2012o Linux

2 Oprogramowanie weryfikuje podpis wykonany przez Komponent podpisujący i

prezentuje informacje o wyniku weryfikacji3 Oprogramowanie do weryfikacji ważności certyfikatów używa list CRL.4 Oprogramowanie do weryfikacji ważności certyfikatów umożliwia użycie protokołu

OCSP.5 Oprogramowanie umożliwia zweryfikowanie podpisu z uwzględnieniem daty

i czasu jego składania, który wskazuje na jaki dzień i godzinę jest sprawdzana ważność certyfikatu.

6 Weryfikując podpis i certyfikat oprogramowanie informuje, jaki certyfikat został użyty do weryfikacji. Możliwa jest prezentacja właściwości certyfikatu.

5. Specyfikacja kart mikroprocesorowych.1 Karty mikroprocesorowe muszą współpracować z wszystkimi systemami operacyjnymi z

rodziny Microsoft Windows dedykowanymi do pracy na serwerach i komputerach osobistych, począwszy od Windows XP, zarówno w wersjach 32 jaki i 64 bitowych.

2 Karty muszą pozwalać na wykorzystanie w systemie Centrum Certyfikacji, będącym w posiadaniu Zamawiającego.

3 Wsparcie dla karty przez system zarządzania cyklem życia karty inteligentnej. Komunikacja pomiędzy kartą i systemem zarządzania odbywa się po zbudowaniu uwierzytelnionego i szyfrowanego bezpiecznego kanału pomiędzy tymi elementami.

4 Możliwość umieszczenia na karcie w chwili jej wydawania przez system zarządzania cyklem życia kart inteligentnej apletu pozwalającego na generowanie haseł jednorazowych zgodnych z system uwierzytelniania w oparciu o hasło jednorazowe.

5 Możliwość nadania kodu PIN o długości minimum 12 znaków alfanumerycznych dla każdej pary kluczy i certyfikatu.

6 Możliwość odblokowania karty po jej zablokowaniu wskutek przekroczenia dozwolonej liczby logowania błędnym PIN w oparciu o procedurę wyzwanie - odpowiedź (challenge-response).

7 Odblokowywanie karty za pomocą mechanizmu challange-reponse. Generowany response musi być przekazany do użytkownika końcowego karty dwoma niezależnymi drogami: jedna część wartości response drogą mailową, druga część drogą telefoniczną

8 Zgodność z Global Platform v2.1.19 Gwarantowany poziom bezpieczeństwa: CommonCriteria EAL5+ lub równoważny – dla

procesora (chipu) karty, FIPS 140-2 Level3 lub równoważny – dla platformy karty10 Pamięć EEPROM: Nieulotna typu EEPROM o pojemności co najmniej 80kB.

Wytrzymałość co najmniej 500000 cykli zapisu i usunięcia.Zdolność przechowania zapisanych danych minimum 20 lat w temperaturze 25°C.

11 Interfejsy: Stykowy, zgodny z ISO 7816-1, -2, -3, -412 Karty muszą być wykonane z materiału laminowanego nieulegającemu odkształceniu i

rozwarstwieniu o wymiarach i właściwościach fizycznych, zgodnych z wymaganiami dla kart identyfikacyjnych formatu ID-1, określonymi w normie ISO 7810 dla kart identyfikacyjnych – właściwości fizyczne.

13 System operacyjny karty: Java Card w wersji minimum 2.2.1 lub równoważny14 Funkcje kryptograficzne: Wsparcie dla algorytmów: DES, TripleDES - zarówno z kluczami

podwójnej jak i potrójnej długości; AES dla kluczy o długości 128, 192, 256 bitów. Funkcje

skrótu: SHA-1 i SHA-2, MD5, RIPEMD-160. Obsługa kluczy RSA o długości 2048 bitów. Wbudowany koprocesor kryptograficzny i generator rzeczywistych liczb losowych.

15 Protokół komunikacji zewnętrznej: Wsparcie dla protokołów T=0 oraz T=1.

6. Specyfikacja czytników kart mikroprocesorowych ze złączem USB.1 Czytnik wspiera następujące typy kart: 5V, 3V, 1.8V Smart Card oraz karty typu ISO 7816 klasy

A, B i C2 Urządzenie obsługuje karty rozmiaru ID-13 Urządzenie ma możliwość podłączenia przy pomocy interfejsu min. USB 2.0.4 Urządzeniu jest zasilane poprzez interfejs USB.5 Urządzenie posiada szybki chipset, charakteryzujący się prędkością interfejsu Smart Card do

420kbps (w zależności od modelu karty), oraz prędkością interfejsu hosta do 12 Mbps.6 Współpraca z aplikacjami odbywa się za pomocą ustandaryzowanego interfejsu: PS/SC, OCF

lub CT-API7 Czytnik obsługuje następujące protokoły: T=0, T=1, 2-wire: SLE 4432/42 (S=10); 3-wire: SLE

4418/28 (S=9), IC (S=8)8 Urządzenie charakteryzuje się żywotnością co najmniej 100 000 cykli włożeniowych9 Średni czas bezawaryjnej pracy urządzenia wynosi co najmniej 500 000 godzin10 W celu ochrony karty i urządzenia, czytnik posiada zabezpieczenia przeciwzwarciowe i

termiczne11 Urządzenie ma możliwość pracy w temperaturze od 0 do 55 stopni Celsjusza, oraz w

wilgotności od 10% do 90%12 Czytnik kart jest obsługiwany przez wszystkie systemy operacyjne z rodziny Microsoft

Windows dedykowane do pracy na serwerach i komputerach osobistych, począwszy od Windows XP, zarówno w wersjach 32 jaki i 64 bitowych.

13 Urządzenie spełnia i posiada następujące standardy i certyfikaty : Microsoft® WHQL, EMV 2000 Level 1, ISO 7816, HBCI, USB 2.0 (USB 1.1 compatible) CCID1 GSA FIPS201 approved product list

14 Urządzenie spełnia następujące normy bezpieczeństwa: CE WEEE FCC UL VCCI MIC RoHS

7. Specyfikacja klienckiego oprogramowania pośredniczącego.1 Wymagania dotyczące funkcjonalności1.1 Oprogramowanie umożliwia obsługę urządzeń uwierzytelniających.1.2 Oprogramowanie umożliwia wykorzystanie urządzeń uwierzytelniających w następującym

zakresie: w przypadku zablokowana urządzenia uwierzytelniającego po przekroczeniu przez

użytkownika ilości dozwolonych prób logowania błędnym PIN oprogramowanie klienckie umożliwia jego odblokowanie poprzez:

o podanie kodu PUK generowanego podczas inicjalizacji urządzenia,o za pomocą mechanizmu wyzwanie-odpowiedź (challenge-response)

1.3 Oprogramowanie powiadamia o obecności (być może nieumyślnym pozostawieniu) urządzenia uwierzytelniającego podłączonego do stacji użytkownika podczas blokowania ekranu stacji użytkownika oraz zamykania systemu operacyjnego,

1.4 Ikona statusu w pasku narzędzi zmienia się wraz z podłączeniem urządzenia uwierzytelniającego do stacji użytkownika jak również wskazuje aktywność tego urządzenia,

1.5 Mechanizm buforowania (cache) PINu karty. W celu podniesienia bezpieczeństwa oraz ułatwienia pracy użytkowników mechanizm jest konfigurowalny ze względu na:

proces Windows; czas wygaśnięcia PIN w danym cache.

2 Oprogramowanie klienckie2.1 Oprogramowanie klienckie umożliwia użytkownikowi m.in.:

Importowanie certyfikatów na urządzenie uwierzytelniające Eksportowanie certyfikatów z urządzenia uwierzytelniającego Generowanie hasła jednorazowego (jeżeli pozwala na to urządzenie

uwierzytelniające) Synchronizację hasła jednorazowego (jeżeli pozwala na to urządzenie

uwierzytelniające) Dostosowanie interfejsu użytkownika oraz paska narzędzi Uruchomienie narzędzia modułu diagnostycznego Uruchomienie kreatora rozwiązywania problemów Uruchomienie menedżera zaawansowanej konfiguracji Wyświetlenie pomocy Wyświetlenie informacji o urządzeniu uwierzytelniającym podłączonym do stacji

użytkownika Wyświetlenie certyfikatów obecnych na urządzeniu uwierzytelniającym Obsługa odblokowywania karty za pomocą mechanizmu challange-reponse Informowanie użytkownika karty o włożonej karcie w przypadku blokowania ekranu i

wylogowywania Informowanie o zbliżającym się terminie wygaśnięcia certyfikatu Posiada moduł diagnostyczny, które wyświetla informacje o włożonych kartach

bazując na ATR-ach i driverach i informacji o czytnikacho wersje komponentów, driverów (m.in. PKCS-a),o działanie usług związanych z kartami i ich wersje,o identyfikacja zgodności karty z oprogramowaniem pośredniczącym

Posiada kreator rozwiązywania problemów, który pomaga zdiagnozować problemy z

kartami i je wyeliminować zawierający m.in. funkcjonalnośćo aktywacja logówo kreator kopiowania logów w określone miejsce

2.2 Musi być możliwa regulacja dostępu pracowników do wyżej wymienionych funkcji / obszarów interfejsu użytkownika,

2.3 Częścią oprogramowania klienckiego musi być moduł diagnostyczny oraz kreator rozwiązywania problemów pozwalające zdiagnozować potencjalne problemy z obsługą karty,

2.4 Wspierane standardy: Obsługa kart opartych na systemie Java Card 2.1 oraz 2.2 Architektura czytników kart inteligentnych PC/SC Klucze RSA o długości 1024 oraz 2048 bitów, certyfikaty X.509 PKCS#7, 10, 11,12, Microsoft CAPI 2.0, SSLv3, TLSv1.1 oraz S/MIME. Kryptografia symetryczna (hasła jednorazowe): DES, Triple DES, ANSI x9.9. Zarządzanie kartą inteligentną: GlobalPlatform v2.1.1. Instalacja poprzez MSI, z możliwością predefiniowania przez administratora

konfiguracji oraz funkcji oprogramowania klienckiego dostępnych dla użytkownika. Możliwość dostosowania oprogramowania klienckiego do własnych potrzeb poprzez

zastosowanie w konsoli użytkownika specyficznej grafiki oraz modyfikację komunikatów.

3. Wymagania systemowe3.1 Instalacja oprogramowania klienckiego na wszystkich systemach operacyjnych z rodziny

Microsoft Windows dedykowane do pracy na serwerach i komputerach osobistych, począwszy od Windows XP, zarówno w wersjach 32 jaki i 64 bitowych.