Im März 2026 haben wir auf den DSAG Security-Tagen einen Vortrag gehalten, der eine Frage in den Mittelpunkt gestellt hat, die viele SAP-Verantwortliche noch immer unterschätzen: Was passiert eigentlich, wenn ein Admin-Konto in den SAP Cloud Identity Services (CIS) kompromittiert wird? Der folgende Artikel fasst die zentralen Erkenntnisse zusammen – und zeigt, welche konkreten Maßnahmen Unternehmen jetzt ergreifen sollten.

Die unterschätzte Angriffsfläche: Admin-Konten in der Cloud

Die SAP Cloud Identity Services bilden das Herzstück jeder modernen SAP-Cloud-Landschaft Sie steuern die Authentifizierung, verwalten Benutzeridentitäten und koordinieren die Provisionierung in nachgelagerte Systeme. Dazu zählen unter anderem SAP SuccessFactors, SAP BTP und SAP Fieldglass. Genau diese zentrale Stellung macht CIS-Administratorkonten zu einem äußerst attraktiven Ziel für Angreifer.

Statistiken aus der Praxis untermauern die Dringlichkeit: Rund 80 Prozent aller Datenpannen beginnen mit gestohlenen oder kompromittierten Zugangsdaten, und 40 Prozent dieser Fälle betreffen privilegierte Konten wie Domain-Admins oder Datenbankbenutzer (Quelle: Security Today, 29.03.2026). Ein einziges kompromittiertes Administratorkonto kann reichen, um weitreichenden Schaden anzurichten. Das ist keine abstrakte Bedrohung. Der Angriff auf Okta im Jahr 2023 hat eindrücklich gezeigt, wie ein kompromittiertes Admin-Konto genutzt werden kann, um einen bösartigen Identity Provider einzuschleusen. Anschließend konnten sich die Angreifer in sämtlichen angebundenen Applikationen als beliebige Benutzer einloggen, ohne eine weitere Authentifizierung durchlaufen zu müssen.

Das Angriffsszenario: Vom Phishing-Link zum Cloud-Admin

Um die Bedrohungslage greifbar zu machen, haben wir auf den DSAG Security-Tagen ein exemplarisches Angriffsszenario anhand des MITRE ATT&CK-Frameworks modelliert. Die Angriffskette verläuft dabei erschreckend geradlinig:

Schritt 1 – Initial Access (T1566.002 – Spearphishing Link): Der Angreifer versendet eine gezielte Phishing-Mail an einen CIS-Administrator. Über eine AiTM-Technik (Adversary-in-the-Middle, z. B. mit Evilginx) wird eine täuschend echte SAP-Loginseite präsentiert.

Schritt 2 – Credential Access (T1539 – Steal Web Session Cookie): Selbst wenn der Administrator eine MFA-Methode nutzt, fängt der AiTM-Proxy nach der erfolgreichen Authentifizierung den Session-Token ab. Die MFA ist damit ausgehebelt, ohne dass der Nutzer es merkt.

Schritt 3 – Defense Evasion (T1078.004 – Valid Accounts: Cloud Accounts): Mit dem gestohlenen Session-Token meldet sich der Angreifer in der CIS-Administrationskonsole an. Aus Sicht des Systems handelt es sich dabei um eine vollkommen legitime Sitzung, die sich nicht von regulären Administratoraktivitäten unterscheiden lässt.

Schritt 4 – Privilege Escalation (T1098.003 – Account Manipulation: Additional Roles): Nun weist der Angreifer einem eigenen, zuvor unauffällig angelegten Konto sämtliche Administratorberechtigungen zu. Dies geschieht ohne Genehmigungsworkflow und ohne Anwendung eines Vier-Augen-Prinzips.

Schritt 5 – Persistence (T1484 – Tenant Policy Modification): Abschließend werden Transformationsregeln oder Trust-Konfigurationen so angepasst, dass ein dauerhafter, von außen schwer erkennbarer Zugang besteht. Von hier aus sind alle angebundenen Subsysteme erreichbar.

Gegenmaßnahmen: Drei Handlungsfelder, die wirklich schützen

Die gute Nachricht: Dieser Angriffspfad lässt sich an mehreren Stellen wirksam unterbrechen. Wir empfehlen drei aufeinander aufbauende Handlungsfelder.

1. Authentifizierung härten

Der effektivste Schutz gegen AiTM-Angriffe und Session-Cookie-Diebstahl ist der Einsatz phishing-resistenter MFA-Methoden. Ergänzend dazu sollten dedizierte Authentifizierungsrichtlinien für Administratoren eingerichtet werden. Dazu gehört beispielsweise die Beschränkung des Zugriffs auf definierte IP-Bereiche. Die CIS bieten hierfür granulare Risk-based Authentication Policies, die auf Benutzertyp, Gruppe und IP-Bereich abgestimmt werden können. Session-Timeouts sollten für Adminkonten deutlich kürzer konfiguriert sein als für reguläre Nutzer.

2. Privilegien strukturieren

Viele CIS-Installationen arbeiten noch immer mit den voreingestellten ALL-Berechtigungen für Administratoren. Das ist aus Sicherheitsperspektive grob fahrlässig  und vollständig vermeidbar. Die Authorization Policies in den CIS ermöglichen eine feingranulare Steuerung, welcher Administrator welche Operationen an welchen Benutzerkategorien durchführen darf.

Bewährt hat sich dabei ein klassifikationsbasierter Gruppenansatz: CIS-Gruppen werden nach ihrem Downstream-Risiko kategorisiert und mit einer verbindlichen Namenskonvention versehen. Beispielsweise werden Gruppen mit Global-Account-Berechtigungen mit dem Präfix „priv-ga-“, Subaccount-kritische Gruppen mit „priv-sub-“ und Gruppen ohne privilegiertes Mapping mit „std-*“ gekennzeichnet. Diese Klassifikation ist Voraussetzung dafür, Segregation of Duties (SoD) in den Authorization Policies sauber umsetzen zu können: Wer Gruppen anlegen darf, sollte nicht gleichzeitig Benutzer zuweisen dürfen.

Ein weiterer Baustein ist das Prinzip der zweistufigen CIS-Landschaft: ein dedizierter Entwicklungstenant für alle Entwicklungs- und Testsysteme sowie ein strikt getrennter Produktivtenant. Externe Dienstleister, Berater und Entwickler erhalten ausschließlich Zugang zum Entwicklungstenant. Der Produktivtenant bleibt für diesen Personenkreis vollständig gesperrt. Konfigurationen, Policies und Anpassungen werden zunächst im Entwicklungstenant erarbeitet, getestet und erst nach Freigabe in die Produktivumgebung importiert. Dieses Vorgehen reduziert die Angriffsfläche auf dem Produktivsystem erheblich und verhindert, dass externe Zugänge, unabhängig davon, ob sie kompromittiert oder missbraucht wurden, direkten Einfluss auf laufende Geschäftsprozesse nehmen können.

3. Anomalien erkennen

Selbst die beste Präventivstrategie ist kein Ersatz für eine funktionierende Erkennung. Zwei Maßnahmen sind hier besonders wirksam:

Eine regelmäßige Admin-Inventur, idealerweise auf quartalsweiser Basis, überprüft, welche Konten überhaupt über Administratorrechte verfügen und ob diese weiterhin erforderlich sind. Erfahrungsgemäß finden sich in gewachsenen Umgebungen immer wieder veraltete Dienstkonten oder ehemalige Mitarbeiterzugänge mit weitreichenden Rechten. Darüber hinaus bieten die CIS ein integriertes Audit-Log, das sicherheitsrelevante Ereignisse wie Anmeldungen, Konfigurationsänderungen und Berechtigungsvergaben protokolliert. Dieses Log sollte nicht nur archiviert, sondern auch aktiv überwacht werden. Idealerweise kommen automatisierte Benachrichtigungen für kritische Ereignisse zum Einsatz, beispielsweise für das Hinzufügen neuer Administratoren oder Änderungen an Trust-Konfigurationen.

Fazit: Threat Modeling als Denkwerkzeug

Was uns an der Arbeit mit dem Threat-Modeling-Ansatz besonders überzeugt hat, ist die strukturierte Auseinandersetzung mit der eigenen Systemlandschaft aus der Perspektive eines Angreifers. Statt nur zu fragen „Was haben wir eingerichtet?“, lautet die entscheidende Frage: „Was kann mit dem, was wir eingerichtet haben, schiefgehen?“

Die SAP Cloud Identity Services sind ein mächtiges Werkzeug. Gerade deshalb verdienen sie die gleiche sicherheitstechnische Aufmerksamkeit wie die Kernsysteme, die sie schützen sollen. Die beschriebenen Maßnahmen sind keine theoretischen Idealzustände, sondern in der Praxis umgesetzte Ansätze.

Wenn Sie wissen möchten, wie es um die Sicherheit Ihrer CIS-Umgebung bestellt ist, sprechen Sie uns gerne an. Eine strukturierte Analyse muss nicht aufwendig sein. Sie sollte jedoch stattfinden, bevor ein Angreifer potenzielle Schwachstellen identifiziert.

OREXES Consulting unterstützt Unternehmen bei der sicheren Gestaltung von SAP-Cloud-Landschaften. Das Leistungsspektrum reicht von der CIS-Governance über Authorization Policies bis hin zur Konzeption und Umsetzung vollständiger IAM-Lösungsarchitekturen. Mehr erfahren Sie unter hier.