Architektura Zero Trust: kompletny przewodnik wdrożenia

Firma wybiera narzędzie do zarządzania tożsamością, wymienia sieć VPN na usługę ZTNA albo uruchamia uwierzytelnianie wieloskładnikowe, a dopiero później próbuje ustalić, kto właściwie powinien mieć dostęp do jakich danych i aplikacji. Efekt bywa znajomy: więcej powiadomień, kolejne panele administracyjne i poczucie, że bezpieczeństwo kosztuje coraz więcej, ale nadal trudno powiedzieć, co dokładnie zostało zabezpieczone.

Architektura Zero Trust nie jest produktem, który można wdrożyć w piątek po południu i odhaczyć w planie transformacji cyfrowej. To sposób projektowania dostępu do zasobów, w którym nie ufamy automatycznie użytkownikowi tylko dlatego, że znajduje się w biurze, korzysta z firmowego komputera albo raz poprawnie się zalogował. Każda sesja powinna być oceniana na podstawie tożsamości, stanu urządzenia, kontekstu i ryzyka.

Dla founderów i osób odpowiedzialnych za IT oznacza to zmianę kolejności myślenia. Najpierw rozpoznajemy firmę taką, jaka naprawdę jest — z rozproszonymi aplikacjami, dostawcami, kontami byłych pracowników i urządzeniami prywatnymi — a dopiero potem projektujemy zabezpieczenia. Właśnie tak wygląda rozsądne wdrożenie architektury Zero Trust krok po kroku.

Zero Trust to proces, nie „bezpieczeństwo w pudełku”

Nazwa może brzmieć jak obietnica radykalnego odcięcia wszystkiego i rozpoczęcia pracy od pustej kartki. W praktyce chodzi o coś bardziej przyziemnego, ale też trudniejszego: o odejście od domyślnego zaufania.

W klasycznym modelu bezpieczeństwa sieć dzieli się często na część wewnętrzną i zewnętrzną. Jeśli użytkownik przejdzie przez bramę VPN albo znajdzie się w biurze, otrzymuje dostęp do określonego segmentu sieci, a później systemy wewnętrzne zakładają, że jest „swój”. To podejście przez lata było wygodne, szczególnie gdy większość pracowników korzystała z komputerów w jednym biurze i łączyła się z kilkoma serwerami należącymi do firmy.

Dzisiaj ten obraz jest już mocno nieaktualny. Dane są w chmurze, aplikacje działają jako usługi, zespoły pracują z różnych miejsc, a część procesów obsługują zewnętrzni partnerzy. Do środowiska firmowego trafiają laptopy, telefony, urządzenia IoT, konta automatyzacji i interfejsy programistyczne. Granica między „wewnątrz” i „na zewnątrz” przestała być oczywista.

Zero Trust odpowiada na ten problem zasadą: nie ufaj domyślnie, zawsze weryfikuj i przyznawaj najmniejszy potrzebny zakres uprawnień. Nie oznacza to, że każdy pracownik będzie za każdym razem przechodził długą kontrolę bezpieczeństwa. Oznacza natomiast, że decyzja o dostępie nie powinna opierać się wyłącznie na adresie IP, lokalizacji użytkownika czy fakcie wcześniejszego zalogowania.

Standard NIST SP 800-207, opublikowany w sierpniu 2020 roku, opisuje siedem podstawowych zasad architektury Zero Trust. Wśród nich znajduje się traktowanie wszystkich źródeł danych i usług jako zasobów, ochrona wszystkich komunikacji niezależnie od lokalizacji oraz przyznawanie dostępu na poziomie pojedynczej sesji. System powinien również stale monitorować stan zasobów, zbierać informacje o bezpieczeństwie i automatycznie reagować na zmiany ryzyka.

Zero Trust nie usuwa zaufania z biznesu. Usuwa tylko zaufanie przyznane na zapas, bez sprawdzenia, czy nadal jest potrzebne.

Warto też od razu odsunąć jeden mit: nie istnieje jedno urządzenie ani jedna aplikacja, która „wdraża Zero Trust”. Możemy kupić system zarządzania tożsamością, usługę dostępu do aplikacji, narzędzia do ochrony urządzeń czy platformę analityczną, ale żadna z tych rzeczy samodzielnie nie tworzy całej architektury. Jeśli nie wiemy, jakie zasoby posiadamy, kto z nich korzysta i które procesy są krytyczne, technologia będzie jedynie kosztowną warstwą nad chaosem.

Od inwentaryzacji do polityki dostępu

Wdrożenie warto rozpocząć od inwentaryzacji. Brzmi mało efektownie, zwłaszcza gdy zarząd oczekuje szybkiego projektu z widocznym rezultatem, ale bez tego kroku nie da się sensownie ustalić priorytetów. Celem nie jest stworzenie idealnego katalogu na potrzeby audytu. Chodzi o uzyskanie odpowiedzi na kilka bardzo praktycznych pytań: jakie zasoby chronimy, kto ich używa, w jaki sposób się z nimi łączy i co stanie się z firmą, jeśli dany system przestanie działać albo wyciekną z niego dane.

NIST SP 800-207 opisuje siedem kroków migracji do architektury Zero Trust:

1. Identyfikacja aktorów — trzeba rozpoznać nie tylko pracowników, lecz także administratorów, klientów, dostawców, konta techniczne, aplikacje i automatyczne procesy wykonujące działania w imieniu użytkownika.

2. Identyfikacja zasobów — na liście powinny znaleźć się aplikacje, bazy danych, repozytoria kodu, systemy finansowe, urządzenia, interfejsy API oraz dane przechowywane w usługach chmurowych.

3. Rozpoznanie kluczowych procesów i ocena ryzyka — nie każda aplikacja ma taką samą wagę. System księgowy, panel do zarządzania produkcją i narzędzie do komunikacji z klientami mogą wymagać zupełnie różnych reguł.

4. Sformułowanie polityk dostępu — dopiero tutaj określamy, kto, z jakiego urządzenia, w jakim kontekście i na jak długo może korzystać z konkretnego zasobu.

5. Identyfikacja punktów egzekwowania polityki — należy ustalić, gdzie decyzja będzie fizycznie wymuszana: przy aplikacji, na urządzeniu, w bramie dostępowej czy w kilku miejscach jednocześnie.

6. Wstępne wdrożenie i monitorowanie — pierwsza wersja powinna objąć ograniczony, dobrze wybrany zakres, aby można było obserwować skutki bez ryzyka sparaliżowania firmy.

7. Rozszerzanie architektury — po zebraniu danych i poprawieniu reguł można obejmować ochroną kolejne aplikacje, zespoły i procesy.

W tym podejściu szczególnie ważne jest rozdzielenie decyzji od jej wykonania. W logicznym modelu NIST punkt decyzyjny składa się z silnika polityk oraz administratora polityk. Silnik ocenia, czy dostęp powinien zostać przyznany, administrator przekazuje tę decyzję dalej, a punkt egzekwowania polityki blokuje albo zezwala na połączenie. W codziennym środowisku nie musimy oczywiście budować tych elementów ręcznie, ale warto rozumieć ich role. Dzięki temu łatwiej ocenić, czy wybrane rozwiązanie rzeczywiście podejmuje decyzję na podstawie kontekstu, czy tylko zastępuje jeden rodzaj bramy inną.

Co powinno trafić do pierwszego zakresu wdrożenia?

Nie zaczynajmy od wszystkich systemów naraz. Najlepszym kandydatem jest zwykle aplikacja, która ma dużą wartość biznesową, wielu użytkowników i wyraźny problem z kontrolą dostępu, ale nie steruje bezpośrednio procesem, którego awaria zatrzymałaby całą firmę.

Dobry pierwszy zakres może obejmować:

• dostęp administratorów do najważniejszych usług chmurowych;
• system finansowy lub kadrowy, w którym znajdują się dane wrażliwe;
• panel klienta używany przez pracowników i zewnętrznych wykonawców;
• repozytoria kodu oraz środowiska deweloperskie;
• dostęp zdalny do jednej konkretnej aplikacji zamiast do całego segmentu sieci.

Taki wybór pozwala zebrać dane o zachowaniach użytkowników, liczbie wyjątków i jakości istniejącej ewidencji urządzeń. Pokazuje też, gdzie organizacja naprawdę ma problem. Czasami nie jest nim brak kolejnej funkcji bezpieczeństwa, lecz fakt, że pięć zespołów korzysta z tego samego konta administratora, a były wykonawca nadal znajduje się na liście aktywnych użytkowników.

Pięć filarów CISA, czyli jak nie zgubić połowy obrazu

NIST daje nam zasady i ścieżkę migracji, natomiast model dojrzałości CISA Zero Trust Maturity Model v2.0 pomaga spojrzeć na organizację szerzej. Został zaktualizowany w kwietniu 2023 roku i opiera się na pięciu filarach oraz trzech zdolnościach przekrojowych.

Pięć filarów to:

Pierwszy filar, czyli tożsamość, jest zazwyczaj najbardziej widoczny. Włączamy uwierzytelnianie wieloskładnikowe, porządkujemy grupy i zaczynamy odbierać uprawnienia osobom, które zmieniły stanowisko. To dobry początek, ale nie pełna architektura. Sam fakt, że użytkownik potwierdził logowanie w aplikacji, nie mówi jeszcze, czy korzysta z zarządzanego urządzenia, czy jego konto zachowuje się normalnie i czy powinien mieć dostęp do całej bazy danych.

Filar urządzeń bywa dla przedsiębiorstw bardziej kłopotliwy, niż zakładają na początku. W organizacji pojawiają się stare laptopy, prywatne telefony, komputery wykonawców, urządzenia bez aktualnych poprawek i sprzęt, którego nikt formalnie nie przypisał do konkretnej osoby. Jeśli system nie zna stanu urządzenia, trudno budować wiarygodną politykę dostępu. Uwierzytelniony użytkownik na niezarządzanym komputerze nadal może stanowić wysokie ryzyko.

Sieci, aplikacje i dane wymagają jeszcze większej dyscypliny. W wielu firmach dane są zabezpieczone na poziomie całego systemu, choć tylko kilka osób powinno widzieć konkretny typ informacji. Zespół sprzedaży potrzebuje danych klientów, ale niekoniecznie pełnego dostępu do tabel rozliczeniowych. Programista może potrzebować środowiska testowego, ale nie produkcyjnej bazy danych. Administrator powinien mieć możliwość wykonania konkretnej operacji, a nie stałe, nieograniczone uprawnienia do wszystkiego.

CISA uzupełnia pięć filarów o trzy zdolności przekrojowe: widoczność i analitykę, automatyzację i orkiestrację oraz zarządzanie. To właśnie one decydują, czy polityki będą działały w codziennym środowisku. Bez widoczności nie zauważymy anomalii, bez automatyzacji nie zareagujemy wystarczająco szybko, a bez zarządzania każda decyzja będzie zależała od pamięci i dobrej woli pojedynczego administratora.

Model CISA wyróżnia cztery poziomy dojrzałości: tradycyjny, początkowy, zaawansowany i optymalny. Nie chodzi o to, aby od razu przeskoczyć na ostatni poziom. Dla mniejszej firmy rozsądniejszym celem może być ograniczenie niekontrolowanych kont, objęcie kluczowych aplikacji silnym uwierzytelnianiem i uzyskanie podstawowej wiedzy o urządzeniach. Dopiero później przychodzi czas na zaawansowane reguły oparte na ryzyku, automatyczne reakcje i drobiazgową mikrosegmentację.

VPN i ZTNA: nie chodzi o nazwę, tylko o zakres dostępu

Migracja z tradycyjnej sieci VPN do ZTNA jest jednym z najczęściej omawianych elementów Zero Trust, ale łatwo tu o zbyt prostą narrację. VPN nie staje się nagle bezużyteczny tylko dlatego, że pojawił się nowy model dostępu. W wielu organizacjach przez pewien czas oba rozwiązania będą działały równolegle, a zadaniem zespołu będzie bezpieczne przenoszenie kolejnych zastosowań.

Różnica polega przede wszystkim na zakresie dostępu. VPN często łączy użytkownika z całym segmentem sieci. Jeśli po zalogowaniu pracownik może zobaczyć wiele usług, z których nie korzysta, organizacja powiększa potencjalny obszar ataku. ZTNA tworzy mikro-tunel bezpośrednio do konkretnej, autoryzowanej aplikacji. Użytkownik otrzymuje dostęp do zasobu, a nie przepustkę do całej sieci.

To podejście ogranicza możliwość ruchu bocznego po wstępnym naruszeniu. Jeżeli napastnik przejmie konto albo sesję, nie powinien automatycznie móc przemieszczać się pomiędzy systemami. To szczególnie istotne, ponieważ według przywoływanych w branży danych średni czas od początkowego naruszenia do rozpoczęcia ruchu bocznego może wynosić około 84 minut. Dla zespołu bezpieczeństwa nie jest to dużo czasu na odkrycie problemu, odcięcie konta i sprawdzenie kolejnych systemów.

ZTNA nie rozwiązuje jednak problemu niewłaściwych uprawnień. Jeśli polityka mówi, że użytkownik ma dostęp do zbyt wielu aplikacji, mikro-tunel po prostu bezpieczniej dostarczy go do zbyt wielu aplikacji. Dlatego kolejność jest niezmienna: najpierw inwentaryzacja zasobów i procesów, następnie projekt polityk, a dopiero później wybór technologii dostępowej.

Przy projektowaniu przejścia warto zapytać:

• Czy użytkownik potrzebuje dostępu do całej sieci, czy tylko do jednej aplikacji?
• Czy aplikacja działa lokalnie, w chmurze, czy w środowisku mieszanym?
• Czy dostęp powinien być stały, czasowy, czy przyznawany tylko na czas wykonania konkretnego zadania?
• Czy dostawca zewnętrzny musi widzieć dane, czy wystarczy mu możliwość wykonania określonej operacji?
• Co ma się stać, gdy urządzenie straci zgodność z wymaganiami albo zachowanie konta nagle się zmieni?

W dobrze zaprojektowanym środowisku odpowiedzi nie są zaszyte w jednym, niezmiennym profilu użytkownika. Zależą od kontekstu. Logowanie z zarządzanego komputera w znanej lokalizacji może przejść bez dodatkowego kroku. Dostęp do tej samej aplikacji z nieznanego urządzenia, po nietypowej godzinie i z nowej lokalizacji powinien uruchomić dodatkową weryfikację albo zostać zablokowany.

Uwierzytelnianie wieloskładnikowe nie wystarczy

Włączenie MFA jest jednym z najbardziej sensownych pierwszych ruchów w kierunku Zero Trust, lecz również tutaj liczy się sposób wykonania. Najprostszy model oparty na zatwierdzaniu powiadomień w telefonie może poprawić bezpieczeństwo, ale nie jest odporny na wszystkie scenariusze.

Atakujący, który zdobędzie hasło, może wielokrotnie wysyłać powiadomienia z prośbą o potwierdzenie logowania. Użytkownik, zmęczony kolejnymi komunikatami albo przekonany, że aplikacja działa niepoprawnie, w końcu zatwierdzi żądanie. To tak zwane zmęczenie powiadomieniami. Problem nie wynika z braku rozsądku pracownika, lecz z procesu, który przerzuca całą odpowiedzialność na osobę będącą pod presją.

Drugim zagrożeniem są ataki typu AiTM, w których napastnik pośredniczy między użytkownikiem a prawdziwą usługą, próbując przejąć dane sesji. Sam drugi składnik nie zawsze wystarczy, jeżeli metoda uwierzytelniania nie rozpoznaje, z jaką stroną użytkownik faktycznie się łączy.

Dlatego w krytycznych obszarach warto stopniowo przechodzić do uwierzytelniania odpornego na phishing, na przykład z wykorzystaniem kluczy FIDO2. Pomocne jest również dopasowywanie liczb, w którym użytkownik nie zatwierdza bezmyślnie powiadomienia, lecz porównuje kod wyświetlany na ekranie logowania z kodem w aplikacji uwierzytelniającej.

MFA powinno być częścią większego systemu decyzji. Poza tożsamością należy brać pod uwagę:

• stan aktualizacji i szyfrowania urządzenia;
• obecność aktywnego zabezpieczenia punktu końcowego;
• nietypową lokalizację lub prędkość przemieszczania się między logowaniami;
• rodzaj aplikacji i wrażliwość danych;
• historię zachowania użytkownika;
• czas trwania sesji oraz potrzebę ponownej autoryzacji;
• fakt, że konto może być używane przez automatyzację, a nie człowieka.

Nie oznacza to konieczności budowania od razu skomplikowanego systemu sztucznej inteligencji. Na początek wystarczą spójne reguły, sensowna ewidencja i procedura reagowania. Dojrzałość pojawia się później, gdy organizacja potrafi łączyć sygnały z wielu systemów i automatycznie ograniczać dostęp bez czekania na ręczną decyzję administratora.

Najsilniejsze uwierzytelnianie nie pomoże, jeśli po poprawnym zalogowaniu użytkownik dostaje więcej dostępu, niż potrzebuje do wykonania swojej pracy.

Jak zaplanować wdrożenie, żeby nie sparaliżować firmy

Zero Trust dotyka procesów, ludzi i przyzwyczajeń, więc plan techniczny bez planu operacyjnego szybko zacznie się rozjeżdżać. Pracownicy mogą stracić dostęp do narzędzi potrzebnych do obsługi klientów, dostawca może zostać odcięty w środku krytycznego zadania, a administratorzy zaczną dodawać wyjątki, aby przywrócić działanie firmy. Po kilku miesiącach powstaje wtedy architektura pełna wyjątków, której nikt nie potrafi już wyjaśnić.

Rozsądny projekt powinien mieć właściciela biznesowego i technicznego. Pierwszy pilnuje, aby reguły odpowiadały realnym procesom, drugi odpowiada za ich implementację, monitorowanie i utrzymanie. Bez tej współpracy zespół bezpieczeństwa może stworzyć politykę teoretycznie szczelną, ale praktycznie niemożliwą do stosowania.

Przydatny jest podział prac na etapy:

Etap pierwszy: obraz stanu obecnego

Zbieramy informacje o użytkownikach, urządzeniach, aplikacjach, danych i połączeniach. W tym momencie nie próbujemy jeszcze blokować wszystkiego. Chodzi o odkrycie nieznanych zależności: aplikacji używanych poza oficjalnym katalogiem, kont współdzielonych, nieaktualnych urządzeń i procesów, które opierają się na dostępie administratora.

Etap drugi: priorytety ryzyka

Wybieramy zasoby, których naruszenie mogłoby spowodować największą szkodę finansową, prawną lub operacyjną. Warto uwzględnić nie tylko dane klientów, lecz także klucze dostępowe, środowiska produkcyjne, systemy rozliczeń i narzędzia pozwalające zmieniać konfigurację infrastruktury.

Etap trzeci: pilotaż

Pilotaż powinien być niewielki, ale reprezentatywny. Jeśli obejmie wyłącznie dział IT, nie pokaże problemów, które pojawiają się w sprzedaży, finansach albo obsłudze klienta. Dobrze, gdy uczestnicy mają różne role, korzystają z różnych urządzeń i pracują w kilku modelach organizacyjnych.

Etap czwarty: obserwacja i poprawki

Mierzymy liczbę zablokowanych prób, fałszywych alarmów, zgłoszeń użytkowników, wyjątków oraz przypadków, w których dostęp został przyznany zbyt szeroko. Nie chodzi o to, żeby wskaźniki wyglądały dobrze w prezentacji. Mają pokazać, czy polityki odpowiadają temu, jak firma faktycznie pracuje.

Etap piąty: rozszerzenie

Dopiero po poprawieniu reguł przenosimy model na kolejne aplikacje i zespoły. Stare mechanizmy, w tym VPN, mogą przez pewien czas współistnieć z nowym podejściem. Każdy wyjątek powinien jednak mieć właściciela, uzasadnienie i termin ponownego przeglądu.

Największą pokusą jest zakup narzędzi przed zaprojektowaniem architektury. Dostawcy potrafią bardzo przekonująco opowiadać o jednej platformie, która łączy zarządzanie tożsamością, urządzeniami, siecią i danymi. Taka platforma może być użyteczna, ale nie zastąpi decyzji o tym, co firma chce chronić i według jakich zasad. Narzędzie powinno wynikać z architektury, nie odwrotnie.

Zero Trust a NIS2 i KSC 2.0

W rozmowach o Zero Trust często pojawia się stwierdzenie, że przepisy nakazują wdrożenie konkretnej architektury. To zbyt daleko idący skrót. NIS2 ani polska ustawa o KSC 2.0 nie mówią po prostu: „każda organizacja ma kupić rozwiązanie Zero Trust”. Wymagają natomiast podejścia opartego na zarządzaniu ryzykiem, kontroli dostępu, ochronie systemów, reagowaniu na incydenty i stosowaniu adekwatnych środków technicznych oraz organizacyjnych.

Zero Trust dobrze wspiera realizację tych obowiązków, ponieważ porządkuje dostęp, ogranicza uprawnienia, wzmacnia uwierzytelnianie i poprawia widoczność zdarzeń. Nie jest jednak certyfikatem zgodności ani zamiennikiem całego systemu zarządzania bezpieczeństwem.

W kontekście NIS2 i KSC 2.0 szczególne znaczenie mają między innymi silne uwierzytelnianie, kontrola dostępu, zarządzanie podatnościami, monitorowanie zdarzeń oraz możliwość wykazania, że organizacja zna swoje zasoby i potrafi reagować na naruszenia. Za rażące zaniedbania w cyberbezpieczeństwie mogą grozić kary sięgające 10 milionów euro albo 2% globalnego rocznego obrotu, zależnie od zastosowanych przepisów i sytuacji podmiotu.

Dla zarządu nie powinien to być jednak wyłącznie argument finansowy. Największy problem zaczyna się wtedy, gdy firma nie potrafi odpowiedzieć na podstawowe pytania po incydencie: jakie konto zostało użyte, do czego miało dostęp, z jakiego urządzenia nastąpiło logowanie, jakie dane mogły zostać pobrane i kto miał uprawnienia do zmiany konfiguracji. Zero Trust nie usuwa ryzyka, ale pomaga zamienić niejasny obszar domysłów w system, który można obserwować, mierzyć i stopniowo poprawiać.

Co powinno zostać po pierwszych miesiącach?

Dobrze przeprowadzone wdrożenie nie kończy się efektownym komunikatem o „pełnym Zero Trust”. Po kilku miesiącach powinniśmy raczej zobaczyć konkretne zmiany w sposobie działania firmy:

• organizacja posiada aktualniejszą mapę użytkowników, urządzeń, aplikacji i danych;
• konta współdzielone są ograniczone albo objęte jasno opisanym wyjątkiem;
• dostęp administratorów jest silniej chroniony i przyznawany na krótszy czas;
• kluczowe aplikacje nie są dostępne szerzej, niż wymaga tego proces;
• zespół wie, które urządzenia mogą łączyć się z najważniejszymi zasobami;
• logi z istotnych systemów trafiają do miejsca, w którym można je analizować;
• istnieje procedura szybkiego odebrania dostępu po zmianie stanowiska, zakończeniu współpracy albo wykryciu incydentu;
• użytkownicy rozumieją, dlaczego pojawiają się dodatkowe pytania i kontrole.

To ostatnie jest często niedoceniane. Jeżeli pracownicy nie wiedzą, po co wprowadzono nowe zasady, będą traktować je jak przeszkodę i szukać obejść. Wtedy nawet najlepsza technologia zaczyna działać przeciwko organizacji. Komunikacja nie musi przybierać formy wielkiej kampanii. Wystarczy jasno powiedzieć, jaki problem rozwiązujemy, które zachowania się zmieniają i gdzie zgłosić sytuację, w której zabezpieczenie blokuje realną pracę.

Architektura Zero Trust jest więc bardziej procesem porządkowania firmy niż pojedynczym projektem infrastrukturalnym. Wymaga cierpliwości, bo pierwsze efekty często są mało widowiskowe: odkryte nieznane konta, poprawiona ewidencja urządzeń, usunięte stare uprawnienia, lepiej opisane wyjątki. To jednak właśnie te nudne elementy budują odporność, której nie da się kupić jednym kliknięciem.

Jeśli zastanawiamy się, jak wdrożyć Zero Trust w przedsiębiorstwie, zacznijmy od najmniejszego sensownego zakresu: jednej krytycznej aplikacji, jasno określonych użytkowników, znanych urządzeń i mierzalnej polityki dostępu. Potem sprawdźmy, co zadziałało, gdzie pojawiły się tarcia i które założenia rozmijają się z codziennością. W świecie startupów nazwalibyśmy to iteracją, a nie porażką — i dokładnie tak warto traktować dojrzewanie bezpieczeństwa.

Nie potrzebujemy obietnicy, że od jutra wszystko będzie „zero trust”. Potrzebujemy systemu, w którym każdy kolejny dostęp ma uzasadnienie, każde uprawnienie można wyjaśnić, a każdą zmianę ryzyka da się zauważyć, zanim przerodzi się w kosztowny incydent. To mniej spektakularne niż zakup nowej platformy, ale znacznie bliższe temu, czym bezpieczeństwo sieci firmowej powinno być naprawdę.