Identity Security in der Praxis: Was Prüfer zuerst kontrollieren

Sicherheitsprogramme beginnen oft mit Netzwerkdiagrammen und Endpoint-Agenten. Externe Prüfer — ISO 27001, NIS2, DORA oder Kunden-DD — starten woanders: wer hat wann Zugriff auf was, über welchen Pfad, mit welcher Freigabe, und können Sie es für das letzte Quartal belegen. Identity ist die Control Plane, kein IT-Unterkapitel. Ist Identity schwach, wird jede andere Kontrolle weniger vertrauenswürdig: Ihr SIEM unterscheidet keinen legitimen Admin von einem veralteten Vendor-Konto, das deaktiviert sein sollte.

W Audit-Eröffnungen präsentiert der CISO einen polierten ISMS-Ordner — und der Lead Auditor antwortet: „Danke — zeigen Sie drei beendete Contractor und wann der Zugriff entzogen wurde.“ Diese Frage setzt den Ton für die Woche. Organisationen, die glatt bestehen, haben selten die meisten Tools. Sie haben HR-Status, IAM-Provisioning und Ticketnummern ohne Improvisation im Einklang.

Die ersten drei Stichproben

Privilegiertes Access-Inventar kommt zuerst. „Wir haben wenige Admins“ reicht nicht. Gefordert werden Konten mit erhöhten Rechten in AD, Entra ID/Azure, Cloud-IAM, DB-Sysadmin und SaaS-Admin — mit Last-Use und benannten Ownern. Dauerhafter Global Admin ohne PIM/JIT wird routinemäßig markiert. Ein Fertigungskunde fand vierzehn schlafende Global-Admins aus einer Migration 2019; drei hatten sich im letzten Monat ohne dokumentierten Grund angemeldet.

MFA-Abdeckung und Ausnahmen folgen. Tenant-weites „MFA enabled“ ist nicht dasselbe wie Erzwingung auf jedem Sign-in-Pfad. Gefordert werden Anteil mit phishing-resistentem MFA plus jede dokumentierte Ausnahme mit kompensierender Kontrolle, Ablaufdatum und Approver. Ein Spreadsheet „temporärer“ Ausnahmen, vierteljährlich erneuert über zwei Jahre, ist ein Major NC.

Joiner-Mover-Leaver-Belege schließen das Trio. Drei zufällige Hires, Rollenwechsel und Exits der letzten neunzig Tage: HR-Ticket → Provisioning → Grant → Revoke. Lücken zwischen HR-Offboarding und Account-Disable — selbst achtundvierzig Stunden — gehören zu den häufigsten Major Findings im B2B-IT. Ein ausgeschiedener Sales Engineer behielt elf Tage VPN, weil „IT auf Laptop-Rückgabe wartete“ — irrelevant für VPN-Credentials.

Was „gut“ ohne neues Portal bedeutet

Reife Identity Security ist absichtlich langweilig. RBAC-Gruppen folgen Jobfunktionen. Rezertifizierung hat Kalender und Owner, die wirklich approve/revoke klicken. Privileged Sessions werden geloggt; Break-Glass offline, an einer Hand abzählbar, quartalsweise im Tabletop geübt. Tools variieren — das Evidence Model nicht.

Wir empfehlen eine Identity Control Matrix: Kontrollziel, System of Record, Log-Quelle, Review-Kadenz, Owner. Auf die Frage „Vendor-Zugriff innerhalb von 24h nach Vertragsende?“ öffnen Sie eine Zeile — nicht fünf Slack-Threads. Die Matrix ist die Karte für CISO- oder MSP-Wechsel ohne Audit-Verlust.

Gute Identity misst Time-to-Revoke als SLA. HR setzt Freitag 17:00 terminated — wann zeigt IAM disabled? Monatlich charten. Spitzen korrelieren mit Reorgs und M&A — genau dann erwarten Prüfer Lücken.

Typische B2B-Fehler

Shared Mailboxes als RDP/VPN-Pseudo-User erscheinen in fast jedem Mid-Market-Review. Sie tragen MFA nicht sauber, verwischen Verantwortung und überleben Reorganisationen, weil „alle das Passwort kennen”. Vendor-Konten ohne Vertragsende im IAM sind Standard: der Integrator, der 2021 die Lager-API baute, hat noch Produktions-Datenbank-Read, weil niemand Offboarding nach Projektende besaß.

Lokaler Admin auf Laptops „weil Helpdesk schneller ist” untergräbt das gesamte Device-Trust-Modell. Cloud-IAM-Sprawl — Owner auf Projektebene aus Bequemlichkeit, Service-Account-Keys in Repos — tritt gleichermaßen auf. Jeder Fehler ist behebbar, aber nicht durch Policy-PDF allein. Automatisieren Sie Disable bei HR-Statusänderung, erzwingen Sie PIM für Cloud-Admin, blockieren Sie Legacy Auth und messen Sie, dass Ausnahmen quartalsweise schrumpfen.

Szenario: ISO-Surveillance vs Kunden-Fragebogen

Vergleichen Sie zwei Assurance-Events im selben Monat. ISO-Surveillance stichprobt JML und Privileged Access — evidenz- und prozesslastig. Ein Enterprise-Kundenfragebogen fragt nach SSO, MFA-Erzwingung auf Admin-Rollen und Third-Party-Zugriff auf Produktion. Wenn Ihre Antworten zwischen beiden divergieren, weil Identity-Daten in drei Systemen leben, widersprechen Sie sich unter Zeitdruck.

Die Lösung ist eine einzige Wahrheitsquelle: IdP-Exporte, Ticketing-IDs, Access-Review-Sign-offs. Ein Fintech-Kunde bündelte diese im quartalsweisen „Identity Pack” für internes Audit, Kunden-DD und Regulierungsvorbereitung. Vorbereitungszeit pro Event sank von Wochen auf Tage — nicht durch ein teures GRC-Tool, sondern weil dieselbe Geschichte nicht jedes Mal neu gebaut wurde.

Wie dies mit weiterem Assurance zusammenhängt

Identity-Findings kaskadieren. Schwaches JML invalidiert Pentest-Scope, wenn der Tester ein veraltetes Vendor-Konto nutzt, das entfernt sein sollte. Schwaches MFA auf Admin-Pfaden lässt Red-Team-Erfolg als „sophisticated attack” erscheinen, wenn die Ursache standing privilege ist. Starke Identity verkleinert die Angriffsfläche und macht technische Tests aussagekräftig — Findings spiegeln echte Kontrolllücken, nicht Hygiene-Schulden.

Für NIS2, DORA oder Risk Committee: Identity-Belege vor dem nächsten Scanner. Unsere Praxis Audit und Informationssicherheit mappt Kontrollen auf Ihren IdP und Ticketing — mit ausführbaren Runbooks, nicht Folien.

Mehr zu diesem Thema

NIS2 und Infrastruktur: Was im Runbook stehen muss

NIS2 ist kein Policy-Ordner. Betrieb braucht Runbooks: Incident-Klassifikation, 24h-Frühwarnung, Restore-Nachweis und Lieferanten-Eskalation — auf echten Systemen, nicht „IR-Plan…