Der eigene Identity Provider: Warum die digitale Identität ins Haus gehört

Ein neuer Mitarbeiter fängt am Montag an. Bis Mittwoch hat er ein Postfach, ein Konto im ERP, eines im Dokumentenmanagement, eines im Ticketsystem, eines in der Zeiterfassung, eines im Wiki, eines im VPN und ein geteiltes Passwort für das Monitoring, das „schon immer so war“. Acht Konten, acht Passwörter, acht Stellen, an denen jemand etwas eintragen musste – und acht Stellen, an denen es beim Austritt wieder verschwinden muss.

Der Austritt ist der interessantere Fall. Die Erfahrung aus Sicherheitsaudits ist so eintönig wie eindeutig: In fast jedem Unternehmen finden sich aktive Konten von Personen, die seit Monaten nicht mehr im Haus sind. Nicht aus Nachlässigkeit, sondern weil niemand acht Systeme im Kopf hat. Jedes dieser Konten ist ein funktionierender Zugang, oft mit einem Passwort, das zuletzt vor Jahren geändert wurde.

Genau das ist das Problem, das ein zentraler Identity Provider löst. Und der Zeitpunkt, es zu lösen, ist günstiger denn je – weil die Kosten des Nichtstuns gerade sichtbar werden.

Was ein Identity Provider tut – und was er nicht ist

Ein Identity Provider (IdP) ist die eine Stelle im Unternehmen, die Personen kennt und ihre Anmeldung beglaubigt. Anwendungen verwalten dann keine Passwörter mehr, sondern fragen den IdP: Wer ist das, und darf er zu mir? Technisch läuft das über offene Standards – OpenID Connect und SAML für Web-Anwendungen, LDAP für ältere Systeme –, die praktisch jede ernst zu nehmende Geschäftssoftware heute spricht.

Für die Person heißt das: einmal anmelden, überall drin (Single Sign-on). Für die IT heißt es etwas Wichtigeres: eine Quelle der Wahrheit. Wer im IdP deaktiviert wird, ist in allen angebundenen Systemen sofort draußen. Wer die Abteilung wechselt, wechselt seine Gruppe – und damit seine Berechtigungen überall. Multi-Faktor-Authentisierung wird einmal erzwungen, nicht acht Mal konfiguriert und sieben Mal vergessen.

Was ein IdP nicht ist: ein Passwortmanager. Der Passwortmanager verwaltet das Chaos, der IdP beseitigt es.

Warum gerade jetzt

Vier Entwicklungen haben das Thema von der Kür zur Pflicht gemacht.

Die Identität ist der neue Perimeter. Die Firewall schützt das Netz, aber die Angriffe kommen längst nicht mehr über das Netz. Sie kommen über gestohlene Zugangsdaten: Phishing, Infostealer auf dem Privatrechner, ein wiederverwendetes Passwort aus einem fremden Datenleck. In den Lageberichten des BSI und in den Vorfallstatistiken der Versicherer stehen kompromittierte Anmeldedaten seit Jahren ganz oben. Der Ransomware-Fall, den wir hier beschrieben haben, begann nicht mit einer Schwachstelle in einem Server, sondern mit einem Konto. Wer Identitäten an acht Stellen führt, hat acht Angriffsflächen mit acht verschiedenen Sicherheitsniveaus – und das schwächste bestimmt das Ergebnis.

Die Regulierung verlangt es inzwischen ausdrücklich. NIS2 nennt Multi-Faktor-Authentisierung und ein Zugriffs- und Berechtigungskonzept als Mindestmaßnahmen; die Sicherheitsfragebögen, die erfasste Unternehmen an ihre Zulieferer weiterreichen, fragen beides ab. Was der Leitungsebene dabei persönlich droht, steht im Grundlagenartikel. Ohne zentrale Identität sind diese Fragen ehrlich kaum mit ja zu beantworten: Man kann MFA nicht nachweisen, wenn man nicht einmal die Liste aller Systeme hat, in denen sich jemand anmelden kann. Dasselbe gilt für Cyber-Versicherungen, deren Bedingungen MFA für alle Fernzugriffe inzwischen fast durchgängig zur Obliegenheit machen.

Die Systemlandschaft ist hybrid geworden – dauerhaft. Kaum ein Mittelständler ist heute noch rein „on-premises“ oder rein „Cloud“. Microsoft 365 im Büro, das ERP im eigenen Rechenzentrum, das DMS beim Dienstleister, drei Fachanwendungen als SaaS, ein halbes Dutzend interner Werkzeuge. Jede dieser Welten bringt ihr eigenes Benutzerkonzept mit. Ein zentraler IdP ist die Klammer, die diese Welten unter einer Identität zusammenhält, statt jede Anwendung an die nächste zu kleben.

Neue Arten von Identitäten kommen dazu. Dienstkonten, API-Schlüssel, Integrationen – und seit Kurzem KI-Agenten, die im Namen von Personen oder Abteilungen handeln. Wer heute nicht sauber weiß, welche menschlichen Konten es gibt, wird bei den nicht-menschlichen keine Chance haben. Ein IdP mit Gruppen, Rollen und Protokoll ist die einzige Struktur, in der sich das noch beherrschen lässt.

Der eigene IdP – oder reicht der Microsoft-Tenant?

Die naheliegende Rückfrage lautet: Wir haben doch Microsoft 365, da ist Entra ID dabei. Genügt das nicht?

Für die Microsoft-Welt selbst: ja. Für alles andere ist die Antwort differenzierter, und sie ist der Kern der Entscheidung.

• Eigene Systeme hängen sonst im fremden Tenant. Das interne Wiki, das Monitoring, die Fachanwendung, der Admin-Zugang zum DNS – all das an Entra anzubinden bedeutet, dass die Anmeldung an die eigene Infrastruktur von einem Cloud-Dienst abhängt, dessen Störungen man in der Presse liest. Ein IdP im eigenen Betrieb ist die Instanz, die auch dann noch beglaubigt, wenn draußen etwas klemmt – und die eigene Systeme mit eigenen Regeln versorgt.
• Legacy und Sonderfälle. Nicht jede Anwendung spricht die Standards sauber. Ältere Fachanwendungen brauchen LDAP, manche brauchen einen vorgeschalteten Proxy, der die Anmeldung übernimmt, manche erwarten Profilfelder unter anderen Namen. Ein eigener IdP lässt sich für jeden dieser Fälle anpassen; eine Cloud-Plattform kann das nur in den Grenzen ihres Produkts.
• Lizenzlogik. Erweiterte Funktionen wie bedingter Zugriff oder feinere Richtlinien sind bei den großen Cloud-Anbietern an höhere Lizenzstufen pro Benutzer gebunden. Bei einem Open-Source-IdP entscheidet man selbst, was man einsetzt, und bezahlt in Betriebsaufwand statt in Lizenzen.
• Souveränität und Auditierbarkeit. Wer die Identität im Haus hält, hält auch die Protokolle im Haus: Wer hat sich wann wo angemeldet, welcher Faktor wurde genutzt, wer hat wessen Rechte geändert. Für Audits, Vorfallaufklärung und Datenschutz-Nachweise ist das Gold wert.

Das ist kein Entweder-oder. Der praktikable Aufbau ist eine Föderation: Der eigene IdP nimmt den Microsoft-Tenant als eine Quelle unter mehreren auf. Die Belegschaft meldet sich weiter mit ihrem gewohnten Microsoft-Konto an, inklusive der dort erzwungenen MFA – aber die eigenen Systeme reden nur mit dem eigenen IdP. Administrative Konten bleiben bewusst lokal und außerhalb der Cloud, mit Hardware-Schlüsseln abgesichert. Fällt der Cloud-Anbieter aus, funktionieren die lokalen Notfallzugänge weiter. Trennt man sich irgendwann vom Anbieter, bleibt die Identitätsstruktur erhalten.

authentik in der Praxis

Wir haben diesen Aufbau selbst umgesetzt, mit authentik – einem Open-Source-IdP, der OpenID Connect, SAML, LDAP und Proxy-Anmeldung aus einer Oberfläche heraus bedient und dessen Anmeldeabläufe sich als konfigurierbare Flows gestalten lassen, statt in Code gegossen zu werden. Die Wahl fiel nicht zuletzt deshalb auf authentik, weil die Verwaltungsoberfläche im freien Tier vollständig enthalten ist; wer sie bei anderen Produkten braucht, landet schnell in der Enterprise-Preisliste.

Ein paar Erfahrungen, die für jede Einführung gelten:

1. Der IdP ist das kritischste System im Haus. Fällt er aus, kann sich niemand mehr irgendwo anmelden. Das verändert die Anforderungen an Betrieb, Hochverfügbarkeit, Backup und – vor allem – an den getesteten Wiederherstellungsfall. Bei uns wurde die Wiederherstellung aus dem Datenbank-Backup vor dem produktiven Rollout einmal komplett durchgespielt, nicht nur dokumentiert.
2. Break-Glass zuerst. Bevor die MFA-Pflicht scharf geschaltet wird, braucht es ein Notfallkonto mit statischen Codes – gedruckt, im Tresor. Nicht im Passwortmanager, dessen Anmeldung möglicherweise am selben IdP hängt.
3. Die erste Anwendung ist die lehrreichste. Unsere erste angebundene Anwendung war eine Verwaltungsoberfläche für den Nameserver – ein vermeintlich simpler Fall, der vier Eigenheiten in der Standardkonfiguration zutage förderte, von der Schreibweise einer URL bis zu einem fehlenden Namensfeld im Profil. Nichts davon war dramatisch, alles davon hätte ohne Testumgebung in der Produktion geknallt. Eine Staging-Instanz des IdP ist keine Luxusausstattung.
4. Patch-Rhythmus festlegen, bevor die erste Lücke kommt. Ein IdP steht per Definition am Netzrand und ist ein lohnendes Ziel. Monatliche Aktualisierung plus sofortige Reaktion auf Sicherheitsmeldungen, mit einer benannten Person – das gehört in den Betriebsvertrag, nicht in die Absichtserklärung.

„Die meisten Unternehmen, mit denen wir sprechen, haben kein Passwortproblem – sie haben ein Inventarproblem. Sie wissen nicht, in wie vielen Systemen jemand ein Konto hat, und darum können sie beim Austritt nicht sauber abschalten, beim Audit nicht sauber nachweisen und beim Vorfall nicht sauber eingrenzen. Ein zentraler Identity Provider ist zuerst einmal genau dieses Inventar, mit einem Schalter dran. Alles andere – Single Sign-on, MFA, Compliance – folgt daraus fast von selbst.“

— Christian Zöpfchen, Geschäftsführer der etis GmbH

Was Entscheider klären sollten

Die Einführung eines IdP ist kein Softwarekauf, sondern eine Organisationsentscheidung. Fünf Fragen sollte die Geschäftsführung beantwortet haben, bevor ein Projekt startet:

1. Wo ist die Quelle der Wahrheit? Personalsystem, Microsoft-Tenant, der IdP selbst? Es darf nur eine geben, und der Ein- und Austrittsprozess muss dort beginnen.
2. Welche Systeme sind in Welle eins? Alle Systeme mit Fernzugriff und alle mit personenbezogenen Daten. Der Rest folgt, aber diese beiden Gruppen entscheiden über das Risiko.
3. Wer betreibt ihn – und mit welcher Verfügbarkeit? Ein IdP ohne Bereitschaft ist ein Single Point of Failure mit Bedienungsanleitung. Eigenes Team, Dienstleister oder eine Kombination – die Antwort muss vor dem Rollout stehen.
4. Wie sieht der Notfall aus? Wiederherstellung getestet, Break-Glass-Zugang vorhanden, Verhalten bei Ausfall des föderierten Cloud-Anbieters durchgespielt.
5. Was ist mit den Ausnahmen? Es wird Systeme geben, die sich nicht anbinden lassen. Für die braucht es eine bewusste Entscheidung – abschaffen, isolieren oder mit dokumentiertem Restrisiko weiterführen –, keine stillschweigende Duldung.

Der Aufwand für einen sauber betriebenen IdP liegt für einen Mittelständler bei wenigen Wochen Einführung und einem überschaubaren laufenden Betrieb. Die Alternative ist keine Ersparnis, sondern ein Kredit: Acht Benutzerlisten, die niemand pflegt, werden irgendwann fällig – beim Audit, beim Fragebogen des Kunden oder beim Konto des ehemaligen Kollegen, das jemand anderes gefunden hat.