> Technische Sicherheitsmaßnahmen in EthicsPortal — Verschlüsselung, Anonymität, Zugriffskontrolle, Audit-Protokollierung und Infrastrukturdetails für die Compliance-Prüfung. Source: https://ethicsportal.eu/de/security/ Updated: 2026-09-23 --- # Sicherheit EthicsPortal verarbeitet sensible Hinweisgeberdaten. Diese Seite dokumentiert die technischen und organisatorischen Maßnahmen, die wir dafür umsetzen. Sie richtet sich an Compliance-Verantwortliche, Datenschutzbeauftragte und Rechtsabteilungen, die die Plattform bewerten. Zuletzt aktualisiert: 2026-08-28. --- ## Datenverschlüsselung {#data-encryption} Alle sensiblen Felder werden mit Rails Active Record Encryption **nicht-deterministisch** verschlüsselt (jede Verschlüsselung erzeugt einen einzigartigen Chiffretext und verhindert Mustererkennung). | Feld | Verschlüsselt | Deterministisch | |---|---|---| | Meldungsbeschreibung | Ja | Nein | | Name der hinweisgebenden Person | Ja | Nein | | Kontaktdaten der hinweisgebenden Person | Ja | Nein | | Nachrichteninhalt (hinweisgebende Person ↔ Fallbearbeitung) | Ja | Nein | | Strukturierte Angaben bei der Meldung (Beziehung, Quelle, Zeitpunkt, frühere Meldung, Sorge vor Repressalien) | Ja | Nein | | Interne Fallnotizen | Ja | Nein | | Zwei-Faktor-Geheimnisse und Backup-Codes | Ja | Nein | Nicht-deterministische Verschlüsselung bedeutet, dass diese Felder auf Datenbankebene nicht nach Wert abfragbar sind. Auch bei vollem Datenbankzugriff kann ein Angreifer keine bestimmten Namen datensatzübergreifend finden. Alle Verbindungen zu EthicsPortal laufen über **HTTPS/TLS**. Unverschlüsselte HTTP-Anfragen werden weitergeleitet. --- ## Anonymität und Datenschutz {#anonymity-and-privacy} ### IP-Anonymisierung EthicsPortal **speichert niemals IP-Adressen**. Portal-Routen (Meldungsabgabe, Fallabruf, Nachrichten) nutzen ausschließlich für das Rate-Limiting einen Einweg-SHA256-Hash der IP-Adresse. Der Hash ist nicht umkehrbar — aus dem gespeicherten Wert lässt sich die ursprüngliche IP nicht rekonstruieren. Dies gilt für alle portal-seitigen Endpunkte. Keine IP-Adresse wird in irgendein Protokoll, Datenbankfeld oder Analytics-System geschrieben. ### Entfernung von Dateimetadaten Hochgeladene Dateien werden **vor** der Speicherung automatisch von identifizierenden Metadaten bereinigt: | Dateityp | Entfernte Metadaten | Methode | |---|---|---| | Bilder (JPEG, PNG, TIFF, WebP) | EXIF-Daten: GPS-Koordinaten, Kameramodell, Seriennummer, Autor, Zeitstempel | Vips-Bildverarbeitung | | PDF-Dokumente | Autor, Erstellerprogramm, Änderungshistorie | exiftool | | Video-Dateien | GPS, Geräte-Info, Aufnahmesoftware | exiftool | | Audio-Dateien | Aufnahmegerät, GPS, Software-Tags | exiftool | Hinweisgebende Personen müssen nicht darauf vertrauen, dass ihre Dateien sicher sind — Metadaten werden serverseitig entfernt, unabhängig vom Dateiinhalt. ### Virenprüfung Alle hochgeladenen Dateien werden automatisch mit [ClamAV](https://www.clamav.net), einer Open-Source-Antivirenlösung, geprüft. Die Prüfung erfolgt serverseitig in einem Hintergrundprozess nach dem Upload. Infizierte Dateien werden automatisch entfernt und erreichen die Fallbearbeitung nicht. Die Prüfung erfolgt auf EthicsPortal-Infrastruktur — es werden keine Dateidaten an Drittdienste übermittelt. ### Anonymität der Fallbearbeitung Hinweisgebende Personen sehen nie die echten Namen oder E-Mail-Adressen der Personen, die ihre Meldung bearbeiten. Alle Nachrichten aus der Bearbeitung werden als **„Fallbearbeitung"** angezeigt. Damit wird die Identität geschützt und Social Engineering erschwert. ### Kein Tracking EthicsPortal setzt keine Tracking-Cookies von Drittanbietern, keine Werbe-Pixel und keine Fingerprinting-Skripte ein. Wir nutzen [Cloudflare Web Analytics](https://www.cloudflare.com/web-analytics/) ausschließlich auf Marketing-Seiten. Es setzt keine Analyse-Cookies, Cloudflare kann jedoch Anfragemetadaten einschließlich IP-Adressen verarbeiten, wie in der [Datenschutzerklärung](/privacy/) beschrieben. Der Meldekanal selbst enthält keine Analyse-Tools. ### Aktueller Nachweisstatus EthicsPortal beansprucht auf dieser Website derzeit keine akkreditierte ISO-27001-Zertifizierung. Ebenso wird derzeit kein unabhängiger Drittbericht zur Anonymitätsarchitektur veröffentlicht. Falls sich das ändert, werden Umfang und Datum hier veröffentlicht. ### Unterlagen für den Sicherheitsreview Kunden, die Unterlagen für Beschaffung oder Rechtsprüfung benötigen, können diese im Rahmen des Reviews anfordern. Verfügbare Unterlagen können einen gegengezeichneten AVV, Register- und Steuernachweise, einen ausgefüllten Sicherheitsfragebogen sowie schriftliche Antworten zu Backup- und Restore-Verfahren, privilegiertem Produktionszugang und Incident Response umfassen. --- ## Zugriffskontrolle {#access-control} Die Autorisierung wird auf Anwendungsebene mit [Pundit](https://github.com/varvet/pundit)-Richtlinien durchgesetzt. | Rolle | Darf Meldungen einsehen | Darf Organisationseinstellungen verwalten | Darf Bearbeitende zuweisen | |---|---|---|---| | Admin | Alle Meldungen | Ja | Ja | | Fallbearbeitung | Nur zugewiesene Meldungen | Nein | Nein | | Betrachter | Nur Lesezugriff, für Auditoren und Rechtsbeistand | Nein | Nein | - Bearbeitende sehen keine Meldungen, die ihnen nicht zugewiesen sind. - Hinweisgebende Personen haben kein Nutzerkonto — der Zugriff erfolgt über eine Vorgangs-ID (`WB-XXXX-XXXX`) und einen 6-stelligen Zugangscode, den sie bei der Abgabe wählen. - Jede Controller-Aktion prüft die Autorisierung. Unbefugte Zugriffsversuche werden blockiert und protokolliert. ### Zwei-Faktor-Authentifizierung {#two-factor-authentication} Konten der Fallbearbeitung und der Admins können TOTP-basierte 2FA über gängige Authenticator-Apps aktivieren (Google Authenticator, 1Password, Authy und kompatible Alternativen). Nach Aktivierung sind bei der Anmeldung die Hauptanmeldeinformation und ein rotierender 6-stelliger Code erforderlich. Auch hinweisgebende Personen authentifizieren mit zwei Faktoren: die Vorgangs-ID (etwas, das sie besitzen) und der selbst gewählte Zugangscode (etwas, das sie wissen). Der Zugangscode wird ausschließlich als bcrypt-Hash gespeichert und ist nicht wiederherstellbar. Das Nachverfolgungspostfach und das Versenden von Nachrichten sind an diese Prüfung gebunden — eine geleakte Vorgangs-ID allein genügt also nicht, um die Meldung einzusehen oder die hinweisgebende Person zu imitieren. ### Sitzungslebenszyklus Jede authentifizierte Sitzung erfasst bei jeder Anfrage `last_seen_at` (entprellt). Nutzer können ihre aktiven Sitzungen einsehen, sehen, wann jede zuletzt aktiv war, einzelne Sitzungen widerrufen oder sich aus allen anderen Sitzungen gleichzeitig abmelden — über die Kontoeinstellungen. Sitzungen verfallen automatisch nach **14 Tagen Inaktivität**. Die nächste Anfrage einer inaktiven Sitzung löscht den serverseitigen Datensatz, entfernt das Cookie und erzwingt eine erneute Authentifizierung über einen neuen Magic Link. Ein nächtlicher Job räumt verlassene Sitzungen anhand desselben Timeouts auf, sodass `user_agent` und `ip_address` nicht über das Inaktivitätsfenster hinaus aufbewahrt werden, selbst wenn der Nutzer nicht zurückkehrt. Die Magic-Link-Authentifizierung begrenzt den Schaden langlebiger Sitzungen: Ein gestohlenes Sitzungs-Cookie liefert kein wiederverwendbares Anmeldemittel, und eine erneute Authentifizierung erfordert Zugriff auf das E-Mail-Konto. ### Mitgliederzugriff und Offboarding Der Organisationszugriff wird an der Anfragegrenze durchgesetzt. Wird ein Mitglied deaktiviert: - Der Zugriff auf die Organisation wird sofort abgewiesen, auch über zuvor mit Lesezeichen gespeicherte URLs. - Offene Meldungszuweisungen werden aufgehoben. - Teilnehmerschaften werden entfernt. - Die dem Mitglied zurechenbare Audit-Protokoll-Historie bleibt erhalten. - Das deaktivierte Mitglied wird benachrichtigt. - Eine Reaktivierung stellt frühere Fallzugriffe nicht automatisch wieder her. Der Eigentümer der Organisation, der letzte aktive Admin und die benannte Compliance-Beauftragte Person des Portals können nicht deaktiviert werden. Alle Deaktivierungs- und Reaktivierungsereignisse werden in das ausschließlich anzuhängende Audit-Protokoll geschrieben. Beim Entfernen eines Mitglieds wird die Mitgliedschaft deaktiviert und nicht gelöscht, damit Audit-Protokoll und Fallhistorie auflösbar bleiben. Hart gelöscht wird eine Mitgliedschaft nur, wenn das Konto des Mitglieds selbst oder die Organisation gelöscht wird. ### Kontolöschung Schließt ein Mitglied sein eigenes Konto, wird seine E-Mail-Adresse durch einen nicht zustellbaren Platzhalter ersetzt und Zwei-Faktor-Anmeldedaten, Sitzungen, API-Token und Präferenzen werden dauerhaft entfernt; das Konto kann sich nicht mehr anmelden und nicht mehr kontaktiert werden. Hat das Konto nie innerhalb einer Organisation gehandelt, wird der Datensatz vollständig gelöscht. Andernfalls bleiben Name und Profilbild des Mitglieds erhalten und seine Mitgliedschaften werden deaktiviert, damit die ihm zugeordneten Fallnotizen, Nachrichten und Audit-Einträge einer namentlich benannten Person zuordenbar bleiben --- eine Aufbewahrung, die Art. 18 der Richtlinie 2019/1937 verlangt und Artikel 17(3)(b) DSGVO erlaubt. Ein bereinigtes Konto kann sich über keinen Weg mehr anmelden: weder per Magic Link noch per SSO-Assertion oder API-Token. ### Rate-Limiting Öffentliche Portal-Endpunkte sind rate-limitiert, um Missbrauch und Enumerationsangriffe zu verhindern: | Endpunkt | Limit | |---|---| | Meldungsabgabe | 5 pro 10 Minuten je anonymisierter IP | | Fallabruf (Vorgangs-ID + Zugangscode) | 10 pro 3 Minuten je anonymisierter IP | | Nachrichtenversand | 10 pro 3 Minuten je anonymisierter IP | Das Rate-Limiting nutzt den oben beschriebenen Einweg-Hash — es wird keine echte IP gespeichert. --- ## Audit und Compliance ### Revisionssicheres Audit-Protokoll {#append-only-audit-trail} Jede Aktion in EthicsPortal wird protokolliert mit: - **Zeitstempel** (UTC) - **Akteur** (welcher Nutzer oder Systemprozess die Aktion ausgeführt hat) - **Aktionstyp** (Meldung erstellt, Status geändert, Nachricht gesendet, Bearbeitung zugewiesen, Meldung eingesehen, Meldung exportiert, Meldung gelöscht usw.) Die Protokolleinträge sind ausschließlich anzuhängen. Sie können von keiner Person — auch nicht von Organisations-Admins — bearbeitet oder gelöscht werden. Das vollständige Audit-Protokoll ist im PDF-Fallexport enthalten und steht der Aufsicht zur Verfügung. ### Aufbewahrungsdauer Organisationen legen ihre Aufbewahrungsdauer selbst fest: **12, 24, 36, 48 oder 60 Monate** nach Abschluss einer Meldung. Nach Ablauf werden die Meldung und alle zugehörigen Daten (Nachrichten, Anhänge, Protokolleinträge) durch einen Hintergrund-Job automatisch und dauerhaft gelöscht. Damit werden die Anforderungen der DSGVO an die Speicherbegrenzung (Art. 5 Abs. 1 lit. e) und die Dokumentationspflichten der Richtlinie 2019/1937 (Art. 17–18) erfüllt. ### CSRF-Schutz Alle Formularübermittlungen sind über Rails' eingebaute CSRF-Tokens gegen Cross-Site Request Forgery geschützt. --- ## Sicherer Entwicklungszyklus {#secure-development-lifecycle} EthicsPortal folgt einem dokumentierten Entwicklungszyklus für Änderungen, die den Dienst betreffen. Die Phasen sind hier aufgeführt, damit eine prüfende Person aus der Beschaffung sie den Controls A.8.25--A.8.29 nach ISO/IEC 27001:2022 zuordnen kann (die vollständige Zuordnung steht in der [Control-Map](/iso-27001/)). | Phase | Praxis | |---|---| | Architektur und Design | Funktionen, die neue Flüsse personenbezogener Daten, Unterauftragsverarbeiter oder Berechtigungsbereiche einführen, werden vor der Umsetzung gegen die auf dieser Seite dokumentierten Zusagen zu Verschlüsselung, Zugriffskontrolle und Audit-Trail geprüft. | | Änderungsprüfung | Jede Produktionsänderung wird vor der Auslieferung anhand einer schriftlichen Checkliste geprüft (Verschlüsselungsabdeckung, Berechtigungsbereich, Ausgabe von Audit-Logs, Eingabevalidierung, Umgang mit Geheimnissen). Die Durchsetzung ist automatisiert und nicht ermessensabhängig: Die vollständige Testsuite und die statische Analyse laufen bei jeder Änderung und blockieren die Auslieferung bei einem Fehler. Die Suite läuft auf einem gehosteten CI-Runner oder auf einer Entwicklungsarbeitsstation, wobei der abgeschlossene Lauf als Commit-Status festgehalten wird, den die Pipeline prüft, bevor sie den gehosteten Lauf überspringt. Rollen für die Änderungsfreigabe werden im Rahmen der Beschaffungsprüfung beschrieben. | | Sichere Programmierung | Die Codebasis nutzt standardmäßig Schutzmechanismen auf Framework-Ebene --- parametrisierte Abfragen über ActiveRecord, Strong Parameters, Ausgabe-Escaping in Views, CSRF-Tokens, Verschlüsselung auf Attributebene, Pundit-Autorisierung an der Controller-Grenze. Abweichungen erfordern eine schriftliche Begründung. | | Sicherheitstests in der Entwicklung | Statische Analyse ([Brakeman](https://brakemanscanner.org), [bundler-audit](https://github.com/rubysec/bundler-audit), `importmap audit`) läuft bei jeder Änderung. Tests decken Autorisierungspfade, Invarianten der Verschlüsselung im Ruhezustand, die Ausgabe von Audit-Logs und die Durchsetzung von Ratenbegrenzungen ab. Die vollständige Toolchain steht unter [Abhängigkeits- und Patch-Management](#dependency-and-patch-management). | | Umgebungstrennung | Produktions- und Nicht-Produktionsumgebungen sind getrennt. Außerhalb der Produktion werden keine personenbezogenen Produktionsdaten verwendet; Staging und Entwicklung nutzen synthetische Testdaten. | | Reaktion auf Schwachstellen | Meldungen werden innerhalb von 2 Werktagen bestätigt (siehe [verantwortungsvolle Offenlegung](#verantwortungsvolle-offenlegung)). Zielwerte: kritische Probleme innerhalb von 7 Tagen behoben, hohe innerhalb von 30, mittlere innerhalb von 90. Bestätigte Probleme, die eingesetzte Kundensysteme betreffen, werden über das [Vorfallregister](/incidents/) gemeldet, sofern sie die Aufnahmekriterien des Registers erfüllen. | --- ## Abhängigkeits- und Patch-Management {#dependency-and-patch-management} EthicsPortal setzt keine Softwarekomponenten ein, deren Support ausgelaufen ist. Die Anwendung läuft auf aktiv unterstützten Versionen von Rails, Ruby, PostgreSQL und dem zugrundeliegenden Betriebssystem; Sicherheits-Releases der Upstream-Projekte werden fortlaufend eingespielt. Abhängigkeiten werden in CI kontinuierlich geprüft: - **[Brakeman](https://brakemanscanner.org)** meldet Rails-spezifische Schwachstellen bei jeder Änderung. - **[bundler-audit](https://github.com/rubysec/bundler-audit)** prüft das Gemfile bei jeder Änderung und zusätzlich täglich nach einem festen Zeitplan gegen die Ruby Advisory Database, sodass neu veröffentlichte Sicherheitshinweise auch ohne Codeänderung erkannt werden. - **`importmap audit`** prüft JavaScript-Imports bei jeder Änderung und zusätzlich täglich nach einem festen Zeitplan auf bekannte Schwachstellen. - **[Dependabot](https://docs.github.com/en/code-security/dependabot)** erstellt wöchentlich Pull Requests für veraltete Ruby-Gems und GitHub Actions, gruppiert nach Minor-/Patch-Updates. Komponenten, deren Upstream-Support ausläuft, werden vor Ablauf des Support-Zeitraums ersetzt oder aktualisiert. --- ## Infrastruktur {#infrastructure} | Komponente | Anbieter | Standort | |---|---|---| | Anwendungs-Server und Datenbank | [Hetzner](https://www.hetzner.com) | Nürnberg, Deutschland (EU) | | Dateispeicher | [Hetzner Object Storage](https://www.hetzner.com/storage/object-storage) | Nürnberg, Deutschland (EU) | | Transaktionale E-Mails | [Mailjet](https://www.mailjet.com) | Frankreich (EU) | | Zahlungsabwicklung | [Stripe](https://stripe.com) | Irland; weitere Länder unter geltenden Garantien — siehe [Datenschutzerklärung](/privacy/) | - Die zentrale Verarbeitung von Meldungen und Falldaten erfolgt ausschließlich innerhalb der Europäischen Union. - Es werden keine Kreditkartennummern oder Zahlungsdaten auf EthicsPortal-Servern gespeichert. Die Zahlungsabwicklung übernimmt vollständig Stripe. - Mailjet wird für transaktionale E-Mails genutzt (Benachrichtigungen an die Fallbearbeitung, nicht an hinweisgebende Personen). Mailjet hat seinen Sitz in Frankreich und verarbeitet alle Daten innerhalb der EU. - Die Marketing-Website wird über Cloudflare (CDN, USA) ausgeliefert; das Berichtsportal und das Bearbeiter-Portal nicht. Diese gesonderte Verarbeitung der öffentlichen Website und ihre Übermittlungsgarantien sind in der [Datenschutzerklärung](/privacy/) beschrieben. --- ## Backup und Restore {#backups-and-restore} EthicsPortal betreibt zwei sich ergänzende Backup-Ebenen, beide werden innerhalb der EU vorgehalten: | Ebene | Was | Wo | Aufbewahrung | |---|---|---|---| | Datenbank | Tägliche PostgreSQL-Dumps über ein Kamal-Accessory | Hetzner Object Storage, Nürnberg (EU) | 21 Tage für aktuelle Versionen; gelöschte Versionen verfallen nach weiteren 7 Tagen | | Server | Vollständige Disk-Snapshots des Anwendungs-Hosts | Hetzner Cloud, Nürnberg (EU) | 7 Tage | **Recovery-Ziele.** Das Recovery Point Objective (RPO) beträgt 24 Stunden. Das Recovery Time Objective (RTO) beträgt 4 Stunden. Diese Ziele sind auch im [Service Level Agreement](/sla/#recovery-objectives) hinterlegt. **Restore-Tests.** Eine Restore-Übung wird monatlich automatisch über einen CI-Workflow in einer Wegwerf-Umgebung durchgeführt. Die Aktualität der Backups wird laufend überwacht. **Verschlüsselung.** Anwendungsseitig verschlüsselte Datenbankfelder bleiben im Dump verschlüsselt. Hetzner Object Storage verschlüsselt Objekte standardmäßig nicht im Ruhezustand; die Verschlüsselung ganzer Dumps und Anhänge ist nicht nachgewiesen. --- ## Operativer Review Diese Seite ist eine öffentliche Sicherheitszusammenfassung. Ein Teil der operativen Unterlagen wird im Rahmen des Beschaffungsreviews bereitgestellt und nicht vollständig im offenen Web veröffentlicht, weil sie Infrastruktur- und Reaktionsdetails enthalten, die sich für eine kontrollierte Offenlegung besser eignen. Auf Anfrage im Beschaffungsreview verfügbare Themen sind unter anderem: - Zusammenfassung des privilegierten Produktionszugangs - Incident-Response-Ablauf und Eskalationskontakte - Business-Continuity- sowie Offboarding-/Export-Antworten --- ## Verantwortungsvolle Offenlegung Wenn Sie eine Sicherheitslücke in EthicsPortal entdecken, melden Sie diese bitte an [security@ethicsportal.eu](mailto:security@ethicsportal.eu). Wir bitten Sie: 1. die Lücke nicht öffentlich zu machen, bevor wir Gelegenheit zur Behebung hatten, 2. genug Details bereitzustellen, damit wir das Problem reproduzieren und beheben können, 3. nicht auf Daten anderer Kunden zuzugreifen oder diese zu verändern. Wir bestätigen Ihre Meldung innerhalb von 2 Werktagen und arbeiten an einer zeitnahen Behebung bestätigter Lücken. **Kein bezahltes Bug-Bounty-Programm.** Wir vergüten Schwachstellenmeldungen nicht und schließen weder Geheimhaltungsvereinbarungen noch kommerzielle Vereinbarungen ab; auch ein Telefonat ist keine Voraussetzung für die Entgegennahme einer Meldung. Senden Sie das betroffene System, die Reproduktionsschritte und die von Ihnen festgestellte Auswirkung an die oben genannte Adresse.