In einer Bank beginnt jede Operation, von der Anmeldung eines Kunden bis zur Limitänderung durch einen Mitarbeiter, mit einer Frage: Wer ist wirklich auf der anderen Seite, und was darf diese Person. Deshalb ist Identität und Authentifizierung längst keine „Login”-Schicht mehr, sondern das Fundament, auf dem die übrige Sicherheit ruht. Für einen Sicherheitsverantwortlichen heißt das: IAM in der Bank ist ein Vorstandsthema, nicht nur ein IT-Thema.
Nach unserer Erfahrung liegt die Schwierigkeit nicht darin, ein IAM-Werkzeug aufzusetzen, sondern es in Dutzende bestehender Banksysteme einzubinden, ohne Services zu brechen oder Lücken im Audit-Trail zu hinterlassen. Deshalb behandeln wir solche Projekte als Entwicklung kritischer Software, mit einem Team, das sowohl Security als auch die Realität von Bankarchitekturen versteht. Genau ein solches Team entwickelt seit 2017 die Sicherheitssysteme und digitalen Plattformen einer globalen Privatbank.
Warum sind Identität und Authentifizierung der Kern der Banksicherheit?
Weil fast jeder ernste Vorfall mit einer gestohlenen Identität beginnt und nicht mit gebrochener Verschlüsselung. Sobald jemand einen Kunden oder Mitarbeiter vortäuscht, beginnen die übrigen Kontrollen zu seinen Gunsten zu arbeiten. Eine gut entworfene Identitätsschicht dreht das um: Sie engt ein, was ein Angreifer tun kann, selbst wenn er ein einzelnes Konto übernommen hat.
Für eine Bank steht dabei nicht nur finanzieller Verlust auf dem Spiel, sondern auch das Vertrauen der Kunden und die Rechenschaft gegenüber der Aufsicht. Deshalb behandeln wir Identität als eine Schicht, die zugleich dicht, in einer Prüfung nachvollziehbar und im Alltag erträglich sein muss. Rutscht eine dieser drei Dimensionen ab, leiden früher oder später auch die beiden anderen.
Was ist Identitäts- und Zugriffsverwaltung (IAM) in einer Bank?
Einfach gesagt: IAM beantwortet, wer worauf und unter welchen Bedingungen zugreifen darf, über den gesamten Lebenszyklus eines Kontos. Es ist kein einzelnes Werkzeug, sondern ein zusammenhängender Satz aus Prozessen und Mechanismen. In der Praxis umfasst es mehrere Bereiche:
- Kundenidentität (CIAM), also Registrierung, Anmeldung und Kontowiederherstellung in den digitalen Kanälen,
- Identität von Mitarbeitern und Partnern, vom ersten Arbeitstag bis zum Entzug der Zugriffe beim Austritt,
- Governance von Zugriffen und Rollen, die festlegt, was eine Person in einem System tatsächlich tun darf,
- technische Identitäten, also Service-Accounts, APIs und Integrationen - häufig die am meisten vernachlässigten.
Wir verbinden diese Bereiche so, dass daraus eine zusammenhängende Zugriffsgeschichte wird und nicht ein Satz getrennter Login-Inseln in jedem System.
Was ist starke Authentifizierung (SCA, MFA), und was verlangt PSD2?
Starke Authentifizierung beruht auf der Kombination von mindestens zwei unabhängigen Faktoren aus verschiedenen Kategorien: etwas, das der Nutzer weiß (ein Passwort, eine PIN), etwas, das er besitzt (ein Telefon, ein Token), und etwas, das er ist (Biometrie). Genau das steckt hinter den Kürzeln MFA (Multi-Faktor-Authentifizierung) und SCA (starke Kundenauthentifizierung).
In Europa ist das längst keine Frage des guten Willens mehr. Die PSD2-Richtlinie verpflichtet Banken zur Anwendung von SCA, wenn Kunden sich im Online-Banking anmelden und wenn sie Zahlungen auslösen, mit einigen Ausnahmen für Transaktionen mit niedrigem Risiko. Wir entwerfen diese Mechanismen so, dass sie die Anforderung erfüllen, ohne jede Handlung in einen Hindernislauf zu verwandeln. Entscheidend ist hier die dynamische Verknüpfung der Authentifizierung mit einem konkreten Betrag und Zahlungsempfänger, denn das erschwert eine Manipulation der Transaktion wirklich.
Wie steuern Sie Zugriffe und Berechtigungen in einer Bank?
Hier versteckt sich meist das größte Risiko, denn Berechtigungen neigen dazu, sich mit der Zeit „anzusammeln”. Ein Mitarbeiter wechselt das Team, übernimmt neue Rollen, und die alten bleiben bestehen. Wir räumen das auf, indem wir Zugriffe auf klare Grundsätze stellen:
- so wenig Rechte wie nötig statt Zugriffe „für alle Fälle”,
- Rollen und Gruppen, die an eine Position gebunden sind und nicht an eine einzelne Person,
- Funktionstrennung, damit niemand allein einen ganzen sensiblen Prozess kontrolliert,
- regelmäßige Überprüfung und Rezertifizierung der Zugriffe, mit automatischem Ablauf dessen, was ungenutzt bleibt.
Darüber hinaus führen wir eine strengere Kontrolle für privilegierte Konten ein (Administratoren, Service-Accounts), denn sie sind das wertvollste Ziel. Gut strukturierte Berechtigungen bedeuten, dass selbst ein erfolgreicher Einbruch in ein Konto dem Angreifer nicht die ganze Bank öffnet.
Wie binden Sie IAM an die bestehenden Systeme einer Bank an?
Das ist meist der schwierigste und am wenigsten sichtbare Teil des Projekts. Eine Bank startet nicht bei null; sie hat Core-Systeme, Online-Banking, mobile Apps und Dutzende interner Anwendungen, oft mit eigenen Login-Mechanismen. Unser Ziel ist eine einzige, zusammenhängende Quelle der Wahrheit über Identität, an die sich diese Systeme anschließen.
Wir integrieren sie über moderne Standards wie OAuth 2.0, OpenID Connect und SAML und führen Single Sign-on (SSO) dort ein, wo es sinnvoll ist. Ältere Anwendungen, die diese Sprache nicht sprechen, umhüllen wir mit Zwischenschichten, statt sie sofort neu zu schreiben. So bleibt die Migration schrittweise und umkehrbar statt ein riskanter Komplettumschwung an einem Wochenende.
Wie sichern Sie Compliance und Audit im Identitätsbereich?
Für eine Bank reicht es nicht, sicher zu sein; sie muss es auch belegen können. Deshalb planen wir die Prüfbarkeit von Anfang an ein, statt die Protokollierung von Ereignissen am Ende anzuschrauben. In der Praxis bedeutet das einen vollständigen, unbestreitbaren Audit-Trail darüber, wer wann worauf zugegriffen hat und wer diesen Zugriff erteilt hat.
Wir bilden die Mechanismen auf konkrete Anforderungen ab, von PSD2 und aufsichtsrechtlichen Leitlinien bis zu den internen Richtlinien der Bank, sodass die Antwort in einer Prüfung eine Frage eines Berichtslaufs ist und nicht wochenlangen Grabens in Logs. Bei personenbezogenen Daten halten wir uns an die Grundsätze der Datenminimierung und Rechenschaftspflicht, denn in einer Bank gehören Identität und Datenschutz immer zusammen.
Welche Kompetenzen stellen wir für ein IAM-Projekt bereit?
Wir stellen das Team rund um die konkrete Phase und Architektur zusammen, nicht „auf Vorrat”. In Identitäts- und Sicherheitsprojekten besetzen wir am häufigsten Rollen wie:
- einen Security- / IAM-Architekten, der das Identitäts- und Berechtigungsmodell definiert,
- Integrations-Engineers, die IAM mit Core-Systemen und digitalen Kanälen verbinden,
- Backend-Entwickler, die Authentifizierungsdienste, APIs und SCA-Mechanismen bauen,
- DevOps- und Security-Spezialisten, die Deployments, Härtung und Monitoring verantworten.
Ein solches Team kann den gesamten Bereich übernehmen, vom Entwurf bis zur Wartung, oder das eigene Team der Bank genau dort verstärken, wo Hände oder Expertise fehlen.
Wie machen wir das bei RITS?
Wir tun es als Nearshore-Partner aus Polen, mit echter Erfahrung an den kritischen Systemen einer Bank. Für eine führende globale Institution im Private Banking und Asset Management entwickeln wir seit 2017 ihre Sicherheitssysteme sowie internen Systeme und digitalen Plattformen, und unser eingesetztes Team ist auf nahezu 90 Spezialisten gewachsen. Identitäts- und Zugriffsverwaltung sowie starke Authentifizierung behandeln wir als einen Bereich innerhalb dieser Security-Kompetenz und nicht als einzelnes Werkzeug.
In diesen Projekten stützen wir uns auf einige Dinge: Wir prüfen die Kompetenzen vor dem Start, wir arbeiten in einer nahen Zeitzone, sodass wir ohne langen Anlauf an Code-Reviews und Terminen teilnehmen, und wir bauen vom ersten Tag an mit Blick auf das Audit. Meist tun wir das als Individualsoftware, gebaut von unserem Team, und dort, wo die Bank Kompetenzen schnell aufstocken muss, als Team-Verstärkung.
Wo beginnen Sie mit IAM und starker Authentifizierung?
Beginnen Sie mit einer ehrlichen Bestandsaufnahme: welche Identitäten, Systeme und Login-Verfahren Sie heute haben und wo die größten Lücken gegenüber PSD2 und Ihren internen Richtlinien liegen. Wählen Sie dann einen Kanal oder einen Prozess mit hohem Risiko (zum Beispiel Anmeldung und Zahlungen im Online-Banking) und weisen Sie dort das Zielmodell nach, statt alles auf einmal umzubauen. Das legt Architektur, Standards und Rollen fest, die Sie brauchen. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie führen IAM und starke Authentifizierung in Ihrer Bank ein oder räumen sie auf? Sprechen wir darüber - wir finden ein Team und eine Architektur passend zu Ihrer Umgebung und Ihren regulatorischen Anforderungen.
IAM und starke Authentifizierung mit uns in Ihrer Bank einführen