Archiwum EB2BCPV 32000000 · Sprzęt radiowy i telekomunikacyjnyCPV 48000000 · Pakiety oprogramowaniaCPV 50000000 · Usługi naprawcze i konserwacyjne Mazowieckie
Dostawa urządzeń Application Delivery Controller (ADC) z wbudowaną obsługą funkcji Web
Pełna nazwa postępowania: Dostawa urządzeń Application Delivery Controller (ADC) z wbudowaną obsługą funkcji Web Application Firewall (WAF) oraz Global Server Load Balancing (GSLB) w ramach projektu CCN
Naukowa i Akademicka Sieć Komputerowa - Państwowy Instytut Badawczy·NIP 5210417157·Warszawa
Wartość szac.
4 000 000 zł
wg ogłoszenia
Termin składania
06.07.2026
postępowanie zakończone
Otwarcie ofert
—
nie podano
Opublikowano
22 maja 2026
źródło: EB2B
Streszczenie SWZ
Streszczenie AI · Janusz
Widzisz połowę każdej z 10 sekcjiDruga połowa — łącznie 21 zdań z warunkami, dokumentami i analizą ryzyka — odsłania się po założeniu darmowego konta.
Nazwa postępowania: Dostawa urządzeń Application Delivery Controller (ADC) z wbudowaną obsługą funkcji Web Application Firewall (WAF) oraz Global Server Load Balancing (GSLB) w ramach projektu CCN.
Znak postępowania: ZZOSE.2611.10.2026.171.PKK[CCN].
Typ zamówienia: Dostawy.
Tryb udzielenia zamówienia: Przetarg nieograniczony.
Postępowanie prowadzone jest w trybie przetargu nieograniczonego na podstawie ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych (t.j. Dz.U. z 2024 r., poz. 1320 ze zm.). (+ 2 zdania — pełna treść po zalogowaniu)
Zamawiający zamierza przeznaczyć na sfinansowanie zamówienia łączną kwotę 4 000 000,00 zł brutto. Zamówienie jest współfinansowane ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach programu „Fundusze Europejskie na Rozwój Cyfrowy 2021-2027” (Działanie FERC.02.02).
5
Terminy
Widoczne 50%
Terminy realizacji poszczególnych elementów zamówienia:
Dostawa Urządzeń, Oprogramowania i Dokumentacji: do 4 tygodni od dnia zawarcia Umowy.
Przeprowadzenie dwóch szkoleń: do 12 tygodni od dnia zawarcia Umowy.
Zamawiający postawił następujące wymagania dotyczące zdolności technicznej lub zawodowej:
Wykonawca musi dysponować zespołem co najmniej 2 inżynierów dedykowanych do realizacji usług wdrożeniowych oraz wsparcia technicznego.
Każdy z inżynierów musi posiadać udokumentowane doświadczenie praktyczne we wdrażaniu urządzeń Application Delivery Controller (ADC), Web Application Firewall (WAF) oraz Global Server Load Balancing (GSLB), obejmujące:
zaawansowaną konfigurację funkcji ADC (m.in. inteligentny Load Balancing L4-L7, optymalizację protokołu HTTP/2, kompresję danych),
zarządzanie politykami WAF w oparciu o modele pozytywne i negatywne (ochrona przed OWASP Top 10),
Podwykonawstwo: Zamawiający dopuszcza udział podwykonawców. Wykonawca odpowiada za prawidłową realizację zamówienia w całości. Wymagane wskazanie części zamówienia powierzonych podwykonawcom oraz ich nazw (o ile są znani). Zmiana podwykonawcy w zakresie, na którego zasoby Wykonawca się powoływał, wymaga wykazania, że nowy podwykonawca lub Wykonawca spełnia warunki w stopniu nie mniejszym.
Zmiany umowy: Przewidziana możliwość zmiany umowy w zakresie uregulowanym w art. 454-455 ustawy Pzp oraz we Wzorze Umowy (Załącznik nr 5).
RODO: Administratorem danych jest Zamawiający (NASK-PIB). Dane przetwarzane w celu prowadzenia postępowania o udzielenie zamówienia. Podanie danych jest dobrowolne, ale konieczne. Brak zautomatyzowanego podejmowania decyzji i profilowania.
Z każdej z 10 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 21 zdań — pełne warunki udziału, dokumenty i analizę ryzyka Janusza. Bez karty, 14 dni za darmo.
14 dni za darmo Bez karty płatniczej Rezygnacja w 1 klik
Opis przedmiotu zamówienia
Streszczenie AI · Janusz
Przedmiotem zamówienia jest dostawa infrastruktury sieciowej wraz z usługami towarzyszącymi:
4 urządzenia typu Application Delivery Controller z funkcją Web Application Firewall
4 urządzenia typu Global Server Load Balancing
1 system centralnego zarządzania rozwiązaniem
68 wkładek światłowodowych (różne standardy)
30 patchcordów światłowodowych
120 godzin asysty technicznej inżyniera
2 szkolenia dla 8 osób (poziom podstawowy i zaawansowany)
3-letni serwis gwarancyjny oraz wsparcie techniczne dla wszystkich dostarczonych urządzeń
Pytania i odpowiedzi
Wyjaśnienia treści SWZ udzielone przez zamawiającego. Odpowiedzi wiążą wszystkich wykonawców — także tych, którzy nie zadali pytania.
Zamawiający wymaga, aby potencjał kadrowy (warunek udziału w postępowaniu opisany w
Rozdziale V ust. 3 pkt 4) SWZ) zakładał posiadanie dwóch osób z certyfikatami. Czy Zamawiający
dopuści do udziału w postępowaniu oferenta, który aktualnie posiada aktualnie jedną osobę z
najwyższym certyfikatem u proponowanego producenta rozwiązań?
Zamawiający nie wyraża zgody na zmianę warunku w powyższym zakresie.
Opisując wymagania platformy ADC w punkcie III.28 Zamawiający określił, że „Urządzenia muszą zapewniać ochronę przed atakami DDoS”. Czy w związku z tym Zamawiający oczekuje rozwiązania, które zapewnia ochronę sprzętowa przed atakami DDOS na poziomie nie mniejszym niż 150 milionów SYN Cookies na sekundę?
Zamawiający wymaga, aby mitygacja najpopularniejszych wektorów ataków DDoS (w tym typu SYN Flood za pomocą mechanizmu SYN Cookies) była realizowana obligatoryjnie w warstwie sprzętowej (z wykorzystaniem dedykowanej akceleracji ASIC/FPGA/procesorów sieciowych), w sposób całkowicie odciążający główne procesory systemu.
Zamawiający wyjaśnia jednocześnie, że nie potwierdza i nie wymaga wskazanego przez Wykonawcę sztywnego limitu wydajności na poziomie minimum 150 milionów SYN Cookies na sekundę. Intencją Zamawiającego jest rezygnacja z narzucania konkretnych, liczbowych limitów wydajnościowych dla tego parametru.
W związku z powyższym Zamawiający dokonuje zmiany treści SWZ - patrz zmiana nr 1.
Opisując wymagania platformy ADC w punkcie III.28 Zamawiający określił, że „Urządzenia muszą zapewniać ochronę przed atakami DDoS”. Czy w związku z tym Zamawiający oczekuje rozwiązania, które powinno obsłużyć́ sprzętowo (za pomocą dedykowanego hardwaru) mitygację minimum 90 wektorów ataków DDoS w warstwie L3/4 oraz na DNS?
Zamawiający nie wymaga, aby zaoferowane urządzenia realizowały mitygację sztywno określonej liczby (minimum 90) wektorów ataków DDoS z użyciem wyłącznie dedykowanych układów sprzętowych (hardware). Wymóg z pkt III.28 SOPZ zakłada dostarczenie skutecznej ochrony przed atakami DDoS dla warstw L3, L4 oraz DNS. Zamawiający dopuszcza nowoczesne systemy klasy ADC/DDoS czołowych producentów rynkowych, w tym rozwiązania działające w oparciu o architekturę hybrydową, tj. sprzętową ochronę ataków wolumetrycznych na poziomie L3/L4 oraz programową ochronę do obsługi skomplikowanych ataków np. na protokół DNS.
Opisując wymagania platformy ADC w punkcie III.28 Zamawiający określił, że „Urządzenia muszą zapewniać ochronę przed atakami DDoS”. Czy w związku z tym Zamawiający oczekuje rozwiązania, które powinno posiadać mechanizmy ochrony przed atakami DoS ukierunkowanymi również na warstwę aplikacyjną (np. ochronę przed atakiem Slow Loris) oraz zawierać moduł sztucznej inteligencji, który na bieżąco obserwuje ruch od użytkowników końcowych, celem budowy i utrzymania modelu prawidłowego ruchu do aplikacji. Na podstawie behawioralnej analizy tego ruchu i zbudowanego modelu, powinien wykrywać i chronić aplikację przed atakiem DDoS w warstwie 7?
Zamawiający wymaga, aby zaoferowane rozwiązanie chroniło przed atakami DoS/DDoS w warstwie aplikacyjnej (L7), w tym m.in. przed atakami typu Slow Loris. Zamawiający wymaga również, aby system miał możliwość profilowania ruchu i na jego podstawie wykrywać oraz mitygować anomalie.
Jednocześnie Zamawiający informuje, że nie narzuca, aby ta funkcjonalność była realizowana wyłącznie przez wyodrębniony "moduł sztucznej inteligencji". Zamawiający w ramach równoważności dopuszcza zastosowanie zaawansowanych mechanizmów uczenia maszynowego, heurystyki, zautomatyzowanej analizy statystycznej lub innych autorskich systemów profilowania ruchu danego producenta.
Wymaganiem Zamawiającego jest osiągnięcie skutecznego efektu funkcjonalnego – to jest ochrony warstwy 7 na podstawie analizy zachowań (anomalii) i budowania modelu prawidłowego ruchu – bez ograniczania się do specyficznej nomenklatury marketingowej czy technologicznej jednego producenta (jak np. "moduł AI").
Opisując wymagania platformy ADC w punkcie III.28 Zamawiający określił, że „Urządzenia muszą zapewniać ochronę przed atakami DDoS”. W związku z tym, iż ataki DDoS są przeprowadzane z sieci botów, czy rozwiązanie powinno kategoryzować boty i umożliwiać przepuszczanie ruchu od pożytecznych botów (np. search enginy), blokując ruch od szkodliwych botów, np. na podstawie sygnatur botów?
Zamawiający oczekuje, aby zaoferowane urządzenia w ramach ochrony przed atakami DDoS w warstwie aplikacyjnej posiadały mechanizmy pozwalające na identyfikację, klasyfikację oraz kontrolę ruchu generowanego przez automatyczne programy (boty). Rozwiązanie musi umożliwiać blokowanie lub ograniczanie ruchu pochodzącego od botów szkodliwych (złośliwych), przy jednoczesnym zapewnieniu niezakłóconego dostępu dla botów pożytecznych (np. robotów indeksujących znanych wyszukiwarek internetowych).
Zamawiający dopuszcza realizację tego wymagania za pomocą dowolnych, równoważnych mechanizmów obsługiwanych przez oferowane rozwiązanie. Celem Zamawiającego jest uzyskanie efektu funkcjonalnego w postaci ochrony przed złośliwym ruchem zautomatyzowanym, bez narzucania konkretnego sposobu licencjonowania czy nazewnictwa modułów technologicznych poszczególnych producentów.
Opisując wymagania platformy ADC w punkcie III.28 Zamawiający określił, że „Urządzenia muszą zapewniać ochronę przed atakami DDoS”. W związku z tym, iż ataki DDoS są przeprowadzane z sieci botów, czy rozwiązanie powinno rozróżniać rzeczywistych użytkowników od automatów poprzez wstrzykiwanie skryptu JavaScript, weryfikacji rezultatów jego wykonania po stronie klienta tylko za pomocą zasobów lokalnych na urządzeniu (bez integracji z chmurą) i na tej podstawie blokowanie podejrzanych zautomatyzowanych żądań?
Zamawiający potwierdza, że oczekuje od zaoferowanego rozwiązania zdolności do skutecznego rozróżniania rzeczywistych użytkowników od automatów (botów), m.in. poprzez mechanizmy aktywnego badania klienta (takie jak wstrzykiwanie i weryfikacja wykonania skryptów JavaScript, CAPTCHA, wyzwania kryptograficzne czy obsługa cookies).
Jednocześnie Zamawiający wyjaśnia, że nie ogranicza architektury systemu wyłącznie do realizacji tych zadań za pomocą zasobów lokalnych urządzenia bez integracji z chmurą.
Zadajcie pytanie, które już macie o definicję threat intelligence i czy chcą subskrypcję IPI. Co wg Zamawiającego oznacza termin threat intelligence w tym zdaniu "WAF musi mieć możliwość automatycznego pobierania i aktualizacji list reputacyjnych (threat intelligence),"
Przez termin „threat intelligence” w kontekście opisanego wymagania Zamawiający rozumie zautomatyzowane usługi dostarczania i aktualizacji baz danych zawierających informacje o globalnych zagrożeniach sieciowych. W szczególności dotyczy to dynamicznych list reputacyjnych adresów IP, podsieci, domen oraz adresów URL powiązanych ze szkodliwą działalnością (taką jak: botnety, hosty dystrybuujące malware, serwery Command & Control, węzły wyjściowe sieci TOR, otwarte proxy czy znane źródła ataków DDoS).
Zamawiający wymaga dostarczenia stosownej subskrypcji (licencji) na dostęp do wyżej wymienionych baz danych reputacyjnych na cały okres wymagany w SOPZ.
Jednocześnie Zamawiający wyjaśnia, że nie narzuca konkretnej nazwy handlowej tej usługi. Zamawiający dopuszcza wszelkie równoważne licencje/subskrypcje wiodących producentów rozwiązań ADC/WAF, które realizują opisany cel funkcjonalny automatycznej aktualizacji list reputacyjnych.
Zamawiający w punkcie V.4. określił wymaganie "Do raportowania/analiz wysyłanych do zarządzania w chmurze mogą być używane wyłącznie metadane (bez faktycznego ruchu klienta)." Zapis jest niezrozumiały, prosimy o szczegółowe opisanie tego wymagania.
Zamawiający wyjaśnia, że intencją zapisu w punkcie V.4 jest zapewnienie bezpieczeństwa oraz prywatności przetwarzanych danych (zgodnie z RODO/GDPR).
Poprzez sformułowanie, że do systemów raportowania/analiz w chmurze mogą być wysyłane wyłącznie metadane (bez faktycznego ruchu klienta), Zamawiający rozumie, że zabronione jest przesyłanie pełnej, surowej zawartości pakietów danych (tzw. packet payload). System zarządzania w chmurze nie może wymagać ciągłego przekazywania (np. w formie mirroringu całego ruchu) właściwej treści danych przesyłanych przez użytkowników końcowych do aplikacji (takich jak: zawartość wpisywanych formularzy, hasła, dane osobowe, pliki przesyłane przez użytkowników itp.).
W punkcie I.9. Zamawiający opisał wymaga dotyczące separacji. Czy w ramach separacji Zamawiający oczekuje również podziału urządzenia na wirtualne systemy (tenanty), z których każdy będzie odseparowany galwanicznie, tzn. będzie posiadał dedykowane zasoby sprzętowe takie jak: CPU, RAM, storage i nie będzie ich współdzielił z pozostałymi tenantami? Podział na tenanty zapewnia: bezpieczeństwo, separację ról, zespołów, funkcji oraz umożliwia większą elastyczność we wdrożeniu i lepsze (optymalniejsze) wykorzystanie zasobów urządzenia.
Zamawiający wyjaśnia, że wymaganie określone w punkcie I.9 dotyczy wyłącznie odseparowania płaszczyzny zarządzania (management plane) od płaszczyzny przetwarzania ruchu sieciowego (data plane) w ramach architektury pojedynczego urządzenia. Celem tego zapisu jest zagwarantowanie, że nawet w warunkach krytycznego obciążenia ruchem sieciowym lub w trakcie odpierania ataków DDoS, administrator zachowa pełną i stabilną kontrolę nad urządzeniem.
Zamawiający określił, że urządzenie ma wspierać VLANy w standardzie 802.1q, LACP, itp. Czy Zamawiający oczekuje, że rozwiązanie powinno posiadać również funkcjonalność bramy VXLAN oraz NVGRE? Wsparcie dla funkcji bramy VXLAN oraz NVGRE jest wymagane w celu zapewnienia integracji środowisk fizycznych i zwirtualizowanych, umożliwienia komunikacji pomiędzy różnymi domenami overlay oraz zapewnienia skalowalności i elastyczności architektury sieciowej w nowoczesnych środowiskach centrów danych i chmur prywatnych.
Zamawiający modyfikuje zapisy SOPZ w ten sposób, że wymaga, aby oferowane urządzenia wspierały funkcjonalność bramy oraz terminacji tuneli VXLAN w celu zapewnienia integracji lokalnego środowiska (on-premise) ze środowiskami zwirtualizowanymi oraz umożliwienia pełnej kompatybilności sieciowej w architekturze hybrydowej z chmurami publicznymi (np. Microsoft Azure, Amazon Web Services, Google Cloud Platform).
Jednocześnie Zamawiający informuje, że nie wymaga wsparcia dla technologii NVGRE.
W związku z powyższym Zamawiający dokonuje zmiany treści SWZ - patrz zmiana nr 2.
Czy Zamawiający posiada szacowany lub historyczny podział ruchu DNS na zapytania:
- autorytatywne,
- rekurencyjne,
- obsłużone z cache,
- wymagające dalszego odpytywania zewnętrznych serwerów DNS?
Zamawiający informuje, że nie dysponuje szczegółowymi, historycznymi danymi ani szacunkami dotyczącymi procentowego lub ilościowego podziału ruchu DNS na zapytania autorytatywne, rekurencyjne, obsłużone z pamięci podręcznej (cache) oraz wymagające dalszego odpytywania serwerów zewnętrznych.
Wykonawca powinien założyć, że oferowane rozwiązanie/system musi być gotowe na obsługę pełnego profilu ruchu sieciowego, optymalizację zapytań poprzez mechanizmy cache oraz wydajną obsługę zapytań rekurencyjnych i autorytatywnych zgodnie z ogólnymi wymaganiami wydajnościowymi określonymi w SOPZ (np. całkowita liczba zapytań na sekundę - QPS).
Pokazujemy 11 z 16 pytań. Komplet wyjaśnień — razem z załącznikami, których dotyczą — jest w dokumentacji postępowania.
