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



Pobieranie 35.03 Kb.
Data28.04.2016
Rozmiar35.03 Kb.



nr sprawy 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 [  ].



Oprogramowanie do elektronicznego autoryzowanego dostępu do wybranych elementów majątków Uczelni
A. Wymagania dla systemu uwierzytelniania i autoryzacji w oparciu o infrastrukturę klucza publicznego (PKI)

A1. Wymagania ogólne

  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)

A2. Oprogramowanie PKI

  1. ObP: [  ] Infrastruktura klucza publicznego (PKI) musi zostać zbudowana w oparciu o Active Directory lub inny LDAP.

  2. Dod: [  ] Oprogramowanie PKI musi umożliwić wystawienie i wgranie certyfikatu na karty Gemalto Classic TPC HM używane na Politechnice Rzeszowskiej

  3. ObP: [  ] Oprogramowanie PKI musi umożliwić definiowanie celów dla wystawianych certyfikatów (np. logowanie, podpis)

  4. 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)

  5. Dod: [  ] Powinno być możliwe zarówno tymczasowe i jak i całkowite unieważnienie certyfikatu.

  6. ObP: [  ] Oprogramowanie PKI musi umożliwiać administratorowi indywidualne utworzenie certyfikatów dla wybranych użytkowników, na wypadek utraty/unieważnienia aktualnego certyfikatu

  7. 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

  8. 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

  9. 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.

  10. ObP: [  ] Oprogramowanie PKI umożliwia wydruk na kopercie utajonej identyfikatora i wygenerowanego w sposób losowy hasła inicjalnego dla pracownika lub studenta/doktoranta.

  11. 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

  12. ObP: [  ] Oprogramowanie PKI w trakcie przygotowania ELD i EKP do obsługi PKI musi wygenerować także 8 cyfrowy PIN administracyjny.

  13. 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

  14. 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.

  15. 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

  16. 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.

  17. ObP: [  ] Oprogramowanie PKI musi umożliwiać generowanie pary kluczy RSA (1024 bit oraz 2048 bit) przez karty ELD i EKP lub system operacyjny.

  18. 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.

  19. 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

  20. Dod: [  ] Dane zapisywane na karcie w formacie PKCS#12 muszą być archiwizowane w bazie Systemu Personalizacji Kart używanym przez Zamawiającego

  21. 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ść

  22. ObP: [  ] Oprogramowanie PKI musi mieć interfejs zgodny z Systemem Personalizacji Kart (w tym układ graficzny i obsługę)

  23. Dod: [  ] Oprogramowanie PKI musi działać na tej samej bazie danych co System Personalizacji Kart

A3. Serwis WWW infrastruktury PKI

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

  1. zmianę hasła dostępu (zmiana ta dotyczy jednocześnie hasła służącego do logowania w sieciach lokalnych),

  2. wymuszenie zmiany hasła inicjalnego podczas pierwszego logowania do serwisu WWW infrastruktury PKI oraz po resecie hasła wykonanego przez administratora,

  3. zażądanie wygenerowania nowego certyfikatu przez użytkownika serwisu. W momencie żądania wydania nowego certyfikatu zostaje unieważniony stary certyfikat,

  4. 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)

  5. 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.

A4. Oprogramowanie administracyjne dla systemu PKI

  1. ObP: [  ] Oprogramowanie umożliwia zarządzanie ELD, EKP w infrastrukturze klucza publicznego (PKI)

  2. 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.

  3. ObP: [  ] Oprogramowanie musi umożliwiać wygenerowanie kluczy i żądań o certyfikat wynikających z przynależności do danej grupy.

  4. ObP: [  ] Oprogramowanie ma działać na stacji roboczej.

  5. ObP: [  ] Oprogramowanie musi umożliwić zapisywanie certyfikatów na kartę kryptograficzną.

  6. ObP: [  ] Oprogramowanie musi umożliwiać odblokowywanie PIN-u.

  7. ObP: [  ] Oprogramowanie musi umożliwiać zmianę PIN-u.

  8. ObP: [  ] Oprogramowanie musi umożliwiać zmianę hasła.

  9. ObP: [  ] Oprogramowanie musi umożliwiać ładowanie zdefiniowanych w centrum PKI certyfikatów na karty Gemalto Classic TPC HM (karty używane przez Uczelnię)

A5. Oprogramowanie dla użytkowników systemu PKI

  1. ObP: [  ] Oprogramowanie musi umożliwiać zmianę hasła użytkownikom poprzez stronę WWW

  2. ObP: [  ] Oprogramowanie musi umożliwiać dodanie przyjaznej nazwy użytkownika poprzez stronę WWW

A6. Oprogramowanie rozszerzające funkcjonalność eduroam

  1. 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.

  2. Dod: [  ] Czynności administracyjne dotyczące eduroam dostępne z poziomu zarządzania AD lub innego LDAP:

  1. edycja konta użytkownika – zmiana wartości oraz dodawanie atrybutów AD/LDAP

  2. import bazy studentów/doktorantów

  3. import bazy pracowników

  4. usunięcie konta

  5. grupowe usunięcie wybranych kont

  6. zablokowanie konta

  7. 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)

  8. zablokowanie możliwości logowania w eduroam przy pomocy co najmniej metody PEAP-MSCHAPv2

  9. odblokowanie czasowo zablokowanego certyfikatu eduroam (z aktualizacją listy CRL)

  10. odblokowanie certyfikatu eduroam (z aktualizacją listy CRL)

  11. całkowite unieważnienie certyfikatu eduroam (z aktualizacją listy CRL)

  12. aktualizacja listy CRL musi być automatycznie uwzględniana przez autentykujący serwer Radius

  13. 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

  1. Dod: [  ] Serwis WWW eduroam umożliwia zalogowanie się użytkownika przy pomocy loginu i hasła wygenerowanego przez Centrum PKI

  2. Dod: [  ] Po zalogowaniu do serwisu WWW użytkownik uzyskuje dostęp do następujących opcji:

  1. 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)

  2. 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

  3. wymuszenie zmiany hasła inicjalnego podczas pierwszego logowania do serwisu WWW eduroam

  4. żą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

  5. użytkownik serwisu może zażądać wygenerowania nowego certyfikatu eduroam. W momencie żądania wydania nowego certyfikatu zostaje unieważniony stary certyfikat.

  1. 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



B. Wymagania dla pakietu (systemu) do zarządzania pomieszczeniami dydaktycznymi (kluczami) oraz ich wyposażeniem

B1. Wymagania ogólne

  1. Dod: [  ] Oprogramowanie musi obsługiwać już wydane u Zamawiającego karty ELS/ELD/EKP.

  2. 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.

  3. ObP: [  ] Oprogramowanie musi uwzględniać możliwość pobrania przez osobę więcej niż jednego klucza w trakcie jednokrotnego logowania.

  4. Dod: [  ] Oprogramowanie musi uwzględniać możliwość wpisania uwag podczas wypożyczania klucza/sprzętu

  5. ObP: [  ] Oprogramowanie musi pozwalać na przypisanie więcej niż jednej osoby do jednego klucza/sprzętu

  6. ObP: [  ] W trakcie operacji pobierania klucza, oprogramowanie musi oznaczyć, że klucz/sprzęt został pobrany przez upoważnionego pracownika/studenta/doktoranta

  7. 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

  8. 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

  9. Dod: [  ] Oprogramowanie nie może ograniczać jednoczesnej obsługi czytników/programatorów kart

  10. Dod: [  ] Oprogramowanie musi mieć możliwość obsługi nielimitowanej ilości kluczy/sprzętu

  11. Dod: [  ] Oprogramowanie musi obsługiwać nielimitowaną ilość użytkowników

  12. 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

  13. 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

  14. 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

  15. ObP: [  ] Oprogramowanie musi mieć możliwość zarządzania rolami użytkowników

  16. ObP: [  ] Oprogramowanie musi mieć możliwość archiwizowania danych/logów/zdarzeń

  17. Dod: [  ] Oprogramowanie musi mieć funkcjonalność uaktywnienia aplikacji (wyświetlenia na pierwszym planie) po przyłożeniu karty do czytnika

  18. Dod: [  ] Aplikacja musi mieć możliwość pracy jako powłoka systemu operacyjnego (shell)

B2. Cechy modułu administratora (zarządzanie)

  1. ObP: [  ] Oprogramowanie musi mieć możliwość zarządzania grupami pracowników

  2. ObP: [  ] Oprogramowanie musi mieć możliwość zarządzania kluczami

  3. Dod: [  ] Oprogramowanie musi mieć możliwość zarządzania strefami czasowymi

  4. ObP: [  ] Oprogramowanie musi mieć możliwość zarządzania uprawnieniami pracowników/studentów/doktorantów do pobierania kluczy/sprzętu

  5. Dod: [  ] Oprogramowanie musi mieć możliwość zarządzania ustawieniami opisu działań (akcji), jakie ma podjąć portier w przypadku sytuacji alarmowych

  6. Dod: [  ] Oprogramowanie musi mieć możliwość generowania zestawień i raportów z konfiguracji systemu

  7. ObP: [  ] Oprogramowanie musi mieć możliwość generowania zestawień i raportów z wypożyczeń kluczy

  8. ObP: [  ] Oprogramowanie musi mieć możliwość generowania zestawień i raportów stanu kluczy na portierni, wypożyczonych kluczy

  9. ObP: [  ] Oprogramowanie musi mieć możliwość ustawienia filtrowania danych i zdarzeń

  10. ObP: [  ] Oprogramowanie musi mieć możliwość generowania Raportów dotyczących wszystkich zdarzeń zachodzących w systemie np. „zalogowanie”, „wylogowanie”

  11. ObP: [  ] Oprogramowanie musi posiadać raport zawierający listę kluczy z przyporządkowanymi nazwiskami pracowników, którzy aktualnie posiadają dostęp do danego klucza

  12. ObP: [  ] Oprogramowanie musi pozwalać na eksport wyników raportów do pliku CSV i PDF

  13. ObP: [  ] Oprogramowanie wydawania kluczy musi być zrealizowany w technologii klient serwer

  14. Dod: [  ] Oprogramowanie musi działać na tej samej bazie danych co System Personalizacji Kart funkcjonujący na Uczelni

  15. ObP: [  ] Oprogramowanie elektronicznego systemu autoryzowanego dostępu musi mieć interfejs zgodny z systemem Personalizacji Kart (w tym podobny układ graficzny i obsługę)

  16. 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.

  17. Dod: [  ] Oprogramowanie powinno posiadać możliwość importu struktury pomieszczeń z arkusza kalkulacyjnego.

  18. Dod: [  ] Oprogramowanie powinno posiadać możliwość importu uprawnień do pomieszczeń z arkusza kalkulacyjnego.

  19. Dod: [  ] Oprogramowanie powinno posiadać możliwość zapisu instrukcji obsługi do wypożyczanego  sprzętu na PENDRIVE

  20. Dod: [  ] Oprogramowanie powinno posiadać możliwość wyświetlania zdjęcia wypożyczanego sprzętu



z07 załącznik do SIWZ Elektroniczny system autoryzowanego dostępu oraz infrastruktura klucza publicznego platformy e-usług

str. z


©absta.pl 2016
wyślij wiadomość

    Strona główna