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-10-06.

Szyfrowanie danych #

Wymienione poniżej wrażliwe pola bazy danych 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 pól nie obejmuje całych zrzutów bazy danych ani załączników; są one szyfrowane osobno, jak opisano w sekcjach załączniki i kopie zapasowe .

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.

Załączniki #

Pliki załączone do zgłoszeń, wiadomości i wewnętrznych notatek, nagrania głosowe oraz eksporty danych sprawy są szyfrowane w spoczynku w Hetzner Object Storage algorytmem AES-256, osobnym losowym kluczem dla każdego pliku (szyfrowanie po stronie serwera z kluczami dostarczanymi przez klienta). Klucz jest przesyłany z każdym żądaniem do magazynu, a Hetzner odrzuca każdy odczyt wykonany bez niego. EthicsPortal przechowuje go w bazie danych, zaszyfrowany opisanym wyżej mechanizmem ActiveRecord Encryption, więc same dane dostępowe do magazynu nie pozwalają odczytać pliku: potrzebne są również baza danych i klucze szyfrowania aplikacji. Pliki trafiają do uprawnionych użytkowników strumieniowo przez aplikację, nigdy przez bezpośredni link do magazynu.

Pliki przesłane przed 6 października 2026 r. zostały tego dnia ponownie zaszyfrowane, a ich niezaszyfrowane kopie, w tym zachowane wcześniejsze wersje, zostały usunięte. Pliki, które nie są danymi zgłoszeń, takie jak zdjęcia profilowe i obrazy udostępniania organizacji, nie są szyfrowane w ten sposób. Żaden z tych środków nie chroni przed przejęciem serwera aplikacji, który przechowuje jednocześnie dane dostępowe do magazynu, bazę danych i klucze.

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łoszeń nie zawierają adresów IP.

Limitowanie żądań w kanale zgłoszeń (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:

Metadane są usuwane po stronie serwera przed zapisem. W przypadku typów plików obsługiwanych przez exiftool zależy to od obecności standardowych narzędzi produkcyjnych.

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. Pliki, które nie przeszły skanowania, są blokowane przed udostępnieniem, a zainfekowane pliki są automatycznie usuwane.

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 . Sam kanał zgłoszeń 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.
• 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 dwuskładnikowe oparte na TOTP w dowolnej standardowej aplikacji uwierzytelniającej (Google Authenticator, 1Password, Authy i zgodne alternatywy). Po włączeniu logowanie wymaga zarówno podstawowego poświadczenia, jak i zmieniającego się 6-cyfrowego kodu.

Zgłaszający również uwierzytelniają się dwoma składnikami: kodem dostępu (coś, co posiadają) i kodem PIN wybranym przy składaniu zgłoszenia (coś, co wiedzą). Kod PIN jest przechowywany wyłącznie w postaci skrótu bcrypt i nie może zostać odzyskany. Skrzynka dalszej komunikacji i wysyłanie wiadomości są dostępne wyłącznie w sesji uzyskanej po tej weryfikacji, więc sam ujawniony kod dostępu nie pozwala odczytać zgłoszenia ani podszyć się pod zgłaszającego.

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.

Właściciela organizacji, ostatniego aktywnego administratora oraz wyznaczonego inspektora ds. zgodności kanału zgłoszeń nie można dezaktywować. Wszystkie zdarzenia dezaktywacji i ponownej aktywacji są zapisywane w dzienniku audytu tylko do dopisywania.

Usunięcie członka dezaktywuje członkostwo zamiast je usuwać, dzięki czemu ślad audytowy i historia zgłoszeń pozostają możliwe do odtworzenia. Członkostwo jest trwale usuwane tylko wtedy, gdy usunięte zostaje własne konto członka albo sama organizacja.

Usunięcie konta #

Gdy członek zamyka własne konto, jego adres e-mail zostaje zastąpiony niedoręczalnym adresem zastępczym, a jego awatar, dane uwierzytelniania dwuskładnikowego, sesje, tokeny API i preferencje są trwale usuwane; konto nie może się już uwierzytelnić ani nie można się z nim skontaktować. Jeżeli konto nigdy nie wykonywało działań w organizacji, rekord jest usuwany w całości. Jeżeli wykonywało, imię i nazwisko członka pozostaje, a jego członkostwa są dezaktywowane, aby zachowane notatki do spraw, wiadomości i wpisy audytowe pozostały możliwe do przypisania. Okres przechowywania określa Administrator zgodnie ze swoimi udokumentowanymi poleceniami i obowiązującym prawem; prawo do usunięcia danych na podstawie RODO pozostaje przedmiotem mających zastosowanie wyjątków dotyczących obowiązków prawnych lub roszczeń.

Oczyszczone konto nie może się uwierzytelnić żadną drogą: linkiem magicznym, asercją SSO ani tokenem API.

Limitowanie żądań #

Publiczne endpointy kanału zgłoszeń 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 #

Określone zdarzenia dotyczące zgłoszeń i kont są rejestrowane z następującymi danymi:

• Znacznik czasu (UTC)
• Wykonawca (który użytkownik lub proces systemowy wykonał akcję)
• Typ akcji (na przykład zgłoszenie utworzone, status zmieniony, wiadomość wysłana, prowadzący przypisany, zgłoszenie wyeksportowane lub zgłoszenie usunięte). Każde wyświetlenie danego zgłoszenia przez prowadzącego jest rejestrowane, z deduplikacją do jednego wpisu na prowadzącego na zgłoszenie na 24 godziny; w ten sam sposób rejestrowane są wyświetlenia zgłoszenia przez zgłaszającego w ramach dalszej komunikacji. Odczyty innych zasobów nie są rejestrowane.

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 zadanie w tle usuwa zgłoszenie i powiązane z nim dane ze środowiska produkcyjnego; kopie zapasowe wygasają zgodnie z odrębnym, udokumentowanym cyklem życia.

Administrator pozostaje odpowiedzialny za wybór okresu, który spełnia wymóg ograniczenia przechowywania z RODO oraz mające zastosowanie krajowe przepisy o prowadzeniu rejestrów.

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 #

• Podstawowe przechowywanie danych zgłoszeń i spraw odbywa się w Unii Europejskiej. Dostarczanie e-maili i telemetria aplikacji mają odrębne łańcuchy dalszych dostawców; zob. DPA .
• 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 wysyła powiadomienia do prowadzących oraz opcjonalne potwierdzenia i powiadomienia o nowych wiadomościach do zgłaszających. Powiadomienia dla zgłaszających zawierają adres e-mail odbiorcy, kod dostępu do zgłoszenia i link, ale nie treść zgłoszenia. Dalszy łańcuch wsparcia Mailjet może obejmować dostęp spoza EOG; zob. DPA .
• Strona marketingowa jest dostarczana przez Cloudflare (CDN, Stany Zjednoczone); kanał zgłoszeń i panel prowadzących nie. To odrębne przetwarzanie publicznej strony i zabezpieczenia transferów opisano w Polityce prywatności , a nie na liście podprzetwarzających w DPA zawieranej z klientem.

Kopie zapasowe i przywracanie #

EthicsPortal utrzymuje trzy uzupełniające się warstwy kopii zapasowych, wszystkie 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, a także na żądanie, i przywraca najnowszy zrzut do jednorazowego środowiska. Test odszyfrowuje zrzut, przywraca go, porównuje każdą tabelę z bieżącą produkcją, a następnie uruchamia aplikację na przywróconej bazie, aby potwierdzić, że zaszyfrowana kolumna nadal daje się odszyfrować , że jeden zaszyfrowany załącznik otwiera się kluczem przechowywanym w przywróconym zrzucie, oraz że każdy załącznik starszy niż godzina ma nienaruszoną kopię w lokalizacji kopii zapasowej — sama liczba wierszy nie pozwala odróżnić użytecznej kopii od szyfrogramu, do którego klucz już nie pasuje. Świeżość kopii zapasowych jest stale monitorowana (alert, jeśli najnowszy zrzut jest starszy niż 36 godzin).

Szyfrowanie. Hetzner podaje, że Object Storage domyślnie nie szyfruje obiektów w spoczynku, dlatego zrzuty bazy danych są szyfrowane, zanim opuszczą hosta: GnuPG symetrycznie AES-256, a hasło zna wyłącznie proces tworzenia kopii i jest zdeponowane poza maszyną. Pola warstwy aplikacji zaszyfrowane przez Rails ActiveRecord Encryption pozostają dodatkowo zaszyfrowane wewnątrz każdego zrzutu. Załączniki są szyfrowane w spoczynku osobnymi kluczami dla każdego pliku (zob. załączniki ). Klucze te istnieją wyłącznie w bazie danych, więc każdy zaszyfrowany zrzut je zawiera. Same pliki nie są kopiowane do zrzutu. Każdy plik jest przechowywany w Norymberdze i kopiowany, z tym samym kluczem, do drugiego zasobnika w Falkenstein; w obu miejscach wcześniejsze wersje są zachowywane przez 30 dni.

Przegląd operacyjny #

Część materiałów operacyjnych jest udostępniana podczas oceny dostawcy zamiast publikowania ich w całości 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ą:

• 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. Ujawnianie jest nieodpłatne: 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: 12 października 2026