(Vertrauen)
Sicherheit bei Verne Software
Verne Software läuft auf Servern von OVHcloud in einem französischen Rechenzentrum. Damit ist die Plattform in der EU gehostet. Das Unternehmen selbst ist in Serbien registriert, außerhalb der EU und des EWR; unser eigener Zugriff auf die Daten ist daher eine Übermittlung in ein Drittland. /gdpr und /dpa erklären, wie diese Übermittlung abgedeckt ist.
Diese Seite führt auf, was am 5. November 2026 umgesetzt ist. Jede Maßnahme hier steht auch in Anhang II des Auftragsverarbeitungsvertrags (AVV), der die Fassung ist, die uns bindet. Steht eine Maßnahme nicht in der Liste, gehen Sie nicht davon aus, dass es sie gibt.
Wo es läuft
- Server: OVHcloud, ein Rechenzentrum in Frankreich.
- Backups: OVHcloud Object Storage, Region Paris, an einem anderen Standort als die Server.
- Ausgehende E-Mails (Anmeldecodes, Wiederherstellungslinks, Löschwarnungen): Scaleway Transactional Email, Paris.
- Jedes Unternehmen, das Kundendaten berührt, steht auf /subprocessors, mit Standort und Garantie für jedes.
Was umgesetzt ist
| Thema | Was wir tun |
|---|---|
| Verschlüsselung bei der Übertragung | Die Websites und die API werden über TLS mit Zertifikaten von Let's Encrypt ausgeliefert, verwaltet vom Reverse-Proxy. Einfaches HTTP wird auf HTTPS umgeleitet, und Browser werden angewiesen, ausschließlich HTTPS zu verwenden (HSTS, ein Jahr). |
| Netzwerkexposition | Web- und API-Verkehr erreicht die Plattform über einen einzigen Reverse-Proxy. Außer ihm sind nur die Ports unseres eigenen Mailservers aus dem Internet erreichbar. Datenbanken, der Cache und interne Dienste liegen in internen Container-Netzwerken, und ihre Ports sind nicht veröffentlicht. |
| Gateway | Jede API-Anfrage passiert ein einziges Edge-Gateway. Es prüft den API-Schlüssel und das Ratenlimit, bevor die Anfrage einen Dienst erreicht. Ein Schlüssel trägt eine Menge von Scopes (Relay, Gate, Clockwork, Passepartout); ein Schlüssel ohne den nötigen Scope wird mit 403 abgelehnt. |
| Angriffsfilterung | Anfragen werden am Edge ratenbegrenzt und von CrowdSec gefiltert, das Adressen blockiert, die mit Angriffen in Verbindung gebracht werden. Ist CrowdSec selbst nicht erreichbar, wird der Verkehr durchgelassen: Wir haben uns entschieden, unsere eigenen Kunden bei einem Neustart nicht zu blockieren. |
| Kundentrennung | Jede Endnutzer-Identität ist an den Kunden gebunden, dem sie gehört. Der Schlüssel eines Kunden sieht nur dessen eigene Nutzer. Dieselbe E-Mail-Adresse bei zwei Kunden sind zwei verschiedene Personen, jede mit eigenem Passwort, eigenen Sitzungen und eigenen E-Mails. |
| API-Schlüssel | Erzeugt aus 32 Zufallsbytes und nur als SHA-256-Hashes gespeichert. Wir können einen Schlüssel nicht zurücklesen. |
| Passwörter | Von Ory Kratos als bcrypt-Hashes mit Kostenfaktor 12 gespeichert. Ein Hash, den ein Kunde aus einem anderen System importiert, wird in der importierten Form aufbewahrt. |
| Telegram-Bot-Tokens | Verschlüsselt mit AES-256-GCM. |
| Zweiter Faktor | Endnutzer und Dashboard-Konten können eine Authenticator-App (TOTP) und Wiederherstellungscodes einschalten. Das ist optional. |
| Logs | Der Identitätsdienst ist so eingestellt, dass er keine sensiblen Werte in seine Logs schreibt. Zugriffslogs des Reverse-Proxys, die IP-Adressen enthalten, werden täglich rotiert und höchstens 14 Tage aufbewahrt. |
| Zugriff auf Server | Die Server werden von unserem Betreiber über SSH mit Schlüsselauthentifizierung verwaltet. Deployments laufen aus einer CI-Pipeline mit eigenem Schlüssel. Der Schlüssel für die automatische Überwachung kann nur eine feste Liste von Befehlen ausführen. |
| Admin-Panel | Wird auf einem eigenen Host ausgeliefert (jules.vernesoft.com). Es erfordert eine Administrator-Identität, getrennt von Kundenkonten. |
| Aktionen von Mitarbeitern | Was unsere Mitarbeiter im Admin-Panel an einem Kundenkonto tun, wird in das Audit-Protokoll dieses Kunden geschrieben, mit dem Akteurstyp staff. |
| Änderungskontrolle | Die automatisierte Testsuite muss bestehen, bevor Images gebaut und freigegeben werden. Das Deployment übernimmt die Pipeline, nicht Handarbeit. |
Audit-Protokoll
Wichtige Aktionen werden in einem Protokoll festgehalten, das sich über den Dienst nicht ändern lässt: Die Datenbank verweigert jede Aktualisierung und jede Löschung, außer dem planmäßigen Entfernen von Einträgen nach Ablauf der Aufbewahrungsfrist und der Löschung des Kontos eines Kunden. Eine Aktion im Dashboard oder mit einem API-Schlüssel wird in derselben Datenbanktransaktion geschrieben wie die Aktion selbst, sodass keines von beiden ohne das andere gespeichert wird.
Was darin steht: erstellte und widerrufene API-Schlüssel, Projekteinstellungen, Mitglieder und Rollen, Organisationen mit ihren Rollen und Mitgliedern, Anmeldeanbieter und Sicherheitseinstellungen, Webhook-Endpunkte, Regeln zur automatischen Löschung, die Absenderdomain für E-Mails an Endnutzer, Anmeldungen und Passwortänderungen der Endnutzer, auf Wunsch des Kontoinhabers erstellte Exporte der Endnutzer sowie die Aufbewahrungseinstellung des Protokolls selbst. Jeder Eintrag enthält Kennungen, die Uhrzeit, die IP-Adresse und den User-Agent. Er enthält keine E-Mail-Adresse, keinen Namen und kein Passwort.
Zwei Grenzen, genannt, weil sie für einen Prüfer wichtig sind. Fehlgeschlagene Anmeldungen werden nicht erfasst, weil der Identitätsdienst sie nicht meldet. Anmeldungen über Telegram werden ebenfalls nicht erfasst.
Aufbewahrung: 7 Tage bei Free, 30 bei Pro, 90 bei Advanced; bei einem Vertragstarif der vereinbarte Zeitraum, oder 90 Tage, wenn der Vertrag nichts sagt. Der Kontoinhaber kann die Frist verkürzen, nicht verlängern. Einsehbar im Dashboard oder über die API: Audit-Protokoll in der Dokumentation.
Backups
Drei Datenbanken enthalten personenbezogene Daten von Kunden: Konten und Konfiguration, Identitäten und Zugangsdaten der Endnutzer sowie die Webhook-Konfiguration. Jede wird einmal täglich als Dump exportiert und auf dem Server mit einem öffentlichen Schlüssel verschlüsselt, bevor die Kopie ihn verlässt. Der private Schlüssel liegt nur bei unserem Betreiber und nicht auf dem Server. Die verschlüsselten Kopien gehen an OVHcloud Object Storage in der Region Paris, wo OVHcloud sie zusätzlich im Ruhezustand verschlüsselt.
Jede Kopie ist 30 Tage lang gegen Löschen und Überschreiben gesperrt und wird danach durch eine Ablaufregel entfernt, spätestens 35 Tage nach ihrer Erstellung. Der Zugriffsschlüssel des Servers selbst kann eine Kopie weder löschen noch überschreiben; ein Angreifer, der den Server übernimmt, kann damit also die Backups nicht löschen.
Nicht gesichert: E-Mail-Inhalte, Support-Postfächer, Nutzungsanalysen und operative Telemetrie.
Die Aktualität der Backups wird automatisch geprüft; ein Alarm geht los, wenn die letzte erfolgreiche Kopie älter als 26 Stunden ist. Eine Wiederherstellung eines Produktions-Backups wurde am 15. Oktober 2026 getestet: Die Zeilenzahlen in allen 70 Tabellen stimmten mit den Live-Datenbanken überein.
Überwachung und Status
- Eine automatisierte externe Funktionsprüfung läuft alle 3 Stunden.
- Ein Watchdog auf dem Server läuft alle 3 Minuten.
- /status zeigt 90 Tage tägliche Verfügbarkeit für sechs Komponenten (API, Dashboard, Relay, Gate, Clockwork, Passepartout) und den Verlauf der Vorfälle.
Vorfälle
Betrifft eine Verletzung des Schutzes personenbezogener Daten die Daten eines Kunden, benachrichtigen wir diesen Kunden unverzüglich, nachdem sie uns bekannt geworden ist, und zwar bei dem im AVV genannten Ansprechpartner für den Datenschutz. Die Meldung sagt, was geschehen ist, welche Kategorien betroffener Personen und ungefähr wie viele Datensätze betroffen sind, welche Folgen wahrscheinlich sind und was wir getan haben oder vorschlagen. Weitere Angaben senden wir nach, sobald wir mehr wissen. Wir nennen keine Stundenzahl: Der AVV sagt „unverzüglich“. Zum Vergleich: Ein Verantwortlicher hat ab dem Zeitpunkt, an dem ihm eine Verletzung bekannt wurde, 72 Stunden, um sie seiner Aufsichtsbehörde zu melden (Artikel 33 DSGVO).
Für Kunden ohne AVV sagt die Datenschutzerklärung dasselbe: Kunden werden unverzüglich informiert.
Schwachstelle melden
Schreiben Sie an security@vernesoft.com; dieselbe Adresse steht in /.well-known/security.txt. Beschreiben Sie, was Sie gefunden haben, wo, und wie es sich reproduzieren lässt. Bitte testen Sie nur mit Ihrem eigenen Konto und hören Sie auf, sobald Sie Daten eines anderen Kunden sehen können.
Was diese Seite nicht abdeckt
- Wir verfügen über keine Sicherheitszertifizierung.
- Der Verkehr zwischen Containern auf demselben Server ist nicht mit TLS verschlüsselt.
- Webhooks und geplante HTTP-Anfragen gehen an die Adresse, die der Kunde festlegt. Sie sind nur verschlüsselt, wenn diese Adresse mit
https://beginnt. - Anmeldeanbieter, die ein Kunde einschaltet (Telegram, Google, GitHub), unterliegen ihren eigenen Bedingungen.
Zuletzt geprüft: 5. November 2026. Fragen: support@vernesoft.com.