Tytułem wstępu
Właściciel serwisu Zgłoszeniomat.pl przykłada szczególną wagę do bezpieczeństwa danych osobowych użytkowników korzystających z systemu zgłaszania nieprawidłowości.
Dane przekazywane w formularzach są zapisywane w bazie w postaci zaszyfrowanej (szyfrowanie kolumnowe). W praktyce oznacza to, że bez użycia kluczy kryptograficznych ich treść jest nieczytelna. Jako właściciel serwisu nie przeglądam Twoich danych „dla zasady” — dostęp do konkretnego rekordu następuje wyłącznie, gdy jest to niezbędne do obsługi zgłoszenia, zapewnienia bezpieczeństwa systemu lub wynika z przepisów prawa.
Uwaga: nie jest to szyfrowanie end-to-end (E2EE) ani model zero-knowledge. W ściśle określonych sytuacjach przewidzianych prawem możemy odszyfrować wskazane dane i udostępnić je uprawnionym organom. Szczegóły znajdziesz w
Polityce prywatności.
Co jeśli dojdzie do wycieku bazy danych?
W scenariuszu wycieku samej bazy danych (bez dostępu do serwera aplikacji i kluczy szyfrujących) osoba atakująca zobaczy
jedynie zaszyfrowane wartości pól wrażliwych. Dla kogoś bez kluczy są to losowo wyglądające ciągi znaków, których treści nie da się odczytać.
Hasła użytkowników przechowujemy w postaci skrótów kryptograficznych (hashy), więc nie da się ich „odwrócić” do postaci jawnej.
Co potencjalnie byłoby widoczne
- zaszyfrowane wartości pól (np. imię, nazwisko, adres, telefon, treść zgłoszenia, adres e-doręczeń) – nieczytelne bez kluczy;
- nieszyfrowane metadane techniczne konieczne do działania systemu (np. identyfikatory, daty utworzenia/aktualizacji, statusy zgłoszeń);
- skróty haseł (hash), a nie same hasła;
Czego zwykle nie da się odczytać
- treści pól wrażliwych (dane osobowe, treść zgłoszeń oznaczona jako wrażliwa) – są szyfrowane kolumnowo z kontrolą integralności;
- haseł użytkowników – przechowywane są jako skróty kryptograficzne;
- treści załączników (zdjęć/wideo) – wyciek samej bazy nie oznacza automatycznie dostępu do plików, które są przechowywane osobno.
Uwaga: „wyciek bazy” ≠ „wyciek serwera aplikacji”. Klucze szyfrujące i konfiguracja są przechowywane poza bazą, z ograniczonym dostępem.
Bez tych kluczy treść zaszyfrowanych pól pozostaje nieczytelna.
A jeśli ktoś zdobyłby również klucze?
Taki scenariusz wymagałby oddzielnej kompromitacji serwera aplikacji lub infrastruktury kluczy. Na tę ewentualność mamy gotowe procedury:
- natychmiastowa izolacja środowiska i rotacja kluczy,
- wymuszenie ponownego logowania użytkowników i (w razie potrzeby) reset haseł,
- szczegółowy audyt logów, ustalenie zakresu naruszenia oraz powiadomienia wymagane przepisami prawa.
Naszym celem jest takie projektowanie systemu, aby sam wyciek bazy nie ujawniał treści danych osobowych, a w przypadku poważniejszego
incydentu możliwa była szybka i skuteczna reakcja ograniczająca skutki.
Dostęp organów ścigania i sądów
Zgłoszeniomat.pl udostępnia dane wyłącznie na podstawie ważnego i właściwego prawnie żądania
(np. postanowienia sądu, prokuratora albo żądania uprawnionego organu działającego w granicach prawa).
Nie przekazujemy danych „dobrowolnie” ani „profilaktycznie”.
Uwaga: nasz model nie jest E2EE/zero-knowledge. Oznacza to, że w prawnie przewidzianych sytuacjach możemy
odszyfrować i udostępnić wyłącznie te dane, których dotyczy żądanie.
Jak to wygląda u nas – procedura
- Weryfikacja żądania – sprawdzamy podstawę prawną, właściwość organu oraz zakres (czas, konkretne konto/zgłoszenie, rodzaj danych).
- Minimalizacja – przygotowujemy tylko dane niezbędne do realizacji żądania (zasada need-to-know).
- Selektywne odszyfrowanie – odszyfrowujemy wskazane rekordy w odizolowanym środowisku roboczym; operacja jest rejestrowana.
- Kontrola integralności – generujemy skrót kryptograficzny paczki (np. SHA-256) i protokół czynności.
- Bezpieczne przekazanie – dostarczamy dane kanałem zaakceptowanym przez organ (np. ePUAP / zaszyfrowana paczka z hasłem przekazanym oddzielnie).
- Audyt i retencja – logujemy kto/co/kiedy, z ograniczonym dostępem i zgodnie z polityką retencji.
- Raport przejrzystości – agregujemy statystyki (liczba żądań, zakres), o ile prawo pozwala na publikację.
Jakie dane mogą być objęte żądaniem
- dane konta użytkownika (np. e-mail, imię i nazwisko, numer telefonu – jeśli podano);
- treści i metadane wybranych zgłoszeń (np. data utworzenia, status, lokalizacja);
- dane techniczne związane z kontem/zgłoszeniem (np. znaczniki czasu, adresy IP logowania – jeśli rejestrowane).
Czego nie udostępniamy
- haseł w postaci jawnej – przechowujemy wyłącznie ich kryptograficzne skróty;
- kluczy szyfrujących ani materiału kluczowego infrastruktury;
- danych osób trzecich, które nie są objęte żądaniem (poza zakresem);
- wewnętrznych sekretów konfiguracyjnych i informacji, których ujawnienie zagrażałoby bezpieczeństwu systemu.
Bezpieczeństwo procesu
- zasada four-eyes (co najmniej dwie osoby po stronie operatora przy odszyfrowaniu i przekazaniu danych);
- czasowe, selektywne odszyfrowanie tylko wskazanych rekordów; brak stałych „eksportów” całej bazy;
- pełne logowanie czynności administracyjnych i okresowe przeglądy uprawnień.
Jeśli prawo pozwala, po zakończeniu czynności możemy poinformować użytkownika, że jego dane były
przedmiotem prawnie wiążącego żądania. W przypadkach objętych zakazem informowania – respektujemy ten zakaz.
Udostępnij artykuł:
FB
X