Bezpieczeństwo platformy i-SZBI

Gdzie są dane

• Dane przechowujemy na serwerach w Polsce.
• Wobec danych jednostki jesteśmy podmiotem przetwarzającym. Administratorem danych pozostaje jednostka. Dostawcę hostingu wskazujemy w umowie powierzenia jako dalszy podmiot przetwarzający.

Szyfrowanie

• Połączenie. Portal działa tylko przez HTTPS (szyfrowane połączenie przeglądarki z serwerem). Adres zaczynający się od „http://” serwer od razu przekierowuje na „https://”.
• Tylko bezpieczne połączenie. Serwer wysyła przeglądarce nagłówek HSTS (HTTP Strict Transport Security). Dzięki niemu przeglądarka przez rok sama łączy się z portalem tylko bezpiecznie.
• Hasła. Nie przechowujemy haseł. Zapisujemy tylko ich skrót bcrypt, czyli zapis, z którego nie da się odczytać hasła.
• Kopie zapasowe. Każda kopia jest zaszyfrowana algorytmem AES (Advanced Encryption Standard, standard szyfrowania danych) z kluczem o długości 256 bitów, w trybie GCM (Galois/Counter Mode), który wykrywa też każdą zmianę w zaszyfrowanym pliku. Kopia danych jednej jednostki ma własny klucz tej jednostki. Po usunięciu jednostki z portalu kasujemy jej klucz, więc jej starych kopii nie da się już odczytać.
• Dane w bazie nie są dziś szyfrowane pole po polu. Piszemy o tym w sekcji „Czego jeszcze nie mamy”.

Oddzielenie jednostek

• Każda jednostka widzi tylko swoje dane. Sprawdza to serwer przy każdym zapytaniu, a nie sama przeglądarka.
• Gdy ktoś zapisuje wpis powiązany z innym wpisem (np. ryzyko z aktywem), serwer sprawdza, czy oba należą do tej samej jednostki.
• Testy automatyczne pilnują tego oddzielenia. Uruchamiamy je przed wydaniem każdej wersji portalu.
• Gmina albo powiat, który opiekuje się swoimi szkołami w portalu, widzi tylko jednostki przypisane do niego. Każda jego zmiana trafia do dziennika tej szkoły razem z nazwą gminy lub powiatu.

Role i dostęp

W jednostce są trzy rodzaje kont:

Pracownik widzi tylko to, czego potrzebuje do pracy. Tę samą zasadę portal pomaga wdrożyć w jednostce.

Logowanie i ochrona kont

• Hasło musi mieć co najmniej 12 znaków. Portal odrzuca popularne hasła (np. „szkola”, „gmina”, „123456”) i hasła z jednego powtarzanego znaku.
• Po 5 nieudanych próbach logowania na jedno konto z tego samego adresu IP (numeru komputera w internecie) w ciągu 15 minut portal wstrzymuje na kilka minut kolejne próby na to konto z tego adresu. Po 20 nieudanych próbach z jednego adresu czeka cały adres, niezależnie od konta.
• Adres, z którego przychodzi seria nieudanych logowań albo skanowanie portalu w poszukiwaniu słabych punktów, portal może zablokować automatycznie.
• Hasło tymczasowe (nadane przez kogoś innego albo przysłane e-mailem) pozwala tylko ustawić własne hasło. Dopiero potem można pracować.
• Sesja wygasa po 12 godzinach. Wylogowanie i zmiana hasła od razu unieważniają sesję także na innych komputerach.
• Odpowiedzi z danymi nie zostają w pamięci przeglądarki na wspólnym komputerze.
• Uwierzytelniania wieloskładnikowego (MFA), czyli logowania hasłem i dodatkowym kodem, do portalu jeszcze nie ma. Piszemy o tym niżej.

Dziennik zdarzeń

• Portal zapisuje logowania, także nieudane, oraz zmiany w rejestrach, usunięcia, eksporty i odtworzenia kopii.
• Przy każdym wpisie jest data, godzina, użytkownik i adres IP.
• Koordynator przegląda dziennik swojej jednostki w portalu (ostatnie 300 wpisów).
• Gdy serwer napotka błąd, użytkownik widzi tylko numer zgłoszenia. Szczegóły techniczne zostają na serwerze i nie trafiają do przeglądarki.

Kopie zapasowe

• Kopie zapasowe bazy wykonujemy automatycznie.
• Kopię jednej jednostki da się odtworzyć bez zmieniania danych innych jednostek. Koordynator może sam zrobić kopię przed dużą zmianą i w razie pomyłki ją odtworzyć.
• Odtworzenie kopii bazy sprawdziliśmy na czystej bazie. Wróciły wszystkie tabele i wszystkie wiersze, z polskimi znakami.
• Pliki kopii są zamknięte przed dostępem z internetu, więc nie da się ich pobrać przez przeglądarkę.
• Kopie są dziś na tym samym serwerze co portal. Wysyłkę kopii poza serwer przygotowujemy. Piszemy o tym niżej.

Jak sprawdzamy bezpieczeństwo

• Przegląd kodu. Sami przeglądamy kod pod kątem bezpieczeństwa. Ostatni pełny przegląd odbył się 4 listopada 2026 r. i objął oddzielenie danych jednostek, logowanie, sesje, wstrzykiwanie kodu i obsługę plików. Znalezione pozycje poprawiliśmy w kolejnej wersji albo są na liście zadań.
• Testy automatyczne. Przed wydaniem każdej wersji uruchamiamy komplet testów. Część z nich sprawdza bezpieczeństwo, np. oddzielenie jednostek i to, czy serwer nie udostępnia plików, których nie powinien.
• Skan z zewnątrz. Sprawdzamy portal z internetu tak, jak widzi go zwykła przeglądarka. Ostatni taki skan odbył się 9 września 2026 r.
• To są nasze własne sprawdzenia. Portalu nie badała jeszcze niezależna firma zewnętrzna.

Certyfikaty

i-SZBI nie ma certyfikatu ISO/IEC 27001 ani innego certyfikatu bezpieczeństwa wydanego przez niezależną jednostkę. ISO/IEC to skrót dwóch organizacji, które wspólnie wydają normy międzynarodowe: Międzynarodowej Organizacji Normalizacyjnej i Międzynarodowej Komisji Elektrotechnicznej. ISO/IEC 27001 to norma opisująca system zarządzania bezpieczeństwem informacji.

Narzędzie, a nie jednostka certyfikująca. i-SZBI to narzędzie, które porządkuje pracę. Pomaga szkole, ośrodkowi pomocy społecznej (OPS, MOPS) albo urzędowi spełnić wymagania prawa: ustawy o krajowym systemie cyberbezpieczeństwa (KSC), rozporządzenia o Krajowych Ramach Interoperacyjności (KRI) i RODO (ogólnego rozporządzenia o ochronie danych). Układ portalu jest oparty na normie ISO/IEC 27001:2022.

Portal nie potrzebuje akredytacji Polskiego Centrum Akredytacji (PCA), żeby działać, i nie może jej dostać. PCA akredytuje jednostki certyfikujące i laboratoria. Nie akredytuje programów komputerowych. Przepisy KSC, KRI i RODO nie wymagają też, żeby program do prowadzenia SZBI miał certyfikat albo akredytację.

Gdy jednostka chce certyfikat. Formalny certyfikat ISO/IEC 27001 wydaje niezależna jednostka certyfikująca po własnym audycie. Taka jednostka ma akredytację: w Polsce wydaje ją PCA, a za granicą krajowa jednostka akredytująca danego państwa. Jednostka sama zamawia taki audyt. i-SZBI jest wtedy bazą dowodową, z której korzysta audytor. W portalu są:

• rejestry: aktywa, dostawcy, dostępy, incydenty;
• ocena ryzyka przed zabezpieczeniami i po nich, z decyzjami o akceptacji;
• Deklaracja Stosowania (SoA): 93 zabezpieczenia z uzasadnieniem;
• dokumenty z historią wersji i potwierdzeniami zapoznania;
• szkolenia z wynikami testów;
• audyty wewnętrzne i działania korygujące.

Portal nie wydaje certyfikatów, nie zastępuje audytu i nie daje pewności, że jednostka przejdzie audyt. Wynik audytu zależy od tego, jak jednostka faktycznie stosuje swój system, a nie od samego narzędzia.

Bezpieczeństwo samej platformy sprawdzamy przeglądami kodu i testami automatycznymi. Ich zakres opisujemy wyżej.

Czego jeszcze nie mamy

Piszemy o tym otwarcie, bo jednostka powinna wiedzieć, komu powierza dane.

Gdy któraś pozycja się zmieni, zaktualizujemy tę stronę.

Zgłaszanie podatności

Podatność to błąd w portalu, który może narazić dane. Jeśli taki znajdziesz, napisz do nas przez formularz kontaktowy na stronie głównej portalu. W polu „Czego szukacie?” zacznij od słów „Zgłoszenie podatności”. Opisz, gdzie jest błąd i jak go powtórzyć. Formularz prosi też o adres e-mail i numer identyfikacji podatkowej (NIP) jednostki albo firmy.

Odpowiemy na adres e-mail podany w formularzu i powiemy, co zrobimy z Twoim zgłoszeniem.

• Nie sprawdzaj błędu na danych innych jednostek.
• Nie publikuj go, zanim go poprawimy.
• Nie wpisuj w formularzu haseł ani danych osobowych innych osób.

Formularz kontaktowy