Unser IS-U Know how

Basierend auf unseren Erfahrungen aus zahlreichen IS-U Projekten haben wir Prüfkriterien entwickelt, um die IS-U Systeme bezüglich der SAP Berech- tigungen revisionskonform umgestalten zu können. Neben kritischen Transaktionen und Objekten lag der Fokus auf der Trennung von Verantwortlichkeiten (SoD).

Wir auditieren Ihr IS-U System oder passen die von uns entwickelte Prüfmatrix an die von Ihnen bevorzugte Prüfsoftware an - für SAP GRC liegen die Uploadfiles bereit.

Für weitergehendes Interesse empfehlen wir Ihnen die Lektüre des folgenden Artikels (ZIR / 2009):

Ein praktikaber Ansatz zur Berechtigungsanalyse in IS-U Systemen

Besonders in Unternehmen der Energiewirtschaft ist die SAP Industrielösung IS-U (Utillities) weit verbreitet. Wie in der allgemein zugänglichen Literatur bereits detailliert ausgeführt wurde, handelt es sich hierbei nicht nur schlicht um neue SAP Funktionalitäten, sondern vielmehr um ein eigenes Abrechnungssystem mit Stammdaten für Geschäftspartner und Buchungsaktivitäten. Dies bedeutet aber im Umkehrschluss, dass eine sachgerechte Prüfung eines SAP Systemes aus Sicht der Revision weit über den Rahmen der klassischen SAP Funktionen hinaus gehen muss. In den folgenden Absätzen wird ein, auch für den SAP Einsteiger, praktikabler Ansatz zum Einstieg in die IS-U Prüfung beschrieben.

1.Vorgehen bei IS- Lösungen allgemein - Nutzungsstatistik (ST03N)

Für die klassischen Funktionalitäten gibt es mittlerweile eine Reihe von Möglichkeiten, sich über kritische Aspekte zu informieren. Sei es die Literatur oder diverse Prüfwerkzeuge die eine gewisse Transparenz hinsichtlich riskant einzuschätzender Transaktionen, Objekte oder Profile versprechen oder SoD relevante Matrizen, die von verschiedenen Anbietern vorliegen. Für die große Masse der von SAP angebotenen Industriesonderlösungen ist das Angebot an Hilfestellungen jedoch rar. Einerseits gibt es SAP Industrielösungen, deren funktionaler Umfang für eine Revision wenig relevant erscheinen, andererseits sind die wenigen Fachleute für relevante IS-Produkte mit anderen Projekten beschäftigt, so dass kaum Zeit für revisionstechnische Betrachtungen bleibt.
Um diesen "blinden Fleck" bei der hausinternen Auditierung von Systemen zumindest Ansatzweise zu beseitigen kann mit den zur Verfügung stehenden "Bordmitteln" gestartet werden.

Da zumindest uns bekannte Revisonsabteilungen nicht an Unterbeschäftigung leiden, empfiehlt es sich, im ersten Ansatz auf die IS-FUnktinalitäten zu konzentrieren, die im eigenen Unternehmen auch real genutzt werden. Die Befragung beteiligter Mitarbeiter hat sich hierfür als unzweckmäßig erwiesen. Wenn nicht der Zeitfaktor der Kollegen die Bemühungen um Transparenz gefährdet, dann wird dies über eine sehr subjektive Darstellung der SAP Nutzung realisiert. Nach Abschluss solcher Befragungen kommt bei der Präsentation der Ergebnisse im Unternehmen nicht selten eine andere Realität zum Vorschein und man beginnt auf's neue. Um diese Situation zu vermeiden lohnt es, das sogenannte Transaktionsprofil in der SAP Transaktion ST03(N) zu rate zu ziehen. In diesem Bericht werden alle in einem gewissen Zeitraum genutzten Transaktionen und Reports nach Zugriffshäufigkeit dargestellt. Die meisten IS-Produkte nutzen Transaktionen in einem speziellen Namensraum - z.B. die Transaktionen der Lösung IS-H (Healthcare) starten mehrheitlich mit "N", bei der Lösung IS-U beginnt die Mehrzahl der relevanten Transaktionen mit "E".
Nachdem nun mehr Klarheit über den real genutzten SAP Funktionsumfang herrscht, wobei der in Betracht gezogene Zeitraum mindestens drei Monate umfassen sollte, kann man daran gehen, sich einen Überblick über die genutzten Geschäftsprozesse bzw. Prozessschritte zu machen. Dies ist häufig im zweiten Buchstaben des Transaktionsnamens verschlüsselt. Um auch hier nur die aus Sicht einer Risikobetrachtung relevanten Transaktionen begutachten zu müssen, werden Transaktionen, deren Bezeichnung auf reine Anzeigeaktivitäten hinweisen aus der Liste gelöscht. Ebenso wie "Berichte", "Listen" und ähnliche Funktionen zur Ergebnisanzeige.

Dieser nun reduzierte Satz an ausgeführten Transaktionen wird einer kritischen Bewertung hinsichtlich enthaltener Risiken unterzogen. Einerseits geht es um Einzelrisiken, wie z.B. bei der Anlage und Änderung zentralen Einstellungen oder zahlungsrelevanten Daten. Andererseits ist der Aspekt der Funktionstrennung (SoD) einzubeziehen. Auf diese Weise erhält man einen überschaubaren Satz an Transaktionen, der, zumindest was die Verwendung in Rollen und deren Vergabe angeht, schnell geprüft werden kann.

Etwas komplizierter stellt sich die Situation bei der Prüfung auf der nächsten Ebene, den Berechtigungsobjekten, dar. Vergleichbar mit den Ausprägungen klassischer Berechtigungsobjekte prüft man im ersten Schritt nur die Feldausprägungen für erlaubte Aktivitäten. Bis auf wenige Ausnahmen hat sich SAP an die R/3 Nomenklatur gehalten: "01" - Anlegen, "02" - Ändern und "*" - alle Aktivitäten usw. Wie gelangt man nun zu DEN kritischen Berechtigungsobjekten. AUch hier hilft es, sich die Struktur des SAP Berechtigungssystems vor Augen zu führen. Kritische Objekte werden in aller Regel mit den im ersten Schritt definierten kritischen Transaktionen verbunden sein. Diese Verbindung wird im SAP über die Transaktion SU24 gepflegt / angezeigt. Auf diese Weise kann man kritische Objekte ausfiltern. Einfacher ist der Abgleich der zuvor als kritisch definierten Transaktionen mit den Inhalten der SAP Tabelle USOBT - dies setzt allerdings gewisse Fertigkeiten beim Umgang mit Excel / Access voraus. Weitergehende Beschreibungen bezüglich der gefundenen kritischen Berechtigungsobjekte können aus der Objektdokumentation im SAP (Transation SU21) bezogen werden.

Final folgt noch eine kurze Betrachtung von mitgelieferten Berechtigungsprofilen. In den Anfangszeiten von SAP R/3 wurden Transaktionen und Objekte direkt durch den Administrator in Profilen zusammengefasst und Anwendern zugeordnet. Mittlerweile wurde die immernoch auf Profilen basierende Rollentechnik eingeführt und sollte aus verschiedenen Gründen auch verwendet werden. Nichtsdestotrotz werden für IS-Lösungen immernoch Standardprofile mitgeliefert. In Ermanglung einer allgemeingültigen Regel sollte es für die erste Betrachtung ausreichen, Profile mit dem Namensbestandteil "ALL" zu prüfen und der Liste der Prüfkriterien zuzufügen. Die Vergabe von Profilen ist in der SAP Tabelle UST04 hinterlegt.

Nun liegt ein ausbaufähiger Satz an zu prüfenden Transaktionen, Transaktionskombinationen, Objekten und Profilen vor, die entweder mit den in SAP vorhandenen Standardreports im AIS oder nach Export der relevanten SAP Tabelleninhalte in Excel / Access auditiert werden können.

2.Realisierung am Beispiel von SAP IS-U (Utilities)

Am Beispiel der SAP Industrielösung Utilities (IS-U) soll exemplarisch demonstriert werden, welche Ergebnisse das Vorgehen nach Absatz 1 hervorbringen kann. Bei der Definition kritischer Transaktionen und von Kombinationen, die dem Vier-Augen-Prinzip widersprechen, können die genutzten Transaktionen den in Tabelle 1 auszugesweise zusammengestellten Geschäftsvorfällen bzw. Prozessschritten (genannt Funktionsgruppen) zugeordnet werden. In Einzelfällen kann die Zuordnung mehrdeutig sein.
Beispielsweise könnte dies zu folgender Gruppierung führen (Tabelle 1).

Tabelle 1

• 510    EA30    Tarif anlegen
• 510    EA31    Tarif ändern
• 510    EA89    Preis anlegen
• 510    EA90    Preis ändern
• 611    EA10    Fakturierung Belege
• 611    EASIBI    Erstellen Einzelrechnung
• 711    FPP1    Vertragspartner anlegen
• 711    FPP2    Vertragspartner ändern.

Diese einfachen Fälle deuten schon einen Sachverhalt an, der in der bisherigen Betrachtung etwas zu kurz kam. SAP ist ein integratives System. Das bedeutet, dass das Vier-Augen-Prinzip nicht nur auf IS-U Transaktionen bezogen werden kann, sondern die Integration in die Module FI (Rechnungswesen), SD (Vertrieb) und PM (Instandhaltung) ebenfalls Eingang in die Betrachtung finden muss. Für Tabelle 2 bedeutet dies, dass die Kombination der IS-U Transaktionen aus den Funktionsgruppen 510 und 611 mit den Transaktionen der Funktionsgruppe 711 (klassisches Vertragskontokorrent) einer gewünschten Funktionstrennung widersprechen würden. Jede der Kombinationen aus zwei oder mehreren Funktionsgruppen können zu Risiken zusammmengestellt und mit einer entsprechenden Beschreibung versehen werden. So würde die Kombination FG 510 und FG 611 die Möglichkeite einräumen, Preise und Tarife zu ändern und Fakturen erzeugen zu können - in der Regel ohne eine mögliche Kontrolle durch einen zweiten Anwender.
So entwickelt sich Schritt für Schritt eine bei Prüfungen üblicherweise genutzte Risikomatrix. Abhängig von den genutzten Prüfwerkzeugen wird die notwendige Zuordnung von Berechtigungsobjekten automatisch generiert oder muss manuell gepflegt werden.

Um die im Titel angekündigte Praktikabilität gewährleisten zu können, sind Kompromisse unumgänglich. Dies gilt insbesondere für die Berechtigungsobjekte und deren Ausprägung. Für eine erste Auditierung genügt es häufig, sich auf die erlaubten Aktivitäten in den Objekten zu konzentrieren. Schnell lässt sich z.B. einschränken, welche Anwender mit welchen Rollen (zumindest Objektseitig) kritische Aktionen ausführen könnten. Ebenfalls offensichtlich werden fehlerhafte Ausprägungen hinsichtlich der Namensgebung. So stellen wir immer wieder fest, dass Rollen, die als "Anzeigerollen" gekennzeichnet sind, pflegende Ausprägungen enthalten.
In Tabelle 3 sind einige der wesentlichen Berechtigungsobjekte mit IS-U Spezifik zusamengefasst. Die Prüfung dieser Objekte ist ein eindeutiger Maßstab für die Qualität des implementierten Berechtigungskonzeptes.

Tabelle 2

• F_KKKO_BUK    Beleg im Vertragskontokorrent Buchungskreis FI-CA
• F_KKMA        Massenaktivitäten im Vertragskontokorrent FI-CA
• E_BILL_CL    Berechtigungsobjekt zur Abrech.klasse
• E_B_BIL_PL    Berechtigungsobjekt zum Abschlagsplan
• E_WABILL    Berechtigungsobjekt zur Pflege abrechnungsrelevnt.Faktoren
• E_CONTRACT    Berechtigungsobjekt zum IS-U Vertrag
• E_INVOICE    Berechtigung zur Fakturierung von Vertragskonten
• E_INV_DOC    Berechtigungsobjekt: Rechnungseingang Beleg / Avis
• E_PRICE        Berechtigungsobjekt Preis
• E_RATE        Berechtigungsobjekt Tarif
• B_BUPA_ATT    Geschäftspartner: Berechtigungsarten
• B_BUPA_FDG    Geschäftspartner: Feldgruppen
• B_BUPA_GRP    Geschäftspartner: Berechtigungsgruppen
• B_BUPA_RLT    Geschäftspartner: GP-Rollen

Eine Besonderheit des IS-U besteht in dem gegenüber R/3 veränderten Aktivitätenschlüssel. Die Ausprägungen für das Feld ISU_ACTIVT besagen u.a. folgendes: 3-Anlegen, 2-Ändern, 1-Anzeigen. Dies ist für eine Filterung über kritische Aktivitäten unbedingt zu beachten.

Im Gegensatz zu anderen SAP Industrielösungen werden beim IS-U keine alle Berechtigungen umfassende Profile mit ausgeliefert. Jedoch sollte - wenn nicht schon in vorherigen Prüfungen geschehen - auf dei Vergabe kritischer Profile besonders integrierter Module wie FI, SD und PM geachtet werden. Beispiele hierfür sind: V_FAKT_ALL, F_KREDI_ALL, F_FICO_ALL oder I_PM_ALL.

3.Kritische Bewertung der Ergebnisse

Grundsätzlich sind an Hand der obig beschriebenen Kriterien folgende Aspekte prüfbar:
Ist das implementierte Rollenkonzept derart strukturiert, dass eine restriktive Vergabe von kritischen Transaktionen mithin auch als kritisch zu bewertender Kombiantionen aus Transaktionen praktikabel erscheint?
Stimmt die Namensgebung und inhaltliche Ausprägung im Rahmen der geprüften Kriterien überein?
Um wie viel größer ist die Anzahl der berechtigten gegenüber den genutzten Transaktionen - und was ist der Grund dafür (z.B. besonders große Einzelrollen)?
Werden Zugriffsrechte durch kritische Profile vergeben?
Wie viele Anwender besitzen die Rechte für kritische Transaktionen bzw. Transaktionskombinationen oder kritisch ausgeprägte IS-U Berechtigungsobjekte?

In aller Regel zeigt sich an dieser Stelle bereits, dass eine Bereinigung von Rollen hinsichtlich der Menge der enthaltenen Transaktionen notwendig ist. Abgesehen von der Tatsache, dass ein schmales, transparentes Berechtigungssystem leichter zu Verwalten ist - auch hinsichtlich latenter Risiken- , der reduzierte Wartungsaufwand hilft auch Kosten in diesem Bereich zu reduzieren. Da an dieser Stelle noch keine Aussage über die Nutzung von Transaktionen durch die Anwender gemacht werden kann, bedeutet dies, die entsprechenden Namenslisten mit den detektierten Risiken werden den jeweiligen Vorgesetzten zur Redutkion bzw. Dokumentation kompensatorischen Reportings überlassen. Die Auswertung der rollenspzifischen Prüfergebnisse sollte der IT Abteilung als Diskussionsgrundlage für eventuell notwendige Umgestaltungen am Berechtigungssystem zur Verfügung gestellte werden

4. Fazit

Angsichts der doch recht großen Risiken, die sich im Bereich der SAP Industrielösungen auftun können, lohnt sich der Aufwand, Kriterien für eine regelmäßige Prüfung auch dieser Funktionen zu erstellen. Mit verhältnismäßig einfachen Mitteln lassen sich diese Kriterien aus den Bereichen Transaktionen, Kombinationen von Transaktionen, kritischen Berechtigungsobjekten sowie Profile zusammenstellen. Wie am Beispiel IS-U vorgestellt, wird am Anfang ein ausbaufähiger Prüfumfang definiert, dem nach und nach weitere Facetten hinzugefügt werden könnnen. Erfahrungsgemäß reicht es aber schon aus, die drei Aspekte: Rolleninhalte, Rollenvergabe und Systemnutzung, unter die Lupe zu nehmen, um einen guten Überblick über den Status quo des Berechtigungskonzeptes zu bekommen. Detailfragen nach z.B. der RFC Nutzung sind nebensächlich, wenn Anwender über Rollen Transaktionen zur Veränderung systemrelevanter oder zahlungssensibler Tabelleninhalte erhalten und nutzen. Eine Verfeinerung der Prüfung ist stets möglich, man muss aber das Machbare im Auge behalten. Der durchschnittliche Stellenwert von SAP Berechtigungen in der unternehmerischen Praxis ist häufi niedrig genug, um selbst einfachste Projekte zu verzögern. In diesem Sinne sollte die Zahl der verprobten Kriterien auf reale Risiken reduziert werden und somit eine Korrektur realisierbar erscheinen lassen.

Dr. Alexander Stendal

JAVA Berechtigungen

UME.Manage_All das SAP_ALL der Java-Welt. Auch im SAP Web AS Java Umfeld (JAVA Stack) sind die Zugriffsrechte hierarchisch strukturiert.

Es gibt Permissions, die in Actions zusammengefasst werden, welche wiederum in Rollen gebündelt werden. Diese Rollen können dann den Anwendern direkt oder indirekt zugeordnet werden.

An dieser Stelle enden dann aber auch die Analogien zu den klassischen ABAP Berechtigungen (ABAP Stack). Der Begriff "Rolle" wird im J2EE WEB AS leider für verschiedene Objekte genutzt, so dass meist ein Namenszusatz für die Eindeutigkeit notwendig wird. Auch wenn viele dieser "Rollen" mit der Beschränkung oder Freigabe von Daten sowie Funktionen zu tun haben, werden sie an unterschiedlichen Stellen gepflegt und vergeben.

Die Berechtigungsvergabe im J2EE WEB AS Umfeld wird durch die UME (User Management Engine) administriert. Parallel gibt es aber noch weitere Möglichkeiten, Rechte zu beschränken. Abhängig von der Systemlandschaft und den strategischen Überlegungen zum weiteren Ausbau der IT Infrastruktur können oder müssen verschiedene Backend Technologien verwendet werden. Hier die richtige Entscheidung zu treffen, ist an sich schon ein eigenes Projekt.

Zu bedenken ist folgendes: Die meist konzeptlose Einführung der ABAP Berechtigungen in den Anfangsjahren der SAP R/3 Implementierung waren noch viele Jahre nach Go-Live zu spüren. Es gibt Fehler, die nicht wiederholt werden müssen!

Gern beraten wir Sie bei der Strukturierung und Entwicklung Ihrer J2EE WEB AS Berechtigungen.