Von der Mandantentrennung über die Verschlüsselung bis zur biometrischen Authentifizierung — hier steht, was technisch tatsächlich passiert, ohne Marketingvokabular.
Jeder Mandant (Tenant) operiert in einer vollständig isolierten Umgebung. Die Datenbank-Architektur trennt Mandanten auf Schema-Ebene, sodass kein Datenbestand in einen anderen Mandanten hineinreicht. Ergänzend sorgen Row-Level-Security-Policies auf PostgreSQL-Ebene für eine zusätzliche, unabhängige Isolationsschicht. Selbst bei einem Softwarefehler ist ein unbefugter Zugriff auf fremde Mandantendaten ausgeschlossen.
PostgreSQL Row-Level Security (RLS) bildet das Rückgrat unserer Zugriffskontrolle. Jede Datenbankabfrage wird automatisch um eine tenant_id-Bedingung ergänzt, die aus dem authentifizierten JWT-Token des Benutzers extrahiert wird. RLS-Policies sind für alle Tabellen aktiviert und werden durch PostgreSQL erzwungen – unabhängig davon, ob der Zugriff über die API, Edge Functions oder direkt erfolgt. Dies verhindert Datenlecks selbst bei fehlerhaften Abfragen.
Sämtliche Aktionen auf der Plattform werden lückenlos protokolliert. Jeder Audit-Log-Eintrag enthält einen eindeutigen Zeitstempel (ISO 8601), die ausführende Benutzer-ID, die IP-Adresse, die durchgeführte Aktion sowie die betroffene Ressource. Die Audit-Logs sind unveränderbar gespeichert und können von Administratoren jederzeit eingesehen werden. So behalten Sie stets die vollständige Kontrolle über alle Vorgänge in Ihrem Tenant.
Alle Datenübertragungen erfolgen ausschließlich über TLS 1.3 (Transport Layer Security). Die ruhenden Daten werden mit AES-256-Verschlüsselung auf Datenbankebene geschützt. Regelmäßige automatisierte Backups werden ebenfalls vollständig verschlüsselt in einem geografisch getrennten Speicherort abgelegt. Die Schlüsselverwaltung erfolgt durch Supabase auf Basis von AWS KMS – ohne dass wir als Betreiber jemals Zugriff auf die Rohschlüssel haben.
Das biometrische Gesichtserkennungssystem speichert ausschließlich gehashte Face Embeddings – keine Rohbilder, keine Fotos. Die Extraktion der biometrischen Merkmale erfolgt lokal im Browser des Benutzers. An den Server wird ausschließlich der unidirektionale Hash des Embeddings übertragen. Eine Rekonstruktion des ursprünglichen Gesichtsbildes ist technisch unmöglich. Die biometrischen Hashes können zudem jederzeit durch den Mandanten gelöscht werden.
Authentifizierungs- und Sitzungstokens werden ausschließlich in HTTP-Only, Secure und SameSite=Lax Cookies gespeichert. Dadurch sind sie für clientseitiges JavaScript (z. B. bei XSS-Angriffen) nicht zugänglich. Die Tokens haben eine kurze Lebensdauer und werden regelmäßig rotiert. Refresh-Tokens werden sicher in der Datenbank verwaltet und sind nur über die serverseitige API austauschbar. CSRF-Schutz wird über SameSite-Cookies und zusätzliche Header-Prüfungen realisiert.
APOHR Portal wird auf der Supabase-Plattform betrieben, die SOC 2 (Type II) zertifiziert ist. Die Infrastruktur läuft auf AWS – unsere Rechenzentren befinden sich ausschließlich in Deutschland (Frankfurt, eu-central-1). Dadurch unterliegen alle Daten dem strengen europäischen Datenschutzrecht. Die Plattform ist hochverfügbar ausgelegt (99,9 % Uptime SLA) und skaliert automatisch mit der Anzahl der aktiven Nutzer und Mandanten.
APOHR Portal ist DSGVO-konform und erfüllt alle Anforderungen der europäischen Datenschutz-Grundverordnung. Wir befinden uns im Zertifizierungsprozess für ISO 27001 (Informationssicherheitsmanagement). Darüber hinaus führen wir regelmäßige interne und externe Penetrationstests durch, um die Sicherheit unserer Plattform kontinuierlich zu überprüfen und zu verbessern. Auf Anfrage stellen wir Ihnen gerne unseren aktuellen Sicherheitsbericht zur Verfügung.
