Bezpieczeństwo #

EthicsPortal obsługuje wrażliwe dane sygnalistów. Ta strona dokumentuje konkretne środki techniczne i organizacyjne, które stosujemy. Jest napisana dla inspektorów ds. zgodności, inspektorów ochrony danych i zespołów prawnych oceniających platformę.

Ostatnia aktualizacja: 2026-05-17.

Szyfrowanie danych #

Wszystkie wrażliwe pola są szyfrowane w spoczynku przy użyciu Rails ActiveRecord Encryption z szyfrowaniem niedeterministycznym (każde szyfrowanie generuje unikalny szyfrogram, co uniemożliwia analizę wzorców).

Pole	Szyfrowane	Deterministyczne
Opis zgłoszenia	Tak	Nie
Imię i nazwisko zgłaszającego	Tak	Nie
Dane kontaktowe zgłaszającego	Tak	Nie
Treść wiadomości (komunikacja zgłaszający–prowadzący)	Tak	Nie
Ustrukturyzowane odpowiedzi w zgłoszeniu (relacja, źródło, czas, wcześniejsze zgłoszenie, obawa przed odwetem)	Tak	Nie
Wewnętrzne notatki do sprawy	Tak	Nie
Sekrety uwierzytelniania dwuskładnikowego i kody zapasowe	Tak	Nie

Szyfrowanie niedeterministyczne oznacza, że tych pól nie można wyszukiwać po wartości na poziomie bazy danych. Nawet mając pełny dostęp do bazy, atakujący nie może wyszukać konkretnego imienia i nazwiska zgłaszającego w rekordach.

Wszystkie połączenia z EthicsPortal wykorzystują HTTPS/TLS. Nieszyfrowane żądania HTTP są przekierowywane.

Anonimowość i prywatność #

Anonimizacja IP #

EthicsPortal nigdy nie przechowuje adresów IP. Trasy portalu (wysyłanie zgłoszeń, sprawdzanie spraw, wymiana wiadomości) wykorzystują jednokierunkowy hasz SHA256 adresu IP wyłącznie do limitowania żądań. Hasz nie jest odwracalny — odzyskanie oryginalnego adresu IP z przechowywanej wartości jest niemożliwe.

Dotyczy to wszystkich endpointów portalu. Żaden adres IP nie jest zapisywany w żadnym logu, polu bazy danych ani systemie analitycznym.

Usuwanie metadanych plików #

Przesłane pliki są automatycznie oczyszczane z identyfikujących metadanych przed zapisem:

Typ pliku	Usuwane metadane	Metoda
Obrazy (JPEG, PNG, TIFF, WebP)	Dane EXIF: współrzędne GPS, model aparatu, numer seryjny urządzenia, autor, znaczniki czasu	Przetwarzanie obrazów Vips
Dokumenty PDF	Autor, aplikacja tworząca, historia modyfikacji	exiftool
Pliki wideo	GPS, informacje o urządzeniu, oprogramowanie nagrywające	exiftool
Pliki audio	Urządzenie nagrywające, GPS, tagi oprogramowania	exiftool

Zgłaszający nie muszą ufać, że ich pliki są bezpieczne — metadane są usuwane po stronie serwera niezależnie od zawartości pliku.

Skanowanie antywirusowe #

Wszystkie przesłane pliki są automatycznie skanowane pod kątem złośliwego oprogramowania za pomocą ClamAV , silnika antywirusowego open source. Skanowanie odbywa się po stronie serwera w procesie w tle po przesłaniu pliku. Zainfekowane pliki są automatycznie usuwane i nigdy nie trafiają do osób prowadzących sprawy.

Pliki są skanowane na infrastrukturze EthicsPortal — żadne dane plików nie są wysyłane do zewnętrznych usług skanowania.

Anonimowość prowadzącego #

Sygnaliści nigdy nie widzą prawdziwych imion i nazwisk ani adresów e-mail osób obsługujących ich zgłoszenie. Wszystkie wiadomości od prowadzących są wyświetlane jako „Osoba prowadząca sprawę". Chroni to tożsamość prowadzącego i zapobiega inżynierii społecznej.

Brak śledzenia #

EthicsPortal nie używa ciasteczek śledzących firm trzecich, pikseli reklamowych ani skryptów fingerprinting. Na stronach marketingowych używamy Cloudflare Web Analytics — narzędzie bez ciasteczek, które nie zbiera danych osobowych i jest w pełni zgodne z RODO. Sam portal zgłoszeniowy nie posiada żadnej analityki.

Aktualny status assurance #

EthicsPortal nie deklaruje obecnie na tej stronie akredytowanej certyfikacji ISO 27001. Nie publikuje też obecnie niezależnego zewnętrznego audytu architektury anonimowości. Jeśli to się zmieni, zakres i data zostaną opublikowane tutaj.

Materiały do przeglądu bezpieczeństwa #

Klienci, którzy potrzebują materiałów do oceny dostawcy lub przeglądu prawnego, mogą o nie poprosić w trakcie oceny. Dostępne materiały mogą obejmować podpisane DPA, dokumenty rejestrowe i podatkowe, wypełniony kwestionariusz bezpieczeństwa oraz pisemne odpowiedzi dotyczące procedur tworzenia kopii zapasowych i przywracania, uprzywilejowanego dostępu do środowiska produkcyjnego oraz reagowania na incydenty.

Kontrola dostępu #

Autoryzacja jest egzekwowana na poziomie aplikacji przy użyciu polityk Pundit .

Rola	Może przeglądać zgłoszenia	Może zarządzać ustawieniami organizacji	Może przypisywać prowadzących
Administrator	Wszystkie zgłoszenia	Tak	Tak
Prowadzący	Zgłoszenia przypisane lub takie, w których uczestniczy	Nie	Nie
Obserwator	Tylko do odczytu, dla audytorów i radców prawnych	Nie	Nie

Prowadzący nie mogą widzieć zgłoszeń, które nie zostały im przypisane ani w których nie zostali dodani jako uczestnicy. Uczestnicy są dodawani wprost przez administratora lub głównego prowadzącego (na przykład w celu włączenia działu prawnego lub HR).
Zgłaszający nie posiadają konta użytkownika — uzyskują dostęp do swojego zgłoszenia za pomocą kodu dostępu (WB-XXXX-XXXX) oraz 6-cyfrowego kodu PIN, który wybierają podczas składania zgłoszenia. Oba są wymagane. Kod PIN jest przechowywany wyłącznie w postaci skrótu bcrypt i nie może zostać odzyskany.
Każda akcja kontrolera sprawdza autoryzację. Próby nieautoryzowanego dostępu są blokowane i rejestrowane.

Uwierzytelnianie dwuskładnikowe #

Konta prowadzących i administratorów mogą włączyć uwierzytelnianie TOTP w standardowej aplikacji uwierzytelniającej. Po włączeniu logowanie wymaga linku magicznego i tymczasowego sześciocyfrowego kodu. Zgłaszający używają osobno identyfikatora sprawy oraz kodu dostępu wybranego przy wysyłaniu; kod jest przechowywany wyłącznie jako skrót bcrypt.

Cykl sesji #

Każda uwierzytelniona sesja rejestruje last_seen_at przy każdym żądaniu (z debouncingiem). Użytkownicy mogą przeglądać swoje aktywne sesje, sprawdzać, kiedy każda z nich była ostatnio aktywna, unieważniać dowolną sesję pojedynczo lub wylogowywać się ze wszystkich pozostałych sesji jednocześnie z poziomu ustawień konta.

Sesje wygasają automatycznie po 14 dniach bezczynności. Kolejne żądanie z bezczynnej sesji niszczy rekord po stronie serwera, czyści ciasteczko i wymusza ponowne uwierzytelnienie nowym linkiem magicznym. Nocne zadanie usuwa porzucone sesje z tym samym limitem czasu, dzięki czemu user_agent i ip_address nie są przechowywane poza oknem bezczynności, nawet gdy użytkownik nigdy nie wraca.

Uwierzytelnianie linkiem magicznym ogranicza zasięg potencjalnych skutków długotrwałych sesji: skradzione ciasteczko sesji nie daje wielokrotnie używanego poświadczenia, a ponowne uwierzytelnienie wymaga dostępu do poczty e-mail.

Dostęp członków i wygaszanie dostępu #

Dostęp do organizacji jest egzekwowany na granicy żądania. Gdy członek zostaje dezaktywowany:

Dostęp do organizacji jest natychmiast odrzucany, również w przypadku wcześniej zapisanych zakładek z adresami URL.
Przypisania do otwartych zgłoszeń są zdejmowane.
Uczestnictwa są usuwane.
Historia dziennika audytu przypisana do tego członka jest zachowywana.
Dezaktywowany członek jest powiadamiany.
Ponowna aktywacja nie przywraca automatycznie wcześniejszego dostępu do spraw.

Ostatniego aktywnego administratora oraz właściciela organizacji nie można dezaktywować. Wszystkie zdarzenia dezaktywacji i ponownej aktywacji są zapisywane w dzienniku audytu tylko do dopisywania.

Członkostwa bez śladu w zakresie zgodności (bez wpisów w dzienniku audytu, bez przypisań, bez uczestnictw) są trwale usuwane przy zdjęciu; członkostwa z takim śladem są dezaktywowane miękko, aby ślad audytowy pozostawał możliwy do odtworzenia.

Usunięcie konta #

Gdy członek zamyka własne konto, jego adres e-mail zostaje zastąpiony adresem niedoręczalnym, a dane 2FA, sesje, tokeny API i preferencje są trwale usuwane. Jeżeli nigdy nie wykonywał działań w organizacji, rekord jest usuwany. W przeciwnym razie imię i zdjęcie pozostają powiązane ze sprawami i dziennikiem audytu, a członkostwa są dezaktywowane, aby zachować wymaganą przypisywalność zapisów.

Limitowanie żądań #

Publiczne endpointy portalu są objęte limitami zapobiegającymi nadużyciom i atakom enumeracyjnym:

Endpoint	Limit
Wysyłanie zgłoszenia	5 na 10 minut na zanonimizowany IP
Sprawdzanie sprawy (kod dostępu + kod PIN)	10 na 3 minuty na zanonimizowany IP
Wysyłanie wiadomości	10 na 3 minuty na zanonimizowany IP

Limitowanie żądań wykorzystuje jednokierunkowy hasz IP opisany powyżej — żaden rzeczywisty adres IP nie jest przechowywany.

Audyt i zgodność #

Dziennik audytu tylko do dopisywania #

Każda akcja w EthicsPortal jest rejestrowana z następującymi danymi:

Znacznik czasu (UTC)
Wykonawca (który użytkownik lub proces systemowy wykonał akcję)
Typ akcji (zgłoszenie utworzone, status zmieniony, wiadomość wysłana, prowadzący przypisany, zgłoszenie wyświetlone, zgłoszenie wyeksportowane, zgłoszenie usunięte itp.)

Wpisy dziennika audytu są tylko do dopisywania. Po utworzeniu nie mogą być modyfikowane przez żadnego użytkownika, w tym administratorów organizacji. Pełny dziennik audytu jest dołączany do eksportów spraw w formacie PDF do przeglądu regulacyjnego.

Przechowywanie danych #

Organizacje konfigurują własny okres przechowywania: 12, 24, 36, 48 lub 60 miesięcy po zamknięciu zgłoszenia. Po upływie okresu przechowywania zgłoszenie i wszystkie powiązane dane (wiadomości, załączniki, wpisy dziennika audytu) są automatycznie i trwale usuwane przez zadanie w tle.

Spełnia to wymogi RODO dotyczące ograniczenia przechowywania (Art. 5(1)(e)) oraz obowiązki prowadzenia rejestrów z dyrektywy 2019/1937 (Art. 17–18).

Ochrona przed CSRF #

Wszystkie formularze są chronione przed fałszowaniem żądań cross-site za pomocą wbudowanych tokenów CSRF w Rails.

Bezpieczny cykl życia oprogramowania #

EthicsPortal stosuje udokumentowany cykl życia oprogramowania dla zmian dotyczących Usługi. Etapy przedstawiono tutaj, aby osoba weryfikująca w procesie zakupowym mogła przypisać je do zabezpieczeń A.8.25–A.8.29 normy ISO/IEC 27001:2022 (pełne odwzorowanie znajduje się w mapie zabezpieczeń ).

Etap	Praktyka
Architektura i projektowanie	Funkcje wprowadzające nowe przepływy danych osobowych, nowych podprzetwarzających lub nowe zakresy uprawnień są przed wdrożeniem oceniane względem udokumentowanych na tej stronie zobowiązań dotyczących szyfrowania, kontroli dostępu i ścieżki audytu.
Przegląd zmian	Każda zmiana produkcyjna jest przed wdrożeniem sprawdzana według pisemnej listy kontrolnej (pokrycie szyfrowaniem, zakres uprawnień, zapis do dziennika audytu, walidacja danych wejściowych, postępowanie z sekretami). Egzekwowanie jest zautomatyzowane, a nie uznaniowe: pełny zestaw testów i analiza statyczna uruchamiają się przy każdej zmianie i blokują wdrożenie w razie niepowodzenia. Zestaw uruchamiany jest na hostowanym runnerze CI albo na stacji roboczej programisty, przy czym zakończone uruchomienie zapisywane jest jako status commita, który potok weryfikuje przed pominięciem uruchomienia hostowanego. Role zatwierdzania zmian opisywane są podczas weryfikacji zakupowej.
Bezpieczne kodowanie	Kod domyślnie korzysta z zabezpieczeń na poziomie frameworka — zapytania parametryzowane przez ActiveRecord, strong parameters, escapowanie danych wyjściowych w widokach, tokeny CSRF, szyfrowanie na poziomie atrybutów, autoryzacja Pundit na granicy kontrolera. Odstępstwa wymagają pisemnego uzasadnienia.
Testy bezpieczeństwa w rozwoju	Analiza statyczna (Brakeman , bundler-audit , `importmap audit`) uruchamiana jest przy każdej zmianie. Testy obejmują ścieżki autoryzacji, niezmienniki szyfrowania w spoczynku, zapis do dziennika audytu oraz egzekwowanie ograniczeń liczby żądań. Pełny zestaw narzędzi opisano w sekcji zarządzanie zależnościami i poprawkami .
Rozdzielenie środowisk	Środowiska produkcyjne i nieprodukcyjne są odseparowane. Produkcyjne dane osobowe nie są używane poza produkcją; środowiska testowe i deweloperskie korzystają z danych syntetycznych.
Reakcja na podatności	Zgłoszenia potwierdzamy w ciągu 2 dni roboczych (zob. odpowiedzialne ujawnianie ). Cele: usunięcie problemów krytycznych w ciągu 7 dni, wysokich w ciągu 30, średnich w ciągu 90. Potwierdzone problemy dotyczące wdrożonych klientów zgłaszane są przez rejestr incydentów , jeżeli spełniają kryteria zakresu rejestru.

Zarządzanie zależnościami i poprawkami #

EthicsPortal nie wdraża komponentów oprogramowania, których wsparcie zostało zakończone. Aplikacja działa na aktywnie wspieranych wydaniach Rails, Ruby, PostgreSQL oraz bazowego systemu operacyjnego; wydania bezpieczeństwa z górnych źródeł są stosowane na bieżąco.

Zależności są skanowane w sposób ciągły w continuous integration:

Brakeman wykrywa podatności specyficzne dla Rails przy każdej zmianie.
bundler-audit sprawdza Gemfile pod kątem Ruby Advisory Database przy każdej zmianie oraz dodatkowo codziennie według harmonogramu, dzięki czemu nowo ujawnione podatności są wykrywane nawet bez zmiany kodu.
importmap audit skanuje importy JavaScript pod kątem znanych podatności przy każdej zmianie oraz dodatkowo codziennie według harmonogramu.
Dependabot otwiera cotygodniowo pull requesty dla nieaktualnych gemów Ruby oraz GitHub Actions, pogrupowane według aktualizacji minor/patch.

Komponenty, których wsparcie po stronie źródłowej dobiega końca, są zastępowane lub aktualizowane przed zamknięciem okna wsparcia.

Infrastruktura #

Komponent	Dostawca	Lokalizacja
Serwer aplikacji i baza danych	Hetzner	Norymberga, Niemcy (UE)
Przechowywanie plików	Hetzner Object Storage	Norymberga, Niemcy (UE)
E-maile transakcyjne	Mailjet	Francja (UE)
Przetwarzanie płatności	Stripe	UE

Całe przetwarzanie danych odbywa się w Unii Europejskiej.
Na serwerach EthicsPortal nie są przechowywane numery kart kredytowych ani dane uwierzytelniające płatności. Wszystkie dane płatnicze są obsługiwane przez Stripe.
Mailjet jest używany do e-maili transakcyjnych (powiadomienia dla prowadzących, nie dla sygnalistów). Mailjet ma siedzibę we Francji i przetwarza wszystkie dane w UE.
Strona marketingowa jest dostarczana przez Cloudflare (CDN, Stany Zjednoczone); portal zgłoszeniowy i portal prowadzących nie. Pełną listę i zabezpieczenia transferów opisano na stronie podwykonawcy .

Kopie zapasowe i przywracanie #

EthicsPortal utrzymuje dwie uzupełniające się warstwy kopii zapasowych, obie przechowywane na terenie UE:

Warstwa	Co	Gdzie	Retencja
Baza danych	Codzienne szyfrowane zrzuty PostgreSQL przez akcesorium Kamal	Hetzner Object Storage, Norymberga (UE)	21 dni dla bieżących wersji; usunięte wersje wygasają po kolejnych 7 dniach
Serwer	Pełne migawki dysku hosta aplikacji	Hetzner Cloud, Norymberga (UE)	7 dni

Cele odzyskiwania. Cel punktu odzyskiwania (RPO) wynosi 24 godziny. Cel czasu odzyskiwania (RTO) wynosi 4 godziny. Cele te są również ujęte w umowie o poziomie usług .

Testy przywracania. Test przywracania jest wykonywany automatycznie co miesiąc przez przepływ CI w odrębnym, jednorazowym środowisku. Świeżość kopii zapasowych jest stale monitorowana.

Szyfrowanie. Zrzuty bazy danych są szyfrowane w spoczynku przez Hetzner Object Storage; pola szyfrowane na warstwie aplikacji za pomocą Rails ActiveRecord Encryption pozostają zaszyfrowane w zrzucie.

Przegląd operacyjny #

Ta strona jest publicznym podsumowaniem bezpieczeństwa. Część materiałów operacyjnych jest udostępniana podczas oceny dostawcy zamiast publikowania ich w otwartym internecie, ponieważ zawiera szczegóły infrastruktury i reakcji, które lepiej nadają się do kontrolowanego ujawnienia.

Tematy dostępne na żądanie w trakcie oceny dostawcy obejmują między innymi:

Podsumowanie uprzywilejowanego dostępu do środowiska produkcyjnego
Procedury reagowania na incydenty i kontakty eskalacyjne
Odpowiedzi dotyczące ciągłości działania oraz zakończenia współpracy z klientem i eksportu danych

Odpowiedzialne ujawnianie #

Jeśli odkryjesz lukę w zabezpieczeniach EthicsPortal, prosimy o zgłoszenie na adres security@ethicsportal.eu . Prosimy, abyś:

Nie ujawniał publicznie luki, zanim nie będziemy mieli możliwości jej naprawienia.
Podał wystarczająco dużo szczegółów, abyśmy mogli odtworzyć i naprawić problem.
Nie uzyskiwał dostępu do danych innych klientów ani ich nie modyfikował.

Potwierdzimy otrzymanie zgłoszenia w ciągu 2 dni roboczych i dążymy do szybkiego rozwiązania potwierdzonych luk.

Ostatnia aktualizacja: 24 sierpnia 2026