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-08-28.

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).

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ść #

Adresy IP #

EthicsPortal nie zapisuje adresu IP zgłaszającego wraz ze zgłoszeniami, wiadomościami ani wpisami audytowymi, a logi aplikacji dla kanału zgłoszeniowego nie zawierają adresów IP.

Limitowanie żądań w kanale zgłoszeniowym (wysyłanie zgłoszeń, sprawdzanie spraw, wymiana wiadomości) opiera się na skróconym haszu SHA-256 adresu IP żądania, obliczanym z kluczem. Hasz jest pseudonimowy, a nie anonimowy: nie da się go odczytać z powrotem jako adresu, ale każdy, kto posiada sekret aplikacji, mógłby sprawdzać względem niego kolejne potencjalne adresy. Jest używany wyłącznie przez okno limitu żądań (maksymalnie 10 minut) i przechowywany w pamięci podręcznej o ograniczonym rozmiarze.

Serwer proxy TLS działający przed aplikacją prowadzi własne logi połączeń, które zawierają adresy IP. Nie są one powiązane ze zgłoszeniami. Są przechowywane w jednym pliku logu o rozmiarze 10 MB, który jest stale nadpisywany, obecnie w ciągu kilku godzin; 7-dniowe migawki serwera opisane w sekcji kopie zapasowe mogą zawierać ich kopię.

Usuwanie metadanych plików #

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

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. Cloudflare Web Analytics działa wyłącznie na stronach marketingowych. Nie ustawia analitycznych plików cookie, ale Cloudflare może przetwarzać metadane żądań, w tym adresy IP, zgodnie z Polityką prywatności . Kanał zgłoszeniowy nie ma 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 .

• 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:

Limitowanie żądań wykorzystuje opisany powyżej hasz IP z kluczem — żaden adres IP nie jest w tym celu 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. Żaden użytkownik, w tym administrator organizacji, nie może edytować wpisu ani usunąć pojedynczego wpisu: wyzwalacze PostgreSQL odrzucają modyfikację i obcięcie na poziomie bazy danych. Wpisy są usuwane wyłącznie przez cykl retencji albo wraz z usunięciem samej organizacji, a uprzywilejowana ingerencja w bazę pozostaje udokumentowanym ryzykiem szczątkowym (rejestr ryzyka R-08 ). 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ń ).

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 #

• Całe podstawowe przetwarzanie zgłoszeń i danych spraw 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. To odrębne przetwarzanie publicznej strony i zabezpieczenia transferów opisano w Polityce prywatności .

Kopie zapasowe i przywracanie #

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

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. Hetzner Object Storage domyślnie nie szyfruje obiektów w spoczynku, dlatego zrzuty bazy danych są szyfrowane, zanim opuszczą serwer: GnuPG symetrycznie AES-256, a hasło zna wyłącznie proces tworzenia kopii i jest zdeponowane poza maszyną. Pola zaszyfrowane przez aplikację pozostają dodatkowo zaszyfrowane wewnątrz zrzutu. Załączniki pozostają otwartą luką: są przesyłane bez szyfrowania po stronie serwera i nie są objęte zrzutem.

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ś:

1. Nie ujawniał publicznie luki, zanim nie będziemy mieli możliwości jej naprawienia.
2. Podał wystarczająco dużo szczegółów, abyśmy mogli odtworzyć i naprawić problem.
3. 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.

Brak płatnego programu bug bounty. Nie wypłacamy wynagrodzenia za zgłoszenia luk w zabezpieczeniach ani nie podpisujemy umów o zachowaniu poufności, nie uzgadniamy warunków handlowych i nie prowadzimy rozmów telefonicznych jako warunku przyjęcia zgłoszenia. Prześlij na powyższy adres informację o objętym zgłoszeniem zasobie, kroki odtworzenia oraz ustalony wpływ.

Ostatnia aktualizacja: 30 września 2026