SOX für SAP Realisierung von Sarbanes-Oxley-Anforderungen im SAP-Berechtigungskonzept

Ordnungsmerkmale

erschienen in: <kes> 2006^#3, Seite 51

Rubrik: Systeme und ihr Umfeld

Schlagwort: SOX-Compliance mit SAP

Zusammenfassung: Auch hiesige Unternehmen kommen häufig am Sarbanes-Oxley Act (SOX) nicht vorbei. Unser Autor beschreibt seinen Weg bei der praktischen Umsetzung der SOX-Anforderungen in einem SAP-Projekt in Deutschland.

Autor: Von Hans-Joachim Gaebert, Hamburg

Der US-amerikanische Sarbanes-Oxley Act (SOX) fordert den Schutz der Integrität von Finanzdaten und angemessene Kontrollen im Rahmen des Risikomanagements. Die Realisierung eines solchen Projekts sollte keinesfalls nur als lästiges Übel angesehen werden, da sie auch die Chance birgt, die eigene IT-Sicherheit insgesamt nachhaltig zu verbessern.

SOX kommt in Deutschland zwingend zur Anwendung, wenn das betreffende Unternehmen an der US-Börse notiert oder Tochter eines US-amerikanischen Konzerns ist. Aber auch freiwillig kann ein deutsches Unternehmen die SOX-Anforderungen für sich anwenden, vor allem wenn es in Handelsbeziehungen mit US-Unternehmen steht – und unter diese Kategorie fallen in einem Exportland wie Deutschland sehr viele Firmen.

Die Gesetzestexte von SOX selbst enthalten keine Sicherheitsanforderungen, orientieren sich aber am Sicherheitsstandard ISO 17799 sowie an den revisorischen Control Objectives for Information and related Technology (COBIT) und dem Integrated Framework des Committee of Sponsoring Organizations of the Treadway Commission ( [externer Link] www.COSO.org). So lässt sich anhand dieser Kriterien der Aufbau eines IT-Sicherheits-Management-Systems ableiten, das alle Sicherheitsmaßnahmen im Unternehmen zusammenfasst und transparent macht.

Bei der Umsetzung von SOX für das SAP-Projekt, das diesem Praxisbericht zugrunde liegt, wurden nicht einfach Standard-Checklisten abgehakt, sondern der Fokus lag vielmehr auf den größten Gefahren, die der materiellen Richtigkeit des Jahresabschlusses drohen, und den Maßnahmen zur Risikominderung und -vermeidung. Bezogen auf das SAP-Berechtigungskonzept heißt dies, dass an Benutzer vergebene Rechte alle identifizierten Risiken und die zugehörigen Kontrollmaßnahmen berücksichtigen müssen.

Die Projektumgebung bestand aus einem zentralen SAP-System für circa 1000 Benutzer aus ganz Europa mit vielen Buchungskreisen, Werken et cetera – im Einsatz waren alle SAP-Module außer HR (Personal). Mitgewirkt haben Spezialisten aus der IT-Abteilung für die einzelnen SAP-Module, Administratoren, Key-User aus den Fachabteilungen sowie der Verfasser als Projektleiter. Das Projekt wurde in folgenden Schritten realisiert: Risikoerkennung, Regeln aufstellen und validieren, Risikoanalyse, Risikovermeidung, Risikoreduzierung sowie der Einrichtung regelmäßiger Überprüfungen.

Risiko-Erkennung

Im ersten Schritt wurden Funktionen zusammengetragen, die mögliche Risiko-Anteile darstellen: SOX geht davon aus, dass mindestens zwei solcher Funktionen zusammen von einer Person ausgeführt werden müssen, um ein Risiko darzustellen. Zum Beispiel: Kann ein Benutzer sowohl Verkaufsrechnungen bearbeiten als auch einen Zahllauf durchführen, entsteht das Risiko, dass er eine fiktive Lieferantenrechnung anlegen und dafür eine Zahlung veranlassen kann und dadurch das Unternehmen schädigt.

In einer Risikobewertung wurden anschließend die größten Gefahren identifiziert und als kritisch definiert; hierzu dient eine "Risikomatrix" in Excel. Da SOX hier keinen Standard vorgibt, lag es im Ermessen des Unternehmens, die kritischen Risiken selbst festzulegen. Im konkreten Fall wurden diese im Projekt definiert und mit demjenigen Wirtschaftsprüfer abgestimmt, der später regelmäßige Audits durchführen soll.

Abbildung 1 zeigt einen Ausschnitt aus dem entsprechenden Excel-Dokument, in dem die SOX-relevanten Risiken als C (critical) vermerkt sind – hohe (H) und mittlere (M) Risiken wurden hingegen nicht weiter verfolgt. Alle Funktionen wurden mit einer ID-Nummer versehen: Beispielsweise wird als SOX-relevantes Risiko die Kombination aus den Funktionen AP01 und AP02 angesehen, da der zugezogene Wirtschaftsprüfer (WP) beide Funktionen, also auch ihre Kombination auf Benutzerebene, als SOX-relevant erachtet. Hingegen wurde beispielsweise die Kombination der Funktionen AP02 und AP04 – in Abstimmung mit dem WP – nicht als SOX-relevantes Risiko eingeschätzt, da dieser in AP04 keine SOX-relevanten Risikoanteile sah.

Abbildung 1: Die Identifikation SOX-relevanter Risiken wurde in einer Excel-Matrix erfasst.

Regelerstellung

Der zweite Schritt diente dazu Regeln aufzustellen und zu validieren, die helfen, Risiken in SAP-Rollen sowie im Benutzerstamm zu finden. Um das sinnvoll zu realisieren, wurde das SAP-Tool Virsa Compliance Calibrator eingesetzt: Die Regeln wurden in Virsa eingestellt, Funktionen definiert, mit Berechtigungen ausgeprägt und kritische Kombinationen von Funktionen als "critical" markiert.

Zudem wurden Kontrollen definiert und in Virsa eingepflegt, die geeignet sind, Fehler oder Betrug möglichst zu minimieren: SOX geht davon aus, dass Risiken zwar nicht immer auszuschließen, aber durch geeignete Kontrollen zu verringern sind (Mitigating Controls). Im Beispiel von Abbildung 2 kann das Risiko, Verkaufspreise zu modifizieren und eine entsprechende Verkaufsrechnung zu manipulieren (S023), bei einem Benutzer durch die Kontrolle (A4) der Preisreduzierungen und Rabatte an Kunden verringert werden.

Entsprechend den definierten Funktionen wurden anschließend die Berechtigungen der Benutzer angepasst. Hierzu wurden im SAP-Berechtigungskonzept so genannte SOX-Rollen gebildet, die Funktionen mit Risikoanteilen enthalten; zudem wurden die Benutzer festgelegt, die solche Rollen zugewiesen bekommen sollen.

Eine wichtige Maßnahme in diesem Zusammenhang war die Administration des Berechtigungskonzepts: Während die Pflege der Berechtigungen sinnvollerweise zentral administriert wird, entschied man sich, die Zuordnung der Berechtigungen an die Benutzer dezentral vorzunehmen. So liegt die Verantwortung für Prozesse und Daten in der Fachabteilung, die letztlich am besten weiß, was ihre Benutzer tun und welches die relevanten Risiken sind. Die Validierung dieses Schrittes erfolgte durch die Fachabteilungen in Zusammenarbeit mit dem Wirtschaftsprüfer.

Abbildung 2: Der Virsa Compliance Calibrator hilft bei der Identifizierung und Anpassung risikobehafteter SAP-Rollen und -Benutzer.

Risiko-Analyse

Anschließend galt es, in mehreren Durchläufen Risikoanalysen durchzuführen, um die SAP-Rollen "SOX-frei" zu bekommen und die SOX-Risiken zwischen Rollenpaaren zu ermitteln. Hierzu bietet das Virsa-Tool Simulationsmöglichkeiten: Wenn man einer Rolle eine Berechtigung entzieht oder hinzufügt, wird als Ergebnis angezeigt, ob diese Rolle SOX-Verletzungen enthält oder nicht. Entsprechendes geschieht mit mehreren Rollen, die ein Benutzer potenziell zusammen besitzen könnte.

Durch die Kombination mehrerer Rollen und die anschließende Analyse ist somit festzustellen, welche SOX-Verletzungen – theoretisch – auf Benutzerebene auftreten könnten. Danach werden Rollen entzogen oder hinzufügt und im Ergebnis zeigt sich, welche Risiken wegfallen würden oder hinzukämen. In diesem Prozess wurden im Projekt sowohl die Regeln aus dem zweiten Schritt als auch die SAP-Rollen mit dem Ziel angepasst, keine SOX-Risiken in Rollen zu "zementieren" und die potenziellen Risiken auf Benutzerebene kennenzulernen.

Risiko-Vermeidung

Um solche potenziellen Risiken bei Benutzern möglichst zu vermeiden, wurde anschließend erneut mit den Virsa-Simulationsmöglichkeiten überprüft, welche Risiken wegfallen, wenn man bestimmten Benutzern gezielt Rollen entzieht: Durch Funktionstrennung lassen sich beispielsweise Rollen auf andere Benutzer umverteilen, ohne dass die neuen Rollenbesitzer dadurch Risiken gleich mit übernehmen. Schwierig wird dieser Schritt bei kleinen Organisationseinheiten, in denen jeder Benutzer "alles" macht und sich daher eine Funktionstrennung kaum durchführen lässt. Abzuwägen ist zudem generell zwischen den Möglichkeiten zur Risikovermeidung durch Funktionstrennung und dem zusätzlichen Kontrollaufwand bei Risikoverminderung (s. u.)

Risiko-Minderung

Kontrollmaßnahmen können schließlich diejenigen Risiken reduzieren, die sich nicht vermeiden lassen. Zur Identifizierung von Fehlern und Manipulationen wurden im behandelten Projekt als notwendige Kontrollen Standardprotokolle und Auswertungs-Tools wie das Security Audit Log (SAL), Application Log, SAP Management of Internal Controls (MIC), Audit Information System (AIS) und wiederum der Compliance Calibrator eingesetzt – inzwischen alles SAP-eigene Tools. Die Namen der Kontrollverantwortlichen wurden hierzu in Virsa eingegeben und den Kontrollen zugeordnet. Aufgrund von Virsa-Auswertungen wurde den Verantwortlichen zudem dargestellt, welche Kontrollen sie für ihre Benutzer durchzuführen haben (vgl. Abb. 2). Sollte ein Verantwortlicher seine regelmäßigen Kontrollen vergessen, übernimmt das Tool auf Wunsch auch die Ausgabe von Alarmmeldungen.

Als sinnvolle Ergänzung für Kontrollen in allen Bereichen kann das SAP-Standardprotokoll Security Audit Log (SAL) dienen. Abbildung 3 zeigt beispielsweise fehlgeschlagene Transaktionen, die auftauchen, wenn ein Benutzer versucht, im SAP-System Missbrauch zu treiben.

Abbildung 3: Für Kontrollen bietet sich unter anderem das SAP Security Audit Log (SAL) an.

Regelmäßige Prüfung

Schwerpunkt des letzten Schritts im SOX-Projekt war die Festlegung einer regelmäßigen Überprüfung. Hierzu wurde ein Sicherheits-Administrator definiert, der mithilfe der Virsa-Auswertungen regelmäßig den Stand der Risiken ermittelt. Spezielle Management-Reports zeigen dabei an, wie viele Risiken in Form potenzieller SOX-Verletzungen auf Benutzerebene insgesamt existieren und wie viele eingerichtete Benutzer tatsächlich SOX-Verletzungen bedeuten. Diese Auswertungen dienen dazu, neue Verletzungen zu erkennen und möglichst zu vermeiden. Der Sicherheits-Administrator wertet zudem auch regelmäßig die genannten Standardprotokolle wie das SAL aus und informiert das Management bei aufgetretenen Verletzungen. Unabhängig davon wurde eine regelmäßige Überprüfung durch interne und externe Auditoren vereinbart.

Ein wesentlicher Aspekt war im Projekt zudem die Schulung der Administratoren und Kontrollverantwortlichen: Der SAP-Administrator muss schließlich wissen, welche Rollen SOX-relevant sind und welche Risiken sowie risikomindernden Kontrollen mit ihrer Zuordnung zu Benutzern verbunden sind. Der Kontrollverantwortliche muss erkennen können, welche Risiken sowie risikomindernden Kontrollen mit der Anforderung von SOX-relevanten Rollen verbunden sind. Ein Tool-Einsatz wie Virsa ist hierzu unerlässlich. Eine vollständige Dokumentation aller SOX-Prozeduren ist überdies Voraussetzung für die regelmäßigen Audits.

Fazit

SOX erreicht zunehmend auch Europa und Deutschland. Transparenz in der Darstellung der Unternehmenssituation ist ohnehin geboten; und nicht zuletzt besteht mit der Realisierung eines SOX-Projekts die Chance zur Verbesserung der IT-Sicherheit insgesamt. Durch Konzentration auf die wesentlichen Risiken sowie Unterstützung durch geeignete Tools lässt sich – zumindest im SAP-Umfeld – der damit verbundene Aufwand in Grenzen halten.

Hans-Joachim Gaebert (gaebert@t-online.de) ist Unternehmensberater für DV-Revision und DV-Sicherheit in Hamburg.