SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA

Transkrypt

1 SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA w postępowaniu o udzielenie zamówienia publicznego prowadzonym w trybie przetargu nieograniczonego na wykonanie projektu implementacji oraz przeprowadzenie migracji Centrum Certyfikacji Zakładu wydającego certyfikaty klucza publicznego na potrzeby wewnętrzne Zakładu Ubezpieczeń Społecznych oraz Kompleksowego Rozproszonego Systemu Bezpieczeństwa do systemu zarządzania tożsamością znak sprawy: TZ/370/55/11 Wartość zamówienia przekracza równowartość kwoty euro Warszawa, 2011 r.

2 SPIS TREŚCI ROZDZIAŁ I INFORMACJE OGÓLNE I. INFORMACJA O ZAMAWIAJĄCYM II. TRYB UDZIELENIA ZAMÓWIENIA I WARTOŚĆ ZAMÓWIENIA III. OFERTY CZĘŚCIOWE, WARIANTOWE. IV. FORMA PRZEKAZYWANIA INFORMACJI, OŚWIADCZEŃ I DOKUMENTÓW W POSTĘPOWANIU V. OSOBY UPRAWNIONE DO KONTAKTÓW Z WYKONAWCAMI VI. ZAMÓWIENIE UZUPEŁNIAJĄCE VII. INFORMACJE DODATKOWE ROZDZIAŁ II OPIS PRZEDMIOTU ZAMÓWIENIA I TERMIN WYKONANIA I. PRZEDMIOT ZAMÓWIENIA II. TERMIN I SPOSÓB WYKONANIA ZAMÓWIENIA, WARUNKI PŁATNOŚCI, GWARANCJA ROZDZIAŁ III WYSOKOŚĆ I ZASADY WNIESIENIA WADIUM I. WYSOKOŚĆ WADIUM II. FORMA WADIUM III. TERMIN I MIEJSCE WNIESIENIA WADIUM IV. ZWROT WADIUM V. ZATRZYMANIE WADIUM ROZDZIAŁ IV WARUNKI UDZIAŁU W POSTĘPOWANIU, OPIS SPEŁNIENIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU, OFERTA ORAZ DOKUMENTY WYMAGANE OD WYKONAWCY I. WARUNKI UDZIAŁU W POSTĘPOWANIU II. WYMOGI FORMALNE OFERTY III. WYMAGANE DOKUMENTY IV. ZASADY UDZIAŁU W POSTĘPOWANIU WYKONAWCÓW WYSTĘPUJĄCYCH WSPÓLNIE V. FORMA DOKUMENTÓW VI. OPAKOWANIE OFERTY VII. OPIS SPOSOBU DOKONYWANIA OCENY SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU ROZDZIAŁ V OPIS SPOSOBU OBLICZENIA CENY OFERTY ROZDZIAŁ VI INFORMACJE O MIEJSCU I TERMINIE SKŁADANIA I OTWARCIA OFERT I. MIEJSCE I TERMIN SKŁADANIA OFERT II. MIEJSCE I TERMIN OTWARCIA OFERT III. PUBLICZNE OTWARCIE OFERT IV. TERMIN ZWIĄZANIA OFERTĄ V. ZMIANA I WYCOFANIE OFERTY ROZDZIAŁ VII KRYTERIA I ZASADY OCENY OFERT I. TRYB OCENY OFERT II. KRYTERIA WYBORU NAJKORZYSTNIEJSZEJ OFERTY III. ZASADY OCENY OFERT WEDŁUG USTALONYCH KRYTERIÓW ROZDZIAŁ VIII ZABEZPIECZENIE NALEŻYTEGO WYKONANIA UMOWY ROZDZIAŁ IX WZÓR UMOWY ROZDZIAŁ X POUCZENIE O ŚRODKACH OCHRONY PRAWNEJ ROZDZIAŁ XI FORMALNOŚCI PO WYBORZE OFERTY W CELU ZAWARCIA UMOWY I. OGŁOSZENIE O WYNIKU POSTĘPOWANIA II. WARUNKI ZAWARCIA UMOWY ROZDZIAŁ XII ZMIANA UMOWY Znak sprawy: TZ/370/55/11 1

3 Rozdział I INFORMACJE OGÓLNE I. INFORMACJA O ZAMAWIAJĄCYM Zamawiającym jest Zakład Ubezpieczeń Społecznych z siedzibą w Warszawie ul. Szamocka 3, 5, Warszawa. Tel.: fax: , II. TRYB UDZIELENIA ZAMÓWIENIA I WARTOŚĆ ZAMÓWIENIA Postępowanie o udzielenie zamówienia publicznego prowadzone jest w trybie przetargu nieograniczonego na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2010 r. Nr 113, poz. 759 ze zm.). Wartość zamówienia: Wartość zamówienia przekracza wyrażoną w złotych równowartość kwoty euro, o której mowa w przepisach wydanych na podstawie art. 11 ust. 8 ustawy. III. OFERTY CZĘŚCIOWE, WARIANTOWE. 1. Każdy Wykonawca ma prawo złożyć tylko jedną ofertę. 2. Oferta musi obejmować całość przedmiotu zamówienia wskazanego w Rozdz.II SIWZ. 3. Zamawiający nie dopuszcza możliwości składania ofert częściowych. 4. Zamawiający nie dopuszcza możliwości składania ofert wariantowych w rozumieniu art. 2 pkt 7 ustawy. IV. FORMA PRZEKAZYWANIA INFORMACJI, OŚWIADCZEŃ I DOKUMENTÓW W POSTĘPOWANIU 1. Oświadczenia, wnioski, zawiadomienia oraz informacje Zamawiający i Wykonawcy przekazują faksem z uwzględnieniem ust Forma pisemna zastrzeżona jest dla złożenia oferty wraz z załącznikami (dotyczy również uzupełnienia oferty art. 26 ust. 3 ustawy), w tym oświadczeń i dokumentów potwierdzających spełnianie warunków udziału w postępowaniu oraz oświadczeń i dokumentów potwierdzających spełnianie przez oferowany przedmiot zamówienia wymagań określonych przez Zamawiającego, a także zmiany lub wycofania oferty. 3. Wykonawca potwierdza niezwłocznie fakt otrzymania oświadczenia, wniosku, zawiadomienia lub informacji poprzez podpisanie pierwszej strony dokumentu i jej odesłanie na faks Zamawiającego. 4. Jeżeli Wykonawca przekaże oświadczenia, wnioski, zawiadomienia oraz informacje faksem i pisemnie za datę ich złożenia przyjmuje się datę wpływu pierwszego dokumentu dokument uważa się za złożony w terminie, jeżeli jego treść dotarła do adresata przed upływem wyznaczonego terminu, z zastrzeżeniem ust. 2. 2

4 5. W przypadku wniesienia odwołania, odwołujący przesyła kopię odwołania Zamawiającemu za pomocą faksu wyłącznie na numer /36 lub drogą elektroniczną na adres bladoszm@zus.pl V. OSOBY UPRAWNIONE DO KONTAKTÓW Z WYKONAWCAMI Osobą uprawnioną do kontaktu z Wykonawcami jest: imię i nazwisko: Renata Łukasiewicz stanowisko służbowe: Główny specjalista tel.: faks: /36 godziny urzędowania: VI. ZAMÓWIENIE UZUPEŁNIAJĄCE Zamawiający nie przewiduje udzielenia zamówienia uzupełniającego na przedmiot zamówienia określony w Rozdziale II Specyfikacji. VII. INFORMACJE DODATKOWE 1. Postępowanie, którego dotyczy niniejszy dokument oznaczone jest znakiem: TZ/370/55/11. Wskazane jest, aby Wykonawcy we wszelkich kontaktach z Zamawiającym powoływali się na ten znak. 2. Istnieje możliwość uzyskania formularza oferty w wersji elektronicznej, pod warunkiem przekazania Zamawiającemu prośby wraz z podaniem adresu poczty elektronicznej ( ) Wykonawcy. Rozdział II OPIS PRZEDMIOTU ZAMÓWIENIA I TERMIN WYKONANIA I. PRZEDMIOT ZAMÓWIENIA Przedmiotem zamówienia jest wykonanie projektu implementacji oraz przeprowadzenie migracji Centrum Certyfikacji Zakładu wydającego certyfikaty klucza publicznego na potrzeby wewnętrzne Zakładu Ubezpieczeń Społecznych oraz Kompleksowego Rozproszonego Systemu Bezpieczeństwa do systemu zarządzania tożsamością wraz z przeniesieniem majątkowych praw autorskich do dokumentacji i wykonanego na potrzeby realizacji umowy oprogramowania lub udzieleniem licencji na gotowe oprogramowanie na czas nieokreślony. Przedmiot zamówienia zgodnie ze Wspólnym Słownikiem Zamówień (CPV): Usługi wdrażania oprogramowania Różne pakiety oprogramowania i systemy komputerowe 3

5 Słownik skrótów i pojęć Skrót/określenie aplikacje autorskie aplikacje interakcyjne baza operacyjna IdM Katalog Korporacyjny KRSB Oprogramowanie dedykowane repozytorium IdM SAP SPB ZUS, SPB SSO SWEZ Objaśnienie W rozumieniu używanym w Zakładzie są to aplikacje wytworzone wewnętrznie spełniające funkcje pomocnicze. Nie wykorzystują zasobów przeznaczonych dla aplikacji interakcyjnych i stosowane są opcjonalnie w TJO Zakładu. Mogą być zintegrowane z KRSB w architekturze dwuwarstwowej lub nie zintegrowane z KRSB. Aplikacje wytworzone dla ZUS przez firmę Asseco-Prokom dla realizacji podstawowych zadań statutowych Zakładu, zintegrowane z KRSB i działające w architekturze trójwarstwowej (klient aplikacyjny-tuxedo-serwer aplikacji). Pojęcie określające przeznaczenie bazy (lub katalogu) jako biorącej udział on-line w świadczeniu usług uwierzytelniania i autoryzacji. Takim pojęciem można określić przeznaczenie Katalogu Korporacyjnego Identity Management - potoczny skrót dla całej grupy oprogramowania różnych producentów służącego do kompleksowego zarządzania tożsamością. Katalog LDAP oparty na Sun Java System Directory Server zawierający dane o użytkownikach i ich uprawnieniach w aplikacjach interakcyjnych i autorskich odwzorowujący strukturę organizacyjną Zakładu. Posiada własną infrastrukturę sprzętowoprogramową centralną i oddziałową. Jest bazą operacyjną dla KRSB. Kompleksowy Rozproszony System Bezpieczeństwa jego bazą operacyjną jest Katalog Korporacyjny Oprogramowanie wytworzone przez Wykonawcę Umowy na potrzeby Zamawiającego uzupełniające funkcjonalność wdrażanego systemu IdM. baza, katalog specyficzny dla danego IdM, w którym przechowuje wszystkie dane niezbędne dla realizacji swojej funkcjonalności, nie będący w większości rozwiązań IdM bazą operacyjną. SAP ECC 6.0 (Systems Applications and Products in Data Processing). System Pocztowo-Biurowy ZUS, oparty na platformie Windows Server 2003 Enterprise Edition/2008 Enterprise Edition R2, Active Directory. SSO (ang. Single Sign-On) system jednokrotnego logowania, umożliwiający zalogowanemu użytkownikowi dostęp do wielu powiązanych, ale niezależnych systemów informatycznych. System Wspomagania Ekonomiki Zakładu zbudowany w oparciu o 4

6 TJO użytkownik końcowy IdM Zakład SAP. Terenowa Jednostka Organizacyjna Zakładu (Oddział ZUS, Inspektorat ZUS, Biuro Terenowe ZUS). Użytkownik biorący udział w zarządzaniu tożsamością (wnioskowanie, akceptacja, kontrola, audyt). Zakład Ubezpieczeń Społecznych. A. Zakres przedmiotu zamówienia Przedmiot zamówienia obejmuje: 1. Projekt implementacji systemu zarządzania tożsamością, który musi zawierać: 1) W części dotyczącej IdM: a) Strukturę rozwiązania oraz specyfikację proponowanego sprzętu. b) Rodzaj dostarczonego oprogramowania wraz z opisem funkcji, jakie będą za jego pośrednictwem wykonywane. c) Propozycje procedur wnioskowania i obiegu dokumentów związanych z obsługą użytkowników korzystających z systemu IdM, w tym m.in.: - zatrudnienie pracownika, - zwolnienie pracownika, - zawieszenie tożsamości, - zmiana uprawnień użytkownika. d) Harmonogram realizacji projektu implementacji (dostarczenie sprzętu, uruchomienie systemu IdM, dostarczenie kart elektronicznych, testy). e) Zestaw scenariuszy testów akceptacyjnych, przygotowanych z udziałem Zamawiającego. Testy muszą obejmować pełny zakres funkcjonalny systemu IdM wraz z wykorzystaniem infrastruktury technicznej. f) Procedury/testy do badania poprawności funkcjonowania systemu IdM w okresie gwarancji. 2) W części dotyczącej Centrum Certyfikacji: a) Strukturę sieci Centrum Certyfikacji oraz specyfikację proponowanego sprzętu. b) Wykaz rodzajów kart elektronicznych (które zostaną dostarczone przez Wykonawcę) i ich systemów operacyjnych obsługiwanych przez Centrum Certyfikacji. Podstawowymi kryteriami wyboru kart powinny być cena, powszechność wykorzystania, dostępność wybranych kart na rynku, pochodzenie od różnych producentów, minimalizacja czynności w procesie wdrażania oraz jak najpełniejsza integracja ze środowiskiem systemowym dostarczonego rozwiązania. Liczba obsługiwanych rodzajów kart nie powinna być mniejsza niż 3, przy czym karty posiadające tę samą linię procesorów, systemów operacyjnych, a różniące się wielkością pamięci wewnętrznej, zegarem procesora lub prędkością transmisji nie będą traktowane jako inny rodzaj. 5

7 c) Opis Firewalla oraz jego proponowaną konfigurację (jeżeli będzie dostarczany). d) Rodzaj dostarczonego oprogramowania wraz z opisem funkcji, jakie będą za jego pośrednictwem wykonywane. e) Procedury generowania, przechowywania i dostępu do klucza prywatnego Root CA. f) Propozycje zawartości polityk i kodeksu postępowania certyfikacyjnego. g) Propozycje procedur wnioskowania i obiegu dokumentów związanych z obsługą użytkowników korzystających z PKI. h) Harmonogram realizacji Projektu implementacji (dostarczenie sprzętu, uruchomienie Centrum Certyfikacji, testy). i) Zestaw scenariuszy testów akceptacyjnych, przygotowanych z udziałem Zamawiającego. Testy muszą obejmować pełny zakres funkcjonalny Centrum Certyfikacji wraz z wykorzystaniem infrastruktury technicznej. j) Procedury/testy do badania poprawności funkcjonowania Centrum Certyfikacji w okresie gwarancji. 3) W części dotyczącej SSO: a) Specyfikację proponowanego sprzętu, b) Rodzaj dostarczonego oprogramowania wraz z opisem funkcji, jakie będą za jego pośrednictwem wykonywane. c) Propozycję integracji systemu SSO z Active Directory oraz innymi kluczowymi systemami informatycznymi użytkowanymi przez Zamawiającego d) Harmonogram realizacji Projektu implementacji (dostarczenie sprzętu, uruchomienie SSO, testy). e) Zestaw scenariuszy testów akceptacyjnych, przygotowanych z udziałem Zamawiającego. Testy muszą obejmować pełny zakres funkcjonalny SSO wraz z wykorzystaniem infrastruktury technicznej. f) Procedury/testy do badania poprawności funkcjonowania systemu SSO w okresie gwarancji. 2. Dostarczenie sprzętu i oprogramowania systemów IdM, CC i SSO zgodnie z harmonogramem realizacji projektu implementacji, przy czym: 1) Wykonawca zapewni licencje na całość dostarczonego oprogramowania. 2) Wykonawca dostarczy materiały eksploatacyjne dla dostarczonych urządzeń w ilości zapewniającej wykonanie personalizacji wszystkich dostarczonych kart elektronicznych. 3) Wykonawca zapewni wsparcie (support) na dostarczony sprzęt i oprogramowanie przez okres 36 miesięcy od dnia odbioru systemu. 4) Wykonawca udzieli gwarancji na wszystkie dostarczone elementy systemu przez okres 36 miesięcy od dnia odbioru systemu. 3. Uruchomienie systemów IdM, CC i SSO: 6

8 1) Uruchomienie systemów IdM, CC i SSO zostanie przeprowadzone przez Wykonawcę na podstawie dostarczonej dokumentacji projektowej i w odpowiednich wersjach instalacyjnych, z udziałem przedstawicieli Zamawiającego. 2) Sprawdzenie poprawności procedur administracyjnych w szczególności wykonanie backupów systemów operacyjnych oraz oprogramowania wszystkich serwerów i stacji składających się na strukturę IdM, CC i SSO, a następnie odtworzenie z nich w pełni funkcjonalnych środowisk. Wykonawca może wykorzystać istniejące u Zamawiającego systemy do tworzenia kopii zapasowych. 3) Wykonanie do IdM migracji kont i uprawnień z Katalogu Korporacyjnego KRSB, SWEZ oraz pozostałych integrowanych z IdM platform i systemów. 4) Dostarczenie kart elektronicznych dla użytkowników - Wykonawca dostarczy karty elektroniczne w ilości po 20 szt. z każdego rodzaju (określonego w projekcie implementacji), które będą testowane przez Zamawiającego podczas odbioru Centrum Certyfikacji. Do każdego typu kart Zamawiający dostarczy oprogramowanie CSP (Cryptographic Service Provider) o ile jest ono potrzebne dla stacji w Punktach Rejestracji. Ponadto Wykonawca dostarczy szt. kart elektronicznych jednego typu spośród modeli zaakceptowanych przez Zamawiającego wraz z oprogramowaniem CSP o ile jest ono niezbędne. 4. Dokumentacja powykonawcza systemu IdM, CC i SSO: 1) Opis finalnej konfiguracji serwerów, stacji roboczych, urządzeń sieciowych. 2) Zestaw procedur i podręczników dla środowiska operacyjnego i środowiska zapasowego zgodnie z zasadą rozdzielenia czynności administracyjnych (zarządzanie serwerami i stacjami roboczymi) od operacyjnych (nadawanie uprawnień), w tym: a) podręczniki administratora dla serwerów systemu IdM, b) podręczniki administratora dla stacji roboczych systemu IdM, c) procedury wykonywania backupu serwerów i stacji roboczych systemu IdM. d) podręczniki administratora dla serwerów Centrum Certyfikacji (dla Poziomu 1 i 2), e) procedurę generowania, przechowywania i dostępu do klucza prywatnego Root CA (dla Poziomu 1), f) podręczniki administratora dla stacji roboczych Centrum Certyfikacji (dla Poziomu 2), g) podręczniki użytkownika stacji roboczych Centrum Certyfikacji (dla Poziomu 2), zawierające opis czynności operacyjnych/operatorskich związanych z produkcją certyfikatów i kart), h) procedury wykonywania kopii zapasowej (backup) serwerów i stacji roboczych Centrum Certyfikacji (dla Poziomu 1 i 2) i) procedury odtworzenia z kopii zapasowej (backup), procedury planowania odnawiania głównego i podrzędnych urzędów certyfikacji, j) podręczniki administratora dla serwerów systemu SSO, k) podręczniki użytkownika stacji roboczych SSO. 7

9 l) procedury wykonywania backupu serwerów systemu SSO. 3) Polityki Certyfikacji. 4) Kodeks postępowania certyfikacyjnego. 5. Dostarczenie dokumentacji Planów Ciągłości Działania Systemu i Planów Odtwarzania po katastrofie Systemu, w skład których wejdą: 1) Plan ciągłości działania: a) definicja wymagań funkcjonalnych, b) analiza wpływu zdarzeń (ang. - Business Impact Analysis - BIA), c) definicja wymagań przetwarzania danych - katalog procesów i aplikacji objętych projektem planu odtwarzania z określeniem ich parametrów odtwarzania po katastrofach (w oparciu o wyniki BIA), d) opis strategii przetrwania, e) plan pierwszej reakcji na zdarzenie (zarządzanie incydentami), f) program szkoleń i budowania świadomości pracowników, g) plan i procedury audytu, h) plan aktualizacji i testowania planu ciągłości działania, i) plan komunikacji kryzysowej, j) plan koordynacji działań ze służbami utrzymania. 2) Plan Odtwarzania po katastrofie: a) schemat organizacyjny i procesy odtwarzania po katastrofach, b) scenariusze i procedury działania w przypadku katastrofy, c) procedury przełączenia na ośrodek zapasowy, d) procedury powrotu do ośrodka operacyjnego. 6. Dostarczenie dokumentacji planów i procedur audytu bezpieczeństwa, które będą mogły być wykorzystane przez Zamawiającego w celu przeprowadzania wewnętrznych audytów bezpieczeństwa. Plany i procedury audytu bezpieczeństwa obejmą w szczególności: 1) audyt infrastruktury techniczno-systemowej, na której będą uruchomione moduły Systemu, 2) audyt uprawnień, uwierzytelniania i autoryzacji użytkowników, 3) przeprowadzenie testów penetracyjnych Systemu. 7. Opracowanie i implementacja systemu monitorowania podatności. 8. Przeprowadzenie przeszkolenia przystanowiskowego dla pracowników obsługujących dostarczone rozwiązanie w zakresie wszystkich modułów wchodzących w jego skład. 8

10 B. Wymagania funkcjonalne System zarządzania tożsamością oparty będzie o oprogramowanie systemowe IdM, w którym weryfikacja tożsamości elektronicznej użytkownika realizowana będzie przy pomocy certyfikatu zapisanego na karcie elektronicznej (służącej do logowania do systemu operacyjnego MS Windows XP, Windows Vista, Windows 7) lub w pliku, generowanego w Centrum Certyfikacji. 1. Wymagania ogólne oraz oczekiwana funkcjonalność systemu zarządzania tożsamością 1) System zarządzania tożsamością musi posiadać architekturę uwzględniającą strukturę organizacyjną Zakładu, który składa się z 44 równorzędnych oddziałów oraz jednostki nadrzędnej Centrali. Oddziałowi Zakładu podlegają inspektoraty i biura terenowe skupione terytorialnie wokół siedzib oddziałów. 2) System zarządzania tożsamością musi posiadać możliwość rozbudowy o kolejne oddziały lub redukcji w przypadku likwidacji kilku z nich. 3) System zarządzania tożsamością musi uwzględniać fakt, że nadawanie uprawnień użytkownikom, tzn. wnioskowanie, zatwierdzanie oraz wykonanie jest realizowane na szczeblu oddziału, ponieważ oddziały Zakładu posiadają autonomię w zakresie zarządzania zasobami KSI. 4) Centralnemu zarządzaniu podlegają jedynie nieliczne aplikacje interakcyjne, system SWEZ (wszystkie uprawnienia oprócz uprawnień do szkoleń elektronicznych nadawane są centralnie), zasoby centralne (platformy systemowe, bazy centralne na serwerach UNIX i Mainframe) oraz administrowanie systemem pocztowo-biurowym opartym na platformie systemowej Windows Server 2003 Enterprise Edition /2008 Enterprise Edition R2 oraz Exchange ) Stan obecny zarządzania uprawnieniami w Zakładzie przedstawiony został ogólnie na Rys.1. Uprawnienia użytkowników aplikacji interakcyjnych KSI są umieszczone w katalogu korporacyjnym. Pozostałe systemy posiadają własne moduły autoryzacji, zarządzania (L1, L2, L3, L4). 6) Docelową strukturę IdM, która obejmie zarządzaniem aplikacje interakcyjne KSI, autorskie oraz inne systemy aplikacyjne i systemowo narzędziowe eksploatowane w Zakładzie, nieobjęte dotychczas przez KRSB przedstawia Rys. 2. 9

11 Rysunek 1. Aktualny stan zarządzania elementami KSI Rysunek 2. Docelowy stan zarządzania elementami KSI przez IdM. 10

12 7) Zamawiający oczekuje w chwili obecnej utrzymania Katalogu Korporacyjnego, jako bazy operacyjnej dla aplikacji interakcyjnych KSI oraz uwzględnienia migracji tej bazy do Active Directory lub innego rozwiązania w przyszłości. Natomiast wdrażany system zarządzania tożsamością powinien posiadać własną bazę - repozytorium wszystkich uprawnień użytkowników zarówno aplikacji zintegrowanych z KRSB jak i aplikacji i systemów obecnie nie zintegrowanych z KRSB. Zamawiający dopuszcza ewentualność innej koncepcji w tym zakresie, którą Wykonawca powinien przedstawić do akceptacji w trakcie tworzenia projektu implementacji. 2. Wymagania szczegółowe dla systemu zarządzania tożsamością. System zarządzania tożsamością musi: 1) umożliwiać stworzenie głównego punktu zakładania kont, nadawania, modyfikacji, odbierania uprawnień do systemów poprzez scentralizowanie procesu zarządzania tożsamością i uprawnieniami, 2) umożliwiać podzielenie scentralizowanego systemu zarządzania tożsamością na odpowiednią ilość gałęzi (określoną ilość oddziałów Zakładu) i delegowanie odpowiednich uprawnień administracyjnych w te miejsca, system powinien graficznie prezentować strukturę organizacyjną, 3) posiadać centralne repozytorium informacji o użytkownikach, kontach, profilach i uprawnieniach, 4) zapewniać bezpieczne przechowywanie i przetwarzanie informacji o użytkownikach, kontach, profilach i uprawnieniach, 5) posiadać informacje o wszystkich istniejących w infrastrukturze kontach, 6) obejmować zarządzaniem wszystkie konta istniejące w infrastrukturze (konta użytkowników, administratorów oraz konta techniczne), 7) posiadać mechanizm raportowania systemu zarządzania tożsamością, który w sposób elastyczny pozwoli na budowanie raportów (dostosowanych do potrzeb różnych grup odbiorców) na podstawie zebranych danych dostępnych w rozwiązaniu, 8) mechanizm raportowania powinien pozwalać na automatyczne i okresowe tworzenie raportów oraz na automatyczną dystrybucję raportów do wskazanych osób lub grup, 9) umożliwiać zarządzanie kontami w całym cyklu życia kont (od tworzenia konta poprzez jego modyfikacje aż do momentu jego usunięcia lub zablokowania), 10) umożliwiać częściowe oddelegowanie zarządzania tożsamością w kierunku użytkowników, 11) zapewniać unikalne ID dla użytkowników końcowych, 12) zapewniać możliwość delegowania uprawnień zgodnie z zakresem czynności delegowanych (a nie wszystkich uprawnień, które w danym momencie osoba delegująca posiada), 13) niezależnie od rozproszenia być zarządzany oraz obsługiwany z dowolnej lokalizacji, 14) zapewniać konsolę administracyjną, z poziomu której można wykonywać wszystkie czynności związane z zarządzaniem tożsamością, 11

13 15) zapewniać konsolę dla użytkowników końcowych w języku polskim, 16) umożliwiać obsługę konsoli użytkownika z poziomu popularnych przeglądarek - co najmniej Microsoft Internet Explorer od wersji 7.0. (ze względu na to, że jest to jedyna przeglądarka użytkowana przez Zamawiającego), 17) posiadać możliwość skalowania interfejsu graficznego aplikacji do rozdzielczości ustawionej na komputerze użytkownika, pozwalając na optymalne wykorzystanie obszaru roboczego okna aplikacji (powszechnie wykorzystywana obecnie w ZUS rozdzielczość ekranu to 1280x1024), 18) posiadać wewnętrzny mechanizm kontroli dostępu służący nadawaniu indywidualnych uprawnień w zakresie zarządzania tożsamością różnym typom i poziomom użytkowników administrujących zabezpieczeniami, 19) zintegrować centralne repozytorium informacji z następującymi systemami: a) Windows Server 2008 Enterprise Edition R2, b) Windows Server 2003 Enterprise Edition, c) ISA server Std Ed 2004 English MVL 1 Proc, d) Active Directory, e) Microsoft Exchange 2010, f) Sun Solaris 9, g) HP UX 11.31, h) AIX 5.3, i) AIX 6.1, j) SQL Server Standard Edition 2005 English Intl MVL, k) Informix 11.10, l) DB2 wersja 9, m) baza LDAP na SUN Java System Directory Server v.5.2 (Katalog Korporacyjny), n) podsystem zarządzania uprawnieniami RACF na Mainframe (z/os 1.12), o) SAP ECC 6.0. z modułami: FI AA zarządzanie majątkiem trwałym, MM gospodarka materiałowa (z zaopatrzeniem), SD sprzedaż (z fakturowaniem), HR kadry, HR płace, FI rachunkowość finansowa, CO kontroling, TR zarządzanie płynnością finansową, SEM strategiczne zarządzanie organizacją, 12

14 BW hurtownia danych (sprawozdawczość), BASIS administracja, technologia informatyczna, LSO szkolenia elektroniczne, SM solution manager (narzędzie administratorskie). 20) umożliwiać objęcie zarządzaniem minimum użytkowników, przy czym: a) użytkowników aplikacji KSI umieszczanych w Katalogu Korporacyjnym przez stosowny interfejs. b) użytkowników pracujących w SWEZ (w tym około posiadających uprawnienia tylko do szkoleń elektronicznych) spośród istniejących w katalogu korporacyjnym, których uprawnienia w poszczególnych modułach SWEZ zarządzane będą poprzez IdM. W chwili obecnej nadawanie uprawnień do SWEZ jest częściowo zautomatyzowane przy pomocy aplikacji E-KARTA (dostępną przez przeglądarkę internetową), z której informacje są replikowane do systemu SAP i automatycznie po zatwierdzeniu przypisywane do kont użytkowników. Istnieją również użytkownicy posługujący się wieloma kontami w SWEZ. 21) umożliwiać objęcie zarządzaniem cykl życia kart i certyfikatów wytworzonych przez Centrum Certyfikacji (obsługa tworzenia, importowania, eksportu, przechowywania, sprawdzania oraz odwoływania certyfikatów elektronicznych). 22) system powinien pracować jako klaster kilku serwerów (lub maszyn wirtualnych), przy czym awaria sprzętu / oprogramowania na jednym serwerze nie spowoduje przerwania działania usług IdM, SSO oraz CC, ponieważ usługi zostaną przeniesione na inne węzły wchodzące w skład klastra. 3. Wymagania w zakresie zarządzania użytkownikami System zarządzania tożsamością musi: 1) zapewniać jednoznaczną identyfikację użytkowników na podstawie ich ID, 2) zapewniać możliwość synchronizacji danych o użytkownikach zawartych w różnych repozytoriach danych, w tym co najmniej: a) Sun Java System Directory Server, b) Active Directory, c) SAP ECC ) zapewniać tworzenie kont użytkowników na podstawie zdarzeń np. po pojawieniu się nowego wpisu w bazie HR, nowej grupy, nowego uprawnienia w systemie lub cyklicznym pobieraniu informacji o takich zdarzeniach. 4) posiadać mechanizmy masowej migracji kont i uprawnień użytkowników z innych systemów, wymienionych w Rozdziale 2.2 pkt 19. 5) zapewniać automatyczne konfigurowanie kont, 13

15 6) umożliwiać tworzenie profili użytkowników pełniących określone role w firmie i wiązanie tych profili z odpowiednimi uprawnieniami, 7) zapewniać możliwość dopisania nowych użytkowników do profili użytkowników (budowanie grup użytkowników o tych samych uprawnieniach), 8) posiadać szablony profili dostępu ułatwiające tworzenie i modyfikowanie kont i powiązanych z nimi prawami dostępu, 9) zapewniać możliwość nadawania uprawnień na podstawie dowolnych atrybutów użytkownika np. lokalizacji, stanowiska czy też działu, 10) zapewniać możliwość definiowania ról wzajemnie się wykluczających oraz automatycznie informować użytkowników o wykluczających się rolach przy akceptacji lub nadawaniu ról użytkownikowi, 11) zapewniać automatyczną aktualizację uprawnień wszystkich osób związanych z danym profilem, na którym dokonywane są zmiany, 12) posiadać możliwość porównywania informacji o kontach z informacją o zatrudnionych pracownikach pochodzących np. z systemu kadrowego lub innych systemów zawierających informację o pracownikach, kontraktorach czy osobach trzecich, 13) zapewniać możliwość oddelegowania zarządzania tożsamością w kierunku użytkownika końcowego. Użytkownik końcowy musi posiadać możliwość zarządzania własną tożsamością w co najmniej następujących obszarach: występowanie o nowe konto, zmianę profilu, resetowanie hasła i propagowanie zmiany hasła do systemów w których istnieją konta użytkownika, 14) przechowywać informację o tym, ile, gdzie oraz jakie konta zostały założone dla danej tożsamości. 4. Wymagania w zakresie zarządzania hasłami i uprawnieniami W zakresie zarządzania hasłami i uprawnieniami system zarządzania tożsamością musi: 1) zapewniać konfigurowalny mechanizm wnioskowania, aprobowania, który skraca czas wykonania żądania w razie niedostępności osób wnioskujących lub aprobujących wnioski, 2) zapewniać okresowy przegląd tożsamości i ich uprawnień oraz porównywanie tego stanu ze stanem wymaganym, wynikającym z formalnie zaakceptowanych wniosków o dostęp. Fakt przeprowadzenia takiego przeglądu powinien być odnotowany i możliwy do raportowania, 3) sprawdzać, z ustaloną dla każdego podłączonego systemu częstotliwością lub w czasie rzeczywistym, czy nie zostało założone lub zmodyfikowane konto z pominięciem systemu zarządzania tożsamością (np. ręcznie przez administratora). W przypadku wykrycia takiego zdarzenia system powinien podejmować zdefiniowane akcje (np. przywrócenie stanu wyjściowego, blokowanie konta, informowanie określonych osób itp.), 4) posiadać możliwość zdefiniowania podejmowanych automatycznie działań w przypadku wykrycia naruszeń w uprawnieniach poszczególnych tożsamości (np. eskalacje do przełożonego, automatyczne zablokowanie kont, powiadomienie wyznaczonych osób funkcyjnych itp.), 14

16 5) umożliwiać nadawanie uprawnień na ustalony okres czasu oraz w ustalonym terminie przed upływem tego okresu automatycznie informować zdefiniowane osoby o zbliżającym się wycofaniu uprawnień, 6) posiadać możliwość wykonania procesu aktualizacji danych użytkownika w przypadku, gdy zmieni on rolę zawodową, komórkę organizacyjną, w której pracuje lub dane personalne, 7) umożliwiać konfigurowanie ścieżek wnioskowania i akceptacji wniosków na podstawie określonych kryteriów za pomocą środowiska graficznego, 8) udostępniać użytkownikom końcowym funkcję samoobsługowego resetowania i zmiany haseł do podłączonych do systemu IdM aplikacji poprzez interfejs webowy, 5. Wymagania w zakresie audytu, raportowania i archiwizacji zdarzeń W zakresie audytu, raportowania i archiwizacji zdarzeń system zarządzania tożsamością musi: 1) przechowywać i udostępniać uprawnionym użytkownikom dostęp do wszystkich informacji: a) niezbędnych do jednoznacznego zidentyfikowania użytkownika, b) niezbędnych do określenia uprawnień wskazanej tożsamości, c) niezbędnych do analizy historii zmian uprawnień, 2) logować zdarzenia dotyczące procesu zarządzania uprawnieniami w systemach objętych zarządzaniem tożsamością, 3) logować zdarzenia związane z dodawaniem lub modyfikacją lub też usuwaniem tożsamości, 4) logować wszelkie różnice pomiędzy kontami istniejącymi w systemach objętych zarządzaniem tożsamością, założonymi poza IdM, a kontami formalnie założonymi za pomocą IdM, 5) zapewniać możliwość automatycznego wykonywania raportu z przeglądu kont, na które nikt się od dłuższego czasu nie logował, tzw. uśpionych kont w systemach, możliwość ich automatycznej blokady i powiadomienia o tym fakcie zdefiniowaną grupę użytkowników, 6) zapewniać możliwość automatycznego wykonywania raportu z przeglądu kont bez przypisanej tożsamości, tzw. osieroconych kont w systemach, 7) posiadać możliwość generowania raportów na żądanie, 8) posiadać możliwość generowania raportów według określonego harmonogramu, 9) zapewniać możliwość podawania parametrów dotyczących generowania raportów (np. zakres dat, zakres użytkowników), 10) Posiadać możliwość generowania co najmniej następujących raportów: a) lista użytkowników, b) lista systemów, c) lista profili użytkowników (pełnionych przez użytkownika ról w przedsiębiorstwie), d) lista uprawnień wskazanych tożsamości, e) lista tożsamości wskazanych uprawnień, 15

17 f) zdarzenia dotyczące procesów (np. kto wystąpił z wnioskiem o konto, kto zatwierdził itp.), g) historia zmian na kontach, 11) Wszystkie raporty muszą być w języku polskim, 12) Wszystkie raporty muszą mieć możliwość eksportu do różnych formatów m.in. CSV, PDF, HTML, XML, 13) Wszelkie modyfikacje procesów związanych z zarządzaniem tożsamością powinny być logowane. 6. Wymagania w zakresie bezpieczeństwa Oferowany system zarządzania tożsamością w zakresie bezpieczeństwa powinien zapewniać ochronę przesyłanych informacji pomiędzy współpracującymi komponentami. 7. Wymagania dla elektronicznego obiegu wniosków związanych z zarządzaniem uprawnieniami W zakresie elektronicznego obiegu wniosków związanych z zarządzaniem uprawnieniami, system zarządzania tożsamością musi spełniać następujące wymagania: 1) umożliwiać tworzenie procesów (w sposób graficzny) związanych z zarządzaniem tożsamością, w szczególności tworzenia wniosków o dostęp do zasobu, obsługi wniosku o zmianę profilu użytkownika, obsługę wniosku o zmianę uprawnień na danym zasobie/do danej aplikacji, 2) zapewniać nadawanie lub modyfikowanie dostępów do obiektów dla tożsamości, które musi się odbywać wyłącznie na podstawie zaakceptowanych zgodnie z ustaloną procedurą wniosków, 3) umożliwiać delegowanie zadań związanych z akceptacją wniosków, w zakresie zdefiniowanym podczas tworzenia procesu; delegowanie nie powinno obejmować wszystkich uprawnień osoby delegującej, a tylko i wyłącznie takie uprawnienie, które jest przedmiotem delegowania, 4) umożliwiać akceptowanie wniosków na poziomie konkretnego użytkownika lub na poziomie zdefiniowanej grupy użytkowników, 5) umożliwiać kilkuetapowe zatwierdzanie, realizację wniosków, przez odpowiednie delegowane do tych czynności osoby (przykładowo począwszy od bezpośredniego przełożonego, administratora bezpieczeństwa informacji, dyrektora oddziału Zakładu, dyrektora komórki organizacyjnej Centrali, kończąc na osobie potwierdzającej realizację wniosku), 6) zawierać mechanizmy powiadamiania użytkowników bądź ich przełożonych o statusie wykonania ich wniosków. W szczególności czy wnioski te zakończyły się powodzeniem czy też niepowodzeniem, 7) umożliwiać obsługę systemu obiegu wniosków poprzez przeglądarkę internetową (protokół HTTPS), 16

18 8) zawierać funkcje raportowe umożliwiające śledzenie historii procesu żądania i zatwierdzania wniosków dla każdego użytkownika końcowego. 8. Wymagania na środowisko sprzętowo-programowe dla IdM 1) Zamawiający wymaga dwóch środowisk dla wdrażanego systemu zarządzania tożsamościąśrodowiska operacyjnego i środowiska zapasowego. 2) infrastruktura zapasowa przeznaczona będzie do wznowienia usług systemu IdM w wypadku całkowitego zniszczenia środowiska operacyjnego (pożar, powódź lub inne zdarzenie) i będzie umieszczona fizycznie w innej lokalizacji. Powinna ona zapewniać identyczną funkcjonalność i wydajność. Zamawiający dopuszcza minimalizację infrastruktury IdM zapasowej poprzez pominięcie elementów niezawodnościowych. 3) Wykonawca dla implementacji systemu IdM może zaproponować i dostarczyć sprzęt zapewniający prawidłowe jego funkcjonowanie lub wykorzystać środowisko VMware posiadane przez Zamawiającego do zainstalowania w nim, wymaganych przez projekt, serwerów IdM. Platforma sprzętowa powinna zapewniać rozwiązania klastrowe serwerów i konfigurację macierzy dyskowych (Zamawiający posiada środowisko i licencje na wymienione oprogramowanie i nie jest ono przedmiotem tego postępowania). 4) System musi integrować się z obecnie stosowanym w Zakładzie standardem monitorowania opartym o narzędzia BMC. 5) Ponadto Wykonawca musi dostarczyć system monitorowania podatności infrastruktury sytemu zarządzania tożsamością spełniający następujące wymagania: a) System musi umożliwiać wykrywanie podatności zasobów wchodzących w skład dostarczonego systemu zarządzania tożsamością. b) System musi skanować zdefiniowane zasoby pod kątem wykrywania podatności. c) System musi umożliwiać skanowanie zasobów w trybie sieciowym (bez lokalnego agenta). d) System musi przeprowadzać operację skanowania w poszukiwaniu podatności tylko dla architektury skanowanego systemu: np. na platformie MS Windows tylko słabości dotyczące tej platformy. e) System musi być w automatyczny sposób zasilany informacjami o nowych podatnościach. f) Skalowalność systemu musi być zapewniona dla dowolnej wielkości sieci. g) System musi umożliwiać elastyczne definiowanie zadań skanowania w taki sposób, aby nie występowały zakłócenia normalnej pracy sieci. h) System musi umożliwiać przeprowadzenie zadań wykrywania podatności zgodnie ze zdefiniowanym harmonogramem, lub na żądanie administratora. i) System musi przedstawiać dane o wynikach skanowania w formie raportów z wyszczególnieniem podatności krytycznych oraz rekomendacjami usunięcia wykrytych podatności. 17

19 j) System musi umożliwiać eksport raportów do różnych formatów m.in. CSV, PDF, HTML, XML 9. Wymagania szczegółowe dla Centrum Certyfikacji 1) Centrum Certyfikacji będzie miało za zadanie wydawanie certyfikatów niekwalifikowanych, co najmniej do następujących zastosowań: uwierzytelnianie użytkowników końcowych, uwierzytelnianie serwerów, zabezpieczenia transmisji, zabezpieczenia danych przechowywanych lokalnie, tworzenia podpisów elektronicznych, 2) Centrum Certyfikacji obsługiwać będzie system KSI ZUS, 3) Centrum Certyfikacji musi być zbudowane w oparciu o hierarchię urzędów certyfikacji, 4) Centrum Certyfikacji musi zapewniać rozbudowę hierarchii urzędów certyfikacji i bezpieczne podłączenie, w sumie do 20 urzędów certyfikacji, które mogą być ustanawiane w przyszłości dla różnych rodzajów grup użytkowników KSI ZUS. 5) Centrum Certyfikacji powinno umożliwiać wydawanie certyfikatów za pośrednictwem Punktów Rejestracji. Oczekiwane jest stworzenie jednego Centralnego Punktu Rejestracji zlokalizowanego w Centrali Zakładu oraz 44 Oddziałowych Punktów Rejestracji zlokalizowanych w poszczególnych Oddziałach Zakładu. 6) W Centralnym Punkcie Rejestracji w Centrali Zakładu będzie odbywała się pełna personalizacja karty elektronicznej (łącznie z personalizacją graficzną). 7) W Oddziałowych Punktach Rejestracji przeprowadzana będzie jedynie personalizacja elektroniczna kart (wymiana kluczy na karcie). Karty będą identyfikowane według wcześniej wykonanej personalizacji w Centralnym Punkcie Rejestracji. 8) Komunikacja Punktu Rejestracji z Centrum Certyfikacji musi odbywać za pośrednictwem oprogramowania do zarządzania cyklem życia kart oraz rozproszonej obsługi użytkowników. 9) Wykonawca dostarczy narzędzia i procedury zapewniające możliwość poprawnego odtworzenia Centrum Certyfikacji po awarii bez utraty informacji o wydanych certyfikatach, w szczególności musi być możliwe unieważnienie certyfikatów wydanych po wykonaniu ostatniej kopii zapasowej serwera, na którym uruchomione jest Centrum Certyfikacji. 10) Wymagania szczegółowe dla oprogramowania Centrum Certyfikacji: a) Użytkownik musi posiadać możliwość sprawdzenia z użytkowanej stacji podstawowych danych o swoim certyfikacie (właściciel, okres ważności, numer seryjny, itp.) np. poprzez interfejs przeglądarki www. Przedstawiane informacje mają dotyczyć certyfikatu znajdującego się na karcie elektronicznej lub w pliku, jak również certyfikatu znajdującego się w Active Directory. b) Użytkownik musi posiadać możliwość odnowienia z użytkowanej stacji swojego certyfikatu przed upływem jego ważności. c) Użytkownik musi posiadać możliwość samodzielnej obsługi sytuacji, gdy zapomni PIN lub odwracalnie zablokuje kartę elektroniczną. d) Listy certyfikatów unieważnionych (ang. Certificate Revocation List) publikowane będą w następujących lokalizacjach: 18

20 katalogu Active Directory dostęp za pośrednictwem protokołu LDAP, dedykowanej witrynie intranetowej dostęp za pośrednictwem bezpiecznego protokołu, katalogu korporacyjnym KRSB. e) Certyfikaty generowane w Centrum Certyfikacji muszą być automatycznie publikowane do katalogu korporacyjnego KRSB oraz Active Directory. f) Certyfikaty generowane muszą być zgodne ze standardem X.509 v.3, z użyciem algorytmów RSA i DSA: g) asymetrycznych: RSA (długość kluczy do b), DSA (długość kluczy do 1024b), h) funkcji skrótu: SHA 1, MD4, MD5. i) Oprogramowanie musi zapewniać obsługę wielu rodzajów (min. 3) kart elektronicznych określonych przez Wykonawcę na etapie projektu implementacji i wykorzystywać specyfikację interfejsu PKCS#11 oraz MS Crypto-API. j) Wykonawca zaproponuje stosowne procedury i wykorzystanie oprogramowania Centrum Certyfikacji dla zapewnienia, w okresie przejściowym (tj. w okresie, gdy zaproponowane przez Wykonawcę typy kart nie będą jeszcze wdrożone w Zakładzie), generowania i dystrybucji certyfikatów i kluczy prywatnych w plikach. k) Oprogramowanie Centrum Certyfikacji musi zapewniać zarządzanie listami CRL oraz unieważnianie certyfikatów. l) Oprogramowanie Centrum Certyfikacji musi zapewniać produkcję pojedynczą i wsadową certyfikatów oraz kluczy do plików w formacie PKCS#12. m) Oprogramowanie Centrum Certyfikacji musi obsługiwać co najmniej dwie drukarki do masowej personalizacji kart elektronicznych. n) Oprogramowanie Centrum Certyfikacji musi zapewniać wydruk kodów PIN użytkowników na kopertach utajnionych. 11) Oprogramowanie Centrum Certyfikacji musi posiadać następujące cechy: a) Zapewniać bezpieczny dostęp do aplikacji Centrum Certyfikacji (zabezpieczenie sprzętowe karta elektroniczna), b) Możliwość generowania raportów związanych z zarządzaniem certyfikatami, c) Współpracować ze skanerem do personalizacji graficznej, d) Posiadać edytor do projektowania formy graficznej do personalizacji, e) Możliwość importowania plików graficznych w formacie JPG, PNG, BMP, GIF, f) Zapewnić sporządzanie i wydrukowanie raportu zawierającego dane dotyczące osób umieszczonych w bazie Centrum Certyfikacji w powszechnie zrozumiałej formie. 12) Centrum Certyfikacji musi oferować mechanizmy umożliwiające weryfikowanie aktualnego statusu certyfikatu. 13) Centrum Certyfikacji musi zapewniać mechanizmy automatycznego zablokowania możliwości logowania się do domeny Active Directory, użytkowników, którym unieważniono certyfikaty 19