Gemeinsamer Login oder getrennte Konten? Das passende Identitätsmodell für selbst gehostete Anwendungen wählen

Mit wachsendem Stack wird die Login-Architektur zu einer Betriebsentscheidung

Eine einzelne selbst gehostete Anwendung lässt sich in der Regel mit lokalen Benutzerkonten verwalten. Betreibt ein Team jedoch mehrere Anwendungen, betrifft das Login-Design mehr als nur die Nutzerfreundlichkeit. Es beeinflusst, wer Konten erstellt, wie schnell Zugriffe entzogen werden, wo Administratoren Wiederherstellungszugriff behalten und was geschieht, wenn ein gemeinsamer Login-Dienst nicht verfügbar ist.

Ein gemeinsamer Identitätsanbieter für selbst gehostete Anwendungen kann wiederholten Aufwand bei der Kontoverwaltung reduzieren. Er kann jedoch auch zu einer kritischen Abhängigkeit werden: Wenn der Identitätsdienst, sein Verwaltungsprozess oder sein Wiederherstellungsprozess ausfällt, können Nutzer möglicherweise mehrere Dienste gleichzeitig nicht erreichen. Die richtige Wahl lautet daher nicht automatisch „alles zentralisieren“. Sie ist das Modell, das Ihr Team sicher betreiben und wiederherstellen kann.

Airbip verwaltet die Cloud-Infrastruktur rund um bereitgestellte Docker-Anwendungs-Workloads, einschließlich Routing und TLS-Zertifikatsautomatisierung, DNS-Prüfungen, Verwaltung des Service-Lebenszyklus und konfigurierbarer Backups. Diese Infrastrukturdienste bestimmen weder die Identitätsquelle, das Berechtigungsmodell, den Kontowiederherstellungsprozess noch die Zugriffssteuerung einer Anwendung. Diese bleiben Entscheidungen des Kunden und sollten für jede Anwendung einzeln getroffen werden.

• Behandeln Sie die Identitätsarchitektur als betriebliche Designentscheidung und nicht nur als Präferenz für einen Login-Bildschirm.
• Bewerten Sie die wahrscheinlichen Auswirkungen eines Ausfalls des Identitätsdienstes, bevor Sie ihn zum Zugangspunkt für jede Anwendung machen.
• Benennen Sie verantwortliche Personen für Aktivitäten im Benutzerlebenszyklus, privilegierte Zugriffe und Wiederherstellungsverfahren.
• Trennen Sie die Identitätsentscheidung von Entscheidungen zu Anwendungs-Backups, Datenaufbewahrung, Sitzungsverwaltung und Anwendungsautorisierung.

Beginnen Sie mit der Unterscheidung: Authentifizierung, Autorisierung und Rollen

Authentifizierung beantwortet die Frage: „Kann diese Person die Kontrolle über das dieser Identität zugeordnete Authentisierungsmittel nachweisen?“ NIST beschreibt erfolgreiche Authentifizierung als die Möglichkeit für einen Verifizierer, gegenüber dem aufgerufenen Dienst eine Kennung und optional Attribute zu bestätigen.

Autorisierung ist eine separate Entscheidung: „Was darf diese authentifizierte Person hier tun?“ Eine Anwendung kann bei dieser Entscheidung während der Authentifizierung erhaltene Informationen verwenden, benötigt aber dennoch eigene Logik für den Zugriff. Rollen auf Anwendungsebene drücken dann die innerhalb dieser Anwendung verfügbaren Berechtigungen aus, etwa eine Administrator-, Bearbeitungs- oder Nur-Lese-Rolle.

Diese Unterscheidung verhindert einen häufigen Designfehler. Ein zentraler Login kann anwendungsübergreifend feststellen, wer jemand ist, macht Berechtigungen aber nicht automatisch einheitlich. Dieselbe Person kann in einem System angemessenerweise Administrator sein und in einem anderen nur eingeschränkten Zugriff haben. Die jeweils aktuelle offizielle Dokumentation einer Anwendung sollte maßgeblich für ihre Rollen, ihr Gruppenverhalten und jede unterstützte Identitätsintegration sein.

• Authentifizierung: überprüft die Kontrolle der antragstellenden Person über ein Authentisierungsmittel.
• Autorisierung: bestimmt den Zugriff auf einen Dienst oder eine Ressource.
• Rollen und Gruppen: bilden anwendungsspezifische Berechtigungen und Verantwortlichkeiten ab.
• Sitzungen: regeln, wie ein authentifizierter Browser oder Client angemeldet bleibt; sie benötigen eigene Kontrollen und Überprüfungen.

Die drei praktikablen Identitätsmodelle

Getrennte lokale Konten bedeuten, dass jede Anwendung ihre eigenen Nutzer und Authentifizierungsmethoden verwaltet. Dieses Modell verursacht mehr wiederholte Verwaltung, aber ein Ausfall oder Konfigurationsproblem in einer Anwendung verhindert nicht automatisch den Login in den übrigen Stack.

Ein Modell mit gemeinsamem Identitätsanbieter nutzt Föderation, sofern sie unterstützt wird: Der Identitätsanbieter authentifiziert die Person und sendet eine Bestätigung an die vertrauende Anwendung. Die Anwendung prüft die Bestätigung, erstellt eine authentifizierte Sitzung und gewährt Zugriff auf ihre Funktionen. Föderation kann den Bedarf an separaten Authentisierungsmitteln für mehrere Anwendungen verringern und Teile der Kontoverwaltung zentralisieren.

Ein Hybridmodell kombiniert beides. Ein Team kann beispielsweise einen gemeinsamen Identitätsanbieter für Anwendungen nutzen, die ihn unterstützen, und sorgfältig kontrollierte lokale Konten behalten, wenn eine Anwendung sie erfordert oder ein administrativer Notfallzugriff benötigt wird. Hybrid ist häufig ein bewusstes Betriebsmodell und keine unvollständige Migration.

• Lokale Konten: weniger gemeinsame Abhängigkeiten; mehr Kontoverwaltung in jeder Anwendung.
• Gemeinsamer Identitätsanbieter: ein primärer Authentifizierungsprozess; stärkere Konzentration betrieblicher Risiken.
• Hybrid: berücksichtigt unterschiedliche Anwendungsfähigkeiten und erhält zugleich einen dokumentierten Rückfallpfad.
• Gehen Sie nicht davon aus, dass ein Produkt Föderation, automatisierte Bereitstellung, detaillierte Gruppenzuordnung oder ein bestimmtes Protokoll unterstützt. Prüfen Sie die aktuelle Primärdokumentation und Ihre Bereitstellungskonfiguration.

Wann getrennte Konten die sicherere Wahl sind

Getrennte Konten sind für ein kleines, stabiles Team mit wenigen Anwendungen, seltenen Ein- und Austritten und ohne zuständige Person für den Betrieb eines dedizierten Identitätsdienstes oft angemessen. In dieser Situation kann eine zentrale Identitätsplattform mehr Konfigurations-, Wiederherstellungs- und Überwachungsaufwand schaffen, als sie einspart.

Diese Wahl ist nur sicher, wenn der wiederholte Aufwand tatsächlich beherrschbar ist. Lokale Konten benötigen einen klaren Prozess für Eintritte, Rollenwechsel und Austritte. Wenn der Entzug von Zugängen davon abhängt, dass sich jemand an jede Anwendung erinnert, kann das Modell beim Ausbau des Stacks unbemerkt versagen.

Wenden Sie in jeder Anwendung das Prinzip der geringsten Berechtigung an: Gewähren Sie nur den Zugriff, der für eine klar definierte Verantwortung erforderlich ist, beschränken Sie Administratorkonten und dokumentieren Sie, wer für jede Rolle verantwortlich ist. Eine kleine Umgebung kann statt einer komplexen Identitätsplattform ein einfaches Register und planmäßige Überprüfungen verwenden, sofern das Register aktuell gehalten wird.

• Wählen Sie lokale Konten, wenn die Zahl der Nutzer klein und Kontoänderungen selten sind.
• Wählen Sie lokale Konten, wenn Ihrem Team die Kapazität fehlt, einen gemeinsamen Identitätsdienst zu verwalten, abzusichern und wiederherzustellen.
• Verwenden Sie eindeutige Konten statt eines gemeinsam genutzten Team-Logins, damit Handlungen zugeordnet und Zugriffe einer einzelnen Person entzogen werden können.
• Führen Sie ein Verzeichnis jeder Anwendung, des Kontoverantwortlichen, privilegierter Konten, des Wiederherstellungskontakts und des Überprüfungsdatums.
• Stellen Sie sicher, dass jeder kritische Administrator über eine dokumentierte Wiederherstellungsmethode verfügt, und vermeiden Sie Wiederherstellungsdesigns, die auf einer einzigen Person beruhen.

Wann ein gemeinsamer Login gerechtfertigt ist

Zentralisierte Authentifizierung wird überzeugender, wenn Onboarding und Offboarding häufig stattfinden, wenn die Anzahl der Anwendungen wiederholte Verwaltung unzuverlässig macht oder wenn die Organisation bereits über ausgereifte Identitätskontrollen und klar geregelte administrative Verantwortung verfügt. Der Vorteil besteht nicht nur in weniger Passwörtern, sondern in einer wiederholbaren Methode, Zugriff auf unterstützte Dienste einzurichten und zu entziehen.

Föderation nimmt die vertrauende Anwendung nicht aus dem Zugriffsmodell heraus. NIST weist darauf hin, dass ein föderiertes Konto bei der vertrauenden Partei bereitgestellt werden muss, bevor eine authentifizierte Sitzung erstellt werden kann, und dass die Anwendung ihr lokales Konto unabhängig vom Identitätsanbieter deaktivieren oder beenden kann. Planen Sie beide Seiten ein: den Identitätsdatensatz und das Anwendungskonto oder den Autorisierungsdatensatz.

Zentralisieren Sie nur dort, wo der Nutzen real ist. Eine Anwendung ohne unterstützte Integration, mit Bedarf an einem lokalen Administrator oder mit einem abweichenden Lebenszyklus kann lokal bleiben. Jede Anwendung durch einen einzigen Zugangspfad zu zwingen, kann fragile Umgehungslösungen schaffen und Verantwortlichkeiten verschleiern.

• Priorisieren Sie gemeinsamen Login dort, wo häufige Kontoänderungen die manuelle lokale Verwaltung fehleranfällig machen.
• Prüfen Sie vor der Festlegung auf ein Design anhand der offiziellen Dokumentation die genaue Integrationsoption, das Rollenverhalten und die Methode zur Kontobereitstellung.
• Legen Sie fest, wer den Identitätsanbieter verwalten, Zugriffe genehmigen und Zuweisungen von Anwendungsrollen ändern darf.
• Dokumentieren Sie, wie Zugriffe sowohl beim Identitätsanbieter als auch in jeder vertrauenden Anwendung entzogen werden.
• Testen Sie die Auswirkungen einer Nichtverfügbarkeit des Identitätsanbieters auf normale Nutzer und Administratoren.

Fragen, die vor der Zentralisierung der Authentifizierung beantwortet werden sollten

Beginnen Sie mit der Kompatibilität, hören Sie dort aber nicht auf. Ermitteln Sie für jede Anwendung anhand der aktuellen Primärdokumentation die unterstützten Authentifizierungs- und Föderationsoptionen, die erforderliche Konfiguration, das Verhalten bei der Kontobereitstellung und die Funktionsweise lokaler Ausnahmen. Produktfähigkeiten können je nach Produkt, Edition, Version und Bereitstellungskonfiguration unterschiedlich sein.

Entwerfen Sie als Nächstes Verwaltung und Wiederherstellung. Die Kontowiederherstellung unterscheidet sich von der regulären Authentifizierung. NIST nennt als Wiederherstellungsansätze gespeicherte oder ausgegebene Wiederherstellungscodes, Wiederherstellungskontakte, erneute Identitätsprüfung und anwendungsspezifische Methoden, die auf dokumentierter Risikoanalyse basieren. NIST empfiehlt zudem, Nutzer dazu anzuhalten, mindestens zwei getrennte Authentifizierungsmöglichkeiten vorzuhalten, um Wiederherstellungsereignisse zu reduzieren.

Entscheiden Sie schließlich, was geschieht, wenn der normale Weg nicht verfügbar ist. Ein Break-Glass-Konto ist ein administrativer Notfallzugang und keine alltägliche Abkürzung zur Umgehung der Governance. Es sollte einen benannten Verantwortlichen, eingeschränkte Nutzung, geschütztes Wiederherstellungsmaterial, ein dokumentiertes Testverfahren und eine Überprüfung nach jeder Nutzung haben.

• Welche Authentifizierungs- oder Föderationsoptionen unterstützt jede Anwendung derzeit?
• Wer verantwortet den Mandanten oder Dienst des Identitätsanbieters, seine privilegierten Konten und seine Konfigurationsänderungen?
• Welche Anwendungskonten müssen weiterhin lokal bestehen, und warum?
• Wie werden neue Nutzer angelegt, Rollenänderungen genehmigt und ausgeschiedene Nutzer entfernt?
• Wie sieht der Break-Glass-Pfad aus, wenn der Identitätsanbieter, ein Administratorkonto oder ein Authentisierungsmittel nicht verfügbar ist?
• Wer verwahrt Wiederherstellungskontakte oder Wiederherstellungsmaterial, und wie wird dieser Zugriff geschützt und getestet?
• Wie werden Sitzungen beendet oder erneut authentifiziert, wenn Risiko- oder Rollenänderungen dies erfordern?
• Welche Nachweise belegen, dass Zugriffe und Berechtigungen überprüft wurden?

Zentralisierte Authentifizierung schafft keine einheitlichen Berechtigungen

Ein gemeinsamer Identitätsanbieter kann einer Person über unterstützte Anwendungen hinweg ein einheitliches Authentifizierungserlebnis bieten. Er legt nicht automatisch fest, was diese Person nach dem Login tun darf. Autorisierung und Zugriffsbestimmung bleiben Entscheidungen der Anwendungen, und verschiedene Anwendungen können Rollen, Gruppen und Attribute unterschiedlich interpretieren.

Vermeiden Sie es, weitreichende administrative Rechte zu vergeben, nur weil sich ein Nutzer erfolgreich über den zentralen Dienst angemeldet hat. Definieren Sie stattdessen für jede Anwendung eine Zugriffsmatrix: Aufgabenverantwortung, Anwendungsrolle, Genehmiger, Kontoverantwortlicher und Überprüfungshäufigkeit. Wo Gruppen- oder Attributzuordnung verfügbar ist, prüfen Sie das tatsächliche Verhalten in der aktuellen Produktdokumentation und testen Sie es, wenn möglich, mit Nicht-Produktionskonten.

Externe Authentifizierungsebenen können zudem eine eng begrenzte Rolle haben. Traefik ForwardAuth delegiert beispielsweise die Authentifizierung an einen externen Dienst und erlaubt Zugriff, wenn dieser Dienst eine 2XX-Antwort zurückgibt. Das beschreibt eine Authentifizierungsschranke; es legt nicht selbst die internen Rollen, Datenberechtigungen oder Lebenszykluskontrollen einer Anwendung fest.

• Pflegen Sie anwendungsspezifische Rollendefinitionen, auch wenn die Authentifizierung gemeinsam erfolgt.
• Verlangen Sie eine ausdrückliche Genehmigung für privilegierte Rollen.
• Überprüfen Sie Gruppen-zu-Rollen-Zuordnungen immer dann, wenn sich entweder die Identitätskonfiguration oder die Anwendungskonfiguration ändert.
• Betrachten Sie eine Authentifizierungsschranke am Reverse Proxy nicht als vollständiges Autorisierungssystem.
• Behalten Sie Sitzungskontrollen und Datenzugriffsregeln als separate Sicherheitsaspekte der Anwendung im Blick.

Betreiben Sie das Modell mit Nachweisen, Überprüfungen und dokumentierter Verantwortung

Unabhängig vom gewählten Modell sollten Sie ein anwendungsbezogenes Identitätsregister führen. Erfassen Sie Identitätsquelle, Anwendungsverantwortlichen, privilegierte Konten, Ausnahmen für lokale Konten, Wiederherstellungskontakte, den normalen Bereitstellungsweg, den Entzugsweg sowie die Nachweise aus der letzten Berechtigungsüberprüfung. So erhält ein wachsendes Team eine prüfbare betriebliche Dokumentation, ohne nicht unterstützte Automatisierung vorauszusetzen.

Richten Sie Überprüfungen an Eintritten, Rollenwechseln und Austritten aus. Eine neu eintretende Person benötigt nur den genehmigten Zugriff, der für den Arbeitsbeginn erforderlich ist. Bei einem Rollenwechsel müssen alte Rechte mit Blick auf die veränderten Verantwortlichkeiten neu bewertet werden, statt lediglich neue Rechte hinzuzufügen. Bei einem Austritt müssen Zugriffe über alle relevanten Wege hinweg zeitnah entfernt oder deaktiviert werden, einschließlich lokaler Ausnahmen und privilegierter Konten. Legen Sie einen Rhythmus fest, der sich an Änderungsvolumen und Risiko orientiert, und bewahren Sie Nachweise auf, dass die Überprüfung stattgefunden hat und Ausnahmen behoben wurden.

Das Cybersecurity Framework 2.0 von NIST betont Governance durch Rollen, Verantwortlichkeiten, Befugnisse, Richtlinien und Aufsicht. Setzen Sie dieses Prinzip praktisch um: Jemand sollte den Identitätsdienst verantworten, jemand das Autorisierungsmodell jeder Anwendung, und Eskalationswege sollten bekannt sein, bevor eine Aussperrung oder ein Austritt eintritt.

Verwaltetes Hosting von Docker-Anwendungen kann den Infrastrukturverwaltungsaufwand rund um bereitgestellte Dienste reduzieren. Es ersetzt weder Identitätsengineering noch Identity Governance auf Unternehmensebene. Wenn Verzeichnisintegration, regulatorische Verpflichtungen, Hochverfügbarkeit oder formale Anforderungen an die Identitätssicherheit die Kapazität Ihres Teams übersteigen, nutzen Sie einen spezialisierten Identitätsdienst oder ein Enterprise-Hosting-Modell, statt eine allgemeine verwaltete Anwendungsplattform als vollständige Lösung für das Identitätsmanagement zu behandeln.

• Erstellen und pflegen Sie für jede Anwendung ein Identitätsregister.
• Überprüfen Sie Zugriffe nach Rollenänderungen und nicht nur bei regelmäßigen Audits.
• Überprüfen Sie privilegierte Konten eingehender als gewöhnliche Konten.
• Dokumentieren Sie Ausnahmen für lokale Konten und entfernen Sie sie, sobald sie nicht mehr gerechtfertigt sind.
• Testen Sie Wiederherstellungs- und Break-Glass-Verfahren in einem geplanten Rhythmus; dokumentieren Sie Ergebnisse und Abhilfemaßnahmen.
• Nutzen Sie die offizielle Dokumentation der Anwendungen und des Identitätsanbieters als Grundlage für Konfigurations- und Kontrollentscheidungen.
• Bewerten Sie das Modell erneut, wenn sich Anwendungszahl, Personalfluktuation, Datensensibilität oder betriebliche Anforderungen ändern.