CyberForces realizował projekt testów bezpieczeństwa infrastruktury sieciowej na rzecz Kancelarii Prezesa Rady Ministrów. Zakres prac obejmował infrastrukturę zewnętrzną, środowisko wewnętrzne, usługi VPN, Active Directory oraz aplikacje krytyczne wskazane przez KPRM.

• W artykule pokazujemy, jaki zakres miały testy bezpieczeństwa infrastruktury sieciowej dla KPRM.
• Opisujemy najważniejsze obszary prac: testy zewnętrzne, testy wewnętrzne, VPN, Active Directory i aplikacje krytyczne.
• Wyjaśniamy, z jakimi wyzwaniami wiązała się realizacja projektu w środowisku produkcyjnym.
• Pokazujemy, jaką wartość taki projekt daje organizacji zarządzającej rozbudowaną infrastrukturą IT.
  

Testy bezpieczeństwa infrastruktury sieciowej dla KPRM: projekt w skrócie

Projekt obejmował kompleksowe testy bezpieczeństwa infrastruktury IT Kancelarii Prezesa Rady Ministrów. Prace dotyczyły zarówno zasobów dostępnych z Internetu, jak i środowiska wewnętrznego organizacji.

Zakres był szeroki. Obejmował infrastrukturę zewnętrzną, sieć wewnętrzną, usługi VPN, Active Directory, serwery, stacje robocze oraz aplikacje krytyczne testowane zgodnie z metodyką OWASP.

Najważniejsze informacje o projekcie

Obszar	Zakres
Klient	Kancelaria Prezesa Rady Ministrów
Typ projektu	Testy bezpieczeństwa infrastruktury sieciowej
Infrastruktura zewnętrzna	Około 45 hostów
Infrastruktura wewnętrzna	Około 900 stacji roboczych i 120 serwerów
VPN	8 tuneli IPsec i 7 SSL/VPN
Aplikacje krytyczne	6 aplikacji testowanych zgodnie z OWASP
Scenariusze wewnętrzne	Bez uwierzytelnienia oraz z kontem zwykłego użytkownika AD
Warunki realizacji	Środowisko produkcyjne, prace prowadzone zgodnie z uzgodnionymi zasadami

W tego typu projekcie nie chodzi wyłącznie o znalezienie pojedynczych podatności. Ważne jest sprawdzenie, jak różne elementy infrastruktury wpływają na bezpieczeństwo całej organizacji.

Zakres testów bezpieczeństwa infrastruktury IT

Zakres wymaganych prac został podzielony na trzy główne obszary: testy zewnętrzne, testy wewnętrzne oraz testy aplikacji krytycznych. Ważnym elementem była też weryfikacja usług VPN, które odpowiadają za zdalny dostęp do zasobów organizacji.

Prace miały objąć zarówno identyfikację usług widocznych z Internetu, jak i ocenę bezpieczeństwa środowiska wewnętrznego. W tym drugim obszarze szczególne znaczenie miały Active Directory, uprawnienia użytkowników, stacje robocze, serwery oraz możliwość eskalacji uprawnień.

Co obejmował zakres prac?

Najważniejsze elementy projektu:

• identyfikacja usług dostępnych z Internetu,
• testy serwerów, urządzeń brzegowych i VPN,
• analiza bezpieczeństwa sieci wewnętrznej,
• testy Active Directory i mechanizmów LDAP,
• próby eskalacji uprawnień,
• analiza zabezpieczeń stacji roboczych,
• ocena bezpieczeństwa serwerów plików, systemów pocztowych i bazodanowych,
• testy aplikacji krytycznych zgodnie z OWASP,
• przygotowanie raportu końcowego z wynikami i rekomendacjami.

Podobny zakres prac jest istotny szczególnie dla organizacji, które mają rozbudowaną infrastrukturę, korzystają z dostępu zdalnego i zarządzają wieloma systemami wewnętrznymi.

Więcej o podobnym zakresie usług: testy penetracyjne infrastruktury sieciowej.

Testy zewnętrzne infrastruktury sieciowej

Testy zewnętrzne obejmowały ocenę usług i hostów dostępnych z Internetu. Ten etap miał pokazać, jakie elementy infrastruktury są widoczne z zewnątrz i jakie ryzyka mogą pojawić się przed uzyskaniem dostępu do sieci wewnętrznej.

Zakres obejmował m.in. serwery, urządzenia brzegowe, firewalle, routery, usługi VPN oraz mechanizmy uwierzytelniania i autoryzacji. W ramach prac przewidziano także analizę znanych typów podatności oraz weryfikację konfiguracji SSL/TLS.

Identyfikacja usług dostępnych z Internetu

W pierwszym kroku istotne było rozpoznanie usług sieciowych wystawionych do sieci publicznej. Taki etap pozwala zrozumieć, które elementy infrastruktury są widoczne dla zewnętrznego użytkownika.

Dzięki temu organizacja może ocenić, czy zakres ekspozycji jest zgodny z założeniami oraz czy publicznie dostępne usługi są odpowiednio zabezpieczone.

Weryfikacja urządzeń brzegowych, VPN i SSL/TLS

W testach zewnętrznych uwzględniono m.in. urządzenia brzegowe, konfigurację VPN oraz certyfikaty SSL/TLS. To ważne, ponieważ te elementy często decydują o bezpieczeństwie dostępu do infrastruktury.

Weryfikacja obejmowała sprawdzenie konfiguracji, aktualności i odporności na znane techniki ataku. Celem było wskazanie obszarów, które mogą wymagać dodatkowego wzmocnienia.

Analiza podatności w usługach publicznych

Zakres przewidywał analizę podatności takich jak SQLi, XSS, RCE, CSRF, Directory Traversal i SSRF. To kategorie błędów często uwzględniane w testach bezpieczeństwa usług dostępnych z Internetu.

Testy były prowadzone z perspektywy zewnętrznego atakującego, bez wykorzystania kont aplikacyjnych. Dzięki temu możliwa była ocena tego, co można zobaczyć i sprawdzić z poziomu Internetu.

Powiązana usługa: testy penetracyjne aplikacji webowej.

Testy wewnętrzne infrastruktury IT, Active Directory i uprawnienia użytkowników

Testy wewnętrzne miały sprawdzić, jakie ryzyka pojawiają się po uzyskaniu dostępu do sieci organizacji. W projekcie przewidziano dwa scenariusze: bez uwierzytelnienia oraz z wykorzystaniem konta zwykłego użytkownika domenowego.

Zakres obejmował analizę bezpieczeństwa sieci wewnętrznej, mechanizmów Active Directory i LDAP, kontrolerów domeny, serwerów, systemów pocztowych, systemów bazodanowych oraz stacji roboczych.

Scenariusz bez uwierzytelnienia

Pierwszy scenariusz zakładał perspektywę nieautoryzowanego urządzenia podłączonego do sieci. Taki wariant pozwala ocenić, jakie informacje i zasoby mogą być dostępne bez posiadania konta użytkownika.

To ważne szczególnie w dużych środowiskach, gdzie bezpieczeństwo zależy nie tylko od haseł i kont, ale również od segmentacji, kontroli dostępu i konfiguracji hostów.

Scenariusz z kontem zwykłego użytkownika AD

Drugi scenariusz zakładał wykorzystanie konta zwykłego użytkownika domenowego. Celem było sprawdzenie, jakie działania może wykonać osoba posiadająca podstawowy dostęp do środowiska.

W tym obszarze istotne było sprawdzenie:

• czy konto zwykłego użytkownika domenowego może zostać wykorzystane do szerszych działań,
• czy konfiguracja uprawnień ogranicza możliwość eskalacji,
• czy stacje robocze i serwery są odpowiednio zabezpieczone,
• czy kontrola dostępu wspiera separację zasobów.

Ocena Active Directory, LDAP i możliwości eskalacji uprawnień

Active Directory jest jednym z najważniejszych elementów infrastruktury w dużych organizacjach. Odpowiada za zarządzanie użytkownikami, dostępem i uprawnieniami.

Błędy w konfiguracji uprawnień, polityk lub mechanizmów uwierzytelniania mogą wpływać na wiele systemów jednocześnie. Dlatego testy AD i LDAP były ważną częścią oceny bezpieczeństwa środowiska wewnętrznego.

 

Testy VPN i dostępu zdalnego

W projekcie ważnym obszarem były również usługi VPN. Zamawiający wskazał konfiguracje IPsec oraz SSL/VPN jako elementy wymagające weryfikacji.

VPN jest jednym z kluczowych punktów dostępu do zasobów organizacji. Z tego powodu jego konfiguracja, mechanizmy uwierzytelniania i odporność na znane podatności powinny być regularnie sprawdzane.

Zakres testów VPN

W ramach takiego zakresu szczególne znaczenie mają:

• konfiguracja tuneli VPN,
• sposób uwierzytelniania użytkowników,
• dostępność usług z Internetu,
• podatności znane dla wykorzystywanych rozwiązań,
• wpływ konfiguracji VPN na bezpieczeństwo sieci wewnętrznej.

Dlaczego testy VPN są ważne?

Dostęp zdalny jest wygodny dla organizacji, ale jednocześnie tworzy istotny punkt wejścia do środowiska. Błędna konfiguracja VPN może zwiększać ryzyko nieuprawnionego dostępu albo ułatwiać dalsze działania w sieci.

Dlatego testy VPN powinny być częścią szerszej oceny infrastruktury, szczególnie w organizacjach, które zarządzają dużą liczbą użytkowników i systemów.

Testy aplikacji krytycznych zgodnie z OWASP

Projekt obejmował również testy aplikacji krytycznych wskazanych przez KPRM. Zakres dotyczył 6 aplikacji, które miały zostać sprawdzone zgodnie z metodyką OWASP.

Ten etap miał na celu ocenę bezpieczeństwa aplikacji wspierających ważne procesy organizacji. Weryfikacji podlegały m.in. mechanizmy uwierzytelniania, autoryzacji, obsługa danych wejściowych oraz konfiguracja bezpieczeństwa.

Co obejmowały testy aplikacji krytycznych?

W testach aplikacyjnych ważne były:

• kontrola dostępu,
• bezpieczeństwo sesji,
• walidacja danych wejściowych,
• odporność na typowe podatności aplikacyjne,
• konfiguracja mechanizmów bezpieczeństwa,
• rekomendacje naprawcze dla zespołów technicznych.

Rola OWASP w testach aplikacji

OWASP pomaga uporządkować zakres testów aplikacyjnych i zwraca uwagę na najczęstsze klasy podatności. Dzięki temu testy aplikacji krytycznych mogą objąć zarówno podstawowe mechanizmy bezpieczeństwa, jak i obszary wymagające bardziej szczegółowej analizy.

Wyzwania w projekcie testów bezpieczeństwa infrastruktury KPRM

Największym wyzwaniem była skala środowiska. Projekt obejmował około 900 stacji roboczych i 120 serwerów, a dodatkowo infrastrukturę zewnętrzną, VPN oraz aplikacje krytyczne.

Drugim ważnym elementem była praca w środowisku produkcyjnym. Testy trzeba było prowadzić ostrożnie, bo wyniki miały być rzetelne, ale działania nie mogły zakłócać dostępności usług.

Duża skala środowiska IT

Rozbudowana infrastruktura wymaga dobrego planowania i jasnego określenia priorytetów. Przy dużej liczbie stacji roboczych, serwerów i usług nie wystarczy samo uruchomienie narzędzi.

Ważne jest zrozumienie zależności między elementami środowiska oraz wskazanie tych obszarów, które mają największe znaczenie dla bezpieczeństwa organizacji.

Testy bezpieczeństwa w środowisku produkcyjnym

Praca na środowisku produkcyjnym wymaga ostrożności. Każde działanie musi być zaplanowane tak, aby ograniczać wpływ na dostępność usług.

Dlatego istotne były uzgodnione zasady współpracy, harmonogram, komunikacja z Zamawiającym i kontrola ryzyka w trakcie realizacji prac.

Kontrola ryzyka i realistyczne scenariusze testowe

Projekt zakładał realistyczne scenariusze testowe prowadzone w sposób kontrolowany i uzgodniony z Zamawiającym. Taki sposób pracy pozwala lepiej ocenić odporność środowiska, ale wymaga precyzyjnego planowania.

Istotna była także ocena separacji środowisk i kontroli dostępu w rozbudowanej sieci wewnętrznej. W praktyce oznaczało to sprawdzenie, czy podstawowy dostęp do sieci albo konto zwykłego użytkownika mogą prowadzić do dalszego dostępu do zasobów.

Poufność i wymagania dla projektu publicznego

Projekt dotyczył administracji centralnej, dlatego sposób pracy, raportowania i przekazywania wyników musiał uwzględniać wymagania dotyczące ochrony informacji.

W takich projektach ważne jest nie tylko samo wykonanie testów. Równie istotne są bezpieczeństwo komunikacji, kontrola dostępu do wyników oraz odpowiednie przygotowanie raportu końcowego.

Efekt testów bezpieczeństwa infrastruktury sieciowej

Efektem prac był raport końcowy z wynikami testów oraz rekomendacjami naprawczymi. Taki dokument miał dostarczyć Zamawiającemu uporządkowany obraz ryzyk w kluczowych obszarach infrastruktury IT.

Raport końcowy mógł stanowić podstawę do priorytetyzacji działań naprawczych. Jego wartość polegała nie tylko na opisaniu podatności, ale też na wskazaniu obszarów, które wymagają dalszego wzmocnienia.

Obszary objęte oceną bezpieczeństwa

W ramach projektu ocenie podlegały:

• infrastruktura zewnętrzna,
• usługi VPN,
• sieć wewnętrzna,
• Active Directory i LDAP,
• uprawnienia użytkowników,
• stacje robocze i serwery,
• aplikacje krytyczne zgodne z zakresem OWASP.

Raport końcowy z wynikami i rekomendacjami

Raport końcowy miał uporządkować wyniki testów i przedstawić rekomendacje naprawcze. W praktyce taki dokument pomaga zespołom technicznym określić, które działania powinny zostać wykonane w pierwszej kolejności.

Dobrze przygotowany raport jest szczególnie ważny w dużych organizacjach. Pozwala połączyć perspektywę techniczną z priorytetami bezpieczeństwa i dalszym planem działań.

Wnioski dla organizacji publicznych

Testy bezpieczeństwa infrastruktury sieciowej powinny obejmować nie tylko systemy widoczne z Internetu. Równie ważne jest sprawdzenie, co może wydarzyć się po uzyskaniu dostępu do sieci wewnętrznej.

Podobny zakres prac jest szczególnie ważny dla administracji publicznej, sektora finansowego, ochrony zdrowia, energetyki i dużych organizacji, które korzystają z Active Directory, VPN oraz aplikacji krytycznych.

Sprawdź także: zgodność z NIS2 oraz vCISO.

FAQ: testy bezpieczeństwa infrastruktury sieciowej

 

Czym są testy bezpieczeństwa infrastruktury sieciowej?

Testy bezpieczeństwa infrastruktury sieciowej to kontrolowana ocena odporności sieci, serwerów, urządzeń, usług i mechanizmów dostępu na potencjalne ataki. Ich celem jest wykrycie podatności, ocena ryzyka i przygotowanie rekomendacji naprawczych.

Co obejmują testy bezpieczeństwa infrastruktury sieciowej?

Projekt obejmował infrastrukturę zewnętrzną, sieć wewnętrzną, VPN, Active Directory oraz aplikacje krytyczne. Testy przewidziano z perspektywy zewnętrznego atakującego oraz z perspektywy dostępu do środowiska wewnętrznego.

Czym różnią się testy zewnętrzne od testów wewnętrznych?

Testy zewnętrzne sprawdzają, co może zrobić osoba atakująca z Internetu. Testy wewnętrzne pokazują, jakie ryzyka pojawiają się po uzyskaniu dostępu do sieci organizacji, np. przez nieautoryzowane urządzenie lub konto zwykłego użytkownika.

Dlaczego testy Active Directory są ważne?

Active Directory odpowiada za zarządzanie użytkownikami, dostępem i uprawnieniami. Błędy w konfiguracji AD mogą ułatwiać eskalację uprawnień i dostęp do zasobów wewnętrznych.

Czy testy bezpieczeństwa infrastruktury sieciowej można prowadzić w środowisku produkcyjnym?

Tak, ale wymagają dokładnego planowania, ustalenia zasad współpracy i kontroli ryzyka. Ważne jest ograniczenie wpływu testów na dostępność usług oraz bieżąca komunikacja z klientem.

 

Skontaktuj się z nami i sprawdź, jak możemy zaplanować testy bezpieczeństwa dla Twojej organizacji.

Kontakt