IAM-Beratung: von der Bestandsaufnahme bis zum Betrieb

Eine IAM-Beratung trifft in den meisten Unternehmen auf eine Landschaft, in der Identitäten seit Jahren an mehreren Stellen entstehen: im Active Directory, im Personalsystem, in einzelnen Fachanwendungen und in Tabellen, die niemand mehr pflegt. Der Produktvergleich ist dabei selten die schwierige Frage. Schwierig ist die Reihenfolge: was zuerst erhoben wird, was in Wellen migriert und welche Prozesse am Ende im Unternehmen liegen. Dieser Artikel beschreibt diese Reihenfolge.

IAM-Beratung: das Inventar der Identitäten und Anwendungen

Die Bestandsaufnahme bestimmt die Schätzung für alles Weitere. Neben den gepflegten Mitarbeiterkonten finden sich auf der Identitätsseite mindestens fünf weitere Arten:

• Servicekonten zwischen Anwendungen. Ihre Zugangsdaten liegen in Konfigurationsdateien, Job-Definitionen und Skripten, oft ohne Ablaufdatum und ohne Eigentümer.
• Technische Konten für Datenbanken und Schnittstellen. Vielfach mit höheren Rechten als die Aufgabe verlangt, weil sie beim ersten Fehler erweitert und danach nicht zurückgenommen wurden.
• Administrationskonten. Bei geteilten Administrationskonten lässt sich eine Handlung keiner Person zuordnen.
• Partner- und Lieferantenkonten. Angelegt für ein Projekt, verlängert für den Betrieb, selten beendet, weil ein Vertragsende im IT-Betrieb nicht ankommt.
• Verwaiste Konten. Aktiv im Verzeichnis, ohne Gegenstück im Personalsystem, ohne Anmeldung seit langer Zeit.

Die Erhebung ist ein Abgleich: das Verzeichnis gegen die aktiven Beschäftigungsverhältnisse aus dem Personalsystem, beides gegen den Zeitstempel der letzten Anmeldung. Was auseinanderfällt, ist die Arbeitsliste.

Auf der Anwendungsseite braucht jede Anwendung vier Angaben: mit welchem Verfahren sie ihre Nutzer authentifiziert, wo ihre Berechtigungen liegen, wer den Zugang genehmigt und wer sie fachlich verantwortet. Einen Zugang, den niemand verantwortet, kann später niemand rezertifizieren.

Aufgeräumt wird erst danach: wer während der Erhebung Konten deaktiviert, erzeugt Störungen, deren Ursache niemand mehr zuordnen kann.

Rollenmodell aufbauen: der Kern jeder IAM-Beratung

Rollenexplosion ist der Zustand, in dem wir bestehende Modelle am häufigsten antreffen. Sie entsteht aus einer nachvollziehbaren Absicht: jede Zugriffskombination soll eine eigene Rolle bekommen. Multipliziert man Abteilung, Standort, Anwendung und Tätigkeit, wächst die Zahl der Rollen bis in die Nähe der Zahl der Nutzer. Ein Modell mit ebenso vielen Rollen wie Personen leistet nichts, was eine Einzelvergabe nicht auch leistet, kostet aber Pflege.

Der Ausweg liegt in zwei getrennten Ebenen. Die obere beschreibt Geschäftsrollen in der Sprache der Organisation: Funktion, Bereich, Standort, Tätigkeit. Die untere enthält die technischen Berechtigungen, wie das jeweilige System sie kennt: Gruppen, Profile, Transaktionscodes, Datenbankrollen. Dazwischen liegt eine gepflegte Zuordnung, sodass neue Berechtigungen unten entstehen, ohne dass oben eine Rolle hinzukommt.

Zwei Regeln halten das Modell dauerhaft brauchbar:

• Der Entwurf beginnt bei den vorhandenen Zuweisungen. Eine Auswertung der vergebenen Berechtigungen zeigt, welche Bündel in der Praxis vorkommen. Ein rein am Organigramm entworfenes Modell wird in der Einführung durch Ausnahmen aufgelöst.
• Nicht jeder Zugriff braucht eine Rolle. Für seltene Kombinationen ist eine dokumentierte Einzelvergabe mit Ablaufdatum sauberer. Eine Rolle für zwei Personen ist Pflegeaufwand ohne Gegenwert.

Mitarbeiter, Kunden und Partner: drei getrennte IAM-Vorhaben

Die zweite Fehlentscheidung ist, diese drei Gruppen in einem Modell zu verwalten.

Mitarbeiter. Führendes System ist die Personalverwaltung. Der Lebenszyklus ist im Voraus bekannt, weil Ein- und Austritt Vertragsdaten sind, und Mehrfaktor-Authentifizierung lässt sich über Firmengeräte durchsetzen.

Kunden. Es gibt kein führendes System außer der Anwendung selbst. Identitäten entstehen durch Selbstregistrierung, das Volumen liegt um Größenordnungen höher, und die Lastspitzen folgen dem Geschäft und nicht den Bürozeiten. Dazu kommen Anforderungen, die es intern nicht gibt: Selbstbedienung beim Passwort, Einwilligungsverwaltung, Löschung auf Antrag, Datenauskunft.

Partner. Die Identität gehört einer anderen Organisation. Tragfähig ist Föderation über den Identity-Provider des Partners, und delegierte Administration dort, wo Föderation nicht möglich ist: der Partner verwaltet seine Nutzer selbst, das Vertragsende beendet den Zugang aller.

Praktisch bedeutet das getrennte Mandanten oder Realms mit eigenen Anmeldeverfahren, Passwortrichtlinien und Sitzungsregeln. Jede der drei Gruppen ist ein eigener Arbeitsstrang mit eigenem Zeitplan, dessen produktseitige Umsetzung wir am Beispiel von Keycloak im Unternehmen beschrieben haben.

IAM-Migration in Wellen und die Koexistenz dazwischen

Die Wellen folgen den Abhängigkeiten, nicht dem Organigramm. Die erste enthält sinnvollerweise eine Anwendung mit echten Nutzern, deren Ausfall verkraftbar ist.

Der schwierige Teil ist der Zustand dazwischen. Über Monate gelten zwei Anmeldewege parallel, und drei Entscheidungen müssen vorher getroffen sein:

• Die Richtung der Synchronisation. Für jedes Attribut wird ein schreibendes System festgelegt. Beidseitige Synchronisation zwischen altem Verzeichnis und neuem Identity-Provider erzeugt Konflikte, die sich nicht regelbasiert auflösen lassen.
• Der Umgang mit den Passwörtern. Hashes lassen sich übernehmen, wenn das Zielsystem den Algorithmus der Quelle unterstützt oder das Passwort beim ersten Login neu hasht. Sonst bleibt ein erzwungener Wechsel, und der gehört terminlich nicht in dieselbe Woche wie die Anwendungsumstellung.
• Das Verhalten beim Abmelden. Während der Koexistenz hat ein Nutzer zwei Sitzungen, und ein Logout im neuen System beendet die alte nicht.

Die Aufteilung in Etappen folgt derselben Logik wie andere Ablösevorhaben, die wir in Altsysteme ablösen ohne Big Bang beschrieben haben: eine Umstellung aller Anwendungen an einem Wochenende verlegt jedes ungelöste Detail in dieselbe Nacht.

Die Anwendungen, die weder OIDC noch SAML sprechen

Diese Kategorie bestimmt meist den Aufwand des Projekts und fehlt meist in der ersten Schätzung. Für jede Anwendung gibt es drei Ausgänge.

Anbinden. Möglich, wenn die Anwendung ein Verzeichnisprotokoll spricht oder eine integrierte Windows-Anmeldung nutzt. Der Identity-Provider vermittelt, das Verzeichnis bleibt im Pfad: kein Zielzustand, aber ein tragfähiger Zwischenschritt.

Vorschalten. Für Anwendungen mit eigener Benutzertabelle und ohne Schnittstelle. Ein Reverse Proxy übernimmt die Authentifizierung und übergibt die Identität in einem geprüften Header. Das setzt voraus, dass die Anwendung ausschließlich über diesen Proxy erreichbar ist. Bleibt der direkte Weg offen, ist die Absicherung wirkungslos.

Ausnahme mit Ablaufdatum. Für Terminalanwendungen, Fat Clients mit fest eingebauten Zugangsdaten und Software am Ende ihres Lebenszyklus, eingetragen mit Eigentümer, Begründung und Datum. Eine Ausnahme ohne Ablaufdatum bleibt dauerhaft bestehen.

Ein Passwort-Tresor verwaltet Passwörter, er beseitigt sie nicht: Richtlinien, Rotation und Protokollierung bleiben eigene Themen. Privilegierte Zugänge sind ein eigener Arbeitsstrang, weil Sitzungsaufzeichnung und Vier-Augen-Freigabe eigene technische und arbeitsrechtliche Voraussetzungen haben.

Der Aufwand entsteht an den Schnittstellen der Anwendungen, nicht im Identity-Produkt. Wir behandeln ihn deshalb als Systemintegration mit eigener Schätzung.

Joiner-Mover-Leaver: ein Prozess ist an einer Messung erkennbar

Fast jedes Unternehmen hat ein Dokument zum Berechtigungslebenszyklus. Der Zustand des Prozesses zeigt sich an drei Punkten.

Joiner. Ein Zugang am ersten Arbeitstag verlangt Personaldaten vor dem ersten Arbeitstag. Auslöser ist der angelegte Vertragsdatensatz, nicht die Mail einer Führungskraft am Morgen. Fehlt die Vorlaufzeit, entsteht der Umgehungsweg, der später schwer zurückzunehmen ist: das Kopieren der Rechte eines Kollegen.

Mover. Der schwierigste Fall, weil Rechte sich addieren: beim Wechsel werden neue Berechtigungen erteilt und die alten selten entzogen, sodass eine Person nach einigen Jahren die Summe aller Rollen hat, die sie je hatte. Ein tragfähiger Mover-Prozess erzeugt deshalb eine Differenzliste mit zwei Spalten, erteilen und entziehen, mit Frist und Verantwortlichem, plus ein automatisches Ablaufdatum auf den alten Rechten, damit Untätigkeit zum Entzug führt.

Leaver. Sperre und Löschung sind zu trennen. Die Sperre unterbindet die Anmeldung, beendet die laufenden Sitzungen und entzieht die Refresh-Token. Der letzte Punkt wird übersehen: ein ausgestelltes Access-Token bleibt bis zu seinem Ablauf gültig, unabhängig davon, ob das Konto noch existiert. Wer die Token-Laufzeiten nicht kennt, kennt seine Sperrfrist nicht. Die Löschung folgt eigenen Fristen, weil Postfächer, Dateien und Nachweise unterschiedlich lange aufzubewahren sind. Vertragsende und Projektende sind Auslöser wie ein Austritt, auch für Partnerzugänge und Servicekonten.

Ob der Prozess trägt, zeigt eine Zahl: die Zeit vom Austrittsdatum im Personalsystem bis zum gesperrten Konto, erhoben an echten Fällen.

Abgleich mit dem Personalsystem und Attributhoheit

An dieser Stelle bleiben Identity-Projekte in unserer Erfahrung besonders oft technisch stehen. Das Personalsystem ist führend für die Existenz einer Person und ihre organisatorische Zuordnung, nicht für alles Übrige.

Für jedes Attribut wird festgelegt, welches System es schreibt: Name, Kostenstelle, Organisationseinheit, Führungskraft, Vertragsende, Mailadresse. Ein Attribut hat genau ein schreibendes System, sonst überschreiben sich zwei Quellen gegenseitig und der jeweils letzte Lauf gewinnt.

Die Fälle, die den Abgleich brechen, werden selten vorab modelliert: Namensänderungen, Doppelerfassungen derselben Person, Wiedereintritte mit neuer Personalnummer, Reorganisationen mit umbenannten Kostenstellen, und die Datumssemantik, in der Eintrittsdatum, Vertragsbeginn und erster Arbeitstag drei verschiedene Werte sein können. Dazu die Gruppen, die im Personalsystem nicht geführt werden: externe Kräfte, Werkverträge, Aushilfen.

Bewährt hat sich ein täglicher Delta-Lauf plus ein vollständiger Abgleich in größerem Abstand, der Abweichungen berichtet statt sie still zu korrigieren. Eine Synchronisation, die selbsttätig geradezieht, verdeckt das Datenqualitätsproblem, das sie sichtbar machen sollte. Die Muster solcher Kopplungen haben wir in Systemintegration für geschäftskritische Systeme ausgeführt.

Rezertifizierung: Umfang, Takt und Entscheider

Die wiederkehrende Überprüfung der Rechte wird in Prüfungen erwartet und bleibt oft ohne Wirkung. Vier Ursachen wiederholen sich.

Der Umfang pro Prüfer ist zu groß. Wer mehrere hundert Zeilen bestätigen soll, bestätigt sie pauschal. Kampagnen werden deshalb nach Anwendung oder Organisationseinheit geschnitten.

Die Rechte sind technisch benannt. Ein Gruppenname aus dem Verzeichnis ist für eine Führungskraft nicht beurteilbar. Jede Berechtigung braucht eine fachliche Beschreibung, und die ist Teil des Rollenkatalogs.

Es gibt keine Folge bei Nichtreaktion. Die Standardhandlung muss vorher festgelegt sein, in der Regel Entzug bei unkritischen Rechten und Eskalation bei kritischen.

Das Ergebnis wird nicht umgesetzt. Ein bestätigter Entzug, den niemand ausführt, ist schlechter als keine Kampagne, weil der Nachweis das Gegenteil behauptet. In die Berichterstattung gehört deshalb die Umsetzungsquote, nicht nur die Rücklaufquote.

DSGVO, Betriebsrat und die Protokollierung der Zugriffe

Im deutschsprachigen Raum hat ein Identity-Projekt zwei Rahmenbedingungen, die den Terminplan beeinflussen.

Die erste ist die DSGVO. Artikel 32 verlangt geeignete technische und organisatorische Maßnahmen, was die Zugriffskontrolle zu einer rechtlichen Anforderung macht. Artikel 15 verlangt Auskunft, das System muss also für eine Person berichten können, welche Zugriffsrechte sie hatte. Und die Datenminimierung nach Artikel 5 Absatz 1 Buchstabe c gilt auch für die Protokolle des Systems selbst: die protokollierten Anmeldevorgänge aller Beschäftigten sind ein Verhaltensdatensatz. Dazu gehört ein Löschkonzept mit Fristen je Protokollart und die Trennung von Sicherheitsprotokollen für die Vorfallanalyse und Nachweisprotokollen für Prüfungen.

Die zweite ist die Mitbestimmung. Nach § 87 Absatz 1 Nummer 6 Betriebsverfassungsgesetz ist die Einführung technischer Einrichtungen, die zur Überwachung von Verhalten oder Leistung der Beschäftigten geeignet sind, mitbestimmungspflichtig. Ein Identity-System mit Anmeldeprotokollen, Auswertungen pro Nutzer oder Sitzungsaufzeichnung für privilegierte Zugänge fällt darunter. Der Betriebsrat wird deshalb in der Entwurfsphase beteiligt, nicht vor dem Produktivstart. Eine Betriebsvereinbarung regelt üblicherweise, welche Daten protokolliert werden, wer sie auswerten darf und wie lange sie aufbewahrt werden. Wer das als Formalie am Ende behandelt, verliert Wochen an der teuersten Stelle des Plans.

Als Struktur für die Konzeptdokumente eignet sich der in Prüfungen anerkannte Baustein ORP.4 Identitäts- und Berechtigungsmanagement aus dem IT-Grundschutz des BSI.

IAM-Betrieb nach der Umstellung: Zertifikate und Notzugang

Nach dem letzten Anwendungswechsel macht ein Ausfall des Identity-Providers jede angebundene Anwendung unbenutzbar. Vier Themen gehören in den Betriebsplan.

Zertifikate und Schlüssel laufen ab. Ein abgelaufenes Signaturzertifikat einer SAML-Verbindung ist in Projekten von DNA Solutions eine wiederkehrende Ausfallursache und vermeidbar, sobald Ablaufdaten überwacht werden.

Die Überwachung misst die Anmeldungen: eine laufende Instanz, die keine erfolgreiche Authentifizierung mehr erzeugt, gilt einer prozessbasierten Überwachung als gesund. Die Kennzahl ist die Erfolgsquote je angebundener Anwendung.

Es gibt einen Notzugang: ein versiegeltes Konto mit Alarmierung bei Nutzung. Seine Verwendung und die Rücksicherung des Identitätsspeichers sind geübt.

Neue Anwendungen kommen über einen Standardvorgang hinzu, mit Antragsweg, Namenskonvention und Konfiguration als Code. Sonst entstehen im zweiten Jahr wieder Anmeldungen außerhalb des Systems. Die produktseitigen Betriebsthemen, von Härtung über Hochverfügbarkeit bis zur Upgrade-Disziplin, beschreiben wir in unserer Leistung zu IAM und Keycloak.

Was nach der IAM-Beratung im Unternehmen bleiben muss

Vier Dinge gehören dauerhaft ins Unternehmen: die fachliche Verantwortung für das Rollenmodell, die Festlegung der Attributhoheit samt Pflege der Personalschnittstelle, die Genehmigungs- und Rezertifizierungsentscheidungen, und das Ausnahmenregister mit seinen Ablaufdaten.

Ein Dienstleister kann den Katalog bauen und die bestehenden Rechte auswerten. Was eine Rolle bedeuten soll, entscheidet der Fachbereich, sonst ist sie in zwei Jahren nicht mehr erklärbar. Im Ausnahmenregister bleibt der ungelöste Rest des Projekts sichtbar.

Zur Übergabe gehören der Rollenkatalog mit fachlichen Beschreibungen, das Anwendungsregister mit Authentifizierungsverfahren und Eigentümer, das Ausnahmenregister, der Berechtigungslebenszyklus mit benannten Verantwortlichkeiten sowie das Protokoll- und Löschkonzept mit der zugehörigen Betriebsvereinbarung.

Sprechen wir über IAM-Beratung

DNA Solutions unterstützt Unternehmen im DACH-Raum bei IAM-Vorhaben dieser Art: von der Bestandsaufnahme über Rollenmodell und Migration in Wellen bis zum Betrieb mit Rezertifizierung und Betriebsvereinbarung. Wir beginnen mit Inventar und Rollenmodell, weil beide die Produktentscheidung vorbereiten. Wenn Sie vor einem solchen Projekt stehen oder eine bestehende Installation in tragfähigen Betrieb bringen wollen: Sprechen Sie uns an.