+150 XP

Ein Access Audit durchführen, bevor die Aufsicht es tut

# Ein Access Audit durchführen, bevor die Aufsicht es tut

Drei Tage bevor 2023 ein Prüfer bei einer mittelgroßen US-Bank auftauchte, stellte die interne Revision fest: 47 Mitarbeiter, darunter zwei Schalterkräfte ohne jede Funktion im Wealth Management, konnten die vollständige Kontohistorie eines prominenten Kunden aufrufen. Diesen Zugriff hatte in den vorangegangenen 18 Monaten niemand genehmigt. Die Bank korrigierte das, bevor die Prüfung begann. Diese Lektion zeigt genau, wie eine solche Überprüfung abläuft.

Warum das wichtiger ist als früher

Banken halten Daten, die finanziell sensibel und im Fall eines Leaks persönlich toxisch sind: Salden, Transaktionsmuster, Wohnadressen, manchmal gesundheitsbezogene Zahlungen. Aufsichtsbehörden fragen nicht mehr nur „Haben Sie eine Datenschutzrichtlinie?“. Sie fragen „Zeigen Sie mir, wer auf diesen Datensatz zugegriffen hat und warum“, und sie erwarten, dass Sie sich diese Frage zuerst selbst gestellt haben.

In den USA gehören zu den relevanten Rahmenwerken der Gramm-Leach-Bliley Act (GLBA), der Finanzinstitute zum Schutz von nonpublic personal information (NPI) der Kunden verpflichtet, durchgesetzt von der Federal Trade Commission (FTC) und Aufsichtsbehörden wie dem OCC (Office of the Comptroller of the Currency) und der FDIC (Federal Deposit Insurance Corporation). In der EU und in Großbritannien ist es die DSGVO (Datenschutz-Grundverordnung), die „geeignete technische und organisatorische Maßnahmen“ verlangt und Behörden wie dem britischen ICO (Information Commissioner's Office) die Befugnis gibt, wegen unzureichender Zugriffskontrollen Bußgelder zu verhängen, nicht nur wegen Datenschutzverletzungen.

Beide Regime laufen auf dieselbe operative Frage zu: least privilege. Braucht jede Person mit Zugriff diesen Zugriff tatsächlich, jetzt, für ihre Arbeit?

Das Entitlement Review: was es konkret ist

Ein Entitlement Review (auch Access Recertification genannt) ist ein periodisches Audit, bei dem jemand, meist ein Data-Governance- oder Information-Security-Team, die Liste aller Nutzer mit Zugriff auf ein System oder einen Datensatz zieht und mit dem abgleicht, was die Rolle dieser Person erlauben sollte.

Für das Konto eines VIP-Kunden heißt das, drei Dinge zu rekonstruieren:

1. Wer hat Zugriff (die Entitlement-Liste, gezogen aus dem Identity and Access Management System, IAM)

2. Wer sollte Zugriff haben (basierend auf der Rolle, die „least privilege“-Baseline)

3. Wer hat diesen Zugriff tatsächlich genutzt, und wann (aus den Access Logs, nicht nur aus den Berechtigungen)

Berechtigungen und Nutzung sind zwei verschiedene Fragen. Eine Person kann berechtigt sein, ein Konto einzusehen, und es nie anfassen. Eine andere kann korrekt berechtigt sein, greift aber in einer Weise darauf zu, die an diesem Tag nicht zu ihrer Aufgabe passt. Prüfer schauen auf beides.

Das Review rekonstruieren, Schritt für Schritt

Schritt 1: Die Entitlement-Liste ziehen

Der Prüfer exportiert jeden Nutzer, jede Rolle und jede Berechtigung, die mit dem Kontodatensatz des Kunden im Kernbankensystem verknüpft ist (z. B. FIS, Temenos oder vergleichbare Plattformen), und ebenso aus allen nachgelagerten Systemen: CRM, Fraud Monitoring, Screen-Pop-Tool des Callcenters, Marketingdatenbanken.

Ein VIP-Konto erscheint häufig in mehr Systemen als ein Standardkonto, weil Private Banking und Relationship Manager eigene CRM-Stufen haben. Jede Kopie der Daten ist eine eigene Zugriffsfläche.

Schritt 2: Entitlement der Rolle zuordnen

Jede Zugriffsvergabe sollte auf einen dokumentierten fachlichen Grund verweisen. Eine typische Mapping-Tabelle:

| Rolle | Sollte Zugriff haben? | Warum |

|---|---|---|

| Zugewiesener Private Banker | Ja | Direkte Betreuungsbeziehung |

| Schalterkraft (Heimatfiliale des Kunden) | Ja, eingeschränkt | Nur Schaltertransaktionen |

| Schalterkraft (andere Filiale) | Nein | Kein Betreuungsgrund |

| Fraud Analyst | Ja, fallgetrieben | Nur während einer offenen Untersuchung |

| Marketing Analyst | Nein (außer anonymisiert) | Kein Betreuungsgrund |

| IT-Datenbankadministrator | Technisch ja, markiert | Braucht Begründung und Monitoring |

Jeder aus den „Nein“-Zeilen, der auf der Entitlement-Liste auftaucht, ist ein over-permissioned Account, der mit Abstand häufigste Befund in solchen Reviews.

Schritt 3: Auf Access Creep prüfen

Access Creep entsteht, wenn jemand die Rolle wechselt (eine Schalterkraft wird Kreditsachbearbeiter, ein Analyst wechselt das Team), die alten Berechtigungen aber nie entzogen werden. Das ist die häufigste Ursache, die Prüfer finden, häufiger als böswilliger Zugriff.

Eine schnelle Prüfung: Den Rollenwechsel-Log des HR-Systems gegen den Berechtigungsänderungs-Log des IAM-Systems abgleichen. Wenn jemand vor acht Monaten die Stelle gewechselt hat und der alte Systemzugriff noch aktiv ist, ist das ein Befund.

Schritt 4: Die Access Logs stichprobenartig prüfen, nicht nur die Berechtigungsliste

Zugriff zu haben ist nicht der Verstoß; ihn ohne Anlass zu nutzen, schon. Ziehen Sie die tatsächlichen Query Logs (wer hat den Datensatz geöffnet, wann, von welchem Gerät oder aus welcher Filiale) für ein Stichprobenfenster, typischerweise 90 Tage.

Markieren Sie:

  • Zugriffe außerhalb der normalen Arbeitszeiten oder des normalen Standorts des Mitarbeiters
  • Zugriffe ohne verknüpftes Service Ticket, Fallnummer oder Transaktion
  • Wiederholtes „Browsing“ (Öffnen des Datensatzes ohne anschließende Aktion wie Notiz, Transaktion oder Rückruf)

Das ist die Prüfung, die den Fall mit den 47 Personen aufgedeckt hätte: Bei mehreren dieser Schalterkräfte war nie eine kundeninitiierte Interaktion zu diesem VIP-Konto protokolliert, sie hatten es aber wiederholt geöffnet.

Schritt 5: Funktionstrennung verifizieren

Segregation of Duties (SoD) heißt, dass keine einzelne Person sowohl den Zugriff als auch die Befugnis haben sollte, sensible Daten einzusehen und eine Aktion auszuführen, die von unkontrolliertem Missbrauch profitiert, etwa ein Callcenter-Mitarbeiter, der das Konto einsehen und ohne zweiten Genehmiger eine Überweisung anstoßen kann.

Speziell für VIP-Konten ergänzen Banken oft eine Vier-Augen-Regel: Jeder Datenexport oder jede Adressänderung auf einem markierten prominenten Konto löst einen zweiten Prüfer aus, automatisch protokolliert.

Eine einfache Logikprüfung, die Sie skripten können

Governance-Teams automatisieren Schritt 3 und 4 zunehmend mit einfachen Queries. Eine vereinfachte Pseudo-SQL-Version:

sql
SELECT user_id, access_time, action_taken
FROM access_log
WHERE account_id = 'VIP_00123'
  AND access_time NOT BETWEEN shift_start AND shift_end
  AND action_taken IS NULL

Das markiert jeden Zugriff auf dieses Konto außerhalb der normalen Arbeitszeit ohne dokumentierte Folgeaktion, genau das Muster, das auf neugierdegetriebenes Schnüffeln statt legitime Betreuung hinweist.

Wissenscheck

1. Auf welche zentrale operative Frage laufen sowohl GLBA (USA) als auch DSGVO (EU/UK) zu, wenn Aufsichtsbehörden Zugriffskontrollen bewerten?

2. Warum fragen Aufsichtsbehörden zunehmend „Zeigen Sie mir, wer auf diesen Datensatz zugegriffen hat und warum“ statt nur „Haben Sie eine Datenschutzrichtlinie?“

3. Eine Bank stellt fest, dass mehrere Mitarbeiter seit über einem Jahr dauerhaften Zugriff auf ein sensibles Konto haben, ohne dass eine Genehmigung dokumentiert ist. Welchen Bedarf veranschaulicht dieses Szenario am besten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten dazu aus, was ein Entitlement Review (Access Recertification) umfasst.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten dazu aus, warum von Banken gehaltene Daten in Regulierungsrahmen als besonders sensibel behandelt werden.

Wählen Sie alle richtigen Antworten aus.

Was Prüfer tatsächlich verlangen

Wenn OCC, FDIC oder eine bundesstaatliche Aufsicht (oder in Europa der ICO bzw. eine nationale Datenschutzbehörde) auftauchen, fordern sie typischerweise:

  • Die Datenklassifizierungsrichtlinie der Bank, die zeigt, dass VIP- oder „prominente“ Konten als sensibel markiert sind
  • Nachweise über periodische Entitlement Reviews (quartalsweise ist bei Hochrisikosystemen üblich)
  • Logs, die belegen, dass markierte Überberechtigungen behoben wurden, mit Zeitstempel, der zeigt, wie lange das gedauert hat
  • Eine Stichprobe von Access Logs zu einem echten Datensatz, um zu testen, ob das Monitoring der Bank tatsächlich funktioniert und nicht nur auf Papier existiert

Aufsichtsbehörden testen zunehmend lieber, als Richtliniendokumente zu lesen. Wenn Ihre Richtlinie quartalsweise Reviews vorsieht, Sie aber keinen Nachweis für das letzte vorlegen können, ist das ein schlechterer Befund, als keine Richtlinie zu haben und die Lücke zuzugeben.

Das Zugriffskontroll-Rahmenwerk des US-amerikanischen NIST (National Institute of Standards and Technology), zusammengefasst in NIST SP 800-53, ist eine breit genutzte Referenz dafür, wie „angemessene“ Zugriffskontrollen aussehen, auch für Banken, die es nicht direkt anwenden müssen.

Häufige Befunde, nach Häufigkeit sortiert

Basierend auf Mustern, die von internen Revisionen in Banken berichtet werden (Schätzungen, branchenkonsistent, aber nicht an eine einzelne veröffentlichte Statistik gebunden):

1. Access Creep durch Rollenwechsel (am häufigsten)

2. Geteilte oder generische Login-Zugangsdaten, die von mehreren Mitarbeitern genutzt werden und die Nachverfolgbarkeit „wer war es“ zerstören

3. Zugriff von Dienstleistern oder Contractors, der nach Vertragsende nie entzogen wurde

4. Zu weit gefasste Standardrollen (z. B. eine Rolle „Filialpersonal“, die systemweite Kontosicht statt nur die der Heimatfiliale gewährt)

5. Neugierde-Zugriffe auf Konten von Prominenten, Führungskräften oder Kollegen ohne legitimen Grund

Wichtigste Erkenntnisse

  • Ein Entitlement Review vergleicht, wer Zugriff hat, wer Zugriff haben sollte und wer ihn tatsächlich genutzt hat. Alle drei Prüfungen sind notwendig; Berechtigungen allein zeigen keinen Missbrauch.
  • Access Creep durch Rollenwechsel, nicht böswillige Insider, ist die häufigste Ursache für over-permissioned Accounts.
  • Log-basierte Prüfungen (unübliche Zeiten, keine verknüpfte Aktion, kein Fall-Ticket) erkennen neugierdegetriebenes Schnüffeln, das eine statische Berechtigungsliste übersieht.
  • GLBA (USA) und DSGVO (EU) laufen auf denselben praktischen Standard zu: least privilege, dokumentierte fachliche Begründung und nachweisbares periodisches Review.
  • Aufsichtsbehörden prüfen Nachweise, nicht Richtliniendokumente. Das letzte Review, seine Befunde und den Nachweis der Behebung vorlegen zu können, zählt mehr als eine gut geschriebene Richtlinie, auf die niemand verweisen kann.