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-11-04.

Datenverschlüsselung #

Die unten aufgeführten sensiblen Datenbankfelder werden im Ruhezustand mit Rails Active Record Encryption nicht-deterministisch verschlüsselt (jede Verschlüsselung erzeugt einen einzigartigen Chiffretext und verhindert Mustererkennung). Die Feldverschlüsselung umfasst weder vollständige Datenbank-Dumps noch Dateianhänge; diese werden gesondert verschlüsselt, wie unter Dateianhänge und Backup und Restore beschrieben.

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.

Dateianhänge #

Dateien, die an Meldungen, Nachrichten und interne Notizen angehängt sind, Sprachaufnahmen sowie Exporte von Falldaten werden in Hetzner Object Storage im Ruhezustand mit AES-256 verschlüsselt, mit einem eigenen zufälligen Schlüssel für jede Datei (serverseitige Verschlüsselung mit kundenseitig bereitgestellten Schlüsseln). Der Schlüssel wird mit jeder Speicheranfrage übermittelt, und Hetzner verweigert jeden Lesezugriff ohne ihn. EthicsPortal speichert ihn in der Datenbank unter der oben beschriebenen Active Record Encryption, sodass die Zugangsdaten zum Speicher allein keine Datei lesbar machen: Dafür werden zusätzlich die Datenbank und die Verschlüsselungsschlüssel der Anwendung benötigt. Dateien erreichen berechtigte Nutzer per Streaming über die Anwendung, nie über einen direkten Speicherlink.

Vor dem 6. Oktober 2026 hochgeladene Dateien wurden an diesem Tag neu verschlüsselt, und ihre unverschlüsselten Kopien, einschließlich aufbewahrter früherer Versionen, wurden gelöscht. Dateien, die keine Meldungsdaten sind, etwa Profilbilder und Teilen-Vorschaubilder von Organisationen, werden nicht auf diese Weise verschlüsselt. Nichts davon schützt vor einer Kompromittierung des Anwendungsservers, der Speicherzugangsdaten, Datenbank und Schlüssel gemeinsam vorhält.

Alle Verbindungen zu EthicsPortal laufen über HTTPS/TLS. Unverschlüsselte HTTP-Anfragen werden weitergeleitet.

Anonymität und Datenschutz #

IP-Adressen #

EthicsPortal speichert die IP-Adresse einer hinweisgebenden Person weder bei Meldungen noch bei Nachrichten oder Audit-Einträgen, und die Anwendungsprotokolle für den Meldekanal enthalten keine IP-Adressen.

Das Rate-Limiting auf dem Meldekanal (Meldungsabgabe, Fallabruf, Nachrichten) basiert auf einem gekürzten, schlüsselbasierten SHA-256-Hash der IP-Adresse der Anfrage. Der Hash ist pseudonym, nicht anonym: Er lässt sich nicht als Adresse zurücklesen, doch wer das Anwendungsgeheimnis besitzt, könnte mögliche Adressen dagegen prüfen. Er wird nur für die Dauer des Rate-Limit-Fensters (höchstens 10 Minuten) verwendet; ein Hintergrundjob löscht ihn spätestens 5 Minuten nach Ablauf des Fensters aus dem Cache.

Der TLS-Proxy vor der Anwendung führt ein eigenes Anfrageprotokoll: IP-Adresse, Anfragepfad, User-Agent und Antwortstatus. Der Pfad der Seite, auf der eine hinweisgebende Person ihre Meldung aufruft, enthält die Vorgangs-ID. Ein Eintrag für diese Seite lässt sich daher der Meldung zuordnen. Sie werden in einer einzigen, 10 MB großen Protokolldatei gehalten, die beim Volllaufen überschrieben wird, derzeit nach etwa zwei Tagen; die unter Backup und Restore beschriebenen 7-Tage-Server-Snapshots können eine Kopie enthalten.

Entfernung von Dateimetadaten #

Hochgeladene Dateien werden vor der Speicherung automatisch von identifizierenden Metadaten bereinigt:

Die Entfernung der Metadaten erfolgt serverseitig vor der Speicherung. Bei Dateitypen, die exiftool verarbeitet, setzt dies voraus, dass die Standard-Werkzeuge der Produktionsumgebung vorhanden sind.

In einem PDF bleiben die Namen bei Kommentaren und die Metadaten eingebetteter Fotos, etwa GPS-Position und Seriennummer der Kamera, erhalten. Eine hinweisgebende Person, die diese entfernen möchte, sollte Fotos als separate Bilddateien hochladen und Kommentare vor dem Hochladen eines PDF entfernen.

Virenprüfung #

Dateien, die an Meldungen, Nachrichten und interne Notizen angehängt sind, werden automatisch mit ClamAV, einer Open-Source-Antivirenlösung, geprüft. Die Prüfung erfolgt serverseitig in einem Hintergrundprozess nach dem Upload. Dateien, die die Prüfung nicht bestanden haben, werden nicht ausgeliefert, und infizierte Dateien werden automatisch entfernt.

Die Prüfung erfolgt auf EthicsPortal-Infrastruktur — es werden keine Dateidaten an Scan-Dienste Dritter übermittelt.

Meldungen per E-Mail #

Jeder Meldekanal hat eine eigene E-Mail-Adresse unter report.ethicsportal.eu. Eine E-Mail an diese Adresse wird zu einem Fall in diesem Meldekanal, genauso wie eine Meldung über das Online-Meldeformular. Meldungen per E-Mail sind standardmäßig eingeschaltet. Eine Organisation kann sie in den Einstellungen des Meldekanals ausschalten; die Adresse weist dann innerhalb einer Minute neue E-Mails ab.

• Eigener Mailserver. E-Mails an diese Adressen empfängt der eigene Mailserver von EthicsPortal auf derselben Infrastruktur in Deutschland, kein externer E-Mail-Anbieter. Er nimmt nur E-Mails an Meldekanal-Adressen an, lehnt alle anderen Adressen ab und leitet nichts weiter.
• Transportverschlüsselung. Der Server bietet TLS 1.2 oder höher mit einem Let’s-Encrypt-Zertifikat an. TLS ist opportunistisch: Ein sendender Server, der TLS nicht unterstützt, liefert unverschlüsselt aus.
• Absenderadresse für die Fallbearbeitung verborgen. Die Adresse des Absenders wird verschlüsselt gespeichert und der Fallbearbeitung nie angezeigt, weder im Fall noch in dessen PDF oder in Exporten. EthicsPortal verwendet sie nur, um der hinweisgebenden Person die Eingangsbestätigung und Hinweise auf neue Nachrichten zu senden.
• Zugang ohne E-Mail. Die Eingangsbestätigung enthält die Vorgangs-ID und ein Einmal-Passwort für das sichere Postfach, das bei der ersten Anmeldung ersetzt wird. Rückfragen und Antworten bleiben im Postfach, nicht in der E-Mail. Lehnt die eigene Domain des Absenders die Adresse in ihrer DMARC-Richtlinie ab, wird die Meldung gespeichert, aber kein Passwort versendet. Nach 10 per E-Mail eingegangenen Meldungen an eine Organisation oder 50 bei EthicsPortal insgesamt innerhalb von 24 Stunden werden weitere Meldungen gespeichert, aber es wird keine E-Mail versendet: keine Eingangsbestätigung an die hinweisgebende Person und kein E-Mail-Hinweis an die Administratoren, die den Fall weiterhin in der Anwendung sehen.
• Anhänge. Dateien durchlaufen dieselbe Entfernung von Metadaten und dieselbe Virenprüfung wie Uploads über das Formular. Dateien, die nicht angenommen werden können (anderer Dateityp, zu groß oder nicht zu bereinigen), werden weggelassen, und die hinweisgebende Person erfährt, wie viele es waren.
• Kopien. Eine Nachricht wartet in der Warteschlange des Mailservers auf demselben Server nur so lange, bis die Anwendung sie übernimmt. Die Anwendung bewahrt die Original-E-Mail verschlüsselt auf, bis der Fall gespeichert ist, und löscht sie dann. Die Protokolle des Mailservers erfassen Meldekanal-Adressen, nie die Adresse des Absenders.
• Absenderprüfung. SPF, DKIM und DMARC werden auf EthicsPortal-Infrastruktur geprüft. Es werden keine Nachrichtendaten an externe Spam- oder Reputationsdienste übermittelt.

E-Mail ist nicht anonym: Der E-Mail-Anbieter der hinweisgebenden Person und, wenn sie von einem dienstlichen Konto schreibt, die E-Mail-Systeme der Organisation können Kopien und Aufzeichnungen der Nachricht aufbewahren. Die Eingangsbestätigung weist darauf hin und verlinkt auf das Online-Meldeformular für hinweisgebende Personen, die anonym bleiben möchten.

E-Mail für Neuigkeiten #

Das Online-Meldeformular hat ein optionales E-Mail-Feld für Neuigkeiten. An diese Adresse gehen die Eingangsbestätigung und ein Hinweis, wenn die Fallbearbeitung schreibt, nie der Inhalt der Meldung. Sie wird verschlüsselt gespeichert und, wie die Absenderadresse einer per E-Mail eingegangenen Meldung, auf keiner Seite der Fallbearbeitung, in keinem PDF und in keinem Export angezeigt. Das Feld bleibt verfügbar, wenn die hinweisgebende Person anonym meldet. Nur wenn die hinweisgebende Person „Anonym melden“ ausschaltet und „meine E-Mail-Adresse auch den Fallbearbeitern zeigen“ ankreuzt, wird daraus eine Kontaktadresse, die die Fallbearbeitung sieht.

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 Plausible Analytics ausschließlich auf der Marketing-Website, ausgeliefert über unsere eigene Domain. Es setzt keine Cookies und speichert keine IP-Adressen. Cloudflare, das die Marketing-Website ausliefert, verarbeitet Anfragemetadaten einschließlich IP-Adressen, wie in der Datenschutzerklärung 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 der Beschaffung 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 #

Die Autorisierung wird auf Anwendungsebene mit Pundit-Richtlinien durchgesetzt.

• Bearbeitende sehen keine Meldungen, denen sie weder zugewiesen sind noch an denen sie teilnehmen. Teilnehmende werden ausdrücklich von einem Admin oder der hauptverantwortlich zugewiesenen Person hinzugefügt (etwa um die Rechts- oder Personalabteilung einzubeziehen).
• Hinweisgebende Personen haben kein Nutzerkonto — sie öffnen ihre Meldung mit einer Vorgangs-ID (WB-XXXX-XXXX) und einem Passwort, das das System bei der Abgabe der Meldung erzeugt.
• Jede Controller-Aktion prüft die Autorisierung. Unbefugte Zugriffsversuche werden blockiert und protokolliert.

Zwei-Faktor-Authentifizierung #

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.

Anmeldung hinweisgebender Personen #

Hinweisgebende Personen melden sich mit ihrer Vorgangs-ID und einem Passwort an. Die Vorgangs-ID kennzeichnet den Vorgang und ist nicht geheim. Das Passwort besteht aus 16 zufälligen Ziffern und wird bei der Abgabe der Meldung vom System erzeugt; die hinweisgebende Person wählt es nicht selbst. Es wird ausschließlich als bcrypt-Hash gespeichert, daher kann niemand es wiederherstellen, und EthicsPortal hat keine Funktion, mit der die hinweisgebende Person, die Fallbearbeitung oder der Betreiber es zurücksetzen könnte. Verliert die hinweisgebende Person das Passwort, reicht sie eine neue Meldung ein und nennt darin die Vorgangs-ID. Vor dem 18. Oktober 2026 abgegebene Meldungen behalten das 6-stellige Passwort, das die hinweisgebende Person damals gewählt hat, und es funktioniert weiterhin. 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.

Unmittelbar nach der Abgabe zeigt eine Bestätigungsseite die Adresse des sicheren Postfachs, die Vorgangs-ID und das Passwort. Sie bleibt in diesem Browser nur abrufbar, solange der Vorgang entsperrt ist, und verschwindet, sobald das Postfach nach 30 Minuten ohne Aktivität gesperrt wird oder die hinweisgebende Person es verlässt. Auf der Anmeldeseite ist das Passwortfeld ein sichtbares Textfeld mit deaktivierter automatischer Vervollständigung statt eines maskierten Passwortfelds, damit Browser nicht anbieten, das Passwort zu speichern; ein vom Arbeitgeber verwalteter Browser könnte es sonst mit dem Konto des Arbeitgebers synchronisieren. Einfügen funktioniert, und Leerzeichen werden ignoriert.

Erfassen Mitarbeitende eine Meldung, die telefonisch, in einem persönlichen Gespräch, per Brief oder per E-Mail eingegangen ist, und möchte die hinweisgebende Person den Vorgang online verfolgen, erzeugt das System ein Einmal-Passwort, das die Fallbearbeitung weitergibt. Es funktioniert nur einmal: Bei der ersten Anmeldung der hinweisgebenden Person wird es serverseitig durch ein neues Passwort ersetzt, das nur die hinweisgebende Person sieht.

Der Zugang der hinweisgebenden Person endet, wenn sie „Verlassen“ wählt, oder nach 30 Minuten ohne Aktivität. Etwa zwei Minuten vor der Sperre bietet eine Warnung an, das Postfach offen zu halten; reagiert niemand, verschwindet der Fall vom Bildschirm. Der Zugang liegt in einem verschlüsselten Cookie im Browser der hinweisgebenden Person; der Server speichert keine Sitzung für sie.

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 für den Meldekanal benannte Compliance-beauftragte Person 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 Profilbild, 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 bleibt der Name des Mitglieds erhalten, während seine Mitgliedschaften deaktiviert werden, damit aufbewahrte Fallnotizen, Nachrichten und Audit-Einträge zuordenbar bleiben. Die Aufbewahrungsdauer bestimmt der Verantwortliche nach seinen dokumentierten Weisungen und dem anwendbaren Recht; das Recht auf Löschung nach der DSGVO steht unter dem Vorbehalt etwaiger Ausnahmen für rechtliche Verpflichtungen oder Rechtsansprüche.

Ein bereinigtes Konto kann sich über keinen Weg mehr anmelden: weder per Magic Link noch per SSO-Assertion oder API-Token.

Rate-Limiting #

Öffentliche Endpunkte des Meldekanals sind rate-limitiert, um Missbrauch und Enumerationsangriffe zu verhindern:

Das Rate-Limiting nutzt den oben beschriebenen schlüsselbasierten IP-Hash — dafür wird keine IP-Adresse gespeichert. Das Limit je Vorgangs-ID nutzt die Vorgangs-ID selbst als Schlüssel; sie wird innerhalb von 15 Minuten aus demselben Cache gelöscht.

Audit und Compliance #

Revisionssicheres Audit-Protokoll #

Festgelegte Meldungs- und Kontoereignisse werden protokolliert mit:

• Zeitstempel (UTC)
• Akteur (welcher Nutzer oder Systemprozess die Aktion ausgeführt hat)
• Aktionstyp (zum Beispiel Meldung erstellt, Status geändert, Nachricht gesendet, Bearbeitung zugewiesen, Meldung exportiert oder Meldung gelöscht). Jede Ansicht einer Meldung durch eine bearbeitende Person wird protokolliert, dedupliziert auf einen Eintrag pro bearbeitender Person und Meldung innerhalb von 24 Stunden; Ansichten der hinweisgebenden Person im Rahmen der Nachverfolgung werden ebenso protokolliert. Lesezugriffe auf andere Ressourcen werden nicht protokolliert.

Die Protokolleinträge sind ausschließlich anzuhängen. Keine Person, auch kein Organisations-Admin, kann einen Eintrag bearbeiten oder einzeln löschen: PostgreSQL-Trigger weisen Änderung und Truncate auf Datenbankebene zurück. Einträge werden nur durch den Aufbewahrungszyklus oder mit der Löschung der Organisation selbst entfernt; privilegierte Eingriffe in die Datenbank bleiben ein dokumentiertes Restrisiko (Risikoregister R-08). Das vollständige Audit-Protokoll ist für die behördliche Prüfung im PDF-Fallexport enthalten.

Aufbewahrungsdauer #

Organisationen legen ihre Aufbewahrungsdauer selbst fest: 12, 24, 36, 48 oder 60 Monate nach Abschluss einer Meldung. Nach Ablauf der Aufbewahrungsdauer löscht ein Hintergrund-Job die Meldung und die zugehörigen Daten aus der Produktion; Backup-Kopien verfallen nach dem gesondert dokumentierten Lebenszyklus.

E-Mails an hinweisgebende Personen hinterlassen keinen Eintrag im Versandverlauf von EthicsPortal. Nach dem Löschen der Meldung bleibt daher keine Adresse einer hinweisgebenden Person zurück.

Der Verantwortliche bleibt dafür verantwortlich, eine Dauer zu wählen, die der Speicherbegrenzung nach der DSGVO und den anwendbaren nationalen Aufbewahrungsvorschriften genügt.

CSRF-Schutz #

Alle Formularübermittlungen sind über Rails’ eingebaute CSRF-Tokens gegen Cross-Site Request Forgery geschützt.

Sicherer Entwicklungszyklus #

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

Abhängigkeits- und 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 meldet Rails-spezifische Schwachstellen bei jeder Änderung.
• 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 erstellt wöchentlich Pull Requests für veraltete Ruby-Gems und GitHub Actions, gruppiert nach Minor-/Patch-Updates.

Kontrollen der Lieferkette begrenzen, was eine kompromittierte Version einer Abhängigkeit erreichen kann:

• Wartezeit für neue Versionen. Neue Gem-Versionen werden erst übernommen, wenn sie seit drei Tagen öffentlich sind; Dependabot-Versionsupdates warten 3, 7 bzw. 14 Tage bei Patch-, Minor- und Major-Releases. Gekaperte Versionen werden in der Regel innerhalb dieses Zeitraums zurückgezogen.
• Fixierte CI-Actions. Jeder GitHub-Actions-Schritt ist auf einen vollständigen Commit-SHA fixiert, sodass ein umgehängter Tag nicht ändern kann, was ausgeführt wird.
• Geprüfte Downloads. Binärdateien, die beim Bau des Container-Images heruntergeladen werden, werden gegen eine fest hinterlegte SHA-256-Prüfsumme geprüft.
• Abgesicherte automatische Updates. Dependabot-Pull-Requests werden erst automatisch zusammengeführt, wenn die vollständige Testsuite und die statische Analyse bestanden sind.

Komponenten, deren Upstream-Support ausläuft, werden vor Ablauf des Support-Zeitraums ersetzt oder aktualisiert.

Infrastruktur #

• Die zentrale Speicherung von Meldungen und Falldaten erfolgt in der Europäischen Union. E-Mail-Zustellung und Anwendungstelemetrie haben eigene nachgelagerte Lieferketten; siehe den AVV.
• Es werden keine Kreditkartennummern oder Zahlungsdaten auf EthicsPortal-Servern gespeichert. Die Zahlungsabwicklung übernimmt vollständig Stripe.
• Mailjet versendet Benachrichtigungen an die Fallbearbeitung sowie optionale Eingangsbestätigungen und Hinweise auf neue Nachrichten an hinweisgebende Personen. Hinweise an hinweisgebende Personen enthalten die E-Mail-Adresse des Empfängers, die Vorgangs-ID und den Link zur Meldung, nicht aber den Meldungsinhalt. Die Eingangsbestätigung für eine per E-Mail eingereichte Meldung enthält zusätzlich ein Einmalpasswort für das sichere Postfach, das bei der ersten Anmeldung der hinweisgebenden Person ersetzt wird. Die nachgelagerte Support-Kette von Mailjet kann Zugriffe außerhalb des EWR umfassen; siehe den AVV.
• Die Marketing-Website wird über Cloudflare (CDN, USA) ausgeliefert; der Meldekanal und die Oberfläche der Fallbearbeitung nicht. Diese gesonderte Verarbeitung der öffentlichen Website und ihre Übermittlungsgarantien sind in der Datenschutzerklärung beschrieben, nicht in der Liste der Unterauftragsverarbeiter im Kunden-AVV.

Backup und Restore #

EthicsPortal betreibt drei sich ergänzende Backup-Ebenen, alle werden innerhalb der EU vorgehalten:

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

Restore-Tests. Eine Restore-Übung läuft jeden Monat automatisch über einen CI-Workflow sowie bei Bedarf und stellt den jüngsten Dump in einer Wegwerf-Umgebung wieder her. Sie entschlüsselt den Dump, stellt ihn wieder her, vergleicht jede Tabelle mit der laufenden Produktion und startet anschließend die Anwendung gegen die wiederhergestellte Datenbank, um zu bestätigen, dass sich eine verschlüsselte Spalte weiterhin entschlüsseln lässt, dass sich ein verschlüsselter Dateianhang mit dem im wiederhergestellten Dump enthaltenen Schlüssel öffnen lässt und dass jeder Anhang, der älter als eine Stunde ist, eine Kopie am Backup-Standort hat, wobei eine Kopie geöffnet und mit ihrer Prüfsumme abgeglichen wird — Zeilenzahlen allein können ein nutzbares Backup nicht von Chiffretext unterscheiden, dessen Schlüssel nicht mehr passt. Die Aktualität der Backups wird laufend überwacht (Alarm, wenn der jüngste Dump älter als 36 Stunden ist).

Verschlüsselung. Nach Angaben von Hetzner verschlüsselt Object Storage Objekte standardmäßig nicht im Ruhezustand, daher werden Datenbank-Dumps verschlüsselt, bevor sie den Host verlassen: GnuPG symmetrisch AES-256, wobei die Passphrase nur dem Backup-Prozess bekannt und außerhalb der Maschine hinterlegt ist. Anwendungsseitig mit Rails Active Record Encryption verschlüsselte Felder bleiben in jedem Dump gesondert verschlüsselt. Dateianhänge sind im Ruhezustand mit dateiindividuellen Schlüsseln verschlüsselt (siehe Dateianhänge). Diese Schlüssel liegen nur in der Datenbank, daher enthält jeder verschlüsselte Dump sie. Die Dateien selbst werden nicht in den Dump kopiert. Jede Datei liegt in Nürnberg und wird unter demselben Schlüssel in einen zweiten Bucket in Falkenstein kopiert; beide bewahren frühere Versionen 28 Tage lang auf.

Operativer Review #

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. 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,
4. keine Denial-of-Service-Angriffe oder automatisierten Massenscans durchzuführen, kein Social Engineering gegen unsere Mitarbeitenden zu versuchen und keine Meldungen über den Meldekanal eines Kunden abzugeben.

Wir bestätigen Ihre Meldung innerhalb von 2 Werktagen und arbeiten an einer zeitnahen Behebung bestätigter Lücken.

Kein bezahltes Bug-Bounty-Programm. Offenlegungen werden nicht vergütet: Wir zahlen nicht für Schwachstellenmeldungen, und als Voraussetzung für die Entgegennahme einer Meldung unterzeichnen wir weder Geheimhaltungsvereinbarungen noch vereinbaren wir kommerzielle Bedingungen oder führen Telefonate. Senden Sie das betroffene System, die Reproduktionsschritte und die von Ihnen festgestellte Auswirkung an die oben genannte Adresse.

Zuletzt aktualisiert: 8. November 2026