Opis przedmitu zamówienia (OPZ) na mdernizację Centrum Certyfikacji Kluczy na ptrzeby Prjektu pl.id plska ID karta raz Prjektu SIPR tekst jednlity uwzględniający zmianę z dnia 28 czerwca 2011 1
Wstęp Przedmitem zamówienia jest mdernizacja Centrum Certyfikacji MSWiA zapewniająca generwanie certyfikatów infrastruktury i certyfikatów użytkwników na ptrzeby pl.id i SIPR. W ramach zamówienia Wyknawca: pracuje dwa dkumenty plityki certyfikacji na pdstawie wytycznych dstarcznych przez Zamawiająceg, uruchmi mechanizmy zarządzania cyklem życia certyfikatów w parciu prtkół Simple Certificate Enrllment Prtcl, dstarczy dwa nwe urzędy certyfikacji zawierające c najmniej cztery serwery sprzętwe wraz z systemami peracyjnymi, cztery mduły kryptgraficzne HSM, macierz dyskwą, prgramwanie bazy danych, prgramwanie realizujące funkcjnalnść klastra niezawdnściweg raz prgramwanie realizujące funkcjnalnść centrum certyfikacji, serwery usług OCSP i SCEP działające w knfiguracji HA z mżliwścią balanswania ruchu, dstarczy pdsystem backupu realizujący funkcjnalnść wyknywania kpii bezpieczeństwa (backup), dstarczy dwa przełączniki sieciwe 24 prtwe Gigabit Ethernet, dstarczy dwa urządzenia balansujące ruchem dla usług OCSP raz SCEP, dstarczy aplikacje d zarządzania cyklem życia certyfikatów w parciu prtkół SCEP raz OCSP, dstarczy trzy kmpletne stanwiska peratrskie przeznaczne d rejestracji raz bsługi wnisków wydanie certyfikatów raz d persnalizacji kart współpracujące z dwma budwanymi urzędami certyfikacji każde wypsażne w kmputer PC z systemem peracyjnym, mnitr, dwa czytniki kart kryptgraficznych, drukarkę d persnalizacji graficznej i elektrnicznej kart, drukarkę igłwą d wydruku kpert utajninych z kdami d kart, drukarkę d wydruku etykiet samprzylepnych, drukarkę laserwą d wydruku dkumentacji, licencje prgramwania z funkcjnalnścią persnalizacji kart dstarczy i sknfiguruje mduł serwera czasu, dstarczy sejf dstarczy szafę Rack włączy nwe urzędy certyfikacji w strukturę drzewa zaufania Centrum Certyfikacji MSWiA, wdrży całe rzwiązanie raz zapewni wsparcie eksplatacyjne przez kres 6 miesięcy d mmentu wskazaneg przez Zamawiająceg, będzie świadczył usługi gwarancji przez kres 36 miesięcy, przeprwadzi niezbędny instruktaż dla pracwników Zamawiająceg. Wymagania I. Wdrżenie dwóch nwych urzędów certyfikacji (CA): 1. Wyknawca wdrży w ramach systemu dwa urzędy certyfikacji: - urząd d generacji kluczy dla urządzeń infrastruktury (w szczególnści pl.id), - urząd d generacji kluczy dla urzędników bsługujących aplikacje lkalne (w szczególnści dla prjektów pl.id i SIPR). 2. Urząd dla infrastruktury zapewni w ramach dstarcznej licencji mżliwść wydawania nielimitwanej liczby certyfikatów i rejestracji niegranicznej liczby użytkwników. 3. Urząd dla peratrów zapewni w ramach dstarcznej licencji mżliwść wydawania nielimitwanej liczby certyfikatów i rejestracji niegranicznej liczby użytkwników. 4. CA muszą: - generwać certyfikaty klucza publiczneg w standardzie X.509 raz CVC (Card Verifying Certificate) - generwać listy CRL/ARL, 2
- umżliwiać bsługę prtkłu SCEP, - umżliwiać weryfikację statusu certyfikatów w parciu OCSP. 5. System musi grmadzić z zachwaniem zasady niezaprzeczalnści i rzliczalnści infrmacje audytwe umżliwiające dtwrzenie histrii wszystkich peracji wyknywanych w systemie. 6. System musi umżliwiać przeglądanie infrmacji audytwych w systemie raz ich eksprt z zachwaniem zasad pufnści, rzliczalnści i niezaprzeczalnści. 7. System musi umżliwiać generwanie certyfikatów na pdstawie elektrnicznych wnisków w frmacie PKCS#10. 8. System musi bsługiwać karty kryptgraficzne z wykrzystaniem PKCS#11 lub Micrsft CryptAPI/CSP. 9. Serwerwa część Systemu musi działać w parciu przynajmniej jeden z systemów peracyjnych: RedHat, Nvell SuSe, Micrsft Windws. 10. System będzie pzwalał wprwadzać plskie znaki diakrytyczne raz będzie je pprawnie bsługiwał w generwanych certyfikatach z użyciem kdwania w standardzie UTF8. 11. System musi zapewnić mechanizm bezpiecznej autmatycznej archiwizacji kluczy przeznacznych d celów chrny pufnści (szyfrwania) raz mechanizmy bezpieczneg dtwarzania kluczy z archiwum. 12. System musi prwadzić ewidencję pdmitów (sób) na ptrzeby których bsługiwane są wniski certyfikaty, generwane są certyfikaty i persnalizwane są karty. Na ptrzeby prwadzenia takiej ewidencji system musi umżliwić wprwadzenie minimum następujących danych: Imię sby. Nazwisk sby. Identyfikatr sby (np. PESEL lub numer służbwy). Organizacja (Np. Gmina). Jednstka rganizacyjna (np. wydział lub departament). Stanwisk. Telefn. Fax. Adres e-mail. Pnadt system musi autmatycznie rejestrwać ddatkwe dane takie jak: Kiedy infrmacja zstała zarejestrwana w Systemie. Kt zarejestrwał w Systemie dana infrmację. System musi umżliwić przeglądanie i mdyfikwanie rejestru raz psiadać mechanizmy wyszukiwania rekrdów z danymi spełniającymi zadane kryteria. 13. a) System musi psiadać funkcjnalnść umżliwiającą administratrwi knfigurację mechanizmu autmatyczneg pwiadamiania subskrybentów drgą e-mailwą, którym wydan certyfikaty na zadaną ilść dni przed wygaśnięciem daneg certyfikatu fakcie zbliżania się kresu kńca ważnści certyfikatu. b) Administratr musi móc selektywnie z dkładnścią d zdefiniwanej w systemie plityki wydawania certyfikatów kreślić mżliwść takieg pwiadamiania i zdefiniwać spsób i treść kmunikatu pwiadmienia. Pwiadmienia muszą być wysyłane na adres e-mail subskrybenta bądź wniskdawcy według knfiguracji zadanej przez administratra systemu. c) Na ptrzeby realizacji tej funkcjnalnści system musi umżliwić grmadzenie 3
danych takich jak adres e-mail subskrybenta i wniskdawcy. 14. d) System musi psiadać mżliwść definiwania użytkwników i przyprządkwywania im dpwiednich ról i praw dstępu a w tym przynajmniej ról: Administratra. Operatra. Audytra. 15. System umżliwia zdefiniwanie kresów zakładkwych dla list CRL. 16. System udstępnia mżliwść dnwienia certyfikatu na te same dane. 17. System musi umżliwiać dnawianie certyfikatów bez kniecznści generwania nwej pary kluczy, zawieszania, uchylenia zawieszenia, unieważniania certyfikatów. 18. System musi dawać mżliwść graniczenia twrzenia hierarchii PKI. 19. System musi przechwywać infrmacje raz certyfikaty w relacyjnej bazie danych. Dpuszczalnymi bazami danych są: DB2, Oracle, PstgreSQL lub MS SQL. 20. System musi umżliwiać eksprtwanie generwanych certyfikatów raz list unieważnień c najmniej d: systemu plików, repzytrium LDAP raz publikację za pmcą prtkłów smtp, ftp, http. 21. Dstęp użytkwników d systemu musi dbywać się z wykrzystaniem silnych technik uwierzytelniania (certyfikat na karcie kryptgraficznej). 22. System musi psiadać interfejs użytkwnika w języku plskim. 23. System musi wspierać kreswe i na żądanie generwanie list CRL. 24. System musi umżliwiać imprt, eksprt raz edycję prfili certyfikatów. 25. Urzędy Certyfikacji muszą prwadzić rejestry zdarzeń umżliwiające przeprwadzenie szczegółweg audytu z pracy systemu raz diagnstyki pracy systemu. 26. System musi wspmagać zarządzanie kartami mikrprcesrwymi (tkenami) pprzez przechwywanie infrmacji miejscu przebywania karty (np. wysłana, u użytkwnika) raz jej statusie (np. używana, zagubina, skradzina). 27. W ramach rzwiązania musi zstać dstarczne i zainstalwane prgramwanie Punktów Rejestracji i Persnalizacji Kart pisane w p. IV. 28. a) W ramach nwych urzędów certyfikacji winna być dstarczna funkcjnalnść serwera OCSP, uruchmina na dwóch drębnych serwerach sprzętwych współpracujących z dwma urządzeniami balanswania ruchem (lad balancing). b) Serwer OCSP musi zapewnić mżliwść bsługi 30000 zapytań status certyfikatu w ciągu gdziny. c) Rzwiązanie serwerów OCSP wraz z urządzeniami balanswania ruchem musi pracwać w knfiguracji HA. d) Rzwiązanie musi umżliwiać pracę z dwlnym prawidłw wydanym certyfikatem dla usługi OCSP wydanym przez dwlny urząd CA. e) Wdrżne rzwiązanie zstanie sknfigurwane w taki spsób aby klucze usługi OCSP były zarządzane przez dwa sprzętwe mduły HSM. 29. a) W ramach nwych urzędów certyfikacji musi być dstarczna funkcjnalnść serwera SCEP (Simple Certificate Enrllment Prtcl) plegająca na dbieraniu wnisków certyfikat d uwierzytelninych klientów usługi i kierwaniu ich d urzędu CA raz udstępniania wydanych przez urząd CA certyfikatów (w tym CVC) uwierzytelninym klientm. b) Serwer musi zapewnić wydajnść bsługi na pzimie min. 1000 zgłszeń na gdzinę. c) Serwer SCEP musi prawidłw funkcjnwać z prgramwaniem d zarządzania 4
cyklem życia certyfikatów pisanym w p. VI. 30. Oba urzędy certyfikacji (wraz ze wszystkimi serwerami) muszą pracwać w strukturze klastra HA, umżliwiająceg pracę urzędów w przypadku awarii jedneg z serwerów. 31. Urządzenia balanswania ruchem muszą zapewniać: 1) Każde urządzenie pwinn psiadać niezbędną ilść interfejsów Gigabit Ethernet pzwalających na pdłączenie d sieci publicznej, na kmunikację pmiędzy urządzeniami raz na kmunikację z serwerami dla których balanswany jest ruch. 2) bsługiwać d 30000 zapytań OCSP raz 1000 zgłszeń SCEP na gdzinę 3) balanswać ruchem dla warstwy http i https przynajmniej z mżliwścią rzkładania ruch na zainstalwane serwery świadczące usługi OCSP i SCEP. 4) pracwać w knfiguracji pdwyższnej niezawdnści w taki spsób, że niedstępnść lub wyłączenie pjedynczeg urządzenia nie pwduje zaprzestania świadczenia usług balanswania ruchem. 5) urządzenia muszą być zamntwane w szafie RACK. II. Cztery serwery raz macierz dyskwa następujących wymaganiach: 1. Obudwy muszą być dstswane d mntażu w standardwej szafie typu Rack 19. Każdy z serwerów musi być dstarczny wraz z szynami mntażwymi i prwadnicą kabli. 2. Serwery muszą być wypsażne w c najmniej jeden prcesr czterrdzeniwy klasy x86-64, dedykwany d pracy w serwerach, umżliwiający ferwanemu serwerwi wypsażnemu w jeden taki prcesr siągnięcie wyniku c najmniej 110 pkt w teście SPECint_rate2006; wyniki testu pwinny być gólnie dstępne na strnie www.spec.rg. 3. Płyty główne muszą być dedykwane d pracy w serwerach raz wyprdukwane przez prducenta dstarcznych serwerów, muszą psiadać mżliwść rzbudwy d dwóch prcesrów. W przypadku dstarczenia przez Wyknawcę urządzeń HSM (pisanych w p. III) w pstaci kart PCI lub PCI-X lub PCI Express, płyty główne muszą psiadać stswne interfejsy. 4. Serwery muszą być wypsażne w c najmniej 8 GB ECC (2x4 GB lub 4x2 GB) w pełni bufrwanej pamięci DIMM, częsttliwści taktwania min. 1066 MHz. Serwery muszą mieć mżliwść rzbudwy pamięci d c najmniej 16 GB. 5. Serwery muszą psiadać minimum dwa dyski, każdy pjemnści c najmniej 300GB, interfejs SAS 6Gb/s, minimum 10000 RPM, Ht Plug. Dyski muszą być pdłączne d kntrlera SAS 6Gb/s i pracwać w knfiguracji RAID 1 realizwanej za pmcą sprzętweg kntrlera. Wyknawca dstarczy d każdeg serwera p jednym dysku zapaswym, dkładnie takich samych parametrach jak zainstalwane w serwerach. 6. Serwery muszą zstać wypsażne w redundantne karty pzwalające na pdłączenie macierzy dyskwej za pmcą interfejsu FC standardzie nie niższym niż 8GFC lub SAS, nie mniej niż 6 Gb/s. 7. Serwery muszą psiadać dwie redundantne karty sieciwe 10/100/1000 Mbps 8. Karta graficzna zintegrwana z płytą główną, wyświetlająca grafikę rzdzielczści min. 1280x1024. 9. Napęd ptyczny min. DVD+/-RW, zapis DVD+RW z prędkścią x8, zapis DVD-RW z prędkścią x4. 10. Każdy z serwerów musi psiadać p dwa zasilacze redundantne Ht-Plug z kmpletem kabli zasilających. 11. Wydajnść dstarcznych serwerów musi zapewniać uzyskanie wymagań wydajnściwych raz funkcjnalnych pisanych w p. I, IV raz VI. 5
12. Zewnętrzna macierz dyskwa musi zawierać redundantne kntrlery RAID (0, 1, 5, 6, 10, 50) z pamięcią cache min. 2GB w każdym kntrlerze. 13. Obudwa macierzy musi być dstswana d mntażu w standardwej szafie typu Rack 19. Macierz musi być dstarczna wraz z szynami mntażwymi. 14. Macierz musi psiadać mżliwść instalacji c najmniej 24 dysków Ht Plug. Macierz musi umżliwiać redundantne pdłączenie za pmcą interfejsu FC standardzie nie niższym niż 8GFC lub SAS, nie mniej niż 6 Gb/s. Zamawiający dstarczy macierz z zainstalwanymi 9 dyskami SAS 6Gb/s dual-prt, pjemnści c najmniej 300 GB, 10000 RPM, Ht Plug. 15. Macierz musi psiadać zasilacze redundantne Ht Plug z kmpletem kabli zasilających. 16. Macierz dyskwa musi być pdłączna w spsób redundantny d dwóch serwerów realizujących funkcjnalnść centrum certyfikacji. 17. Wyknawca dstarczy serwery z zainstalwanym systemem peracyjnym, dpwiadającym wymaganim funkcjnalnym dla systemu. 18. Wyknawca dstarczy i sknfiguruje prgramwanie klastra wyskiej dstępnści na dwóch serwerach centrum certyfikacji wraz z dstarczną macierzą dyskwą. Oprgramwanie klastrwe musi zapewnić autmatyczne przełączanie aplikacji wraz z wykrzystywanymi przez nią zasbami w przypadku wystąpienia awarii raz mżliwść przełączania ręczneg. 19. Oferwany typ serwerów, system peracyjny raz macierz dyskwa musi znajdwać się na liście kmpatybilnści (Hardware Cmpatibility List) ferwaneg prgramwania klastrweg, publikwanej przez prducenta prgramwania. III. Cztery urządzenia HSM następujących minimalnych wymaganiach: 1. Certyfikat c najmniej FIPS 140-2 Level 2 lub Cmmn Criteria EAL4. 2. Aktywacja urządzeń musi być parta karty kryptgraficzne. 3. Zabezpieczenie klucza główneg z zastswaniem kart kryptgraficznych raz z zastswaniem mechanizmu pdziału sekretu w schemacie prgwym stpnia (m,n), gdzie wartść m i n peratr pdczas eksplatacji mże swbdnie kształtwać na pzimie d 1 d 16. 4. Urządzenie musi umżliwić generwanie, zarządzanie i krzystanie z wielu kluczy równcześnie. 5. Urządzenie musi bsługiwać algrytmy RSA z kluczami długściach 1024/2048/4096 bit, funkcje skrótu minimum SHA-1, SHA-256, SHA-512 raz wsparcie dla generacji kluczy z zastswaniem algrytmów partych krzywe eliptyczne 6. Wydajnść urządzeń przy użyciu algrytmu RSA z kluczem 2048 bitów pwinna być nie mniejsza niż 50 peracji kryptgraficznych na sekundę. 7. Urządzenie musi zstać dstarczne w pstaci karty PCI lub PCI-X lub PCI Express mntwanej w serwerze lub w pstaci urządzenia zewnętrzneg mntwaneg w szafie RACK 19 z interfejsem kmunikacyjnym Ethernet 100 lub 1000 Mbps. 8. Mżliwść bezpieczneg przeniesienia materiału kryptgraficzneg na inny mduł HSM (w brębie teg sameg mdelu) pprzez dtwrzenie klucza główneg zabezpieczneg z użyciem pdziału sekretu w schemacie prgwym przy użyciu dpwiedniej ilści kart kryptgraficznych. 9. Mżliwść bezpieczneg usuwania kluczy. 10. Urządzenie musi zstać dstarczne wraz z prgramwaniem d zarządzania kluczami w ramach mdułu HSM raz wraz z kartami administracyjnymi i peratrskimi niezbędnymi d aktywacji mdułu w ilści minimum 16 szt. dla każdeg mdułu. 6
11. Urządzenie musi zstać dstarczne z interfejsem PKCS#11 w wersji 2.01 lub nwszym. IV. Trzy stanwiska punktów rejestracji (RA) raz persnalizacji kart kryptgraficznych: 1. Każdy kmputer musi psiadać budwę Micr Twer ATX. 2. Każdy kmputer musi być wypsażny w prcesr dwurdzeniwy klasy x86-64, umżliwiający siągnięcie przez ferwany kmputer wydajnści w teście Bapc SYSMARK 2007 Preview wyników nie grszych niż 150 punktów (SYSmark 2007 Preview Rating) na pdstawie tabeli publikwanej pd adresem: http://www.bapc.cm/supprt/fdrs/sysmark2007web.html 3. Płyta główna każdeg z kmputerów: musi być kmpatybilna z wybranym prcesrem, musi bsługiwać pamięć DDR3 d minimum 16GB, musi psiadać 4 gniazda pamięci, musi mieć mżliwść pracy w trybie dual channel, musi psiadać 2 wejścia PS/2 raz 10 x USB 2.0 (cztery na panelu przednim budwy). 4. W każdym z kmputerów musi być zainstalwane 4 GB (2x2 GB) pamięci RAM DDR3, 1333 MHz. 5. Każdy z kmputerów musi psiadać dysk twardy pjemnści 320 GB, minimum 7200 RPM, 16MB cache, minimum SATA II. 6. Każdy z kmputerów musi psiadać napęd ptyczny DVD+/-RW. Minimalne prędkści zapisu: DVD+R 8x, DVD+RW 8x, DVD-R 8x, DVD-RW 6x. Interfejs SATA. 7. Każdy z kmputerów musi psiadać kartę sieciwą 10/100/1000 Mbps zintegrwaną z płytą główną. 8. W każdym z kmputerów musi być karta graficzna zintegrwana z płytą główną, umżliwiająca pracę przy rzdzielczści 1440x900 lub wyższej zgdnej z mnitrem, psiadająca złącze DVI-D umżliwiające pdłączenie dstarczneg mnitra. 9. Każdy z kmputerów musi psiadać kartę dźwiękwą zintegrwaną z płytą główną. 10. Każdy z kmputerów musi mieć zasilacz dpwiedni d zainstalwanych pdzespłów. 11. Każdy z mnitrów musi mieć przekątną ekranu c najmniej 19. Każdy z mnitrów musi pracwać w rzdzielczści nminalnej minimum 1440x900, przy czasie reakcji plamki <=5 ms, brak uszkdznych (bad pixel, ht pixel) pikseli, złącze DVI-D. 12. D każdeg z kmputerów musi być klawiatura pdłączana pprzez złącze USB lub PS/2, wypsażna w 104 klawisze QWERTY. 13. D każdeg z kmputerów musi być mysz ptyczna z rlką pdłączana pprzez złącze USB lub PS/2 raz pdkładka. 14. Każdy z kmputerów musi mieć zainstalwany system peracyjny Micrsft Windws 7 Prfessinal 32-bit PL. 15. Oprgramwanie ddatkwe: Micrsft Office 2010 Prfessinal PL raz prgram typu Internet security (prgram antywiruswy + firewall + antyspyware) z rczną subskrypcją aktualizacyjną. 16. Każdy z czytników kart kryptgraficznych musi: - psiadać złącze USB, - psiadać zgdnść z PC/SC, - psiadać zgdnść ze standardami ISO 7816, - współpracwać z dstarcznym śrdwiskiem, - psiadać interfejs stykwy, - psiadać sygnalizację ptyczną akceptacji karty raz pracy z kartą, - gwarantwać pprawną pracę dla c najmniej 100 000 cykli włżenia/wyjęcia karty, Wyknawca dstarczy prgramwanie niezbędne d współpracy z dstarcznymi czytnikami. 7
17. Oprgramwanie punktu rejestracji zainstalwane na stanwiskach musi prwadzić rejestr wnisków elektrnicznych w tym wnisków PKCS#10, które będą stanwiły pdstawę d wydania certyfikatu. W rejestrze muszą być zawarte przynajmniej następujące dane: Data rejestracji wnisku. Osba która zarejestrwała wnisek. Treść wnisku. Status bsługi wnisku. System musi umżliwić przeglądanie rejestru raz mechanizmy wyszukiwania rekrdów z danymi spełniającymi zadane kryteria. 18. Oprgramwanie punktu rejestracji musi umżliwiać maswe wprwadzenie danych niezbędnych d wydania certyfikatów na pdstawie elektrnicznych plików wsadu w pstaci c najmniej tekstwej. 19. 1) Oprgramwanie punktu rejestracji musi ewidencjnwać spersnalizwane z użyciem systemu karty kryptgraficzne. W tym celu system musi prwadzić rejestr spersnalizwanych kart który będzie zawierał minimum następujące infrmacje: Datę rejestracji karty w systemie. Dane sby która zarejestrwała kartę w systemie. Elektrniczny numer seryjny karty. Prducent/mdel karty. Aktualny status karty (min. spersnalizwana, zagubina, zniszczna, zablkwana). Aktualny status dystrybucji karty (min. wydana, zwrócna). 2) W ramach rejestru w kntekście każdej zarejestrwanej karty muszą być również rejestrwane infrmacje każdej persnalizacji karty raz infrmacje tym jakie certyfikaty były wgrywane w ramach pszczególnych persnalizacji karty. Infrmacje te muszą zawierać c najmniej dane takie jak: Data persnalizacji karty. Dane sby która persnalizwała kartę w systemie. Status z jakim zakńczyła się persnalizacji. Certyfikaty które zstały wgrane na kartę. 3) Oprgramwanie RA musi umżliwić przeglądanie bazy rejestracji raz psiadać mechanizmy wyszukiwania rekrdów z danymi spełniającymi zadane kryteria. 20. 1) W ramach persnalizacji graficznej karty prgramwanie musi pzwalać na zdefiniwanie przez peratra pdczas eksplatacji systemu szablnów szaty graficznej wizerunku karty (awersu i rewersu karty). W ramach definiwania szablnów szaty graficznej karty być mżliwe swbdne wybranie pól jakie będą nadrukwywane na karcie spśród minimum następująceg zakresu infrmacji: Zdjęcie sby. Imię sby. Nazwisk sby. Identyfikatr sby (np. PESEL lub numer służbwy). Organizacja (Np. Gmina). Jednstka rganizacyjna (np. wydział lub departament). Data kńca ważnści certyfikatu (lub jedneg wskazaneg certyfikatu spśród wielu wgrywanych na kartę). 8
Elektrniczny numer seryjny karty. 2) Definiwanie umiejscwienie wybranych pól infrmacji na karcie pdczas definiwania szablnu pwinn być wyknywane przez peratra lub administratra z użyciem narzędzia graficzneg dstarczneg wraz z systemem. 21. Wyszukiwanie danych takich jak spersnalizwane dla daneg pdmitu/sby karty czy wygenerwane dla daneg pdmitu certyfikaty muszą być mżliwe d wglądu w spsób kntekstwy p wyszukaniu rekrdu pdmitu/sby. 22. System musi umżliwiać identyfikację pdmitu/sby (subskrybenta) certyfikatu/karty na pdstawie pdanych przez nieg lsw wybranych znaków z hasła uwierzytelniająceg. Operatr punktu RA nie mże mieć mżliwści zapznania się z treścią całeg hasła. 23. System musi umżliwiać generwanie kdów zabezpieczających (np. PIN) raz haseł uwierzytelniająceg zgdnie z szablnem zdefiniwanym przez peratra RA. 24. Każdy punkt RA musi mieć urządzenie (drukarka) d persnalizacji kart mikrprcesrwych które musi: - bsługiwać karty w frmacie ID1, - psiadać pdajnik na nie mniej niż 100 kart, - umżliwiać dwustrnny, klrwy nadruk na kartach z materiału typu PVC, - umżliwiać wydruk (persnalizację graficzną) c najmniej 50 kart na gdzinę. - zapewnić elektrniczną (stykwą i bezstykwa) persnalizację kart (urządzenie musi być wypsażne w ba typy kderów kart) 25. System musi zapewniać mżliwść elektrnicznej i graficznej persnalizacji kart kryptgraficznych w trybie autmatycznym na pdstawie pliku wsadu. 26. Drukarka d etykiet w każdym z punktów RA musi: - umżliwiać wydruk etykiet samprzylepnych w rzdzielczści 300 x 300 dpi i rzmiarach kreślnych w p. XII, - psiadać wydajnść nie mniejszą niż 100 etykiet samprzylepnych na gdzinę. 27. Drukarka igłwa dla każdeg z punktów RA d zabezpiecznych kpert musi umżliwiać wydruk graficzny na zabezpiecznych papierwych kpertach z wydajnścią minimum 50 kpert na gdzinę. 28. Drukarka laserwa klrwa wydajnści 10 strn na minutę w frmacie A4, psiadająca interfejs sieciwy. 29. Wszystkie trzy stanwiska muszą zapewnić pełną współpracę z bma urzędami certyfikacji wymieninymi w p. I. Wszystkie dane niezbędne dla urzędów certyfikacji muszą zstać przesłane siecią teleinfrmatyczną, bez kniecznści pwtórneg wprwadzania danych już znajdujących się (lub wprwadznych) na w/w stanwiskach. V. Dwa dkumenty Plityk certyfikacji 1. Dkumenty muszą być przygtwane zgdnie z wytycznymi RFC 3647 Internet X.509 Public Key Infrastructure Certificate Plicy and Certificatin Practices Framewrk. 2. Wyknawca wytwrzy dkumenty Plityk certyfikacji na wzór dstarcznej przez Zamawiająceg Plityki, p jednym dla każdeg z wdrażanych urzędów tj.: - urząd d generacji kluczy dla urządzeń infrastruktury - urząd d generacji kluczy dla urzędników bsługujących aplikacje lkalne 3. Wyknawca dkna uruchmienia Urzędów Certyfikacji w parciu wytwrzne Plityki Certyfikacji. 4. Certyfikaty wydane przez urząd generacji kluczy dla urządzeń infrastruktury muszą 9
umżliwiać pełnienie m.in. funkcji: - klient SSL, - serwer SSL, - urządzenia sieciwe VPN, - szyfrwanie danych. 5. Certyfikaty wydane przez urząd generacji kluczy dla urzędników bsługujących aplikacje lkalne muszą pełnić m.in. funkcje: - pdpisywanie danych, - uwierzytelnienie użytkwnika. VI. Oprgramwanie d zarządzania cyklem życia certyfikatów w parciu prtkły Simple Certificate Enrllment Prtcl (SCEP) 1. Wyknawca dstarczy prgramwanie niezbędne d uruchmienia usługi zarządzania cyklem życia certyfikatów w parciu prtkół SCEP i współpracująceg z serwerem SCEP stanwiącym element nwych centrów certyfikacji. 2. Wyknawca dstarczy prgramwanie klienta SCEP które: 1. musi pprawnie współpracwać z kntenerami certyfikatów (serwer aplikacyjny JBss lub równważny) w zakresie: a. generacji kluczy kryptgraficznych, b. generacji zgłszeń certyfikacyjnych, c. zasilenia kntenera certyfikatami trzymanymi z urzędu certyfikacji, d. zapewnienia interfejsu d wprwadzania danych pól certyfikatu e. kntrlwania ważnści certyfikatów umieszcznych w kntenerze i w zdefiniwanym czasie przesłać d usługi SCEP żądanie dnwienie certyfikatu. 2. musi w pprawny spsób współpracwać z dstarczną usługą SCEP w zakresie: a. przesyłania d usługi SCEP zgłszeń certyfikacyjnych, b. pbierania d usługi SCEP gtwych certyfikatów. c. Zapewniać inicjalną certyfikację uwierzytelniną hasłem 3. Oprgramwanie klienta SCEP jak również serwera SCEP, musi być dstarczne wraz z licencją niegraniczającą Zamawiająceg w kwestii ilści rejestrwanych użytkwników i składanych przez subskrybentów wnisków. VII. Pdsystem wyknywania kpii bezpieczeństwa (backupu) 1. Pdsystem musi umżliwiać: 1. Wyknywanie kpii bezpieczeństwa zasbów znajdujących się w utwrznych systemach 2. Odtwarzanie danych z kpii bezpieczeństwa. 3. Zapisywania danych na taśmach. 2. Wyknawca dstarczy pniższy sprzęt raz prgramwanie d wyknywania backupów: 1. Urządzenie taśmwe w budwie dstswanej d mntażu w standardwej szafie typu Rack 19, wyskść budwy nie mże przekrczyć 1U. 2. Urządzenie musi być wypsażne w jeden napęd LTO pjemnści natywnej nie mniejszej niż 400GB, raz w czytnik kdów paskwych. 3. Urządzenie musi umżliwiać równczesne umieszczenie minimum 8 nśników taśmwych. 4. Pjemnść natywna urządzenia nie mże być mniejsza niż 3,2 TB. 5. Urządzenie musi współpracwać z taśmami jedn- i wielkrtneg zapisu. 6. Urządzenie musi być wypsażne w interfejs hsta FC, nie mniej niż 8GFC lub SAS, nie mniej niż 6 Gb/s. 10
7. Dstarczne wraz z urządzeniem sterwniki i prgramwanie d wyknywania kpii zapaswych musi dpwiadać systemm peracyjnym dstarcznym w ramach niniejszeg pstępwania. 8. Wraz z urządzeniem Wyknawca dstarczy niezbędną ilść taśm wielkrtneg zapisu wynikającą z prcedury backupwania, zgdnych z technlgią LTO, pjemnści natywnej c najmniej 400GB, jednak nie mniej niż 8 sztuk, raz jedną taśmę czyszczącą. 9. Wraz z urządzeniem Wyknawca dstarczy raz sknfiguruje prgramwanie d wyknywania kpii zapaswych. Wraz z urządzeniem Wyknawca dstarczy kntrler hsta FC, nie mniej niż 8GFC lub SAS, nie mniej niż 6 Gb/s raz kablwanie dpwiedniej długści i zainstaluje w jednym z dstarcznych serwerów. 3. Wyknawca dstarczy prgramwanie umżliwiające wyknywanie backupów na urządzeniu taśmwym pisanym w p. 2, wraz z bsługą zmieniarki i czytnika kdów paskwych. Oprgramwanie musi umżliwiać wyknywanie backupu serwera, d któreg będzie pdłączne urządzenie taśmwe, raz wyknywanie backupu pprzez sieć LAN pzstałych serwerów dstarcznych w ramach niniejszeg pstępwania. 4. Wyknawca przygtuje i przedstawi d zaakceptwania Zamawiającemu niezbędne prcedury i instrukcje d wyknywania backupów. VIII. Mduł serwera czasu 1 Wyknawca dstarczy mduł serwera czasu który musi: 1. Synchrnizwać czas UTC dla dstarczaneg systemu. 2. Pracwać w parciu prtkły NTP raz SNTP. 3. Dla synchrnizacji czasu wykrzystywać (pprzez płączenie satelitarne) sygnał z satelitów systemu GPS. 4. Psiadać scylatr OCXO. 5. Mieć mżliwść mntażu w szafie typu Rack 19. 2 Wyknawca w miejscu (knkretnie: w biekcie w którym eksplatwane jest Centrum) wskazanym przez Zamawiająceg zainstaluje antenę GPS, którą następnie płączy i sknfiguruje z serwerem czasu. IX. Instruktaż 1. Wyknawca udzieli instruktażu dla 7 sób wskazanych przez Zamawiająceg z zakresu: - bsługi dstarczneg prgramwania, - bsługi dstarcznych urządzeń, - bsługi mechanizmów zarządzania cyklem życia certyfikatów. X. Sejf 1. Sejf musi umżliwiać przechwywanie nśników ptycznych i magnetycznych. 2. Sejf musi psiadać dprnść na włamanie klasy I, zgdnie z nrmą PN EN 1143-1. 3. Sejf musi psiadać gnidprnść gwarantującą bezpieczeństw zawartści przez c najmniej 60 minut. 4. Sejf musi psiadać 2 zamki: elektrniczny raz kluczwy. 5. Sejf musi psiadać pjemnść nie mniejszą niż 160 litrów. 6. Sejf musi być dstarczny wraz z c najmniej jedną półką stałą. 7. S Sejf musi psiadać trzy zamykane na klucz szuflady. 11
XI. Szafa Rack 1. Wyknawca zbwiązany jest d dstarczenia szafy Rack 19 następujących parametrach: - wyskść 42U - szerkść 600 mm - głębkść 1000 mm - drzwi przednie muszą psiadać perfrację drbną, zamykane na klucz - drzwi tylne muszą psiadać perfrację drbną, skrócne + 2 maskwnice 3U - słny bczne muszą być pełne - dach musi psiadać twry na zaślepkę - pdstawa musi psiadać ckół wyskści 100 mm - przednia ściana ckłu musi mieć wysuwaną ramę wsprczą - tylna ściana ckłu musi psiadać perfrację - lewa i prawa ściana musi być z przepustem szcztkwym - w szafie muszą być zamntwane dwie pary belek nśnych 19 raz jedna para belek nśnych śrdkwych - w panelu wentylacyjnym muszą być zamntwane 4 wentylatry - w szafie muszą być zamntwane 2 półki stałe z elementami mcującymi d mntażu na belkach nśnych, głębkści 650 mm - szafa musi być w klrze czarnym - w szafie muszą być zamntwane dwie listwy zasilające wszystkie urządzenia, pzwalające na pdłączenie d sieci energetycznej XII. Materiały eksplatacyjne 1. Wyknawca dstarczy materiały eksplatacyjne dla drukarek w ilści niezbędnej d spersnalizwania 25000 kart mikrprcesrwych w technlgii klrwej przy załżeniu, że nadruk będzie następwał na jednej strnie karty. 2. Wyknawca dstarczy zabezpieczne kperty d wydruku kdów PIN w ilści 25000 sztuk 3. Wyknawca dstarczy naklejki pzwalające na wydruk 50000 białych etykiet wielkści nie mniejszej niż 70mm x 35mm i nie większej niż 100mm x 50 mm 4. Wyknawca dstarczy papier d wydruku dkumentacji, frmat A4, 80 g/m 2 50 ryz. 5. Wyknawca dstarczy czyste, zapisywalne płyty DVD w plastikwych, pjedynczych pakwaniach 40 sztuk. XIII. Gwarancja 1. W przypadkach gdzie nie wyspecyfikwan inaczej, ferent zapewni 36 miesięcy gwarancji na części, rbciznę i naprawę w miejscu instalacji. Naprawa zstanie wyknana w ciągu 7 dni rbczych d mmentu zgłszenia przez Zamawiająceg. Zgłszenia awariach składane będą w dni rbcze w gdzinach 8-16. Uszkdzne nśniki danych pzstają u Zamawiająceg. 2. Oferent zapewni, że w kresie gwarancji Zamawiający będzie miał praw dstępu d aktualizacji, pprawek i nwych wersji systemu peracyjneg raz prgramwania dstarczneg wraz z serwerami. 3. Przed uruchmieniem prdukcyjnym urzędów, wyknawca przeprwadzi testy akceptacyjne w zakresie funkcjnalnści kreślnych w Opisie Przedmitu Zamówienia. XIV. Wymagania ddatkwe 1. Wyknawca w ramach zamówienia dstarczy wszystkie, niewymienine w niniejszym pisie, elementy w tym sprzęt i prgramwanie (wraz z bezterminwymi licencjami) w ilściach niezbędnych d prawidłweg uruchmienia i eksplatacji w/w systemów. 2. W kresie 6 miesięcy d uruchmienia systemu Wyknawca będzie zbwiązany d dknania ewentualnych mdyfikacji w knfiguracji prgramwania centrum certyfikacji (CA) raz punktów rejestracji (RA) w przypadku gdyby zmiany te wynikały ze 12
zmiany bądź pwstania nwych przepisów prawa w zakresie rzprządzeń d ustawy dwdach sbistych z dnia 6 sierpnia 2010 (Dz.U. Nr 167, pz. 1131). 3. Wszystkie urządzenia dstarczne w ramach zamówienia (pza stanwiskami punktów rejestracji) muszą być zamntwane w standardwej szafie typu Rack 19 i nie mgą łącznie przekraczać wyskści 30U. 4. Wdrżenie nie mże wpłynąć na pzim świadczenia usług dla systemów teleinfrmatycznych krzystających z usług Centrum Certyfikacji. 5. Architektura systemu musi przewidywać utwrzenie centrum zapasweg jak również nie mże być sprzeczna z rzwiązaniami architektnicznymi prjektu pl.id (szczegóły dtyczące wykrzystywanych rzwiązań dstępne są pd adresem: http://cpi.mswia.gv.pl/prtal/cpi/390/1990/dkumentacja_techniczna_dt_pr jektu_plid.html). Wszędzie gdzie t mżliwe, dstarczane rzwiązanie musi być zgdne ze standardami i prtkłami kmunikacyjnymi pwszechnie wykrzystywanymi w budwie systemów IT, w szczególnści: XML, SOAP, WebServices, JSP, HTTP, HTTPS, XSD, WSDL, JEE, X509, VPN, SCEP, OCSP. XV. Dkumentacja 1. Zamawiający wymaga, aby Wyknawca przygtwał, zgdnie z gólnie akceptwalnymi standardami w dziedzinie dkumentwania, następujące rdzaje dkumentacji: Harmngram i plan realizacji Umwy Prcedury akceptacji i dbiru przedmitu Umwy Prcedurę zarządzania zmianami Plan Testów Akceptacyjnych zawierający: Opis dstarczaneg prgramwania. Scenariusze testwe. Terminy testów akceptacyjnych. Kategryzację błędów i warunki dbiru. Opisy ról raz dpwiedzialnści sób zaangażwanych w przeprwadzenie testów raz dbiór przedmitu Umwy. Spsób i terminy naprawy błędów. Opis śrdwiska testweg. Plany testów systemwych, wydajnściwych i integracyjnych w zakresie właściwym dla zaawanswania budwy systemu. Raprt Wyników Testów zawierający: Infrmacje zakresie przeprwadznych testów. Liczbie i rdzaju błędów. Pdsumwanie wyników testów. Plan Instruktażu zawierający c najmniej: Harmngram Instruktażu. Szczegółwą listę zawierającą infrmacje zakresie tematycznym pszczególnych sptkań instruktażwych. Infrmacje miejscu przeprwadzenia pszczególnych sptkań instruktażwych. Prjekt Techniczny uwzględniający: Dkumentację użytkwnika: Opracwanie wyskpzimwej architektury rzwiązania. Opracwanie niskpzimwej architektury rzwiązania. Opracwanie wytycznych d budwy śrdka zapasweg. Opracwanie szacwania ksztów eksplatacji systemu w ciągu 5 lat. Instrukcje użytkwnika - system musi psiadać pełną dkumentację użytkwnika pisującą mżliwści knfiguracji aplikacji przez użytkwnika raz dstępnych funkcjnalnści. Dtyczy t także pisów 13
interfejsów użytkwnika. Instrukcje administratra zawierająca mżliwści knfiguracyjne i zarządcze dstarczaneg rzwiązania. Dkumentację eksplatacyjną, zawierającą, c najmniej plan utrzymania ciągłści działania raz prcedury: administracyjne, backupu systemu i danych, awaryjne i użytkwnika, przy czym każda z prcedur pwinna zawierać, c najmniej następujące wyszczególnine infrmacje: prcedury związane z administracją i eksplatacją Systemu, prcedury charakterze testwym, prcedury działania administratra Systemu, prcedury knserwacji pdsystemów Systemu, prcedury awaryjne, prcedury zabezpieczeń (backup we), prcedury kntrli bezpieczeństwa Systemu (Audyt), Prcedury ciągłści działania (uwzględniające przełączanie śrdków). Każda z w/w prcedur będzie zawierać minimum następujące infrmacje: nazwa prcedury, rdzaj prcedury, data utwrzenia i zatwierdzenia raz wersja prcedury, cel i zakres prcedury, warunki uruchmienia prcedury i czekiwany raz mżliwy rezultat jej wyknania, dane sób, które pracwały prcedurę, sprawdziły, zaakceptwały i zatwierdziły, wzór frmularza zgłszenia Awarii (dla prcedur awaryjnych), algrytm działania, jaki należy zastswać, wyknując klejne czynnści, aby siągnąć pstawiny cel, w tym infrmacja sbie która pwinna wyknać dane czynnści. 2. Zamawiający wymaga, aby wszystkie dkumenty twrzne w ramach realizacji przedsięwzięcia charakteryzwały się wyską jakścią na którą będą miały wpływ takie czynniki jak: Struktura dkumentu, rzumiana jak pdział daneg dkumentu na rzdziały, pdrzdziały i sekcje, w czytelny i zrzumiały spsób. Zachwanie standardów, a także spsób pisania, rzumianych jak zachwanie spójnej struktury, frmy i spsbu pisania dla pszczególnych dkumentów raz fragmentów teg sameg dkumentu Kmpletnść dkumentu, rzumiana jak pełne przedstawienie mawianeg prblemu bejmujące całść z daneg zakresu rzpatrywaneg zagadnienia. Spójnść i niesprzecznść dkumentu, rzumianych jak zapewnienie wzajemnej zgdnści pmiędzy wszystkimi rdzajami infrmacji umieszcznymi w dkumencie, jak i brak lgicznych sprzecznści pmiędzy infrmacjami zawartymi we wszystkich przekazanych dkumentach raz we fragmentach teg sameg dkumentu. 3. Zamawiający wymaga, aby cała dkumentacja, której mwa pwyżej, pdlegała jeg akceptacji, a także, aby zstała dstarczna w języku plskim, w wersji elektrnicznej w frmacie Wrd i/lub PDF (na płycie CD-ROM lub innym równważnym nśniku danych) i drukwanej, c najmniej w 3 egzemplarzach (dpuszcza się inne frmaty zapisu dkumentacji np. diagramy UML lub frmaty wektrwe jak DWG,. DXF, należy jednak dłączyć przeglądarkę bsługującą wykrzystane frmaty). Dla harmngramów frmat MPP. 4. Kdy źródłwe d wytwrzneg prgramwania muszą być patrzne kmentarzami, wyjaśnieniami. W przypadku kdów źródłwych prgramwania wytwrzneg w języku Java, Wyknawca przekaże także dkumentację kdów źródłwych przygtwaną w narzędziu JavaDc. 14