Artykuł pochodzi z wydania: Lipiec-Sierpień 2026
Wprowadzenie na rynek rozwiązania QNAP ADRA NDR (Network Detection and Response) miało być przełomem dla sektora SMB – obietnicą dostarczenia narzędzia klasy Enterprise w cenie akceptowalnej dla mniejszych wrożeń, bez konieczności ponoszenia gigantycznych kosztów licencyjnych u rynkowych potentatów. Czy rozwiązanie spełniło pokładane w nim nadzieje? Odpowiadamy w naszym teście.
Próba wejścia producenta klasycznych pamięci masowych w segment zaawansowanego bezpieczeństwa sieciowego zawsze budzi uzasadniony niepokój wśród inżynierów systemowych. QNAP od lat próbuje udowodnić, że jego urządzenia to coś więcej niż tylko proste kontenery na dyski twarde, serwujące udziały SMB czy cele iSCSI, co zresztą dogłębnie opisywaliśmy na przestrzeni ostatnich lat, obserwując systematyczne rozbudowywanie ekosystemu o wirtualizację, konteneryzację, a teraz o twardą analitykę cyberbezpieczeństwa.
Wprowadzenie QNAP ADRA NDR miało być przełomem w sektorze SMB, ale rzeczywistość bywa jednak brutalna i rzadko pokrywa się z barwnymi folderami marketingowymi. Klasyczne systemy NDR to potężne, autonomiczne platformy analityczne, które konsumują ogromne ilości zasobów, przetwarzając surowy ruch sieciowy i nakładają na niego zaawansowane modele behawioralne. QNAP postanowił podejść do tematu inaczej: stworzyć hybrydę, w której przełącznik sieciowy warstwy dostępnej pełni funkcję sensora i punktu wykonawczego, a serwer NAS staje się mózgiem operacyjnym analizującym anomalie.
Najważniejszym wnioskiem, jaki nasuwa się po przeprowadzeniu naszych testów, jest fakt, że ADRA w swojej obecnej odsłonie to wciąż oprogramowanie w fazie zaawansowanej, publicznej bety, która docelowo ma być oferowana w cenie wybranych urządzeń NAS i przełączników sieciowych, zapewniając podstawowy zakres funkcjonalny NDR. Wypuszczenie na rynek rozwiązania mającego chronić infrastrukturę przed atakami typu ransomware czy lateral movement, które ma fundamentalne błędy w samej logice projektowanej oraz architekturze zarządzania, to ogromne ryzyko. W tym tekście prześwietlimy to narzędzie warstwa po warstwie, bez taryfy ulgowej, skupiając się na jego architekturze, rzeczywistej funkcjonalności oraz problemach, które potrafią sparaliżować pracę administratora.
Architektura i wymagania
Zrozumienie sposobu, w jaki QNAP ADRA funkcjonuje w topologii sieciowej, wymaga porzucenia myślenia o klasycznych sondach NDR, które podpina się pod porty SPAN/TAP dowolnego przełącznika rdzeniowego. QNAP zbudował całkowicie zamknięty, oparty na bezwzględnym vendor lock-inie. Jeśli infrastruktura sieciowa nie jest oparta wyłącznie na specyficznych i wspieranych komponentach tego producenta, wdrożenie ADRA jest technicznie niemożliwe. O ile popularność serwerów NAS QNAP-a wśród klientów z sektora MSP jest niezaprzeczalna, o tyle już budowa sieci oparta na przełącznikach tego producenta pozostaje jedynie w sferze jego ambicji i planów.
Sercem całego systemu w najnowszej wersji jest aplikacja ADRA NDR Standalone (docelowo ADRA NDR X), która wdraża się bezpośrednio na wybranych modelach NAS, działających pod kontrolą systemów operacyjnych QTS lub QuTS hero w wersji minimum 5.2.0. Aplikację instaluje się bezpośrednio ze sklepu App Center, lecz wymaga ona również pobrania dobrze znanego silnika do obsługi kontenerów – Container Station. Z perspektywy zasobów sprzętowych silnik analityczny stawia pewne wymagania. Odpalenie ADRA NDR na budżetowych jednostkach wyposażonych w procesory ARM czy podstawowe układy Intel Celeron się nie uda. Do sprawnej korelacji zdarzeń, parsowania nagłówków i obsługi baz danych logów niezbędny jest wydajny procesor wielordzeniowych klasy x86 (Intel Core, Xeon lub AMD Ryzen/EPYC) oraz minimum 8 GB pamięci RAM, choć w środowisku produkcyjnym, gdzie NAS równolegle obsługuje operacje I/O na dyskach, 16 GB to absolutne minimum. Co więcej, baza danych ADRA drastycznie obciąża podsystem pamięci masowej, co wymusza dedykowanie szybkiej puli dyskowej opartej wyłącznie na nośnikach SSD NVMe lub SATA. Między innymi z tego powodu mój domowy, leciwy TS-253D nie sprostał wymaganiom wstępnym. Do testów dostarczono duet: NAS TVS-h874T, wyposażony w 4 GB RAM oraz procesor Intel Core i9-12900E oraz przełącznik QSW-M3224-24T wyposażony w 24 porty miedziane 10 Gbps.
Drugim, niemniej krytycznym elementem architektury jest warstwa przełączenia. ADRA nie potrafi analizować surowego, masowego ruchu sieciowego z obcych urządzeń. Wymaga przełączników zarządzalnych QNAP z serii QSW, które mają zaimplementowaną natywną komunikację z API systemu ADRA.
Logika przepływu danych w tej architekturze została zaprojektowana tak, aby uniknąć degradacji wydajności sieciowej (co byłoby nieuniknione, gdyby mały NAS próbował przetwarzać ruch 10 Gb/s). Zamiast pełnej inspekcji głebokiej (DPI) każdego pakietu przełączniki QNAP realizują proces selektywnego mirroringu. Na poziomie sprzętowym switcha definiowane są reguły, które wyłapują jedynie metadane pakietów, zapytania ARP, nagłówki sesji TCP/UDP oraz specyficzny ruch powiązany z protokołami podatnymi na ataki (np. SMB, RPC, RDP, SSH). Ten odfiltrowany, lekki strumień danych jest przekazany dedykowanym kanałem do aplikacji ADRA na NAS-ie. W ten spoób ruch produkcyjny (masowe transfery plików do i z macierzy) trafia bezpośrednio do celu z pełną prędkością przełączenia, a silnik analityczny dostaje jedynie esencję niezbędną do wykrywania anomalii.
[…]
Marcin Jurczyk
Autor pracuje jako architekt w międzynarodowej firmie świadczącej usługi IT i posiada doświadczenie w zakresie projektowania i integracji systemów na poziomie infrastruktury, chmury i sieci.
