In jedem Unternehmen bilden Prozesse, Risiken und Kontrollen die Basis für das Interne Kontrollsystem (IKS). Dieses erstreckt sich über die gesamte Unternehmenslandschaft, um sicherzustellen, dass alle sogenannten Schutzobjekte des Unternehmens auch tatsächlich geschützt werden. Es ist dabei essenziell, dass sich das unternehmensweite IKS mit sämtlichen Schutzobjekten, wie dem Schutz von Leib und Leben der Mitarbeiter, den Vermögenswerten sowie den Daten und Informationen des Unternehmens auseinandersetzt. In diesem Zusammenhang muss jedes Unternehmen sicherstellen, dass es ausreichend Kontrollen für alle diese Themenbereiche definiert und implementiert.
Aufgrund von gesetzlichen Vorgaben ist ein IKS in jedem Unternehmen einzurichten. Die Detailausprägung hängt jedoch von der Geschäftstätigkeit bzw. Branche des jeweiligen Unternehmens ab. Die größte Herausforderung ist es, sicherzustellen, dass auch tatsächlich sämtliche Risiken im Zusammenhang der Prozesse im SAP®-System erkannt sind.
Prüfungshandlungen im SAP®-System – Modul BC
Welche Kontrollen können im Zusammenhang des IKS im SAP®-System definiert, bzw. wie können diese geprüft werden? Auch wenn die Zusammenstellung der Kontrollen bei jedem Unternehmen aufgrund von Abweichungen in den diversen Prozessen unterschiedlich sein kann, so gibt es doch ein paar Kontrollen, welche in der Regel immer vorkommen sollten. Die folgenden Prüfungshandlungen spiegeln nur einen Auszug dessen wider, was im Modul BC möglich ist. Außerdem ist zu beachten, dass neben diesen Prüfungshandlungen natürlich die regelmäßige Überprüfung des SAP®-Berechtigungskonzepts ein zusätzlicher wesentlicher Bestandteil ist und sich diese diversen Prüfungshandlungen ergänzen. Das Modul BC hat direkte bis indirekte Auswirkungen auf das IKS im Bereich der Fachmodule und damit auf die Geschäftsprozesse, weshalb diesem immer ausreichend Aufmerksamkeit gewidmet werden muss.
SAP® Standardprofile
Im SAP®-System gibt es einige Standardprofile, welche kritische bzw. umfassende Berechtigungen besitzen und daher einer regelmäßigen Kontrolle unterzogen werden müssen. Das Sammelprofil SAP_ALL ist eines dieser kritischen Profile, da es sehr weitreichende und kritische Berechtigungen enthält. Es können damit unerwünschte Änderungen (Verstoß gegen das Radierverbot) an internen Kontrollen oder sicherheitsrelevanten Systemeinstellungen vorgenommen werden.
Daher ist es unumgänglich, eine regelmäßige Kontrolle zur Überwachung der Zuweisung dieser Profile einzurichten. In den meisten Fällen wird nur zu einem Stichtag geprüft, ob im SAP®-System Benutzer mit diesen Profilen existieren. Die Interpretation der Ergebnisse wird ebenso in den meisten Fällen nicht vollständig korrekt vorgenommen, da die Konzentration in erster Linie nur auf den dialogfähigen Benutzern liegt, also Benutzer mit den Benutzertypen „Dialog“ und „Service“. Sämtliche Hintergrundbenutzer mit den Benutzertypen „System“ und „Kommunikation“ werden dabei viel zu häufig ausgeklammert, weil diese fälschlicherweise als weniger risikobehaftet angesehen werden.
Eine vollständige Prüfungshandlung in diesem Zusammenhang differenziert jedoch nicht zwischen den Benutzertypen, da jeder Benutzer nach dem Prinzip der minimalen Rechtevergabe berechtigt werden muss und auch die sogenannten Hintergrundbenutzer eine Gefahrenquelle darstellen können.
Mithilfe der Transaktion SUIM kann eine Auswertung der Benutzer durchgeführt werden, die SAP_ALL bzw. SAP_NEW besitzen. Am folgenden Beispiel erfolgte die Auswertung für SAP_ALL.
Abbildung 1: Benutzer mit SAP_ALL
Das Ergebnis aus Abbildung 1 muss noch weiter verfeinert werden, um nur die aktiven Benutzer anzuzeigen, dazu zahlt es sich aus, die Liste zu exportieren und außerhalb des SAP®-Systems auszuwerten.
Diese Auswertung reicht jedoch nicht aus, da sie nur einen Status-Quo darstellt. Die zusätzliche Frage, ob in einem bestimmten Zeitraum das Profil SAP_ALL zugewiesen oder entzogen wurde, muss ebenfalls Teil der Kontrolle sein. Diese kann ebenfalls über die Transaktion SUIM, oder über den Report RSUSR100N erfolgen.
Abbildung 2: Änderungsbelege der Benutzer mit SAP_ALL
Die Abbildung 2 zeigt sehr deutlich, dass im geprüften Zeitraum sehr viele Zuweisungen des Profils SAP_ALL vorgenommen wurden. Der nächste Schritt muss daher die Überprüfung der dazugehörigen Dokumentationen sein. Insbesondere darf der Änderer nicht gleich der Benutzer sein, da es sich hierbei um eine Umgehung des Vier-Augenprinzips handelt. Die zuvor gezeigten Prüfungshandlungen sind analog für alle weiteren SAP® Standardprofile durchzuführen.
Systemöffnungen
Das Customizing von betriebswirtschaftlichen Prozessen kann ausschließlich pro Mandanten gesperrt oder erlaubt werden. Hierfür existiert kein globaler Schalter für das gesamte System. Customizing, also die Pflege der Tabellen zur Steuerung des Systems und der betriebswirtschaftlichen Prozesse, als auch Anwendungsentwicklung, also die Pflege von Programmen, Menüs oder Bildschirmmasken etc., dürfen nicht in jedem SAP-System möglich sein.
In Produktivsystemen sollte grundsätzlich das gesamte System, somit alle Mandanten, gegen Änderungen gesperrt sein. In Entwicklungssystemen können die Mandanten, in denen nicht entwickelt werden soll, wie z.B. die Mandanten 000 und 066, einzeln gegen Änderungen gesperrt werden.
Neben der Kontrolle über die Mandanten- und Systemänderbarkeit, welche über die Tabelle T000 eingesehen werden kann, muss auch überprüft werden, ob diese Absicherung in einem bestimmten Zeitraum nicht geändert wurde. Und wenn es zu einer Systemöffnung gekommen ist, muss es dafür eine nachvollziehbare Begründung inklusive ausreichender Dokumentation existieren. Die Prüfung erfolgt über die Transaktion SCU3, über welche die Änderungsprotokolle der Tabelle T000 ausgewertet werden kann.
Abbildung 3: Änderungsbelege der Tabelle T000
Die Abbildung 3 zeigt, dass es im Betrachtungszeitraum keine Änderungen der Systemeinstellungen gegeben hat und damit der Status der Werte in der Tabelle T000 für diesen Zeitraum gültig war.
Fazit
Der Aufbau eines IKS stellt jedes Unternehmen vor einige Herausforderungen, wenn sichergestellt werden soll, dass alles wesentlichen Risiken berücksichtigt sind. In einem SAP®-System kann auf verschiedene Arten ein IKS eingerichtet werden. Einerseits kann bereits mittels automatischer präventiver Kontrollen sichergestellt werden, dass bestimmte Aktivitäten schon vorab unterbunden werden. Andererseits müssten diese jedoch auch immer mithilfe von Änderungsprotokollen über einen Zeitraum überwacht werden, um sicherzustellen, dass sie auch in diesem Zeitraum immer wirksam waren.
Eine andere Variante sind nachgelagerte manuelle detektivische Kontrollen, mit deren Hilfe definierte Sachverhalte analysiert werden, um sicherzustellen, dass bestimmte Ereignisse im geprüften Zeitraum nicht aufgetreten sind.
Unabhängig davon, welche Kontrollvariante implementiert wurde, muss ein Risikoverantwortlicher Mitarbeiter dafür Sorge tragen, dass diese Kontrollen aktiv sind und auch im definierten Zeitraum durchgeführt und dokumentiert werden.
Ungeachtet der Kontrollausprägung muss dem Modul BC immer ausreichend Aufmerksamkeit gewidmet werden, da es direkte bis indirekte Auswirkungen auf das IKS im Bereich der Fachmodule und damit auf die Geschäftsprozesse hat.