Jak wygląda wdrożenie cyberbezpieczeństwa w firmie?

Wdrożenie cyberbezpieczeństwa rzadko zaczyna się od początku. Firma ma już sieć, komputery, serwery, Microsoft 365, backup, dostęp zdalny i różne mechanizmy ochrony. Zwykle nie powstały one jednak według jednego projektu.

Część rozwiązań pojawiła się przy migracji do Microsoft 365, inne podczas uruchamiania pracy zdalnej. Sieć była rozbudowywana wraz z kolejnymi lokalizacjami, a nowe aplikacje i usługi chmurowe dochodziły w miarę rozwoju organizacji. Po kilku latach infrastruktura potrafi wyglądać zupełnie inaczej niż w momencie, gdy projektowano jej pierwsze zabezpieczenia.

I właśnie tutaj zaczyna się problem. Firma może mieć firewall, MFA, ochronę komputerów i codzienny backup, a jednocześnie nie wiedzieć, czy wszystkie te elementy rzeczywiście tworzą spójne środowisko bezpieczeństwa. Czasem wystarczy jedno stare konto z nadmiernymi uprawnieniami, urządzenie pozostające poza zarządzaniem albo serwer dostępny z niewłaściwego segmentu sieci, żeby ominąć dużą część pozostałych zabezpieczeń.

Dlatego sensowne wdrożenie nie zaczyna się od wyboru kolejnego produktu. Najpierw trzeba ustalić, jak środowisko wygląda dzisiaj, gdzie znajdują się jego słabe punkty i które z nich mają rzeczywiste znaczenie dla działania firmy.

Najpierw trzeba poznać środowisko

Pierwszym zadaniem jest rozpoznanie infrastruktury. Nie chodzi jeszcze o szczegółową ocenę każdej konfiguracji, lecz o uzyskanie wiarygodnego obrazu tego, co faktycznie działa w organizacji.

W tym miejscu pojawia się inwentaryzacja. Na potrzeby cyberbezpieczeństwa powinna obejmować znacznie więcej niż komputery i numery seryjne urządzeń. Istotne są systemy, aplikacje, konta, usługi chmurowe, urządzenia sieciowe, zasoby wystawione do Internetu oraz miejsca, w których przechowywane są dane. Do tego dochodzą konta administracyjne, dostęp zdalny, kopie zapasowe i systemy objęte monitoringiem.

Ważne są też zależności. Sam spis zasobów mówi niewiele, jeśli nie wiadomo, które z nich są potrzebne do obsługi sprzedaży, produkcji, księgowości czy magazynu.

Stary serwer może wyglądać jak mało istotny element infrastruktury, dopóki nie okaże się, że korzysta z niego aplikacja krytyczna dla jednego z działów. Podobnie konto techniczne, które działa od kilku lat, może nie zwracać uwagi do momentu sprawdzenia jego uprawnień.

Rozpoznanie środowiska nie musi oznaczać tworzenia rozbudowanej dokumentacji opisującej każdy element infrastruktury. Powinno jednak dać odpowiedź na kilka podstawowych pytań: co znajduje się w środowisku, kto z tego korzysta, gdzie są dane, co jest dostępne z zewnątrz i które systemy są istotne dla ciągłości działania.

Bez tego dalsza ocena bezpieczeństwa opiera się w dużej części na założeniach.

Audyt powinien objąć całe środowisko

Kiedy wiadomo już, co znajduje się w infrastrukturze, można przejść do właściwej oceny bezpieczeństwa. Audyt nie powinien sprowadzać się do skanowania podatności ani porównania ustawień z checklistą. Takie narzędzia są przydatne i potrafią szybko wskazać część błędów, ale nie pokazują, w jaki sposób poszczególne elementy wpływają na siebie nawzajem.

Dobrym przykładem jest tożsamość. Informacja, że w firmie działa MFA, sama w sobie niewiele mówi. Znaczenie ma to, kogo obejmuje, jakie istnieją wyjątki, jak zabezpieczone są konta administratorów i czy w Active Directory lub Entra ID nie pozostały konta, które od dawna nie powinny mieć dostępu.

Podobnie z urządzeniami. Można korzystać z Microsoft Intune oraz EDR lub XDR, ale podczas audytu trzeba sprawdzić, czy wszystkie wymagane komputery rzeczywiście są zarządzane, czy otrzymują właściwe polityki oraz co dzieje się z alertami generowanymi przez system ochrony.

Microsoft 365 również wymaga szerszego spojrzenia niż samo logowanie użytkowników. Znaczenie mają role administracyjne, konfiguracja poczty, dostęp gości oraz sposób udostępniania informacji w SharePoint i OneDrive.

Jeśli organizacja korzysta z Azure, do oceny dochodzą role i uprawnienia, zasoby publiczne, sieci wirtualne, maszyny, połączenia z lokalną infrastrukturą, logowanie zdarzeń i backup.

Osobną częścią pozostaje sieć. Warto sprawdzić, czy urządzenia i systemy są odpowiednio odseparowane, jak wyglądają reguły firewalli i dostęp zdalny oraz czy przejęcie zwykłej stacji roboczej nie otwiera zbyt szerokiej drogi do serwerów i innych wrażliwych zasobów.

Podobnej weryfikacji wymaga system kopii zapasowych. Codzienny komunikat o poprawnym wykonaniu zadania nie oznacza jeszcze, że firma jest przygotowana na ransomware lub poważną awarię. Liczy się również sposób zabezpieczenia kopii, dostęp administracyjny oraz możliwość rzeczywistego odtworzenia danych i systemów.

Dobry audyt łączy te informacje. Dzięki temu nie patrzymy osobno na firewall, konta, komputery i chmurę, tylko na środowisko, w którym wszystkie te elementy są ze sobą powiązane.

Nie każda nieprawidłowość oznacza takie samo ryzyko

Raport z audytu może zawierać wiele uwag, ale sama ich liczba nie mówi jeszcze wiele o stanie bezpieczeństwa. Znaczenie problemu zależy od miejsca, w którym występuje.

Ta sama podatność na urządzeniu znajdującym się w wydzielonym segmencie sieci i na serwerze dostępnym z Internetu nie oznacza takiego samego ryzyka. Podobnie brak dodatkowego zabezpieczenia na nieużywanym koncie testowym trudno stawiać na równi z niewłaściwie chronionym kontem administratora posiadającym szeroki dostęp do infrastruktury.

Dlatego wyniki audytu trzeba zestawić ze znaczeniem zasobu, jego ekspozycją oraz konsekwencjami ewentualnego incydentu. Liczy się nie tylko to, czy błąd da się wykorzystać, ale też co można dzięki temu osiągnąć. Czy przejęcie systemu otworzy dostęp do innych zasobów? Czy przestój będzie problemem dla jednego zespołu, czy zatrzyma dużą część firmy? Czy dane można szybko odtworzyć?

Taka ocena pozwala oddzielić problemy wymagające szybkiej reakcji od tych, które mogą zostać zaplanowane na później. Bez niej audyt łatwo zamienia się w długą listę technicznych uwag, z której trudno wyciągnąć sensowne decyzje.

Co powinno wydarzyć się po audycie?

Raport nie powinien być końcem pracy. Jego najważniejszym rezultatem jest możliwość ustalenia, co należy zrobić dalej. Część problemów można poprawić stosunkowo szybko. Niepotrzebne konto można wyłączyć, nadmierne uprawnienia ograniczyć, a niewłaściwie wystawioną usługę zamknąć. Czasami duża część ryzyka wynika nie z braku nowych technologii, lecz z konfiguracji tego, co już działa.

Większe problemy wymagają osobnego projektu. Brak centralnego zarządzania urządzeniami może prowadzić do wdrożenia Intune. Nieuporządkowane Active Directory i Entra ID wymagają pracy nad tożsamością i uprawnieniami. Płaska sieć może oznaczać potrzebę segmentacji, a problemy w Azure zmianę architektury dostępu lub sposobu monitorowania zasobów.

Podobnie jest z backupem. Jeżeli kopie istnieją, ale nie zapewniają możliwości pewnego i odpowiednio szybkiego odtworzenia najważniejszych usług, problem trudno rozwiązać pojedynczą zmianą ustawienia.

Z tych ustaleń powinna powstać roadmapa. Nie katalog produktów do kupienia, ale plan prac uwzględniający priorytety, zależności i możliwości organizacji.

Kolejność potrafi być ważniejsza niż sama technologia. Rozbudowywanie polityk dostępu w środowisku z nieuporządkowanymi kontami i uprawnieniami może tylko zwiększyć jego złożoność. Z kolei wdrażanie zaawansowanego monitoringu niewiele pomoże, jeśli istotna część urządzeń w ogóle nie znajduje się pod kontrolą.

Dobrze przygotowany plan pozwala uniknąć przebudowy wszystkiego jednocześnie. Część zmian można wprowadzić od razu, kolejne rozłożyć na etapy, a większe projekty przygotować tak, żeby nie zakłócały bieżącej pracy firmy.

Dopiero wtedy zaczyna się właściwe wdrożenie

To, co zostanie wdrożone, zależy od wniosków z wcześniejszej analizy. Nie istnieje jeden zestaw zabezpieczeń odpowiedni dla każdej organizacji. Jeżeli słabym punktem jest tożsamość, prace mogą objąć Active Directory, Microsoft Entra ID, konta administratorów, MFA, Conditional Access i sposób nadawania uprawnień.

Gdy problemem jest brak kontroli nad komputerami, większego znaczenia nabierają Microsoft Intune, szyfrowanie, zarządzanie aktualizacjami oraz systemy EDR lub XDR.

W środowiskach z rozbudowaną infrastrukturą lokalną często pojawia się temat segmentacji sieci, dostępu pomiędzy strefami, konfiguracji firewalli i bezpiecznego dostępu zdalnego.

Microsoft 365 wymaga z kolei uwzględnienia nie tylko kont użytkowników, lecz również poczty, udostępniania dokumentów, uprawnień w SharePoint i OneDrive oraz konfiguracji SPF, DKIM i DMARC.

W Azure istotne będą role administracyjne, sieci, zasoby publiczne, połączenia z lokalną infrastrukturą oraz monitoring. Chmura zmienia się szybko, więc dobrze zaprojektowane środowisko musi uwzględniać również późniejszą kontrolę nowych zasobów i zmian konfiguracji.

Do tego dochodzi ciągłość działania. Backup powinien uwzględniać nie tylko wykonywanie kopii, ale też możliwość odtworzenia firmy po awarii lub ataku. W praktyce oznacza to właściwy zakres danych, odpowiednią retencję, separację kopii i określony czas przywracania najważniejszych usług. Zakres wdrożenia wynika więc z problemów, które zostały wcześniej rozpoznane. Technologia jest tu narzędziem, a nie punktem wyjścia.

Po wdrożeniu trzeba sprawdzić, czy zabezpieczenia działają

Zakończenie konfiguracji nie oznacza jeszcze końca projektu.

Nowe zasady dostępu warto zweryfikować na rzeczywistych kontach. Po wdrożeniu zarządzania urządzeniami trzeba sprawdzić, czy komputery otrzymują właściwe polityki. Segmentację sieci należy przetestować, a po zmianach w systemie backupu wykonać próbne odtworzenie.

Sam fakt obecności agenta EDR kub XDR na urządzeniu nie wystarcza, jeśli zdarzenia nie trafiają do właściwego procesu obsługi. Celem takich testów nie jest potwierdzenie, że w konsoli pojawiła się odpowiednia konfiguracja. Chodzi o sprawdzenie, czy osiągnięto efekt, dla którego została wdrożona. Po większych zmianach warto również zaktualizować dokumentację. Środowisko nie powinno być zrozumiałe wyłącznie dla osoby, która je konfigurowała. Dotyczy to szczególnie architektury sieci, uprawnień administracyjnych, backupu i procedur awaryjnych.

Co dzieje się po zakończeniu projektu?

Cyberbezpieczeństwo nie pozostaje niezmienne po zakończeniu wdrożenia.

Pojawiają się nowi użytkownicy i urządzenia. Zmieniają się uprawnienia. W Azure powstają kolejne zasoby, firma wdraża nowe aplikacje, a sposób pracy zespołów ewoluuje. Równocześnie pojawiają się nowe podatności i techniki ataku.

Dlatego potrzebne są dalsze przeglądy, aktualizacje i monitoring.

Informacje o bezpieczeństwie mogą pochodzić z Entra ID, Microsoft 365, komputerów i serwerów, firewalli, infrastruktury sieciowej czy Azure. Ich zbieranie ma jednak sens dopiero wtedy, gdy wiadomo, kto je analizuje i co powinno się wydarzyć po wykryciu rzeczywistego zagrożenia.

W jednej organizacji będzie odpowiadał za to wewnętrzny zespół. W innej zewnętrzny SOC lub MDR. Możliwy jest też model mieszany. Sam sposób organizacji ma mniejsze znaczenie niż to, czy alert ma właściciela i określoną ścieżkę reakcji.

Podobnie jest z procedurami. Warto wcześniej wiedzieć, kto może zablokować konto, odizolować urządzenie, podjąć decyzję o odtworzeniu systemu czy skoordynować działania podczas poważnego incydentu.

Z czasem potrzebne są również kolejne przeglądy uprawnień, testy backupu i ponowna ocena ryzyka, zwłaszcza po większych zmianach w infrastrukturze.

Jak wygląda wdrożenie cyberbezpieczeństwa w praktyce?

Nie ma uniwersalnego projektu, który można zastosować w każdej firmie.

Punktem wyjścia jest poznanie środowiska. Inwentaryzacja pokazuje zasoby i zależności, audyt pozwala ocenić ich bezpieczeństwo, a analiza ryzyka wskazuje, które problemy mają największe znaczenie. Na tej podstawie można przygotować plan zmian i dopiero wtedy przejść do właściwego wdrożenia.

Dla jednej organizacji priorytetem będzie Active Directory i Entra ID, dla innej urządzenia i ochrona endpointów. Gdzie indziej najważniejsza okaże się segmentacja sieci, środowisko Azure albo możliwość odtworzenia danych po awarii.

Po wykonaniu zmian pozostają testy, dokumentacja, monitoring i utrzymanie.

O poziomie bezpieczeństwa firmy mówi więc nie tyle liczba posiadanych narzędzi, ile to, czy organizacja rozumie swoje środowisko, zna najważniejsze ryzyka i potrafi zareagować, gdy jedno z zabezpieczeń zawiedzie.