SAP Identity Services & Zero Trust

Worum es geht

Klassische SAP-Landschaften haben User-Stamm in jedem System separat: ein S/4HANA-Stamm, ein SuccessFactors-Tenant, ein Ariba-Account, ein BTP-Subaccount, vielleicht noch Concur. Pro System eigene Passwörter, eigene Berechtigungs-Logik, eigene Audit-Spur. Aus Sicherheits- und Compliance-Sicht ein Albtraum; aus User-Sicht ein Onboarding- und Logout-Tagebuch.

SAP Cloud Identity Services lösen das auf der Identitäts- Schicht: eine zentrale Identität, föderiert in alle SAP-Welten, mit modernem Auth-Stack.

Architektur

mermaid flowchart TD IDP[Corporate IDP<br/>Entra ID / Okta / Ping] IAS[SAP Identity Authentication] IPS[SAP Identity Provisioning] HR[Corporate HR-System<br/>SuccessFactors EC] S4[S/4HANA<br/>Cloud / On-Prem] BTP[BTP Cockpit] SF[SuccessFactors<br/>HR-Suite] AR[Ariba P2P] IDP -->|SAML / OIDC| IAS IAS -->|SAML / OIDC| S4 IAS -->|SAML / OIDC| BTP IAS -->|SAML / OIDC| SF IAS -->|SAML / OIDC| AR HR -->|SCIM| IPS IPS --> S4 IPS --> BTP IPS --> SF IPS --> AR click IDP call mmdInfo() "Ihr unternehmensweiter Identity-Provider – Microsoft Entra ID, Okta oder Ping. Hier hinterlegen Sie zentrale Login-Policies, Conditional Access und SSO-Konfiguration. Die SAP-Welt nutzt diese Identitäten via SAML 2.0 oder OIDC, ohne eigenen User-Speicher zu pflegen." click IAS call mmdInfo() "SAP Identity Authentication ist der Authentication-Hub für die SAP-Welt. Er föderiert Anfragen aus dem Corporate IDP und reichert sie mit MFA, Passkeys und risikobasierter Step-Up-Authentifizierung an. Conditional Access greift auf Geräte-Compliance, Standort und Risiko-Score zu. Jeder Zugriff landet im Audit-Log." click IPS call mmdInfo() "SAP Identity Provisioning automatisiert das Lifecycle-Management. Wenn jemand im HR-System onboarded oder offboarded wird, propagiert IPS die Veränderung via SCIM in alle SAP-Zielsysteme – innerhalb von Minuten. Keine manuellen Berechtigungs-Tickets, keine vergessenen Accounts, kein verzögerter Offboarding-Lebenszyklus." click HR call mmdInfo() "Das HR-System ist die Quelle der Wahrheit für Mitarbeiter-Daten – typischerweise SuccessFactors Employee Central. Wenn jemand eingestellt wird, einen Wechsel macht oder das Unternehmen verlässt, wird das hier zuerst sichtbar. Über SCIM fliessen diese Veränderungen automatisch in IPS." click S4 call mmdInfo() "S4HANA – Cloud oder On-Premise – bekommt seine Identitäten vom IAS via SAML oder OIDC. Berechtigungen werden über Rollen gepflegt, die IPS automatisch zuweist und entzieht. SSO bedeutet einen Login pro Tag, statt eines pro System." click BTP call mmdInfo() "Das BTP Cockpit, alle BTP-Apps und Custom-Extensions nutzen IAS als Authentication-Layer. Die gleichen Identitäten gelten in S4HANA, im AI Hub, in der HANA Cloud und in selbstgebauten Side-by-Side-Apps. Eine Welt, eine Identity." click SF call mmdInfo() "SuccessFactors HR-Suite – Recruiting, Performance, Compensation – nutzt ebenfalls IAS für Authentication. Manager loggen sich einmal ein und haben Zugriff auf alle Module gemäss ihrer Rolle. SCIM-getriggertes Provisioning hält Berechtigungen synchron mit dem Lifecycle." click AR call mmdInfo() "Ariba P2P – Procure-to-Pay – sitzt im selben Identity-Mesh. Einkäufer und Genehmiger nutzen ihren Corporate-Login. Compliance- und Audit-Anforderungen aus FINMA und nDSG werden zentral durch IAS-Policies erfüllt, nicht in jedem System einzeln."

Zwei zentrale Komponenten

IAS – Identity Authentication

Tut die Authentifizierung:

IPS – Identity Provisioning

Tut die Provisionierung:

Zero Trust – die fünf Prinzipien angewandt

  1. Verify explicitly – kein Vertrauen nur basierend auf Netzwerk-Standort. Jeder Zugriff prüft Identität, Gerät, Kontext.
  2. Use least privilege – Just-in-Time-Berechtigungen für privilegierte Aktionen statt Dauer-Mitgliedschaft in SAP_ALL.
  3. Assume breach – Audit-Logs gehen in SAP ETD und SIEM, nicht erst beim Verdachtsfall ausgewertet (siehe Use Case "Threat Detection").
  4. Segment – Mandanten haben getrennte IDP-Konfigurationen; Test/Produktion sind separat trust-domänen.
  5. Continuously monitor – Risk-Score in IAS lebt; bei Verschlechterung wird Auth verschärft (step-up MFA).

Conditional Access – typische Regeln

Bedingung Auswirkung
Compliant Device + Corporate-IP Standard-Auth
Compliant Device + ausserhalb Corporate-IP + MFA
Non-Compliant Device Block
Risk-Score > 0.7 (Travel + neuer Standort) + step-up MFA
Privileged Action (PFCG, SU01, Massendaten) + step-up MFA
Service-Account ohne Interactive-Login nur per OAuth-Token

Modern Auth-Stack (Stand 2026)

Passkeys (FIDO2)

Passkeys sind der derzeit stärkste, am wenigsten User-störende Faktor. Phishing-resistent, kein Shared Secret, biometrisch geschützt am Gerät. Unterstützung in IAS seit 2024.

Wir empfehlen Passkeys als primären Faktor für alle privilegierten Rollen und als alternativen Faktor für Endanwender (mit TOTP als Fallback).

OAuth 2.1 / OIDC

OAuth 2.0 hat in der Vergangenheit einige Sicherheitsthemen gehabt (Implicit Flow). OAuth 2.1 räumt das auf – kein Implicit, Pflicht-PKCE, kürzere Token-Lebensdauer. Alle neuen BTP-Integrationen bauen wir auf OAuth 2.1.

Service-Konten

Klassische SAP-Hintergrund-User (RFC, Schnittstellen-User) sind Sicherheitsrisiken. Wir migrieren sie auf:

Lifecycle-Beispiel: ein Mitarbeiter steigt aus

Tag X-1, 17:00 – Letzter Arbeitstag, Manager triggert "Leave"-Workflow im HR-System.

Tag X-1, 17:05 – IPS empfängt das Event, deaktiviert Account in:

Tag X, 09:00 – Mitarbeiter versucht Login → wird blockiert.

Tag X+30 – IPS löscht Account final (SOX-konform mit Aufbewahrung der Audit-Spuren).

Klassisch dauert dieser Prozess Tage bis Wochen, mit Sicherheits-Lücke. Mit IPS: Minuten.

Re-Zertifizierung

Quartalsweise (oder häufiger für privilegierte Rollen) müssen Manager bestätigen, dass ihre direkten Reports die richtigen SAP-Rollen haben. Standard via SAP Access Governance – Re- Zertifizierungs-Kampagnen mit Excel-Export und Eskalations-Logik bei nicht-bearbeiteten Reviews.

Was wir liefern

Was wir nicht liefern

Compliance-Mehrwert

Stand: 2026-05-10

SFOUR Consulting — Übersicht · Kontakt