wladimir1804 - stock.adobe.com
Mit Cloud Identity Services SAP-Zugriffe sicher verwalten
Zwischen Cloud, On-Premises und SAP BTP gibt es komplexe Identitätsflüsse. Der Beitrag erklärt, wie SAP Cloud Identity Services diese technisch in den Griff bekommen.
In SAP-Landschaften mit wachsendem Cloud-Anteil verlagert sich das Problem der Identitäten schnell weg von der reinen Benutzerverwaltung hin zur Frage, wie Identitäten systemübergreifend konsistent bleiben. Ohne übergreifende Identitätsschicht existieren Benutzer nicht nur mehrfach, sondern mit unterschiedlichen Bedeutungen. In einem System steuert dann ein Attribut die Anmeldung, im nächsten entscheidet eine Rolle über fachliche Berechtigungen und an anderer Stelle dient dieselbe Kennung nur noch als technischer Platzhalter für Audits.
SAP Cloud Identity Services ordnet SAP-Identitäten
SAP Cloud Identity Services sollen diese Zersplitterung beheben. Die Plattform definiert Identität nicht mehr als Eigenschaft eines einzelnen Systems, sondern als zentral verwaltetes, persistentes Objekt mit systemübergreifender Referenz. Für den Betrieb bedeutet das einen fundamentalen Wechsel. Identitäten verlieren ihren anwendungsspezifischen Charakter und erhalten eine feste Referenz, die unabhängig von Deployments, Unterkonten (Subaccounts) oder Applikationsversionen existiert.
Diese Entkopplung wirkt sich unmittelbar auf Stabilität und Nachvollziehbarkeit aus. Fehler, bei denen sich Benutzer zwar anmelden können, aber keine fachlichen Funktionen sehen oder umgekehrt, lassen sich klar zuordnen. Authentifizierung, Attributweitergabe und Autorisierung folgen nicht mehr impliziten Annahmen einzelner Systeme, sondern einem definierten Identitätsfluss. Damit sinkt die Abhängigkeit von applikationsinternen Sonderlogiken, die in vielen Landschaften historisch gewachsen sind und kaum noch dokumentiert vorliegen.
Identitätsgrenzen und Trust-Design in SAP Business Technology Platform
Die SAP Business Technology Platform (BTP) erzwingt durch ein globales Konto (Global Account) und Unterkonten eine harte Trennung von Ressourcen, Berechtigungen und Sicherheitskontexten. Diese Architektur schützt Mandanten, erzeugt aber ohne zusätzliche Identitätsschicht schnell operative Reibung. Platform User verwalten Unterkonten und Quotas, Business User konsumieren Anwendungen, beide Gruppen folgen unterschiedlichen Sicherheitsmodellen. SAP Cloud Identity Services setzen an dieser Trennlinie an und schaffen eine einheitliche Identitätsverwaltung oberhalb der Unterkonten. Die Identität selbst bleibt eindeutig, der Zugriff auf Ressourcen bleibt begrenzt.
Das Trust-Modell folgt dieser Logik strikt. Der Trust im globalen Konto regelt ausschließlich den Zugriff auf die Plattformadministration. Der Trust im Unterkonto steuert ausschließlich den Zugang zu Anwendungen. Diese Trennung wirkt auf den ersten Blick aufwendig, verhindert jedoch eine der häufigsten Fehlerquellen im Betrieb. Plattformrechte und Applikationsrechte vermischen sich nicht mehr. Änderungen an Authentifizierungsregeln für Administratoren haben keine Auswirkungen auf Business User und umgekehrt. Für den Betrieb ergibt sich damit eine klare Zuständigkeit. Plattformzugriff bleibt ein Infrastrukturthema, Anwendungszugriff ein fachliches Thema.
Der SAP ID Service eignet sich für den Einstieg, bietet jedoch keine Kontrolle über Passwortregeln, MFA-Strategien (Multifaktor-Authentifizierung) oder Lifecycle. Mit der Einführung von SAP Cloud Identity Services wandert diese Kontrolle in einen eigenen Tenant. Änderungen an Sicherheitsregeln erfolgen zentral und wirken reproduzierbar auf alle angebundenen Unterkonten. Damit verlieren Notfallmaßnahmen ihren improvisierten Charakter und lassen sich dauerhaft in Governance-Prozesse integrieren.
Identity Authentication als verbindendes Element zwischen Identity Provider, Plattform und Anwendung
Identity Authentication übernimmt in dieser Architektur eine Schlüsselrolle, da sie nicht nur authentifiziert, sondern Protokolle, Token-Formate und Attributmodelle vermittelt. In der Praxis existiert selten ein homogener Anwendungsbestand. Ältere SaaS-Lösungen erwarten SAML-Assertions, neuere Anwendungen setzen OIDC voraus, interne Tools nutzen proprietäre Claims. Identity Authentication entkoppelt diese Anforderungen vom Corporate Identity Provider (IdP). Der IdP liefert eine einmal definierte Authentifizierungsantwort, die Plattform übersetzt sie kontextabhängig für jedes Zielsystem.
Dieser Ansatz reduziert die Anzahl kritischer Integrationspunkte erheblich. Statt jede Anwendung direkt an den Corporate-IdP anzubinden, existiert ein kontrollierter Vermittler. Änderungen am IdP betreffen nicht mehr jede Anwendung einzeln. Ebenso lassen sich neue Anwendungen anbinden, ohne bestehende Authentifizierungsflüsse anzupassen. Der Nutzen zeigt sich im Betrieb dort, wo Authentifizierungsfehler bisher nur schwer einzugrenzen waren. Fehler lassen sich eindeutig dem Upstream-Login, der Token-Übersetzung oder der Downstream-Autorisierung zuordnen.
Delegierte Authentifizierung verstärkt diesen Effekt. Identity Authentication speichert keine produktiven Passwörter, sondern fungiert als Proxy vor dem Corporate-IdP. Conditional Authentication entscheidet anhand definierter Regeln, welcher IdP zum Einsatz kommt oder ob ein Zugriff unterbunden wird. Damit lassen sich interne Nutzer, Partner und externe Identitäten trennen, ohne zusätzliche Trust-Beziehungen auf Plattformebene zu etablieren. Der Betrieb profitiert von zentralen Regeln, die unmittelbar für alle Anwendungen gelten, statt von fragmentierten Konfigurationen, die sich gegenseitig widersprechen.
MFA fügt sich in dieses Modell ein. Zusätzliche Faktoren greifen kontextabhängig, nicht pauschal. Administrative Gruppen, auffällige Anmeldezeiten oder externe Netzbereiche erfordern eine zusätzliche Authentifizierung, reguläre Zugriffe bleiben unbeeinträchtigt. Dadurch steigt die Akzeptanz im Tagesgeschäft, ohne sicherheitsrelevante Abstriche. Änderungen an MFA-Strategien erfolgen zentral und benötigen keine Anpassung einzelner Anwendungen.
Laufzeitintegration, Rollenmodelle und föderierte Anwendungen
In produktiven SAP-BTP-Landschaften entscheidet sich der tatsächliche Nutzen der Identity Services erst in der Laufzeit, nicht beim Login. Sobald Anwendungen Anfragen verarbeiten, greifen App-Router und der SAP Authorization and Trust Management Service (XSUAA) als verbindliche Kontrollinstanzen. Der App-Router liegt vor jeder Anwendung und akzeptiert ausschließlich Anfragen mit gültiger Sitzung. Die Authentifizierungslogik verbleibt vollständig außerhalb des Anwendungscodes. XSUAA validiert die von Identity Authentication gelieferten Tokens, reichert sie mit BTP-spezifischen Claims an und stellt der Anwendung ein JSON Web Token (JWT) zur Verfügung, das Rollen, Scopes und Identitätsattribute enthält. Anwendungen treffen keine eigenen Authentifizierungsentscheidungen mehr, sondern prüfen deklarativ definierte Berechtigungen. Dadurch reduziert sich die Komplexität im Anwendungscode und Sicherheitsprüfungen lassen sich systematisch nachvollziehen.
Dieses Modell wirkt direkt mit dem Rollen- und Berechtigungskonzept der Plattform zusammen. Entwickler definieren Rollenvorlagen (Role Templates) in der Applikation, die beim Deployment in das Unterkonto übertragen werden. Administratoren bündeln diese Rollen in Rollensammlungen (Role Collections) und ordnen sie Benutzern zu. Die eigentliche Identität stammt aus den Identity Services, die fachliche Berechtigung aus dem Unterkonto. Diese Trennung verhindert, dass Identitätsattribute unkontrolliert zu Berechtigungen führen. Änderungen an Rollen betreffen ausschließlich das Unterkonto, Änderungen an Identitäten wirken systemübergreifend, ohne implizit neue Zugriffe zu öffnen. Für den Betrieb ergibt sich daraus eine klare Fehlertrennung zwischen Identitätsproblemen und Berechtigungsproblemen.
Ein weiterer Effekt zeigt sich bei föderierten Anwendungen, insbesondere im Zusammenspiel mit SAP Build Work Zone und angebundenen S/4HANA-Systemen. Anwendungen aus unterschiedlichen Systemen erscheinen in einer gemeinsamen Oberfläche, greifen jedoch weiterhin auf ihre jeweiligen Autorisierungsmodelle zurück. Identity Authentication stellt die durchgängige Identität sicher, Principal Propagation ermöglicht, dass diese Identität bis in das angebundene Backend weitergereicht wird. Aktionen in SAP S/4HANA laufen damit unter dem tatsächlichen Benutzerkontext und lassen sich revisionssicher auswerten. Für Administratoren entfällt die Notwendigkeit technischer Sammeluser oder Sonderkonten, da Identität und Autorisierung entlang der gesamten Zugriffskette erhalten bleiben.
Die technische Grundlage für diese Zusammenarbeit bildet der Cloud Connector, der On-Premises-Systeme ohne zusätzliche eingehende Firewall-Ports an SAP BTP bindet. Der Verbindungsaufbau erfolgt initiierend aus dem internen Netz, Sitzungen bleiben persistent offen und erlauben bidirektionale Kommunikation über etablierte Kanäle. Dadurch lassen sich interne Systeme anbinden, ohne die Netzwerksicherheitsarchitektur aufzubrechen. In Kombination mit den Identity Services ergibt sich eine Zugriffskette, die Identität, Netzwerkzugang und Anwendungssicherheit konsistent miteinander verknüpft und auch in hybriden Landschaften beherrschbar hält.
Betrieb, Transparenz und technische Nachvollziehbarkeit
Im laufenden Betrieb verschiebt sich der Fokus von der reinen Konfiguration hin zur Beobachtbarkeit von Identitätsflüssen. SAP Cloud Identity Services liefern hierfür eine technische Grundlage, die in klassischen IAM-Ansätzen häufig fehlt. Job-Logs und Echtzeit- Provisioning-Logs bilden jede relevante Aktion ab, vom initialen Abgleich über Attributänderungen bis zur Deaktivierung von Konten. Diese Protokolle lassen sich systematisch auswerten und erlauben eine saubere Trennung zwischen Fehlern im Quellsystem, Transformationsproblemen und Zielsystemreaktionen. Für Administratoren verändert sich dadurch die Art der Fehlersuche grundlegend. Statt Vermutungen über nicht erfolgte Synchronisationen existieren konkrete Zeitpunkte, Statusmeldungen und technische Ursachen, die sich eindeutig zuordnen lassen.
Auch im Bereich Authentifizierung ist eine neue Form von Transparenz verfügbar. Anmeldeereignisse lassen sich entlang der gesamten Kette nachvollziehen, vom ersten Request über Identity Authentication bis zum Token-Verbrauch in der Anwendung. Auffälligkeiten bei MFA, Regelverletzungen oder blockierte Zugriffe erscheinen nicht mehr als isolierte Ereignisse in einzelnen Systemen, sondern als Teil eines konsistenten Flusses. Diese Konsistenz vereinfacht nicht nur die Fehleranalyse, sondern auch interne und externe Prüfungen. Audit-Fragen lassen sich direkt an der Identität festmachen, ohne Logs aus mehreren Systemen manuell korrelieren zu müssen.
Ein weiterer Effekt zeigt sich bei Änderungen an der Landschaft. Neue Unterkonten, zusätzliche Regionen oder weitere angebundene Systeme erweitern die Identitätsarchitektur, ohne bestehende Flüsse aufzubrechen. Die Identität bleibt unverändert, nur ihre Nutzung wächst. Damit verliert Skalierung ihren Ausnahmecharakter. Änderungen erfolgen kontrolliert über die Konfiguration, nicht über Eingriffe in bestehende Benutzerbestände. Für den Betrieb reduziert sich das Risiko schleichender Inkonsistenzen, die sonst erst später auffallen und dann nur mit hohem Aufwand korrigierbar sind.
Tenant-Strategie, Regionen und betriebliche Grenzen
Ein oft unterschätzter Punkt bei SAP Cloud Identity Services ist die bewusste Entscheidung für eine Tenant- und Regionenstrategie. Identity Services laufen als global verteilte SaaS-Komponente auf unterschiedlichen IaaS-Plattformen, darunter AWS, Microsoft Azure, Google Cloud und Alibaba Cloud. SAP betreibt die Plattformebene, die Infrastruktur liegt beim jeweiligen Provider. Für den Betrieb bedeutet dies, dass Hochverfügbarkeit und Disaster-Recovery-Eigenschaften primär durch die gewählte Region und deren Infrastruktur bestimmt werden. Identity Authentication selbst nutzt die Fähigkeiten der darunterliegenden Plattform, stellt jedoch keinen eigenständigen, konfigurierbaren Disaster-Recovery-Mechanismus bereit. Administratoren müssen daher früh entscheiden, in welcher Region produktive und Test-Tenants liegen und wie nah diese an angebundenen Unterkonten und Backend-Systemen positioniert sind.
Diese Entscheidung wirkt sich unmittelbar auf Latenzen, Fehlerszenarien und Wartungsfenster aus. Identitäten sind zwar global eindeutig, Authentifizierungsflüsse bleiben jedoch gebunden an die Region. Ein Wechsel der Region bedeutet faktisch einen neuen Tenant mit neuem Trust-Aufbau. Daraus ergibt sich ein klarer operativer Vorteil einer stabilen Tenant-Struktur. Test- und Produktiv-Tenants erlauben getrennte Regelwerke, MFA-Policies und Provisionierungsjobs, ohne Risiko für den laufenden Betrieb. Gleichzeitig vermeiden sie Konfigurations-Drift, da Änderungen vorab validiert werden können.
Identity Directory und Provisionierung als Fundament
Identity Directory bildet die persistente Ebene dieser Architektur. Benutzer und Gruppen existieren dort unabhängig von ihrer Nutzung in einzelnen Systemen. Die Global User ID fungiert als Referenzpunkt über den gesamten Lifecycle. Attributänderungen verlieren ihre destruktive Wirkung, da Identität nicht an mutable Eigenschaften gekoppelt ist. Für Audits und Log-Analysen ergibt sich ein konsistenter Bezugspunkt, der systemübergreifend gültig bleibt.
Identity Provisioning ergänzt diese Persistenz durch kontrollierte Synchronisation. Änderungen im Quellsystem propagieren automatisiert in Zielsysteme. Transformationen gleichen unterschiedliche Attributmodelle an, Filter begrenzen den Umfang auf relevante Benutzer. Gerade in Landschaften mit SAP S/4HANA, SuccessFactors und weiteren Cloud-Diensten reduziert sich damit der manuelle Pflegeaufwand. Offboarding-Szenarien lassen sich reproduzierbar abbilden, da Deaktivierungen systemübergreifend greifen.
In hybriden Umgebungen übernimmt Identity Provisioning zudem die Rolle des Vermittlers zu Systemen ohne native SCIM-Unterstützung. Proxy-Szenarien schließen diese Lücke, ohne die Identitätslogik zu fragmentieren. Für Admins entsteht ein zentraler Punkt, an dem Lifecycle-Änderungen sichtbar, nachvollziehbar und steuerbar bleiben.
