audyt bezpieczeństwa

Audyt bezpieczeństwa to niezależna, oparta na dowodach ocena, czy zabezpieczenia i procesy organizacji spełniają przyjęte kryteria: normę, przepis prawa albo politykę wewnętrzną. NIST definiuje go jako niezależny przegląd i badanie zapisów oraz działań, który ma ocenić adekwatność kontroli systemu, zapewnić zgodność z ustalonymi politykami i procedurami oraz wskazać potrzebne zmiany ^[1]. Audyt różni się od pojedynczego testu tym, że porównuje stan faktyczny z kryterium i kończy się raportem z ustaleniami. W Polsce audyt systemu informacyjnego jest obowiązkiem ustawowym części podmiotów objętych ustawą o krajowym systemie cyberbezpieczeństwa ^[3].

Jak przebiega

Audyt zaczyna się od ustalenia zakresu i kryteriów. Kryterium może być norma ISO/IEC 27001, wewnętrzna polityka bezpieczeństwa albo konkretny przepis. Audytor zbiera dowody: dokumenty, konfiguracje, logi, wyniki narzędzi i rozmowy z personelem. Porównuje je z kryterium i opisuje niezgodności. Według NIST audyt ma także wykrywać naruszenia usług bezpieczeństwa i rekomendować środki zaradcze ^[1].

RYS. 1Typowy przebieg audytu

Wynik audytu zasila rejestr ryzyk i plan działań naprawczych. Kolejny audyt sprawdza, czy zalecenia wdrożono.

Rodzaje

Audyt bywa wewnętrzny, gdy prowadzą go pracownicy organizacji, albo zewnętrzny, gdy robi go niezależny podmiot. Różni się też od pokrewnych form oceny bezpieczeństwa, z którymi bywa mylony.

Test penetracyjny i skanowanie często są częścią audytu jako źródło dowodów. Sam skan nie jest jednak audytem, bo nie odnosi wyników do przyjętego kryterium.

Wymogi prawne w Polsce

Ustawa o krajowym systemie cyberbezpieczeństwa. W brzmieniu z 2018 roku operator usługi kluczowej miał zapewnić audyt bezpieczeństwa systemu informacyjnego co najmniej raz na 2 lata ^[2]. Audyt mogła przeprowadzić akredytowana jednostka oceniająca zgodność, co najmniej dwóch audytorów z określonymi kwalifikacjami albo sektorowy zespół cyberbezpieczeństwa ^[2]. Kwalifikacje obejmowały wskazane certyfikaty albo co najmniej trzyletnią praktykę w audycie bezpieczeństwa systemów informacyjnych ^[2]. Audytor sporządzał pisemne sprawozdanie ^[2].

Nowelizacja z 23 stycznia 2026 roku, wdrażająca NIS2, zmieniła ten obowiązek. Podmiot kluczowy przeprowadza na własny koszt audyt co najmniej raz na 3 lata, licząc od podpisania raportu z ostatniego audytu ^[3]. Kopię raportu przekazuje organowi właściwemu w ciągu 3 dni roboczych od jego otrzymania ^[3]. Organ może nakazać decyzją zewnętrzny audyt podmiotowi kluczowemu w każdym czasie, a podmiotowi ważnemu po incydencie poważnym lub innym naruszeniu ustawy ^[3]. Audytu nie może prowadzić osoba, która w audytowanym podmiocie realizuje zadania z zakresu bezpieczeństwa albo realizowała je w roku przed audytem ^[3].

Pierwszy audyt podmiot kluczowy przeprowadza w ciągu 24 miesięcy od spełnienia przesłanek uznania za taki podmiot ^[3]. Nowelizacja weszła w życie 3 kwietnia 2026 roku, a rząd jako termin pierwszego audytu wskazuje 3 kwietnia 2028 roku ^[4].

Jednostki publiczne. Rozporządzenie w sprawie Krajowych Ram Interoperacyjności wymaga okresowego audytu wewnętrznego w zakresie bezpieczeństwa informacji nie rzadziej niż raz na rok ^[5]. Wymóg można spełnić także przez wdrożenie wskazanych Polskich Norm, m.in. PN-ISO/IEC 27001 ^[5].

Szersze ramy takich obowiązków opisuje hasło zgodność regulacyjna (compliance).

W WordPressie

Audyt strony na WordPressie obejmuje kilka warstw: aplikację, serwer, dostęp i procesy. Dokumentacja WordPressa wskazuje, że przyczyną włamań na strony jest najczęściej sama aplikacja, czyli środowisko, za które odpowiada właściciel ^[6].

Aplikacja. Audytor sprawdza wersję rdzenia, wtyczek i motywów. Dokumentacja zaleca, by zawsze mieć najnowszą wersję WordPressa ^[6]. Narzędzie WPScan, opisane przez autorów jako skaner bezpieczeństwa WordPressa, rozpoznaje wersję rdzenia, zainstalowane wtyczki i motywy z wersjami, konta użytkowników oraz katalogi kopii tworzone przez popularne wtyczki ^[7]. Dane o podatnościach pobiera z API po podaniu tokenu; bez niego działa, ale nie zgłasza podatności ^[7]. Wynik zestawia się z listą znanych podatności we wtyczkach.

Serwer i pliki. Według dokumentacji wszystkie pliki powinny należeć do konta użytkownika i być przez nie zapisywalne ^[6], co sprawdza się jako uprawnienia plików. Użytkownik bazy MySQL potrzebuje tylko uprawnień SELECT, INSERT, UPDATE i DELETE ^[6]. Konfigurację systemu Linux można przejrzeć narzędziem Lynis, które wykonuje setki testów i podaje sugestie utwardzania ^[8].

Dostęp i ślady. Audytor przegląda konta z rolą administratora, zgodnie z zasadą opisaną w haśle role i uprawnienia użytkowników. Dokumentacja nazywa logi najlepszym przyjacielem przy ustalaniu, co dzieje się ze stroną ^[6]. Zaleca też śledzenie zmienionych i dodanych plików, czyli monitorowanie integralności plików ^[6].

Procesy. Ostatnia warstwa to kopia zapasowa (backup) i jej odtwarzanie. Dokumentacja zaleca regularne kopie danych, w tym bazy MySQL ^[6].

Dobre praktyki

• Ustalić kryterium przed rozpoczęciem. Bez niego audyt zamienia się w luźną listę uwag.
• Zapewnić niezależność audytora. Ustawa po nowelizacji wprost wyklucza osoby, które same prowadzą zabezpieczenia audytowanego podmiotu ^[3].
• Łączyć przegląd dokumentów z weryfikacją techniczną, np. skanem i testem.
• Każde ustalenie opisać z dowodem, oceną ryzyka i właścicielem działania naprawczego.
• Powtarzać audyt cyklicznie. Stan strony zmienia się z każdą aktualizacją i nową wtyczką, dlatego audyt uzupełnia ciągłe zarządzanie podatnościami.