Übersicht über SAP ERP
Für Unternehmen, die SAP ERP (Enterprise Resource Planning) einsetzen, ist dies oft eines ihrer wichtigsten Systeme. Es erfasst und bearbeitet Kundenaufträge, fordert Zahlungen an und überwacht sie und stellt Führungskräften und Investoren Finanzdaten bereit. Kurz gesagt ist dieses System das Rückgrat des Geschäftsbetriebs, der zum Erliegen kommen kann, wenn SAP ERP ausfällt oder kompromittiert wird.
Trotz ihrer Bedeutung halten einige SAP ERP-Umgebungen die Zero-Trust-Sicherheitsstandards, die häufig von modernen Cloud- und SaaS-Lösungen verwendet werden, noch nicht gut genug ein. Dies liegt oft an der Flexibilität von SAP, was bedeutet, dass keine zwei Implementierungen identisch sind und Änderungen oft erhebliche und spezielle Anstrengungen erfordern.
Als Identity-Architekt mit umfassender Erfahrung in verschiedenen Bereichen der SAP-Sicherheit kann ich eine Perspektive darauf bieten, wie SAP ERP-Bereitstellungen modernisiert werden können, um die neuesten Sicherheitsvorteile zu nutzen.
Häufige Probleme/Herausforderungen
Bevor wir uns ansehen, wie ein Zielzustand aussehen könnte, gehen wir zunächst auf einige typische Bereiche ein, die die größten Verbesserungsmöglichkeiten bieten.
Nomenklatur und Terminologie
Bei der Zusammenarbeit mit einem so großen Anbieter wie SAP kann es schwierig sein, die richtige Terminologie und Nomenklatur zu verwenden. Ich hatte Schwierigkeiten, einen passenden Titel für diesen Blog-Beitrag zu finden, weil ich sicherstellen wollte, dass ich mich auf die richtige SAP-Technologie beziehe.
SAP bietet ein breites Spektrum von Produkten an, und einige der neueren Angebote folgen anderen Modellen als denen, die ich hier behandeln werde. Wenn ich in diesem Beitrag von SAP ERP spreche, beziehe ich mich auf die Produktpalette, die SAP seit 1972 entwickelt und erweitert hat. Sie können diese Suite normalerweise anhand einiger Schlüsselwörter identifizieren: ABAP, S4/HANA, ECC, Basis oder Netweaver.
Legacy-Authentifizierung
Trotz der Fortschritte von SAP im Bereich webbasierter Benutzeroberflächen greifen Unternehmen häufig weiterhin über den traditionellen Windows-Client (SAPGUI) auf SAP zu. Auch wenn Zero-Trust-Authentifizierung für SAPGUI möglich ist (mehr dazu später), lässt sie sich nur kompliziert bereitstellen und konfigurieren. Deshalb setzen viele Unternehmen bei der Authentifizierung weiterhin auf Passwörter.
Passwörter bringen die üblichen Herausforderungen mit sich: suboptimale User Experience, die Notwendigkeit von Tools zur Passwortsynchronisierung und Authentifizierungsmethoden mit geringer Sicherheit.
Das größte Problem ist jedoch nicht die User Experience, sondern das potenzielle Sicherheitsrisiko. Bei SAPGUI ist die Netzwerkverschlüsselung eng mit der Authentifizierung verbunden. Für viele Installationen bedeutet dies, dass Benutzernamen und Passwörter im Klartext über das interne Netzwerk übertragen werden. Wenn Tools zur Passwortsynchronisierung verwendet werden, können dadurch auch Active Directory-Passwörter offengelegt werden. Wenn der Entra ID Hybrid-Modus aktiviert ist, könnte sich dieses Risiko schließlich auch auf Entra-Anmeldedaten ausweiten.
Die Verwendung eines VPN oder die Aktivierung der Windows-Authentifizierung kann dazu beitragen, dieses Risiko zu verringern. Damit erhalten Sie aber keine vollständigen Lösungen. Eine echte Zero-Trust-Strategie geht davon aus, dass das Netzwerk kompromittiert ist, und erzwingt starke Authentifizierung auf jeder Ebene, ohne sich ausschließlich auf netzwerkbasierte Schutzmaßnahmen zu verlassen.
Unvollständige RBAC-Projekte und Konfigurationsdrift
Das SAP-Berechtigungsmodell ist sehr detailliert und komplex. Früh in meiner Karriere als Administrator musste ich den ADM940-Kurs von SAP über Sicherheit und Autorisierungen belegen. Es war keine leichte Lektüre, aber sie hat mir die Funktionsweise der SAP-Sicherheitsmaßnahmen vermittelt.
SAP-Sicherheit wird oft im Zusammenhang mit Transaktionscodes (Tcodes) gesehen, die jeweils mit einer Geschäftsaufgabe verbunden sind. Hinter jeder Benutzeraktion werden jedoch Dutzende oder sogar Hunderte unterschiedlicher Autorisierungen überprüft. Diese Autorisierungsprüfungen können je nach Benutzerbedingungen oder der eingesetzten SAP-Version unterschiedlich sein (mehr dazu später).
Komplexität ist eine Sache, Größe eine andere. Nachdem wir die Komplexität von Rollen innerhalb von SAP festgestellt haben, sprechen wir über Größe. Viele RBAC-Projekte (rollenbasierte Zugriffskontrolle) stehen vor Schwierigkeiten, wenn sie versuchen, sämtliche Zugriffe mit dedizierten Jobrollen abzudecken. Dieses unrealistische Ziel kann zu einem nahezu 1:1-Verhältnis zwischen der Anzahl der Benutzer und Rollen führen. Dieses Problem ist nicht auf SAP-Bereitstellungen beschränkt und manifestiert sich auf verschiedene Weise, was eine SAP-Landschaft verkomplizieren kann.
SAP bietet Tools für die Verwaltung von Rollen, die bei konsistenter Nutzung nützlich sind. In vielen Umgebungen ist Konsistenz jedoch selten. Was in einem SAP-System funktioniert, funktioniert anderswo oft nicht auf dieselbe Weise.
Infolgedessen verlassen sich viele Unternehmen auf Methoden mit niedriger Sicherheit für die Zuweisung von Zugriffsrechte:
- Kopieren von einem bestehenden Benutzer: SAP hat diese „Modellieren als“-Funktion integriert.
- Zuweisung von Zugriffsrechten basierend auf Transaktionscodes (T-Codes): T-Codes sind eine einfache Methode, um die Zugriffsebene einer bestimmten Rolle zu bestimmen.
Beide Ansätze bringen Herausforderungen mit sich. Die Modellierung von Benutzern auf der Grundlage von bestehendem Personal birgt das Risiko, unangemessene Zugriffsrechte weiterzugeben, die sich im Laufe der Zeit angesammelt haben könnten. T-Codes geben nur einen teilweisen Überblick darüber, was ein Benutzer tun kann. Darüber hinaus gibt es ein weit verbreitetes Missverständnis, dass T-Codes direkt zugewiesen werden können – das ist nicht der Fall. Mittlerweile basieren neuere SAP-Module nicht auf T-Codes, so dass diese Methode allmählich veraltet.
Diesen Weg sind wir schon einmal gegangen
Es sollte nicht überraschen, dass in der Vergangenheit verschiedene Iterationen von Lösungen für dieses Problem eingesetzt wurden (und auch heute noch verwendet werden). Hier ist ein Beispiel dafür, wie Identity-Management- und Identity-Governance-Produkte verwendet wurden, um Teillösungen bereitzustellen:
Zusammenfassung der Komponenten
Hinweis: Ich verwende absichtlich generische Begriffe für diese Komponenten – häufig erfüllen Identity-Produkte eine oder mehrere dieser Funktionen.
Enterprise Directory Service
Diese Komponente ist für Laufzeit-Zugriffskontrolldienste verantwortlich. In Situationen, in denen eine lokale SAP-Authentifizierung stattfindet, wird hier das Passwort des Benutzers synchronisiert. Wenn dagegen SSO in SAP konfiguriert ist, werden Legacy-Kerberos-Authentifizierungsdienste von diesem Dienst bereitgestellt.
Enterprise Provisioning Service
Diese Komponente ist für die Durchführung der rollenbasierten Zugriffskontrolle und die Provisionierung von Zugriffen in der gesamten Umgebung verantwortlich. Dieser Dienst trägt dazu bei, dass die richtigen User Accounts in den richtigen Systemen eingerichtet sind und dass die richtigen Zugriffe für diese Accounts eingerichtet sind (einschließlich des Directory-Services).
SAP GRC-Modul
Dieses Modul dient vielen Zwecken, darunter der Übernahme der automatisierten SAP-Bereitstellung vom globalen Provisionierungs-Service, der Gewährleistung der Funktionstrennung und der Einholung der entsprechenden Zugriffsgenehmigungen für jeden angeforderten SAP-Zugriff.
Dieses Design kann zwar dazu beitragen, Compliance-Anforderungen zu erfüllen, bringt jedoch einige Herausforderungen mit sich, die den Erfolg der Bereitstellung einschränken können.
- Genehmigungen für den SAP-Zugriff unterscheiden sich grundlegend von denen für andere Unternehmensanwendungen. Dies bedeutet unterschiedliche Audit-Systeme, unterschiedliche Workflow-Engines für Administratoren und unterschiedliche Genehmigungsprozesse für Genehmigende. Es kann auch zu einer irritierenden User Experience führen, die für Benutzer schwer zu verstehen ist, wenn Genehmigende Aufgaben nicht schnell genehmigen.
- Der Enterprise Provisioning Service hat nur begrenzten Einblick in die Zugriffsrechte, die in jedem SAP-System vorhanden sind. Während SAP GRC über zuverlässige Mechanismen zur Datensynchronisierung zwischen sich und einzelnen SAP-Systemen verfügt, kann der fehlende direkte Zugriff des unternehmensweiten Systems auf das Aufzeichnungssystem die Identifizierung und das Nachverfolgen von Synchronisationsfehlern erschweren, wenn diese auftreten.
- Dieses Design erlaubt im Allgemeinen keine Zusammenarbeit zwischen dem durch den Directory-Service gesteuerten Laufzeit-Zugriff und dem durch den Provisionierungs-Service verwalteten Zugriff auf gespeicherte Daten. Beispiele:
- Was ist, wenn wir nur für eine Stunde einen temporären Zugriff gewähren müssen?
- Was ist, wenn wir die Authentifizierung basierend auf der Zugriffsebene eines Benutzers ändern möchten?
- Was ist, wenn wir starke Authentifizierung für SAP-Hauptbenutzer im Vergleich zu Benutzern mit eingeschränkten Zugriffsrechten benötigen?
Bei diesem Modell steuern zwei separate Plattformen zwei verschiedene Arten des Zugriffs. Infolgedessen können Zero-Trust-Anwendungsfälle wie diese in der Regel nur durch komplexe, anfällige Orchestrierung zusammengefügt werden – und werden nicht nativ unterstützt.
Es gibt einen besseren Weg!
Bei Okta haben wir uns die Aufgabe gesetzt, jedem Unternehmen die Möglichkeit zu geben, jede Technologie sicher zu nutzen. Das bedeutet, dass SAP als kritische Komponente bei jedem Unternehmen auf standardisierte Weise verwaltet werden muss, die sich für eine unternehmensweite Zero-Trust-Strategie eignet.
Zusammenfassung der Komponenten
Okta Platform
Hier bietet Okta unternehmensweites Identity-Management, Identity Governance und Privileged Access Services. Damit wird gewährleistet, dass digitale Identitäten ordnungsgemäß synchronisiert und gemäß den Richtlinien verwaltet werden. Okta bietet eine zentrale Zugriffsanfrage/-genehmigung, eine zentrale Zugriffszertifizierung sowie eine zentrale, kontextbezogene Authentifizierungsplattform für das Unternehmen.
SAP GRC
Für größere Compliance-orientierte SAP-Implementierungen spielt SAP GRC eine wichtige Rolle. Das Framework bietet die detaillierten Funktionen zur Überprüfung der Funktionstrennung, die zur Erfüllung der Compliance-Anforderungen erforderlich sind. In diese Funktion ist das fachspezifische Know-how eingebettet, das SAP am besten vermitteln kann. Was stellt unangemessenen Zugriff dar? Welcher Zugriff kollidiert mit welchem anderen Zugriff? Die Antworten auf diese Fragen sind tief im SAP-Produkt verwurzelt und werden am besten von SAP selbst beantwortet. Meiner Meinung stellt diese Regeln eine der wertvollsten Komponenten des SAP GRC-Produkts dar.
Auch wenn GRC in dieser Architektur eine wichtige Rolle spielt, fungiert es eher als API und Verwaltungstool und nicht als etwas, mit dem Endbenutzer oder Genehmigende normalerweise interagieren.
Dieses Diagramm veranschaulicht auf allgemeine Weise die Rollen und Verantwortlichkeiten von Okta und GRC in diesem empfohlenen Bereitstellungsmuster.
Oberflächlich betrachtet bietet diese Strategie einige klare Vorteile für Endbenutzer und Administratoren:
- Ein zentrales System, das unternehmensweit für alle Identity-Synchronisierungsaufgaben zuständig ist
- Ein gemeinsamer Genehmigungsprozess, Antragsprozess und Auditprozess für das gesamte Unternehmen
- Kritische SAP-Sicherheitskontrollen werden gepflegt
- Grundlegende Auditing-Plattformen erhalten die neuesten Informationen direkt von SAP-Systemen, ohne dass es zu Ausfällen bei Vermittlungssystemen kommen kann
Allgemein betrachtet geht es darum, das richtige Werkzeug für die richtige Aufgabe zu verwenden. Heute agieren wir jedoch in einer Welt, in der Identität gleichbedeutend mit Sicherheit ist, und Okta bietet Ihnen einen Identity Security Fabric, der Identity-Tools in Sicherheitstools verwandelt.
Vielleicht haben Sie schon einmal den Begriff „konvergierte Identity-Plattform“ gehört, der von Branchenführern und Analysten genutzt wird. In der Praxis kann das Konzept nicht nur die Sicherheit Ihrer SAP-Bereitstellung verbessern, sondern auch die Sicherheit Ihres gesamten Unternehmens.
Zuvor habe ich zwei Arten von Zugriff erwähnt: „gespeichert“ und „zur Laufzeit“.
- „Gespeicherter“ Zugriff bezieht sich auf die Benutzer, Accounts, Berechtigungen und Rollen, die in Ihrem gesamten Unternehmen eingerichtet sind. Bei SAP sind damit Ihre Benutzerstammsätze und deren Rollenzuweisungen gemeint. Ich bezeichne diesen Zugriff als „gespeichert“, weil er relativ stabil ist und keinen Laufzeitkontext berücksichtigt, wenn SAP-Autorisierungsprüfungen durchgeführt werden.
- Beim „Laufzeit“-Zugriff versucht ein Benutzer, tatsächlich etwas zu tun. Welches Gerät nutzt er? Wie ist die Sicherheitslage dieses Geräts? Aus welchem Netzwerk kommt der Benutzer? Gibt es etwas Ungewöhnliches an seinem Verhalten? Wie hat er sich authentifiziert und wie lange ist das her?
Für echten mehrstufigen Schutz und eine Zero-Trust-Strategie müssen beide Zugriffsarten zusammenarbeiten. Es reicht nicht aus, dass ein Benutzer Zugriff hat – er sollte diesen Zugriff nur unter den richtigen Bedingungen nutzen.
Durch Zusammenführen all dieser Faktoren auf einer einzigen Plattform wie Okta können Sie diese Sicherheitsebenen auf skalierbare Weise anwenden. Das Ergebnis ist ein moderner Zero-Trust-Ansatz, der dazu beiträgt, dass Ihre SAP-Umgebung ebenso konsequent geschützt wird wie Ihre übrige kritische Infrastruktur.
Zusammenfassung
Wenn ich noch Ihre Aufmerksamkeit habe, dann danke ich Ihnen, dass Sie mir Ihre Zeit geschenkt haben. Das Ziel meines Beitrags war es, drei zentrale Ideen zu beleuchten:
- Ein kurzer Überblick über die Möglichkeiten zur Identity-Modernisierung, die SAP-Kunden heute zur Verfügung stehen
- Eine Analyse der Gründe, warum klassische und isolierte Ansätze die Implementierung eines echten Sicherheitsmodells der nächsten Stufe einschränken können
- Ein moderner Design-Ansatz, der die Stärken sowie die Sicherheitsfunktionen von SAP nutzt – und gleichzeitig SAP in die allgemeinen Sicherheitsprogramme integriert, die viele Unternehmen heute aufbauen
Wenn Sie mehr darüber erfahren möchten, wie eine konvergente Identity-Plattform in der Praxis aussieht, sehen Sie sich hier unser neuestes Webinar an.
Diese Informationen und die darin enthaltenen Empfehlungen stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Geschäftsberatung dar. Dieses Dokument dient nur zu allgemeinen Informationszwecken und gibt womöglich nicht den aktuellen Stand aller relevanten Fragen wieder. Es liegt in Ihrer Verantwortung, sich mit Blick auf die Rechtslage, den Datenschutz, die Sicherheit, die Compliance und das Business beraten zu lassen. Stützen Sie sich nicht allein auf die enthaltenen Empfehlungen. Okta übernimmt keine Haftung für Verluste oder Schäden, die sich potenziell aus der Umsetzung der Empfehlungen in diesen Materialien ergeben. Okta gibt keine Zusicherungen, Garantien oder sonstigen Zusicherungen in Bezug auf den Inhalt dieser Materialien. Informationen zu den vertraglichen Zusicherungen von Okta an seine Kunden finden Sie unter okta.com/agreements.
Dieser Blog repräsentiert nicht notwendigerweise die Position, Strategien oder Meinung von Okta.
