polityka bezpieczeństwa

Polityka bezpieczeństwa to zatwierdzony przez kierownictwo dokument albo zbiór dokumentów, który określa zasady, obowiązki i granice korzystania z informacji i systemów IT w organizacji. NIST definiuje politykę bezpieczeństwa informacji jako zbiór dyrektyw, regulacji, reguł i praktyk określających, jak organizacja zarządza informacją, chroni ją i rozpowszechnia ^[1]. Sekurak ujmuje to prościej: to zbiór ogólnych zasad bezpieczeństwa przyjętych i obowiązujących w danej organizacji, a nie tylko dokument o przetwarzaniu danych osobowych ^[6]. Polityka jest podstawą, na której opiera się egzekwowanie wymagań wobec pracowników i dostawców.

Rodzaje i składniki

NIST SP 800-12 dzieli polityki na trzy podstawowe typy ^[1].

Ponieważ polityka jest pisana ogólnie, organizacje uzupełniają ją standardami, wytycznymi i procedurami. Według NIST standardy i wytyczne określają technologie i metody zabezpieczania systemów, a procedury to jeszcze bardziej szczegółowe kroki wykonania zadań ^[1]. Polityka programowa zwykle obejmuje cel, zakres, podział odpowiedzialności i zgodność ^[1]. Polityka problemowa zaczyna się od zdefiniowania problemu, a kończy wskazaniem osób kontaktowych, przy czym lepiej podawać stanowiska niż nazwiska, bo zmieniają się rzadziej ^[1].

Cykl życia

Polityka nie jest dokumentem jednorazowym. NIST CSF 2.0 w funkcji Govern wymaga, by polityka zarządzania ryzykiem cyberbezpieczeństwa była ustanowiona na podstawie kontekstu organizacji, strategii i priorytetów, a następnie komunikowana i egzekwowana ^[2]. Ma być też przeglądana i aktualizowana, gdy zmieniają się wymagania, zagrożenia, technologia lub misja organizacji ^[2]. Schemat poniżej pokazuje ten cykl.

RYS. 1Cykl polityki bezpieczeństwa

NIST zwraca uwagę, że naruszenie polityki przez pracownika bywa nieumyślne i wynika np. z braku wiedzy albo szkolenia ^[1]. Dlatego etap komunikacji obejmuje szkolenia z cyberbezpieczeństwa dla pracowników (security awareness training). Im bardziej formalna jest dokumentacja polityki systemowej, tym łatwiej ją egzekwować i przestrzegać ^[1].

Wymogi prawne

W Unii polityka bezpieczeństwa przestała być wyłącznie dobrą praktyką. Art. 21 dyrektywy NIS2 wymienia wśród minimalnych środków politykę analizy ryzyka i bezpieczeństwa systemów informatycznych, polityki i procedury oceny skuteczności środków, polityki stosowania kryptografii oraz politykę kontroli dostępu ^[3]. Organy nadzoru mogą żądać od podmiotów kluczowych udokumentowanej polityki cyberbezpieczeństwa i dowodów jej realizacji, np. wyników audytu ^[3].

Polska ustawa o krajowym systemie cyberbezpieczeństwa po nowelizacji z 2026 roku wymaga w ramach systemu zarządzania bezpieczeństwem informacji (SZBI) polityk szacowania ryzyka oraz bezpieczeństwa systemu informacyjnego, „w tym polityk tematycznych” ^[4]. Kierownik podmiotu zapewnia, że personel zna wewnętrzne regulacje w tym zakresie ^[4].

RODO w art. 24 stanowi, że jeżeli jest to proporcjonalne do czynności przetwarzania, środki administratora obejmują wdrożenie odpowiednich polityk ochrony danych ^[5]. Środki te są w razie potrzeby przeglądane i uaktualniane ^[5]. Wymóg dotyczy każdego administratora danych osobowych, także właściciela sklepu internetowego.

W WordPressie

WordPress nie ma modułu „polityki bezpieczeństwa”. Polityka organizacji przekłada się jednak na konkretne ustawienia strony, a strona jest miejscem, w którym widać, czy polityka jest egzekwowana.

Dostęp. WordPress stosuje koncepcję ról, która ma dać właścicielowi strony kontrolę nad tym, co użytkownicy mogą, a czego nie mogą robić ^[7]. Ma sześć predefiniowanych ról: superadministratora, administratora, redaktora, autora, współpracownika i subskrybenta ^[7]. Polityka kontroli dostępu wskazuje, kto dostaje którą rolę, zgodnie z zasadą najmniejszych uprawnień; szczegóły opisuje hasło role i uprawnienia użytkowników.

Aktualizacje. Od wersji 5.5 administrator może włączyć automatyczne aktualizacje osobno dla każdej wtyczki i każdego motywu ^[8]. Dokumentacja zaleca, by przed ich włączeniem upewnić się, że można przywrócić poprzednią wersję strony z kopii ^[8]. Polityka aktualizacji rozstrzyga, które komponenty aktualizują się same, a które przechodzą przez środowisko testowe (staging).

Hasła i logowanie. Polityka haseł i uwierzytelniania dwuskładnikowego (2FA) dla kont z uprawnieniami administracyjnymi to typowa polityka problemowa. Podobnie polityka kopii zapasowych (backup) i polityka reagowania na incydenty.

Przykładowy zapis polityki systemowej dla strony może brzmieć tak:

Strona example.com
- Rola Administrator: najwyżej 2 osoby, obowiązkowe 2FA.
- Wtyczki: tylko z katalogu WordPress.org, test na stagingu.
- Kopia zapasowa: codziennie, przechowywana poza serwerem.
- Przegląd kont i wtyczek: co kwartał.

Dobre praktyki

Najczęstszym problemem nie jest brak dokumentu, lecz rozjazd między dokumentem a rzeczywistością. Polityka ogranicza liczbę administratorów, a w panelu pozostało kilka dodatkowych kont, w tym konto byłego podwykonawcy. Polityka wymaga codziennej kopii, a wtyczka do kopii od dawna zgłasza błąd, którego nikt nie czyta. Dlatego polityka powinna wskazywać nie tylko zasadę, ale też sposób jej sprawdzenia i osobę, która to robi.

Polityka powinna być krótka na poziomie programowym i konkretna na poziomie systemowym. Stanowiska kontaktowe zamiast nazwisk, regularny przegląd polityk problemowych i jawne konsekwencje naruszeń wynikają wprost z zaleceń NIST ^[1]. Zakres polityk warto wyprowadzić z szacowania ryzyka, a nie z gotowego wzoru. Wzory, takie jak te udostępnione przez Sekuraka, są punktem wyjścia do dostosowania ^[6]. Organizacje, które chcą certyfikacji, opierają zestaw polityk na normie ISO/IEC 27001.