Warum ein Passwort schützen, wenn man darauf verzichten kann?

Ein Problem, das wir als normal hinzunehmen gelernt haben

Praktisch jede Webanwendung hat einen Administrationsbereich. Und ein Administrationsbereich hat in der Regel eine Anmeldeseite, ein Authentifizierungsformular, einen Benutzernamen und ein Passwort.

Wir haben uns so sehr an diese Konstruktion gewöhnt, dass wir uns kaum noch fragen: Muss das wirklich alles genau so funktionieren?

Wenn man nur eine Website hat, scheint das Problem nicht besonders relevant zu sein. Man erstellt ein sicheres Passwort, aktiviert die Zwei-Faktor-Authentifizierung, richtet eine Begrenzung der Anmeldeversuche ein – und arbeitet weiter.

Aber was passiert, wenn es zehn, zwanzig oder dreißig Projekte werden?

In meinem Fall geht es um das DigiMeld-Ökosystem, das mehr als dreißig eigenständige Softwareprojekte umfasst. Jedes hat seine eigene Architektur, Serverlogik und Verwaltungsoberfläche.

Entsprechend benötigt jedes einen Mechanismus für den administrativen Zugriff.

Lange Zeit habe ich einen durchaus üblichen Ansatz verwendet: separate administrative Zugangsdaten, sichere Passwörter und deren Speicherung im Browser.

Das funktionierte.

Doch irgendwann fragte ich mich: Warum muss ich überhaupt so viele administrative Passwörter speichern? Warum muss ich nicht nur die Server schützen, sondern auch die Mittel, mit denen ich Zugang zu ihnen erhalte?

Und lässt sich auf diese Notwendigkeit nicht verzichten?

Ich kam auf einen Gedanken, der später zur Grundlage meiner Lösung wurde:

Vielleicht sollte man nicht den permanenten Zugang schützen, sondern das Recht, vorübergehend Zugriff zu erhalten.

Was wäre, wenn es gar keine gewohnte Anmeldeseite gäbe?

Ich beschloss, in meinen Projekten auf das traditionelle Modell der administrativen Authentifizierung zu verzichten.

Nicht einfach das Anmeldeformular zu verstecken.

Nicht die Adresse umzubenennen.

Nicht das Passwort durch ein noch komplizierteres zu ersetzen.

Sondern auf die Notwendigkeit eines dauerhaft bestehenden passwortbasierten Zugangs zu verzichten.

Natürlich sind die Verwaltungsoberflächen dadurch nicht verschwunden. Sie werden weiterhin benötigt, um die Anwendungen zu verwalten.

Geändert hat sich die Art, wie man Zugriff auf sie erhält.

Für die Anmeldung an den Verwaltungsoberflächen der angebundenen Projekte muss man jetzt keinen gespeicherten Benutzernamen und kein gespeichertes Passwort eingeben.

Stattdessen verwende ich mein eigenes Identitäts- und Zugriffsverwaltungssystem MeldID.

Das Prinzip ist einfach: Administrativer Zugriff wird nur dann gewährt, wenn er tatsächlich benötigt wird, und zwar einem bestimmten Benutzer für ein bestimmtes Projekt.

Allein der Besitz eines Benutzerkontos berechtigt noch nicht dazu, den Administrationsbereich zu öffnen.

Diese Berechtigung muss separat erteilt werden.

Zugriff, den es vor einer Minute noch nicht gab

Das ist wohl der interessanteste Teil des gesamten Konzepts.

Im traditionellen Modell verfügt ein Administrator dauerhaft über Anmeldedaten. Er kann sie heute, morgen oder in einem Monat verwenden, solange sie gültig bleiben.

Ich beschloss, dieses Prinzip zu ändern.

Anstelle permanenter administrativer Zugangsdaten gibt es eine zeitlich begrenzte Möglichkeit, eine Anmeldung einzuleiten.

Sie wird auf Anfrage über ein vertrauenswürdiges Mobilgerät erstellt, enthält einen kryptografisch sicheren Zufallswert und ist nur für begrenzte Zeit gültig.

Aber selbst der Besitz eines solchen temporären Links bedeutet noch nicht, dass man Zugriff erhält.

Das ist ein entscheidender Punkt.

Angenommen, jemand gelangt auf irgendeine Weise an den Link. In einem herkömmlichen System, das ausschließlich auf der Geheimhaltung der Adresse beruht, könnte ein solches Leck ein ernstes Problem darstellen.

In meinem Modell ermöglicht der Link lediglich, den Bestätigungsprozess zu starten.

Für den nächsten Schritt ist eine separate Freigabe über ein vertrauenswürdiges MeldID-Mobilgerät erforderlich.

Ohne die entsprechende Bestätigung wird keine administrative Sitzung erstellt.

Deshalb betrachte ich den temporären Link nicht als Ersatz für ein Passwort, sondern als ein Element des Verfahrens zur Zugriffsgewährung.

Zu wissen, wohin man sich wenden muss, und das Recht zu haben, sich anzumelden, sind zwei völlig verschiedene Dinge.

Das Telefon wird zum Instrument der Zugriffsverwaltung

In diesem Modell spielt das Mobilgerät eine deutlich wichtigere Rolle als ein gewöhnlicher Generator für Einmalcodes.

Es wird verwendet, um Aktionen im Zusammenhang mit administrativem Zugriff zu bestätigen.

Wenn ich den Administrationsbereich öffnen möchte, fordert das System eine Bestätigung über MeldID an.

Ich sehe die entsprechende Anfrage auf einem vertrauenswürdigen Gerät und bestätige die Aktion.

Erst nach erfolgreicher Prüfung erlaubt das System, mit der Anmeldung fortzufahren.

Dabei ist die Bestätigung an eine konkrete Aktion gebunden und nicht einfach an die Tatsache, dass das Telefon entsperrt wurde.

Die biometrische Authentifizierung auf dem Mobilgerät überprüft den Benutzer lokal, während die Serverseite die kryptografische Bestätigung des registrierten Geräts prüft.

So muss man sich nicht ausschließlich auf ein Passwort oder auf eine Meldung verlassen, laut der der Benutzer die Anmeldung angeblich bestätigt hat.

Hinzu kommt ein weiterer Vorteil: Vertrauenswürdige Geräte lassen sich verwalten.

Wenn ein Gerät nicht mehr zur Bestätigung des Zugriffs verwendet werden soll, kann ihm der Vertrauensstatus entzogen werden.

Danach kann es nicht mehr als gültiges Authentifizierungsmittel für die entsprechenden Vorgänge dienen.

Ein System – viele unabhängige Projekte

Als ich mit der Entwicklung dieses Mechanismus begann, bestand eine der wichtigsten Aufgaben darin, die Eigenständigkeit jedes Projekts zu bewahren.

Ich wollte nicht alle Verwaltungsoberflächen zu einer riesigen Anwendung zusammenführen.

Jeder DigiMeld-Dienst sollte weiterhin seine eigene Logik, seine Einstellungen, Benutzer und Daten verwalten.

Deshalb habe ich zwei Aufgaben voneinander getrennt.

MeldID ist für die Identifizierung und die Erteilung der administrativen Zugriffsberechtigung zuständig.

Das jeweilige Projekt wiederum kümmert sich um seine eigenen Verwaltungsfunktionen und prüft, ob die Berechtigungen gültig sind.

So entstand ein zentralisiertes Modell der Zugriffsverwaltung, ohne die Anwendungen selbst zentralisieren zu müssen.

Außerdem werden Berechtigungen separat erteilt.

Ein Administrator eines Projekts erhält nicht automatisch Zugriff auf die übrigen Projekte, nur weil er ein MeldID-Konto hat.

Für jeden Verwaltungsbereich lässt sich ein eigener Kreis berechtigter Benutzer festlegen.

Dabei sind die Rechte gewöhnlicher Benutzer und die administrativen Berechtigungen voneinander getrennt.

Für ein Ökosystem mit Dutzenden Diensten erwies sich das als besonders praktisch.

Warum mir temporärer Zugriff besser gefällt als permanenter

Es gibt noch ein weiteres Prinzip, das ich bewusst in das System aufgenommen habe.

Administrativer Zugriff sollte nicht unbegrenzt bestehen bleiben.

Die Berechtigung gilt nur für eine begrenzte Zeit und endet unabhängig davon, ob der Benutzer im Browser weiterarbeitet.

Um nach Ablauf der Gültigkeitsdauer weiterzuarbeiten, ist ein neuer Bestätigungsprozess erforderlich.

So wird verhindert, dass eine einmal abgeschlossene Authentifizierung zu einer dauerhaft gültigen Berechtigung wird.

Eine zeitliche Begrenzung allein reicht jedoch nicht aus.

Wichtig ist auch die Möglichkeit, einen bereits gewährten Zugriff vorzeitig zu beenden.

Deshalb bietet MeldID eine zentrale Funktion zum Widerruf administrativer Berechtigungen.

Wird eine Berechtigung widerrufen, erhalten die angebundenen Projekte ein entsprechendes Ereignis und machen die zugehörigen administrativen Sitzungen ungültig.

Die Zugriffsverwaltung endet also nicht in dem Moment, in dem sich ein Benutzer erfolgreich angemeldet hat.

Die Möglichkeit, Berechtigungen zu widerrufen, ist für mich genauso wichtig wie die Möglichkeit, sie zu erteilen.

Ein verteiltes System muss dabei Verzögerungen bei der Übermittlung von Ereignissen, die vorübergehende Nichterreichbarkeit einzelner Komponenten und andere betriebliche Umstände berücksichtigen. Die begrenzte Gültigkeitsdauer der Sitzungen bildet eine zusätzliche Grenze.

Was hat sich im Arbeitsalltag geändert?

Vor allem ist es nicht mehr nötig, ständig auf gespeicherte administrative Passwörter zurückzugreifen.

Ich muss keine Sammlung von Zugangsdaten im Browser behalten, um mich an jedem angebundenen Administrationsbereich anzumelden.

Stattdessen verwalte ich Berechtigungen über einen einheitlichen Mechanismus.

Ich wähle das benötigte Projekt aus, bestätige den Zugriff und arbeite.

Wenn der administrative Zugriff nicht mehr benötigt wird, kann er widerrufen werden.

Besonders praktisch ist, dass bei einem neuen Projekt nicht das gesamte System für die administrative Authentifizierung erneut entworfen werden muss.

Es reicht, das Projekt an das bestehende Modell anzubinden und die erforderlichen Berechtigungen festzulegen.

Das bedeutet natürlich nicht, dass sämtliche Sicherheitsrisiken verschwunden sind.

Auch temporäre Berechtigungen, vertrauenswürdige Geräte, Serversitzungen und die zentrale Infrastruktur müssen geschützt werden.

Aber ich muss nicht mehr für jede Anwendung separat dasselbe Problem der Verwaltung administrativer Passwörter lösen.

Und genau das war eines meiner ursprünglichen Ziele.

Gibt es solche Technologien nicht längst?

Doch, natürlich.

Passwortlose Authentifizierung, Verwaltung privilegierter Zugriffe, temporäre Berechtigungen und Bestätigungen über vertrauenswürdige Geräte sind in der Informationssicherheitsbranche seit Langem bekannt.

Solche Ansätze finden sich in Identity-and-Access-Management- und Privileged-Access-Management-Systemen sowie in Zero-Trust-Konzepten.

Ich erhebe nicht den Anspruch, diese Prinzipien erfunden zu haben.

Meine Aufgabe war eine andere.

Ich musste ein eigenes integriertes System entwickeln, das konkrete Probleme der DigiMeld-Infrastruktur löst und die Verwaltung des administrativen Zugriffs auf zahlreiche eigenständige Projekte ermöglicht.

Am Ende habe ich mehrere bekannte Ansätze in einer Architektur zusammengeführt, die meinen Anforderungen entspricht.

Und ich bin der Ansicht, dass der Wert von Ingenieursarbeit nicht zwangsläufig darin liegt, eine völlig neue Technologie zu erfinden.

Manchmal besteht er darin, das Problem richtig zu formulieren und eine passende Lösung dafür zu finden.

MeldID ist nicht nur für Administrationsbereiche gedacht

Hier ist eine gesonderte Klarstellung angebracht.

MeldID wurde nicht ausschließlich als Werkzeug für meinen eigenen administrativen Zugriff entwickelt.

Entwicklern steht außerdem ein SDK zur Verfügung, mit dem sie Identifizierungs- und Anmeldebestätigungsmechanismen in ihre eigenen Anwendungen integrieren können.

Dieses SDK ist kostenlos verfügbar.

Ein Drittentwickler kann MeldID beispielsweise als zusätzliche Bestätigungsebene für die Benutzerauthentifizierung einsetzen.

Auch wenn die Anwendung weiterhin eine herkömmliche Anmeldung mit Benutzername und Passwort verwendet, muss die erfolgreiche Eingabe dieser Daten nicht ausreichen, um die Authentifizierung abzuschließen.

Der Benutzer erhält eine Anfrage auf sein vertrauenswürdiges Mobilgerät und kann dort den Anmeldeversuch bestätigen oder ablehnen.

So lässt sich das Risiko eines unbefugten Zugriffs verringern, falls Zugangsdaten kompromittiert werden.

Wichtig ist, diese allgemein zugängliche Funktion von MeldID von dem Modell für den administrativen Zugriff auf DigiMeld-Projekte zu unterscheiden, das ich entwickelt habe.

Beide nutzen gemeinsame Prinzipien des Vertrauens und der Bestätigung von Aktionen, lösen aber unterschiedliche Aufgaben.

Sicherheit bedeutet nicht nur, Bestehendes zu schützen

Die Arbeit an diesem System hat mich dazu gebracht, die gewohnten Authentifizierungsmechanismen anders zu betrachten.

Oft versuchen wir, etwas zu schützen, das aus historischen Gründen existiert.

Wir fügen neue Prüfungen, Einschränkungen, zusätzliche Passwörter und Schutzschichten hinzu.

Manchmal ist das tatsächlich notwendig.

Doch manchmal ist es hilfreicher, eine andere Frage zu stellen:

Muss der zu schützende Mechanismus überhaupt in seiner bisherigen Form bestehen bleiben?

In meinem Fall lautete die Antwort: nein.

Ich brauchte kein dauerhaft verfügbares Formular zur administrativen Anmeldung.

Ich brauchte die Möglichkeit, genau dann sicher administrative Berechtigungen zu erhalten, wenn sie benötigt werden.

Das sind zwei verschiedene Aufgaben.

Der Wechsel von der ersten zur zweiten hat nicht nur die technische Architektur, sondern auch die tägliche Arbeit mit den Projekten verändert.

Kein endgültiger Abschluss, sondern eine gewählte Richtung

Heute ist diese Architektur bereits in einem großen Teil des DigiMeld-Ökosystems im Einsatz.

Die übrigen Projekte werden nach und nach auf das neue Modell des administrativen Zugriffs umgestellt.

Ich führe die Migration schrittweise durch und prüfe dabei jedes einzelne Projekt. Nach Abschluss der Umstellung plane ich ein zusätzliches Audit des gesamten Systems.

Einzelne Elemente der Benutzeroberfläche und Regeln für die Verwaltung von Sitzungen können sich noch ändern.

Die Grundidee steht jedoch bereits fest.

Ich möchte nicht zu einem Modell zurückkehren, in dem ich für die Verwaltung Dutzender eigener Projekte ständig Dutzende administrative Passwörter speichern und verwenden muss.

Gleichzeitig halte ich meine eigene Implementierung nicht für eine Universallösung für alle.

Verschiedene Organisationen haben unterschiedliche Anforderungen, Infrastrukturen, Bedrohungsmodelle und Verwaltungsansätze.

Was für das DigiMeld-Ökosystem praktisch und sinnvoll ist, muss für andere Entwickler nicht unbedingt optimal sein.

Das Prinzip der zeitlich begrenzten Erteilung von Berechtigungen verdient jedoch Beachtung.

Zum Schluss

Ich habe beschlossen, diese Erfahrung zu teilen, nicht weil ich mich für den Erfinder einer neuen Authentifizierungsmethode halte.

Und auch nicht, weil ich ein weiteres System als absolut sicher darstellen möchte.

Absolute Sicherheit gibt es nicht.

Mich interessiert einfach die Fragestellung selbst.

Anstatt den permanenten administrativen Zugang endlos zu schützen, kann man hinterfragen, ob er überhaupt dauerhaft bestehen muss.

Anstelle vieler gespeicherter Passwörter lassen sich temporäre Berechtigungen verwenden.

Anstelle automatischen Vertrauens nach der ersten Authentifizierung kann man die Erteilung konkreter Berechtigungen bestätigen lassen.

Anstatt auf den Ablauf einer Sitzung zu warten, kann man die Möglichkeit vorsehen, den Zugriff zentral zu widerrufen.

Und schließlich lässt sich anstelle eines separaten Anmeldemechanismus für jedes Projekt ein einheitliches System zur Verwaltung administrativer Zugriffsrechte aufbauen, ohne die Eigenständigkeit der Anwendungen aufzugeben.

Ich behaupte nicht, dass dieser Ansatz eine Kompromittierung unmöglich macht.

Er verlagert den Schwerpunkt lediglich vom Schutz dauerhaft bestehender Zugangsdaten auf die kontrollierte Erteilung und Beendigung von Berechtigungen.

Vielleicht besteht der wirksamste Weg, die Angriffsfläche zu verkleinern, manchmal nicht darin, einen weiteren Schutzmechanismus hinzuzufügen, sondern auf etwas zu verzichten, ohne das das System problemlos funktionieren kann.

Mit diesem Gedanken begann für mich die Geschichte des MeldID Admin Gateway.