Banken · 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, dass 47 Mitarbeiter, darunter zwei Schalterkräfte ohne jede Funktion im Wealth Management, die komplette Kontohistorie eines prominenten Kunden aufrufen konnten. Diesen Zugriff hatte in den vergangenen 18 Monaten niemand genehmigt. Die Bank behob das, bevor die Prüfung begann. Diese Lektion zeigt genau, wie so ein Review abläuft.

Warum das heute mehr Gewicht hat als früher

Banken halten Daten, die finanziell sensibel und bei einem Leak persönlich toxisch sind: Kontostände, Transaktionsmuster, Privatadressen, 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 vorher selbst gestellt haben.

In den USA gehören zu den relevanten Frameworks der Gramm-Leach-Bliley Act (GLBA), der Finanzinstitute verpflichtet, nonpublic personal information (NPI) von Kunden zu schützen, 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 (General Data Protection Regulation), die „geeignete technische und organisatorische MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßnahmen“ vorschreibt und Behörden wie dem britischen ICO (Information Commissioner's Office) die Befugnis gibt, Bußgelder allein wegen unzureichender Zugriffskontrollen zu verhängen, nicht erst wegen eines Datenlecks.

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, üblicherweise ein Data-Governance- oder Information-Security-Team, die Liste aller Nutzer mit Zugriff auf ein System oder einen Datensatz zieht und gegen das 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, kurz IAM)
2. Wer sollte Zugriff haben (basierend auf der Rolle, der „least privilege“-Baseline)
3. Wer hat diesen Zugriff tatsächlich genutzt, und wann (aus Access Logs, nicht nur aus 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 und trotzdem in einer Weise zugreifen, die an diesem Tag nicht zu ihrer Aufgabe passt. Prüfer schauen sich beides an.

Das Review Schritt für Schritt rekonstruiert

Schritt 1: Entitlement-Liste ziehen

Der Reviewer exportiert jeden Nutzer, jede Rolle und jede Berechtigung, die mit dem Kontodatensatz des Kunden verknüpft ist, im Kernbankensystem (z. B. FIS, Temenos oder vergleichbare Plattformen) und in allen nachgelagerten Systemen: CRMCRMCustomer Relationship Management: Software und Strategie, um Kundeninteraktionen über den gesamten Lifecycle zu steuern und zu analysieren.Vollständige Definition ansehen →, Fraud Monitoring, Screen-Pop-Tool des Callcenters, Marketing-Datenbanken.

Ein VIP-Konto erscheint oft in mehr Systemen als ein Standardkonto, weil Private Banking und Relationship Manager eigene CRM-Ebenen haben. Jede Kopie der Daten ist eine eigene Angriffsfläche für Zugriffe.

Schritt 2: Entitlement auf Rolle abbilden

Jede Zugriffsvergabe sollte auf einen dokumentierten fachlichen Grund zurückführbar sein. Eine typische Mapping-Tabelle:

Jeder aus den „Nein“-Zeilen, der auf der Entitlement-Liste auftaucht, ist ein over-permissioned Account, der häufigste Einzelfund 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 Grundursache, die Prüfer finden, häufiger als böswillige Zugriffe.

Ein schneller Check: das Rollenwechsel-Log des HR-Systems gegen das 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 Finding.

Schritt 4: 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 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, ohne Fallnummer, ohne Transaktion
• Wiederholtes „Browsing“ (Öffnen des Datensatzes ohne anschließende Aktion wie Notiz, Transaktion oder Rückruf)

Das ist der Check, der den Fall mit den 47 Personen aufgedeckt hätte: mehrere dieser Schalterkräfte hatten nie eine kundeninitiierte Interaktion zu diesem VIP-Konto protokolliert, hatten es aber wiederholt geöffnet.

Schritt 5: Funktionstrennung überprüfen

Segregation of Duties (SoD) heißt, dass keine einzelne Person zugleich den Zugriff und 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 ein Vier-Augen-Prinzip: jeder Datenexport oder jede Adressänderung an einem markierten prominenten Konto löst einen zweiten Reviewer aus, automatisch protokolliert.

Ein einfacher Logik-Check, den Sie skripten kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen

Governance-Teams automatisieren Schritt 3 und 4 zunehmend mit einfachen Queries. Eine vereinfachte Pseudo-SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen →-Variante:

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 Arbeitszeiten ohne dokumentierte Folgeaktion, genau das Muster, das auf neugierdegetriebenes Schnüffeln statt legitimer Betreuung hindeutet.

Was Prüfer tatsächlich anfordern

Wenn OCC, FDIC oder eine Aufsichtsbehörde eines Bundesstaats (oder in Europa das ICO oder eine nationale Datenschutzbehörde) auftaucht, wird typischerweise angefordert:

• Die Datenklassifizierungsrichtlinie der Bank, die zeigt, dass VIP- oder „high-profile“-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 es 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 setzen zunehmend auf Tests statt auf das Lesen von Richtliniendokumenten. Wenn Ihre Richtlinie quartalsweise Reviews vorsieht, Sie aber keinen Nachweis über das letzte liefern können, ist das ein schlimmeres Finding, als keine Richtlinie zu haben und die Lücke einzugestehen.

Das Zugriffskontroll-Framework des US-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 Findings, nach Häufigkeit sortiert

Basierend auf Mustern, die aus internen Revisionsfunktionen von Banken berichtet werden (Schätzungen, branchenkonsistent, aber nicht auf eine einzelne veröffentlichte Statistik gestützt):

1. Access Creep aus Rollenwechseln (am häufigsten)
2. Gemeinsam genutzte oder generische Login-Credentials, von mehreren Mitarbeitern verwendet, was die Spur „wer war es“ unterbricht
3. Nie entzogener Zugriff von Dienstleistern oder Contractors nach Vertragsende
4. Zu breit gefasste Default-Rollen (z. B. eine Rolle „Filialpersonal“, die systemweite Kontosicht gewährt statt nur die der Heimatfiliale)
5. Neugierdezugriffe auf Konten von Prominenten, Führungskräften oder Kollegen ohne legitimen Grund

Die wichtigsten Punkte

• Ein Entitlement Review vergleicht, wer Zugriff hat, wer Zugriff haben sollte und wer ihn tatsächlich genutzt hat. Alle drei Prüfungen sind nötig; Berechtigungen allein zeigen keinen Missbrauch.
• Access Creep aus Rollenwechseln, nicht böswillige Insider, ist die häufigste Grundursache für over-permissioned Accounts.
• Log-basierte Prüfungen (untypische Uhrzeiten, keine verknüpfte Aktion, kein Fall-Ticket) fangen neugierdegetriebenes Schnüffeln, das eine statische Berechtigungsliste übersieht.
• GLBA (USA) und DSGVODSGVOEU-Verordnung zur Erhebung, Speicherung und Nutzung personenbezogener Daten, mit Bußgeldern, die am weltweiten Umsatz bemessen werden.Vollständige Definition ansehen → (EU) drängen beide auf denselben praktischen Standard: least privilege, dokumentierte fachliche Begründung und nachweisbares periodisches Review.
• Aufsichtsbehörden testen Nachweise, keine Richtliniendokumente. Das letzte Review, seine Findings und den Nachweis der Behebung vorlegen zu können, zählt mehr als eine gut geschriebene Richtlinie, auf die niemand verweisen kann.