In diesem Blog Post stelle ich ein Vorgehen zur Analyse von Funktionstrennungskonflikten ohne Drittanbieter-Tools vor. Alles, was Sie für die Auswertung benötigen, finden Sie in Ihrem Standard SAP System wieder. Das Vorgehen wird für 5 kritische SoD Konflikte vorgestellt, die Sie auf diese Weise auswerten können.
Wenn Sie die automatisierte Auswertung bevorzugen, dann werfen Sie doch mal einen Blick auf die integrierte Analyse in der kostenlosen Version von zap Audit.
Segregation of Duties
Um Missbrauch kritischer Kombinationen von Tätigkeiten innerhalb eines Prozesses zu verhindern, werden Funktionen innerhalb eines Unternehmens getrennt (engl. Segregation of Duties, kurz SoD). Präventive Maßnahmen im Berechtigungswesen des Unternehmens sollen dazu beitragen, dass einzelne User keine Möglichkeit haben, ihre Berechtigungen für kriminelle Handlungen zu missbrauchen. Damit präventive Maßnahmen gegen kriminelle Handlungen getroffen werden können, müssen die SoD Konflikte zunächst identifiziert werden. Vor der Umsetzung der Maßnahmen ist eine Analyse erforderlich, für die es zwei Ansätze gibt: Den proaktiven Ansatz, der die Berechtigungen / Berechtigungsobjekte eines Users untersucht, und den reaktiven Ansatz, in dem bereits aufgetretene Missbrauchsfälle in der Funktionstrennung aufgedeckt werden. Konflikte in der Funktionstrennung sind in diversen Bereichen eines Unternehmens, wie z.B. im Order-to-Cash (O2C) / Verkauf oder Purchase-to-Pay (P2P) / Einkauf zu finden.
Führt eine einzelne Person eine Kombination aus kritischen Tätigkeiten innerhalb eines Prozesses durch, wird dies als Konflikt angesehen, da die Möglichkeit besteht, dass die Person nicht im Interesse des Unternehmens gehandelt hat. Der Konflikt dient als Indikator für mögliche kriminelle Handlungen zwischen zwei Tätigkeiten. Selbstverständlich beruht nicht jeder Konflikt, der von einem Nutzer ausgelöst wird auf krimineller Intention. Kam es jedoch tatsächlich zu kriminellen Handlungen, lassen sich diese unter Berücksichtigung eines vollständigen Regelwerks mit dem Funktionstrennungskonflikt als Indikator identifizieren.
Voraussetzung für das Aufdecken von SoD Konflikten ist, dass beide in Konflikt stehenden Tätigkeiten von einem User im System durchgeführt wurden. Kriminelle Handlungen, die über den Täter als einzelne Person hinausgehen, wie z.B. eine Absprache zwischen zwei oder mehreren Mitarbeitern, werden in diesem Artikel nicht berücksichtigt.
5 kritische Funktionstrennungskonflikte
P2P: Pflege der Kreditorenstammdaten + Kreditorenstammdaten bestätigen
Ein User kann Kreditorenstammdaten anlegen, ändern und gleichzeitig die Änderungen bestätigen, ohne das Vier-Augen-Prinzip einhalten zu müssen. So können fiktive Lieferanten und Bankkonten angelegt und verändert werden, um z.B. Zahlungen umzuleiten. Als Kompensationskontrolle sollte vor jedem Zahllauf das „Master Data Change Protocol“ überprüft werden. Dieses lässt sich über die Transaktion „FK04“ einsehen. Zu kontrollieren ist, ob für einen Kreditorenstammsatz sowohl die Pflege als auch die Bestätigung von einem User vorgenommen wurde. Die Kontrolle sollte von einer Person durchgeführt werden, die selbst nicht zur Stammdatenpflege berechtigt ist.
Welcher User welche Kreditorenstammdaten angelegt hat, zeigt z.B. die Tabelle „LFB1“ (Lieferantenstamm (Buchungskreis)), technisches Feld ERNAM (Name des Sachbearbeiters, der das Objekt hinzugefügt hat). In der Tabelle „CDHDR“ (Änderungsbelegkopf) sind alle Freigaben von Kreditorenstammdaten hinterlegt. Beschränkt man die Ausgabe der „CDHDR“ z.B. auf den verwendeten Transaktionscode „FK08“ oder „FK09“ (Freigabe Kreditoren), bekommt man alle Freigaben mit den jeweiligen Usern. Mithilfe der Transaktion „SQVI“ lassen sich beide Tabellen über den User verbinden (Tabelle LFB1 technisches Feld ERNAM mit der CDHDR technisches Feld USERNAME). Mit dem Hinzufügen des Selektionsfeldes für einen Transaktionscode kann das Ergebnis auf „FK08“ und „FK09“ eingegrenzt werden. Anhand des Ergebnisses können anschließend all diejenigen User identifiziert werden, die beide Funktionen durchgeführt haben. Ob ein User seine eigens angelegten Kreditoren bestätigt hat, kann ohne ABAP Programmierung an dieser Stelle nicht überprüft werden, da die entsprechenden Feldtypen der Tabellen keine Verbindung über die Lieferantennummer zulassen.
Listenfeldauswahl:
- LFB1 – Name des Sachbearbeiters
- LFB1 – Kontonummer des Lieferanten / Kreditors
- CDHDR – Transaktionscode
- CDHDR – Benutzername des Änderers im Änderungsbeleg
- CDHDR – Objektwert
- CDHDR – Objektklasse
Das Ergebnis der Analyse zeigt, ob ein User die Rechte besitzt, Kreditoren anlegen und bestätigen zu können. Unter Umständen wurde so ein vorgesehenes Vier-Augen-Prinzip in der Stammdatenpflege umgangen.
P2P: Anlegen/ Verändern von Bestellungen + Freigabe von Bestellungen
Für das Anlegen und Verändern von Bestellungen und deren Freigabe in der Warenbeschaffung sollte ebenfalls ein Vier-Augen-Prinzip implementiert sein. Die Kombination beider Berechtigungen eines Users kann dazu führen, dass nicht autorisierte Bestellungen getätigt werden.
Welcher User welche Bestellungen angelegt hat, können Sie in der Tabelle „EKKO“ (Einkaufsbelegkopf) einsehen. Zu jeder Bestellung wird in SAP ein User angeführt, der eine Bestellung angelegt hat.
In der Tabelle „CDHDR“ finden Sie dazugehörige Änderungsdokumente. Bestellungen lassen sich mit den Transaktionen „ME28“, „ME29“ und „ME29N“ freigeben. Um auch nur diese Ergebnisse zu erhalten, muss die Ausgabe der Dokumente auf Tätigkeiten mit diesen Transaktionen eingeschränkt werden. Die Ausgabe beinhaltet alle Freigaben der Bestellungen mit dem jeweiligen User.
Um einen Konflikt in der Funktionstrennung zu identifizieren, können Sie im ersten Schritt überprüfen, ob es User gibt, die sowohl Bestellungen angelegt als auch Bestellungen freigegeben haben. Sollten die User der beiden Tabellen keine Schnittmenge bilden, liegen keine Funktionstrennungskonflikte vor.
Benutzen Sie für die Analyse erneut die Quickviewer Transaktion „SQVI“ und verknüpfen Sie die Tabellen über den User folgendermaßen: Tabelle „EKKO“ technischer Name „ERNAM“ mit der Tabelle „CDHDR“ und dem technischen Namen „USERNAME“ (vgl. Abbildung 1). Schränken Sie die Ausgabe der Tabelle „CDHDR“ auf die Transaktionen zur Freigabe von Bestellungen unter dem Reiter Selektionsfelder – Transaktionscode ein. Als Ausgabe wählen Sie die Belegnummer des Einkaufsbelegs mit dem zugehörigen User der Tabelle „EKKO“, der die Bestellung angelegt hat, und den Objektwert mit zugehörigem User der Tabelle „CDHDR“. Da aufgrund der unterschiedlichen Objekttypen die Belegnummer und der Objektwert ohne ABAP Programmierung kein Verbund möglich ist, besteht nur die Möglichkeit einer manuellen Auswertung.
Listenfeldauswahl:
- EKKO – Name des Sachbearbeiters
- EKKO – Belegnummer des Einkaufsbelegs
- CDHDR – Transaktionscode
- CDHDR – Benutzername des Änderers im Änderungsbeleg
- CDHDR – Objektwert
- CDHDR – Objektklasse
Das Ergebnis zeigt Ihnen zunächst diejenigen User, die beide Funktionen durchgeführt haben. Sie können nun die Belegnummer aus der Tabelle „EKKO“ mit dem Objektwert der Tabelle „CDHDR“ vergleichen. Stimmen die Werte der Felder überein, hat der User die Bestellung angelegt und auch freigegeben: Ein Konflikt in der Funktionstrennung liegt vor.
Das Vergleichen der Werte beider Tabellen kann bei großen Datensätzen sehr mühsam sein. Unser Tipp: Exportieren Sie die Ausgabe in eine Excel Datei. Grenzen Sie das Ergebnis auf die Zeilen ein, in denen der Einkaufsbeleg gleich dem Objektwert ist. Das Ergebnis der Auswertung beschränkt sich auf das Anlegen von Bestellungen. Bestelländerungen werden in dem Vorgehen nicht berücksichtigt. Änderungen werden ebenfalls in der Tabelle „CDHDR“ mit der korrespondierenden Transaktion „ME22/ME22N“ hinterlegt. Die „SQVI“ verbietet das mehrfache Verwenden einer Tabelle in einer Abfrage, daher ist eine Analyse von Bestelländerungen und Bestellfreigaben auf diesem Wege leider nicht möglich.
Abbildung 1: Verbund EKKO zu CDHDR für SoD Analyse
P2P: Anlegen/Verändern von Bestellungen + Wareneingangsbuchung vornehmen
In diesem Konflikt kann ein User eine Bestellung anlegen, verändern und gleichzeitig eine fiktive Wareneingangsbestätigung vornehmen. Als Szenario wäre die Absprache unter einem Kreditor und einem Mitarbeiter vorstellbar, indem eine Bestellung aufgegeben und der Wareneingang ohne erfolgte Leistung bestätigt wird.
In der Tabelle „EKKO“ sind die Bestellungen und der User in dem technischen Feld „ERNAM“ zu finden. In der Tabelle „MKPF“ (Belegköpfe des Materialbelegs) finden Sie den verantwortlichen User für die Buchung des Wareneingangs im technischen Feld „USNAM“. Zu prüfen ist, ob die Person, die eine Bestellung in Auftrag gegeben hat, ebenfalls den Wareneingang verbucht hat.
Verbinden Sie die beiden Tabellen mithilfe der Transaktion „SQVI“ über den User (Tabelle: EKKO technisches Feld: ERNAM und Tabelle: MKPF technisches Feld: USNAM). Selektieren Sie in der Listenfeldauswahl die erwähnten Felder für den User, die Transaktionscodes, den Buchungskreis und die Belegnummern. Das Ergebnis beinhaltet alle User, die beide Funktionen ausgeführt haben. Ob die Wareneingangsbuchung zu der korrespondierenden Bestellung gehört, lässt sich aufgrund der unterschiedlichen Datentypen nur manuell vergleichen. Auch hier ist wegen der großen Datenmenge der Export der Daten empfehlenswert.
Die Rechnungsfreigabe erfolgt in der Regel erst ab einer bestimmten Bestellmenge und / oder einem Bestellwert. Wird die Trennung der Funktionen nicht eingehalten, sind Betrugsfälle auch bis zum Schwellenwert denkbar. Kommen Berechtigungen für die Transaktionen „ME21“, „ME21N“, „ME22“ und „ME25“ in Kombination mit „MB01“, „MB0A“, „MB1A“ oder „MIGO“ vor, kann ein User beide Tätigkeiten ausführen.
Listenfeldauswahl:
- EKKO – Name des Sachbearbeiters
- EKKO – Belegnummer des Einkaufsbelegs
- EKKO – Buchungskreis
- MKPF – Name des Benutzers
- MKPF – Transaktionscode
- MKPF – Referenz-Belegnummer
Die Auswertung betrachtet ausschließlich Konflikte durch das Anlegen und nicht das Ändern von Bestellungen. Eine Erweiterung um eine weitere Komponente, die zusätzliche Änderungen berücksichtigt, ist nicht trivial, da die gesamte Änderungshistorie nachvollzogen werden muss.
O2C: Pflege von Kunden Stammdaten + Kundenaufträge anlegen
Auch im Bereich „Order-to-Cash“ können weitreichende Berechtigungen eines einzelnen Users zu Funktionstrennungskonflikten führen: Ist ein User z.B. berechtigt, die Kundenstammdaten zu pflegen und Kundenaufträge anzulegen, könnte dieser fiktive Kunden mit seinen eigenen Bankinformationen anlegen. Er hätte also potentiell die Möglichkeit, Gutschriften für den Kunden zu buchen – und so das Geld auf das eigene Konto umzuleiten.
Kundenstammdaten befinden sich in der Tabelle „KNA1“. Mit den Transaktionen „FD01“, „FD02“, „XD01“ oder „XD02“ lassen sich diese anlegen oder verändern. Kundenaufträge sind in der Tabelle „VBAK“ zu finden. Aufträge werden beispielsweise mit den Transaktionen, „VA01“ und „VA02“ angelegt.
Die beiden Tabellen können ebenfalls mit der „SQVI“ über den User (Tabelle: KNA1 technisches Feld: ERNAM und Tabelle: VBAK technisches Feld: ERNAM) und zusätzlich den Kunden (Tabelle: KNA1 technisches Feld: KUNNR und Tabelle: VBAK technisches Feld: KUNNR) verbunden werden. (vgl. Abbildung 2)
Das Ergebnis beinhaltet diejenigen User, die einen Kundenauftrag sowie den zugehörigen Kunden angelegt haben.
Abbildung 2: Verbund von KNA1 + VBAK für SoD Analyse
Listenfeldauswahl:
- KNA1- Name des Sachbearbeiters, der das Objekt hinzugefügt hat
- KNA1 – Debitorennummer
- VBAK- Auftraggeber
- VBAK – Name des Sachbearbeiters, der das Objekt hinzugefügt hat
Auch hier beschränkt sich die Analyse auf das Anlegen der Kunden und betrachtet nicht die Änderungen von Kundenstammdaten, da dafür die gesamte Änderungshistorie hinzugezogen werden muss. (siehe. Einschränkungen Funktionstrennungskonflikt 1-3)
P2P: Kreditorenrechnung erfassen + Kreditorenzahlung veranlassen
Ein weiterer Konflikt in der Funktionstrennung kann durch das Erfassen von Kreditorenrechnungen und dem Anstoßen des Zahllaufs entstehen. Zum Beispiel können Sie über die Transaktion „MIRO“ eine Rechnung für einen CPD-Kreditor anlegen, sowie die Zahlungsbedingungen für einen CPD-Lieferanten ändern. Ist ein User ebenfalls dazu berechtigt den Zahllauf anzustoßen, kann es dazu führen, dass nicht genehmigte Rechnungen umgelenkt und unbemerkt vom Unternehmen bezahlt werden.
Das Ausführen der Transaktionen „MIRO“ oder „FB01“ (Eingangsrechnung hinzufügen / Beleg buchen) und das anschließende Ausführen von Zahlläufen mit z.B. der Transaktion „F110“ ist somit ein Indikator für einen weiteren Funktionstrennungskonflikt.
Die Tabelle „BKPF“ (Belegkopf für Buchhaltung) zeigt die Kreditorenrechnungen, die mit den Transaktionen „MIRO“ und „FB01“ erstellt wurden. In der Tabelle „BSEG“ (Belegsegment Buchhaltung) sind unter anderem die Ausgleichsbelege für die Kreditorenrechnungen zu finden. Weil in der „BSEG“ allerdings keine Transaktionscodes angeführt werden, müssen die Transaktionscodes der Ausgleichsbelege in einem weiteren Schritt aus der „BKPF“ exportiert werden.
Verbinden Sie die Tabellen „BKPF“ und „BSEG“ zunächst über die Belegnummern (BELNR), den Buchungskreis (BUKRS) und das Geschäftsjahr (GJAHR). Schränken Sie das Ergebnis über die Selektionsfelder auf die Transaktionen „FB01“ und „MIRO“ ein. Wählen Sie in der Listenfeldauswahl: BKPF – Belegnummer eines Buchhaltungsbelegs, BKPF – Buchungskreis, BKPF – Name des Benutzers, BKPF – Transaktionscode, BSEG – Belegnummer des Ausgleichsbelegs und BSEG – Geschäftsjahr des Ausgleichsbelegs. Anschließend exportieren Sie das Ergebnis, z.B. nach Excel.
Als zweiten Schritt exportieren Sie eine Selektion der „BKPF“, eingeschränkt auf den TCODE „F110“ über die Transaktion „SE16N“. Für die Auswertung werden lediglich die BELNR, BUKRS, GJAHR, USNAM und TCODE benötigt. Anschließend verbinden Sie den ersten exportieren Datensatz in Excel über die Felder 1.BSEG.AUGBL, BSEG.AUGGJ und 1.BSEG.BUKRS mit dem zweiten Ergebnis 2.BKPF.BELNR, BKPF.GJAHR und 2.BKPF.BUKRS.
Steht in beiden Feldern der neuen Ergebnistabelle im Feld „USNAM“ derselbe Wert, liegt ein SoD Konflikt vor und der User hat zwei Tätigkeiten ausgeführt: die Rechnung angelegt und den Zahllauf angestoßen.
Listenfeldauswahl:
- BKPF – Belegnummer eines Buchhaltungsbelegs
- BKPF – Buchungskreis
- BKPF – Name des Benutzers
- BKPF – Transaktionscode
- BSEG – Belegnummer des Ausgleichsbelegs
- BSEG – Geschäftsjahr des Ausgleichsbelegs
Fazit
Die Auswertungsmöglichkeiten in SAP ohne ABAP Programmierung und Drittanbieter Tools stellt sich in einigen Fällen als sehr schwierig heraus. In wenigen der aufgezeigten SoD Konflikte können Änderungen in die Analysen miteinbezogen werden, was dazu führt, dass keine vollständigen Auswertungen möglich sind. Allerdings können viele Fälle initial identifiziert werden, was ein erster Ansatz hin zu einem konfliktfreien System bezüglich der Funktionstrennung wäre.
Bei der manuellen Auswertung von SoD Konflikten stößt man auf eine Vielzahl von Restriktionen. Hat man einen vermeintlichen SoD identifiziert, so kann man in den wenigsten Fällen auch feststellen, ob er tatsächlich in dem gleichen Prozessablauf stattgefunden hat und somit eine Feststellung im Sinne der Prüfung darstellt. Aufgrund dessen eignet sich zap Audit perfekt für eine Analyse der Funktionstrennungskonflikte auf Basis von Transaktionscodes und tatsächlich stattgefundenen Konflikten. Das integrierte Financial Process Mining rekonstruiert die kompletten Prozessabläufe und dient als Grundlage der Analyse. Damit werden in der Analyse nicht nur Restriktionen eliminiert, sondern auch False Positives effizient reduziert. Dieser Artikel stellt nur eine von 125 Prüfungsfragen aus zap Audit vor.
