Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, Warszawa tel: , fax:

Transkrypt

1 Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, Warszawa tel: , fax: /370/IN- 34 /12 Warszawa, Informacja dla Wykonawców, którzy pobrali Specyfikację Istotnych Warunków Zamówienia w postępowaniu o udzielenie zamówienia publicznego 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. Na podstawie art. 38 ust. 1, 2 i 4 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2010 r. Nr 113, poz. 759 ze zm.) informuję, że do Zamawiającego wpłynęły pytania dotyczące Specyfikacji Istotnych Warunków Zamówienia, na które udziela się następującej odpowiedzi: Pytanie 1. W oparciu o załączony do zapytania szablon Oferty, proszę o wskazanie takiego miejsca w którym ma znaleźć się opis proponowanego rozwiązania. W szczególności gdzie w ramach tego szablonu Oferent ma wskazać proponowane komponenty oprogramowania? Zamawiający podtrzymuje zapisy SIWZ. W szablonie nie ma miejsca na opis proponowanego rozwiązania. Rozwiązanie powinno spełniać wskazane wymagania Zamawiającego. Pytanie 2. Jaka jest liczba tożsamości, które mają być zarządzane przy pomocy IdM? Pytanie wynika z różnicy między liczbami 50,000 (wskazanej w sekcji IdM) i 70,000 (wskazanej w sekcji CC). Liczba ta jest istotna w kontekście obliczenia właściwej kwoty za licencje oferowanego oprogramowania, którego model licencyjny bazuje właśnie na liczbie tożsamości. Prosimy jednocześnie o wskazanie jaka część tej populacji, to pracownicy ZUS a jaka to pracownicy zewnętrzni - pytanie to wynika z rozróżnienia pod względem tego typu tożsamości w modelu licencyjnym produktów IdM. Zamawiający podtrzymuje zapisy SIWZ. Zamawiający przewiduje zarządzanie około kont użytkowników. Wyższa liczba w sekcji CC wynika z faktu obsługi przez Centrum Certyfikacji oprócz kont użytkowników, certyfikaty dla serwerów oraz kont użytkowników wykorzystujących VPN (dla których wydawane są obecnie dodatkowe certyfikaty). Pracownicy firm zewnętrznych wykonujących czynności, dla wykonywania których 1

2 niezbędne jest posiadanie kont w systemach informatycznych, traktowani są tak samo, jak pracownicy Zakładu. Pytanie 3. Czy sformułowanie, że można będzie "wykorzystać środowisko VMWare posiadane przez Zamawiającego" oznacza, że Oferent będzie mógł wykorzystać je do wszystkich modułów, którego dotyczy zapytanie ofertowe TZ/370/55/11, tj. IdM, CC, SSO, skaner podatności, środowisko podstawowe, środowisko zapasowe, środowisko testowe? Zamawiający podtrzymuje zapisy SIWZ. Większość modułów będzie mogła być obsłużona za pomocą środowiska wirtualnego opartego o platformę VMware, poza platformą sprzętową pod środowisko bazodanowe, które to Wykonawca będzie musiał dostarczyć. Pytanie 4. W odniesieniu do wymagania "Wykonanie do IdM migracji kont i uprawnień z Katalogu Korporacyjnego KRSB, SWEZ oraz pozostałych integrowanych z IdM platform i systemów." Ile jest platform i systemów przewidzianych do integracji przez Oferenta z IdM w ramach projektu? W jakiej technologii zostały wytworzone i czy systemy te posiadają API do zarządzana użytkownikami? Zamawiający podtrzymuje zapisy SIWZ. Wykaz platform i systemów przewidzianych do integracji został przedstawiony na stronie 12 w pkt 19 SIWZ. Do integrowanych platform/systemów Wykonawca powinien korzystać z funkcji API do zarządzania użytkownikami dostarczanych przez dostawców tych systemów. Pytanie 5. Czy przez zamieszczone w tytule zapytania pojęcie "przeprowadzenie migracji" CC oraz KRSB do IdM rozumiemy, że konta i uprawnienia w KRSB oraz CC mają być zarządzane przez IdM? Czy też znaczenie określenia "migracja" w tym kontekście jest jakieś szersze? Jeśli tak, to jakie? Zamawiający podtrzymuje zapisy SIWZ. Konta i uprawnienia w KRSB (Katalogu Korporacyjnym) mają być zaimportowane do IdM, a następnie z jego poziomu zarządzane. Dane z Centrum Certyfikacji ZUS mają być przeniesione do nowego rozwiązania. Pytanie 6. W odniesieniu do wymagania, że system IdM ma "posiadać mechanizmy masowej migracji kont i uprawnień użytkowników z innych systemów" czy rozumiemy, że IdM ma mieć możliwość importowania do swojego repozytorium informacji o kontach i uprawnieniach z systemów zarządzanych? Zamawiający podtrzymuje zapisy SIWZ. System zarządzania tożsamością ma posiadać mechanizmy masowej migracji rozumiane jako możliwość inicjalnego i regularnego zasilania swojego repozytorium danymi o kontach i uprawnieniach z systemów zarządzanych. Pytanie 7. 2

3 Czy system monitorowania podatności ma być wykorzystywany jedynie w odniesieniu do modułów dostarczanych w odpowiedzi na zapytanie TZ/370/55/11? Czy do jakichś innych aplikacji/systemów też? Jeśli również do innych, to do jakich? Zamawiający podtrzymuje zapisy SIWZ. System monitorowania podatności ma być wykorzystywany jedynie w odniesieniu do modułów dostarczanych w ramach zamówienia. Pytanie 8. Czy ZUS posiada już utworzony i wdrożony Plan Ciągłości Działania (BCP)? Jeśli tak, to czy wymagania odnośnie BCP zawarte w zapytaniu odnoszą się jedynie do tych aspektów BCP, które są bezpośrednio związane z systemami i procesami, które zostaną wdrożone w ZUS wraz z implementacją rozwiązań, które są przedmiotem tego zapytania? Zamawiający podtrzymuje zapisy SIWZ. ZUS nie posiada utworzonego i wdrożonego Planu Ciągłości Działania (BCP), wymagania odnośnie BCP zawarte w SIWZ odnoszą się jedynie do systemów i procesów, które zostaną wdrożone w ZUS wraz z implementacją rozwiązań, które są przedmiotem tego zamówienia. Pytanie 9. Czy ZUS posiada jakieś narzędzia do przeprowadzania testów penetracyjnych? Pytanie wynika stąd, że w zapytaniu znajduje się wymaganie związane z takimi testami. Jeśli ZUS nie posiada takich narzędzi, to czy Oferent ma je dostarczyć w ramach realizacji tego projektu? Zamawiający podtrzymuje zapisy SIWZ. ZUS nie posiada narzędzi do przeprowadzania testów penetracyjnych, testy penetracyjne Wykonawca musi przeprowadzić przy pomocy własnych narzędzi na potrzeby weryfikacji planów i procedur audytu bezpieczeństwa, o których mowa na stronie 49 SIWZ. Pytanie 10. W odniesieniu do sformułowania, że "weryfikacja tożsamości elektronicznej użytkownika realizowana będzie przy pomocy certyfikatu" to czy oznacza ono, że użytkownik końcowy ma mieć możliwość logowania się do systemu IdM przy pomocy certyfikatu? Jeśli sformułowanie to oznacza coś innego, to prosimy o wyjaśnienie. Zamawiający podtrzymuje zapisy SIWZ. Zamawiający w odniesieniu do sformułowania, że "weryfikacja tożsamości elektronicznej użytkownika realizowana będzie przy pomocy certyfikatu" rozumie weryfikację tożsamości w chwili logowania się na stacji roboczej do domeny Active Directory poprzez certyfikat zapisany na karcie elektronicznej. Karta elektroniczna będzie wykorzystywana między innymi do mechanizmu SSO, podpisu cyfrowego poczty elektronicznej oraz autoryzacji w aplikacjach interakcyjnych KSI. Jeżeli certyfikat znajduje się w pliku w zdefiniowanym kontenerze użytkownika, logowanie do systemu Windows będzie odbywało się za pomocą hasła zaś certyfikat może być wykorzystywany na potrzeby mechanizmów SSO, podpisu cyfrowego poczty elektronicznej oraz autoryzacji w aplikacjach interakcyjnych KSI. Dostęp do pozostałych elementów systemu i sieci następuje przy wykorzystaniu mechanizmów Active Directory lub z wykorzystaniem mechanizmów SSO. Mechanizm uwierzytelniania w oparciu o certyfikat w pliku będzie wykorzystywany na etapie wdrożenia kart elektronicznych w celu zapewnienia ciągłości pracy użytkowników. 3

4 Pytanie 11. W odniesieniu do wymagania "zapewniać tworzenie kont użytkowników na podstawie zdarzeń np. po pojawieniu się nowego wpisu w bazie HR" to czy system HR udostępnia odpowiedni interfejs API (z informacjami o tożsamościach, o strukturze organizacyjnej, itp) i czy ZUS posiada odpowiednie licencje na ten interfejs z systemu HR? Zamawiający podtrzymuje zapisy SIWZ. Aktualnie żadne dane HR nie są wystawiane z SAPa na zewnątrz i dostawca będzie miał obowiązek skonfigurować takie wyjście (interfejs), które zapewni komunikację dostosowaną do założeń. Wykonawca może ingerować w SAP w zakresie który nie spowoduje konieczności modyfikacji oprogramowania wykorzystywanego przez Zamawiającego. Pytanie 12. W odniesieniu do wymagania, że IdM ma "zapewniać automatyczne konfigurowanie kont", to prosimy o informację w ilu i jakich systemach automatyzacja tego procesu ma zostać zrealizowana przez Oferenta w ramach tego projektu. Czy systemy te udostępniają odpowiednie interfejsy API pozwalające na zdalną administrację kontami? Czy ZUS posiada odpowiednie licencje na te interfejsy API? Patrz odpowiedź na pytanie 4. Zamawiający nie posiada licencji do wykorzystania na interfejsy API o ile nie są one produktem ogólnie dostępnym lub standardowym produktem dostarczanym przez producenta/wydawcę oprogramowania/systemu wraz z tym oprogramowaniem/systemem. Pytanie 13. Czy zarządzaniu przez IdM podlegać będą konta w systemie mainframe? Jeśli tak, to jaka jest liczba tych kont? Pytanie jest o tyle zasadne, że od ich liczby zależy koszt adaptera zarządzającego kontami na mainframe. Zamawiający podtrzymuje zapisy SIWZ. Zarządzaniu podlegać będą konta w systemie mainframe. Liczba kont jest zależna od partycji. Partycji jest ok. 15 i na każdej z nich jest ok kont z czego ok. 200 to konta osobowe. Każda partycja systemowa (sysplex) posiada oddzielną bazę RACF. Pytanie 14. W odniesieniu do wymagań, że IdM ma "posiadać informacje o wszystkich istniejących w infrastrukturze kontach" i "obejmować zarządzaniem wszystkie konta istniejące w infrastrukturze", prosimy o informację na temat liczby tych komponentów infrastruktury (w rozbiciu na rodzaje tych komponentów, np. 10 serwerów Windows 2003, 5 serwerów UNIX/AIX, itp), które mają zostać podłączone do IdM przez Oferenta w ramach realizacji tego projektu. Zamawiający podtrzymuje zapisy SIWZ. Liczba komponentów infrastruktury (w rozbiciu na rodzaje tych komponentów), Platforma Unix 82 serwery HP-UX, 4

5 44 serwery AIX. 49 serwerów SUN Solaris 9, jedna instancja bazy SUN Java System Directory Serwer 5.2. Platforma Windows: Windows Server 2008 Enterprise Edition R2 253 serwery Windows Server 2003 Enterprise Edition serwery ForeFront TMG 45 serwerów Active Directory - kontrolery domen - 46 serwerów Microsoft Exchange serwerów SQL Server Standard Edition 2005 English Intl MVL 51, Platforma mainframe Z10 Enterprise Class 3 serwery Z10 Buissnes Class 1 serwer Podane liczby są wartościami na dany dzień i nie zawierają tendencji rosnącej. Ilość użytkowników w poszczególnych systemach: Platforma Unix: - HP-UX ok kont - AIX ok. 700 kont - SUN Solaris ok. 250 kont Platforma Windows: - ok kont systemowych lokalnych - ok kont systemowych w domenie AD - ok kont użytkowników w domenie AD Platforma mainframe - ok. 15 partycji zarządzanych RACF na każdej z partycji ok kont, z czego 200 to konta osobowe SAP: - ok kont Pytanie 15. W odniesieniu do mechanizmu raportowania, prosimy o informację na temat liczby i rodzaju raportów jakie mają zostać dostarczone przez Oferenta w ramach realizacji tego projektu. Zamawiający podtrzymuje zapisy SIWZ. Zamawiający oczekuje od Wykonawcy mechanizmów umożliwiających tworzenie dowolnie sparametryzowanego raportu w oparciu o zgromadzone dane, zależnie od potrzeby Zamawiającego. Pytanie 16. W odniesieniu do wymagania, że IdM ma "zapewniać konfigurowalny mechanizm wnioskowania, aprobowania" prosimy o określenie ile różnych ścieżek wnioskowania i aprobowania (workflow) ma zostać zaimplementowanych przez Oferenta w ramach tego projektu. Zamawiający podtrzymuje zapisy SIWZ. Zamawiający określił w rozdziale II punkt I.A.1.1c), że Wykonawca wraz z systemem ma zaimplementować 4 ścieżki obiegu dokumentów. 5

6 System ma umożliwiać tworzenie kolejnych ścieżek, ich modyfikację (również już zdefiniowanych) przez Zamawiającego samodzielnie. Pytanie 17. W odniesieniu do wymagania "Zamawiający wymaga dwóch środowisk dla wdrażanego systemu zarządzania tożsamością środowiska operacyjnego i środowiska zapasowego", to czy Zamawiający oczekuje, aby zbudowane zostało również środowisko testowe? Zamawiający podtrzymuje zapisy SIWZ. Środowisko zapasowe nie jest środowiskiem testowym. Jest to środowisko, które przejmie zadania środowiska operacyjnego w przypadku awarii lub katastrofy, jaką będzie fizyczne zniszczenie sprzętu w środowisku operacyjnym. Zamawiający nie wymaga budowy dodatkowego środowiska testowego. Pytanie 18. W odniesieniu do wymagań na przeniesienie praw autorskich i przekazaniu kodu źródłowego dla ZUS, to czy słuszne jest założenie że wymaganie to NIE dotyczy tych komponentów oferowanego rozwiązania, które są gotowymi/półkowymi produktami dostawców technologicznych (np. Microsoft, Oracle, IBM)? Zamawiający podtrzymuje zapisy SIWZ. Przeniesienie praw autorskich i kodu źródłowego dla ZUS nie dotyczy rozwiązań, które są gotowymi/półkowymi produktami dostawców technologicznych (np. Microsoft, Oracle, IBM). Pytanie 19. Jak zbudowany jest katalog korporacyjny? I czy wymagane jest zarządzanie KSI? Zamawiający podtrzymuje zapisy SIWZ. Katalog Korporacyjny jest to baza danych zbudowana na standardowym produkcie, którym jest SUN Java System Directory Server 5.2. Zarządzanie KSI oparte jest o zarządzanie danymi znajdującymi się w Katalogu Korporacyjnym. Pytanie 20. Co konkretnie oznacza bezpieczne przechowywanie i przetwarzanie informacji o użytkownikach, kontach, profilach i uprawnieniach? Zamawiający podtrzymuje zapisy SIWZ. Bezpieczne przechowywanie i przetwarzanie informacji o użytkownikach, kontach, profilach i uprawnieniach oznacza zapewnienie poufności, integralności i dostępności przetwarzanych informacji. Pytanie 21. W jaki sposób mają być zarządzane konta techniczne i administracyjne, i jakie są różnice względem kont użytkowników? Zamawiający podtrzymuje zapisy SIWZ. Konta techniczne i administracyjne będą istniały w systemie jako osobne tożsamości. Tożsamości te będą pozostawały w relacji z tożsamościami osób fizycznych, które posiadają do nich hasła/odpowiadają za wykonywane z ich użyciem 6

7 czynności. W ramach systemu powinny istnieć specjalne procesy wnioskowania o utworzenie/usunięcie takich kont Pytanie 22. Jak konkretnie należy rozumieć elastyczność która pozwoli na budowanie raportów? Zamawiający podtrzymuje zapisy SIWZ. Elastyczność, która pozwoli na budowanie raportów rozumiana jest jako możliwość tworzenia dowolnie sparametryzowanego raportu w oparciu o zgromadzone dane, zależnie od potrzeby Zamawiającego. Pytanie 23. Na czym ma polegać umożliwianie częściowego oddelegowania zarządzania tożsamością w kierunku użytkowników? Zamawiający podtrzymuje zapisy SIWZ. Możliwość częściowego oddelegowania zarządzania tożsamością w kierunku użytkowników ma polegać na udostępnieniu użytkownikom mechanizmów samoobsługi w zakresie wnioskowania o uprawnienia oraz modyfikację opisu tożsamości. Pytanie 24. Czy systemy zarządzane wymienionymi systemami Windows oprócz wymagań dla Active Directory należy rozumieć jako zarządzanie kontami lokalnymi na tych systemach? Ile systemów Windows (konta lokalne będzie zarządzanych)? Ile systemów UNIX/Linux będzie zarządzanych? Ile baz danych będzie zarządzanych? Ile instancji RACF będzie zarządzanych? Ile mandantów SAP będzie zarządzanych? Ile kont RACF będzie zarządzanych? Ile kont SAP będzie zarządzanych? Patrz odpowiedź na pytanie 13 i 14. Pytanie 25. Prosimy o opis sposobu przechowywania danych uwierzytelniających i autoryzacyjnych w systemach FI-AA, MM, SD - sprzedaż, HR kadry, HR płace, FI, CO, TR, SEM, BW, BASIS, LSO, SM Dostęp do modułów jest regulowany rolami nadawanymi w SAP. Pytanie 26. Czy rozwiązanie ma zarządzać dostępem do KSI czy tylko importować dane o użytkownikach i posiadanych przez nich uprawnieniach w systemie KSI? Zamawiający podtrzymuje zapisy SIWZ. System IdM ma zarządzać dostępem do KSI. Pytanie 27. Czy unikalne ID ma być tworzone przez system IdM czy też importowane z zewnętrznych źródeł? 7

8 Zamawiający podtrzymuje zapisy SIWZ. System IdM ma mieć zaimplementowane mechanizmy tworzenia identyfikatorów do zewnętrznych źródeł, którymi będzie zarządzać. Pytanie 28. Czy synchronizacja ma odbywać się w postaci pełnej synchronizacji wszystkich obiektów, czy poprzez budowanie delty zmian, czy też zmiany w źródłach danych mają być automatycznie odzwierciedlane w IdM Jaki protokół SAP ma być użyty do synchronizacji: BAPI czy RFC/oba? Zamawiający podtrzymuje zapisy SIWZ. Sposób synchronizacji musi być opisany w projekcie przygotowanym przez Wykonawcę. Pytanie 29. Prosimy opisać oczekiwany mechanizm masowej migracji kont. Patrz odpowiedź na pytanie 6. Pytanie 30. Na czym ma polegać porównywanie? Czy dane kadrowe o pracownikach z systemu kadrowego czy innych systemów nie będą zasilały systemu IdM? (patrz pkt B.3.2) Zamawiający podtrzymuje zapisy SIWZ. Dane kadrowe będą zasilały system IdM. Zamawiający oczekuje, że porównanie informacji o kontach z informacją o zatrudnionych pracownikach będzie następowało na żądanie Zamawiającego oraz wykonanie przeglądu zostanie odnotowane przez wyznaczone osoby (w punktach gdzie jest to zaznaczone) poprzez system dostarczony przez Wykonawcę. Może być to wbudowana funkcjonalność IDM, a może to być oddzielny produkt dostarczony wraz z IdM. Pytanie 31. Na czym ma polegać ochrona przesyłanych danych pomiędzy elementami rozwiązania? Zamawiający podtrzymuje zapisy SIWZ. Ochrona przesyłanych danych pomiędzy elementami rozwiązania polegać ma na zapewnieniu poufności i integralności przesyłanych danych. Pytanie 32. Jaka forma współdzielenia stacji roboczej ma być wspierana: 1. Zamykanie aplikacji otwartych przez poprzedniego użytkownika i umożliwienie logowania nowego? 2. Wsparcie niezależnych sesji dla każdego użytkownika utrzymywanych przez system (czy wsparcie dla Windows XP?) Zamawiający podtrzymuje zapisy SIWZ. Stacje współdzielone, to takie na których pracuje przynajmniej dwóch użytkowników. Użytkownicy muszą logować się i wylogowywać za każdym razem, kiedy chcą uzyskać dostęp do stacji. 8

9 Pytanie 33. Skąd i dokąd szablony mają by importowane? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający nie narzuca miejsca repozytorium, w związku z powyższym nie ma możliwości udzielenia odpowiedzi na tak sformułowane pytanie. Pytanie 34. Co uznaje Zamawiający za silny mechanizm? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający za silny mechanizm uznaje taki, który zapewni poufność i integralność przetwarzanych informacji. Pytanie 35. Czy logowanie do systemu SSO ma się odbywać za pomocą kart i usług PKI? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający nie narzuca sposobu logowania do systemu SSO. Sposób autoryzacji użytkownika opisany został w odpowiedzi na pytanie 10. Pytanie 36. Czy logowanie ma być zcentralizowane czy też składowane na każdej stacji roboczej niezależnie? Zamawiający podtrzymuje zapisy SIWZ. Logowanie powinno być zcentralizowane. Pytanie 37. Czy użytkowników to pracownicy ZUS? Jeśli nie prosimy o podanie ilości użytkowników z podziałem pracownicy, osoby trzecie. Zamawiający podtrzymuje zapisy SIWZ. Na chwilę obecną Zamawiający ma zarejestrowanych w systemie kont, z czego osoby trzecie stanowią poniżej 500 kont. Należy jednak zaznaczyć, że osoby trzecie wykonują u zamawiającego czynności na takich samych warunkach jak pracownicy Zakładu. Pytanie 38. Czy system ma zarządzać tożsamością historyczną? Jeśli tak to jaką ilość tożsamości historycznej ma być wspierana w ramach oferowanego rozwiązania? Zamawiający podtrzymuje zapisy SIWZ. System zarządzania tożsamością ma zarządzać kontami od chwili wdrożenia systemu. Historia konta nie będzie wprowadzana do systemu. Po wdrożeniu systemu, system ma zapamiętać ostatni stan tożsamości w chwili jego kasowania. Ilości wspieranych skasowanych tożsamości Zamawiający nie jest w stanie określić. W 2011 roku zostało z systemu KSI skasowanych 3608 tożsamości. 9

10 Pytanie 39. Czy na potrzeby wyceny należy przyjąć, że do implementacji będą tylko cztery obiegi akceptacyjne (workflow) wymienione w rozdziale II punkt I.A.1.1c)? Jeśli NIE, to ile obiegów w sumie należy przyjąć w wycenie? Prosimy o podanie przewidywanego stopnia skomplikowania tych obiegów (liczba akceptantów, zrównoleglanie akceptacji, konieczne eskalacje, itp) Zamawiający podtrzymuje zapisy SIWZ. Zamawiający w zamówieniu oczekuje implementacji 4 kategorii parametryzowanych procesów. Na potrzeby wyceny proszę przyjąć do trzech stopni akceptacji parametryzowanych w zależności od położenia użytkownika w strukturze organizacyjnej, systemu i uprawnienia/roli, możliwe wyzwalane czasem eskalacje na każdym z etapów, ewentualność automatycznego odrzucenia w przypadku przekroczenia czasu granicznego. Pytanie 40. Ile w sumie systemów ma być objęte mechanizmem SSO? Patrz odpowiedź na pytanie 14 i 67. Pytanie 41. Ilu pracowników ma objąć szkolenie przystanowiskowe, o którym mowa w punkcie I.A.8? Zamawiający informuje, że na podstawie art. 38 ust 4 ustawy Prawo zamówień publicznych dokonuje modyfikacji SIWZ w następującym zakresie: W Specyfikacji Istotnych Warunków Zamówienia rozdz.ii, podrozdz.i, część A, ust.8 oraz analogicznie w załączniku nr 1 do umowy dodaje zapis: Zamawiający oczekuje przeszkolenia dla 10 pracowników z systemu zarządzania tożsamością oraz 2 osób z każdego z systemów, z którym będzie zintegrowany, w zakresie mechanizmów instalowanych na tej platformie. Pytanie 42. Ile kont administracyjnych i technicznych w poszczególnych systemach/aplikacjach należy przyjąć w wycenie licencji (punkt I.B.2.6)) Patrz odpowiedź na pytanie 14. Pytanie 43. W punkcie I.B.2.20)b) jest mowa o użytkownikach posługujących się wieloma kontami - o ile liczba kont przekracza liczbę użytkowników z punktu I.B.2.20)a) Zamawiający podtrzymuje zapisy SIWZ. W chwili obecnej liczba wszystkich kont w SAP łącznie z mnogimi kontami wynosi i nie przekracza liczby kont użytkowników z punktu I.B.2.20)a). Liczba ta rośnie z uwagi na szkolenia elektroniczne, które Zamawiający zamierza realizować w oparciu o autoryzację w SAP. 10

11 Pytanie 44. Jakie komponenty wchodzą w skład wymienianego m.in. w pkcie I.B.1.4) systemu pocztowobiurowego? W skład systemu pocztowo biurowego wchodzą: Windows 2008 Active Directory MS Exchange 2010 ForeFront TMG 2010 Ponadto: Zamawiający informuje, że na podstawie art. 38 ust 4 ustawy Prawo zamówień publicznych dokonuje modyfikacji SIWZ w następującym zakresie: W Specyfikacji Istotnych Warunków Zamówienia rozdz.ii, podrozdz.i, część B, ust.2 pkt19) ppkt c) oraz analogicznie w załączniku nr 1 do umowy zapis: c) ISA server Std Ed 2004 English MVL 1 Proc zastępuje się zapisem: c) ForeFront TMG Pytanie 45. Jak odbywa się zarządzanie użytkownikami SAP? Dla każdego modułu osobno, czy poprzez CUA? Zamawiający podtrzymuje zapisy SIWZ. Zarządzanie użytkownikami SAP odbywa się poprzez CUA. Pytanie 46. Co będzie podstawowym źródłem danych o użytkownikach? SAP HR? Zamawiający podtrzymuje zapisy SIWZ. Podstawowym źródłem danych o użytkownikach będzie SAP HR. Pytanie 47. Czy poza systemem kadrowym będą jeszcze jakieś źródła tożsamości (np. konsultantów)? jakie? Zamawiający podtrzymuje zapisy SIWZ. Poza modułem HR nie istnieją autorytatywne źródła danych o tożsamościach. Rejestracja tożsamości w tym module może być niewystarczająca ze względu na konieczność rejestracji i zarządzanie kontami użytkowników pracowników firm zewnętrznych. Należy przewidzieć ręczną rejestrację tożsamości w systemie przez wyznaczoną grupę osób. System powinien używać różnych źródeł na poziomie poszczególnych elementów opisu tożsamości. Pytanie 48. Na jakim poziomie wymagana jest integracja z bazami danych? Czy na poziomie kont bazodanowych, czy na poziomie poszczególnych aplikacji? 11

12 Zamawiający podtrzymuje zapisy SIWZ. Zamawiający wykorzystuje w swoich aplikacjach autoryzację na poziomie kont bazodanowych jak również aplikacyjnych. Integracja powinna odbywać się na obu płaszczyznach. Pytanie 49. Jeśli integracja ma być na poziomie poszczególnych aplikacji bazowodanowych to prosimy o podanie ich orientacyjnej liczby oraz gdzie są przechowywane informacje autoryzacyjne (konto bazowodanowe, tabela aplikacji, inne)? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający wykorzystuje w swoich aplikacjach autoryzację na poziomie kont bazodanowych, aplikacyjnych oraz w oparciu o Active Directory. Integracja powinna odbywać się na wszystkich płaszczyznach. Zamawiający eksploatuje około 500 aplikacji, w których informacje autoryzacyjne są przechowywane w relacyjnych bazach danych. Aplikacji webowych jest około 84 (ale jest to liczba ciągle rosnąca). Aplikacji opartych o okna Windows jest około 456. Pytanie 50. W pkt 2. Szczegółowe wymagania dla systemu zarządzania tożsamością w ppkt 19a) do 19o) zostały wymienione systemy, które mają być zintegrowane z centralnym repozytorium, natomiast w pkt 3. Wymagania w zakresie zarządzania użytkownikami jest podane że Zamawiający wymaga, aby oferowany system do zarządzania tożsamością zapewniał synchronizację danych przynajmniej dla 3 wymienionych repozytoriów - pytanie: czy system ma się synchronizować z tylko z tymi 3 repozytoriami czy też systemami opisanymi w 2 ppkt 19 a) do 2 ppkt 19o)? Ile z tych użytkowników ma dane przechowywane w poszczególnych systemach które mają być synchronizowane za pomocą systemu do zarządzania tożsamością? Zamawiający podtrzymuje zapisy SIWZ. System ma synchronizować się z przynajmniej 3 repozytoriami: SAP, AD i Katalog Korporacyjny, w pozostałych systemach ma jedynie zarządzać kontami. Systemy, które mają być synchronizowane docelowo mają posiadać informacje o wszystkich użytkownikach. Pytanie 51. Czy Zamawiający zaakceptuje architekturę umożliwiającą każdemu administratorowi domeny dostęp, zmianę i rekonfigurację CA? Tj. rozwiązanie w którym uprawnienia zarządzania CA są na stałe powiązane z uprawnieniami administratora domeny? Łączenie uprawnień administracyjnych CA i domeny jest niezgodne ze sztukę i niebezpieczne. Zamawiający podtrzymuje zapisy SIWZ. Zamawiający rozumie, że uprawnienia zarządzania CA będą powierzone tylko i wyłącznie administratorom Centrum Certyfikacji. Pytanie 52. Czy KRSB ściąga certyfikaty z Active Directory? Prosimy o opis interface'u jaki ma być użyty do opublikowania CRL w KRSB. 12

13 Zamawiający podtrzymuje zapisy SIWZ. KRSB nie korzysta z Active Directory. Publikacja list CRL w KRSB ma odbywać się z wykorzystaniem protokołu LDAP lub SASL. Pytanie 53. Czy skrót b przy podanej długości kluczy oznaczy bity czy bajty? Zamawiający podtrzymuje zapisy SIWZ. Skrót b oznacza bity. Pytanie 54. Czy Zamawiający zaakceptuje algorytm SHA-256 zamiast MD4, MD-5 i SHA-1? Algorytm MD4 jest przestarzały i skompromitowany. Od roku 2005 nawet Microsoft zakazał używania MD4 i MD5, a SHA-1 dopuszcza tylko w szczególnych przypadkach. Zamawiający informuje, że na podstawie art. 38 ust 4 ustawy Prawo zamówień publicznych dokonuje modyfikacji SIWZ w następującym zakresie: W Specyfikacji Istotnych Warunków Zamówienia rozdz.ii, podrozdz.i, część B, ust.9 pkt.10) ppkt h) oraz analogicznie w załączniku nr 1 do umowy zapis: h) funkcji skrótu: SHA-1, MD4, MD5 zastępuje się zapisem: h) funkcji skrótu: SHA-256 lub innych funkcji których bezpieczeństwo jest równe lub wyższe. Pytanie 55. Czy "serwery pełniące funkcję urzędów certyfikacji" mają być dostarczone jako hardware czy też Zamawiający udostępni np. zasoby w środowisku VMware? Czy Zamawiający ma posiada do wykorzystania licencje na bazę danych np.: Oracle, Microsoft, lub podobne, czy ma to dostarczyć je Wykonawca? Patrz odpowiedź na pytanie 3. Zamawiający nie posiada wolnych licencji do wykorzystania na motory baz danych. Pytanie 56. Czy Zamawiający zrezygnuje z wymogu logowania do domeny z wykorzystaniem wewnętrznych mechanizmów MS Windows XP? Karty które to potrafią, już nie są produkowane lub kolidują z wymogiem 12-6 (15 certyfikatów o długości 2048 bit) Zamawiający podtrzymuje zapisy SIWZ. Pytanie 57. Jakie uzasadnienie techniczne ma kontrast między bardzo wysokimi wymaganiami do kart (EAL5+,FIPS (level 3)) do przestarzałych i niebezpiecznych wymagań z Strony 19, punkt h? Patrz odpowiedź na pytanie

14 Pytanie 58. dotyczy: SIWZ: str. 17, punkt 8.4; str.22 punkt f; str. 24 punkt 23: System musi integrować się z obecnie stosowanym w Zakładzie standardem monitorowania opartym o narzędzia BMC. Prosimy o uściślenie określenia: integrować się jakie kryteria będą użyte do oceny tego wymagania. Zamawiający podtrzymuje zapisy SIWZ. Pod pojęciem integracji Zamawiający rozumie możliwość monitorowania za pomocą dedykowanego agenta oprogramowania BMC krytycznych z punktu widzenia poprawności i stabilności działania systemu zarządzania tożsamością parametrów podsystemów dostarczonego rozwiązania (np.: wykorzystanie pamięci, wykorzystanie procesora, wykorzystanie zasobów dyskowych, monitorowanie usług systemowych, serwisów itp.). Pytanie 59. dotyczy: SIWZ: str. 16 punkt 12; oraz str. 18 punkt j; str. 23 podpunkt g; str. 25 punkt 10 wymagania dla SSO Wszystkie raporty muszą mieć możliwość eksportu do różnych formatów m.in. CSV, PDF, HTML, XML, Prosimy o uściślenie tego warunku: czy będzie on spełniony, jeśli którykolwiek z wymienionych formatów (CSV, PDF, HTML, XML) będzie dostępny czy dostępne muszą być wszystkie wymienione? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający poprzez zapis m.in. CSV, PDF, HTML, XML rozumie, że wszystkie wymienione formaty muszą być wspierane. Pytanie 60. dotyczy: SIWZ: str. 22 podpunkt e: Drukarki do personalizacji kart, drukarki igłowe oraz skanery muszą zapewnić sprawną obsługę wszystkich użytkowników Zakładu. Prosimy uściślić, co Zamawiający rozumie pod pojęciem: zapewnić sprawną obsługę. Zamawiający podtrzymuje zapisy SIWZ. Pod pojęciem: zapewnić sprawną obsługę Zamawiający rozumie możliwość obsługi na etapie wdrożenia około 1000 użytkowników tygodniowo, w okresie powdrożeniowym około 50 użytkowników dziennie. Pytanie 61. dotyczy: SIWZ: str. 5 punkt 2.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. 14

15 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. Prosimy uściślić kryterium powszechność wykorzystania. Zamawiający podtrzymuje zapisy SIWZ. Przez powszechność wykorzystania Zamawiający rozumie, że nie będzie jedynym użytkownikiem kart elektronicznych danego typu w chwili wdrażania systemu. Pytanie 62. Pytanie 6, dotyczy: SIWZ: str 12/13 punkt 19: 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ą, BW hurtownia danych (sprawozdawczość), BASIS administracja, technologia informatyczna, LSO szkolenia elektroniczne, SM solution manager (narzędzie administratorskie). 15

16 Czy konta istniejące w wymienionych systemach posiadają jakiś unikalny atrybut, umożliwiający połączenie ich z kontem właściciela? Prosimy o informację jaki to jest rodzaj atrybutu. Czy są to standardowe atrybuty systemów? (np. SID dla Windows lub UID dla Unix). Zamawiający podtrzymuje zapisy SIWZ. W sieci Zakładu, podobnie jak w większości standardowych implementacji, konta w systemie Windows posiadają identyfikator SID, a konta w systemie UNIX identyfikator UID. W systemie RAFC mainframe użytkownik posiada unikalną nazwę konta, a jeżeli ma segment omvs to posiada unikalny UID. W każdym systemie istnieje unikalny identyfikator konta. Nie w każdym przypadku możliwe jest jednoznaczne, automatyczne przyporządkowanie konta do tożsamości, jednakże konta, które nie mogły być przyporządkowane powinny być raportowane jako niepołączone i system powinien umożliwić ich przyporządkowanie ręczne. Pytanie 63. dotyczy: SIWZ: str. 13 punkt 4: posiadać mechanizmy masowej migracji kont i uprawnień użytkowników z innych systemów, wymienionych w Rozdziale 2.2 pkt 19. Prosimy +uściślić definicję uprawnień w tych systemach oraz oszacować łączną liczbę użytkowników i ich uprawnień (w systemach wymienionych w rozdziale 2.2 punkt 19). Zamawiający podtrzymuje zapisy SIWZ. Zamawiający pod pojęciem uprawnienia rozumie przynależność konta do grup lub posiadanie atrybutów traktowanych przez system jako uprawnienia. Łączna ilość użytkowników jest równoznaczna z ilością pracowników i jest to Ilość kont jaka jest w poszczególnych systemach została wymieniona w odpowiedzi na pytanie 14. Jeden użytkownik może mieć wiele kont w różnych systemach. Łączna liczba kont patrz odpowiedź na pytanie 14. Pytanie 64. dotyczy: SIWZ: str. 11 punkt 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. Prosimy o specyfikację typów uprawnień w aplikacjach KRSB, które mają użytkownicy obecnie oraz jak uprawnienia te są zdefiniowane aktualnie (przykładowo baza danych, LDAP, pliki płaskie, inne?). Zamawiający podtrzymuje zapisy SIWZ. Zamawiający uprawnienia do aplikacji KSI przechowuje w bazie LDAP w postaci atrybutu typu tekstowego będącego elementem obiektu opisującego konto użytkownika. Pytanie

17 dotyczy: SIWZ: str. 11 punkt 3: System zarządzania tożsamością musi: posiadać centralne repozytorium informacji o użytkownikach, kontach, profilach i uprawnieniach, Prosimy o definicję jak zbudowane są profile, czy profil jest tożsamy z rolą pełnioną przez osobę w przedsiębiorstwie? Zamawiający podtrzymuje zapisy SIWZ. Profil uprawnień w systemie SAP od strony modułu HR jest tożsamy z rolą pełnioną przez osobę w Zakładzie. Dodatkowo w systemie SAP użytkownicy modułu HR posiadają profil uprawnień strukturalnych oparty o strukturę organizacyjną. Profil w połączeniu z rolą i przypisaniem organizacyjnym daje uprawnienia do określonego Oddziału. W pozostałych systemach brak zdefiniowanych profili. Pytanie 66. dotyczy: SIWZ: str. 23 punkt 11.2: udostępniać swoje usługi na wszystkich stacjach końcowych opierających się o systemy Windows Prosimy o specyfikację wersji wspomnianych systemów Windows. Czy są to systemy XP, Vista, 7? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający na chwilę obecną na stacjach roboczych wykorzystuje system operacyjny Windows XP Professional SP3 oraz Windows 7 Professional. Pytanie 67. dotyczy: SIWZ: str. 23 punkt umożliwiać realizowanie jednokrotnego logowania dla następujących rodzajów aplikacji: a) aplikacji opartych o okna Windows, b) aplikacji Javy, c) aplikacji Webowych, d) aplikacji opartych o terminal TTY, e) aplikacji dedykowanych Czy Zamawiający ma na myśli aplikacje dedykowane jako Oprogramowanie dedykowane uzupełniające funkcjonalność systemu IdM? Jeżeli nie, to prosimy o informację, w jakiej technologii wykonane są aplikacje dedykowane jak również, w jaki sposób odbywa się interakcja użytkownika przy logowaniu się do tych aplikacji. Zamawiający podtrzymuje zapisy SIWZ. Zamawiający jako aplikacje dedykowane rozumie aplikacje stworzone w technologii opisanej w podpunktach a) d) wyłącznie na potrzeby Zamawiającego. Interakcja użytkownika do tych aplikacji odbywa się poprzez login i hasło lub poprzez informację o zalogowanym użytkowniku systemu Windows na stacji roboczej. Aplikacji webowych jest około 84 (ale jest to liczba ciągle rosnąca). Aplikacji opartych o okna Windows jest około 456. Pytanie 68. dotyczy: SIWZ: str. 23 punkt

18 7) SSO musi również zapewniać możliwość przechowywania zaszyfrowanych haseł do zdefiniowanych systemów na karcie elektronicznej Prosimy o wyspecyfikowanie ilości systemów, dla których zaszyfrowane hasła mają być przechowywane na karcie elektronicznej. Odpowiedź Zamawiający podtrzymuje zapisy SIWZ. Należy przyjąć, że będą osoby, które będą miały konto na wszystkich platformach systemowych wymienionych w rozdz.ii, podrozdz.i, częśćb, ust.2, pkt 19) SIWZ i w ramach tych platform ma działać SSO. Pytanie 69. dotyczy: SIWZ: str. 9 punkt B 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. Ze względów bezpieczeństwa oraz wspominanych w dalszej części dokumentu możliwości użycia uwierzytelniania dwuskładnikowego używanie certyfikatu z pliku może narażać użytkownika i system na nadużycia i zagrożenia bezpieczeństwa. Prosimy o przybliżenie funkcjonalności weryfikacji tożsamości użytkownika przy pomocy certyfikatu zapisanego w pliku. Czy użytkownik ma się logować do stacji roboczej na konto tymczasowe lub konto gościa a następnie użyć certyfikatu w pliku do weryfikacji w systemie IdM? Patrz odpowiedź na pytanie 10. Pytanie 70. dotyczy: SIWZ: str. 11 punkt 7 na górze 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. W związku z możliwością zaproponowania innej koncepcji odnośnie repozytorium wszystkich uprawnień prosimy o podanie kryteriów akceptacji ewentualnej koncepcji. Zamawiający podtrzymuje zapisy SIWZ. Zamawiający dopuszcza inną koncepcję pod warunkiem że wydajność systemów obecnie eksploatowanych nie ulegnie pogorszeniu/obniżeniu oraz nie będzie to związane z dodatkowymi kosztami, które mogą wystąpić po stronie Zamawiającego. Pytanie 71. dotyczy: SIWZ: str. 11 punkt 13 13) niezależnie od rozproszenia być zarządzany oraz obsługiwany z dowolnej lokalizacji 18

19 Czy Zamawiający gwarantuje zapewnienie dostępności ścieżki sieciowej z dowolnej lokalizacji do środowiska gdzie będzie uruchomiony system IdM? Odpowiedź Zamawiający podtrzymuje zapisy SIWZ. Zamawiający gwarantuje dostępność portów i usług niezbędnych dla IdM w ramach własnej sieci. Pytanie 72. dotyczy: SIWZ: str. 14 punkt 12 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, Czy możliwość porównywania informacji o kontach z informacją o zatrudnionych pracownikach pochodzących np. z systemu kadrowego ma być: a) wbudowaną funkcjonalnością systemu IdM dostępnego i realizowanego poprzez interfejs administracyjny IdM poprzez wskazanie systemu, z którym ma nastąpić porównanie? b) czy chodzi o możliwość wykonania eksportu/raportu informacji o kontach z systemu IdM z przeznaczeniem do porównania ręcznego lub zewnętrznym narzędziem? Zamawiający podtrzymuje zapisy SIWZ. Patrz odpowiedź na pytanie 30. Pytanie 73. dotyczy: SIWZ: str. 24 punkt loginy i hasła muszą być szyfrowane odpowiednio silnym mechanizmem szyfrowania, Czy algorytmy 3DES lub AES są traktowane jako odpowiednio silne mechanizmy szyfrowania? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający traktuje algorytmy 3DES i AES jako silne mechanizmy szyfrowania do przechowywania haseł. Pytanie 74. dotyczy: SIWZ: str. 18 punkt 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. Czy Wykonawca ma dostarczyć sprzęt, systemy operacyjne i oprogramowanie używane w punktach rejestracji? Zamawiający podtrzymuje zapisy SIWZ. Wykonawca ma dostarczyć jednolity sprzęt, system operacyjny i oprogramowanie używane w 44 Oddziałowych Punktach Rejestracji. Centralny Punkt Rejestracji ma być rozbudowanym Oddziałowym Punktem Rejestracji umożliwiającym dodatkowo graficzną personalizację karty elektronicznej. Jeżeli czynności wykonywane w Punkcie Rejestracji będzie można wykonać na dowolnej stacji w ramach systemu Zamawiający nie wymaga uruchamiania Punktów Rejestracji w poszczególnych oddziałach. 19

20 Pytanie 75. dotyczy: SIWZ: str. 18 punkt 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. Jaką funkcjonalność powinno posiadać oprogramowanie do zarządzania cyklem życia kart oraz rozproszonej obsługi użytkowników? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający rozumie, że oprogramowanie do zarządzania cyklem życia karty powinno co najmniej potrafić określić jaka karta jest spersonalizowana, dla kogo i jaką pełni rolę w systemie (aktywna, nieaktywna, imienna, gość, itp). Pytanie 76. dotyczy: SIWZ: str. 18 punkt 10.b Użytkownik musi posiadać możliwość odnowienia z użytkowanej stacji swojego certyfikatu przed upływem jego ważności. Czy pod pojęciem odnowienie certyfikatu rozumiane jest wystawienie certyfikatu z dotychczas używanym kluczem czy certyfikatu z nowym kluczem o tej samej funkcjonalności, co certyfikat dotychczasowy? Zamawiający podtrzymuje zapisy SIWZ. Zamawiający pod pojęciem odnowienie certyfikatu rozumie wydanie przez Centrum Certyfikacji nowego certyfikatu klucza publicznego o tej samej funkcjonalności co dotychczasowy. Pytanie 77. dotyczy SIWZ: str. 1 temat zamówienia: 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ą Pytanie dotyczy funkcjonalności Centrum Certyfikacji. Zamawiający posiada infrastrukturę PKI, która będzie podlegać migracji.: 1. O jaki system operacyjny oparta jest istniejąca infrastruktura PKI? 2. Czy istniejący system PKI jest zintegrowany z AD i KRSB? 3. Które elementy składowe istniejącego systemu PKI podlegają migracji? 4. Które elementy składowe istniejącego systemu PKI nie podlegają migracji? 5. Czy występują takie elementy składowe istniejącego systemu PKI, których konfiguracja musi zostać zachowana? Jeśli tak to prosimy podać te elementy i wymienić, które części konfiguracji muszą być zachowane. Zamawiający podtrzymuje zapisy SIWZ. 1. Istniejąca infrastruktura PKI oparta jest o Windows NT 4.0 Server i oprogramowanie TrustedCA firmy Siemens. 2. Istniejący system PKI jest zintegrowany z KRSB i nie jest zintegrowany z AD. 3. Migracji podlegają dane o użytkownikach wraz z ostatnim wydanym im certyfikatem. 4. Elementy nie wymienione w pkt 3. 20