OPIS PRZEDMIOTU ZAMÓWIENIA W PRZETARGU NA

ZP/UR/10/2013 Załącznik nr 3 do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA W PRZETARGU NA Wdrożenie, dostosowanie i obsługa techniczna zintegrowanego systemu zarządzania uczelnią wraz z przeszkoleniem użytkowników Przedmiotem zamówienia jest: Wdrożenie, dostosowanie i obsługa techniczna zintegrowanego systemu zarządzania uczelnią wraz z przeszkoleniem użytkowników System będzie przeznaczony do obsługi uczelni, której społeczność liczy obecnie ponad 21000 studentów, 1500 pracowników kadry naukowo-dydaktycznej i pracowników administracji. Na przedmiot zamówienia składać się będą następujące czynności: W ramach rozbudowy systemu kartowego uwierzytelnienia i autoryzacji działającego w oparciu o karty elektroniczne: - modernizacja centrum przetwarzania danych w zakresie niezbędnym dla uruchomienia systemu uwierzytelnienia i autoryzacji; - wdrożenie oprogramowania i przeszkolenie administratorów oraz dostawa, instalacja i konfiguracja dostarczonego sprzętu; - wdrożenie, konfiguracja i uruchomienie oprogramowania oraz dostawa sprzętu składającego się na system Elektronicznej Karty Pracowniczej moduł PKI; - wydanie nowych Elektronicznych Kart Pracowniczych EKP oraz Elektronicznych Legitymacji Studenckich/Doktoranckich (ELS/ELD) z wgraną strukturą PKI; - stworzenie infrastruktury klucza publicznego (PKI) opartej na zmodernizowanym centrum przetwarzania danych, istniejącym systemie Elektronicznej Karty Pracowniczej, systemie Elektronicznej Legitymacji Studenckiej oraz doktoranckiej, w której nośnikiem certyfikatów będą Elektroniczna Karta Pracownicza (EKP) oraz Elektroniczna Legitymacja Studencka/Doktorancka (ELS/ELD); - wdrożenie, konfiguracja i uruchomienie oprogramowania umożliwiającego przeglądanie zasobów przynależnych do pracownika lub studenta, wypełnianie formularzy, zmianę PIN-ów na kartach oraz zapisywanie na nich certyfikatów cyfrowych; - wdrożenie, rozbudowa, konfiguracja i uruchomienie oprogramowania oraz dostawa sprzętu składającego się na system do wypożyczeń kluczy/sprzętu; - wdrożenie, konfiguracja i uruchomienie oprogramowania oraz dostawa sprzętu składającego się na system kontroli dostępu do pomieszczeń; - dostarczenie dokumentacji systemu (użytkownika, administratora, itp.); - opieka serwisowa w okresie 24 miesięcy od dnia zakończenia wdrożenia. W ramach wdrożenia systemu obiegu dokumentów: - wdrożenie oprogramowania wraz z udzieleniem licencji niewyłącznych na czas nieoznaczony na oprogramowanie wchodzące w skład systemu; - wykonanie analizy przedwdrożeniowej wraz z opracowaniem stosownej pisemnej dokumentacji; - stworzenie diagramów i przepływu dokumentów (m.in. umowy) z założeniami określonymi w analizie przedwdrożeniowej; - wdrożenie wraz z przeszkoleniem użytkowników oraz administratorów wskazanych przez Zamawiającego; - dostarczenie dokumentacji systemu (użytkownika, administratora, itp.); - opieka serwisowa w okresie 24 miesięcy od dnia zakończenia wdrożenia. W ramach wdrożenia systemu zarządzania majątkiem trwałym: - wdrożenie oprogramowania wraz z udzieleniem licencji niewyłącznych na czas nieoznaczony na oprogramowanie wchodzące w skład systemu; Strona 1 z 92

- wykonanie analizy przedwdrożeniowej wraz z opracowaniem stosownej pisemnej dokumentacji; - wdrożenie wraz z przeszkoleniem użytkowników oraz administratorów wskazanych przez Zamawiającego; - dostarczenie dokumentacji systemu (użytkownika, administratora, itp.); - opieka serwisowa w okresie 24 miesięcy od dnia zakończenia wdrożenia. W ramach wdrożenia systemu obsługi Działu Zamówień Publicznych oraz Biura Karier: - wdrożenie oprogramowania wraz z udzieleniem licencji niewyłącznych na czas nieoznaczony na oprogramowanie wchodzące w skład systemu; - wdrożenie wraz z przeszkoleniem użytkowników oraz administratorów wskazanych przez Zamawiającego; - dostarczenie dokumentacji systemu (użytkownika, administratora, itp.); - opieka serwisowa w okresie 24 miesięcy od dnia zakończenia wdrożenia. W ramach wdrożenia systemu do obsługi procesu dydaktycznego: - wdrożenie oprogramowania wraz z udzieleniem licencji niewyłącznych na czas nieoznaczony na oprogramowanie wchodzące w skład systemu; - wykonanie analizy przedwdrożeniowej wraz z opracowaniem stosownej pisemnej dokumentacji; - import danych do nowego systemu z obecnie użytkowanych systemów zgodnie z założeniami określonymi wbanalizie przedwdrożeniowej; - modyfikacja i przystosowanie dostarczonych programów do potrzeb Zamawiającego zgodnie z dokumentacją sporządzoną w fazie analizy przedwdrożeniowej; - wdrożenie z zapewnieniem nadzoru autorskiego; - przeszkolenie użytkowników oraz administratorów wskazanych przez Zamawiającego; - dostarczenie dokumentacji systemu (użytkownika, administratora, itp.); - opieka serwisowa w okresie 24 miesięcy od dnia zakończenia wdrożenia. System musi posiadać architekturę modularną, w obrębie której zastosowany musi zostać podział na grupy modułów funkcjonalnych odzwierciedlający główne procesy operacyjne. Gwarancja min. 24 miesiące na całość przedmiotu zamówienia. Strona 2 z 92

ROZBUDOWA SYSTEMU KARTOWEGO SYSTEM PKI Aby wdrożyć System uwierzytelniania i autoryzacji w oparciu o infrastrukturę klucza publicznego (PKI) należy wykonać następujące zadania: 1. przeprowadzić modernizację centrum przetwarzania danych w zakresie niezbędnym dla uruchomienia systemu uwierzytelnienia i autoryzacji, polegającą na dostawie, instalacji i konfiguracji sprzętu i oprogramowania podstawowego oraz dostawie, konfiguracji i uruchomieniu oprogramowania i sprzętu składającego się na system SELS; 2. stworzyć uczelnianą infrastrukturę klucza publicznego (PKI) opartą na systemie SELS, w której nośnikiem certyfikatów będą Elektroniczna Karta Pracownicza (EKP) oraz Elektroniczna Legitymacja Studencka (ELS) oraz Elektroniczna Legitymacja Doktoranta (ELD); 3. dostarczyć, skonfigurować i uruchomić oprogramowanie zarządzające pozwalające na: przeglądanie za pomocą interfejsu webowego zasobów udostępnionych pracownikowi lub studentowi, wypełnianie formularzy, wykonywanie zmiany PIN-ów na kartach, wykonywanie zmianę haseł, zapisywanie na kartach certyfikatów cyfrowych. 4. przeprowadzić Integrację infrastruktury PKI z funkcjonującym u Zamawiającego systemami: do personalizacji ELS, ELD i EKP (SELS), Bezobsługowym Centrum Wydruku (BCW), Systemem obsługi infokiosków (SKI) 5. przeszkolić administratorów Uczelni, dostarczyć dokumentację Systemu PKI (użytkownika, administratora, itp.), oraz dostarczyć nośniki instalacyjne systemu. Niezbędne elementy potrzebne do zbudowania Systemu PKI (wymagania techniczne podano w dalszej części załącznika): 1. serwer CA; 2. karty elektroniczne z przeznaczeniem na EKP; 3. czytniki kart stykowych z podstawkami biurkowymi; 4. drukarka igłowa do zadruku kopert z numerami PIN; 5. koperty utajnione; 6. licencje na oprogramowanie typu middleware umożliwiające komunikację systemu operacyjnego z kartą ELS, ELD i EKP do instalacji na komputerach w Uczelni; 7. oprogramowanie umożliwiające zarządzanie Elektroniczną Kartą Pracowniczą (EKP), Elektroniczną Legitymacją Studencką (ELS) i Elektroniczną Legitymacją Doktoranta (ELD) w infrastrukturze klucza publicznego (PKI) (generowanie kluczy i żądań o certyfikat wynikający z przynależności do danej grupy, zapisywanie certyfikatów, zmiana PIN-u, dodanie przyjaznej nazwy użytkownika, zmiana hasła, zapisanie zestawu certyfikatów na kartę); 8. oprogramowanie umożliwiające użytkownikom samodzielną zmianę hasła lub PIN poprzez stronę WWW. Opieka serwisowa Systemu PKI Zamawiający wymaga, aby Wykonawca objął dostarczony System 24 miesięczną opieką serwisową. W ramach opieki serwisowej Zamawiający wymaga darmowego dostarczania aktualizacji oprogramowania będących wynikiem zmian przepisów prawa. Minimalny zestaw wymagań względem usług wykonywanych w ramach opieki serwisowej: 1. Usuwanie błędu krytycznego w nie dłużej niż 1 dzień roboczy od momentu zgłoszenia; 2. Usuwanie błędu zwykłego w nie dłużej niż 3 dni robocze od momentu zgłoszenia; 3. Usunięcia usterki w nie dłużej niż 10 dni roboczych od momentu zgłoszenia. Zamawiający przewiduje możliwość zdalnego dostępu do bazy i aplikacji produkcyjnej Systemu po zapewnieniu wymaganego poziomu bezpieczeństwa danych. Zamawiający wymaga bieżących modyfikacji i uaktualnień Systemu wynikających ze zmiany przepisów prawnych. Ponadto Wykonawca zobowiązuje się do rozszerzenia programu (na podstawie Strona 3 z 92

odrębnych zleceń) o nowe funkcjonalności wymagane przez Zamawiającego. Zgłoszenia dotyczące modyfikacji muszą być zrealizowane w uzasadnionym czasie. Wymagania niefunkcjonalne Systemu PKI 1. System PKI powinien posiadać możliwość bezpiecznej komunikacji z Systemem OPTIcamp firmy OPTeam S.A. funkcjonującym u Zamawiającego w Centrum Personalizacji Elektronicznych Legitymacji Studenckich. W szczególności muszą być wykorzystane istniejące bazy danych; 2. System PKI musi być skalowalny i posiadać możliwość rozbudowy (poszerzenia funkcjonalności o nowe moduły); Wymagana funkcjonalne Systemu PKI Wymagania ogólne 1. System PKI musi posiadać interfejs w języku polskim; 2. System PKI musi działać z wykorzystaniem relacyjnej, transakcyjnej bazy danych SQL spełniającej wymagania określone w dalszej części dokumentu; 3. System PKI powinien umożliwiać stosowanie podpisów elektronicznych dla wysyłanych danych cyfrowych i ich autoryzację; 4. System PKI musi być skalowalny i posiadać możliwość rozbudowy (poszerzenia funkcjonalności o nowe moduły, zwiększenia liczby stanowisk); 5. System PKI musi umożliwiać import danych studentów, pracowników z istniejących baz danych; 6. System PKI musi posiadać możliwość przechowywania i udostępniania informacji o charakterze graficznym (np. zdjęcia) a nie tylko o charakterze tekstowym; 7. System PKI musi pracować w środowisku graficznym na komputerach klienckich wyposażonych w system operacyjny MS Windows XP Professional/Vista Business/Windows 7 Professional; 8. System PKI musi być wyposażony w mechanizmy zabezpieczające przed nieautoryzowanym dostępem; 9. System PKI musi umożliwiać definiowanie i zarządzanie prawami użytkowników; 10. System PKI musi być zintegrowany z Active Directory/LDAP (automatyczne zakładanie kont studentów, pracowników, w AD w trakcie personalizacji określonego rodzaju kart, przenoszenie danych z Active Directory do systemu PKI oraz z PKI do Acticve Directory). Zakres przenoszonych danych powinien być konfigurowalny. Wymagania w zakresie bezpieczeństwa danych Bezpieczeństwo Systemu PKI musi być oparte na tajności kluczy kryptograficznych, PIN-ów i haseł nie zaś na okryciu tajemnicą metod i nazw algorytmów i funkcji bezpieczeństwa. Budowa Systemu PKI powinna przebiegać etapami, zgodnie z tabelą poniżej: Etap Zadanie Termin realizacji 1 Dostawa licencji Do 10 dni od daty zawarcia umowy Dostawa, instalacja sprzętu komputerowego i oprogramowania 2 Zgodnie z podstawowego dla Systemu PKI. harmonogramem Stworzenie infrastruktury klucza publicznego (PKI) opartej na 3 ustalonym z zmodernizowanym centrum przetwarzania danych Wykonawcą, nie Dostawa, konfiguracja i uruchomienie oprogramowania później niż do 30 4 umożliwiającego pracę EKP i ELS/ELD w infrastrukturze PKI oraz listopada 2014 r. szkolenie użytkowników Zakres zadań dla poszczególnych etapów ETAP 1 Dostawa licencji: Strona 4 z 92

a) Licencja PKI Administracja (Centrum PKI) minimum 2 licencje (umożliwia odblokowanie apletu PKI oraz tworzenie i nagrywanie certyfikatów na karty podczas personalizacji ELS/ELD/EKP) b) Licencja PKI dla obsługi Elektroniczna Karta Pracownicza (PKI EKP) minimum 35 licencji na stację roboczą (moduł zarządzający umożliwiający obsługę i przedłużanie ważności karty pracowniczej i certyfikatów zapisanych na karcie) c) Licencja PKI dla Elektroniczna Legitymacja Studencka/Doktoranta minimum 35 licencji na stację roboczą (umożliwia odblokowanie apletu PKI oraz tworzenie i nagrywanie certyfikatów na karty już wydane użytkownikom) d) Licencja PKI dla obsługi kiosków minimum 37 licencji (umożliwia odblokowanie apletu PKI oraz tworzenie/przedłużanie i nagrywanie certyfikatów na karty już wydane użytkownikom) Termin realizacji: 10 dni od daty podpisania umowy. ETAP 2 Dostawa, instalacja sprzętu komputerowego (wraz z oprogramowaniem) i oprogramowania podstawowego dla Systemu PKI. Termin realizacji: Zgodnie z harmonogramem ustalonym z Wykonawcą, nie później do 30 listopada 2014 r. Wymagania względem dostarczanego sprzętu: 1. Urządzenia muszą być fabrycznie nowe; 2. Urządzenia i ich komponenty muszą być oznakowane przez producentów w taki sposób, aby możliwa była identyfikacja zarówno produktu jak i producenta; 3. Wszystkie serwery muszą posiadać Certyfikat B lub CE albo spełniać normy równoważne; 4. Oferowane serwery muszą być przygotowane do współpracy z systemami operacyjnymi takimi jak: Microsoft Windows Server, LINUX Red Hat oraz z systemem VMware; 5. Wszystkie urządzenia muszą współpracować z siecią energetyczną o parametrach: 230 V ± 10%, 50Hz. Zamawiający zapewnia podłączenie dostarczonego sprzętu do istniejącej sieci LAN Uczelni. PKI Lp. Specyfikacja 1. Serwer CA wymagania minimalne Typ obudowy serwera: Rack (2U); Ilość zainstalowanych procesorów: 1 szt.; Maksymalna ilość procesorów: 2 szt.; Częstotliwość procesora: 2,3 GHz; Częstotliwość szyny QPI/DMI: 7,2 GT/s; Pojemność pamięci cache [L3]: 15 MB; Ilość zainstalowanych dysków: 2 szt - Dysk twardy 300GB 6G SAS 10K 2.5in; Maksymalna ilość dysków: 8 szt.; Pojemność zainstalowanych dysków: 600 GB; Pojemność zainstalowanej pamięci: 16384 MB; Maksymalna pojemność pamięci: 786432 MB; Rodzaj zainstalowanej pamięci: DDR3; Typ pamięci: Registered; Częstotliwość szyny pamięci: 1333 MHz; Ilość banków pamięci: 24 szt.; Ilość wolnych banków pamięci: 20 szt.; Ilość slotów PCI-E 16x: 1 szt.; Ilość slotów PCI-E 8x: 2 szt.; Dodatkowe informacje n/t slotów PCI: 1 x slot PCI-E 16x (standard), 1 x slot PCI-E 8x (standard), 1 x slot PCI-E 8x (standard) [8x mechanicznie, 4x elektrycznie]; Typ Ilość (szt.) 1 Strona 5 z 92

karty graficznej: Matrox G200; Karta sieciowa: 10/100/1000 Mbit/s; Ilość wolnych kieszeni 2,5 (zewnętrznych): 8 szt.; Interfejsy: 2 x 15-stykowe D-Sub (wyjście na monitor), 6 x USB 2.0, 4 x RJ-45 (LAN), 1 x Serial; Ilość zasilaczy: 1 szt.; Moc zasilacza (zasilaczy): 460 Wat; Wykonawca dostarczy niezbędne licencje bazodanowe oraz systemowe potrzebne do wdrożenia poszczególnych modułów (np. SQL Server, Windows Server itp.) wraz z nośnikami instalacyjnymi. 2. Czytnik elektronicznych kart stykowych standardu PC/SC z podstawką biurkową - zgodność ze standardem PC/SC - zgodność z normami ISO7816 Class A, B i C (5V, 3V, 1.8V) - obsługa kart procesorowych zgodnych z ISO 7816-1,2,3,4 - obsługa protokołów T=0 i T=1 - wytrzymałość, co najmniej 100 000 włożeń kart - zgodność ze standardami elektromagnetycznymi: Europe: 89/336/CEE guideline, EN 55022: 1994 Class B, EN 50082-1: 1994, EN 50081-1: 1992, EN 61000-4-2: 1995, EN 61000-4-3: 1997, EN 61000-4-4: 1995 - zgodność z normą bezpieczeństwa EN60950 - standardy i certyfikaty: ISO/IEC 7816-1,2,3,4, EMV poziom 1, EMV96 wersja 3.1.1, Microsoft Windows Hardware Quality Labs (WHQL), USB 2.0 full speed (w trybie USB), CCID - Chip card Interface device 1.0 (w trybie USB) - obsługa w systemach operacyjnych: MS Windows 95 OSR2, 98, 98SE, ME, NT, 2000, XP,Vista,7, 8. 3. Karty procesorowe wykorzystywane jako Elektroniczne Karty Pracownicze Karta jest hybrydową elektroniczną kartą procesorową z dwoma interfejsami: 1. stykowym określonym w normach ISO/IEC 7816-2 i ISO/IEC 7816-3 o pojemności pamięci EEPROM co najmniej 67 kilobajtów 2. bezstykowym określonym w normie ISO/IEC 14443 typ A, zgodnym ze standardem przemysłowym MIFARE dla protokołu klasycznego o pojemności pamięci 1 kilobajt (MIFARE Stadnard Card IC MF1 IC S50 Functional Specification). Karty wykonane są z materiału nieulegającemu odkształceniu i / lub rozwarstwieniu. 200 Wygląd karty Karta biała umożliwiająca personalizację graficzną kart na dowolnej drukarce termo lub re transferowej. Projekt graficzny karty zostanie zrobiony przez Zamawiającego. Część elektroniczna stykowa Część stykowa karty jest wyposażona w interfejs określony w normach ISO/IEC 7816-2 i ISO/IEC 7816-3. Polecenia i odpowiedzi przesyłane podczas komunikacji Karty z infrastrukturą informatyczną powinny mieć strukturę zgodną z APDU określoną w normie ISO/IEC 7816-4. Polecenia realizowane przez Kartę dla operacji kryptograficznych i zarządzania są zgodne z ISO/IEC 7816-8, ISO/IEC 7816-9 oraz opcjonalnie ISO/IEC 7816-15. Karta może być stosowany jako komponent techniczny urządzenia do składania podpisu elektronicznego (ustawa z dnia 18 września 2001 r. o podpisie elektronicznym Dz. U. 2001 nr 130 poz. 1450). 1200 Karta musi spełniać następujące wymagania: 1. Układ elektroniczny o pojemności pamięci EEPROM co najmniej 67 kilobajtów z wbudowanym koprocesorem kryptograficznym. 2. Układ elektroniczny blankietu EKP musi posiadać certyfikat Common Criteria Standard na poziomie co najmniej EAL4+. Strona 6 z 92

3. Card Management i API zgodne z Global Platform 2.1.1 4. System operacyjny Java Card Virtual Machine, RTE i API zgodne z JC2.2.1 5. Blankiet EKP musi posiadać certyfikat Common Criteria Standard według profilu PPSSCD Protection Profile Secure Signature Creation Device Type 2 and/or 3, version 1.05, EAL4+ (CWA14169). 6. Zgodny ze standardem funkcjonalności E-Sign K (CWA14890). 7. DAP zgodne z Global Platform 2.1 (PK-Based). 8. Obsługiwane protokoły: T=0, T=1, PPS. 9. Prędkość transmisji czytnik karta co najmniej 230 Kbauds. 10. Dostęp do klucza prywatnego zapisanego na Karcie możliwy jest wyłącznie przez koprocesor kryptograficzny Karty. 11. Wszystkie operacje kryptograficzne dotyczące klucza prywatnego wykonywane na karcie. 12. Użycie klucza prywatnego tylko po podaniu kodu PIN użytkownika. 13. Generowanie kluczy kryptograficznych o długości do 2048 bitów przeznaczonych do użycia przez algorytm RSA, podpisywanie za pomocą algorytmu RSA, obsługa funkcji skrótu SHA-1, SHA-256, obsługa algorytmów DES, 3DES (ECB, CBC), AES. 14. Karta przystosowana do umieszczenia na niej certyfikatu kwalifikowanego wraz z kluczami kryptograficznymi oraz certyfikatu niekwalifikowanego wraz z kluczami kryptograficznymi; certyfikaty mogą zostać umieszczone w późniejszym czasie. Część elektroniczna bezstykowa Część bezstykowa jest wyposażona w interfejs zgodny z ISO/IEC 14443 typ A. Sposób komunikacji karty jest zgodny ze standardem przemysłowym MIFARE dla protokołu klasycznego spełniającym wymagania normy ISO/IEC 14443-1, ISO/IEC 14443-2, ISO/IEC 14443-3 oraz opcjonalnie ISO/IEC 14443-4 (protokół T=CL), przy zachowaniu pełnej antykolizyjności. Zabezpieczenia na czas dostawy Dostęp do układów elektronicznych karty jest zabezpieczany na czas dostawy specjalnymi kluczami transportowymi dla części bezstykowej (MIFARE ) i stykowej. ETAP 3 Stworzenie infrastruktury klucza publicznego (PKI) opartej na zmodernizowanym centrum przetwarzania danych gdzie nośnikiem certyfikatów będzie Elektroniczna Karta Pracownicza i Elektroniczna Legitymacja Studencka. Termin realizacji: Zgodnie z harmonogramem ustalonym z Wykonawcą, nie później niż do 30 listopada 2014 r. Specyfikacja sprzętu i oprogramowania PKI System do obsługi infrastruktury klucza publicznego (PKI) składa się z: 1. Systemu Informatycznego PKI wyspecyfikowanego w podpunktach I i II oraz licencje: a) Licencja PKI Administracja (Centrum PKI) minimum 2 licencje (umożliwia odblokowanie apletu PKI oraz tworzenie i nagrywanie certyfikatów na karty podczas personalizacji ELS/ELD/EKP) b) Licencja PKI dla obsługi Elektroniczna Karta Pracownicza (PKI EKP) minimum 35 licencji na stację roboczą (moduł zarządzający umożliwiający obsługę i przedłużanie ważności karty pracowniczej i certyfikatów zapisanych na karcie) Strona 7 z 92

c) Licencja PKI dla Elektroniczna Legitymacja Studencka/Doktoranta minimum 35 licencji na stację roboczą (umożliwia odblokowanie apletu PKI oraz tworzenie i nagrywanie certyfikatów na karty już wydane użytkownikom) d) Licencja PKI dla obsługi kiosków minimum 35 licencji (umożliwia odblokowanie apletu PKI oraz tworzenie/przedłużanie i nagrywanie certyfikatów na karty już wydane użytkownikom) 2. Oprogramowania middleware (licencja dla minimum 22.000 studentów i 1.500 pracowników Zamawiającego) o funkcjonalności opisanej poniżej; 3. Dwóch drukarek igłowych umożliwiających poufny wydruk PIN-ów, specyfikacja drukarki opisana w podpunkcie III poniżej; 4. Kopert utajnionych 27.000 szt., specyfikacja kopert w podpunkcie IV; 5. Licencji MS Windows Server wyspecyfikowanych w tabeli zawartej w opisie Etapu 2; 6. Czytników kart stykowych z podstawkami biurkowymi, wyspecyfikowanych w tabeli zawartej w opisie Etapu 1; 7. Blankietów EKP, wyspecyfikowanych w tabeli zawartej w opisie Etapu 2. Wykonawca będzie utrzymywał PKI w zakresie odebranych części, do upływu 2 lat liczonych od daty startu produktywnego PKI. Celem utrzymania PKI jest zapewnienie pierwotnie określonej jego funkcjonalności oraz uzyskanie nowych funkcjonalności niezbędnych z uwagi na cel Zamówienia, a także funkcjonalności podnoszących użyteczność PKI. I. Active Directory (lub serwer LDAP) 1. Pozycje katalogu opisujące użytkowników muszą zawierać atrybut umożliwiający rozróżnienie grupy użytkowników (co najmniej podział: pracownik/student/doktorant/inny); 2. W obrębie każdej grupy użytkowników konieczne jest dodatkowe rozróżnienie (jednostka organizacyjna w przypadku pracowników, wydział w przypadku studentów, kategoria w przypadku inny); 3. Czynności administracyjne dotyczące zarządzania AD lub LDAP: - możliwość zmiany schematu bazy AD/LDAP poprzez dodawanie atrybutów; - edycja konta użytkownika; - import bazy studentów; - import bazy pracowników; - usunięcie konta; - grupowe usunięcie wybranych kont; - zablokowanie konta; - zmiana hasła; - zablokowanie możliwości logowania z wykorzystaniem AD/LDAP; - czasowe zablokowanie certyfikatu (z aktualizacją listy CRL); - odblokowanie certyfikatu (z aktualizacją listy CRL); - całkowite unieważnienie certyfikatu (z aktualizacją listy CRL). II. Oprogramowanie PKI 1. Oprogramowanie PKI musi umożliwić wystawienie i wgranie certyfikatu. 2. Oprogramowanie PKI musi umożliwić definiowanie celów dla wystawianych certyfikatów (np. logowanie, podpis). 3. Oprogramowanie PKI musi umożliwiać unieważnianie certyfikatów oraz musi publikować listy CRL (listy certyfikatów unieważnionych), a także wspierać protokół OCSP (Online Certificate Status Protocol). 4. Powinno być możliwe zarówno tymczasowe i jak i całkowite unieważnienie certyfikatu. 5. Oprogramowanie PKI powinno umożliwiać administratorowi indywidualne utworzenie certyfikatów dla wybranych użytkowników, na wypadek utraty/unieważnienia aktualnego certyfikatu. 6. Oprogramowanie PKI musi umożliwić ustalenie odrębnego okresu ważności generowanych certyfikatów, innego w przypadku pracowników, innego w przypadku studentów lub doktorantów. Strona 8 z 92

7. Oprogramowanie PKI musi umożliwiać przechowywanie i wygenerowanie dla użytkowników kluczy prywatnych i certyfikatów w plikach w formacie PKCS#12, w którym do szyfrowania zastosowano PIN administracyjny, wygenerowany w czasie inicjalizacji karty. 8. Oprogramowanie PKI musi przygotowywać ELS, ELD i EKP do obsługi PKI w procesie personalizacji blankietu, przez co Zamawiający rozumie m.in. wykonanie następujących czynności: utworzenie konta w AD dla danego użytkownika, wygenerowanie żądania certyfikatu dla tego konta, wygenerowanie PIN-ów, dystrybucja certyfikatów. W trakcie procesu personalizacji ELS, ELD, EKP musi zostać wygenerowany indywidualny numer PIN użytkownika dla każdej karty. PIN do karty musi być co najmniej 6 znakowy. PIN karty musi zostać wydrukowany w poufny sposób na kopertach utajonych. 9. Oprogramowanie PKI umożliwia wydruk na kopercie utajonej identyfikatora i wygenerowanego w sposób losowy hasła inicjalnego dla pracownika lub studenta/doktoranta. 10. Oprogramowanie PKI w trakcie przygotowania ELS, ELD i EKP do obsługi PKI musi wygenerować także 8 cyfrowy PIN administracyjny. 11. Oprogramowanie PKI musi przygotować ELS, ELD i EKP do obsługi PKI w procesie przedłużania ważności - w systemie OPTIcamp firmy OPTeam SA. 12. Oprogramowanie PKI musi przygotować ELS, ELD i EKP do obsługi PKI w kioskach informacyjnych z oprogramowaniem OPTIcamp firmy OPTeam SA. 13. Oprogramowanie PKI musi umożliwiać wydanie dla każdego użytkownika co najmniej dwóch zestawów kluczy z certyfikatami. Liczba wydawanych certyfikatów powinna być konfigurowalna w obrębie grup. 14. Oprogramowanie PKI musi umożliwiać generowanie pary kluczy RSA (1024 bit oraz 2048 bit) przez karty ELS, ELD i EKP lub system operacyjny. 15. Oprogramowanie musi umożliwiać wybór szablonu do utworzenia certyfikatu. Szablon musi mieć możliwość definiowania listy atrybutów umieszczanych w certyfikacie oraz przeznaczenia klucza. 16. Dane zapisywane na karcie w formacie PKCS#12 muszą być archiwizowane w bazie Systemu Personalizacji Kart. 17. Oprogramowanie PKI musi umożliwiać logowanie do kiosków informacyjnych przy pomocy karty i PIN-u użytkownika i/lub konta i hasła z AD (URZ posiada kioski z oprogramowaniem firmy OPTeam SA). 18. W przypadku gdy na karcie są 2 PIN-y tj. PIN użytkownika oraz PIN ELS/ELD/EKP, system powinien zapewnić, że PIN-y te będą miały taką samą wartość. 19. Oprogramowanie PKI musi mieć wspólny interfejs z Systemem Personalizacji Kart. 20. Oprogramowanie PKI musi działać na tej samej bazie danych co System Personalizacji Kart. 21. Infrastruktura klucza PKI musi być wyposażona w serwis WWW, który umożliwi zalogowanie się użytkownika przy pomocy certyfikatu lub konta w AD. Serwis WWW infrastruktury PKI, musi umożliwiać: 22. Wyświetlenie listy wydanych certyfikatów wraz z ich statusami. 23. Unieważnienie wydanego certyfikatu. 24. Unieważnienie aktualnego certyfikatu. 25. Odnowienie certyfikatu. 26. Wyświetlenie certyfikatów znajdujących się na karcie. 27. Odblokowanie numeru PIN na karcie. 28. Zmianę numeru PIN na karcie. 29. Zmianę hasła dostępu (zmiana ta dotyczy jednocześnie hasła służącego do logowania w sieciach lokalnych). 30. Wymuszenie zmiany hasła inicjalnego podczas pierwszego logowania do serwisu WWW infrastruktury PKI oraz po resecie hasła wykonanego przez administratora. 31. Wygenerowania klucza prywatnego i żądania certyfikatu służącego do logowania; klucz prywatny i certyfikat są generowane w postaci pliku w formacie PKCS#12 i zaszyfrowane PIN-em administracyjnym, wybór tej opcji powinien być możliwy jedynie po zautoryzowaniu się w serwisie WWW. 32. Pobranie wygenerowanego certyfikatu i zapisanie go na kartę. 33. Zażądanie wygenerowania nowego certyfikatu przez użytkownika serwisu. W momencie żądania wydania nowego certyfikatu zostaje unieważniony stary certyfikat. Strona 9 z 92

34. Dostęp do historii zdarzeń powiązanych z kontem zarejestrowanych w globalnym rejestrze zdarzeń. 35. Możliwość współpracy z innymi instancjami tego systemu wdrożonego w różnych lokalizacjach. 36. możliwość wykorzystania elektronicznej portmonetki do realizacji innych rodzajów mikropłatności na rzecz uczelni lub współpracujących z nią podmiotów (np. płacenie za wydruki, opłaty w maszynach vendingowych, płatności w punktach usługowych i handlowych działających na terenie uczelni). 37. Funkcje które związane są z dostępem do karty procesorowej, są osiągalne na jednostce roboczej wyposażonej w czytnik kart inteligentnych. W przeciwnym przypadku musi pojawić się komunikat o niemożliwości wykonania operacji. Powyższe funkcje powinny być wykonywane z poziomu przeglądarki Microsoft Internet Explorer. Oprogramowanie administracyjne dla systemu PKI 38. Oprogramowanie umożliwiające zarządzanie ELS, ELD, EKP w infrastrukturze klucza publicznego (PKI). 39. Oprogramowanie musi umożliwiać wygenerowanie kluczy i żądań o certyfikat wynikających z przynależności do danej grupy. 40. Oprogramowanie ma działać na stacji roboczej. 41. Oprogramowanie musi umożliwić zapisywanie certyfikatów na kartę. 42. Oprogramowanie musi umożliwiać odblokowywanie PIN-u. 43. Oprogramowanie musi umożliwiać zmianę PIN-u. 44. Oprogramowanie musi umożliwiać zmianę hasła. 45. Oprogramowanie musi umożliwiać ładowanie zdefiniowanych w centrum PKI certyfikatów na karty GemXpresso E36 / TPC HM (karty używane w URZ jako Elektroniczne Legitymacje Studenckie, Doktoranta oraz EKP). Oprogramowanie dla użytkowników systemu PKI 46. Oprogramowanie musi umożliwiać zmianę hasła użytkownikom poprzez stronę WWW. 47. Oprogramowanie musi umożliwiać dodanie przyjaznej nazwy użytkownika poprzez stronę WWW. Oprogramowanie middleware 1. Obsługa ładowania zdefiniowanych w centrum PKI certyfikatów na karty GemXpresso E36, Classic TPC HM CC (są to karty używane u Zamawiającego jako Elektroniczne Legitymacje Studenckie/doktoranckie/pracownicze); 2. Bezpieczne logowanie do systemów Windows XP/Vista/7, Windows 2000/2003/2008/2008 R2 Server w domenie Windows; 3. Blokowanie i odblokowywanie stacji roboczych Windows XP/Vista/7 oraz Windows 2000/2003/2008/2008 R2 Server w domenie Windows; 4. Podpisywanie makr w dokumentach Office 2003,2007 oraz dokumentów Adobe Acrobat; 5. Wysyłanie i otrzymywanie zaszyfrowanej poczty elektronicznej przy wykorzystaniu oprogramowania firm Microsoft oraz Mozilla; 6. Zarządzanie certyfikatami wgranymi na Elektroniczną Legitymację Studencką, doktorancką oraz na Elektroniczną Kartę Pracowniczą. III. Specyfikacja drukarki igłowej do poufnego wydruku kodów PIN 1 szt. LP Parametry Wymagania minimalne 1 Ilość igieł 9 2 Szerokość papieru (arkusze) 102-239 mm 3 Szerokość papieru (składanka) 63,5-406 mm 4 Druk w kolorze Nie 5 Ilość drukowanych kopii (oryginał + kopie) 5 6 Maksymalna długość wiersza 15 cali 7 Emulacje Epson FX, IBM ProPrinter 8 Maksymalna szybkość druku (DRAFT) 435 zn./sek. 9 Maksymalna szybkość druku (NLQ) 73 zn./sek. 10 Polskie znaki Mazovia, Latin 2, ISO Latin, Win Latin 11 Średni czas pracy bez awarii @ 25% 10000 godzin 12 Pamięć buforowa 88 kb Strona 10 z 92

13 Trwałość głowicy (mln uderzeń) 200 14 Trwałość taśmy (mln znaków) 3 15 Dwukierunkowy druk grafiki Nie 16 Sposób podawania papieru Dół, góra, tył 17 Złącza zewnętrzne Centronics, USB 18 Kabel PC Kabel USB 19 Poziom hałasu 58 db 20 Obsługiwane systemy operacyjne MS DOS, Microsoft Windows 21 Masa netto 9,1 kg IV. Koperta utajniona do wydruku kodów PIN, loginu i hasła 25 200szt (14 kartonów) Koperty utajnione KU 240x4" wzór 01 w kartonie 1800 sztuk kopert (600 składek x 3 koperty). ETAP 4 Dostawa, konfiguracja i uruchomienie oprogramowania administracyjnego dla systemu uwierzytelnienia i autoryzacji. Termin realizacji: Zgodnie z harmonogramem ustalonym z Wykonawcą, nie później niż do 30 listopada 2014 r. Oprogramowanie umożliwiające zarządzanie Elektroniczną Kartą Pracowniczą (EKP), Elektroniczną Legitymacją Studencką (ELS) i Elektroniczną Legitymacją Doktoranta (ELD) w infrastrukturze klucza publicznego (PKI) licencja na 2 stanowiska. Funkcjonalność: 1. Oprogramowanie musi umożliwiać wygenerowanie kluczy i żądań o certyfikat wynikających z przynależności do danej grupy; 2. Oprogramowanie ma działać na stacji roboczej klasy PC; 3. Oprogramowanie musi umożliwić zapisywanie certyfikatów na kartę; 4. Oprogramowanie musi umożliwiać odblokowywanie PIN-u; 5. Oprogramowanie musi umożliwiać zmianę PIN-u; 6. Oprogramowanie musi umożliwiać zmianę hasła. Oprogramowanie dla użytkowników systemu uwierzytelnienia i autoryzacji Funkcjonalność: 1. Oprogramowanie musi umożliwiać zmianę hasła użytkownikom poprzez stronę WWW; 2. Oprogramowanie musi umożliwiać dodanie przyjaznej nazwy użytkownika poprzez stronę WWW. Strona 11 z 92

SYSTEM WYPOŻYCZEŃ KLUCZY/SPRZĘTU System do zarządzania kluczami/sprzętem ma zapewnić: 1. sprawne i skuteczne zarządzanie kluczami w Uniwersytecie Rzeszowskim, 2. kontrolę dostępu do pomieszczeń tak aby uniemożliwić zabranie kluczy przez osoby nieupoważnione, 3. identyfikację użytkownika w oparciu o karty zbliżeniowe (ELS, ELD, EKP i inne), 4. raportowanie i monitorowanie zdarzeń, incydentów a także obiegu kluczy w poszczególnych lokalizacjach Uniwersytetu 5. możliwość zapisu/wydruku danych identyfikacyjnych na karcie wydawanej użytkownikowi Aby wdrożyć System wypożyczeń kluczy/sprzętu należy wykonać następujące zadania: 1. Dostarczyć, zainstalować i skonfigurować sprzęt. 2. Dostarczyć niezbędne licencje bazodanowe oraz systemowe potrzebne do wdrożenia poszczególnych modułów (np. SQL Server, Windows Server itp.) wraz z nośnikami instalacyjnymi. 3. Dostarczyć, skonfigurować i uruchomić oprogramowanie zarządzające oraz klienckie do obsługi wydań kluczy/sprzętu. 4. Przeszkolić administratorów i użytkowników oraz dostarczyć dokumentację Systemu wypożyczeń kluczy/sprzętu (użytkownika, administratora, itp.). Zasoby niezbędne do zbudowania Systemu wypożyczeń kluczy/sprzętu (wymagania techniczne podano w dalszej części załącznika): 1. Breloki z interfejsem bezstykowym typu Mifare 3.100 szt; 2. Terminale z czytnikami bezstykowymi 26 szt; 3. Oprogramowanie umożliwiające zarządzanie (administracyjne) 26 licencji stanowiskowych; 4. Oprogramowanie umożliwiające obsługę wydawania kluczy i sprzętu 26 licencji stanowiskowych. Opieka serwisowa Systemu Wypożyczeń Kluczy/Sprzętu Zamawiający wymaga, aby Wykonawca objął dostarczony System 24 miesięczną opieką serwisową. W ramach opieki serwisowej Zamawiający wymaga darmowego dostarczania aktualizacji oprogramowania będących wynikiem zmian przepisów prawa. Minimalny zestaw wymagań względem usług wykonywanych w ramach opieki serwisowej: 1. Usuwanie błędu krytycznego w nie dłużej niż 8 godzin roboczych od momentu zgłoszenia; 2. Usuwanie błędu zwykłego w nie dłużej niż 3 dni robocze od momentu zgłoszenia; 3. Usunięcia usterki w nie dłużej niż 10 dni roboczych od momentu zgłoszenia. Zamawiający przewiduje możliwość zdalnego dostępu do bazy i aplikacji produkcyjnej Systemu po zapewnieniu wymaganego poziomu bezpieczeństwa danych. Zamawiający wymaga bieżących modyfikacji i uaktualnień Systemu wynikających ze zmiany przepisów prawnych. Ponadto Wykonawca zobowiązuje się do rozszerzenia programu (na podstawie odrębnych zleceń) o nowe funkcjonalności wymagane przez Zamawiającego. Zgłoszenia dotyczące modyfikacji muszą być zrealizowane w uzasadnionym czasie. Wymagana ogólne funkcjonalne Systemu Wypożyczeń Kluczy/Sprzętu System powinien zapewnić możliwość reagowania na zdarzenia incydentalne związane np. z brakiem lub zagubieniem karty przez użytkownika i pozwolić na wydanie klucza/sprzętu po wybraniu go z listy użytkowników. System musi obsługiwać typy operacji: Wypożyczenie / oddanie klucza, sprzętu Wypożyczenie wielu kluczy na raz Zwroty obiektów/kluczy Wypożyczanie / zwrot w trybie awaryjnym Strona 12 z 92

Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Status klucza, sprzętu Podgląd kluczy niewypożyczonych Podgląd kluczy wypożyczonych System musi posiadać funkcję anulowania operacji wydania lub odbioru klucza. Dodatkowo, jeżeli klucz nie został wydany w przewidzianym czasie a system zidentyfikował użytkownika (zalogował) musi automatycznie zakończyć operację (wylogować użytkownika) po zdefiniowanym okresie czasu. System powinien umożliwiać przypisanie więcej niż jednego klucza do jednego breloka. System musi identyfikować osobę w momencie przyłożenia karty zbliżeniowej (ELS/ELD/EKP) do czytnika oraz wskazać uprawnienia tej osoby. System musi uwzględniać możliwość pobrania przez osobę więcej niż jednego klucza w trakcie jednokrotnego logowania oraz pozwalać na przypisanie więcej niż jednej osoby do jednego klucza/sprzętu. W trakcie operacji pobierania klucza, system musi oznaczyć, że klucz/klucze zostały pobrane przez upoważnionego pracownika/studenta/doktoranta. W razie braku uprawnienia do pobrania/zwrotu klucza system musi ten fakt wyraźnie zasygnalizować za pomocą dźwięku i widocznego sygnału na ekranie o braku uprawnienia, a następnie odnotować to zdarzenie, jako incydent. Osoba wydająca klucz musi być zalogowana do systemu za pomocą karty pracowniczej lub loginu i hasła oraz jednoznacznie identyfikowana w systemie przy wykonywaniu operacji. System musi mieć możliwość jednoczesnej obsługi nielimitowanej ilości czytników/programatorów kart i kluczy. System musi obsługiwać nielimitowaną ilość kluczy. System musi obsługiwać nielimitowaną ilość użytkowników. W obrębie wszystkich lokalizacji URZ system musi mieć możliwość zdefiniowania nielimitowanej ilości ograniczeń czasowych nakładanych na dostęp do pomieszczeń wraz z powiązaniem ich z użytkownikiem lub grupą użytkowników. Dostawa, instalacja sprzętu komputerowego i oprogramowania do wypożyczeń kluczy/sprzętu: Etap Zadanie Termin realizacji 1 Dostawa licencji Do 10 dni od daty zawarcia umowy 2 Dostawa, instalacja sprzętu komputerowego i oprogramowania Zgodnie z harmonogramem 4 Dostawa, konfiguracja i uruchomienie oprogramowania oraz szkolenie użytkowników ustalonym z Wykonawcą, nie później niż do 30 listopada 2014 r. Termin realizacji: Zgodnie z harmonogramem ustalonym z Wykonawcą, nie później niż do 30 listopada 2014 r. ETAP 1 Dostawa licencji: a) Licencja kliencka do obsługi wypożyczeń minimum 26 licencji na stację roboczą b) Licencja administratora minimum 26 licencji na stację roboczą (moduł zarządzający) Termin realizacji: 10 dni od daty podpisania umowy. ETAP 2 Dostawa, instalacja sprzętu komputerowego i oprogramowania podstawowego dla Systemu PKI. Termin realizacji: Zgodnie z harmonogramem ustalonym z Wykonawcą, nie później niż do 30 listopada 2014 r. Wymagania względem dostarczanego sprzętu: 1. Urządzenia muszą być fabrycznie nowe; 2. Urządzenia i ich komponenty muszą być oznakowane przez producentów w taki sposób, aby możliwa była identyfikacja zarówno produktu jak i producenta; Strona 13 z 92

3. Wszystkie serwery muszą posiadać Certyfikat B lub CE albo spełniać normy równoważne; Zamawiający zapewnia podłączenie dostarczonego sprzętu do istniejącej sieci LAN Uczelni. System Wypożczyń Kluczy I Sprzętu Lp. Specyfikacja 1. Breloki z interfejsem bezstykowym Mifare 1kB Zgodny z normą ISO/IEC 14443 typ A, zgodny ze standardem przemysłowym MIFARE dla protokołu klasycznego o pojemności pamięci 1 kilobajta (MIFARE Standard 1 kbyte Card IC MF1 IC S50 Functional Specification) 2. Terminal/ z ekranem dotykowym do wydawania kluczy na portierni oraz koderem kart/breloków Mifare Obsługa kart: Philips MIFARE, DESFire, MIFARE ProX, and i.code; HID: iclass ; Texas Instruments: TagIT ; ST Micro: x-ident, SR 176, SR 1X 4K; Infineon: My-d (in secure mode UID); Atmel: AT088RF020; KSW MicroTech: KSW TempSens; JavaCard: JCOP in RSA mode. Interfejs hosta: USB 2.0 CCID 1 (zgodny z USB 1.1) Prędkość transmisji: 12 Mbps (USB 2.0 pełna prędkość) Zasilanie poprzez USB Smart Card Interface, Standardy ISO 7816 & EMV2 2000 Level 1 Protokoły T=0, T=1, 2-wire: SLE 4432/42 (S=10), 3-wire: SLE 4418/28 (S=9), I2C (S=8) Rozmiar karty: ID-1 (pełny wymiar) Prędkość interfejsu Smart Card: 420 Kbps (w zależności od typu karty) Taktowanie Smart Card: do 8 MHz Wspierane typy kart: 5V, 3V and 1.8V Smart Cards, ISO 7816 Class A, AB and C Zapotrzebowanie prądowe: 60 ma Wykrywanie i ochrona Smart Card: wykrywanie włożenia karty oraz auto power-off wykrywanie typu karty zabezpieczenie przeciwzwarciowe i termiczne 8 Pin handling wsparcie dla C4 / C8 Wspierane API: PC/SC driver (ready for 2.01), CT-API (on top of PC/SC), Synchronous-API (on top of PC/SC), OCF (on top of PC/SC) Wsparcie dla PC/SC: Windows 2000 / XP (32bit), 2003 Server, 2008 Server, Windows CE 5.0 / CE.NET / CE 6.0 (w zależności od konfiguracji sprzętowej), Windows XP 64bit, Windows Vista (32bit / 64bit), Windows 7 (32bit / 64bit), Linux, Mac OS X (Power PC/Intel) Częstotliwość procesora: minimum 1,8 GHz; Częstotliwość szyny QPI/DMI minimum: 2,5 GT/s; Pojemność pamięci cache [L2]: 512 kb; Ilość zainstalowanych dysków: 1 szt. Dysk HDD: minimum 320 GB SATA II Pamięć RAM: minimum 2048 MB DDR; Zintegrowana karta graficzna Zintegrowana karta dźwiękowa Zintegrowana karta sieciowa 10/100/1000 Mbit/s Minimum 4 x USB 2.0 System operacyjny Windows 7 lub nowszy ekran minimum 15,6 rozdzielczość minimum 1024x768 Ilość (szt.) 3100 26 Specyfikacja oprogramowania do wypożyczeń kluczy/sprzętu Strona 14 z 92

Systemem do obsługi wypożyczeń kluczy składa się z: Systemu Informatycznego do wypożyczeń kluczy i sprzętu wyspecyfikowanego w punkcie 1 poniżej oraz licencje: a) Licencja kliencka do obsługi wypożyczeń minimum 26 licencji na stację roboczą b) Licencja administratora - minimum 26 licencji na stację roboczą (moduł zarządzający) Wymagania 1. Oprogramowanie musi umożliwiać przypisanie więcej niż jednego klucza/sprzętu do jednego breloka/etykiety Mifare 2. Oprogramowanie musi obsługiwać już wydane karty ELS/ELD/EKP 3. Oprogramowanie musi identyfikować osobę w momencie przyłożenia karty zbliżeniowej (ELS/ELD/EKP) do czytnika oraz wskazać uprawnienia tej osoby 4. Oprogramowanie musi uwzględniać możliwość pobrania przez osobę więcej niż jednego klucza w trakcie jednokrotnego logowania 5. Oprogramowanie musi uwzględniać możliwość wpisania uwag podczas wypożyczeń klucza/sprzętu 6. Oprogramowanie musi pozwalać na przypisanie więcej niż jednej osoby do jednego klucza/sprzętu 7. W trakcie operacji pobierania klucza, oprogramowanie musi oznaczyć, że klucz/sprzęt został pobrany przez upoważnionego pracownika/studenta/doktoranta 8. Oprogramowanie w razie braku uprawnienia do pobrania/zwrotu klucza musi ten fakt wyraźnie zasygnalizować za pomocą dźwięku i widocznego sygnału na ekranie o braku uprawnienia, a następnie odnotować to zdarzenie, jako incydent 9. Osoba wydająca klucz musi być zalogowana do systemu za pomocą karty pracowniczej lub loginu i hasła oraz jednoznacznie identyfikowana w systemie przy wykonywaniu operacji 10. Oprogramowanie nie może ograniczać jednoczesnej obsługi czytników/programatorów kart 11. Oprogramowanie musi mieć możliwość obsługi nielimitowanej ilości kluczy/sprzętu 12. Oprogramowanie musi obsługiwać nielimitowaną ilość użytkowników 13. Oprogramowanie musi mieć możliwość zdefiniowania nielimitowanej ilości ograniczeń czasowych nakładanych na dostęp do pomieszczeń wraz z powiązaniem ich z użytkownikiem lub grupą użytkowników 14. Oprogramowanie obsługujące wydawanie kluczy/sprzętu musi być zintegrowane z systemem SELS na URZ - ma czerpać listę użytkowników oraz kart (identyfikatorów) z bazy danych SELS oraz uaktualniać ją na bieżąco 15. Oprogramowanie musi mieć możliwość tworzenia kont administratorów i użytkowników (gości) oraz nadawania im stosownych uprawnień. Operacje dokonywane w aplikacji muszą jednoznacznie identyfikować konto, z którego zostały wykonane 16. Oprogramowanie musi mieć możliwość zarządzania rolami użytkowników 17. Oprogramowanie musi mieć możliwość archiwizowania danych/logów/zdarzeń 18. Oprogramowanie musi mieć funkcjonalność uaktywnienia aplikacji ( wyświetlenia na pierwszym planie) po przyłożeniu karty do czytnika 19. Aplikacja musi mieć możliwość pracy jako powłoka systemu operacyjnego (shell) Cechy modułu administratora (zarządzanie) 20. Dostęp tylko po zalogowaniu dla uprawnionych administratorów systemu 21. Oprogramowanie musi mieć możliwość zarządzania grupami pracowników 22. Oprogramowanie musi mieć możliwość zarządzania kluczami 23. Oprogramowanie musi mieć możliwość zarządzania strefami czasowymi 24. Oprogramowanie musi mieć możliwość zarządzania uprawnieniami pracowników/studentów/doktorantów do pobierania kluczy/sprzętu 25. Oprogramowanie musi mieć możliwość zarządzania ustawieniami opisu działań (akcji), jakie ma podjąć portier w przypadku sytuacji alarmowych 26. Oprogramowanie musi mieć możliwość generowania zestawień i raportów z konfiguracji systemu 27. Oprogramowanie musi mieć możliwość generowania zestawień i raportów z wypożyczeń kluczy Strona 15 z 92

28. Oprogramowanie musi mieć możliwość generowania zestawień i raportów stanu kluczy na portierni, wypożyczonych kluczy 29. Oprogramowanie musi mieć możliwość generowania indywidualnych dowolnych zestawień i raportów 30. Oprogramowanie musi mieć możliwość ustawienia filtrowania danych i zdarzeń 31. Oprogramowanie musi mieć możliwość generowania Raportów dotyczących wszystkich zdarzeń zachodzących w systemie np. zalogowanie, wylogowanie" 32. Oprogramowanie musi mieć posiadać raport zawierający listę kluczy z przyporządkowanymi nazwiskami pracowników, którzy aktualnie posiadają dostęp do danego klucza 33. Oprogramowanie musi pozwalać na eksport wyników raportów do pliku csv i PDF 34. Oprogramowanie wydawania kluczy musi być zrealizowany w technologii klient serwer 35. Oprogramowanie na serwerze musi mieć możliwość pracy w środowisku wirtualnym, na systemie operacyjnym Windows Server 2008 R2 36. Oprogramowanie musi mieć możliwość instalacji na dowolnie wskazanym stanowisku pracy opartym na środowisku Windows XP/Vista(32 lub 64)/Win7 (32 lub 64) 37. Komunikacja z terminalami (rejestrowanie wydawania/przyjmowania kluczy i sprzętu) ma się odbywać z wykorzystaniem standardu Ethernet (protokoły IP, TCP, UDP) 38. Oprogramowanie musi działać na tej samej bazie danych co System Personalizacji Kart funkcjonujący na URZ 39. Oprogramowanie musi być w pełni obsługiwane z poziomu systemu do Personalizacji Kart użytkowanego przez URZ przy zachowaniu dotychczasowych funkcjonalności systemu. Nie dopuszcza się stosowania dodatkowego interfejsu do obsługi systemu wypożyczeń Wykaz lokalizacji gdzie będzie zainstalowany system do wypożyczeń Kluczy i Sprzętu będzie udostępniony podczas analizy wdrożeniowej. Strona 16 z 92

SYSTEM KONTROLI DOSTĘPU System kontroli dostępu ma zapewnić ograniczony dostęp do trzech pomieszczeń w Uniwersytecie Rzeszowskim tak aby uniemożliwić niepowołany dostęp oraz pozwoli na identyfikację użytkownika w oparciu o karty zbliżeniowe (ELS, ELD, EKP i inne), raportowanie i monitorowanie zdarzeń, incydentów. Aby zrealizować System wypożyczeń kluczy/sprzętu należy wykonać następujące zadania: 1. dostarczyć, zainstalować i skonfigurować sprzęt i oprogramowanie 2. dostarczyć niezbędne licencje bazodanowe oraz systemowe potrzebne do wdrożenia poszczególnych modułów (np. SQL Server, Windows Server itp.) wraz z nośnikami instalacyjnymi. 3. przeszkolić administratorów oraz użytkowników Uczelni oraz dostarczyć dokumentację Systemu kontroli dostępu (SKD) (użytkownika, administratora, itp.). Zasoby niezbędne do zbudowania Systemu Kontroli Dostępu (SKD) - (wymagania techniczne podano w dalszej części załącznika): 1. Kontroler SKD wraz z niezbędnymi zasilaczami itp. 2. Czytniki bezstykowe 3. Elementy wykonawcze 4. Oprogramowanie umożliwiające zarządzanie (administracyjne) 5. Oprogramowanie integrujące z systemem SELS (automatyczna synchronizacja danych) Opieka serwisowa Systemu Kontroli Dostępu Zamawiający wymaga, aby Wykonawca objął dostarczony Systemu 24 miesięczną opieką serwisową. W ramach opieki serwisowej Zamawiający wymaga darmowego dostarczania aktualizacji oprogramowania będących wynikiem zmian przepisów prawa. Minimalny zestaw wymagań względem usług wykonywanych w ramach opieki serwisowej: 1. Usuwanie błędu krytycznego w nie dłużej niż 8 godzin roboczych od momentu zgłoszenia; 2. Usuwanie błędu zwykłego w nie dłużej niż 3 dni robocze od momentu zgłoszenia; 3. Usunięcia usterki w nie dłużej niż 10 dni roboczych od momentu zgłoszenia. Zamawiający przewiduje możliwość zdalnego dostępu do bazy i aplikacji produkcyjnej Systemu po zapewnieniu wymaganego poziomu bezpieczeństwa danych. Wymagana ogólne funkcjonalne Systemu KD Wdrożenie i uruchomienie systemu KD obejmuje: montaż urządzeń i elementów wykonawczych (sterowniki, czytniki, zasilacze buforowe, tablice rozdzielcze, okablowanie, zabezpieczenia, itp.), konfiguracja urządzeń wykonawczych i systemu KD, wdrożenie i uruchomienie oprogramowania KD, integracja z systemem SELS, przeszkolenie administratora i operatorów, rozprowadzenie kabli podtynkowo (skrętka). Przeszkolenie grupy pracowników w zakresie funkcjonowania, obsługi i zarządzania SKD. Zamawiający wymaga zapewnienia poprawnego działania dostarczonych systemów we współpracy z kartami jakie posiada zamawiający oraz pełną integrację dostarczonego oprogramowania z użytkowanym przez zamawiającego systemem elektronicznej legitymacji studenckiej, doktoranckiej, karty pracowniczej - produkcji firmy OPTeam S.A. Zamawiający informuje, że realizacja i montaż systemu odbywać będzie się w budynku czynnym, w którym odbywają się zajęcia dla studentów. Zamawiający posiada już karty zbliżeniowe MIFARE w standardzie ISO 14443A (studenci/doktoranci: 22 000). Łącznie System musi obsługiwać minimum 26500 identyfikatorów zbliżeniowych w standardzie MIFARE (kart/breloków). Wykonawca musi zapewnić poprawne działanie dostarczonych systemów we współpracy z kartami wydawanymi przez zamawiającego (legitymacje studenckie, pracownicze oraz klucze z brelokiem MIFARE). Należy również zapewnić pełną integrację dostarczonego oprogramowania zużytkowanym Strona 17 z 92

przez zamawiającego systemem elektronicznej legitymacji studenckiej, doktoranckiej i karty pracowniczej - SELS produkcji firmy OPTeam S.A. Zamawiający poprzez pełną integrację oprogramowania rozumie: Dostarczenie aplikacji, której zadaniem będzie synchronizacja danych między bazami danych SELS a SKD (w określonych porach lub na każdorazowe żądanie operatora). Synchronizacja ta powinna odbywać się bezpośrednio na bazie danych systemu elektronicznej legitymacji studenckiej, doktoranckiej oraz karty pracowniczej - SELS (pracującej pod kontrolą MS SQL Server 2008) oraz bazie danych SKD. Powinno to polegać na: - dla nowych użytkowników zakładaniu globalnych kartotek bez nadawania żadnych praw szczegółowych, - dla dotychczasowych uaktualnieniu danych. Zakres synchronizowanych danych powinien zawierać wszystkie możliwe do skopiowania dane, które można skopiować do systemów KD, a które są dostępne w systemach SELS. Unieważnienie legitymacji/klucza w systemie elektronicznej legitymacji studenckiej, doktoranckiej oraz karty pracowniczej powinno skutkować unieważnieniem jej/ich w systemie KD. Dostawa, instalacja sprzętu i oprogramowania SKD: Termin realizacji: Zgodnie z harmonogramem ustalonym z Wykonawcą, nie później niż do 30 listopada 2014 r. Zamawiający zapewnia podłączenie dostarczonego sprzętu do istniejącej sieci LAN Uczelni. SKD Lp. Specyfikacja Ilość (szt.) 1. Kontroler SKD z modułem LAN, zasilaczem, obudową i podtrzymaniem akumulatorowym Musi pracować w sieci VLAN z protokołem TCP/IP. Ilość obsługiwanych przejść minimum 3 jednostronnie Zdalne otwieranie drzwi Informacja o braku zasilania dioda na obudowie kontrolera Automatyczna dezaktywacja kart za pomocą harmonogramów Posiada port do podłączenia bezpośredniego drukarki Wymienna bateria do podtrzymania kalendarza, zegara i wszystkich zaprogramowanych ustawień Podtrzymanie pamięci po zaniku zasilania min. 5 lat Wymienne przekaźniki Diody LED informujące o statusie komunikacji (nadawanie/odbieranie) przez RS232/RS485 Wbudowany przycisk reset Wyświetlacz diagnostyczny umożliwiający sprawdzenie urządzenia w czasie rzeczywistym Wbudowany procesor Intela Flash memory Wbudowany zasilacz 12V DC/6A Wilgotność: od 0 do 90% (bez kondensacji) Temperatura pracy: od 0 st.c do 46st.C Miejsce w obudowie na akumulator 7Ah Opcjonalnie karta sieciowa na płycie kontrolera Kontroler obsługuje do 42 wejść i 38 wyjść Obsługa przycisków wyjścia i czujników magnetycznych Obsługa do 64 okresów czasowych Obsługa do 999 grup dostępu Każdy identyfikator może należeć do 4 grup dostępu Możliwość dołączenia modułu alarmowego (8 lub 16 wejśd) 1 Strona 18 z 92