Hardening (utwardzanie systemu) to proces zwiększania bezpieczeństwa systemów i infrastruktury IT przez ograniczenie ich powierzchni ataku. W praktyce hardening polega na usuwaniu zbędnych usług i kont, zmianie ustawień domyślnych, ograniczaniu uprawnień i regularnym instalowaniu poprawek. NIST (National Institute of Standards and Technology) w swoim glosariuszu bezpieczeństwa definiuje hardening jako proces eliminowania sposobów ataku przez łatanie podatności i wyłączanie zbędnych usług.
Główne założenia hardeningu
- Zasada minimalizacji: mniej funkcji, usług, otwartych portów i aktywnych kont to mniej miejsc do ataku. NIST SP 800-123 zaleca usuwanie wszystkich niepotrzebnych usług, aplikacji i protokołów sieciowych, a usunięcie uznaje za bezpieczniejsze od samego wyłączenia.
- Zmiana ustawień domyślnych: hardening zastępuje konfigurację fabryczną ustawieniami bezpiecznymi, bo według NIST SP 800-123 producenci konfigurują sprzęt i oprogramowanie pod funkcje i łatwość użycia, kosztem bezpieczeństwa. CERT Polska w rekomendacjach dla systemów OT (2024) również zaleca wyłączanie niewykorzystywanych funkcji i zmianę domyślnych danych uwierzytelniających.
Obszary hardeningu
- Systemy operacyjne: wyłączanie zbędnych usług w Windows i Linux, aktualizacje i poprawki bezpieczeństwa, egzekwowanie polityki haseł oraz bezpieczna konfiguracja SSH (np. logowanie wyłącznie kluczami).
- Sieć i urządzenia brzegowe: zamykanie nieużywanych portów, restrykcyjne reguły zapór oraz segmentacja sieci na strefy, która utrudnia atakującemu przemieszczanie się między systemami.
- Konta i uprawnienia: zmiana lub usunięcie domyślnych poświadczeń, które według NIST SP 800-123 są powszechnie znane atakującym, zasada najmniejszego uprzywilejowania i uwierzytelnianie wieloskładnikowe (MFA), najlepiej odporne na phishing, np. sprzętowe klucze FIDO2/U2F.
- Aplikacje i bazy danych: usuwanie zbędnych modułów, wtyczek i przykładowych danych oraz wyłączanie funkcji uruchamiających polecenia systemowe z poziomu bazy, np. xp_cmdshell w Microsoft SQL Server.

Standardy i narzędzia do hardeningu
- Standardy: CIS Benchmarks od Center for Internet Security (CIS) to szczegółowe zalecenia bezpiecznej konfiguracji systemów operacyjnych, chmury i urządzeń sieciowych, opracowywane wspólnie przez ekspertów w procesie konsensusu. Uzupełniają je publikacje NIST oraz norma ISO/IEC 27001:2022, której załącznik A zawiera zabezpieczenie 8.9 „Zarządzanie konfiguracją” (według omówienia zmian w normie przygotowanego przez DQS).
- Narzędzia audytowe: CIS-CAT (w wersji Pro i darmowej Lite) ocenia konfigurację względem CIS Benchmarks, Lynis od CISOfy audytuje systemy Linux, macOS i uniksowe, a OpenSCAP sprawdza zgodność konfiguracji z politykami zapisanymi w standardzie SCAP.
- Listy kontrolne NIST: NIST SP 800-70 Rev. 5 opisuje National Checklist Program, czyli program NIST udostępniający repozytorium list kontrolnych bezpiecznej konfiguracji.
Czy hardening jest jednorazowy?
Hardening systemu nie jest działaniem jednorazowym. NIST SP 800-128 wskazuje, że systemy stale się zmieniają, a zmiany, w tym łatki i aktualizacje, mogą obniżyć ustalony poziom bezpieczeństwa. Dlatego organizacja utrzymuje zatwierdzoną konfigurację bazową (baseline), po większych zmianach sprawdza zgodność z nią i regularnie wykrywa odstępstwa (tzw. configuration drift).
Jak sprawdzić, czy hardening działa?
Skuteczność hardeningu sprawdza się przez porównanie konfiguracji z benchmarkiem lub konfiguracją bazową oraz praktyczną próbę wykorzystania pozostałych słabości. W projektach, które prowadzimy, regularnie znajdujemy domyślne konta i hasła na urządzeniach sieciowych i drukarkach, interfejsy zarządzania dostępne z sieci biurowej, protokoły SMBv1 lub Telnet pozostawione „na wszelki wypadek” oraz reguły zapór „any-any” dodane tymczasowo i nigdy nieusunięte.
- Przegląd konfiguracji względem CIS Benchmarks dla danego systemu lub przyjętej konfiguracji bazowej.
- Skan podatności i wystawionych usług, z zewnątrz i od wewnątrz sieci. Automatyczny skan nie zastępuje ręcznej weryfikacji – zobacz, czym skanowanie podatności różni się od ręcznego testu.
- Próba wykorzystania znalezionych słabości w teście infrastruktury i priorytetyzacja wyników, np. na podstawie oceny podatności w skali CVSS.
- Retest po wdrożeniu poprawek i cykliczne sprawdzanie odstępstw od konfiguracji bazowej.
Jak Pentestica może pomóc
Pentestica ma ponad 10 lat doświadczenia i setki zrealizowanych projektów. Przegląd ustawień serwerów, stacji roboczych i urządzeń sieciowych realizujemy w ramach audytu bezpieczeństwa IT z przeglądem konfiguracji, a skuteczność utwardzenia sprawdzamy w testach infrastruktury. Zakres prac można wstępnie określić w konfiguratorze zakresu.
Źródła
- NIST CSRC Glossary – hardening – definicja hardeningu za NIST SP 800-152.
- NIST SP 800-123 „Guide to General Server Security” – zalecenia usuwania zbędnych usług i kont domyślnych oraz uwagi o ustawieniach fabrycznych.
- NIST SP 800-128 „Guide for Security-Focused Configuration Management of Information Systems” – zarządzanie konfiguracją bazową i monitorowanie zmian.
- NIST SP 800-70 Rev. 5 „National Checklist Program for IT Products” – opis repozytorium list kontrolnych bezpiecznej konfiguracji.
- Center for Internet Security – CIS Benchmarks – zalecenia bezpiecznej konfiguracji opracowywane przez ekspertów w procesie konsensusu.
- Center for Internet Security – CIS-CAT Pro – narzędzie do oceny konfiguracji względem CIS Benchmarks (wersje Pro i Lite).
- CISOfy – Lynis – otwarte narzędzie audytu bezpieczeństwa systemów Linux, macOS i uniksowych.
- OpenSCAP – otwarte narzędzia do oceny zgodności konfiguracji w standardzie SCAP.
- DQS – zmiany w ISO/IEC 27001:2022 – omówienie nowych zabezpieczeń załącznika A, w tym 8.9.
- CERT Polska – Rekomendacje dla wzmocnienia ochrony systemów OT – zalecenia utwardzania konfiguracji urządzeń i zmiany domyślnych danych uwierzytelniających.

Redakcja Pentestica to zespół pentesterów i konsultantów bezpieczeństwa, którzy na co dzień wykonują testy penetracyjne, testy TLPT wymagane przez DORA, red teaming i audyty bezpieczeństwa IT, a także prowadzą wdrożenia zgodności z NIS2, DORA i MiCA. Teksty na tym blogu piszemy z tej praktyki, a nie z opracowań. Każde twierdzenie o przepisie, terminie albo karze opieramy na źródle pierwotnym: dzienniku ustaw, tekście dyrektywy, komunikacie organu nadzoru. Jeśli czegoś nie da się potwierdzić, piszemy o tym wprost, zamiast powtarzać liczbę krążącą po branżowych portalach.