> Techniczne środki bezpieczeństwa w EthicsPortal — szyfrowanie, anonimowość, kontrola dostępu, dziennik audytu i szczegóły infrastruktury do przeglądu zgodności.

Source: https://ethicsportal.eu/pl/security/
Updated: 2026-08-24

---

# 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 {#data-encryption}

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ść {#anonymity-and-privacy}

### 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](https://www.clamav.net), 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](https://www.cloudflare.com/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 {#kontrola-dostepu}

Autoryzacja jest egzekwowana na poziomie aplikacji przy użyciu polityk [Pundit](https://github.com/varvet/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 {#append-only-audit-trail}

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 {#secure-development-lifecycle}

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ń](/iso-27001/)).

| 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](https://brakemanscanner.org), [bundler-audit](https://github.com/rubysec/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](#zarzadzanie-zaleznosciami-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](#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](/incidents/), jeżeli spełniają kryteria zakresu rejestru. |

---

## Zarządzanie zależnościami i poprawkami {#zarzadzanie-zaleznosciami-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](https://brakemanscanner.org)** wykrywa podatności specyficzne dla Rails przy każdej zmianie.
- **[bundler-audit](https://github.com/rubysec/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](https://docs.github.com/en/code-security/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](https://www.hetzner.com) | Norymberga, Niemcy (UE) |
| Przechowywanie plików | [Hetzner Object Storage](https://www.hetzner.com/storage/object-storage) | Norymberga, Niemcy (UE) |
| E-maile transakcyjne | [Mailjet](https://www.mailjet.com) | Francja (UE) |
| Przetwarzanie płatności | [Stripe](https://stripe.com) | 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](/subprocessors/).

---

## 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](/sla/#cele-odzyskiwania).

**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](mailto: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.