Wymagania funkcjonalne I niefunkcjonalne



Pobieranie 0.56 Mb.
Strona13/14
Data28.04.2016
Rozmiar0.56 Mb.
1   ...   6   7   8   9   10   11   12   13   14

1.16Podpis elektroniczny

Weryfikacja podpisu elektronicznego


  1. Wykonawca dostarczy niezbędne komponenty technologiczne pozwalające na weryfikację poprawności podpisu elektronicznego i statusu powiązanego z nim certyfikatu klucza publicznego. Wynik weryfikacji powinien pozwalać na dostarczenie wszystkich niezbędnych informacji związanych z wynikiem weryfikacji danego podpisu elektronicznego oraz powiązanego z nim certyfikatu klucza publicznego.

  2. Rozwiązanie musi zapewnić wiarygodną weryfikację poprawności podpisu (-ów) elektronicznego złożonego pod dokumentami elektronicznymi, statusu certyfikatu (-ów) klucza publicznego oraz statusu znacznika (-ów) czasu.

  3. Rozwiązanie musi pozwalać na realizację co najmniej 5 000 000 weryfikacji w ciągu roku.

  4. Rozwiązanie musi zapewnić wiarygodną weryfikację poprawności certyfikatów wszystkich krajowych kwalifikowanych Centrów Certyfikacji, wpisanych do rejestru podmiotów kwalifikowanych, opublikowanym na stronach Narodowego Centrum Certyfikacji (www.nccert.pl), zgodnie ze specyfikacją ETSI TS 101 903 v1.3.2 lub nowszą.

  5. Rozwiązanie musi zapewnić weryfikację formatów certyfikatów niekwalifikowanych zgodnych ze standardem X.509 v3 z wewnętrznego PKI GUS.

  6. Rozwiązanie musi zapewnić możliwość dodania wystawcy (zgodnie z odpowiednimi wymaganiami dla wystawców) w czasie działania systemu.

  7. Rozwiązanie musi zapewnić dostęp do usługi (weryfikację podpisu elektronicznego) dla dokumentów przekazywanych przez najpopularniejsze protokoły komunikacyjne (co najmniej usługi sieciowe WebServices z wykorzystaniem protokołu SOAP, http, https).

  8. Rozwiązanie musi w prosty sposób umożliwić dostarczenie usługi dla usług sieciowych.

  9. Rozwiązanie musi zapewniać pełną automatyzację procesu weryfikacji.

  10. Rozwiązanie musi zapewniać dostęp do usługi za pośrednictwem dedykowanych bibliotek API, przy czym jako API można także rozumieć udostępnienie usług sieciowych (WebServices).

  11. Rozwiązanie musi zapewnić pełną weryfikację zarówno samego podpisu, jak i całej ścieżki certyfikacji certyfikatu.

  12. Rozwiązanie musi zapewnić możliwość odróżnienia certyfikatów kwalifikowanych od pozostałych certyfikatów.

  13. Rozwiązanie musi zapewnić weryfikację podpisu złożonego na platformie ePUAP.

  14. Rozwiązanie musi zapewnić weryfikację po CRL.

  15. Rozwiązanie musi zapewnić weryfikację po OCSP.

  16. Rozwiązanie musi zapewnić weryfikację podpisów złożonych w formie kontrasygnaty.

  17. Rozwiązanie musi zapewnić weryfikację zarówno podpisów elektronicznych w postaci wewnętrznej, jak i zewnętrznej.

  18. Rozwiązanie musi zapewnić możliwość weryfikacji ważności podpisu złożonego przy wykorzystaniu profilu zaufanego za pomocą platformy ePUAP.

  19. Rozwiązanie powinno umożliwić określenie maksymalnej wielkości weryfikowanych plików zarówno za pośrednictwem protokołu SOAP jak i API.

  20. W przypadku, gdyby rozwiązanie nie dawało możliwości parametryzacji wielkości weryfikowanych plików, rozwiązanie powinno umożliwiać zweryfikowanie co najmniej plików o wielkości do 5 MB.



1.16.1Podpisywanie





  1. Rozwiązanie musi zawierać aplet podpisujący, rozumiany jako komponent służący do składania podpisu elektronicznego.

  2. Aplet podpisujący musi umożliwiać podpisanie danych z wykorzystaniem podłączonego do stacji komponentu sprzętowego bezpiecznego urządzenia do składania podpisów elektronicznych (np. karty kryptograficznej) dostarczającego interfejs zgodny ze standardem PKCS#11.

  3. Aplet podpisujący musi pozwalać na realizację co najmniej 2 000 000 podpisów w ciągu roku przy założeniu standardowego pliku o wielkości ok. 100 KB.

  4. Aplet podpisujący musi zapewnić możliwość podpisania dokumentów certyfikatami wszystkich krajowych kwalifikowanych Centrów Certyfikacji, wpisanych do rejestru podmiotów kwalifikowanych, opublikowanym na stronach Narodowego Centrum Certyfikacji (www.nccert.pl), zgodnie ze specyfikacją ETSI TS 101 903 v1.3.2 lub nowszą (po zainstalowaniu na stacji podpisującej sterownika pkcs#11 dostarczonego przez dostawcę komponentu sprzętowego bezpiecznego urządzenia do składania podpisów).

  5. Rozwiązanie musi umożliwić złożenie podpisu za pomocą profilu zaufanego ePUAP.

  6. Aplet podpisujący musi zapewnić podpisanie dokumentów, zarówno w dowolnym formacie binarnym (PDF, XLS, inne) jak i dokumentów XML.

  7. Aplet podpisujący musi zapewnić podpisywanie dokumentów podpisem niekwalifikowanym z certyfikatem zgodnym ze standardem X.509 v3 z wewnętrznego PKI GUS.

  8. Aplet podpisujący poza integracją z procesem podstawowym musi zapewniać dobrze zdefiniowany i opisany interfejs programistyczny, umożliwiający co najmniej zainicjowanie operacji podpisu, wskazanie danych do podpisania i odebranie podpisanych danych. Interfejs ten musi umożliwiać wywołanie go np. poprzez kontrolki z następujących źródeł:

    1. formularze - po wykonaniu czynności podpisania podpisane dane muszą zostać przekazane pod wskazany w ustawieniach adres,

    2. biblioteki dokumentów użytkowanego w jednostkach statystyki MS Sharepoint - po wykonaniu czynności podpisania podpisane dane muszą zostać przekazane pod wskazany w ustawieniach adres,

  1. Aplet podpisujący musi umożliwiać zintegrowanie go z portalem lub aplikacją, w ramach której składane są podpisy elektroniczne pod dokumentami.

  2. Aplet podpisujący musi zapewnić możliwość wybrania z magazynu certyfikatów dowolnego certyfikatu do podpisu z możliwością wyboru kwalifikowany/wszystkie.

  3. Aplet podpisujący musi zapewnić możliwość podejrzenia treści podpisywanego pliku (co najmniej format XML) samodzielnie przez aplikację bądź z wykorzystaniem aplikacji zewnętrznych.

  4. W przypadku podejrzenia pliku z wykorzystaniem aplikacji zewnętrznej rozwiązanie musi zapewnić możliwość wyboru aplikacji wykorzystując mechanizmy wbudowane w system operacyjny.

  5. Rozwiązanie musi zapewnić możliwość oznakowania podpisu znacznikiem czasu z dowolnego źródła spełniającego normę RFC 3161 dla znakowania czasem w tym z wewnętrznego TSA GUS i kwalifikowanych centrów certyfikacji przy zapewnieniu przez Zamawiającego dostępu do kwalifikowanego znacznika czasu.

  6. Rozwiązanie musi zapewnić możliwość konfiguracji ustawień podpisywania przynajmniej w zakresie:

    1. rodzaj XADES (XADES-BES, XADES-T),

    2. podpis w postaci wewnętrznej, zewnętrznej.

  1. Rozwiązanie musi zapewnić parametryzację i skonfigurowanie apletu w celu dostosowania go do wymagań konkretnego systemu co najmniej w następującym zakresie:

    1. wymuszenie certyfikatu kwalifikowanego,

    2. tryb podpisu – zwykły podpis bądź kontrasygnata,

    3. adres serwera znakowania czasem,

    4. generowanie osobnych podpisów dla wszystkich przekazanych danych czy jednego podpisu pod wszystkimi danymi.

  1. Rozwiązanie musi umożliwić wygenerowanie jednego wspólnego podpisu dla wielu danych (podpis wielokrotny), jak również dodanie kontrasygnat pod już istniejącymi podpisami.



1.16.2Budowa wewnętrznego serwera znakowania czasem (TSA)





  1. Rozwiązanie musi umożliwiać zaopatrywanie dokumentów elektronicznych w stempel czasowy.

  2. Rozwiązanie musi zapewnić zgodność z normami RFC 3161, ETSI TS 101 861, ETSI TS 102 023, ETSI TS 101 731.

  3. Rozwiązanie musi zapewnić dostarczenie dowodu na istnienie danych w momencie oznaczania czasem.

  4. Zdarzenie oznaczenia czasem powinno być rejestrowane w bazie danych żądań znakowania czasem.

  5. Rejestracji powinny podlegać przesyłane zapytania i udzielone odpowiedzi.

  6. Rozwiązanie powinno zawierać interfejs służący co najmniej do przeglądania bazy danych żądań znakowania czasem.

  7. Rozwiązanie musi zapewnić synchronizację z wzorcowym serwerem czasu Głównego Urzędu Miar poprzez protokół NTP.

  8. Rozwiązanie musi zapewnić zapasowy wzorzec czasu w przypadku przerw w działaniu serwerów Głównego Urzędu Miar.

  9. Zamawiający dopuszcza instalację na serwerach Zamawiającego sprzętowego wzorca sekundy jako drugiego wzorca czasu.

  10. Rozwiązanie musi zapewnić możliwość synchronizacji z innymi zewnętrznymi wzorcowymi serwerami czasu przez protokół NTP.

  11. Rozwiązanie musi zapewnić obsługę minimum 5 żądań o znacznik czasu na sekundę.

  12. Rozwiązanie musi zapewnić dostęp do znaczników czasu dla elektronicznego archiwum GUS umożliwiając długoterminowe przechowywanie dokumentów podpisanych podpisem elektronicznym w sposób zapewniający zabezpieczenie ich wartości dowodowej.



1.16.3Sprzętowy Moduł Kryptograficzny (Hardware Security Module)





  1. Rozwiązanie musi zapewnić możliwość przechowywania klucza prywatnego Centrum Certyfikacji (CA) w urządzeniu HSM.

  2. HSM musi być zgodny z standardem co najmniej FIPS 140-2 poziom 3.

  3. HSM musi zapewnić możliwość podpisania (rozumianego jako złożenie podpisu pod przesłanymi danymi) Urzędowego Potwierdzenia Odbioru (UPO) dla dokumentów przyjmowanych ze źródeł zewnętrznych w tym Elektronicznej Skrzynki Podawczej GUS.

  4. Rozwiązanie musi umożliwiać nawiązywanie połączeń z HSM przez sieć opartą na protokole TCP/IP z co najmniej 3 korzystających z niego urządzeń.

  5. HSM musi potrafić wykonać co najmniej 60 operacji RSA z wykorzystaniem kluczy o długości 4096 bit na sekundę.

  6. HSM musi zapewnić ochronę przed nieupoważnionym dostępem i powinien znajdować się w bezpiecznej obudowie odpornej na nieuprawnioną ingerencję zewnętrzną.

  7. HSM musi zapewniać możliwość ochrony klucza prywatnego RSA o długości 2048–bitów i powyżej.

  8. HSM musi poprawnie współpracować co najmniej z następującymi systemami operacyjnymi:

    1. MS Windows Serwer 2003R2 w środowisku co najmniej 32-bitowym,

    2. MS Windows Server 2008R2 w środowisku 32-bitowym i 64-bitowym,

    3. Linux.

  1. HSM musi obsługiwać co najmniej następujące API:

  1. PKCS#11,

  2. CSP for Microsoft CryptoAPI,

  3. OpenSSL,

  4. CNG (Cryptography Next Generation).

  1. HSM musi obsługiwać następujące algorytmy:

    1. symetryczne: AES, DES, 3DES,

    2. asymetryczne: DSA, El Gamal, RSA,

    3. wymiany kluczy: Diffie-Hellman,

    4. hash: MD5, SHA-1, SHA-2.

  1. HSM musi zapewniać w przyszłości możliwość pracy w układach wysokiej dostępności (ang. High Availability) umożliwiających pełną redundantność i rozkładanie obciążenia.

  2. HSM musi zapewniać możliwość obsługi wielu serwerów, w tym również zbudowanych w oparciu o maszyny wirtualne, przez jeden moduł HSM.

  3. HSM musi zapewniać możliwość obsługi wielu aplikacji przez jeden moduł HSM.

  4. HSM musi zapewniać możliwość równoległej obsługi, przez jeden moduł HSM, wielu kompletów kluczy.

  5. HSM nie powinien mieć ograniczeń na liczbę chronionych przez moduł kluczy.

  6. HSM powinien zapewniać możliwość wykonywania kopii zapasowych kluczy prywatnych chronionych przez HSM.


1   ...   6   7   8   9   10   11   12   13   14


©absta.pl 2016
wyślij wiadomość

    Strona główna