Identität als Fundament: Auth0 und der Schutz von Gesundheitsdaten

Foto: EU2017EE Estonian Presidency · Wikimedia Commons (BY 2.0), via Openverse

Bevor man auch nur eine einzige Blutzuckermessung oder einen Schrittzähler-Wert speichert, muss man eine unbequeme Frage beantworten: Wer darf diese Daten eigentlich sehen? Bei einer normalen App ist das eine Fleißaufgabe. Bei einer Gesundheitsplattform ist es die Frage, an der alles hängt. Wenn die Identität nicht wasserdicht ist, ist der Rest egal.

Deshalb ist die erste Schicht, die wir bei Xircuit gebaut haben, keine schöne Oberfläche und kein cleveres Feature, sondern das Fundament darunter — die Identität. Diese Woche beschreibe ich, warum wir sie so ernst nehmen wie kaum etwas anderes im System und welche Entscheidungen daraus folgen.

Warum Gesundheitsdaten anders sind

Die DSGVO kennt eine Handvoll Datenarten, die sie gesondert behandelt. Gesundheitsdaten gehören dazu: Sie sind nach Artikel 9 eine besondere Kategorie personenbezogener Daten, zusammen mit Dingen wie ethnischer Herkunft oder religiöser Überzeugung. Der Gesetzgeber hat sie bewusst herausgehoben, weil ein Missbrauch hier nicht rückgängig zu machen ist. Ein geleaktes Passwort kann man ändern. Die Information, dass jemand eine chronische Erkrankung hat, bekommt man nicht wieder aus der Welt.

Für uns bedeutet das eine klare Reihenfolge: Der Schutz dieser Daten beginnt nicht bei der Datenbank und nicht bei der Verschlüsselung, sondern bei der Identität. Wenn ich nicht mit hoher Sicherheit sagen kann, wer da gerade eingeloggt ist, nützt mir die beste Verschlüsselung im Ruhezustand wenig. Die ganze Kette hängt am ersten Glied, und das erste Glied ist die Anmeldung.

Diese Sichtweise hat unsere Architekturentscheidungen von Anfang an geprägt. Identität ist bei uns kein Modul unter vielen, sondern die Ebene, auf der alles andere aufsetzt.

Warum wir Passwörter nicht selbst speichern

Die vielleicht wichtigste Entscheidung war, die Identität nicht selbst zu bauen. Es ist verlockend, eine eigene Nutzertabelle mit gehashten Passwörtern anzulegen — es sieht nach wenig Aufwand aus. In Wahrheit übernimmt man damit eine Verantwortung, die man kaum tragen kann: Passwort-Hashing nach aktuellem Stand, Brute-Force-Schutz, Wiederherstellungsflüsse, die nicht selbst zum Einfallstor werden, und die laufende Pflege gegen neue Angriffsmuster.

Wir haben uns stattdessen für Auth0 entschieden, ein Unternehmen von Okta. Auth0 übernimmt Login, Mehr-Faktor-Authentifizierung, Social Login und die Konto-Wiederherstellung. Der entscheidende Punkt dabei: Xircuit speichert selbst nie ein Passwort. Es gibt in unserer Datenbank keine Spalte, in der ein Passwort-Hash stünde. Damit können wir eine ganze Klasse von Vorfällen gar nicht erst erleiden — man kann nicht verlieren, was man nie besitzt.

Die Mehr-Faktor-Authentifizierung ist dabei kein optionales Extra, das man irgendwo tief in den Einstellungen findet. Für eine Plattform mit Gesundheitsbezug ist ein zweiter Faktor die naheliegende Grundlinie, und Auth0 gibt sie uns ohne dass wir die dazugehörige Kryptografie selbst betreuen müssen.

Rollen und Organisationen zusammenführen

Auth0 weiß, wer jemand ist. Es weiß aber nicht, was diese Person in Xircuit tun darf — und das ist bewusst so. Die Berechtigungslogik gehört zur Anwendung, nicht zum Identitätsanbieter. Also führen wir zwei Welten zusammen: die Identität aus Auth0 und die Rollen- und Organisationsstruktur aus unserer eigenen Datenbank.

Ein Detail, das dabei früh wichtig wurde: Ein Nutzer ist bei uns nicht an genau eine Organisation gebunden. Dieselbe Person kann in mehreren Organisationen Mitglied sein — etwa als Patientin in der einen und als Betreuerin in einer anderen. Die Identität bleibt dieselbe, die Rolle hängt am Kontext. Beim Login etablieren wir also nicht nur, wer jemand ist, sondern in welcher Organisation er gerade handelt und mit welchen Rechten.

Foto: Sanskritibharti1398 · Wikimedia Commons (BY-SA 4.0), via Openverse

Technisch heißt das, dass die stabile Kennung aus Auth0 als Anker dient, an den wir unsere eigenen Mitgliedschafts- und Rollendatensätze hängen. Auth0 bleibt die Quelle der Wahrheit für „wer", unsere Datenbank die Quelle der Wahrheit für „darf was, und wo". Diese Trennung klingt nach einer Kleinigkeit, aber sie hält die Zuständigkeiten sauber: Ändert sich eine Rolle, fassen wir Auth0 nicht an; ändert jemand sein Passwort, fassen wir unsere Datenbank nicht an.

Testbarkeit ohne Hintertüren

Ein Identitätssystem, das man nicht automatisiert testen kann, ist ein Risiko für sich — denn dann testet man es entweder gar nicht oder von Hand, und beides führt irgendwann zu Fehlern. Gleichzeitig ist gerade die Authentifizierung der Ort, an dem eine bequeme Testabkürzung zur gefährlichsten Hintertür des ganzen Systems werden kann.

Wir lösen das mit einem klar abgegrenzten Testclient nach dem ROPC-Verfahren, mit dem die End-to-End-Tests einen echten Anmeldevorgang durchlaufen können, ohne die Oberfläche fernzusteuern. Das gibt uns verlässliche Tests über den kompletten Auth-Pfad. Der wichtige Teil ist aber die Grenze: Diese Test-Authentifizierung und jede Art von Produktions-Hintertür sind in der Produktion hart abgeschaltet. Der Testpfad existiert nur dort, wo er existieren soll, und ist im Live-Betrieb schlicht nicht vorhanden — nicht per Konfiguration deaktiviert, die jemand versehentlich umlegt, sondern grundsätzlich nicht erreichbar.

Diese Unterscheidung zwischen „aus" und „nicht vorhanden" nehmen wir bei sicherheitsrelevanten Pfaden bewusst ernst. Ein Schalter, den man umlegen kann, wird irgendwann umgelegt.

Diagnose, ohne PII zu verraten

Anmeldeprobleme sind eine der häufigsten Supportanfragen überhaupt, und sie sind notorisch schwer nachzuvollziehen, weil sie über mehrere Systeme laufen — Browser, Auth0, unsere API, unsere Datenbank. Wer schon einmal ein „ich komme nicht rein" ohne brauchbare Logs debuggen musste, weiß, wie frustrierend das ist.

Deshalb protokollieren wir an jeder Auth-Grenze bewusst, was passiert: an welchem Schritt jemand ankommt, was der Übergang zurückgibt, wo eine Anmeldung abbricht. Dieses Boundary-Logging macht Anmeldeprobleme diagnostizierbar, statt sie zum Ratespiel zu machen. Die entscheidende Regel dabei ist eine Verbotszone: Es wird nie ein Passwort geloggt und nie personenbezogene Daten. Wir protokollieren den Fluss, nicht den Inhalt. Man sieht, dass ein Faktor fehlschlug, aber nicht, welcher Wert eingegeben wurde; man sieht, dass eine Organisation nicht aufgelöst werden konnte, aber keine Klarnamen.

Das ist eine Gratwanderung, und wir behandeln sie als solche. Zu wenig Logging, und man ist im Ernstfall blind. Zu viel, und die Logs selbst werden zu dem Datenleck, das man eigentlich verhindern wollte. Die Linie verläuft für uns genau dort, wo aus Diagnose ein Rückschluss auf eine konkrete Person würde.

Was das Fundament trägt

Wenn ich diese Woche auf einen Punkt bringen müsste: Identität ist bei Xircuit kein Feature, sondern die Voraussetzung für alle Features. Auth0 nimmt uns die riskanteste Kryptografie ab, die Trennung zwischen Identität und Rollen hält die Zuständigkeiten sauber, der Testpfad existiert ohne Produktionsrisiko, und das Boundary-Logging macht das Ganze wartbar, ohne die Daten zu gefährden, die wir schützen wollen.

Nichts davon ist besonders spektakulär, und genau das ist der Punkt. Ein gutes Fundament fällt nicht auf. Es trägt einfach.

Was kommt als Nächstes?

Nächste Woche: wie eine einzige Plattform sieben Branchen mandantenfähig bedient — Organisationen, Rollen und Mitgliederverwaltung.