| Zakup 3-letnich licencji czasowych systemu DDI Infoblox wraz ze wsparciem producenta i aktywacją subskrypcji, świadczenie wsparcia technicznego wykonawcy oraz realizacja prac rozwojowych. - 10 typów 3-letnich licencji systemu DDI Infoblox ze wsparciem producenta: łącznie 12 518 szt. (w tym 12 500 szt. licencji ochrony zapytań DNS oraz 18 szt. pozostałych licencji). - Świadczenie wsparcia technicznego wykonawcy: 36 miesięcy. - Realizacja prac rozwojowych: 450 roboczogodzin.|
Trudność: średnia
Zamówienie obejmuje dostawę wielu typów licencji specjalistycznego systemu DDI oraz wieloletnie wsparcie i prace rozwojowe, co wymaga doświadczenia i koordynacji wdrożeniowej.
Wyodrębnione z wyjaśnień treści SWZ.
1Pytanie nr 1.
Pkt 4.1.1 i 4.4 Wzoru umowy, pkt 1 OPZ, wykaz architektury Kryteriów Równoważności oraz pkt 26.1.2 SWZ – zakres rozwiązania równoważnego, liczba komponentów i sposób wyceny
Uwagi Wykonawcy:
Kryteria Równoważności opisują rozwiązanie jako zestaw ośmiu podsystemów o z góry określonej liczbie instancji, odpowiadającej dotychczasowemu wdrożeniu rozwiązania referencyjnego. Jednocześnie pkt 4.1.1 Wzoru umowy i pkt 1 OPZ określają przedmiot dostawy wyłącznie przez dziesięć kodów produktowych Infoblox, a pkt 26.1.2 SWZ i pkt 9.2.1.1 – 9.2.1.10 Wzoru umowy wiążą cenę oferty z tymi samymi dziesięcioma pozycjami i ilościami licencji. Rozwiązanie innego producenta może zapewniać te same role, środowiska, zasięg lokalizacji, nadmiarowość, wydajność i izolację awarii przy innej liczbie lub innym rozmieszczeniu komponentów, a jego licencje nie muszą odpowiadać podziałowi stosowanemu przez Infoblox. Dokumenty Zamówienia nie wskazują, czy wykonawca może w takim przypadku zastąpić odpowiednie istniejące komponenty DDI i ochrony DNS ani w jaki sposób ma wycenić takie rozwiązanie w Formularzu oferty.
Dopuszczenie Produktu Równoważnego w pkt 4.4 Wzoru umowy ma charakter realny tylko wtedy, gdy obejmuje cały zakres Zamówienia i daje się przełożyć na formularz cenowy. Jeżeli architektura, liczba instancji i struktura wyceny pozostają przypisane do produktów Infoblox, równoważność jest pozorna, co narusza art. 99 ust. 4 – 6 PZP w zw. z art. 16 pkt 1 – 3 PZP. Brak zasad wypełnienia Formularza oferty przez wykonawcę oferującego rozwiązanie równoważne narusza ponadto art. 99 ust. 1 PZP i uniemożliwia porównanie ofert na jednolitych zasadach.
Pytania do Zamawiającego:
Czy Zamawiający potwierdzi, że wykonawca może zaoferować rozwiązanie równoważne, w tym zastąpić odpowiednie istniejące komponenty DDI i ochrony DNS, bez obowiązku dostarczenia lub odnowienia licencji oznaczonych kodami produktowymi wskazanymi w pkt 4.1.1 Wzoru umowy, oraz że dopuszczalna jest inna liczba lub inne rozmieszczenie komponentów niż wskazane w wykazie architektury Kryteriów Równoważności, o ile zachowane zostaną wymagane role, środowiska, zasięg lokalizacji, nadmiarowość, wydajność i izolacja awarii?
W jaki sposób wykonawca oferujący rozwiązanie równoważne ma podać ceny jednostkowe w poz. 1 – 10 Formularza oferty (pkt 26.1.2 SWZ), jeżeli oferowane rozwiązanie licencjonowane jest w innej strukturze niż kody produktowe Infoblox? Czy Zamawiający dostosuje odpowiednio pkt 9.2.1 Wzoru umowy oraz zasady odbioru określone w pkt 6.3 Wzoru umowy?Odpowiedź na pytanie nr 1
Zamawiający dostosował zapisy we Wzorze umowy.
2Sekcja 1 pkt 1.1, 3.1, 3.2, 3.4 i 3.6 Kryteriów Równoważności oraz odpowiadające im postanowienia sekcji 2 – 5, 7 i 8 – komponenty pomocnicze i centralne zarządzanie
Uwagi Wykonawcy:
Kryteria Równoważności wymagają, aby każdy podsystem był dostarczony jako kompletna maszyna wirtualna niezależna od dodatkowych systemów operacyjnych i bibliotek, działał pod kontrolą dedykowanego systemu operacyjnego, był zarządzany z jednego miejsca i przez podsystem zarządzania DDI, a ponadto pełnił funkcję platformy dystrybucji plików i synchronizacji czasu. Wymagania te, rozpatrywane łącznie, opisują sposób pakietowania i zarządzania właściwy rozwiązaniu referencyjnemu. Rozwiązania równoważne w zakresie serwerów proxy, integracji z systemem SIEM, wykrywania urządzeń czy równoważenia obciążenia mogą korzystać z udokumentowanych komponentów pomocniczych i z infrastruktury Zamawiającego, zachowując centralne zarządzanie podstawowymi politykami DDI i bezpieczeństwa DNS.
Wymóg realizacji każdej funkcji w ramach jednego pakietu oprogramowania i z jednego punktu zarządzania wykracza poza uzasadnioną potrzebę spójnego zarządzania i jednoznacznej odpowiedzialności wykonawcy, przez co narusza art. 99 ust. 2 i 4 PZP w zw. z art. 16 pkt 1 i 3 PZP. Cel ten można osiągnąć środkiem mniej restrykcyjnym, wskazanym w proponowanym brzmieniu.
● Pytanie do Zamawiającego:
Czy Zamawiający zaakceptuje udokumentowane komponenty pomocnicze i integracje, o ile oferowane rozwiązanie zapewnia centralne zarządzanie podstawowymi politykami DDI i bezpieczeństwa DNS, filtrowaniem klientów i raportowaniem? Czy infrastruktura chmurowa, wirtualizacyjna, certyfikatów, tożsamości, serwerów proxy, VPN, SIEM i dystrybucji plików może być administrowana za pomocą własnych, obsługiwanych narzędzi?Zamawiający zaakceptuje rozwiązanie składające się z podsystemów pochodzących od różnych producentów pod warunkiem, że całe rozwiązanie będzie w pełni zarządzane przy pomocy maksymalnie 2 konsoli zarządzających.
3Czy Zamawiający potwierdzi, że w połączeniach ze zdalnymi punktami końcowymi oraz przy przekazywaniu zapytań DNS przez sieci publiczne lub niezaufane wymagane jest stosowanie protokołu DoT lub DoH, przy czym ruch szyfrowany może być terminowany na obsługiwanym interfejsie usługi, a interfejs ten może komunikować się z serwerem egzekwującym politykę bezpieczeństwa za pomocą standardowego DNS w wydzielonej, izolowanej sieci usługowej? Czy Zamawiający potwierdzi również, że wymóg szyfrowania nie obejmuje zapytań iteracyjnych kierowanych do publicznych serwerów autorytatywnych?Zamawiający potwierdza, że wymóg szyfrowania nie obejmuje zapytań iteracyjnych kierowanych przez Internet do publicznych serwerów autorytatywnych.
Z zakresie Usługi Ochrony Zapytań DNS (sekcja 6 Warunków Równoważności) w związku z tym, że wymagana jest widoczność co do źródła zapytań DNS w celu np. identyfikacji zainfekowanej maszyny końcowej i że widoczność ta wymaga przesyłania informacji prywatnych Zamawiającego (m.in. prywatny adres IP, nazwa użytkownika), Zamawiający nie dopuści rozwiązania, które tych informacji nie będzie szyfrować, np. używając zwykłego protokołu DNS do komunikacji, lub będzie je szyfrować zamkniętym algorytmem szyfrowania. Wymagane protokoły DNS-over-HTTPS oraz DNS-over-TLS są rozwiązaniami otwartymi używanymi od wielu lat powszechnie przez wielu producentów, opartymi na uznanych i otwartych protokołach szyfrowania. Wymaganie to jest zgodne z najlepszymi praktykami i rekomendacjami, np. rekomendacja CSIRT KNF z czerwca 2026 „Bezpieczne wdrożenie systemu DNS w organizacji”, standard NIST SP 800-81r3 „Secure Domain Name System (DNS) Deployment Guide”, czy Rozporządzenie Wykonawcze nr 14144 Prezydenta USA, z dnia 16 stycznia 2025 pt. „Strengthening and Promoting Innovation in the Nation's Cybersecurity”.
4Pkt 1 i pkt 2 lit. b ppkt 1 OPZ w zw. z pkt 5.2 i 9.2.3.2 Wzoru umowy oraz część „Warunki dotyczące rozwiązania równoważnego” Kryteriów Równoważności – informacje o środowisku, migracja i daty subskrypcji
Uwagi Wykonawcy:
Zastąpienie systemu DDI obsługującego infrastrukturę Zamawiającego wymaga przeniesienia stref DNS, zakresów i rezerwacji DHCP oraz bazy adresacji IP, okresu współistnienia obu systemów, testów, przełączenia i planu powrotu do stanu poprzedniego. Wykonawca nie może rzetelnie wycenić tych prac bez informacji o aktualnej topologii DDI, liczbie obiektów i punktów końcowych, profilach ruchu DNS i DHCP, strefach wewnętrznych, integracjach i oknach serwisowych, których dokumenty Zamówienia nie zawierają.
Niejasne pozostaje również, czy początkowa migracja ma być realizowana w ramach 450 roboczogodzin Prac Rozwojowych (pkt 2 lit. b ppkt 1 OPZ, pkt 9.2.3.2 Wzoru umowy). Pkt 1 OPZ i pkt 5.2 Wzoru umowy wiążą przy tym początek subskrypcji z dniem 26 listopada 2026 r., a jej koniec z dniem 25 listopada 2029 r. Dokumenty Zamówienia nie określają, jak zostaną ustalone daty subskrypcji rozwiązania równoważnego, jeżeli migracja nie zostanie zakończona przed 26 listopada 2026 r.
Brak tych informacji narusza art. 99 ust. 1 PZP, który nakazuje uwzględnić w opisie przedmiotu zamówienia wszystkie wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty.
Wykonawca oferujący rozwiązanie równoważne musiałby wycenić ryzyko, którego nie jest w stanie oszacować i które nie występuje po stronie wykonawcy oferującego rozwiązanie referencyjne, co czyni dopuszczenie równoważności pozornym i narusza art. 99 ust. 4 PZP w zw. z art. 16 pkt 1 i 3 PZP.
Pytania do Zamawiającego:
Czy przed upływem terminu składania ofert Zamawiający udostępni informacje o aktualnej topologii DDI, liczbie obiektów DNS, DHCP i IPAM oraz punktów końcowych, profilach ruchu DNS i DHCP, strefach wewnętrznych, integracjach i oknach serwisowych, a także dopuści przedstawienie przez wykonawcę udokumentowanego planu migracji obejmującego współistnienie systemów, testy, przełączenie i powrót do stanu poprzedniego?
Czy początkowa migracja do rozwiązania równoważnego pomniejsza pulę 450 roboczogodzin Prac Rozwojowych, o której mowa w pkt 9.2.3.2 Wzoru umowy?
W jaki sposób zostaną ustalone daty obowiązywania subskrypcji rozwiązania równoważnego, jeżeli migracja nie zostanie zakończona przed 26 listopada 2026 r., i jak w takim przypadku Zamawiający zapewni ciągłość usług DNS, DHCP i IPAM?Zamawiający dopuścił rozwiązania równoważne, jednak ich wdrożenie nie może spowodować niezachowania ciągłości usług DNS, DHCP i IPAM. Zamawiający jest podmiotem kluczowym z punktu widzenia Ustawy o Krajowym Systemie Cyberbezpieczeństwa (UKSC), gdzie ma jasno sprecyzowane obowiązki w zakresie zapewnienia ciągłości działania systemów i infrastruktury teleinformatycznej i nie może dopuścić rozwiązania, które spowoduje brak ciągłości działania krytycznych usług sieciowych DNS/DHCP, czy braku ochrony przez zagrożeniami po zakończeniu obecnie posiadanych subskrypcji 26 listopada 2026.
5Czy Zamawiający zaakceptuje integrację z systemami SIEM, NAC, skanerami podatności i systemami klasy sandbox faktycznie eksploatowanymi przez Zamawiającego za pośrednictwem udokumentowanego interfejsu REST API, STIX/TAXII, syslog lub obsługiwanych łączników, bez wymogu natywnej obsługi pxGrid i OpenDXL oraz wszystkich wymienionych interfejsów jednocześnie? Prosimy o wskazanie tych systemów, ich wersji, przepływów danych oraz zautomatyzowanych działań, które muszą być obsługiwane.Zamawiający posiada i eksploatuje system NAC Cisco ISE (Identity Service Engine) – dwa klastry i w związku z tym wymaga obsługi szyny pxGrid do integracji z tym systemem. System musi wspierać integrację z systemami bezpieczeństwa SIEM i NAC, skanerami podatności, systemami typu sandbox oraz magistralą pxGrid używanego przez Zamawiającego systemu Cisco ISE (Identity Services Engine).