NA/P/129/2014 Załącznik z07 do siwz elektroniczny system autoryzowanego dostępu oraz infrastruktura klucza publicznego platformy e-usług

Objaśnienia użytych skrótów:

a) „Ob:” oznacza, że funkcjonalność jest wymagana

b) „ObP:” oznacza, że funkcjonalność jest wymagana najpóźniej w dniu uruchomienia produkcyjnej wersji systemu

c) „Dod:” oznacza, że funkcjonalność jest opcjonalna.

Dla każdej z wymienionych funkcjonalności należy potwierdzić gotowość jej dostarczenia w ramach oferowanego systemu, umieszczając odpowiedni znak w nawiasie kwadratowym w następujący sposób: [ x ] oznacza potwierdzenie dostarczenia funkcjonalności, a [ - ] oznacza brak potwierdzenia dostarczenia funkcjonalności. Wymagane jest wypełnienie wszystkich pól [  ].

1. 
   ObP: [  ] Wymagane jest wdrożenie uczelnianego centrum certyfikacji – PKI, obejmującego zaufaniem pracowników, studentów i doktorantów Politechniki Rzeszowskiej.
   
2. 
   ObP: [  ] Certyfikaty muszą zapewniać możliwość ich wykorzystania w systemie elektronicznego obiegu dokumentów.
   
3. 
   ObP: [  ] Proces uwierzytelniania realizowany w systemie dostępu do pomieszczeń musi wykorzystywać układ bezstykowy ELS/ELD/EKP.
   
4. 
   ObP: [  ] Usługi katalogowe muszą umożliwiać przechowywanie klucza publicznego, a 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)
   
5. 
   ObP: [  ] Wymaga się aby dane w katalogach, w obrębie każdej grupy użytkowników zawierały atrybuty pozwalające na ich bardziej szczegółowe rozróżnienie (np. według jednostki organizacyjnej, wydziału, kierunku studiów, grup studenckich)
   
6. 
   ObP: [  ] Czynności administracyjne dotyczące zarządzania usługami katalogowymi muszą umożliwiać:
   

1. 
   zmianę schematu
   
2. 
   edycję kont użytkowników
   
3. 
   import z bazy studentów systemu USOS
   
4. 
   import z bazy pracowników systemu kadrowego
   
5. 
   usunięcie konta
   
6. 
   grupowe usunięcie wybranych kont
   
7. 
   zablokowanie konta
   
8. 
   zmiana hasła
   
9. 
   czasowe zablokowanie certyfikatu (z aktualizacją listy CRL)
   
10. 
    odblokowanie certyfikatu (z aktualizacją listy CRL)
    
11. 
    całkowite unieważnienie certyfikatu (z aktualizacją listy CRL)
    
12. 
    odnowienie certyfikatu (z aktualizacją listy CRL)
    

7. 
   ObP: [  ] Infrastruktura klucza publicznego (PKI) musi zostać zbudowana w oparciu o Active Directory lub inny LDAP.
   
8. 
   Dod: [  ] Oprogramowanie PKI musi umożliwić wystawienie i wgranie certyfikatu na karty Gemalto Classic TPC HM używane na Politechnice Rzeszowskiej
   
9. 
   ObP: [  ] Oprogramowanie PKI musi umożliwić definiowanie celów dla wystawianych certyfikatów (np. logowanie, podpis)
   
10. 
    ObP: [  ] 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)
    
11. 
    Dod: [  ] Powinno być możliwe zarówno tymczasowe i jak i całkowite unieważnienie certyfikatu.
    
12. 
    ObP: [  ] Oprogramowanie PKI musi umożliwiać administratorowi indywidualne utworzenie certyfikatów dla wybranych użytkowników, na wypadek utraty/unieważnienia aktualnego certyfikatu
    
13. 
    ObP: [  ] 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
    
14. 
    ObP: [  ] 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 kryptograficznej
    
15. 
    ObP: [  ] Oprogramowanie PKI musi przygotowywać 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 lub innym LDAP dla danego użytkownika, wygenerowanie żądania certyfikatu dla tego konta, wygenerowanie PIN-ów, dystrybucja certyfikatów. W trakcie procesu personalizacji 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.
    
16. 
    ObP: [  ] Oprogramowanie PKI umożliwia wydruk na kopercie utajonej identyfikatora i wygenerowanego w sposób losowy hasła inicjalnego dla pracownika lub studenta/doktoranta.
    
17. 
    ObP: [  ] W przypadku użycia przez Zamawiającego kart kryptograficznych wykorzystywanych jako Elektroniczne Legitymacje Studenckie (ELS) oprogramowanie musi zapewniać także dla tych kart funkcjonalności opisane w pkt. 15
    
18. 
    ObP: [  ] Oprogramowanie PKI w trakcie przygotowania ELD i EKP do obsługi PKI musi wygenerować także 8 cyfrowy PIN administracyjny.
    
19. 
    ObP: [  ] W przypadku użycia przez Zamawiającego kart kryptograficznych ELS oprogramowanie musi zapewniać także dla tych kart funkcjonalności opisane w pkt. 18
    
20. 
    Dod: [  ] Oprogramowanie PKI musi przygotować ELD i EKP do obsługi PKI w procesie przedłużania ważności w Systemie Elektronicznej Legitymacji Studenckiej używanym przez Zamawiającego.
    
21. 
    Dod: [  ] W przypadku użycia przez Zamawiającego kart kryptograficznych ELS oprogramowanie musi zapewniać także dla tych kart funkcjonalności opisane w pkt. 20
    
22. 
    ObP: [  ] Oprogramowanie PKI musi umożliwiać wydanie dla każdego użytkownika co najmniej jednego zestawu kluczy z certyfikatami. Liczba wydawanych certyfikatów powinna być konfigurowalna w obrębie grup.
    
23. 
    ObP: [  ] Oprogramowanie PKI musi umożliwiać generowanie pary kluczy RSA (1024 bit oraz 2048 bit) przez karty ELD i EKP lub system operacyjny.
    
24. 
    ObP: [  ] W przypadku użycia przez Zamawiającego kart kryptograficznych ELS oprogramowanie musi zapewniać także dla tych kart funkcjonalności opisane w pkt. 23.
    
25. 
    Dod: [  ] 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
    
26. 
    Dod: [  ] Dane zapisywane na karcie w formacie PKCS#12 muszą być archiwizowane w bazie Systemu Personalizacji Kart używanym przez Zamawiającego
    
27. 
    ObP: [  ] W przypadku gdy na karcie są 2 PIN-y tj. PIN użytkownika oraz PIN ELD/EKP, system powinien zapewnić, że PIN-y te będą miały taką samą wartość
    
28. 
    ObP: [  ] Oprogramowanie PKI musi mieć interfejs zgodny z Systemem Personalizacji Kart (w tym układ graficzny i obsługę)
    
29. 
    Dod: [  ] Oprogramowanie PKI musi działać na tej samej bazie danych co System Personalizacji Kart
    

30. 
    ObP: [  ] Serwis WWW infrastruktury PKI, musi umożliwiać:
    

13. 
    zmianę hasła dostępu (zmiana ta dotyczy jednocześnie hasła służącego do logowania w sieciach lokalnych),
    
14. 
    wymuszenie zmiany hasła inicjalnego podczas pierwszego logowania do serwisu WWW infrastruktury PKI oraz po resecie hasła wykonanego przez administratora,
    
15. 
    zażądanie wygenerowania nowego certyfikatu przez użytkownika serwisu. W momencie żądania wydania nowego certyfikatu zostaje unieważniony stary certyfikat,
    
16. 
    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)
    
17. 
    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.
    

31. 
    ObP: [  ] Oprogramowanie umożliwia zarządzanie ELD, EKP w infrastrukturze klucza publicznego (PKI)
    
32. 
    ObP: [  ] W przypadku użycia przez Zamawiającego kart kryptograficznych ELS oprogramowanie musi zapewniać także dla tych kart funkcjonalności opisane w pkt. 31.
    
33. 
    ObP: [  ] Oprogramowanie musi umożliwiać wygenerowanie kluczy i żądań o certyfikat wynikających z przynależności do danej grupy.
    
34. 
    ObP: [  ] Oprogramowanie ma działać na stacji roboczej.
    
35. 
    ObP: [  ] Oprogramowanie musi umożliwić zapisywanie certyfikatów na kartę kryptograficzną.
    
36. 
    ObP: [  ] Oprogramowanie musi umożliwiać odblokowywanie PIN-u.
    
37. 
    ObP: [  ] Oprogramowanie musi umożliwiać zmianę PIN-u.
    
38. 
    ObP: [  ] Oprogramowanie musi umożliwiać zmianę hasła.
    
39. 
    ObP: [  ] Oprogramowanie musi umożliwiać ładowanie zdefiniowanych w centrum PKI certyfikatów na karty Gemalto Classic TPC HM (karty używane przez Uczelnię)
    

40. 
    ObP: [  ] Oprogramowanie musi umożliwiać zmianę hasła użytkownikom poprzez stronę WWW
    
41. 
    ObP: [  ] Oprogramowanie musi umożliwiać dodanie przyjaznej nazwy użytkownika poprzez stronę WWW
    

42. 
    Dod: [  ] Wymagana jest implementacja oprogramowania rozszerzającego usługę eduroam, która pozwoli na integrację istniejących w Uczelni serwerów Radius z implementowanymi w projekcie e-PRz usługami PKI oraz centralnym systemem autoryzacji.
    
43. 
    Dod: [  ] Czynności administracyjne dotyczące eduroam dostępne z poziomu zarządzania AD lub innego LDAP:
    

18. 
    edycja konta użytkownika – zmiana wartości oraz dodawanie atrybutów AD/LDAP
    
19. 
    import bazy studentów/doktorantów
    
20. 
    import bazy pracowników
    
21. 
    usunięcie konta
    
22. 
    grupowe usunięcie wybranych kont
    
23. 
    zablokowanie konta
    
24. 
    zmiana hasła (zmiana ta dotyczy jednocześnie hasła służącego do logowania w sieci eduroam przy pomocy co najmniej metody PEAP-MSCHAPv2)
    
25. 
    zablokowanie możliwości logowania w eduroam przy pomocy co najmniej metody PEAP-MSCHAPv2
    
26. 
    odblokowanie czasowo zablokowanego certyfikatu eduroam (z aktualizacją listy CRL)
    
27. 
    odblokowanie certyfikatu eduroam (z aktualizacją listy CRL)
    
28. 
    całkowite unieważnienie certyfikatu eduroam (z aktualizacją listy CRL)
    
29. 
    aktualizacja listy CRL musi być automatycznie uwzględniana przez autentykujący serwer Radius
    
30. 
    grupowa (dla wybranych kont) modyfikacja atrybutów określających przynależność do określonej grupy kont, jednostki organizacyjnej, wydziału oraz przydzielonego numeru VLAN
    

44. 
    Dod: [  ] Serwis WWW eduroam umożliwia zalogowanie się użytkownika przy pomocy loginu i hasła wygenerowanego przez Centrum PKI
    
45. 
    Dod: [  ] Po zalogowaniu do serwisu WWW użytkownik uzyskuje dostęp do następujących opcji:
    

31. 
    zmiana hasła dostępu (zmiana ta dotyczy jednocześnie hasła służącego do logowania w sieci eduroam przy pomocy co najmniej metody PEAP-MSCHAPv2)
    
32. 
    umożliwienie logowania w eduroam przy pomocy co najmniej metody PEAP-MSCHAPv2, identyfikator i hasło eduroam jest takie samo, jak identyfikator i hasło stosowane przy dostępie do serwisu WWW
    
33. 
    wymuszenie zmiany hasła inicjalnego podczas pierwszego logowania do serwisu WWW eduroam
    
34. 
    żądanie wygenerowania klucza prywatnego i certyfikatu służącego do logowania w eduroam przy pomocy metody EAP-TLS; klucz prywatny i certyfikat są generowane w postaci pliku w formacie PKCS#12 i zaszyfrowane hasłem stosowanym przy dostępie do serwisu WWW, jednak system po wybraniu tej opcji żąda podania przez użytkownika jego aktualnego hasła i je weryfikuje
    
35. 
    użytkownik serwisu może zażądać wygenerowania nowego certyfikatu eduroam. W momencie żądania wydania nowego certyfikatu zostaje unieważniony stary certyfikat.
    

46. 
    Dod: [  ] wygenerowanie klucza prywatnego i żądanie certyfikatu służącego do logowania; klucz prywatny i certyfikat są generowane w postaci pliku w formacie PKCS#12 i zaszyfrowane hasłem podanym na formularzu żądania certyfikatu, wybór tej opcji powinien być możliwy jedynie po zautoryzowaniu się w serwisie WWW
    
    
    

47. 
    Dod: [  ] Oprogramowanie musi obsługiwać już wydane u Zamawiającego karty ELS/ELD/EKP.
    
48. 
    ObP: [  ] Oprogramowanie musi identyfikować osobę (wyświetlać zdjęcie i informacje o osobie) w momencie przyłożenia karty zbliżeniowej (ELS/ELD/EKP) do czytnika oraz wskazać listę kluczy do których ta osoba ma uprawnienie.
    
49. 
    ObP: [  ] Oprogramowanie musi uwzględniać możliwość pobrania przez osobę więcej niż jednego klucza w trakcie jednokrotnego logowania.
    
50. 
    Dod: [  ] Oprogramowanie musi uwzględniać możliwość wpisania uwag podczas wypożyczania klucza/sprzętu
    
51. 
    ObP: [  ] Oprogramowanie musi pozwalać na przypisanie więcej niż jednej osoby do jednego klucza/sprzętu
    
52. 
    ObP: [  ] W trakcie operacji pobierania klucza, oprogramowanie musi oznaczyć, że klucz/sprzęt został pobrany przez upoważnionego pracownika/studenta/doktoranta
    
53. 
    ObP: [  ] 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
    
54. 
    ObP: [  ] Osoba wydająca klucz musi być zalogowana do systemu za pomocą EKP lub loginu i hasła oraz jednoznacznie identyfikowana w systemie przy wykonywaniu operacji
    
55. 
    Dod: [  ] Oprogramowanie nie może ograniczać jednoczesnej obsługi czytników/programatorów kart
    
56. 
    Dod: [  ] Oprogramowanie musi mieć możliwość obsługi nielimitowanej ilości kluczy/sprzętu
    
57. 
    Dod: [  ] Oprogramowanie musi obsługiwać nielimitowaną ilość użytkowników
    
58. 
    Dod: [  ] 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
    
59. 
    Dod: [  ] Oprogramowanie obsługujące wydawanie kluczy/sprzętu musi być zintegrowane z Systemem Elektronicznej Legitymacji Studenckiej (SELS) użytkowanym na Uczelni - ma czerpać listę użytkowników oraz kart (identyfikatorów) z bazy danych SELS oraz uaktualniać ją na bieżąco
    
60. 
    ObP: [  ] 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
    
61. 
    ObP: [  ] Oprogramowanie musi mieć możliwość zarządzania rolami użytkowników
    
62. 
    ObP: [  ] Oprogramowanie musi mieć możliwość archiwizowania danych/logów/zdarzeń
    
63. 
    Dod: [  ] Oprogramowanie musi mieć funkcjonalność uaktywnienia aplikacji (wyświetlenia na pierwszym planie) po przyłożeniu karty do czytnika
    
64. 
    Dod: [  ] Aplikacja musi mieć możliwość pracy jako powłoka systemu operacyjnego (shell)
    

65. 
    ObP: [  ] Oprogramowanie musi mieć możliwość zarządzania grupami pracowników
    
66. 
    ObP: [  ] Oprogramowanie musi mieć możliwość zarządzania kluczami
    
67. 
    Dod: [  ] Oprogramowanie musi mieć możliwość zarządzania strefami czasowymi
    
68. 
    ObP: [  ] Oprogramowanie musi mieć możliwość zarządzania uprawnieniami pracowników/studentów/doktorantów do pobierania kluczy/sprzętu
    
69. 
    Dod: [  ] Oprogramowanie musi mieć możliwość zarządzania ustawieniami opisu działań (akcji), jakie ma podjąć portier w przypadku sytuacji alarmowych
    
70. 
    Dod: [  ] Oprogramowanie musi mieć możliwość generowania zestawień i raportów z konfiguracji systemu
    
71. 
    ObP: [  ] Oprogramowanie musi mieć możliwość generowania zestawień i raportów z wypożyczeń kluczy
    
72. 
    ObP: [  ] Oprogramowanie musi mieć możliwość generowania zestawień i raportów stanu kluczy na portierni, wypożyczonych kluczy
    
73. 
    ObP: [  ] Oprogramowanie musi mieć możliwość ustawienia filtrowania danych i zdarzeń
    
74. 
    ObP: [  ] Oprogramowanie musi mieć możliwość generowania Raportów dotyczących wszystkich zdarzeń zachodzących w systemie np. „zalogowanie”, „wylogowanie”
    
75. 
    ObP: [  ] Oprogramowanie musi posiadać raport zawierający listę kluczy z przyporządkowanymi nazwiskami pracowników, którzy aktualnie posiadają dostęp do danego klucza
    
76. 
    ObP: [  ] Oprogramowanie musi pozwalać na eksport wyników raportów do pliku CSV i PDF
    
77. 
    ObP: [  ] Oprogramowanie wydawania kluczy musi być zrealizowany w technologii klient serwer
    
78. 
    Dod: [  ] Oprogramowanie musi działać na tej samej bazie danych co System Personalizacji Kart funkcjonujący na Uczelni
    
79. 
    ObP: [  ] Oprogramowanie elektronicznego systemu autoryzowanego dostępu musi mieć interfejs zgodny z systemem Personalizacji Kart (w tym podobny układ graficzny i obsługę)
    
80. 
    Dod: [  ] Unieważnienie EKP/ELS/ELD w Systemie Elektronicznej Legitymacji Studenckiej wykorzystywanej na Uczelni do personalizacji i przedłużania ważności legitymacji skutkuje odebraniem praw do wypożyczania kluczy przy pomocy tej karty.
    
81. 
    Dod: [  ] Oprogramowanie powinno posiadać możliwość importu struktury pomieszczeń z arkusza kalkulacyjnego.
    
82. 
    Dod: [  ] Oprogramowanie powinno posiadać możliwość importu uprawnień do pomieszczeń z arkusza kalkulacyjnego.
    
83. 
    Dod: [  ] Oprogramowanie powinno posiadać możliwość zapisu instrukcji obsługi do wypożyczanego  sprzętu na PENDRIVE
    
84. 
    Dod: [  ] Oprogramowanie powinno posiadać możliwość wyświetlania zdjęcia wypożyczanego sprzętu