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.
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.
Die wichtigsten Schutzmaßnahmen einfach erklärt – ohne Fachsprache.
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.
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 Nutzer müssen beim ersten Login ein eigenes, sicheres Passwort vergeben. Die Passwortanforderungen werden dabei direkt geprüft und verständlich angezeigt.
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.
Alle Daten zwischen Ihrem Browser und unseren Servern werden ausschließlich verschlüsselt über HTTPS übertragen.
DrillyHub sammelt bewusst keine überflüssigen persönlichen Daten – nur das, was für Schulungsverwaltung und Nachweise tatsächlich benötigt wird.
Für IT-Verantwortliche, Datenschutzbeauftragte und alle, die genauer hinschauen möchten.
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.
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.
Passwörter werden ausschließlich als bcrypt-Hash mit Kostenfaktor 12 gespeichert, niemals im Klartext oder umkehrbar verschlüsselt.
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.
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.
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.
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.
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.
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.
Hochgeladene Dateien, z. B. Logos, werden serverseitig gegen eine Positivliste zulässiger MIME-Types sowie eine Maximalgröße geprüft, bevor sie gespeichert werden.
Produktivbetrieb ausschließlich über TLS/HTTPS, mit automatisierter Zertifikatsausstellung und -erneuerung (Let's Encrypt) über einen vorgeschalteten Reverse Proxy.
Zugangsdaten und Secrets liegen ausschließlich in umgebungsspezifischen, nicht versionierten Konfigurationsdateien — niemals im Quellcode oder in der Versionsverwaltung.
Wir erläutern unsere Sicherheitsarchitektur bei Bedarf auch direkt im Rahmen einer Demo oder IT-Abstimmung.