Licencja systemu DDI Infoblox ze wsparciem – Warszawa
Przedmiot zamówienia
AI- Licencje czasowe 3‑letnie do systemu DDI Infoblox ze wsparciem producenta, aktywacją subskrypcji, wsparciem technicznym Wykonawcy i pracami rozwojowymi dla infrastruktury teleinformatycznej Urzędu m.st. Warszawy: - Pozycja 1: 12 500 szt. - Pozycje 2–10: po 1–3 szt. każda (łącznie 9 pozycji). - Abonament wsparcia technicznego Wykonawcy: 36 miesięcy. - Prace rozwojowe: 450 roboczogodzin.
Trudność: wysoka
Wymaga szczegółowej analizy 10 pozycji licencji, wsparcia technicznego i prac rozwojowych o różnym zakresie.
Terminy realizacji
Termin realizacji
do 29.11.2029 r.
do 29.11.2029 r.
Warunki udziału
AI1Doświadczenie — min. 1 zamówienie polegające na dostarczeniu licencji i wsparciu serwisowym systemu typu DDI w ostatnich 5 lat
2Kadra — min. 2 osoby uczestniczące w realizacji z certyfikatem Core DDI lub DDI Professional Certification (lub wyższym) producenta Infoblox Inc.
Czerwone flagi
AISygnały, na które warto zwrócić uwagę przed startem.
Brak istotnych sygnałów ostrzegawczych.
Kary i sankcje
AI- Wadium: nie wymagane
- Zabezpieczenie należytego wykonania: 2% ceny ofertowej brutto
- Kary umowne: w projekcie umowy (zał. nr 1)
Pytania i odpowiedzi
31Wyodrębnione z wyjaśnień treści SWZ.
1Czy 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?
Zamawiający dostosował zapisy we Wzorze umowy.
2Czy 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”.
4Pytanie nr 4.
Pkt 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).
6Pytanie nr 6.
Sekcja 1 pkt 2.38 – 2.39, sekcja 2 pkt 2.11, sekcja 4 pkt 2.23 – 2.24 i sekcja 7 pkt 4.12
Kryteriów Równoważności – atrybuty obiektów DNS i identyfikacja nieużywanych rekordów
Uwagi Wykonawcy:
Wymagania te nie opisują potrzeby (przypisania odpowiedzialności za strefy i rekordy, porządkowania nieużywanych wpisów), lecz konkretną implementację rozwiązania referencyjnego: mechanizm atrybutów rozszerzalnych z zamkniętym zestawem typów i poziomów wymagalności oraz powiązaną z nim funkcję czyszczenia rekordów opartą na czasie ostatniego zapytania. Rozwiązanie osiągające ten sam cel przy użyciu innego modelu metadanych (np. tagów lub pól niestandardowych innego typu) nie spełni wymogu odczytywanego dosłownie.
Kryterium równoważności skonstruowane wokół modelu danych jednego produktu nie wyznacza dopuszczalnego zakresu odstępstw, lecz opisuje produkt referencyjny, co pozostaje w sprzeczności z art. 99 ust. 5 i 6 PZP. Równoważność nie może oznaczać tożsamości z produktem wskazanym z nazwy, gdyż czyni to dopuszczenie rozwiązań równoważnych pozornym, z naruszeniem zasad wyrażonych w art. 16 pkt 1 i 2 PZP.
Pytanie do Zamawiającego:
Czy Zamawiający zaakceptuje metadane, tagi lub pola niestandardowe definiowane przez Zamawiającego oraz obsługiwany mechanizm identyfikacji nieużywanych rekordów DNS i ich usuwania (automatycznie lub po zatwierdzeniu przez administratora), bez wymogu stosowania identycznych typów atrybutów, poziomów wymagalności, pola czasu ostatniego zapytania i przepływu pracy czyszczenia rekordów jak w rozwiązaniu referencyjnym?
Zamawiający nigdzie w Wymaganiach nie wymaga „atrybutów rozszerzalnych”. Wymaga możliwości stosowania zdefiniowanych przez Zamawiającego atrybutów. Słowa użyte przez Wykonawcę „tag”, „metadane”, „pola niestandardowe” są tu równoznaczne. Atrybuty takie pozwalają na tworzenie relacji pomiędzy różnymi obiektami (czyli powiązań pomiędzy różnymi informacjami), co gwarantuje elastyczność zastosowania bazy danych. Jednak atrybuty bez określenia typu, poziomu wymagalności itp. powodują, że baza danych staje się podatna na błędy ludzkie, co finalnie może skutkować niezachowaniem ciągłości działania sieci. Z kolei brak informacji o ostatnim zapytaniu DNS do danego rekordu DNS uniemożliwia kasowanie rekordów nieużywanych, co powoduje do powstania różnego typu zagrożeń typu „dangling record”, np. możliwości wykorzystania rekordu w zaufanej domenie Zamawiającego do zmylenia i zaatakowania obywateli miasta). Umożliwienie powstawania takich zagrożeń byłoby w niezgodzie z wymaganiami nałożonymi na Urząd Miasta w ramach Ustawy o Krajowym Systemie Cyberbezpieczeństwa.
W związku powyższym Zamawiający pozostawia wymagania w tym zakresie bez zmian.
7Sekcja 1 pkt 2.43, sekcja 2 pkt 2.20, sekcja 4 pkt 2.28 i sekcja 7 pkt 4.21 Kryteriów Równoważności – pojemność stref RPZ
Uwagi Wykonawcy:
Kryteria Równoważności wymagają obsługi stref RPZ o rozmiarze co najmniej 30 mln rekordów przez podsystem zarządzania DDI oraz od 10 do 15 mln rekordów przez podsystemy serwerowe. Dokumenty Zamówienia nie wskazują rzeczywistego rozmiaru aktywnego zbioru danych RPZ wykorzystywanego przez Zamawiającego ani przyczyny, dla której parametr wymagany dla podsystemu zarządzania jest dwu- albo trzykrotnie wyższy niż dla podsystemów serwerowych. Parametr ten może wykluczyć rozwiązania, w których zbiór danych RPZ jest rozłożony na serwery egzekwujące politykę bezpieczeństwa.
Parametr niepowiązany z ujawnioną potrzebą Zamawiającego nie odpowiada wymogowi opisania przedmiotu zamówienia stosownie do uzasadnionych potrzeb (art. 99 ust. 1 i 2 PZP) i jest nieproporcjonalny w rozumieniu art. 16 pkt 3 PZP.
Pytanie do Zamawiającego:
Czy Zamawiający obniży wymaganą w sekcji 1 pkt 2.43 Kryteriów Równoważności pojemność stref RPZ z 30 mln do 20 mln rekordów albo potwierdzi, że wymóg 30 mln rekordów może być spełniony przez rozwiązanie jako całość, z rozłożeniem zbioru danych na poszczególne podsystemy? Prosimy o wskazanie maksymalnego rozmiaru aktywnego zbioru danych RPZ stosowanego obecnie przez Zamawiającego.
Odnośnie wymagania w sekcji 1 pkt 2.43 Kryteriów Równoważności Zamawiający zaakceptuje pojemność 20 mln rekordów w strefach RPZ.
Historia zmian
18.09.2026 — publikacja ogłoszenia