docOpis przedmiotu zamówienia (OPZ)
download 
Reklamacja Transkrypt
Opis przedmiotu zamówienia (OPZ)
Opis przedmiotu zamówienia (OPZ) na modernizację Centrum Certyfikacji Kluczy na potrzeby Projektu „pl.ID – polska ID karta” oraz Projektu „SIPR” tekst jednolity uwzględniający zmianę z dnia 28 czerwca 2011 1 Wstęp Przedmiotem zamówienia jest modernizacja Centrum Certyfikacji MSWiA zapewniająca generowanie certyfikatów infrastruktury i certyfikatów użytkowników na potrzeby pl.ID i SIPR. W ramach zamówienia Wykonawca: opracuje dwa dokumenty polityki certyfikacji na podstawie wytycznych dostarczonych przez Zamawiającego, uruchomi mechanizmy zarządzania cyklem życia certyfikatów w oparciu o protokół Simple Certificate Enrollment Protocol, dostarczy dwa nowe urzędy certyfikacji zawierające co najmniej cztery serwery sprzętowe wraz z systemami operacyjnymi, cztery moduły kryptograficzne HSM, macierz dyskową, oprogramowanie bazy danych, oprogramowanie realizujące funkcjonalność klastra niezawodnościowego oraz oprogramowanie realizujące funkcjonalność centrum certyfikacji, serwery usług OCSP i SCEP działające w konfiguracji HA z możliwością balansowania ruchu, dostarczy podsystem backupu realizujący funkcjonalność wykonywania kopii bezpieczeństwa (backup), dostarczy dwa przełączniki sieciowe 24 portowe Gigabit Ethernet, dostarczy dwa urządzenia balansujące ruchem dla usług OCSP oraz SCEP, dostarczy aplikacje do zarządzania cyklem życia certyfikatów w oparciu o protokół SCEP oraz OCSP, dostarczy trzy kompletne stanowiska operatorskie przeznaczone do rejestracji oraz obsługi wniosków o wydanie certyfikatów oraz do personalizacji kart współpracujące z dwoma budowanymi urzędami certyfikacji każde wyposażone w komputer PC z systemem operacyjnym, monitor, dwa czytniki kart kryptograficznych, drukarkę do personalizacji graficznej i elektronicznej kart, drukarkę igłową do wydruku kopert utajnionych z kodami do kart, drukarkę do wydruku etykiet samoprzylepnych, drukarkę laserową do wydruku dokumentacji, licencje oprogramowania z funkcjonalnością personalizacji kart dostarczy i skonfiguruje moduł serwera czasu, dostarczy sejf dostarczy szafę Rack włączy nowe urzędy certyfikacji w strukturę drzewa zaufania Centrum Certyfikacji MSWiA, wdroży całe rozwiązanie oraz zapewni wsparcie eksploatacyjne przez okres 6 miesięcy od momentu wskazanego przez Zamawiającego, będzie świadczył usługi gwarancji przez okres 36 miesięcy, przeprowadzi niezbędny instruktaż dla pracowników Zamawiającego. Wymagania I. Wdrożenie dwóch nowych urzędów certyfikacji (CA): 1. Wykonawca wdroży w ramach systemu dwa urzędy certyfikacji: - urząd do generacji kluczy dla urządzeń infrastruktury (w szczególności pl.ID), - urząd do generacji kluczy dla urzędników obsługujących aplikacje lokalne (w szczególności dla projektów pl.ID i SIPR). 2. Urząd dla infrastruktury zapewni w ramach dostarczonej licencji możliwość wydawania nielimitowanej liczby certyfikatów i rejestracji nieograniczonej liczby użytkowników. 3. Urząd dla operatorów zapewni w ramach dostarczonej licencji możliwość wydawania nielimitowanej liczby certyfikatów i rejestracji nieograniczonej liczby użytkowników. 4. CA muszą: - generować certyfikaty klucza publicznego w standardzie X.509 oraz CVC (Card Verifying Certificate) - generować listy CRL/ARL, 2 - umożliwiać obsługę protokołu SCEP, - umożliwiać weryfikację statusu certyfikatów w oparciu o OCSP. 5. System musi gromadzić z zachowaniem zasady niezaprzeczalności i rozliczalności informacje audytowe umożliwiające odtworzenie historii wszystkich operacji wykonywanych w systemie. 6. System musi umożliwiać przeglądanie informacji audytowych w systemie oraz ich eksport z zachowaniem zasad poufności, rozliczalności i niezaprzeczalności. 7. System musi umożliwiać generowanie certyfikatów na podstawie elektronicznych wniosków w formacie PKCS#10. 8. System musi obsługiwać karty kryptograficzne z wykorzystaniem PKCS#11 lub Microsoft CryptoAPI/CSP. 9. Serwerowa część Systemu musi działać w oparciu o przynajmniej jeden z systemów operacyjnych: RedHat, Novell SuSe, Microsoft Windows. 10. System będzie pozwalał wprowadzać polskie znaki diakrytyczne oraz będzie je poprawnie obsługiwał w generowanych certyfikatach z użyciem kodowania w standardzie UTF8. 11. System musi zapewnić mechanizm bezpiecznej automatycznej archiwizacji kluczy przeznaczonych do celów ochrony poufności (szyfrowania) oraz mechanizmy bezpiecznego odtwarzania kluczy z archiwum. 12. System musi prowadzić ewidencję podmiotów (osób) na potrzeby których obsługiwane są wnioski o certyfikaty, generowane są certyfikaty i personalizowane są karty. Na potrzeby prowadzenia takiej ewidencji system musi umożliwić wprowadzenie minimum następujących danych: Imię osoby. Nazwisko osoby. Identyfikator osoby (np. PESEL lub numer służbowy). Organizacja (Np. Gmina). Jednostka organizacyjna (np. wydział lub departament). Stanowisko. Telefon. Fax. Adres e-mail. Ponadto system musi automatycznie rejestrować dodatkowe dane takie jak: Kiedy informacja została zarejestrowana w Systemie. Kto zarejestrował w Systemie dana informację. System musi umożliwić przeglądanie i modyfikowanie rejestru oraz posiadać mechanizmy wyszukiwania rekordów z danymi spełniającymi zadane kryteria. 13. a) System musi posiadać funkcjonalność umożliwiającą administratorowi konfigurację mechanizmu automatycznego powiadamiania subskrybentów drogą e-mailową, którym wydano certyfikaty na zadaną ilość dni przed wygaśnięciem danego certyfikatu o fakcie zbliżania się okresu końca ważności certyfikatu. b) Administrator musi móc selektywnie z dokładnością do zdefiniowanej w systemie polityki wydawania certyfikatów określić możliwość takiego powiadamiania i zdefiniować sposób i treść komunikatu powiadomienia. Powiadomienia muszą być wysyłane na adres e-mail subskrybenta bądź wnioskodawcy według konfiguracji zadanej przez administratora systemu. c) Na potrzeby realizacji tej funkcjonalności system musi umożliwić gromadzenie 3 danych takich jak adres e-mail subskrybenta i wnioskodawcy. 14. d) System musi posiadać możliwość definiowania użytkowników i przyporządkowywania im odpowiednich ról i praw dostępu a w tym przynajmniej ról: Administratora. Operatora. Audytora. 15. System umożliwia zdefiniowanie okresów zakładkowych dla list CRL. 16. System udostępnia możliwość odnowienia certyfikatu na te same dane. 17. System musi umożliwiać odnawianie certyfikatów bez konieczności generowania nowej pary kluczy, zawieszania, uchylenia zawieszenia, unieważniania certyfikatów. 18. System musi dawać możliwość ograniczenia tworzenia hierarchii PKI. 19. System musi przechowywać informacje oraz certyfikaty w relacyjnej bazie danych. Dopuszczalnymi bazami danych są: DB2, Oracle, PostgreSQL lub MS SQL. 20. System musi umożliwiać eksportowanie generowanych certyfikatów oraz list unieważnień co najmniej do: systemu plików, repozytorium LDAP oraz publikację za pomocą protokołów smtp, ftp, http. 21. Dostęp użytkowników do systemu musi odbywać się z wykorzystaniem silnych technik uwierzytelniania (certyfikat na karcie kryptograficznej). 22. System musi posiadać interfejs użytkownika w języku polskim. 23. System musi wspierać okresowe i na żądanie generowanie list CRL. 24. System musi umożliwiać import, eksport oraz edycję profili certyfikatów. 25. Urzędy Certyfikacji muszą prowadzić rejestry zdarzeń umożliwiające przeprowadzenie szczegółowego audytu z pracy systemu oraz diagnostyki pracy systemu. 26. System musi wspomagać zarządzanie kartami mikroprocesorowymi (tokenami) poprzez przechowywanie informacji o miejscu przebywania karty (np. wysłana, u użytkownika) oraz jej statusie (np. używana, zagubiona, skradziona). 27. W ramach rozwiązania musi zostać dostarczone i zainstalowane oprogramowanie Punktów Rejestracji i Personalizacji Kart opisane w p. IV. 28. a) W ramach nowych urzędów certyfikacji winna być dostarczona funkcjonalność serwera OCSP, uruchomiona na dwóch odrębnych serwerach sprzętowych współpracujących z dwoma urządzeniami balansowania ruchem (load balancing). b) Serwer OCSP musi zapewnić możliwość obsługi 30000 zapytań o status certyfikatu w ciągu godziny. c) Rozwiązanie serwerów OCSP wraz z urządzeniami balansowania ruchem musi pracować w konfiguracji HA. d) Rozwiązanie musi umożliwiać pracę z dowolnym prawidłowo wydanym certyfikatem dla usługi OCSP wydanym przez dowolny urząd CA. e) Wdrożone rozwiązanie zostanie skonfigurowane w taki sposób aby klucze usługi OCSP były zarządzane przez dwa sprzętowe moduły HSM. 29. a) W ramach nowych urzędów certyfikacji musi być dostarczona funkcjonalność serwera SCEP (Simple Certificate Enrollment Protocol) polegająca na odbieraniu wniosków o certyfikat od uwierzytelnionych klientów usługi i kierowaniu ich do urzędu CA oraz udostępniania wydanych przez urząd CA certyfikatów (w tym CVC) uwierzytelnionym klientom. b) Serwer musi zapewnić wydajność obsługi na poziomie min. 1000 zgłoszeń na godzinę. c) Serwer SCEP musi prawidłowo funkcjonować z oprogramowaniem do zarządzania 4 cyklem życia certyfikatów opisanym w p. VI. 30. Oba urzędy certyfikacji (wraz ze wszystkimi serwerami) muszą pracować w strukturze klastra HA, umożliwiającego pracę urzędów w przypadku awarii jednego z serwerów. 31. Urządzenia balansowania ruchem muszą zapewniać: 1) Każde urządzenie powinno posiadać niezbędną ilość interfejsów Gigabit Ethernet pozwalających na podłączenie do sieci publicznej, na komunikację pomiędzy urządzeniami oraz na komunikację z serwerami dla których balansowany jest ruch. 2) obsługiwać do 30000 zapytań OCSP oraz 1000 zgłoszeń SCEP na godzinę 3) balansować ruchem dla warstwy http i https przynajmniej z możliwością rozkładania ruch na zainstalowane serwery świadczące usługi OCSP i SCEP. 4) pracować w konfiguracji podwyższonej niezawodności w taki sposób, że niedostępność lub wyłączenie pojedynczego urządzenia nie powoduje zaprzestania świadczenia usług balansowania ruchem. 5) urządzenia muszą być zamontowane w szafie RACK. II. Cztery serwery oraz macierz dyskowa o następujących wymaganiach: 1. Obudowy muszą być dostosowane do montażu w standardowej szafie typu Rack 19”. Każdy z serwerów musi być dostarczony wraz z szynami montażowymi i prowadnicą kabli. 2. Serwery muszą być wyposażone w co najmniej jeden procesor czterordzeniowy klasy x86-64, dedykowany do pracy w serwerach, umożliwiający oferowanemu serwerowi wyposażonemu w jeden taki procesor osiągnięcie wyniku co najmniej 110 pkt w teście SPECint_rate2006; wyniki testu powinny być ogólnie dostępne na stronie www.spec.org. 3. Płyty główne muszą być dedykowane do pracy w serwerach oraz wyprodukowane przez producenta dostarczonych serwerów, muszą posiadać możliwość rozbudowy do dwóch procesorów. W przypadku dostarczenia przez Wykonawcę urządzeń HSM (opisanych w p. III) w postaci kart PCI lub PCI-X lub PCI Express, płyty główne muszą posiadać stosowne interfejsy. 4. Serwery muszą być wyposażone w co najmniej 8 GB ECC (2x4 GB lub 4x2 GB) w pełni buforowanej pamięci DIMM, o częstotliwości taktowania min. 1066 MHz. Serwery muszą mieć możliwość rozbudowy pamięci do co najmniej 16 GB. 5. Serwery muszą posiadać minimum dwa dyski, każdy o pojemności co najmniej 300GB, interfejs SAS 6Gb/s, minimum 10000 RPM, Hot Plug. Dyski muszą być podłączone do kontrolera SAS 6Gb/s i pracować w konfiguracji RAID 1 realizowanej za pomocą sprzętowego kontrolera. Wykonawca dostarczy do każdego serwera po jednym dysku zapasowym, o dokładnie takich samych parametrach jak zainstalowane w serwerach. 6. Serwery muszą zostać wyposażone w redundantne karty pozwalające na podłączenie macierzy dyskowej za pomocą interfejsu FC o standardzie nie niższym niż 8GFC lub SAS, nie mniej niż 6 Gb/s. 7. Serwery muszą posiadać dwie redundantne karty sieciowe 10/100/1000 Mbps 8. Karta graficzna zintegrowana z płytą główną, wyświetlająca grafikę o rozdzielczości min. 1280x1024. 9. Napęd optyczny min. DVD+/-RW, zapis DVD+RW z prędkością x8, zapis DVD-RW z prędkością x4. 10. Każdy z serwerów musi posiadać po dwa zasilacze redundantne Hot-Plug z kompletem kabli zasilających. 11. Wydajność dostarczonych serwerów musi zapewniać uzyskanie wymagań wydajnościowych oraz funkcjonalnych opisanych w p. I, IV oraz VI. 5 12. Zewnętrzna macierz dyskowa musi zawierać redundantne kontrolery RAID (0, 1, 5, 6, 10, 50) z pamięcią cache min. 2GB w każdym kontrolerze. 13. Obudowa macierzy musi być dostosowana do montażu w standardowej szafie typu Rack 19”. Macierz musi być dostarczona wraz z szynami montażowymi. 14. Macierz musi posiadać możliwość instalacji co najmniej 24 dysków Hot Plug. Macierz musi umożliwiać redundantne podłączenie za pomocą interfejsu FC o standardzie nie niższym niż 8GFC lub SAS, nie mniej niż 6 Gb/s. Zamawiający dostarczy macierz z zainstalowanymi 9 dyskami SAS 6Gb/s dual-port, o pojemności co najmniej 300 GB, 10000 RPM, Hot Plug. 15. Macierz musi posiadać zasilacze redundantne Hot Plug z kompletem kabli zasilających. 16. Macierz dyskowa musi być podłączona w sposób redundantny do dwóch serwerów realizujących funkcjonalność centrum certyfikacji. 17. Wykonawca dostarczy serwery z zainstalowanym systemem operacyjnym, odpowiadającym wymaganiom funkcjonalnym dla systemu. 18. Wykonawca dostarczy i skonfiguruje oprogramowanie klastra wysokiej dostępności na dwóch serwerach centrum certyfikacji wraz z dostarczoną macierzą dyskową. Oprogramowanie klastrowe musi zapewnić automatyczne przełączanie aplikacji wraz z wykorzystywanymi przez nią zasobami w przypadku wystąpienia awarii oraz możliwość przełączania ręcznego. 19. Oferowany typ serwerów, system operacyjny oraz macierz dyskowa musi znajdować się na liście kompatybilności (Hardware Compatibility List) oferowanego oprogramowania klastrowego, publikowanej przez producenta oprogramowania. III. Cztery urządzenia HSM o następujących minimalnych wymaganiach: 1. Certyfikat co najmniej FIPS 140-2 Level 2 lub Common Criteria EAL4. 2. Aktywacja urządzeń musi być oparta o karty kryptograficzne. 3. Zabezpieczenie klucza głównego z zastosowaniem kart kryptograficznych oraz z zastosowaniem mechanizmu podziału sekretu w schemacie progowym stopnia (m,n), gdzie wartość m i n operator podczas eksploatacji może swobodnie kształtować na poziomie od 1 do 16. 4. Urządzenie musi umożliwić generowanie, zarządzanie i korzystanie z wielu kluczy równocześnie. 5. Urządzenie musi obsługiwać algorytmy RSA z kluczami o długościach 1024/2048/4096 bit, funkcje skrótu minimum SHA-1, SHA-256, SHA-512 oraz wsparcie dla generacji kluczy z zastosowaniem algorytmów opartych o krzywe eliptyczne 6. Wydajność urządzeń przy użyciu algorytmu RSA z kluczem 2048 bitów powinna być nie mniejsza niż 50 operacji kryptograficznych na sekundę. 7. Urządzenie musi zostać dostarczone w postaci karty PCI lub PCI-X lub PCI Express montowanej w serwerze lub w postaci urządzenia zewnętrznego montowanego w szafie RACK 19” z interfejsem komunikacyjnym Ethernet 100 lub 1000 Mbps. 8. Możliwość bezpiecznego przeniesienia materiału kryptograficznego na inny moduł HSM (w obrębie tego samego modelu) poprzez odtworzenie klucza głównego zabezpieczonego z użyciem podziału sekretu w schemacie progowym przy użyciu odpowiedniej ilości kart kryptograficznych. 9. Możliwość bezpiecznego usuwania kluczy. 10. Urządzenie musi zostać dostarczone wraz z oprogramowaniem do zarządzania kluczami w ramach modułu HSM oraz wraz z kartami administracyjnymi i operatorskimi niezbędnymi do aktywacji modułu w ilości minimum 16 szt. dla każdego modułu. 6 11. Urządzenie musi zostać dostarczone z interfejsem PKCS#11 w wersji 2.01 lub nowszym. IV. Trzy stanowiska punktów rejestracji (RA) oraz personalizacji kart kryptograficznych: 1. Każdy komputer musi posiadać obudowę Micro Tower ATX. 2. Każdy komputer musi być wyposażony w procesor dwurdzeniowy klasy x86-64, umożliwiający osiągnięcie przez oferowany komputer wydajności w teście Bapco SYSMARK 2007 Preview wyników nie gorszych niż 150 punktów (SYSmark 2007 Preview Rating) na podstawie tabeli opublikowanej pod adresem: http://www.bapco.com/support/fdrs/SYSmark2007web.html 3. Płyta główna każdego z komputerów: musi być kompatybilna z wybranym procesorem, musi obsługiwać pamięć DDR3 do minimum 16GB, musi posiadać 4 gniazda pamięci, musi mieć możliwość pracy w trybie dual channel, musi posiadać 2 wejścia PS/2 oraz 10 x USB 2.0 (cztery na panelu przednim obudowy). 4. W każdym z komputerów musi być zainstalowane 4 GB (2x2 GB) pamięci RAM DDR3, 1333 MHz. 5. Każdy z komputerów musi posiadać dysk twardy o pojemności 320 GB, minimum 7200 RPM, 16MB cache, minimum SATA II. 6. Każdy z komputerów musi posiadać napęd optyczny DVD+/-RW. Minimalne prędkości zapisu: DVD+R 8x, DVD+RW 8x, DVD-R 8x, DVD-RW 6x. Interfejs SATA. 7. Każdy z komputerów musi posiadać kartę sieciową 10/100/1000 Mbps zintegrowaną z płytą główną. 8. W każdym z komputerów musi być karta graficzna zintegrowana z płytą główną, umożliwiająca pracę przy rozdzielczości 1440x900 lub wyższej zgodnej z monitorem, posiadająca złącze DVI-D umożliwiające podłączenie dostarczonego monitora. 9. Każdy z komputerów musi posiadać kartę dźwiękową zintegrowaną z płytą główną. 10. Każdy z komputerów musi mieć zasilacz odpowiedni do zainstalowanych podzespołów. 11. Każdy z monitorów musi mieć przekątną ekranu co najmniej 19”. Każdy z monitorów musi pracować w rozdzielczości nominalnej minimum 1440x900, przy czasie reakcji plamki <=5 ms, brak uszkodzonych (bad pixel, hot pixel) pikseli, złącze DVI-D. 12. Do każdego z komputerów musi być klawiatura podłączana poprzez złącze USB lub PS/2, wyposażona w 104 klawisze QWERTY. 13. Do każdego z komputerów musi być mysz optyczna z rolką podłączana poprzez złącze USB lub PS/2 oraz podkładka. 14. Każdy z komputerów musi mieć zainstalowany system operacyjny Microsoft Windows 7 Professional 32-bit PL. 15. Oprogramowanie dodatkowe: Microsoft Office 2010 Professional PL oraz program typu Internet security (program antywirusowy + firewall + antyspyware) z roczną subskrypcją aktualizacyjną. 16. Każdy z czytników kart kryptograficznych musi: - posiadać złącze USB, - posiadać zgodność z PC/SC, - posiadać zgodność ze standardami ISO 7816, - współpracować z dostarczonym środowiskiem, - posiadać interfejs stykowy, - posiadać sygnalizację optyczną akceptacji karty oraz pracy z kartą, - gwarantować poprawną pracę dla co najmniej 100 000 cykli włożenia/wyjęcia karty, Wykonawca dostarczy oprogramowanie niezbędne do współpracy z dostarczonymi czytnikami. 7 17. Oprogramowanie punktu rejestracji zainstalowane na stanowiskach musi prowadzić rejestr wniosków elektronicznych w tym wniosków PKCS#10, które będą stanowiły podstawę do wydania certyfikatu. W rejestrze muszą być zawarte przynajmniej następujące dane: Data rejestracji wniosku. Osoba która zarejestrowała wniosek. Treść wniosku. Status obsługi wniosku. System musi umożliwić przeglądanie rejestru oraz mechanizmy wyszukiwania rekordów z danymi spełniającymi zadane kryteria. 18. 19. Oprogramowanie punktu rejestracji musi umożliwiać masowe wprowadzenie danych niezbędnych do wydania certyfikatów na podstawie elektronicznych plików wsadu w postaci co najmniej tekstowej. 1) Oprogramowanie punktu rejestracji musi ewidencjonować spersonalizowane z użyciem systemu karty kryptograficzne. W tym celu system musi prowadzić rejestr spersonalizowanych kart który będzie zawierał minimum następujące informacje: Datę rejestracji karty w systemie. Dane osoby która zarejestrowała kartę w systemie. Elektroniczny numer seryjny karty. Producent/model karty. Aktualny status karty (min. spersonalizowana, zagubiona, zniszczona, zablokowana). Aktualny status dystrybucji karty (min. wydana, zwrócona). 2) W ramach rejestru w kontekście każdej zarejestrowanej karty muszą być również rejestrowane informacje o każdej personalizacji karty oraz informacje o tym jakie certyfikaty były wgrywane w ramach poszczególnych personalizacji karty. Informacje te muszą zawierać co najmniej dane takie jak: Data personalizacji karty. Dane osoby która personalizowała kartę w systemie. Status z jakim zakończyła się personalizacji. Certyfikaty które zostały wgrane na kartę. 3) Oprogramowanie RA musi umożliwić przeglądanie bazy rejestracji oraz posiadać mechanizmy wyszukiwania rekordów z danymi spełniającymi zadane kryteria. 20. 1) W ramach personalizacji graficznej karty oprogramowanie musi pozwalać na zdefiniowanie przez operatora podczas eksploatacji systemu szablonów szaty graficznej wizerunku karty (awersu i rewersu karty). W ramach definiowania szablonów szaty graficznej karty być możliwe swobodne wybranie pól jakie będą nadrukowywane na karcie spośród minimum następującego zakresu informacji: Zdjęcie osoby. Imię osoby. Nazwisko osoby. Identyfikator osoby (np. PESEL lub numer służbowy). Organizacja (Np. Gmina). Jednostka organizacyjna (np. wydział lub departament). Data końca ważności certyfikatu (lub jednego wskazanego certyfikatu spośród wielu wgrywanych na kartę). 8 Elektroniczny numer seryjny karty. 2) Definiowanie umiejscowienie wybranych pól informacji na karcie podczas definiowania szablonu powinno być wykonywane przez operatora lub administratora z użyciem narzędzia graficznego dostarczonego wraz z systemem. 21. Wyszukiwanie danych takich jak spersonalizowane dla danego podmiotu/osoby karty czy wygenerowane dla danego podmiotu certyfikaty muszą być możliwe do wglądu w sposób kontekstowy po wyszukaniu rekordu podmiotu/osoby. 22. System musi umożliwiać identyfikację podmiotu/osoby (subskrybenta) certyfikatu/karty na podstawie podanych przez niego losowo wybranych znaków z hasła uwierzytelniającego. Operator punktu RA nie może mieć możliwości zapoznania się z treścią całego hasła. 23. System musi umożliwiać generowanie kodów zabezpieczających (np. PIN) oraz haseł uwierzytelniającego zgodnie z szablonem zdefiniowanym przez operatora RA. 24. Każdy punkt RA musi mieć urządzenie (drukarka) do personalizacji kart mikroprocesorowych które musi: - obsługiwać karty w formacie ID1, - posiadać podajnik na nie mniej niż 100 kart, - umożliwiać dwustronny, kolorowy nadruk na kartach z materiału typu PVC, - umożliwiać wydruk (personalizację graficzną) co najmniej 50 kart na godzinę. - zapewnić elektroniczną (stykową i bezstykowa) personalizację kart (urządzenie musi być wyposażone w oba typy koderów kart) 25. System musi zapewniać możliwość elektronicznej i graficznej personalizacji kart kryptograficznych w trybie automatycznym na podstawie pliku wsadu. 26. Drukarka do etykiet w każdym z punktów RA musi: - umożliwiać wydruk etykiet samoprzylepnych w rozdzielczości 300 x 300 dpi i rozmiarach określonych w p. XII, - posiadać wydajność nie mniejszą niż 100 etykiet samoprzylepnych na godzinę. 27. Drukarka igłowa dla każdego z punktów RA do zabezpieczonych kopert musi umożliwiać wydruk graficzny na zabezpieczonych papierowych kopertach z wydajnością minimum 50 kopert na godzinę. 28. Drukarka laserowa kolorowa o wydajności 10 stron na minutę w formacie A4, posiadająca interfejs sieciowy. 29. Wszystkie trzy stanowiska muszą zapewnić pełną współpracę z oboma urzędami certyfikacji wymienionymi w p. I. Wszystkie dane niezbędne dla urzędów certyfikacji muszą zostać przesłane siecią teleinformatyczną, bez konieczności powtórnego wprowadzania danych już znajdujących się (lub wprowadzonych) na w/w stanowiskach. V. Dwa dokumenty Polityk certyfikacji 1. 2. Dokumenty muszą być przygotowane zgodnie z wytycznymi RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. Wykonawca wytworzy dokumenty Polityk certyfikacji na wzór dostarczonej przez Zamawiającego Polityki, po jednym dla każdego z wdrażanych urzędów tj.: - urząd do generacji kluczy dla urządzeń infrastruktury - urząd do generacji kluczy dla urzędników obsługujących aplikacje lokalne 3. Wykonawca dokona uruchomienia Urzędów Certyfikacji w oparciu o wytworzone Polityki Certyfikacji. 4. Certyfikaty wydane przez urząd generacji kluczy dla urządzeń infrastruktury muszą 9 umożliwiać pełnienie m.in. funkcji: - klient SSL, - serwer SSL, - urządzenia sieciowe VPN, - szyfrowanie danych. 5. Certyfikaty wydane przez urząd generacji kluczy dla urzędników obsługujących aplikacje lokalne muszą pełnić m.in. funkcje: - podpisywanie danych, - uwierzytelnienie użytkownika. VI. Oprogramowanie do zarządzania cyklem życia certyfikatów w oparciu o protokoły Simple Certificate Enrollment Protocol (SCEP) 1. Wykonawca dostarczy oprogramowanie niezbędne do uruchomienia usługi zarządzania cyklem życia certyfikatów w oparciu o protokół SCEP i współpracującego z serwerem SCEP stanowiącym element nowych centrów certyfikacji. 2. Wykonawca dostarczy oprogramowanie klienta SCEP które: 1. musi poprawnie współpracować z kontenerami certyfikatów (serwer aplikacyjny JBoss lub równoważny) w zakresie: a. generacji kluczy kryptograficznych, b. generacji zgłoszeń certyfikacyjnych, c. zasilenia kontenera certyfikatami otrzymanymi z urzędu certyfikacji, d. zapewnienia interfejsu do wprowadzania danych pól certyfikatu e. kontrolowania ważności certyfikatów umieszczonych w kontenerze i w zdefiniowanym czasie przesłać do usługi SCEP żądanie o odnowienie certyfikatu. 2. musi w poprawny sposób współpracować z dostarczoną usługą SCEP w zakresie: a. przesyłania do usługi SCEP zgłoszeń certyfikacyjnych, b. pobierania od usługi SCEP gotowych certyfikatów. c. Zapewniać inicjalną certyfikację uwierzytelnioną hasłem Oprogramowanie klienta SCEP jak również serwera SCEP, musi być dostarczone wraz z licencją nieograniczającą Zamawiającego w kwestii ilości rejestrowanych użytkowników i składanych przez subskrybentów wniosków. 3. VII. Podsystem wykonywania kopii bezpieczeństwa (backupu) 1. 2. Podsystem musi umożliwiać: 1. Wykonywanie kopii bezpieczeństwa zasobów znajdujących się w utworzonych systemach 2. Odtwarzanie danych z kopii bezpieczeństwa. 3. Zapisywania danych na taśmach. Wykonawca dostarczy poniższy sprzęt oraz oprogramowanie do wykonywania backupów: 1. Urządzenie taśmowe w obudowie dostosowanej do montażu w standardowej szafie typu Rack 19”, wysokość obudowy nie może przekroczyć 1U. 2. Urządzenie musi być wyposażone w jeden napęd LTO o pojemności natywnej nie mniejszej niż 400GB, oraz w czytnik kodów paskowych. 3. Urządzenie musi umożliwiać równoczesne umieszczenie minimum 8 nośników taśmowych. 4. Pojemność natywna urządzenia nie może być mniejsza niż 3,2 TB. 5. Urządzenie musi współpracować z taśmami jedno- i wielokrotnego zapisu. 6. Urządzenie musi być wyposażone w interfejs hosta FC, nie mniej niż 8GFC lub SAS, nie mniej niż 6 Gb/s. 10 3. 4. 7. Dostarczone wraz z urządzeniem sterowniki i oprogramowanie do wykonywania kopii zapasowych musi odpowiadać systemom operacyjnym dostarczonym w ramach niniejszego postępowania. 8. Wraz z urządzeniem Wykonawca dostarczy niezbędną ilość taśm wielokrotnego zapisu wynikającą z procedury backupowania, zgodnych z technologią LTO, o pojemności natywnej co najmniej 400GB, jednak nie mniej niż 8 sztuk, oraz jedną taśmę czyszczącą. 9. Wraz z urządzeniem Wykonawca dostarczy oraz skonfiguruje oprogramowanie do wykonywania kopii zapasowych. Wraz z urządzeniem Wykonawca dostarczy kontroler hosta FC, nie mniej niż 8GFC lub SAS, nie mniej niż 6 Gb/s oraz okablowanie o odpowiedniej długości i zainstaluje w jednym z dostarczonych serwerów. Wykonawca dostarczy oprogramowanie umożliwiające wykonywanie backupów na urządzeniu taśmowym opisanym w p. 2, wraz z obsługą zmieniarki i czytnika kodów paskowych. Oprogramowanie musi umożliwiać wykonywanie backupu serwera, do którego będzie podłączone urządzenie taśmowe, oraz wykonywanie backupu poprzez sieć LAN pozostałych serwerów dostarczonych w ramach niniejszego postępowania. Wykonawca przygotuje i przedstawi do zaakceptowania Zamawiającemu niezbędne procedury i instrukcje do wykonywania backupów. VIII. Moduł serwera czasu 1 2 Wykonawca dostarczy moduł serwera czasu który musi: 1. Synchronizować czas UTC dla dostarczanego systemu. 2. Pracować w oparciu o protokoły NTP oraz SNTP. 3. Dla synchronizacji czasu wykorzystywać (poprzez połączenie satelitarne) sygnał z satelitów systemu GPS. 4. Posiadać oscylator OCXO. 5. Mieć możliwość montażu w szafie typu Rack 19”. Wykonawca w miejscu (konkretnie: w obiekcie w którym eksploatowane jest Centrum) wskazanym przez Zamawiającego zainstaluje antenę GPS, którą następnie połączy i skonfiguruje z serwerem czasu. IX. Instruktaż 1. Wykonawca udzieli instruktażu dla 7 osób wskazanych przez Zamawiającego z zakresu: - obsługi dostarczonego oprogramowania, - obsługi dostarczonych urządzeń, - obsługi mechanizmów zarządzania cyklem życia certyfikatów. X. Sejf 1. Sejf musi umożliwiać przechowywanie nośników optycznych i magnetycznych. 2. Sejf musi posiadać odporność na włamanie klasy I, zgodnie z normą PN EN 1143-1. 3. 4. Sejf musi posiadać ognioodporność gwarantującą bezpieczeństwo zawartości przez co najmniej 60 minut. Sejf musi posiadać 2 zamki: elektroniczny oraz kluczowy. 5. Sejf musi posiadać pojemność nie mniejszą niż 160 litrów. 6. Sejf musi być dostarczony wraz z co najmniej jedną półką stałą. 7. S Sejf musi posiadać trzy zamykane na klucz szuflady. 11 XI. Szafa Rack 1. Wykonawca zobowiązany jest do dostarczenia szafy Rack 19˝ o następujących parametrach: - wysokość 42U - szerokość 600 mm - głębokość 1000 mm - drzwi przednie muszą posiadać perforację drobną, zamykane na klucz - drzwi tylne muszą posiadać perforację drobną, skrócone + 2 maskownice 3U - osłony boczne muszą być pełne - dach musi posiadać otwory na zaślepkę - podstawa musi posiadać cokół o wysokości 100 mm - przednia ściana cokołu musi mieć wysuwaną ramę wsporczą - tylna ściana cokołu musi posiadać perforację - lewa i prawa ściana musi być z przepustem szczotkowym - w szafie muszą być zamontowane dwie pary belek nośnych 19˝ oraz jedna para belek nośnych środkowych - w panelu wentylacyjnym muszą być zamontowane 4 wentylatory - w szafie muszą być zamontowane 2 półki stałe z elementami mocującymi do montażu na belkach nośnych, o głębokości 650 mm - szafa musi być w kolorze czarnym - w szafie muszą być zamontowane dwie listwy zasilające wszystkie urządzenia, pozwalające na podłączenie do sieci energetycznej XII. Materiały eksploatacyjne 1. 2. 3. 4. 5. Wykonawca dostarczy materiały eksploatacyjne dla drukarek w ilości niezbędnej do spersonalizowania 25000 kart mikroprocesorowych w technologii kolorowej przy założeniu, że nadruk będzie następował na jednej stronie karty. Wykonawca dostarczy zabezpieczone koperty do wydruku kodów PIN w ilości 25000 sztuk Wykonawca dostarczy naklejki pozwalające na wydruk 50000 białych etykiet o wielkości nie mniejszej niż 70mm x 35mm i nie większej niż 100mm x 50 mm Wykonawca dostarczy papier do wydruku dokumentacji, format A4, 80 g/m2 – 50 ryz. Wykonawca dostarczy czyste, zapisywalne płyty DVD w plastikowych, pojedynczych opakowaniach – 40 sztuk. XIII. Gwarancja 1. 2. 3. W przypadkach gdzie nie wyspecyfikowano inaczej, oferent zapewni 36 miesięcy gwarancji na części, robociznę i naprawę w miejscu instalacji. Naprawa zostanie wykonana w ciągu 7 dni roboczych od momentu zgłoszenia przez Zamawiającego. Zgłoszenia o awariach składane będą w dni robocze w godzinach 8-16. Uszkodzone nośniki danych pozostają u Zamawiającego. Oferent zapewni, że w okresie gwarancji Zamawiający będzie miał prawo dostępu do aktualizacji, poprawek i nowych wersji systemu operacyjnego oraz oprogramowania dostarczonego wraz z serwerami. Przed uruchomieniem produkcyjnym urzędów, wykonawca przeprowadzi testy akceptacyjne w zakresie funkcjonalności określonych w Opisie Przedmiotu Zamówienia. XIV. Wymagania dodatkowe 1. 2. Wykonawca w ramach zamówienia dostarczy wszystkie, niewymienione w niniejszym opisie, elementy w tym sprzęt i oprogramowanie (wraz z bezterminowymi licencjami) w ilościach niezbędnych do prawidłowego uruchomienia i eksploatacji w/w systemów. W okresie 6 miesięcy od uruchomienia systemu Wykonawca będzie zobowiązany do dokonania ewentualnych modyfikacji w konfiguracji oprogramowania centrum certyfikacji (CA) oraz punktów rejestracji (RA) w przypadku gdyby zmiany te wynikały ze 12 3. 4. 5. zmiany bądź powstania nowych przepisów prawa w zakresie rozporządzeń do ustawy o dowodach osobistych z dnia 6 sierpnia 2010 (Dz.U. Nr 167, poz. 1131). Wszystkie urządzenia dostarczone w ramach zamówienia (poza stanowiskami punktów rejestracji) muszą być zamontowane w standardowej szafie typu Rack 19” i nie mogą łącznie przekraczać wysokości 30U. Wdrożenie nie może wpłynąć na poziom świadczenia usług dla systemów teleinformatycznych korzystających z usług Centrum Certyfikacji. Architektura systemu musi przewidywać utworzenie centrum zapasowego jak również nie może być sprzeczna z rozwiązaniami architektonicznymi projektu pl.ID (szczegóły dotyczące wykorzystywanych rozwiązań dostępne są pod adresem: http://cpi.mswia.gov.pl/portal/cpi/390/1990/Dokumentacja_techniczna_dot_pr ojektu_plID.html). Wszędzie gdzie to możliwe, dostarczane rozwiązanie musi być zgodne ze standardami i protokołami komunikacyjnymi powszechnie wykorzystywanymi w budowie systemów IT, w szczególności: XML, SOAP, WebServices, JSP, HTTP, HTTPS, XSD, WSDL, JEE, X509, VPN, SCEP, OCSP. XV. Dokumentacja 1. Zamawiający wymaga, aby Wykonawca przygotował, zgodnie z ogólnie akceptowalnymi standardami w dziedzinie dokumentowania, następujące rodzaje dokumentacji: Harmonogram i plan realizacji Umowy Procedury akceptacji i odbioru przedmiotu Umowy Procedurę zarządzania zmianami Plan Testów Akceptacyjnych zawierający: o o o o o o o o Opis dostarczanego oprogramowania. Scenariusze testowe. Terminy testów akceptacyjnych. Kategoryzację błędów i warunki odbioru. Opisy ról oraz odpowiedzialności osób zaangażowanych w przeprowadzenie testów oraz odbiór przedmiotu Umowy. Sposób i terminy naprawy błędów. Opis środowiska testowego. Plany testów systemowych, wydajnościowych i integracyjnych – w zakresie właściwym dla zaawansowania budowy systemu. Raport Wyników Testów zawierający: o o o Informacje o zakresie przeprowadzonych testów. Liczbie i rodzaju błędów. Podsumowanie wyników testów. Plan Instruktażu zawierający co najmniej: o o o Harmonogram Instruktażu. Szczegółową listę zawierającą informacje o zakresie tematycznym poszczególnych spotkań instruktażowych. Informacje o miejscu przeprowadzenia poszczególnych spotkań instruktażowych. Projekt Techniczny uwzględniający: o o o o Opracowanie Opracowanie Opracowanie Opracowanie wysokopoziomowej architektury rozwiązania. niskopoziomowej architektury rozwiązania. wytycznych do budowy ośrodka zapasowego. oszacowania kosztów eksploatacji systemu w ciągu 5 lat. Dokumentację użytkownika: o Instrukcje użytkownika - system musi posiadać pełną dokumentację użytkownika opisującą możliwości konfiguracji aplikacji przez użytkownika oraz dostępnych funkcjonalności. Dotyczy to także opisów 13 interfejsów użytkownika. Instrukcje administratora zawierająca możliwości konfiguracyjne i zarządcze dostarczanego rozwiązania. Dokumentację eksploatacyjną, zawierającą, co najmniej plan utrzymania ciągłości działania oraz procedury: administracyjne, backupu systemu i danych, awaryjne i użytkownika, przy czym każda z procedur powinna zawierać, co najmniej następujące wyszczególnione informacje: o o o o o o o o procedury procedury procedury procedury procedury procedury procedury Procedury związane z administracją i eksploatacją Systemu, o charakterze testowym, działania administratora Systemu, konserwacji podsystemów Systemu, awaryjne, zabezpieczeń (backup’owe), kontroli bezpieczeństwa Systemu (Audyt), ciągłości działania (uwzględniające przełączanie ośrodków). Każda z w/w procedur będzie zawierać minimum następujące informacje: nazwa procedury, rodzaj procedury, data utworzenia i zatwierdzenia oraz wersja procedury, cel i zakres procedury, warunki uruchomienia procedury i oczekiwany oraz możliwy rezultat jej wykonania, o dane osób, które opracowały procedurę, sprawdziły, zaakceptowały i zatwierdziły, o wzór formularza zgłoszenia Awarii (dla procedur awaryjnych), o algorytm działania, jaki należy zastosować, wykonując kolejne czynności, aby osiągnąć postawiony cel, w tym informacja o osobie która powinna wykonać dane czynności. Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji przedsięwzięcia charakteryzowały się wysoką jakością na którą będą miały wpływ takie czynniki jak: o Struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały, podrozdziały i sekcje, w czytelny i zrozumiały sposób. o Zachowanie standardów, a także sposób pisania, rozumianych jako zachowanie spójnej struktury, formy i sposobu pisania dla poszczególnych dokumentów oraz fragmentów tego samego dokumentu o Kompletność dokumentu, rozumiana jako pełne przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia. o Spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu. Zamawiający wymaga, aby cała dokumentacja, o której mowa powyżej, podlegała jego akceptacji, a także, aby została dostarczona w języku polskim, w wersji elektronicznej w formacie Word i/lub PDF (na płycie CD-ROM lub innym równoważnym nośniku danych) i drukowanej, co najmniej w 3 egzemplarzach (dopuszcza się inne formaty zapisu dokumentacji np. diagramy UML lub formaty wektorowe jak DWG,. DXF, należy jednak dołączyć przeglądarkę obsługującą wykorzystane formaty). Dla harmonogramów – format MPP. Kody źródłowe do wytworzonego oprogramowania muszą być opatrzone komentarzami, wyjaśnieniami. W przypadku kodów źródłowych oprogramowania wytworzonego w języku Java, Wykonawca przekaże także dokumentację kodów źródłowych przygotowaną w narzędziu JavaDoc. o o o o o 2. 3. 4. 14
