Sicherheit bei DrillyHub

Ihre Daten sind bei uns in guten Händen.

Bei DrillyHub verwalten Sie sensible Informationen: Namen, E-Mail-Adressen und Schulungsnachweise Ihrer Mitarbeitenden. Weil das personenbezogene Daten sind, nehmen wir Sicherheit nicht als Feature, sondern als Grundvoraussetzung unserer Plattform.

Was das für Sie konkret bedeutet.

Die wichtigsten Schutzmaßnahmen einfach erklärt – ohne Fachsprache.

◫

Ihre Daten bleiben Ihre Daten.

Jedes Unternehmen, das DrillyHub nutzt, arbeitet in einem strikt abgetrennten Bereich. Diese Trennung ist nicht nur in der Anwendung vorgesehen, sondern zusätzlich direkt in der Datenbank verankert.

•••

Passwörter sehen wir nie.

Ihr Passwort wird nicht im Klartext gespeichert. Stattdessen wird daraus ein nicht umkehrbarer Prüfwert erzeugt. Auch wir als Betreiber können Ihr Passwort deshalb nicht auslesen.

↻

Neue Zugänge sind von Anfang an geschützt.

Neue Nutzer müssen beim ersten Login ein eigenes, sicheres Passwort vergeben. Die Passwortanforderungen werden dabei direkt geprüft und verständlich angezeigt.

✓

Jeder sieht nur, was ihn etwas angeht.

Betreiber, Mandant-Administratoren, Firmenverantwortliche und Teilnehmer besitzen unterschiedliche Rechte. Firmenverantwortliche sehen ausschließlich Daten der eigenen Firma. Diese Berechtigungen werden bei jeder einzelnen Anfrage an unsere Server erneut geprüft.

🔒

Übertragung nur verschlüsselt.

Alle Daten zwischen Ihrem Browser und unseren Servern werden ausschließlich verschlüsselt über HTTPS übertragen.

−

Wir erheben nur, was nötig ist.

DrillyHub sammelt bewusst keine überflüssigen persönlichen Daten – nur das, was für Schulungsverwaltung und Nachweise tatsächlich benötigt wird.

Sie möchten es technisch genauer wissen?
Der folgende Abschnitt richtet sich an IT-Verantwortliche und beschreibt die wichtigsten Schutzmaßnahmen auf technischer Ebene.

Technische Details

Für IT-Verantwortliche, Datenschutzbeauftragte und alle, die genauer hinschauen möchten.

Technische Sicherheitsmaßnahmen anzeigen

Mandantentrennung auf Datenbankebene (Row-Level Security)

Die Isolation zwischen Mandanten wird nicht ausschließlich in der Anwendungslogik durchgesetzt, sondern zusätzlich über PostgreSQL Row-Level-Security-Policies direkt in der Datenbank. Jede Anfrage setzt zu Beginn einer Transaktion tenant_id und Rolle als Session-Parameter; die Datenbank selbst lässt nur Zeilen des passenden Mandanten zu. Ein Fehler in der Anwendungsschicht kann diese Grenze dadurch nicht unterlaufen.

Least-Privilege-Datenbankzugriff

Die Anwendung verbindet sich bewusst nicht mit einem privilegierten Datenbank-Account, sondern mit einer eigens dafür angelegten, eingeschränkten Rolle ohne Superuser-Rechte — denn Superuser-Rollen umgehen Row-Level-Security grundsätzlich, unabhängig von den definierten Policies.

Passwort-Hashing

Passwörter werden ausschließlich als bcrypt-Hash mit Kostenfaktor 12 gespeichert, niemals im Klartext oder umkehrbar verschlüsselt.

Erzwungene Passwortrichtlinie

Mindestlänge 12 Zeichen, Groß-/Kleinschreibung, Ziffer und Sonderzeichen erforderlich, Abgleich gegen eine Liste gängiger Passwörter sowie Ausschluss von Namens-/E-Mail-Bestandteilen. Die Prüfung erfolgt serverseitig als Autorität; die client-seitige Live-Anzeige ist lediglich Komfortfunktion.

Erzwungener Passwortwechsel

Von einem Administrator vergebene Initialpasswörter erzwingen beim ersten Login einen Wechsel — technisch durchgesetzt über einen Guard, der sämtliche anderen API-Routen sperrt, bis das eigene Passwort gesetzt wurde. Ein Umgehen über direkte API-Aufrufe ist damit ausgeschlossen.

Zustandslose Authentifizierung (JWT)

Nach erfolgreichem Login erhält der Client ein signiertes JWT mit Rolle und Mandantenzuordnung als Claims. Jede Anfrage wird serverseitig gegen die Signatur verifiziert; es gibt keinen client-seitig vertrauten Zustand.

Rollenbasierte Zugriffskontrolle (RBAC)

Vier streng getrennte Rollen (Betreiber, Mandant-Admin, Firmenverantwortlicher, Teilnehmer) mit serverseitig auf jedem einzelnen Endpunkt geprüften Berechtigungen — nicht nur durch Ausblenden von UI-Elementen.

Serverseitige Auswertungslogik

Sicherheitsrelevante Logik, z. B. die Auswertung von Quiz-Antworten, läuft ausschließlich serverseitig; der Client erhält niemals vorab Informationen, die zur Manipulation genutzt werden könnten.

Datensparsamkeit in API-Antworten

Sensible Felder wie Passwort-Hashes werden über einen globalen Serializer explizit aus jeder API-Antwort ausgeschlossen — unabhängig davon, an welcher Stelle im Code ein Objekt zurückgegeben wird.

Validierte Datei-Uploads

Hochgeladene Dateien, z. B. Logos, werden serverseitig gegen eine Positivliste zulässiger MIME-Types sowie eine Maximalgröße geprüft, bevor sie gespeichert werden.

Transportverschlüsselung & Zertifikatsmanagement

Produktivbetrieb ausschließlich über TLS/HTTPS, mit automatisierter Zertifikatsausstellung und -erneuerung (Let's Encrypt) über einen vorgeschalteten Reverse Proxy.

Trennung von Konfiguration und Code

Zugangsdaten und Secrets liegen ausschließlich in umgebungsspezifischen, nicht versionierten Konfigurationsdateien — niemals im Quellcode oder in der Versionsverwaltung.

Weitere technische Fragen?

Wir erläutern unsere Sicherheitsarchitektur bei Bedarf auch direkt im Rahmen einer Demo oder IT-Abstimmung.

Kontakt aufnehmen