Hardening urządzeń i systemów w 2026 r.: bezpieczna konfiguracja, CIS, STIG i kontrola odchyleń

Hardening, patching i detekcja odpowiadają na różne pytania

Hardening nie jest tym samym co aktualizowanie oprogramowania. Aktualizacja usuwa znaną podatność w określonej wersji produktu. Hardening zmniejsza liczbę dostępnych funkcji i ścieżek nadużycia oraz utrudnia wykorzystanie części błędów konfiguracyjnych i podatności. Nie daje jednak ochrony absolutnej i nie zastępuje zarządzania podatnościami, EDR, segmentacji, kopii zapasowych ani monitorowania.

Patching odpowiada na pytanie, czy znane błędy zostały usunięte. Hardening sprawdza, czy system udostępnia tylko potrzebne funkcje i egzekwuje właściwe zasady bezpieczeństwa. Detekcja odpowiada na pytanie, czy organizacja potrafi zauważyć działanie przeciwnika albo inne zdarzenie wymagające reakcji.

Przykład pokazuje różnicę. Aktualny serwer może nadal zezwalać na logowanie administracyjne z całej sieci, mieć włączoną usługę, której nikt nie używa, oraz przechowywać współdzielone konto o zbyt szerokich uprawnieniach. Nie ma tu koniecznie CVE do załatania, ale powierzchnia ataku pozostaje niepotrzebnie duża. Z drugiej strony doskonale skonfigurowany serwer bez aktualizacji może zawierać krytyczną podatność zdalnego wykonania kodu. Oba procesy są potrzebne.

Podobnie nie należy przeciwstawiać hardeningu EDR ani SOC. Ograniczenie możliwości uruchamiania nieautoryzowanych programów, odseparowanie kont administracyjnych i wyłączenie starych protokołów mogą utrudnić część technik przeciwnika. Monitoring pozostaje jednak potrzebny, ponieważ nie każdą technikę da się zablokować konfiguracją. MITRE ATT&CK v19.2, aktualny od 6 sierpnia 2026 r., jest użytecznym katalogiem zachowań przeciwnika, ale nie jest checklistą hardeningu ani dowodem skuteczności zabezpieczeń.^[8]

Jak wybrać punkt odniesienia: CIS Benchmarks

CIS Benchmarks są konsensusowymi zaleceniami konfiguracji dla wielu systemów operacyjnych, chmur, baz danych, urządzeń sieciowych i platform kontenerowych.^[1] Większość benchmarków zawiera profile Level 1 i Level 2. CIS opisuje Level 1 jako bazowy zestaw zaleceń ograniczających powierzchnię ataku przy zachowaniu użyteczności systemu, a Level 2 jako bardziej rygorystyczny profil defense-in-depth, który wymaga ostrożniejszego testowania i może wpływać na działanie środowiska.^[2] Nie wolno z tego wyciągać wniosku, że Level 1 jest zawsze bezpieczny dla produkcji albo że Level 2 jest zawsze lepszy.

Benchmark trzeba dobierać do dokładnej technologii i wersji. W 2026 r. biblioteka CIS nadal szybko się zmienia: opublikowano między innymi nowe wersje benchmarków Windows Server 2025, Windows Server 2019, Ubuntu 24.04 LTS, Microsoft 365 i Kubernetes.^[1][15] Sam fakt, że organizacja kiedyś wdrożyła CIS, nie wystarcza. W raporcie powinien znaleźć się numer benchmarku i profilu oraz data przyjęcia własnego baseline.

STIG, NIST, Microsoft i środowiska przemysłowe

DISA Security Technical Implementation Guides są szczegółowymi wytycznymi konfiguracyjnymi rozwijanymi dla środowisk amerykańskiego Departamentu Obrony.^[3] Poza takim kontekstem mogą być wartościowym źródłem technicznym, ale nie stają się przez to polskim obowiązkiem prawnym. Ich rygor może też być nieadekwatny do funkcji systemu cywilnego.

NIST SP 800-53 Rev. 5 działa na innym poziomie. To katalog kontroli bezpieczeństwa i prywatności, w którym zarządzanie konfiguracją tworzy odrębną rodzinę CM.^[4] Nie podaje dla każdego produktu gotowej wartości ustawienia, dlatego częściej służy do budowania wymagań procesu niż do bezpośredniego konfigurowania systemu. Starszy NIST SP 800-123 z 2008 r. pozostaje opublikowanym przewodnikiem dotyczącym ogólnego bezpieczeństwa serwerów, lecz jego wiek trzeba brać pod uwagę przy szczegółach technicznych.^[5]

Dla produktów Microsoft warto zestawić własny baseline także z aktualnymi security baselines producenta oraz współczesnym modelem dostępu uprzywilejowanego. Microsoft opisuje w 2026 r. Enterprise Access Model jako rozwinięcie dawnego modelu warstw Active Directory na środowiska lokalne, chmurowe i hybrydowe.^[6] Jest to lepszy punkt odniesienia niż mechaniczne kopiowanie historycznego podziału na warstwy do każdej organizacji.

Nie istnieje jeden benchmark dla całej organizacji. Baseline dla kontrolera domeny, stacji dewelopera, serwera WWW, przełącznika, dzierżawy Microsoft 365 i sterownika przemysłowego będzie inny. W środowiskach OT rodzina IEC 62443 dostarcza ram dotyczących bezpieczeństwa przemysłowych systemów automatyki i sterowania, lecz szczegółowe zabezpieczenia trzeba dobrać do architektury, procesu technologicznego i wymagań bezpieczeństwa funkcjonalnego.^[9]

Co wzmacniać: systemy, tożsamość, sieć i stacje

System operacyjny

Typowy baseline serwera lub stacji obejmuje minimalizację usług i pakietów, ochronę kont lokalnych, politykę uwierzytelniania, zaporę hostową, konfigurację rejestrowania, ustawienia kryptograficzne, mechanizmy ochrony pamięci i aplikacji oraz prawa użytkowników. Wartość ustawienia musi wynikać z funkcji systemu. Wyłączenie mechanizmu tylko dlatego, że benchmark tak zaleca, bez sprawdzenia zależności aplikacji, nie jest profesjonalnym hardeningiem.

Tożsamość i dostęp uprzywilejowany

W środowisku Windows jednym z najważniejszych celów jest przerwanie ścieżek eskalacji do kont o najwyższych uprawnieniach. Oznacza to między innymi rozdzielenie kont zwykłych i administracyjnych, ograniczenie miejsc, z których można wykonywać administrację, kontrolę delegacji, ochronę kont usługowych, ograniczanie kont współdzielonych oraz silne uwierzytelnianie tam, gdzie jest technicznie możliwe.

Hasła lokalnych kont administracyjnych nie powinny być wspólne dla wielu urządzeń. Windows LAPS pozwala centralnie zarządzać losowymi, unikalnymi hasłami takich kont i jest jednym z elementów redukcji ryzyka ruchu bocznego.^[7] Nie zastępuje jednak zarządzania całą klasą kont uprzywilejowanych ani kontroli sesji administracyjnych. W środowiskach hybrydowych ważne jest rozdzielenie płaszczyzny sterowania, zarządzania i danych oraz ochrona urządzeń używanych do administracji.^[6] Im wyższe uprawnienie, tym mniej miejsc powinno móc je przyjąć.

Sieć

Hardening urządzeń sieciowych obejmuje zarządzanie tylko z wydzielonych źródeł, silne uwierzytelnianie administratorów, wyłączenie nieużywanych usług zarządzających, szyfrowane protokoły administracyjne, ograniczenie dostępu do interfejsów zarządzających, centralne logowanie oraz kontrolę zmian. Segmentacja i reguła domyślnej odmowy mogą istotnie ograniczyć ruch boczny, ale wymagają znajomości rzeczywistych przepływów aplikacyjnych.

Stacje robocze

Na stacjach ważne są między innymi szyfrowanie dysku, ograniczenie lokalnych uprawnień administracyjnych, kontrola uruchamianych aplikacji, bezpieczna konfiguracja przeglądarki i pakietu biurowego, ochrona poświadczeń, zapora hostowa oraz polityka EDR. Stacja deweloperska może wymagać innych wyjątków niż komputer pracownika administracyjnego. Wyjątek powinien jednak mieć właściciela, uzasadnienie i termin ponownego przeglądu.

Chmura, kontenery i środowiska OT

Chmura i SaaS

W chmurze hardening przesuwa się z ustawień systemu operacyjnego na tożsamość, role, sieć, logowanie, konfigurację usług zarządzanych, klucze, sekrety i polityki organizacyjne. Trzeba badać zarówno konfigurację poszczególnych zasobów, jak i mechanizmy dziedziczenia polityk na poziomie organizacji lub dzierżawy. Samo włączenie MFA nie naprawia nadmiernych ról ani niekontrolowanych aplikacji OAuth.

Kontenery i Kubernetes

Baseline obejmuje obrazy, hosty, runtime, orkiestrator, polityki sieciowe, sekrety, uprawnienia workloadów i proces CI/CD. CIS publikuje osobne benchmarki dla Kubernetes oraz wybranych środowisk kontenerowych.^[1] Najczęstszym błędem jest traktowanie bezpieczeństwa obrazu kontenera jak całego bezpieczeństwa klastra.

OT i systemy wbudowane

W OT nie wolno przenosić baseline serwera biurowego bez analizy wpływu. Dostępność procesu, wymagania producenta, długie cykle życia i ograniczone okna serwisowe zmieniają sposób wdrażania zabezpieczeń. Często ważniejsze od wymuszenia pojedynczego ustawienia są segmentacja, kontrola zdalnego dostępu, ograniczenie dozwolonej komunikacji, monitorowanie i formalne zarządzanie zmianą.^[9]

Automatyzacja i kontrola odchyleń

Hardening wykonywany ręcznie na dziesiątkach urządzeń szybko traci spójność. Automatyzacja może wykorzystywać GPO, Intune, Ansible, Puppet, Chef, narzędzia chmurowe, mechanizmy policy-as-code albo własne skrypty. Narzędzie jest mniej ważne od możliwości powtórzenia konfiguracji i wykrycia odchylenia.

Dojrzały proces ma co najmniej sześć elementów:

1. wersjonowany baseline z właścicielem i wskazaniem źródła;
2. środowisko lub próbę, na której zmiana jest testowana przed szerokim wdrożeniem;
3. mechanizm automatycznego lub regularnego pomiaru zgodności;
4. formalny rejestr wyjątków z uzasadnieniem, ryzykiem i datą ponownej oceny;
5. plan wycofania zmiany, jeśli konfiguracja zakłóci usługę;
6. dowody wdrożenia: wyniki skanów konfiguracji, eksporty polityk, logi zmian i próbki urządzeń.

Stuprocentowa zgodność z CIS nie powinna być celem samym w sobie. Część zaleceń może być nieadekwatna, inne mogą być zastąpione kontrolą równoważną. Świadoma, udokumentowana decyzja jest wartościowsza niż sztucznie podniesiony wskaźnik.

Najczęstsze błędy

1. Wdrożenie benchmarku bez testów. Baseline jest źródłem rekomendacji i nie zna zależności konkretnej aplikacji. Zmiana TLS, uprawnień, szyfrowania albo zasad uruchamiania aplikacji może przerwać usługę.
2. Brak wersjonowania. Zdanie "mamy CIS Level 1" nic nie mówi bez nazwy produktu, wersji benchmarku, profilu i listy zaakceptowanych odstępstw.
3. Hardening tylko serwerów. Atakujący często potrzebuje jednego słabego punktu w tożsamości, stacji administracyjnej, urządzeniu brzegowym, chmurze albo systemie zarządzającym, aby ominąć dobrze zabezpieczony serwer.
4. Brak kontroli driftu. Bez porównywania stanu rzeczywistego z baseline nie wiadomo, czy zabezpieczenie nadal istnieje.
5. Traktowanie każdej niezgodności jako podatności o tej samej wadze. Odchylenie powinno być oceniane w kontekście funkcji zasobu, ekspozycji i możliwego skutku.
6. Brak właściciela wyjątku. Tymczasowe odstępstwo bez terminu i decyzji ryzyka staje się konfiguracją stałą.

Skąd wynika obowiązek

Polskie prawo nie nakazuje ogólnego obowiązku wdrożenia CIS Benchmarks. Wymaga natomiast rezultatów, do których bezpieczna konfiguracja może być jednym z właściwych środków.

Po nowelizacji obowiązującej od 3 kwietnia 2026 r. ustawa o krajowym systemie cyberbezpieczeństwa wymaga od podmiotów kluczowych i ważnych adekwatnych środków zarządzania ryzykiem, obejmujących między innymi bezpieczeństwo nabywania, rozwoju i utrzymania systemów, zarządzanie podatnościami, kontrolę dostępu, bezpieczeństwo łańcucha dostaw, kryptografię oraz ocenę skuteczności środków.^[10][11] Ustawa nie wskazuje CIS ani STIG jako obowiązkowego profilu, co ma znaczenie także w audycie KSC/NIS2.

KRI z 21 maja 2024 r. wymaga od objętych nim podmiotów utrzymywania systemu zarządzania bezpieczeństwem informacji, aktualnych regulacji wewnętrznych, ograniczania ryzyka wynikającego z podatności, zarządzania uprawnieniami i ochrony systemów adekwatnie do ryzyka.^[12] Hardening jest naturalnym sposobem realizacji części tych wymagań, ale nie jedynym.

DORA idzie dalej w odniesieniu do podmiotów finansowych. Rozporządzenie delegowane (UE) 2024/1774 wymaga identyfikacji bezpiecznego baseline konfiguracji dla aktywów ICT, który minimalizuje ich ekspozycję na cyberzagrożenia, oraz regularnej weryfikacji, czy baseline został skutecznie wdrożony.^[13] To bezpośrednia podstawa dla procesu bezpiecznej konfiguracji, ale nie nakaz użycia konkretnego benchmarku.

RODO w art. 32 wymaga środków odpowiednich do ryzyka dla danych osobowych. Nie ustanawia listy konfiguracji ani profilu hardeningu.^[14] W praktyce błędna konfiguracja może być jednym z czynników prowadzących do naruszenia, ale dobór zabezpieczenia trzeba uzasadnić ryzykiem.

ISO/IEC 27001:2022 pozostaje dobrowolną normą systemu zarządzania, chyba że obowiązek jej stosowania wynika z umowy lub szczególnego reżimu. Jej zabezpieczenia obejmują między innymi zarządzanie konfiguracją, ale zgodność z normą nie oznacza automatycznie zgodności z każdym benchmarkiem.^[16]

Jak ocenić dojrzałość hardeningu

Program można ocenić przez proste pytania:

• Czy każdy istotny typ systemu ma wskazany, wersjonowany baseline?
• Czy wiadomo, które ustawienia zostały świadomie zmienione względem benchmarku?
• Czy nowe urządzenie otrzymuje bezpieczną konfigurację automatycznie lub w powtarzalnym procesie?
• Czy odchylenia są wykrywane po wdrożeniu, a nie dopiero podczas audytu?
• Czy wyjątek ma właściciela, uzasadnienie, ryzyko i datę ponownej oceny?
• Czy zmiany są najpierw testowane i istnieje sposób bezpiecznego wycofania?
• Czy dostęp uprzywilejowany jest odseparowany od zwykłej pracy użytkownika?
• Czy baseline obejmuje chmurę, urządzenia sieciowe i platformy zarządzające, a nie tylko systemy operacyjne?
• Czy po aktualizacji benchmarku organizacja wykonuje analizę różnic zamiast bezrefleksyjnie wdrażać wszystkie nowe ustawienia?
• Czy wyniki hardeningu trafiają do procesu audytu, zarządzania ryzykiem i monitorowania?

W projektach audytowych i hardeningowych 4crypto taki wynik warto przedstawiać nie jako procent zgodności z CIS, lecz jako mapę odchyleń, ryzyka, decyzji i dowodów. Pozwala to rozdzielić brak techniczny od świadomego wyjątku.