Es beginnt nicht mit einem Hack.
Es beginnt an einem Dienstagmorgen. Ein externer IT-Dienstleister meldet sich an, um ein Ticket zu bearbeiten. Die Verbindung steht. Der Account ist bekannt. Die Systeme akzeptieren die Identität ohne Zögern.
Nichts deutet darauf hin, dass dieser Zugriff anders ist als tausend andere zuvor.
So beginnen die meisten sicherheitsrelevanten Vorfälle im Finanzsektor nicht mit Alarm, sondern mit Normalität.
Unter der Oberfläche verschiebt sich etwas
Banken und Versicherungen gelten als reif organisierte Institutionen. Prozesse sind dokumentiert. Zugriffe formal genehmigt. Kontrollen sind vorhanden. Und doch hat sich die Realität ihrer IT-Landschaft in den letzten Jahren leise, aber grundlegend verändert.
Wertschöpfung liegt heute nicht mehr nur im eigenen Haus. Sie liegt bei Core-Banking-Anbietern, KYC-Providern, Inkassodienstleistern, Softwarehäusern, Versicherungsbrokern. Jede Auslagerung bringt Effizienz. Jede bringt Zugriff.
Diese Zugriffe entstehen selten aus einem klaren Modell heraus. Sie entstehen aus Projekten. Aus Deadlines. Aus pragmatischen Entscheidungen. Ein VPN-Zugang hier. Ein Service-Account dort. Ein API-Key, der „vorübergehend“ benötigt wird.
Vorübergehend wird permanent.
Identitäten bleiben bestehen, auch wenn der Zweck längst erfüllt ist. Vertrauen wird implizit. Kontrolle verteilt sich über Teams, Tools und Verantwortlichkeiten hinweg.
Die Eskalation ist nicht spektakulär. Sie ist schleichend.
Der erste Fehler tritt in der Bank selbst fast nie auf. Er passiert beim Partner. Ein Phishing-Mail bei einem kleinen IT-Dienstleister. Malware auf dem Laptop eines externen Entwicklers. Ein Credential, das in einem Partnerportal wiederverwendet wurde. Ein API-Key, der in einer CI-Pipeline oder in einem Repository auftaucht.
Der Angreifer erhält keinen privilegierten Zugang. Er erhält etwas Gefährlicheres. Eine gültige Identität.
Für die Sicherheitsarchitektur ist alles korrekt. Der Login ist erfolgreich. MFA greift oder ist ausgenommen, weil es sonst den Betrieb behindert hätte. Es gibt keine Signatur, keinen Exploit, kein auffälliges Verhalten.
Zero Trust existiert konzeptionell – aber nicht im Zugriffsmoment.
Bewegung findet nicht nach oben statt. Sondern zur Seite.
Was nun folgt, ist kein klassisches Eskalationsszenario. Der Angreifer versucht nicht, Root-Rechte zu erlangen. Er sucht keinen spektakulären Durchbruch.
Er bewegt sich horizontal.
Partner-Accounts sind selten präzise geschnitten. Sie haben mehr Rechte als nötig, weil sie historisch gewachsen sind. Sie funktionieren in mehreren Umgebungen, weil es praktisch war. Test, Pre-Prod und Produktion sind oft nicht sauber getrennt. Menschliche Accounts und Service-Accounts teilen sich Identitäten oder Berechtigungen.
Die gleiche Identität existiert in mehreren Systemen. Nicht integriert. Nicht zentral sichtbar. Nicht kontinuierlich bewertet.
Der Angreifer nutzt genau diese Übergänge. Von Anwendung zu Anwendung. Von Umgebung zu Umgebung. Von System zu System. Jeder Zugriff ist für sich genommen legitim. In Summe entsteht ein Bewegungsraum, den niemand explizit genehmigt hat.
Das ist der Moment, in dem der Schaden entsteht – lange bevor jemand ihn bemerkt.
Der Impact ist grösser, als viele Organisationen annehmen
Manchmal ist der Schaden offensichtlich. Kundendaten werden abgefragt und abgeführt. Persönliche Informationen. Kontodaten. Vertragsdetails. Die Systeme liefern sie korrekt aus, weil der Zugriff formell erlaubt war.
Dann greifen Meldepflichten. DSGVO. FINMA. BaFin. Der Reputationsschaden beginnt nicht mit der Veröffentlichung, sondern mit der internen Erkenntnis, dass der Zugriff nicht unautorisiert war, sondern schlecht kontrolliert.
Manchmal ist der Schaden subtiler. Transaktionsparameter werden angepasst. Limits verändert. Fraud-Regeln modifiziert. Wochen später lässt sich nicht mehr sauber rekonstruieren, ob es sich um einen Fehler oder um Manipulation handelte.
Und manchmal passiert zunächst scheinbar nichts. Backdoors werden platziert. Logging reduziert. Zugänge vorbereitet. Der eigentliche Angriff erfolgt Monate später – mit deutlich grösserem Effekt und massiv höheren Incident-Response-Kosten.
Der teuerste Schaden ist selten der technische. Es ist der Verlust an Klarheit.
Warum klassische Security hier nicht greift
Der Angriff ist weder netzwerkgetrieben noch malwarebasiert. Er ist identitätsgetrieben.
Login korrekt. MFA erfüllt. Keine Policy verletzt. Kein Alarm ausgelöst.
Moderne Security-Stacks sind hervorragend darin, bösartige Aktivitäten zu erkennen. Sie sind deutlich schlechter darin, legitime Identitäten im Kern ihrer Geschäftsprozesse zu hinterfragen.
Identität wird geprüft. Kontext bleibt unbeachtet.
Warum vorhandene IAM-Controls nicht ausreichen
Nach einem Vorfall fällt ein Satz fast immer.
„Aber wir haben doch IAM.“
Oft folgt eine Aufzählung. IAM. IGA. PAM.
Das ist meist korrekt.
Das Problem ist nicht die Abwesenheit von Werkzeugen. Es ist die falsche Zuordnung von Verantwortung über Identitätsdomänen hinweg.
Klassisches Workforce-IAM ist für interne Mitarbeitende ausgelegt. Für HR-getriebene Lebenszyklen. Für stabile Rollenmodelle. Es funktioniert hervorragend – solange Identitäten Teil der Organisation sind.
Externe Partner passen nicht in dieses Modell. Sie sind nicht HR-geführt. Ihre Zugriffe sind projektbasiert, zeitlich begrenzt und zweckgebunden. Das System verwaltet sie dennoch wie interne Nutzer – und verliert genau dort an Schärfe.
Identity Governance ergänzt diese Welt um Kontrolle. Rezertifizierungen schaffen Nachvollziehbarkeit. Audit-Trails liefern Antworten auf die Frage, wer wann welchen Zugriff hatte.
Was IGA nicht leistet, ist die kontinuierliche Risikobewertung. Governance ist periodisch. Angriffe sind es nicht. Eine kompromittierte Identität bleibt gültig bis zur nächsten Kampagne.
Privileged Access Management schützt die Extreme. Root. Admin. Break-Glass. Die Kronjuwelen. Es ist dort hochwirksam, wo Privilegien klar definiert sind.
Viele Third-Party-Zugriffe fallen darunter nicht. Sie sind funktional privilegiert, aber nicht als solche klassifiziert. APIs, Service-Accounts und B2B-Zugriffe bewegen sich unterhalb der PAM-Schwelle – und oberhalb der Aufmerksamkeit.
So entsteht eine Lücke, die niemand bewusst öffnet.
Nicht, weil etwas fehlt.
Sondern weil externe Identitäten zwischen den Systemen liegen.
Und damit oft auch zwischen den Verantwortlichkeiten.
Was fehlt, ist eine Identitätsdomäne, die externe Zugriffe eigenständig modelliert, kontextualisiert und kontinuierlich bewertet.
Dann kommen die Fragen
Nach dem Incident sitzen keine Angreifer im Raum. Sondern Prüfer. Juristen. Aufsichtsbehörden.
Warum hatte dieser Partner Zugriff?
Warum war er nicht zeitlich begrenzt?
Warum gab es kein sauberes Offboarding?
Wer hat das genehmigt?
Wo ist die Dokumentation?
Und schliesslich die Frage, die niemand delegieren kann.
Wer trägt die Verantwortung?
Nicht der Partner.
Die Bank.
Die Sprache der Aufsicht ist nüchtern
Sie spricht nicht von Advanced Threats. Sie spricht von unkontrolliertem Drittzugriff. Von Identity Sprawl. Von fehlendem Least Privilege. Von mangelnder kontinuierlicher Zugriffsbewertung. Von unzureichender Identity Governance.
Es sind keine spektakulären Befunde. Aber sie landen regelmässig in der Kategorie High Risk.
Die Frage, die bleibt
Wenn ein externer Partner morgen kompromittiert wird –
und jeder einzelne Zugriff technisch korrekt aussieht –
würde eure Organisation erkennen,
dass sich gerade jemand horizontal durch eure Identitätslandschaft bewegt?
Oder erst, wenn der Prüfer fragt –
und eine Antwort erwartet.
