Benutzerzugriffsprüfungen, die Auditoren akzeptieren (mit Vorlage)

Eine Benutzerzugriffsprüfung ist eine regelmäßige Kontrolle, ob jedes Konto in einem System noch jemandem gehört, der es braucht — auf der Berechtigungsstufe, die er braucht. Sie gehört zu den am häufigsten angeforderten Audit-Nachweisen — und zu den am häufigsten abgelehnten, weil Teams einen Export der Benutzerliste einreichen, während der Auditor nach einem Entscheidungsprotokoll gefragt hat.

Dieser Unterschied ist wichtiger als jedes andere Detail in diesem Artikel: ein Export zeigt einen Zustand; eine Prüfung zeigt Urteilsvermögen. Eine Tabelle mit allen, die im März Zugriff hatten, beweist nur, dass du deine eigenen Systeme abfragen kannst. Was der Auditor testet, ist, ob ein namentlich benannter Mensch sich jedes dieser Konten angesehen und etwas dazu entschieden hat.

Was die Frameworks tatsächlich verlangen

Zugriffsprüfungen liegen im Schnittpunkt zweier Framework-Anforderungen — deshalb kommen sie in fast jedem Audit vor:

• SOC 2 Common Criteria CC6 deckt den logischen Zugriff ab: wie Zugriff registriert, autorisiert, geändert und entzogen wird. Prüfungen sind der Weg zu zeigen, dass die Autorisierung über die Zeit korrekt bleibt und nicht nur im Moment der Vergabe gestimmt hat. Siehe die Common Criteria erklärt.
• ISO 27001 Anhang A.5.18 (Zugangsrechte) deckt Vergabe, Überprüfung und Entzug von Zugangsrechten ab. A.8.2 (privilegierte Zugangsrechte) legt die Latte speziell für administrative Konten höher, und A.5.15–A.5.17 decken die umliegenden Praktiken zu Zugangskontrolle, Identität und Authentifizierung ab. Der vollständige Leitfaden zu Anhang A zeigt, wie das zusammenspielt.

Keines der beiden Frameworks schreibt eine Frequenz vor. Beide erwarten, dass du eine festlegst, sie gegen das Risiko begründest — und sie dann auch wirklich einhältst.

Schritt 1: Definiere die Grundgesamtheit — das wird als Erstes geprüft

Bevor ein Auditor sich eine einzige Entscheidung ansieht, testet er, ob deine Liste vollständig war. Das ist der Schritt, den Teams überspringen, und es ist der Schritt, der alles Nachgelagerte entwertet: Wenn die Grundgesamtheit falsch ist, lässt sich keine der darauf getroffenen Entscheidungen verifizieren.

Vollständigkeit heißt zweierlei. Erstens: Du hast jedes Konto im System geprüft, nicht nur die, an die du dich erinnert hast — inklusive Dienstkonten, Konten externer Dienstleister, geteilter Konten und Konten von Leuten, die längst weg sind. Zweitens: Du kannst zeigen, woher die Liste stammt — ein systemgenerierter Export mit sichtbarer Quelle und Zeitstempel, keine handgepflegte Tabelle.

Praktischer Weg dorthin: Exportiere die Benutzerliste direkt aus jedem System im Prüfungsumfang, halte das Exportdatum und die Person fest, die den Export gezogen hat, und gleiche die Gesamtzahl mit deiner HR-Liste und deinem Asset- und Systeminventar ab. Jedes Konto, das im System auftaucht, aber nicht in HR, ist entweder ein Dienstkonto, das du dokumentieren musst, oder eine Feststellung, die du beheben musst.

Schritt 2: Wähle die Frequenz nach Risiko, nicht nach Gewohnheit

Die Frequenz sollte dem Schadensradius des Zugriffs folgen. Ein belastbares Muster für ein kleines Team:

• Privilegierte und administrative Zugriffe — quartalsweise. Produktionsinfrastruktur, Cloud-Root- und Admin-Rollen, Datenbankadministration, alles, was weiteren Zugriff vergeben kann.
• Standardzugriffe auf Systeme mit Kundendaten — halbjährlich oder jährlich, je nachdem, wie sensibel die Daten sind und wie viel sich bei deinem Personalbestand bewegt.
• Ereignisgesteuert, zusätzlich zum Kalender — eine Prüfung, ausgelöst durch einen Rollenwechsel, eine Team-Reorganisation oder einen Austritt, statt auf den nächsten geplanten Zyklus zu warten.

Schreib die Frequenz in deine Zugriffskontrollrichtlinie und halte sie dann ein. Ein Auditor, der eine Richtlinie mit dem Versprechen quartalsweiser Prüfungen gegen den Nachweis von zwei Prüfungen im Jahr hält, wird eine Feststellung erheben — und die Feststellung richtet sich gegen die verfehlte Zusage, nicht gegen die Frequenz selbst. Eine Richtlinie, die du tatsächlich befolgst, schlägt eine ambitionierte, die du nicht einhältst.

Schritt 3: Sorge dafür, dass der Prüfer nicht sich selbst prüft

Unabhängigkeit ist der zweithäufigste Ablehnungsgrund. Wer ein Konto prüft, sollte nicht die Person sein, die es hält — und idealerweise auch nicht die, die Zugriffe vergibt.

Für die meisten kleinen Unternehmen ist das praktikable Modell: Der Systemverantwortliche oder die Führungskraft des Kontoinhabers führt die Prüfung durch, und jemand anderes — ein Gründer, der Security-Verantwortliche, wer auch immer das ISMS verantwortet — zeichnet die Prüfung als Ganzes ab. Damit stehen zwei Namen auf dem Nachweis, und genau danach sucht der Auditor.

Der unangenehme Fall ist das Zwei-Personen-Startup, in dem dem CTO jedes System gehört und er sämtliche Admin-Zugangsdaten hält. Die ehrliche Antwort ist nicht, so zu tun, als wäre es anders: Lass den anderen Gründer den Zugriff des CTO prüfen, dokumentiere, dass die Funktionstrennung durch die Teamgröße begrenzt ist, und halte die kompensierenden Kontrollen fest (Logging, Alarmierung bei Berechtigungsänderungen). Auditoren akzeptieren dokumentierte, begründete Einschränkungen weit bereitwilliger als eine fingierte Trennung.

Schritt 4: Halte pro Konto eine Entscheidung fest

Das ist der Teil, der aus einem Export eine Prüfung macht. Jede Zeile der Grundgesamtheit braucht ein explizites Ergebnis — und „keine Maßnahme“ ist ein Ergebnis, solange ein Mensch es gewählt hat.

Die letzten beiden Spalten sind die, die Teams leer lassen — und genau die, die Auditoren am härtesten prüfen.

Schritt 5: Schließe den Kreis — genehmigt ist nicht entfernt

Eine Prüfung, die zwölf Konten zum Entziehen identifiziert und bei keinem davon den Zugriff entzieht, ist schlimmer als gar keine Prüfung: Sie dokumentiert, dass du von einem Problem wusstest und es nicht behoben hast. Auditoren ziehen routinemäßig Stichproben der entzogenen Zugriffe aus deiner Prüfung und schauen im Livesystem nach, ob das Konto wirklich weg ist.

Das Nachweispaket für jeden Zyklus braucht deshalb drei Artefakte, nicht eins:

1. Den Export der Grundgesamtheit, mit Quelle und Datum.
2. Das ausgefüllte Prüfprotokoll, mit Entscheidungen je Konto, Namen der Prüfer und Datumsangaben.
3. Den Beleg der Umsetzung — Tickets, Change-Records oder ein nachgelagerter Export, der zeigt, dass die entzogenen Konten tatsächlich weg sind.

Dieses dritte Artefakt macht aus einer Behauptung einen Nachweis. Wie das ins größere Nachweisbild passt, zeigt was Auditoren wirklich als Nachweis wollen.

Prüfungen fangen ab, was das Offboarding verpasst hat

Es hilft, sich klarzumachen, welche Aufgabe die Prüfung erfüllt. Offboarding ist deine präventive Kontrolle: Wenn jemand geht, geht der Zugriff am selben Tag mit. Die Zugriffsprüfung ist die detektivische Kontrolle, die die Fälle einfängt, in denen das Offboarding nicht gegriffen hat — der externe Dienstleister, dessen Auftrag still ausgelaufen ist, das SaaS-Tool, das nicht auf der Offboarding-Checkliste stand, das Dienstkonto, das für eine Migration angelegt wurde, die vor einem Jahr fertig war.

Wenn deine Zugriffsprüfungen regelmäßig ausgeschiedene Mitarbeitende zutage fördern, geht es bei der Feststellung eigentlich nicht um die Prüfung. Es geht um den Offboarding-Prozess, und dort gehört die Korrektur hin.

Die Anti-Patterns

• Den Export als Prüfung einreichen. Zustand statt Urteil. Der mit Abstand häufigste Ablehnungsgrund.
• Nur die Systeme prüfen, die sich leicht exportieren lassen. Auditoren fragen nach den Systemen im Prüfungsumfang — auch nach den unbequemen.
• Alle Zeilen mit einem Klick pauschal genehmigen. Eine Prüfung, in der in einem wachsenden Unternehmen 100 % der Konten beibehalten wurden, lädt zu genauerem Hinsehen ein — und wenn sich nie etwas ändert, prüft der Prüfer nicht.
• Dienst- und Sammelkonten vergessen. Sie tragen die meisten Berechtigungen und die geringste Verantwortlichkeit.
• Keine Spur der Umsetzung hinterlassen. Die Entscheidung ohne die Durchführung ist eine offene Feststellung.

Das Fazit

Zugriffsprüfungen sind nicht schwer, aber sie sind genau: eine vollständige Grundgesamtheit aus einem Systemexport, ein Prüfer, der den Zugriff nicht selbst hält, eine explizite Entscheidung zu jedem Konto und der Beleg, dass die Zugriffsentzüge tatsächlich umgesetzt wurden. Mach das viermal im Jahr für deine privilegierten Konten, und die Nachweisanforderung hört auf, ein Feuerwehreinsatz zu sein.

Weiter: die Monitoring-Checkliste fürs ganze Jahr dafür, wo Prüfungen im größeren Kalender sitzen, SOC 2 Nachweiserhebung für den Rest der Anforderungsliste, oder sieh dir an, wie die automatisierte Nachweiserfassung Grundgesamtheit und Beleg zusammenhält.