Najczęstsze luki bezpieczeństwa IT i jak je naprawić

Przez ostatnie kilka lat zespół ExColo przeprowadził dziesiątki audytów bezpieczeństwa IT w polskich organizacjach — od małych firm po duże przedsiębiorstwa i instytucje publiczne. W każdym środowisku spotykamy te same luki bezpieczeństwa, powtarzające się z zadziwiającą regularnością niezależnie od branży, rozmiaru organizacji czy posiadanego budżetu IT. Ten artykuł opisuje siedem najczęstszych luk, ich rzeczywiste konsekwencje oraz konkretne kroki naprawcze możliwe do wdrożenia już dziś.

Luka 1: Słabe hasła i brak MFA

Skompromitowane poświadczenia są przyczyną ponad 80% naruszeń danych według raportu Verizon DBIR 2024. Mimo powszechnej świadomości problemu, słabe hasła i brak wieloskładnikowego uwierzytelniania pozostają najczęstszą luką, jaką znajdujemy podczas audytów. Ataki credential stuffing (próba logowania z listami wykradzionych haseł z innych serwisów), brute force słownikowy na konta bez blokady, czy phishing wyłudzający hasła — wszystkie te metody są trywialne technicznie i wysoce skuteczne, gdy organizacja nie stosuje MFA.

Szczególnie niebezpieczne jest zjawisko password reuse: użytkownicy używają tego samego hasła w firmowym systemie co na prywatnych portalach, które już raz zostały skompromitowane. Bazy danych skradzionych poświadczeń (dostępne w darknecie za kilka dolarów) zawierają miliardy par login-hasło. Atakujący automatycznie sprawdzają je przeciwko firmowemu VPN, poczcie, czy portalom korporacyjnym.

Jak naprawić:

• Wdróż MFA dla wszystkich użytkowników bez wyjątku. Minimum: aplikacja uwierzytelniająca (Microsoft Authenticator, Google Authenticator). Dla kont administracyjnych: wyłącznie FIDO2 (klucze bezpieczeństwa YubiKey lub Windows Hello for Business) — jedyna metoda odporna na phishing.
• Włącz "number matching" i "additional context" w Microsoft Authenticator, aby zapobiec MFA fatigue attacks (ataki polegające na zasypaniu użytkownika prośbami o zatwierdzenie, licząc na przypadkową akceptację).
• Wdróż menedżera haseł korporacyjnych (1Password Teams, Bitwarden for Business) — wyeliminuje password reuse i pozwoli użytkownikom używać silnych, unikalnych haseł bez zapamiętywania.
• Wyłącz wymóg regularnej rotacji haseł — wbrew intuicji, wymuszanie częstej zmiany hasła prowadzi do tworzenia słabszych haseł (Password1!, Password2!). Zgodnie z wytycznymi NIST SP 800-63B, hasła powinny być zmieniane tylko po podejrzeniu kompromitacji, nie według harmonogramu.
• Sprawdź konta użytkowników pod kątem haseł figurujących w znanych wyciekach (Have I Been Pwned API, funkcja Password Protection w Entra ID).

Luka 2: Brak aktualizacji systemów

Niezałatane systemy to otwarte zaproszenie dla atakujących. Według danych firmy Mandiant, średni czas od opublikowania CVE do aktywnego wykorzystania w atakach to zaledwie 15 dni. Dla krytycznych podatności klasy CVSS 9.0+ czas ten skraca się do kilku dni. Organizacje, które nie mają zdefiniowanego procesu patch managementu, często funkcjonują z podatnościami sprzed wielu miesięcy lub nawet lat.

Najczęściej zaniedbywane obszary to: serwery Windows bez aktualnych aktualizacji (zwłaszcza te "krytyczne" dla biznesu, których właściciel boi się dotykać), urządzenia sieciowe (routery, przełączniki, firewalle) z oprogramowaniem sprzed 2-3 lat, aplikacje trzecich stron (Adobe, Java, VLC, narzędzia backup) oraz systemy OT/ICS działające na Windows XP lub Server 2003. Szczególnie niebezpieczne są podatności na kontrolerach domeny — ich kompromitacja oznacza natychmiastową pełną kontrolę atakującego nad całą infrastrukturą.

Jak naprawić:

• Wdróż scentralizowane zarządzanie aktualizacjami: WSUS/SCCM dla środowisk on-premises, Microsoft Intune dla urządzeń mobilnych i zdalnych. Zautomatyzuj wdrażanie poprawek dla stacji roboczych — nie powinny wymagać manualnej interwencji.
• Zdefiniuj SLA dla wdrożenia poprawek: krytyczne (CVSS 9.0+): 24-48 godzin; wysokie (CVSS 7.0-8.9): 7 dni; średnie i niskie: do 30 dni. SLA musi być egzekwowane, nie tylko zapisane w polityce.
• Regularnie skanuj środowisko narzędziami do wykrywania podatności (Nessus, OpenVAS, Qualys) — pozwala to zidentyfikować systemy, które wypadły z procesu patch managementu.
• Stwórz rejestr wyjątków dla systemów, których nie można zaktualizować (legacy OT, systemy vendorów bez wsparcia) z dokumentacją kompensujących kontroli bezpieczeństwa (izolacja sieciowa, monitoring, ograniczenie dostępu).

Luka 3: Błędna konfiguracja Active Directory

Active Directory jest kluczowym celem każdego zaawansowanego atakującego — kontroluje dostęp do wszystkich zasobów organizacji. Błędne konfiguracje AD są niezwykle powszechne i często stanowią prostą ścieżkę od zwykłego użytkownika do pełnej kontroli nad domeną (Domain Admin). Podczas audytów praktycznie zawsze znajdujemy co najmniej kilka z następujących problemów.

Konta serwisowe podatne na Kerberoasting — konta z zarejestrowanymi SPN (Service Principal Name) i słabymi hasłami, których hashe można pobrać bez uprawnień administracyjnych i złamać offline. Konta podatne na AS-REP Roasting — użytkownicy z wyłączoną flagą "Kerberos pre-authentication required", co pozwala pobrać ich hashe bez znajomości hasła. Nadmierne uprawnienia w ACL (Access Control Lists) — użytkownicy lub grupy mające prawa do resetowania haseł, modyfikacji grup uprzywilejowanych lub zapis do obiektów GPO bez uzasadnienia biznesowego. AdminSDHolder abuse — historyczne modyfikacje listy kontroli dostępu chronionego kontenera AdminSDHolder, które po propagacji przez SDProp nadają nieoczekiwane uprawnienia kontom lub grupom.

Jak naprawić:

• Uruchom Ping Castle (bezpłatne narzędzie) — generuje ocenę zdrowia Active Directory od 0 do 100 i listę konkretnych problemów z priorytetami. Zacznij od eliminacji problemów sklasyfikowanych jako "Critical". Docelowy wynik: powyżej 85.
• Uruchom BloodHound z zebraniem danych przez SharpHound — graficznie pokaże ścieżki ataku od zwykłego użytkownika do Domain Admin. Każda zidentyfikowana ścieżka powinna być systematycznie eliminowana.
• Przeprowadź audyt SPN — zidentyfikuj konta serwisowe podatne na Kerberoasting. Zmień hasła tych kont na silne (minimum 30 znaków losowych) lub przepnij usługi na konta gMSA (Group Managed Service Accounts), które mają automatyczną rotację haseł.
• Włącz audytowanie zmian w AD (Event ID 4728, 4732, 4756 — zmiany grup uprzywilejowanych; 4670 — zmiany ACL) i wyślij logi do SIEM lub Microsoft Defender for Identity.
• Przeprowadzaj kwartalny przegląd AD z użyciem Ping Castle — śledź poprawę wyniku i eliminuj nowe problemy przed ich eksploatacją.

Luka 4: Brak segmentacji sieci

Płaska sieć (flat network) — czyli sieć, w której wszystkie urządzenia mogą się swobodnie komunikować ze sobą — jest marzeniem atakującego i koszmarem administratora bezpieczeństwa. Gdy atakujący uzyska przyczółek w jednym systemie (np. przez phishing pracownika), może swobodnie skanować całą sieć, szukać podatnych systemów, wykradać dane i rozprzestrzeniać ransomware na setki urządzeń. Brak segmentacji sprawia, że jeden skompromitowany system oznacza potencjalne skompromitowanie wszystkich.

W środowiskach, które audytujemy, stacja robocza pracownika administracyjnego często może bezpośrednio połączyć się z kontrolerem domeny, serwerami finansowymi, systemem backupu i zarządzaniem sieciowym — co jest architektonicznie nieakceptowalne. Ransomware takie jak LockBit, BlackCat i inne aktywnie skanuje sieć lokalną w poszukiwaniu udziałów sieciowych (SMB shares) i wrażliwych systemów, zanim rozpocznie szyfrowanie.

Jak naprawić:

• Wdróż segmentację sieci opartą na VLAN-ach jako minimum: oddziel sieci serwerów od sieci użytkowników, sieć zarządzania od sieci produkcyjnej, sieć gości od sieci korporacyjnej, systemy OT/ICS od sieci IT.
• Dodaj reguły ACL na firewall między segmentami — komunikacja między segmentami powinna być domyślnie blokowana i wymagać jawnego zezwolenia. Minimalna zasada: użytkownicy nie mogą bezpośrednio łączyć się z kontrolerami domeny ani serwerami backupu na portach administracyjnych.
• Dla krytycznych aktywów (serwery finansowe, bazy danych, systemy ERP) rozważ wdrożenie mikrosegmentacji — granularnej kontroli na poziomie workload, niezależnie od VLAN-ów.
• Sprawdź reguły firewall — wiele organizacji ma "tymczasowe" reguły sprzed lat, które przez nieuwagę zostawiają otwarte bramy do krytycznych systemów.

Luka 5: Nadmierne uprawnienia

Zasada najmniejszych uprawnień (Least Privilege) jest jedną z fundamentalnych zasad bezpieczeństwa IT, a jednocześnie jedną z najczęściej łamanych w praktyce. Typowe problemy, które znajdujemy podczas audytów: konta serwisowe mające uprawnienia Domain Admin (bo "tak było łatwiej podczas wdrożenia"), wszyscy użytkownicy mający prawa lokalnego administratora na swoich komputerach (bo "IT nie chciało się zajmować każdą instalacją"), pracownicy, którzy odeszli z firmy 6 miesięcy temu, ale ich konta wciąż są aktywne, czy też deweloperzy mający dostęp do produkcyjnych baz danych bez procesu zatwierdzenia.

Nadmierne uprawnienia to problem multiplikatora: skompromitowanie jednego konta z nadmiernymi uprawnieniami daje atakującemu dostęp do zasobów, do których kompromitowane konto nigdy nie powinno mieć dostępu. Konto serwisowe z Domain Admin jest gotową ścieżką do pełnego przejęcia infrastruktury.

Jak naprawić:

• Wdróż LAPS (Local Administrator Password Solution) — Microsoft LAPS generuje i przechowuje unikalne, rotowane hasła lokalnego administratora dla każdej stacji roboczej i serwera. Eliminuje problem wspólnych haseł lokalnych administratorów, które po wycieku dają dostęp do setek systemów jednocześnie.
• Wdróż PAM (Privileged Access Management) dla kont uprzywilejowanych — konta serwisowe i konta administracyjne powinny być przechowywane w sejfie haseł (vault), a ich poświadczenia cyklicznie rotowane. Każde użycie konta uprzywilejowanego powinno być logowane.
• Przeprowadź kwartalny przegląd uprawnień (Access Review) — systematyczne sprawdzanie, czy każde konto ma uprawnienia odpowiednie do aktualnej roli użytkownika. Usuń konta osób, które opuściły organizację lub zmieniły rolę.
• Ustaw automatyczne wyłączanie kont po określonym czasie bezczynności (90 dni) lub po dacie zakończenia umowy.
• Przejrzyj konta serwisowe — każde konto serwisowe z Domain Admin jest krytycznym ryzykiem. Przepnij usługi na konta z minimalnymi uprawnieniami lub gMSA.

Luka 6: Brak monitoringu i detekcji

Nie możesz zatrzymać ataku, którego nie widzisz. Mediana czasu przebywania atakującego w sieci przed wykryciem wynosi 16 dni według DBIR 2024 — przez ponad dwa tygodnie atakujący może swobodnie zbierać informacje, eskalować uprawnienia, zakładać tylne drzwi i przygotowywać właściwy cios. W polskich organizacjach, które audytujemy, monitoring jest często całkowicie nieobecny lub ograniczony do przeglądania logów na żądanie po incydencie — co jest analogiczne do zainstalowania kamery bezpieczeństwa i nieoglądania nagrań.

Brak monitoringu to nie tylko problem techniczny — to problem proceduralny. Nawet jeśli narzędzia generują alerty, bez zdefiniowanych procesów i odpowiedzialności za ich obsługę pozostają niezauważone.

Jak naprawić:

• Włącz zaawansowane auditowanie na kontrolerach domeny: logowanie zdarzeń 4624 (udane logowanie), 4625 (nieudane logowanie), 4728/4732/4756 (zmiany w grupach uprzywilejowanych), 4740 (blokada konta), 4768/4769 (żądania biletów Kerberos).
• Wdróż Microsoft Defender for Identity (MDI) — sensor na kontrolerach domeny analizuje ruch AD w czasie rzeczywistym i wykrywa ataki takie jak Pass-the-Hash, Kerberoasting, DCSync i rekonesans. Dostępny w ramach licencji Microsoft 365 E5 lub jako osobny produkt.
• Włącz Entra ID Protection — automatyczna ocena ryzyka logowań i użytkowników z alertami przy wykryciu anomalii (impossible travel, anonimowy IP, zainfekowane urządzenie). Konfiguruj polityki automatycznej reakcji: wymóg MFA lub blokada konta przy wykryciu wysokiego ryzyka.
• Centralnie zbieraj logi z kluczowych systemów (kontrolery domeny, serwery krytyczne, firewall, VPN) w SIEM. Nawet proste rozwiązanie (Microsoft Sentinel, Wazuh) z kilkoma regułami korelacji jest znacznie lepsze niż brak monitoringu.
• Zdefiniuj procesy i odpowiedzialności: kto odbiera alerty, w jakim czasie musi zareagować, jak eskaluje nierozwiązane incydenty.

Luka 7: Niezabezpieczone kopie zapasowe

Backup jest ostatnią linią obrony przed ransomware — ale tylko wtedy, gdy jest właściwie zabezpieczony. Nowoczesne grupy ransomware (LockBit, BlackCat/ALPHV, Akira) przed uruchomieniem szyfrowania aktywnie szukają i niszczą systemy backupu. Atakujący wiedzą, że jeśli backup jest dostępny, ofiara nie zapłaci okupu. Dlatego pierwszym celem jest często serwer backupu i mechanizmy Volume Shadow Copy (VSS).

Typowe błędy, które widzimy: backupy na udziałach SMB dostępnych z sieci produkcyjnej (ransomware szyfruje je razem z danymi produkcyjnymi), brak backupów offline lub offsite (jedyna kopia danych jest w tej samej lokalizacji co dane produkcyjne), backupy nigdy nieprzetestowane pod kątem możliwości odtworzenia (organizacja dowiaduje się o problemie dopiero podczas incydentu), oraz konta backupowe z nadmiernie wysokimi uprawnieniami.

Jak naprawić:

• Wdróż zasadę 3-2-1-1: 3 kopie danych, na 2 różnych nośnikach, 1 kopia poza siedzibą firmy (offsite), 1 kopia offline lub immutowalna (niemodyfikowalna przez system produkcyjny). Kopia immutowalna (object storage z włączonym WORM, taśmy magnetyczne) jest kluczowa — nawet jeśli atakujący ma Domain Admin, nie może zmodyfikować immutowalnego backupu.
• Regularnie testuj odtwarzanie — przynajmniej raz na kwartał wykonaj pełny test odtworzenia krytycznego systemu z backupu. Dokumentuj czas odtworzenia (RTO) i cel punktu odtworzenia (RPO). Backup, który nigdy nie był testowany, jest tylko hipotezą, nie gwarancją.
• Izoluj infrastrukturę backupową — serwer backupu nie powinien być dostępny z sieci użytkowników ani z sieci serwerów produkcyjnych na portach innych niż niezbędne do zbierania danych. Konto agenta backupu powinno mieć minimalne uprawnienia (nie Domain Admin).
• Wyłącz lub chroń Volume Shadow Copy — włącz ochronę VSS przez Microsoft Defender for Endpoint lub ogranicz dostęp do narzędzi usuwania kopii cieni (vssadmin, wmic shadowcopy) przez AppLocker lub Windows Defender Application Control.
• Przechowuj co najmniej jedną kopię danych w usłudze chmurowej z włączoną opcją niezmienialności (Azure Blob Storage z immutable storage, AWS S3 Object Lock) — taka kopia jest odporna na szyfrowanie ransomware, które działa w sieci lokalnej.

Plan działania: od czego zacząć

Siedem opisanych luk może wydawać się przytłaczającą listą zadań. W praktyce naprawienie ich wszystkich jednocześnie jest niemożliwe — kluczowe jest priorytetyzowanie i podejście etapowe.

Szybkie wygrane — Tydzień 1:

• Włącz MFA dla wszystkich kont administracyjnych i kont z dostępem do poczty (priorytet: Microsoft 365/Entra ID).
• Uruchom Ping Castle i przejrzyj listę krytycznych problemów AD — wiele z nich można naprawić w ciągu godzin (np. wyłączenie niebezpiecznych ustawień GPO, zmiana haseł kont serwisowych).
• Zweryfikuj integralność backupów — sprawdź datę i kompletność ostatnich kopii krytycznych systemów. Jeśli backup nie był testowany, przeprowadź test odtworzenia na środowisku testowym.

Miesiąc 1:

• Wdróż MFA dla wszystkich użytkowników (nie tylko administratorów).
• Uruchom skanowanie podatności (Nessus/OpenVAS) — identyfikacja brakujących poprawek i krytycznych podatności.
• Przeprowadź przegląd uprawnień: usuń nieaktywne konta, zidentyfikuj konta serwisowe z Domain Admin.
• Oceń segmentację sieci: czy stacje robocze mogą łączyć się z kontrolerami domeny na portach administracyjnych? Jeśli tak — to priorytet do naprawienia.

Kwartał 1:

• Pełny hardening Active Directory na podstawie wyników BloodHound i Ping Castle.
• Wdrożenie LAPS dla wszystkich stacji roboczych i serwerów.
• Wdrożenie centralnego SIEM z regułami korelacji dla zdarzeń bezpieczeństwa tożsamości.
• Wdrożenie lub przegląd procesu patch management z zdefiniowanym SLA.
• Ocena potrzeby wdrożenia PAM dla kont uprzywilejowanych.

Jak ExColo może pomóc

ExColo przeprowadza kompleksowe audyty bezpieczeństwa IT obejmujące wszystkie opisane obszary — tożsamość i Active Directory, bezpieczeństwo sieci i segmentację, zarządzanie uprawnieniami, stan systemów backupu i poziom monitoringu. Wynikiem audytu jest priorytetyzowana lista luk z ocenami ryzyka i konkretnymi krokami naprawczymi — nie ogólne rekomendacje, ale szczegółowy plan działania dostosowany do Twojego środowiska.

W zależności od potrzeb organizacji możemy przeprowadzić pełny audyt infrastruktury, skoncentrować się na audycie Identity Security i Active Directory, ocenić stan bezpieczeństwa sieci i segmentacji, lub zaprojektować wdrożenie mikrosegmentacji dla krytycznych aktywów.

Jeśli nie wiesz, od czego zacząć poprawę bezpieczeństwa swojej infrastruktury IT, zacznij od rozmowy z nami. Skontaktuj się z ExColo — pierwsza konsultacja diagnostyczna jest bezpłatna.