Cześć!

Dziś bierzemy na warsztat temat, który powinien zainteresować każdego admina zarządzającego flotą Samsungów. The Hacker News opublikował niedawno artykuł o tym, jak Samsung Knox pomaga chronić sieć firmową. Artykuł sponsorowany przez Samsunga, więc trzeba go czytać z odpowiednim filtrem marketingowym — ale pod warstwą PR-owego lukru kryją się naprawdę konkretne funkcje, o których warto wiedzieć, bo zmieniają zasady gry.

Prawda jest brutalna: Wasze firmy wydały fortunę na firewalle brzegowe, systemy IDS/IPS i platformy Threat Intelligence dla serwerów. A tymczasem urządzenia mobilne latają pod radarem. Scenariusz z życia? Smartfon handlowca rano łączy się z bezpiecznym Wi-Fi w biurze. W południe łapie darmowy hotspot w kawiarni, żeby wysłać ofertę (i złapać przy okazji „pasażera na gapę”). Wieczorem ląduje w sieci domowej, gdzie obok niego działa zawirusowany laptop dziecka.

Jeśli ten smartfon jest „bramą” do Waszej firmy (a jest), to właśnie zostawiliście ją uchyloną. Dziś sprawdzimy, jak Samsung Knox próbuje ją zatrzasnąć za pomocą dwóch mechanizmów: Knox Firewall i Knox ZTNA Framework.

Jeśli interesuje Was temat bezpieczeństwa mobilnego w kontekście Zero Trust, to dzisiejszy wpis jest naturalnym rozszerzeniem tego, o czym pisałem wcześniej.

Knox Firewall — skalpel zamiast maczety

Większość rozwiązań firewall-owych na urządzeniach mobilnych, z którymi miałem do czynienia, działa binarnie: albo blokujesz ruch, albo go przepuszczasz. Całe urządzenie = jeden wielki przełącznik. To jak leczenie bólu głowy gilotyną – skuteczne, ale mało praktyczne.

Samsung w Knox Firewall podchodzi do tematu inaczej – daje nam kontrolę granularną na poziomie pojedynczej aplikacji (Per-app network controls). Co to oznacza w praktyce admina? Możemy zdefiniować, że aplikacja do przeglądania poufnych dokumentów ma mieć dostęp wyłącznie do konkretnych adresów IP naszych serwerów. Aplikacja do wideokonferencji może łączyć się tylko z zatwierdzonymi domenami dostawcy usługi. Przeglądarka Chrome może mieć zablokowany dostęp do określonych stron. Każda aplikacja dostaje własny „paszport” sieciowy dopasowany do jej profilu ryzyka — nie jest wrzucona do jednego worka z resztą.

Dokumentacja techniczna Knox SDK donosi, że firewall obsługuje cztery typy reguł: Allow (zezwalaj), Deny (blokuj), Redirect (przekieruj) i Redirect Exception (wyjątek od przekierowania). Możemy ciąć ruch po IP, portach, a nawet typie interfejsu (np. blokujemy YouTube na danych komórkowych, ale pozwalamy na Wi-Fi). Obsługiwane są zarówno protokoły IPv4, jak i IPv6 — co w 2026 roku powinno być oczywistością, ale w świecie MDM zdarza się, że nie jest.

Forensics – czyli kto pukał?

Ale nie samo blokowanie jest tu najciekawsze. Moim zdaniem prawdziwą wartość Knox Firewall pokazuje w obszarze widoczności. Gdy użytkownik (lub aplikacja w tle) próbuje połączyć się z zablokowaną domeną, system loguje zdarzenie z pełnym kontekstem: nazwa pakietu aplikacji, która próbowała się połączyć, adres zablokowanej domeny lub IP oraz znacznik czasu zdarzenia. Dla zespołów bezpieczeństwa, które prowadzą threat hunting lub reagują na incydenty, taki poziom szczegółowości potrafi skrócić dochodzenie z kilku dni do kilku godzin.

Knox Firewall wspiera też filtrowanie domen i subdomen — możemy zablokować *.przykład.com jedną regułą, ale jednocześnie zezwolić na bezpieczny.przykład.com. Całość działa zarówno w trybie per-app (reguły per aplikacja), jak i device-wide (reguły dla całego urządzenia).

Co siedzi pod maską?

Co jest istotne z perspektywy wdrożenia: Knox Firewall to nie osobna aplikacja ani agent, który trzeba instalować. Jest wbudowany w architekturę urządzenia Samsung i wykorzystuje mechanizm iptables na poziomie systemu. Konfigurację realizujemy przez Knox Service Plugin (KSP) z poziomu naszego systemu MDM — czy to Knox Manage, Microsoft Intune, czy innego rozwiązania obsługującego KSP, jak np. popularne na polskim rynku rozwiązania od Proget czy Techstep.

Wykorzystanie systemowego mechanizmu iptables (stary, dobry Linux) jest bardzo wydajne, ale… ma swoje humory. Ponieważ bazuje na iptables, może gryźć się z innymi funkcjami korzystającymi z tego samego stosu – np. z tetheringiem czy klientami VPN firm trzecich. Dobra wiadomość jest taka, że od wersji Knox 3.2.1 Samsung przebudował ten proces i teraz połączenia VPN są nawiązywane dopiero po załadowaniu reguł firewalla, co minimalizuje ryzyko konfliktów.

Knox ZTNA Framework — Zero Trust, który nie jest tylko slajdem w prezentacji

O Zero Trust pisałem już w kontekście roli urządzeń mobilnych w tej architekturze i tego, jak Conditional Access w Azure AD pomaga weryfikować zgodność urządzeń przed udzieleniem dostępu do zasobów chmurowych. Knox ZTNA Framework przenosi tę filozofię bezpośrednio na urządzenie.

Tradycyjny VPN to model „Twierdzy”. Jak już wejdziesz do środka (nawiążesz tunel), masz zazwyczaj dostęp do sporej części sieci. Jeśli malware przełamie ten jeden punkt, może hasać po całej infrastrukturze (tzw. Lateral Movement). Knox ZTNA wprowadza mikrosegmentację opartą na hoście. Wyobraź sobie, że wejście do VPN wpuszcza Cię tylko do korytarza. Żeby wejść do konkretnego pokoju (aplikacji), musisz mieć osobny klucz.

Framework obsługuje trzy protokoły: UDP, TCP i DNS. Oferuje split DNS tunneling, który pozwala kierować zapytania DNS selektywnie — wewnętrzne zapytania idą przez tunel ZTNA, a zewnętrzne bezpośrednio do publicznych serwerów DNS. To poprawia zarówno bezpieczeństwo (wewnętrzne nazwy domen nie wyciekają do publicznych resolverów), jak i wydajność (nie przeciążamy tunelu niepotrzebnym ruchem).

Metadata Injection – magia kontekstu

Z perspektywy polityk bezpieczeństwa jedną z najciekawszych cech jest wstrzykiwanie metadanych kontekstowych (metadata injection). Knox ZTNA wzbogaca ruch sieciowy o informacje takie jak nazwa pakietu aplikacji, podpis aplikacji i wersja aplikacji. Te dane trafiają do Policy Decision Point, który decyduje dynamicznie: „Okej, to jest Janek, ale łączy się z przestarzałej wersji Outlooka na zrootowanym telefonie. BLOKUJEMY”. Nie jest to jednorazowa weryfikacja przy logowaniu, jak w przypadku klasycznego VPN — ewaluacja polityk odbywa się przy każdym żądaniu dostępu, na podstawie aktualnego kontekstu urządzenia i aplikacji.

Co ze starym VPN-em?

Knox ZTNA Framework nie zastępuje istniejącego VPN-a. Został został zaprojektowany tak, aby współistnieć z klasycznym VPN. Możecie migrować usługi stopniowo – np. krytyczny CRM puszczacie przez ZTNA, a resztę ruchu starym tunelem.

Aktualnie Knox ZTNA Framework jest dostępny w ramach współpracy Samsunga z Cisco Secure Access. Na urządzeniach zarządzanych (fully managed lub z work profile) wymaga Androida 14 lub nowszego oraz bezpłatnej licencji Knox Platform for Enterprise Premium. Na urządzeniach niezarządzanych (BYOD) działa od Androida 15 wzwyż i nie wymaga licencji KPE — wystarczy, że użytkownik zainstaluje klienta ZTNA ze Sklepu Play. To dość elastyczne podejście, które adresuje zarówno scenariusze z pełnym zarządzaniem, jak i BYOD.

Przewaga integracji, czyli dlaczego to nie jest „kolejny firewall”

Artykuł z The Hacker News słusznie podkreśla jedną rzecz: Knox to nie zbiór osobnych narzędzi, ale zintegrowany system. Sygnały o zagrożeniach przepływają między komponentami platformy w czasie rzeczywistym. Alert o phishingu może automatycznie wywołać nową regułę firewalla. Zmiana stanu zdrowia urządzenia (np. wykrycie roota) może zablokować dostęp do zasobów firmowych bez interwencji administratora.

Cisi ochroniarze: RKP, DEFEX i… komputery kwantowe?

Oprócz warstwy sieciowej (Firewall/ZTNA), Samsung ma potężne zaplecze działające „pod spodem”, o którym marketing mówi rzadziej, a szkoda.

• RKP (Real-time Kernel Protection): monitoruje jądro systemu na żywo. Nawet jeśli haker ominie firewalla, nie zmodyfikuje kernela, bo RKP go zablokuje.
• DEFEX (Defeat Exploit): mechanizm uczący się wzorców. Jeśli kalkulator nagle prosi o roota, DEFEX uznaje to za anomalię i ubija proces.

Ta integracja jest możliwa, bo Knox jest wbudowany w urządzenia Samsung Galaxy — od poziomu chipa, przez jądro systemu, po warstwę aplikacji. Nie potrzebujemy osobnych agentów od trzech różnych dostawców, z których każdy wymaga osobnej licencji, osobnej konsoli i osobnej sesji troubleshootingu. Knox jest certyfikowany SOC 2, gotowy na GDPR i kompatybilny z wiodącymi platformami MDM/UEM/SIEM.

Przy okazji, Samsung nie osiada na laurach i nie próżnuje w innych obszarach bezpieczeństwa sieciowego. W One UI 8, które pojawi się na nadchodzących smartfonach Galaxy, Samsung wprowadza Secure Wi-Fi z szyfrowaniem kwantowo-odpornym (quantum-resistant encryption), certyfikowanym zgodnie ze standardem NIST FIPS 203 (ML-KEM). W praktyce oznacza to ochronę ruchu w publicznych sieciach Wi-Fi z algorytmem, który ma być odporny na ataki z wykorzystaniem komputerów kwantowych. Funkcja oferuje bezpłatną ochronę do 1024 MB miesięcznie na Androidzie 13 i nowszym.

Co z tego wynika dla administratora MDM?

Jeśli zarządzasz flotą urządzeń Samsung przez system MDM (a jeśli czytasz ten blog, to pewnie tak), Knox Firewall i ZTNA Framework dają Ci narzędzia, które jeszcze kilka lat temu były dostępne tylko na stacjach roboczych z pełnymi agentami endpoint security. Granularna kontrola ruchu sieciowego per aplikacja, szczegółowe logi prób dostępu, mikrosegmentacja na poziomie urządzenia, dynamiczna ewaluacja polityk — to wszystko na smartfonie, bez instalowania czegokolwiek dodatkowego.

Jednocześnie trzeba być uczciwym: te zaawansowane funkcje działają w pełni tylko na urządzeniach Samsung Galaxy z aktywowaną licencją Knox Platform for Enterprise. Jeśli Twoja flota to mix producentów (Samsung, Motorola, Xiaomi, Google Pixel), to Knox Firewall i ZTNA Framework nie zadziałają na urządzeniach innych marek. W scenariuszu mieszanej floty nadal potrzebujesz rozwiązania MDM, które zapewni bazowy poziom bezpieczeństwa na wszystkich urządzeniach — a zaawansowane funkcje Knox możesz wykorzystać jako dodatkową warstwę na Samsungach. Pisałem o tym w kontekście ekosystemu Knox Suite i jego trzech planów licencyjnych — warto wrócić do tego artykułu, żeby zobaczyć, które funkcje są dostępne na jakim poziomie.

Moim zdaniem Samsung buduje coś, co można nazwać „defense in depth” na poziomie pojedynczego urządzenia mobilnego. Knox Firewall zapewnia kontrolę na warstwie sieciowej, ZTNA Framework implementuje Zero Trust na warstwie dostępowej, Knox Vault chroni poświadczenia na warstwie sprzętowej, a całość jest zintegrowana z ekosystemem MDM/UEM przez Knox Service Plugin. Jako admin, który spędził tysiące godzin w konsolach różnych MDM-ów, mogę powiedzieć, że Samsung traktuje bezpieczeństwo urządzeń mobilnych poważniej niż większość konkurencji (ehhh, i nikt mi nie zapłacił za taką opinię ¯_(ツ)_/¯). Czy to oznacza, że urządzenie Samsung z Knoxem jest niezdobywalne? Oczywiście nie. Ale z całą pewnością podnosi poprzeczkę tak wysoko, że dla większości zagrożeń staje się nieopłacalnym celem.

Do następnego!