Die gängigsten Fehlkonfigurationen in SAP-Systemen

SAP-Systeme spielen eine zentrale Rolle in vielen Unternehmen, da sie eine Vielzahl von Geschäftsprozessen unterstützen und optimieren.

Die IT-Sicherheit von SAP-Systemlandschaften ist daher ein zentraler Baustein einer umfassenden Strategie für die IT-Sicherheit eines Unternehmens. SAP bietet eine umfassende Palette an integrierten Sicherheitsfunktionen und -maßnahmen, die darauf abzielen, die Einhaltung internationaler Cybersicherheitsstandards sowie datenschutzrechtlicher Anforderungen sicherzustellen.

Um die drei grundlegenden Prinzipien der Informationssicherheit – Integrität, Verfügbarkeit und Vertraulichkeit – gewährleisten zu können, ist die systematische Umsetzung von Sicherheitsmaßnahmen unerlässlich. Diese Maßnahmen dienen der Prävention von unberechtigten Zugriffen auf sensible Daten, kritische Anwendungen und geschützte Funktionen innerhalb der SAP-Systeme.

Ein Sicherheitsvorfall in einer SAP-Landschaft kann erhebliche betriebliche und finanzielle Folgen nach sich ziehen. Dazu zählen beispielsweise Finanzbetrug, Sabotage von Geschäftsprozessen oder der Diebstahl von Unternehmensgeheimnissen durch Betriebsspionage.

Häufige Ursachen für Sicherheitsrisiken in SAP-Systemen sind sowohl technische Schwachstellen in der Software als auch menschliche Fehler, insbesondere bei der Konfiguration und Verwaltung der Systeme. Eine unsachgemäße Einrichtung von Berechtigungen, unzureichende Patchmanagement-Prozesse oder die Verwendung von Standardpasswörtern oder schwachen Passwörtern können erhebliche Sicherheitslücken schaffen.

Daher sind eine kontinuierliche Sicherheitsbewertung, die regelmäßige Überprüfung von Zugriffsrechten, die Anwendung von Sicherheitspatches sowie die Schulung von Fachpersonal entscheidend, um die Sicherheitslage der SAP-Landschaft nachhaltig zu stärken und potenzielle Bedrohungen proaktiv zu erkennen und zu minimieren.

Im Folgenden werden die häufigsten Fehler und Fehlkonfigurationen, die die SySS bei Sicherheitsüberprüfungen (Security Reviews) feststellt, näher betrachtet.

1. Exponierung von SAP-Diensten

Der umfassende Zugriff auf SAP-Dienste aufgrund laxer Firewallregeln – sei es im öffentlichen Internet oder im internen Netzwerk – stellt eines der gravierendsten Sicherheitsrisiken in SAP-Systemlandschaften dar. Insbesondere dann, wenn einzelne Dienste oder gesamte SAP-Systeme über offene Internetverbindungen erreichbar sind, wird die Angriffsfläche erheblich vergrößert. Dies erhöht nicht nur die Wahrscheinlichkeit eines erfolgreichen Angriffs erheblich, sondern kann auch die Auswirkungen eines Sicherheitsvorfalls drastisch verschärfen.

Auch im internen Netzwerk sind häufig mehr Dienste erreichbar, als für den betriebsnotwendigen Einsatz erforderlich sind. Eine solche „Over-Exposition“ von Diensten führt zu einer unnötigen Vergrößerung der Angriffsfläche und erhöht das Risiko, dass durch interne Fehlkonfigurationen oder Missbrauch durch autorisierte Benutzer Sicherheitslücken ausgenutzt werden können.

Besonders kritisch ist die Exponierung von zentralen SAP-Diensten wie dem SAP Gateway oder dem SAP Message Server, die aufgrund ihrer zentralen Rolle in der Systemarchitektur häufig Ziel von Angriffen sind. Bei einer Sicherheitsüberprüfung (Security Review) steht daher die Erreichbarkeit dieser Dienste häufig im Fokus, da eine unzureichende Absicherung ein direktes Einfallstor für Angreifer darstellen kann.

Um die Sicherheitslage zu verbessern, ist es entscheidend, ein striktes Prinzip der Minimierung der Zugriffsrechte (Principle of Least Privilege) anzuwenden. Zusätzlich ist es wichtig, dass nur diejenigen Dienste angeboten werden sollten, die tatsächlich im geschäftlichen Betrieb benötigt werden. Alle anderen Dienste sind zu deaktivieren oder zumindest von der direkten Erreichbarkeit auszuschließen.

Darüber hinaus wird empfohlen, nur autorisierten Benutzern Zugriff auf SAP-Systeme und -Dienste zu gewähren. Dies könnte über virtuelle private Netzwerke (VPN) umgesetzt werden, die ebenfalls ein sicheres Netzwerk bieten.

Ein solcher Ansatz verhindert, dass kritische Dienste direkt im öffentlichen Internet erreichbar sind, und reduziert die Angriffsfläche erheblich.

Die SySS GmbH rät daher, die Erreichbarkeit von SAP-Diensten systematisch zu überprüfen und auf den notwendigen Mindestumfang zu beschränken. Dies beinhaltet die regelmäßige Überprüfung der Dienstkonfigurationen, die Einschränkung der Zugriffsrechte auf den jeweils notwendigen Benutzerkreis und die Anwendung von Zugriffssteuerungsmechanismen wie Firewalls, Netzwerksegmentierung und zentrale Authentifizierung.

Zusammenfassend ist festzuhalten: Die Exponierung von SAP-Diensten, sei es im Internet oder im internen Netzwerk, ist ein signifikantes Sicherheitsrisiko. Eine proaktive, kontrollierte und auf Sicherheitsprinzipien basierende Steuerung der Dienstverfügbarkeit ist entscheidend, um die Integrität, Vertraulichkeit und Verfügbarkeit der SAP-Systeme langfristig zu gewährleisten.

2. Access Control Lists im Kontext von SAP-Systemen

In einer modernen SAP-Landschaft spielen Zugriffssteuerungsmechanismen eine zentrale Rolle für die Sicherheit und Integrität der Systeme. Insbesondere an den Schnittstellen zwischen Systemen und externen Anwendungen sind Access Control Lists (ACLs) als effektive Werkzeuge zur Steuerung von Zugriffen von entscheidender Bedeutung. ACLs ermöglichen die gezielte Einschränkung oder Freigabe von Zugriffen auf Dienste, Endpunkte oder Systemressourcen – basierend auf IP-Adressen, Hostnamen, Benutzergruppen oder anderen Identifikatoren.

Zwei zentrale Komponenten in der SAP-Architektur, bei denen ACLs eine besondere Relevanz besitzen, sind:

• SAP Gateway (SAP NetWeaver Gateway)

Das Gateway dient als zentrale Schnittstelle für die Bereitstellung von OData- und REST-basierten APIs. Da es direkten Zugriff auf unterliegende SAP-Systeme und Daten ermöglicht, ist eine präzise Kontrolle über die Quellen, die auf diese APIs zugreifen dürfen, von höchster Bedeutung. Hier sind ACLs entscheidend, um sicherzustellen, dass nur autorisierte Clients (z. B. interne Anwendungen, mobile Apps oder externe Partner) auf die Dienste zugreifen können.

• SAP Message Server

Der Message Server ist zentral für die Kommunikation zwischen SAP-Systemkomponenten (z. B. Application Server, Central Services). Er ermöglicht die Verbindung von Prozessen innerhalb einer Systemlandschaft. Die Kontrolle über die Hosts, die mit dem Message Server kommunizieren dürfen, ist daher entscheidend, um unerwünschte oder unbefugte Systemkommunikation zu verhindern – insbesondere im Kontext von Angriffen wie Server-Side Request Forgery (SSRF) oder innerhalb von Cloud- oder Hybrid-Infrastrukturen.

Trotz der technischen Möglichkeit zur Implementierung von ACLs wird diese Funktion in vielen Unternehmen entweder nicht aktiviert oder nicht konsequent angewendet oder nicht überwacht. Häufig werden ACLs zwar angelegt und dokumentiert, jedoch ohne strikte Durchsetzung.

Dies führt zu folgenden Risiken:

• Unkontrollierte Zugriffe: Da keine Einschränkung erfolgt, können beliebige Systeme oder IP-Adressen auf kritische Dienste zugreifen, was das Risiko von Datenlecks, Manipulationen oder Angriffen erhöht.

• Fehlende Nachverfolgbarkeit: Ohne eine klare Zugriffssteuerung ist es schwierig, Sicherheitsvorfälle zu identifizieren oder die Ursache von Datenzugriffen zu rekonstruieren.

• Verletzung des Prinzips der minimalen Berechtigung (Least Privilege-Prinzip): Unbegrenzter Zugriff auf APIs oder Systemdienste führt zu einer Erweiterung des Angriffsvektors, insbesondere wenn ein System kompromittiert wird.

Besonders kritisch ist die Tatsache, dass viele Organisationen eine passive ACL-Pflege betreiben – also Listen erstellen, aber keine technische Sperre oder Überprüfung implementieren. Dies führt zu einem falschen Sicherheitsgefühl, da die Maßnahmen „auf dem Papier“ existieren, aber in der Praxis keine Wirkung entfalten.

Um die Sicherheit der SAP-Landschaft zu stärken, empfiehlt die SySS GmbH eine umfassende und proaktive Nutzung von ACLs mit folgenden Prinzipien:

• Aktivierung und Erzwingung von ACLs: ACLs sollten nicht nur konfiguriert, sondern auch aktiviert und technisch erzwungen werden. Die Verwendung von „passiven“ Listen ohne Durchsetzung ist nicht wirksam und stellt eine Sicherheitslücke dar.

• Implementierung eines expliziten Allowlist-Ansatzes: Es sollte stets der prinzipiell verweigernde Ansatz (Deny by Default) angewendet werden, der nur explizit erlaubte Zugriffe zulässt. Dies bedeutet:

           - Alle Zugriffe sind standardmäßig verboten.

           - Nur diejenigen IPs, Hosts oder Systeme, die explizit in die ACL eingetragen sind, dürfen kommunizieren.

           - Die Liste sollte so kurz wie möglich gehalten werden, um das Risiko von Missbrauch zu minimieren.

• Regelmäßige Überprüfung und Aktualisierung: ACLs sollten regelmäßig auf Aktualität überprüft werden. Bestehende Einträge sollten auf ihre Relevanz hin geprüft und veraltete oder nicht mehr benötigte Einträge sollten entfernt werden. Dies beugt der sogenannten „ACL-Bloat“-Problematik vor, bei der sich über Jahre hinweg unkontrollierte Zugriffsrechte ansammeln.

• Integration in Sicherheits- und Compliance-Prozesse: ACLs sollten Bestandteil von Sicherheitsaudits, Change-Management-Prozessen und Compliance-Checklisten sein. Änderungen an ACLs sollten dokumentiert und genehmigt werden – beispielsweise über den SAP-Change Management (RFC, Transport etc.).

• Überwachung und Logging: Die Verwendung von ACLs sollte mit umfassender Log- und Monitoring-Unterstützung kombiniert werden. Alle Zugriffsversuche – sowohl erlaubte als auch abgelehnte – sollten protokolliert werden, um Anomalien oder Angriffsversuche frühzeitig erkennen zu können.

Zusammenfassend lässt sich festhalten: Die fehlende oder unzureichende Nutzung von ACLs in einer SAP-Landschaft ist eine der klassischen Sicherheitslücken, die leicht zu beheben sind, aber häufig vernachlässigt werden. Insbesondere an kritischen Schnittstellen wie SAP Gateway und SAP Message Server ist eine strenge Zugriffssteuerung nicht nur empfehlenswert, sondern unverzichtbar.

Die Implementierung eines klaren, technisch durchgesetzten und regelmäßig überwachten ACL-Managements ist ein zentraler Baustein für eine robuste SAP-Sicherheitsarchitektur und trägt erheblich zur Einhaltung von Standards bei.

3. Unverschlüsselte Kommunikation in SAP-Systemlandschaften

Trotz der fortschreitenden Digitalisierung und der zunehmenden Bedeutung von Cybersicherheit werden in vielen SAP-Systemlandschaften nach wie vor Kommunikationsprotokolle eingesetzt, die keine Verschlüsselung der übertragenen Daten bieten. Diese Praxis stellt eine erhebliche Sicherheitslücke dar und erhöht das Risiko des Abfangens, der Manipulation und des unbefugten Zugriffs auf Daten erheblich.

Insbesondere die Kommunikation über RFC (Remote Function Call) und DIAG (Dynamic Information and Action Gateway) erfolgt in vielen Umgebungen noch unverschlüsselt, was die Übertragung sensibler Geschäftsdaten, Anmeldeinformationen und Systemparameter über das Netzwerk ohne Schutz ermöglicht. Ähnlich kritisch sind klassische Protokolle wie FTP (File Transfer Protocol), HTTP (Hypertext Transfer Protocol) oder Telnet, die in vielen Fällen weiterhin in der Praxis verwendet werden – oft aus Gründen der Kompatibilität oder mangelnder Umstellungsstrategien – trotz ihrer bekannten Sicherheitsdefizite.

Da diese Dienste keine integrierte Verschlüsselung bieten, können Angreifer über sogenannte Packet Sniffing-Techniken die übertragenen Daten während der Übertragung abfangen und auswerten. Dies kann zu schwerwiegenden Folgen führen, darunter der Verlust vertraulicher Unternehmensdaten, die Entnahme von Zugangsdaten, die Manipulation von Transaktionen oder die Ausnutzung von Schwachstellen zur Etablierung von persistenten Zugriffen auf die SAP-Infrastruktur.

Die SySS GmbH empfiehlt daher, die Nutzung unverschlüsselter Kommunikationsprotokolle grundsätzlich zu vermeiden und stattdessen auf sichere Alternativen umzusteigen. Dazu zählen beispielsweise:

• SFTP (Secure File Transfer Protocol) anstelle von FTP
• HTTPS (HTTP Secure) anstelle von HTTP
• SSH (Secure Shell) anstelle von Telnet

Für die Kommunikation zwischen SAP-Systemen sollte SNC (Secure Network Communications) als Standard für die Verschlüsselung und Authentifizierung eingesetzt werden, was die RFC- und DIAG-Verbindungen betrifft. SNC ermöglicht eine sichere, verschlüsselte Kommunikation, die sowohl die Integrität als auch die Vertraulichkeit der Daten gewährleistet. In Fällen, in denen eine Umstellung auf sichere Alternativen technisch oder organisatorisch nicht sofort möglich ist, ist eine bestmögliche Abschottung der betroffenen Dienste erforderlich. 

Dazu gehören:

• Isolierung der betroffenen Dienste in dedizierten Netzwerksegmenten
• Einschränkung des Zugriffs auf autorisierte IP-Adressen oder Hosts
• Implementierung von Firewalls und Intrusion Detection/Prevention-Systemen (IDS/IPS)
• Regelmäßige Überwachung und Protokollierung von Kommunikationsaktivitäten

Zusammenfassend ist festzuhalten: Die Fortführung unverschlüsselter Kommunikation in SAP-Systemlandschaften ist ein erhebliches Sicherheitsrisiko, das in der heutigen Bedrohungslandschaft nicht mehr akzeptabel ist. Eine systematische Überprüfung der Kommunikationswege, die Umstellung auf sichere Protokolle und die Anwendung von Schutzmaßnahmen wie SNC oder Netzwerksegmentierung sind entscheidende Schritte zur Stärkung der IT-Sicherheit und zur Einhaltung von Datenschutz- und Cybersicherheitsstandards.

4. Weitreichende Berechtigungen

Die Verwaltung von Berechtigungen in SAP-Systemlandschaften ist ein entscheidender Faktor für die Einhaltung von Sicherheitsstandards und die Reduzierung von Angriffsvektoren. In der Praxis zeigt sich jedoch häufig eine unübersichtliche und unzureichend kontrollierte Vergabe von Berechtigungen, die zu erheblichen Sicherheitsrisiken führen kann. Insbesondere die Zuweisung von administrativen Rechten an Benutzer, die keine entsprechende Verantwortung oder Aufgabenstellung erfordern, stellt eine gravierende Schwachstelle dar.

Ein typisches und weit verbreitetes Problem ist die Vergabe der höchstmöglichen Berechtigungen über das SAP_ALL-Profil oder die SAP_NEW-Rolle, die in der Regel den vollen Zugriff auf alle Funktionen, Daten und Systeme innerhalb eines SAP-Systems ermöglicht. Diese Rollen werden oft ohne ausreichende Begründung oder Kontrolle an Benutzer vergeben, was zu einer übermäßigen Anzahl an „Super-User“-Konten führt. In mehreren Sicherheitsüberprüfungen (Security Reviews) wurde festgestellt, dass in kritischen SAP-Systemen eine signifikante Anzahl von Benutzern über diese umfassenden Berechtigungen verfügt – ein Zustand, der das Risiko von Missbrauch, internen Angriffen oder systemischen Ausfällen erheblich erhöht.

Die zugrunde liegende Ursache hierfür ist oft eine mangelnde Prozess- und Governance-Struktur bei der Berechtigungsvergabe. So werden in vielen Unternehmen Berechtigungen aufgrund von Kompatibilitätsproblemen, fehlenden Rollenkonzepten oder fehlender Überwachung nicht gezielt nach dem Prinzip der geringsten Berechtigung (Principle of Least Privilege) vergeben. Stattdessen werden standardisierte, hochprivilegierte Rollen als „schnelle Lösung“ eingesetzt, was langfristig zu einer unübersichtlichen Berechtigungslandschaft führt.

Ein besonderes Risiko ergibt sich aus der Zuweisung sogenannter Debug-Berechtigungen, was über das Berechtigungsobjekt S_DEVELOP umgesetzt wird. Diese Berechtigung ermöglicht es Benutzern, den Systemdebugger zu aktivieren, was wiederum die Berechtigungsüberprüfung umgehen lässt und direkten Zugriff auf kritische Systemfunktionen, Daten und Prozesse erlaubt. In der Praxis wurde mehrfach beobachtet, dass solche Berechtigungen an Entwickler oder Support-Mitarbeiter vergeben wurden, obwohl kein rechtfertigender Bedarf für den Einsatz des Debuggers bestand. Die Folge kann eine vollständige Kontrolle über das System durch einen einzelnen Benutzer sein, was die Grundlage für schwerwiegende Sicherheitsvorfälle bildet.

Darüber hinaus existieren weitere Berechtigungsobjekte mit administrativen Funktionen, wie beispielsweise S_TABU_DIS (Zugriff auf Tabellen, die Sicherheitsregeln definieren), S_RFC (Rollen für Remote Function Call-Verbindungen) oder S_USER_GRP (Verwaltung von Benutzergruppen), die bei unsachgemäßer Zuweisung zu erheblichen Sicherheitslücken führen können.

Die SySS GmbH empfiehlt daher eine systematische Überarbeitung der Berechtigungsstruktur in SAP-Systemen.

Kernprinzipien hierbei sind:

• Prinzip der minimalen Berechtigung: Jeder Benutzer sollte nur die Berechtigungen erhalten, die unbedingt erforderlich sind, um seine Aufgaben zu erfüllen.

• Feingranulare Berechtigungsvergabe: Die Nutzung von Berechtigungsobjekten ermöglicht eine detaillierte Steuerung der Zugriffsrechte. So können beispielsweise Zugriffe auf spezifische Transaktionen, Datenbereiche oder Funktionen gezielt freigegeben oder eingeschränkt werden.

• Regelmäßige Berechtigungsüberprüfungen: Eine kontinuierliche Überprüfung der Berechtigungen (z. B. jährlich oder bei Personalwechsel) ist essenziell, um ungenutzte oder übermäßige Rechte zu identifizieren und zu entfernen.

• Vermeidung von Standardrollen: Die Nutzung von SAP_ALL oder SAP_NEW sollte strikt eingeschränkt werden und nur im Notfall und unter strenger Dokumentation erfolgen.

• Einschränkung des Zugriffs auf Debug- und Systemfunktionen: Debug-Berechtigungen und andere hochprivilegierte Rechte sollten nur nach ausführlicher Analyse und Genehmigung an qualifizierte Benutzer vergeben werden.

Zusammenfassend lässt sich festhalten, dass die Vergabe weitreichender Berechtigungen in SAP-Systemen ein erhebliches Sicherheitsrisiko darstellt, das durch unzureichende Prozesse und mangelnde Transparenz verstärkt wird. Eine gezielte, auf Sicherheitsprinzipien basierende Berechtigungsvergabe – unterstützt durch regelmäßige Überprüfungen, Schulungen und eine klare Governance-Struktur – ist entscheidend, um die Integrität, Vertraulichkeit und Verfügbarkeit der SAP-Infrastruktur und der auf ihr verarbeiteten Daten zu gewährleisten. Insbesondere in kritischen Systemumgebungen wie Finanz-, HR- oder Produktionsanwendungen ist eine solche Sicherheitsstrategie nicht nur empfehlenswert, sondern unverzichtbar.

5. Passwörter in SAP-Systemen

Die Sicherheit von Passwörtern bleibt ein grundlegendes und unverzichtbares Element der IT-Sicherheit, insbesondere in kritischen Unternehmenssystemen wie SAP. Als primäre Methode zur Authentifizierung von Benutzern stellen Passwörter die erste und oft entscheidende Schutzschicht dar. Ihre Schwächung oder unsichere Verwaltung kann die gesamte IT-Infrastruktur gefährden und zu unbefugtem Zugriff, Datenlecks oder sogar Systemkompromittierungen führen.

In der Praxis sind mehrere zentrale Aspekte entscheidend für die Passwortsicherheit:

• Passwortlänge: Längere Passwörter sind resistent gegen Brute-Force-Angriffe. Empfohlen werden mindestens zwölf Zeichen, wobei längere Passwörter (z. B. 14 bis 16 Zeichen) signifikant sicherer sind.

• Passwortkomplexität: Die Kombination aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen erhöht die Entropie und erschwert das Erraten oder automatisierte Brute-Force-Verfahren.

• Vermeidung der Wiederverwendung: Die Wiederverwendung von Passwörtern über verschiedene Systeme oder Konten ist ein erhebliches Risiko, da ein kompromittiertes Passwort dann mehrere Systeme gefährden kann.

• Gültigkeitsdauer: Initialpasswörter sollten nach einer festgelegten Zeitspanne (z. B. 7 bis 14 Tage) automatisch ablaufen und die erste Anmeldung erzwingen, um ein sicheres Passwort festzulegen. Benutzerkonten, die über einen längeren Zeitraum (z. B. 90 Tage oder mehr) nicht genutzt wurden, sollten automatisch gesperrt werden.

• Sperrung nach mehreren Fehlversuchen: Eine automatische Sperrung nach mehreren fehlgeschlagenen Anmeldeversuchen (z. B. nach fünf Versuchen) verhindert automatisierte Angriffe wie Brute Force oder Credential Stuffing. Anstelle einer dauerhaften Sperre sollte jedoch eine Sperre für einen bestimmten Zeitraum eingerichtet werden.

• Umgang mit Initialpasswörtern: Die Verwendung von Standard- oder Initialpasswörtern ist eine häufige Sicherheitslücke. Diese müssen unverzüglich nach der ersten Anmeldung geändert werden. Das System sollte die Änderung erzwingen.

In SAP-Systemen existiert eine besondere Herausforderung: die Möglichkeit, Passwörter in veralteten und unsicheren Speicherformen zu hinterlegen. Insbesondere die Formate BCODE und PASSCODE sind in älteren SAP-Versionen enthalten und bieten nur eine geringe Sicherheit. Diese Methoden basieren auf einfachen Hash-Algorithmen, die bei Bekanntwerden der Hash-Werte leicht durch Reverse Engineering, Passwort-Rateangriffe oder Lookup-Tabellen erraten werden können.

Ein entscheidender Sicherheitsaspekt ist daher die Verwendung moderner, sicherer Hash-Verfahren. In SAP wird hierfür der Standard PWDSALTEDHASH empfohlen.

Die SySS GmbH rät daher, die Passwortsicherheit in SAP-Systemen an aktuellen und etablierten Standards auszurichten.

Dazu gehören:

• Die vollständige Deaktivierung und Löschung von Passwörtern, die in den unsicheren Formaten BCODE oder PASSCODE gespeichert sind
• Die Aktivierung und Durchsetzung des sicheren PWDSALTEDHASH-Verfahrens als Standard
• Regelmäßige Audits der Passwortverwaltung und der Speicherformate durch technische Prüfungen
• Die Erzwingung der Passwortänderung bei Erstnutzung, nach Sicherheitsvorfällen oder bei Veränderungen der Benutzerrolle

Zusammenfassend ist die Passwortsicherheit kein einmaliger Maßnahmenkatalog, sondern ein kontinuierlicher Prozess, der durch technische Maßnahmen, klare Richtlinien und regelmäßige Überprüfungen unterstützt werden muss. In SAP-Systemen, bei denen die Authentifizierung eine zentrale Rolle spielt, ist die Verwendung sicherer Passwortformate wie PWDSALTEDHASH nicht nur eine Empfehlung, sondern eine unverzichtbare Voraussetzung für den Erhalt der Integrität und Vertraulichkeit sensibler Unternehmensdaten.

6. Standardkonfiguration in SAP-Systemen

Die Standardkonfiguration von SAP-Systemen, insbesondere in der Phase der Initialisierung und Installation, ist in vielen Fällen ein zentrales Sicherheitsrisiko. Während sie die schnelle Inbetriebnahme erleichtert, birgt sie erhebliche Gefahren, wenn sie nicht systematisch überprüft und angepasst wird. Insbesondere die Nutzung von Standardbenutzern mit Standardpasswörtern im produktiven Umfeld stellt eine der bekanntesten und am häufigsten ausgenutzten Schwachstellen dar, die von Angreifern gezielt für unbefugten Zugriff oder Systemkompromittierungen genutzt werden.

In der Praxis wird häufig beobachtet, dass eine Vielzahl von Standardbenutzern, die ursprünglich nur zur Systemverwaltung oder zur Initialisierung vorgesehen waren, auch nach der Inbetriebnahme aktiv bleiben und über unbefugte oder nicht notwendige Berechtigungen verfügen. Dies führt zu einer signifikanten Erweiterung des Angriffsvektors.

Zu den kritischsten Beispielen gehören folgende Standardbenutzer:

• SYSTEM: Dieser Benutzer verfügt über umfassende Administratorrechte und ist standardmäßig aktiv. Er sollte nach der ersten Systemkonfiguration deaktiviert werden, da er in der Regel im laufenden Betrieb nicht benötigt wird. Eine aktive Nutzung des SYSTEM-Benutzers erhöht das Risiko von schwerwiegenden Sicherheitsvorfällen erheblich.

• SAP*: Dieser Benutzer existiert in jedem SAP-System und ist standardmäßig aktiv. Er ist mit hohen Rechten ausgestattet und sollte deaktiviert und nicht verwendet werden. Insbesondere das Initialpasswort sollte niemals im produktiven Betrieb eingesetzt werden. Eine Überprüfung der Benutzerberechtigungen zeigt häufig, dass SAP* trotz Deaktivierung weiterhin Rechte zugewiesen hat – diese sollten dem Benutzer entzogen werden.

• DDIC: Der Benutzer DDIC ist für die Verwaltung des SAP-Systems zuständig und verfügt über umfassende Berechtigungen. Er sollte nicht mit dem Standardpasswort betrieben werden. Bei Verwendung im Produktivsystem ist eine Passwortänderung unbedingt erforderlich.

• TMSADM: Dieser Benutzer ist für die Verwaltung des Transport Management Systems (TMS) zuständig. Er sollte deaktiviert werden, wenn keine aktive Transportverwaltung im Unternehmen stattfindet. Auch hier ist die Verwendung des Standardpassworts eine erhebliche Sicherheitslücke.

• SAPCPIC: Dieser Benutzer ist für die Kommunikation zwischen SAP-Systemen zuständig. Wenn keine aktive Kommunikationsinfrastruktur (z. B. mit anderen Systemen über RFC oder IDoc) existiert, sollte der Benutzer gelöscht werden, um das Angriffsrisiko zu minimieren.

Ein weiterer kritischer Aspekt der Standardkonfiguration betrifft die Nutzung des Secure Storage – eines Mechanismus zur sicheren Speicherung sensibler Daten wie Passwörter, Zertifikate oder Schlüssel. In vielen Fällen wird hier der Standardschlüssel verwendet, der für alle Systeme identisch und somit öffentlich bekannt ist. Dies bedeutet, dass alle Daten, die mit diesem Schlüssel verschlüsselt wurden, nicht sicher sind und bei Zugriff durch einen Angreifer mit vergleichsweise geringem Aufwand entschlüsselt werden können.

Die Verwendung von Standardschlüsselmaterial ist eine gravierende Verletzung der Kryptografieprinzipien und stellt eine direkte Gefährdung für die Vertraulichkeit sensibler Informationen dar. Selbst wenn die Daten innerhalb des Systems geschützt erscheinen, können sie durch Ausnutzung des bekannten Schlüssels entschlüsselt werden, was insbesondere bei Datenlecks oder Systemdump-Angriffen katastrophale Folgen haben kann.

Um die Sicherheit von SAP-Systemen zu gewährleisten, empfiehlt die SySS GmbH eine umfassende Überprüfung und Anpassung der Standardkonfiguration:

• Deaktivierung oder Löschung von Standardbenutzern: Alle Standardbenutzer, die im produktiven Betrieb nicht benötigt werden, sollten deaktiviert oder gelöscht werden. Insbesondere SAP*, SYSTEM, SAPCPIC und TMSADM sind Kandidaten für eine Deaktivierung.

• Erzwingung einer Passwortänderung: Alle Standardpasswörter müssen vor Inbetriebnahme des Systems durch ein sicheres, komplexes Passwort ersetzt werden. Dies sollte durch technische Maßnahmen (z. B. durch SAP-Systemeinstellungen oder Überwachungsregeln) sichergestellt werden.

• Verwendung von sicheren Schlüsseln im Secure Storage: Der Standardschlüssel sollte nicht verwendet werden. Stattdessen muss ein eigenes, geheimes und sicher verwaltetes Schlüsselmaterial generiert und implementiert werden. Dies ist eine zentrale Maßnahme zur Gewährleistung der Datenverschlüsselung.

• Anlegen von benutzerdefinierten Benutzern: Statt auf Standardbenutzer zurückzugreifen, sollten eigene Benutzerkonten angelegt werden, die nur die notwendigen Berechtigungen erhalten. Dies entspricht dem Prinzip der minimalen Berechtigung und reduziert das Angriffsrisiko signifikant.

• Regelmäßige Audits und Überwachung: Die Konfiguration sollte regelmäßig überprüft werden, um sicherzustellen, dass keine Standardbenutzer aktiv sind und keine unsicheren Einstellungen bestehen.

Zusammenfassend ist festzuhalten: Die Standardkonfiguration eines SAP-Systems ist kein „Sicherheitsgrundstein“, sondern vielmehr eine potenzielle Gefahrenquelle. Die Aufrechterhaltung von Standardbenutzern, Standardpasswörtern oder bekannten Schlüsseln entspricht einem offenen Tor für Angreifer. Die Umsetzung einer sicheren, individualisierten Konfiguration ist daher keine Option, sondern eine zwingende Voraussetzung für die Integrität, Vertraulichkeit und Verfügbarkeit von SAP-Systemen im produktiven Betrieb.

7. Veraltete Systeme in SAP-Landschaften

Die technische Aktualität von SAP-Systemen ist ein entscheidender Faktor für die langfristige Sicherheit, Stabilität und Erfüllung von Compliance-Anforderungen einer Unternehmenslandschaft. Trotz der unbestrittenen Bedeutung aktueller Softwareversionen steht die Systemverfügbarkeit häufig im Spannungsfeld mit der Notwendigkeit von Updates und Patches. Insbesondere in kritischen Produktivumgebungen ist die Planung von Wartungszeiten, die Sicherstellung von Datensicherheit und die Vermeidung von Ausfallzeiten eine zentrale Herausforderung. Dennoch darf diese Herausforderung nicht als Rechtfertigung für die Vermeidung von Aktualisierungen dienen.

Veraltete Software stellt eine der häufigsten Ursachen für Sicherheitsvorfälle in der IT-Infrastruktur dar – dies gilt auch für SAP-Systeme. Veraltete Systeme weisen folgende Risiken auf:

• Unbehobene Sicherheitslücken (Vulnerabilities): Mit der Zeit werden in SAP-Systemen bekannte Schwachstellen entdeckt und durch Security Patches geschlossen. Systeme, die nicht regelmäßig aktualisiert werden, bleiben anfällig für Angriffe.

• Fehlende Unterstützung und Patchupdates: SAP stellt nach dem EOL (End of Life) keine technische Unterstützung mehr zur Verfügung. Dies bedeutet, dass kritische Sicherheitspatches nicht mehr bereitgestellt werden, selbst wenn neue Bedrohungen identifiziert werden.

• Kompatibilitätsprobleme mit modernen Sicherheitsstandards: Alte Systeme sind oft nicht mit aktuellen Authentifizierungsmechanismen, Verschlüsselungsschemata oder Compliance-Anforderungen kompatibel.

• Vergrößerte Angriffsfläche: Je länger ein System in Betrieb ist, desto größer ist die Wahrscheinlichkeit, dass es bereits in der Vergangenheit unentdeckte Schwachstellen enthält, die von Angreifern gezielt ausgenutzt werden können.

Zahlreiche Beiträge – z. B. aus den SAP Security Notes, SAP News, von Security Bridge, ONAPSIS oder Supply Chain Brain – belegen, dass ein erheblicher Teil der SAP-Sicherheitsvorfälle auf die Nutzung veralteter Systeme zurückzuführen ist. Selbst wenn die Systeme intern nicht sichtbar sind, können sie über Schnittstellen, externe Dienste oder verbundene Anwendungen als Einfallstor dienen.

Um die Sicherheitslage zu stabilisieren und die Angriffsfläche kontinuierlich zu reduzieren, ist die Etablierung eines regelmäßigen und strukturierten Aktualisierungszyklus unverzichtbar. Dieser sollte folgende Prinzipien berücksichtigen:

• Proaktive Planung statt Reaktionsmanagement: Statt auf Sicherheitslücken zu reagieren, die bereits ausgenutzt wurden, sollte eine proaktive Strategie verfolgt werden, die regelmäßige Prüfung, Testung und Implementierung von Patches und Updates vorsieht.

• Definition klarer Aktualisierungsintervalle: Ein festgelegter Zeitrahmen (z. B. monatlich, vierteljährlich oder nach jeder SAP Security Note) für die Prüfung und Anwendung von Patches stellt sicher, dass Sicherheitslücken zeitnah geschlossen werden.

• Getrennte Umgebungen für Test und Produktion: Updates sollten zunächst in einem Test- oder Qualifizierungssystem (z. B. DEV, QA) getestet werden, um Kompatibilitätsprobleme, Abstürze oder Datenintegritätsrisiken zu identifizieren. Erst nach erfolgreicher Validierung werden die Patches in die Produktivumgebung übernommen.

• Automatisierte Überwachung und Berichterstattung: Die Verwendung von Tools zur Überwachung der Systemaktualität (z. B. SAP Solution Manager, SAP EarlyWatch Alert, Drittanbieter-Tools) ermöglicht eine kontinuierliche Einschätzung des Sicherheitszustands und die frühzeitige Erkennung von Verzögerungen im Aktualisierungsprozess.

• Integration in Governance und Compliance: Der Aktualisierungszyklus sollte Teil eines umfassenden IT-Sicherheits- und Compliance-Programms sein. Dies ermöglicht die Dokumentation von Aktualisierungsmaßnahmen für Audits, Prüfungen und regulatorische Anforderungen.

Die SySS GmbH empfiehlt, eine konsistente und nachvollziehbare Aktualisierungsstrategie zu etablieren, die auf folgenden Grundpfeilern basiert:

• Regelmäßige Prüfung von SAP Security Notes und Patch-Status
• Einhaltung eines definierten Zeitrahmens für die Anwendung von Patches (z. B. innerhalb von 30 Tagen nach Veröffentlichung)
• Vermeidung von „Technical Debt“ durch die kontinuierliche Modernisierung der SAP-Landschaft
• Förderung einer Kultur der Sicherheit, in der Aktualisierungen nicht als Hindernis, sondern als zentrale Sicherheitsmaßnahme verstanden werden

Zusammenfassend lässt sich festhalten: Die Vermeidung von Updates aus Verfügbarkeitsgründen ist eine kurzfristige Denkweise, die langfristig zu erheblichen Sicherheitsverletzungen, finanziellen Verlusten und regulatorischen Sanktionen führen kann. Die Sicherheit einer SAP-Landschaft hängt nicht nur von technischen Maßnahmen wie Firewalls oder Identity Management ab, sondern auch entscheidend von der technischen Aktualität der Systeme selbst.

Daher ist es eine unternehmerische Verantwortung, die Aktualisierung von SAP-Systemen nicht zu verschieben, sondern als zentrales Element der IT-Sicherheitsstrategie zu betrachten. Nur durch eine kontinuierliche und gut geplante Modernisierung kann die SAP-Landschaft gegen aktuelle und zukünftige Bedrohungen gewappnet werden – mit einem minimalen Sicherheitsrisiko und maximaler Betriebssicherheit.