Lista kontrolna audytu bezpieczeństwa RDP: 12 rzeczy do naprawienia przed kolejnym testem penetracyjnym
RDP (Remote Desktop Protocol) pojawia się w fazie dostępu inicjalnego prawie każdego poważnego incydentu ransomware. Wystawiony port 3389, słabe poświadczenia, brak MFA — atakujący znają ten schemat. Twój kolejny test penetracyjny znajdzie te problemy, jeśli jeszcze ich nie naprawiłeś. Ta lista kontrolna mówi Ci dokładnie, co naprawić i jak to zrobić.
Lista kontrolna 12 elementów
Przejdź przez nie po kolei. Elementy 1–3 są krytyczne; zajmij się nimi przed wszystkim innym.
1. Wystawiony port RDP (3389) bezpośrednio w internecie
Problem: Twoje serwery Windows akceptują połączenia RDP na porcie 3389 z publicznego internetu.
Ryzyko: Atakujący ciągle skanują w poszukiwaniu otwartego portu 3389. W ciągu kilku godzin od uruchomienia nowego serwera, jest on celem ataków brute-force i credential-stuffing. To najczęstszy wektor dostępu inicjalnego ransomware w środowiskach korporacyjnych.
Rozwiązanie: Usuń regułę zapory sieciowej zezwalającą na przychodzące połączenia na port 3389 z internetu. Uzyskuj dostęp do serwerów Windows wyłącznie przez rozwiązanie PAM (takie jak VaultPAM), które pośredniczy w sesji — port RDP pozostaje zamknięty na serwerze, a połączenie jest ustanawiane wychodzące przez konektor.
2. Współdzielone poświadczenia administratora między serwerami
Problem: Twój zespół używa współdzielonego konta Administrator (lub admin, lub jednego nazwanego konta) między wieloma serwerami, i wiele osób zna hasło.
Ryzyko: Gdy ktoś odchodzi, stajesz przed niemożliwym wyborem: rotować hasło i zakłócić działanie wszystkich innych, lub pozostawić dostęp byłego pracownika nienaruszony. Gdy masz incydent, nie możesz ustalić, kto wykonał jaką czynność, ponieważ cała aktywność jest przypisana do współdzielonego konta.
Rozwiązanie: Przejdź na indywidualne nazwane konta dla całego dostępu uprzywilejowanego. Użyj sejfu poświadczeń do przechowywania i automatycznej rotacji poświadczeń serwera. Użyj pośrednictwa sesji, aby użytkownicy łączyli się bez otrzymywania rzeczywistego hasła — sejf je przechowuje.
3. Brak MFA na kontach uprzywilejowanych
Problem: Administratorzy uwierzytelniają się w systemach produkcyjnych wyłącznie za pomocą nazwy użytkownika i hasła.
Ryzyko: Jeden e-mail phishingowy, zrzut poświadczeń lub ponownie użyte hasło daje atakującemu pełny dostęp administracyjny. MFA to pojedynczy mechanizm kontrolny o najwyższym wpływie na zatrzymywanie ataków opartych na poświadczeniach.
Rozwiązanie: Wymagaj TOTP (Google Authenticator, Authy) lub sprzętowych tokenów (YubiKey, Touch ID, Windows Hello) dla każdego konta uprzywilejowanego. Zweryfikuj wymuszanie — dokumenty polityk się nie liczą; wykaż, że próba logowania bez MFA jest odrzucana.
4. Brak nagrywania sesji
Problem: Gdy odbywają się uprzywilejowane sesje, nie ma zapisu tego, co się wydarzyło w trakcie sesji.
Ryzyko: Kryminalistyka po incydencie jest niemożliwa. Audytorzy nie mogą zweryfikować, jakie działania zostały podjęte. Zagrożenia wewnętrzne nie pozostawiają śladu dowodowego. Atakujących ransomware, którzy nadużywają poświadczeń administratora, nie można śledzić poza zdarzeniem logowania.
Rozwiązanie: Kieruj wszystkie uprzywilejowane sesje przez rozwiązanie PAM, które nagrywa pełne wideo sesji i dzienniki aktywności (wykonane polecenia, przesłane pliki, zawartość schowka). Przechowuj nagrania z integralością odporną na manipulacje (łańcuchy skrótów) przez co najmniej 12 miesięcy.
5. Stałe uprawnienia administratora (bez dostępu JIT)
Problem: Administratorzy mają 24/7/365 uprzywilejowany dostęp do systemów produkcyjnych, nawet gdy nie wykonują zadania administracyjnego.
Ryzyko: Atakujący, który kompromituje stację roboczą lub poświadczenia administratora, ma natychmiastowy i trwały dostęp do środowiska produkcyjnego. Powierzchnia ataku jest zawsze maksymalna.
Rozwiązanie: Wdróż dostęp just-in-time (JIT). Uprawnienia są przyznawane dla konkretnego zadania i okna czasowego, a następnie automatycznie odbierane. Między zadaniami konto nie ma dostępu uprzywilejowanego — lub nie ma aktywnego konta w ogóle.
6. Brak przekazywania dziennika audytu
Problem: Dzienniki zdarzeń serwera (Dziennik zdarzeń Windows, dziennik auth Linux) siedzą na serwerze, gdzie mogą być wyczyszczone przez atakującego, który uzyska dostęp administracyjny.
Ryzyko: Atakujący z dostępem administratora może wyczyścić dzienniki i zatrzeć ślady swojej obecności. Podczas reagowania na incydenty krytyczne dane kryminalistyczne mogą być brakujące.
Rozwiązanie: Natychmiast przekazuj wszystkie zdarzenia dostępu uprzywilejowanego do scentralizowanego SIEM lub niezmiennego magazynu dzienników. Upewnij się, że program przekazujący dziennieki działa jako usługa, której zatrzymanie bez wyzwolenia alertu jest niemożliwe.
7. Nierotowane poświadczenia we współdzielonych sejfach lub arkuszach kalkulacyjnych
Problem: Hasła produkcyjne są przechowywane we współdzielonym arkuszu kalkulacyjnym, współdzielonym menedżerze haseł z wieloma użytkownikami lub narzędziu dokumentacji IT — i nie były rotowane od miesięcy lub lat.
Ryzyko: Każda osoba, która kiedykolwiek miała dostęp do tego arkusza kalkulacyjnego lub menedżera haseł, jest potencjalnym zagrożeniem. Poświadczenia współdzielone w postaci zwykłego tekstu to poświadczenia, które w końcu wyciekną.
Rozwiązanie: Przenieś wszystkie poświadczenia produkcyjne do sejfu z automatyczną rotacją. Ustaw harmonogramy rotacji odpowiednie do wrażliwości (codziennie dla krytycznych kont produkcyjnych, co tydzień dla innych). Skonfiguruj sejf, aby rotował poświadczenia po każdym pobraniu.
8. Brak przepływu zatwierdzania dla wrażliwych celów
Problem: Każdy administrator może uzyskać dostęp do dowolnego serwera w dowolnym czasie bez wiedzy lub zatwierdzenia przez drugą osobę.
Ryzyko: Ruch boczny przez zagrożenie wewnętrzne lub skompromitowane konto administratora jest niekontrolowany. Przypadkowe zmiany w krytycznych systemach nie mają kontroli drugiej pary oczu.
Rozwiązanie: Wdróż przepływy zatwierdzania dla pięciu najważniejszych celów produkcyjnych. Żądania dostępu wymagają udokumentowanego zatwierdzenia przez drugą upoważnioną osobę przed rozpoczęciem sesji. VaultPAM rejestruje żądanie, zatwierdzenie i każdą czynność podjętą podczas zatwierdzonej sesji.
9. Domyślne nazwy kont administratora (Administrator, admin, root)
Problem: Twoje serwery używają domyślnych wbudowanych nazw kont administratora.
Ryzyko: Ataki credential-stuffing celują w domyślne nazwy kont, ponieważ są przewidywalne. Każdy serwer Windows ma konto Administrator; atakujący wiedzą, żeby próbować go pierwsi.
Rozwiązanie: Zmień nazwę wbudowanego konta Windows Administrator na wszystkich serwerach. Na Linuksie wyłącz bezpośrednie logowanie SSH przez root (PermitRootLogin no w sshd_config). Utwórz nazwane konta administracyjne do legalnego użytku. Przechowuj poświadczenia w sejfie.
10. Brak limitu czasu nieaktywnych sesji
Problem: Sesje RDP pozostają aktywne w nieskończoność, gdy użytkownik odejdzie od biurka bez zablokowania lub rozłączenia.
Ryzyko: Nienadzorowana aktywna sesja to otwarte drzwi. Fizyczny tailgating lub zdalny dostęp do stacji roboczej administratora daje pełny dostęp do każdego systemu, z którym administrator jest połączony.
Rozwiązanie: Skonfiguruj polityki limitu czasu sesji — rozłącz bezczynne sesje po 15 minutach, wyloguj rozłączone sesje po 30 minutach. Wymuś zarówno na poziomie klienta (GPO), jak i serwera. VaultPAM wymusza limity czasu sesji na warstwie PAM niezależnie od konfiguracji klienta.
11. Kontrola dostępu tylko przez VPN (bez warstwy PAM)
Problem: Twój model kontroli dostępu brzmi: „jeśli jesteś w sieci VPN, możesz połączyć się przez RDP z dowolnym serwerem, dla którego masz poświadczenia".
Ryzyko: VPN to kontrola dostępu na warstwie sieci. Nie ogranicza, do których serwerów użytkownik może dotrzeć, nie wymusza minimalnych uprawnień, nie nagrywa sesji i nie wymaga MFA per sesja. Skompromitowane poświadczenie VPN daje atakującemu dostęp do całej wewnętrznej sieci.
Rozwiązanie: Dodaj warstwę PAM na szczycie VPN (lub całkowicie zastąp dostęp oparty na VPN). Użytkownicy uwierzytelniają się w rozwiązaniu PAM, które wymusza oparty na politykach dostęp do konkretnych celów, wymaga MFA i nagrywa każdą sesję. Serwery docelowe nie są dostępne z VPN — tylko z konektora PAM.
12. Brak procesu przeglądu dostępów
Problem: Prawa dostępu uprzywilejowanego są przyznawane, ale nigdy przeglądane. Użytkownicy gromadzą dostęp w czasie; odchodzący pracownicy mogą zachować dostęp przez miesiące po odejściu.
Ryzyko: Privilege creep to najczęstsze odkrycie audytów i realne ryzyko bezpieczeństwa. Uśpione konta z dostępem uprzywilejowanym to cele o wysokiej wartości — atakujący szukają kont, które nie logowały się ostatnio (nikt nie patrzy).
Rozwiązanie: Wdróż kwartalny proces przeglądu dostępów. Wyeksportuj kompletną listę kont uprzywilejowanych i ich praw dostępu. Poproś wyznaczonego recenzenta, aby potwierdził, że każdy dostęp jest nadal wymagany i odpowiednio zakrojony. Cofnij dostęp, który nie może być uzasadniony. Udokumentuj przegląd z datą, nazwiskiem recenzenta i wynikiem.
Od czego zacząć
Jeśli przygotowujesz się do testu penetracyjnego, najpierw priorytetyzuj elementy 1, 2 i 3 — to najczęstsze odkrycia dostępu inicjalnego i najwyższe ryzyko. Elementy 4, 5 i 6 to najczęstsze odkrycia po eksploatacji. Elementy 7–12 to najczęstsze odkrycia audytów compliance.
Wszystkie 12 elementów jest rozwiązanych przez wdrożenie rozwiązania PAM. Lista odkryć testów penetracyjnych nie skraca się w czasie bez niego — rośnie w miarę rozrastania się środowiska.
VaultPAM rozwiązuje wszystkie 12 z tych odkryć w jedno popołudnie wdrożenia. Brak agentów do zainstalowania. Nie są potrzebne żadne zmiany w zaporze sieciowej. Sesje są pośredniczone przez konektory wyłącznie wychodzące; port 3389 pozostaje zamknięty.
Zacznij bezpłatny okres próbny — sprawdź, jak VaultPAM eliminuje najczęstsze odkrycia testów penetracyjnych RDP z Twojego środowiska.