SOX-Compliance in SAP: Anforderungen, IT-Kontrollen und der Weg zur Automatisierung

Was SOX-Compliance im SAP-Kontext bedeutet

Der Sarbanes-Oxley Act wurde im Jahr 2002 als Reaktion auf Bilanzskandale großer US-Konzerne verabschiedet. Sein Ziel: den Schutz von Anlegern vor fehlerhafter oder manipulierter Finanzberichterstattung. Obwohl es sich dem Wesen nach um eine Finanzvorschrift handelt, stützt sie sich in erheblichem Maße auf IT-Generalkontrollen (ITGCs) als Teil einer umfassenden SAP-GRC-Strategie.

Die zugrundeliegende Logik ist klar: Sind die IT-Systeme, in denen Finanzdaten gespeichert, verarbeitet und weitergeleitet werden, nicht ausreichend gesichert, kann auch den auf diesen Daten basierenden Finanzberichten nicht uneingeschränkt vertraut werden. Die Absicherung des IT-Fundaments ist damit keine optionale Ergänzung, sondern eine Voraussetzung für glaubwürdige Finanzberichterstattung.

Im SAP-Umfeld bedeutet SOX-Compliance konkret: Unternehmen müssen Prüfern nachweislich belegen, dass geregelt ist, wer auf Finanzdaten zugreifen darf, wie Systemänderungen autorisiert und dokumentiert werden und wie sicherheitsrelevante Konfigurationen gepflegt werden. Dabei unterscheidet sich SOX von anderen Regelwerken wie der DSGVO oder NIST dadurch, dass es sich ausschließlich auf die Richtigkeit und Integrität von Finanzunterlagen konzentriert.

Das Nichtbestehen eines ITGC-Audits ist folgenreich: Eine festgestellte wesentliche Schwäche muss veröffentlicht werden — mit möglichen Auswirkungen auf den Börsenkurs und das Investorenvertrauen.

Die fünf zentralen Kontrollbereiche im Überblick

Ein strukturierter Ansatz für die SAP-Architektur ist Voraussetzung, um externe Prüfer zu überzeugen. Im Zentrum stehen fünf Bereiche, die in jedem SOX-Audit unter die Lupe genommen werden.

1. Zugriffsrisikomanagement und Aufgabentrennung

Prüfer prüfen zunächst, ob Nutzer ausschließlich die Berechtigungen besitzen, die ihre konkrete Aufgabe erfordert. Dieses als „Prinzip der minimalen Berechtigung“ bekannte Konzept ist die Grundlage eines ordnungsgemäßen SAP-Zugriffsrisikomanagements.

Noch zentraler ist die Einhaltung der Segregation of Duties (SoD): Kein einzelner Nutzer darf die Befugnis haben, zwei miteinander unvereinbare, sensible Vorgänge auszuführen. Ein klassisches Beispiel: Die Person, die einen neuen Lieferanten anlegt, darf nicht dieselbe sein, die anschließend eine Zahlung an diesen Lieferanten veranlassen kann. Diese Trennung verhindert, dass ein einzelner Insider Finanzdaten unbemerkt manipulieren kann.

Besondere Aufmerksamkeit erhalten übermäßig ausgestattete Standardkonten wie SAP* oder DDIC. Sie gelten in Prüfungsberichten als deutliche Warnsignale und sollten konsequent deaktiviert oder eingeschränkt werden.

2. Sicherheitsrelevante Systemparameter

SAP-Systeme steuern ihr Verhalten über hunderte von Profilparametern. Prüfer verlangen Nachweise, dass diese Parameter gemäß Branchenstandards und internen Richtlinien konfiguriert sind — und nicht auf unsicheren Standardwerten belassen wurden.

Geprüft werden unter anderem:

• Mindestanforderungen an die Passwortkomplexität
• Begrenzung fehlgeschlagener Anmeldeversuche
• Automatische Sitzungszeitlimits bei Inaktivität

Werden diese Parameter auf Standardwerten belassen, erhöht sich das Risiko eines unbefugten Zugriffs auf finanzrelevante Daten erheblich.

3. Patch-Management

Selbst ein lückenlos konfiguriertes Berechtigungssystem verliert an Wirksamkeit, wenn die zugrundeliegende SAP-Anwendung bekannte, ausnutzbare Schwachstellen enthält. Das Patch-Management ist deshalb ein eigenständiger Prüfungsbereich innerhalb der ITGCs.

Erwartet wird der dokumentierte Nachweis, dass SAP-Sicherheitshinweise systematisch beobachtet und relevante Patches innerhalb eines definierten Zeitrahmens eingespielt werden. Ziel ist es zu verhindern, dass Angreifer öffentlich bekannte Schwachstellen nutzen, um Autorisierungsmechanismen zu umgehen und Finanzdaten zu verändern.

4. Änderungsmanagement und Transportprozesse

SOX schreibt vor, dass keine nicht autorisierten Änderungen an Systemen vorgenommen werden dürfen, die finanzrelevante Prozesse betreffen. Im SAP-Kontext dreht sich das um den Transportmanagementprozess.

Jede Änderung — ob benutzerdefinierter ABAP-Code oder eine Systemkonfiguration in der Entwicklungsumgebung — muss über einen klar definierten, nachvollziehbaren und genehmigten Weg die Produktionsumgebung erreichen. Prüfer untersuchen, ob Transportaufträge Genehmigungsworkflows umgehen können oder ob während des Migrationsprozesses nicht autorisierter Code eingeschleust werden könnte.

Können diese Fragen nicht zufriedenstellend beantwortet werden, gilt die Integrität der Produktionsumgebung als nicht ausreichend gesichert.

5. Kontinuierliche Überwachung und Protokollierung

Prüfer verlangen nicht nur den Nachweis, dass Kontrollen vorhanden sind — sie wollen auch belegt sehen, dass das System aktiv auf unerlaubte Aktivitäten überwacht wird. Das setzt voraus, dass der SAP Security Audit Log (SAL) ordnungsgemäß konfiguriert ist und alle sicherheitsrelevanten Transaktionscodes, Parameteränderungen und Hintergrundjobs lückenlos erfasst.

Nimmt ein privilegierter Nutzer eine Änderung an einer finanzrelevanten Tabelle vor, muss das System einen unveränderlichen Prüfpfad erzeugen, der diese Aktion dokumentiert. Fehlt dieser Prüfpfad, ist eine nachträgliche Aufklärung von Vorfällen nicht möglich.