Prüfmanual. SAP-Business Warehouse. (Entwurf)

Transkript

1 Prüfmanual SAP-Business Warehouse (Entwurf) Einführung Seite I

2 Einführung Liebe Leserinnen und Leser, Bisher hatte die Einführung klassischer Datenverarbeitungssysteme und Enterprise Resource Planning (ERP)-Systeme primär die Beschleunigung, Kostenreduzierung und Automatisierung von Prozessen in einzelnen Unternehmensbereichen zum Ziel. Auf diese Weise hat sich im Verlauf der letzten Jahrzehnte innerhalb der Unternehmen ein enormes Informationspotenzial gebildet. Parallel besteht durch die stetig wachsende Globalisierung und gleichzeitige Dezentralisierung der Unternehmen die Notwendigkeit, Tendenzen am Markt zu erkennen, Informationen über Wettbewerber verfügbar zu haben und schnell auf Veränderungen reagieren zu können. Informationen sind somit zu einem entscheidenden Wettbewerbsvorteil geworden. Die Entscheidungsträger im Unternehmen bauen auf die effiziente Nutzung dieser Informationen, die in vielen verschiedenen Anwendungssystemen und Datenbeständen innerhalb und außerhalb des Unternehmensverbunds verteilt sind. Das Konzept zur Integration und Konsolidierung dieser Daten ist das Data Warehousing. Das BW-System wird häufig als EIS 1 -System im Unternehmen eingesetzt. Analyseergebnisse werden häufig als Grundlage für unternehmerische Entscheidungen herangezogen. Daher sollte nicht nur das SAP-ERP-System sondern auch das SAP-BW-System in regelmäßigen Abständen einer eingehenden Prüfung unterzogen werden. Wer bisher nur SAP- ERP-Systeme geprüft hat, wird bei einer SAP-BW-Prüfung umdenken müssen. Datenfluss, -verarbeitung und- speicherung sowie die Berechtigungsvergabe folgen anderen Konzepten. Dieses Prüfmanual gibt Ihnen Werkzeuge (Checklisten, Hintergrundinformationen, technische Informationen, Glossar) an die Hand, so dass Sie eine BW-Prüfung kompetent, effizient und effektiv durchführen können. Ihr Marcus Herold 1 Executive Information System Einführung Seite II

3 Inhaltsverzeichnis Einführung... II Inhaltsverzeichnis... III Abbildungsverzeichnis... V Literaturverzeichnis... VI 1 Checklisten Datenschutz Dokumentation Risikolandkarte eines BW-Systems Prüfen der Basissicherheit eines BW-Systems Datenfluss und Datenablage in Quellsystemen Datenfluss und Datenablage im BW-System Analyseberechtigungen... 5 Hintergrundinformationen Data-Warehouse-System Data-Warehouse-System Anforderungen an ein Data-Warehouse-System OLTP- und OLAP-Systeme Rechtliche Grundlagen Datenschutz Technische Grundlagen eines BW-Systems Der Datenfluss im SAP NetWeaver BW Die Objekte der Modellierung Die InfoProvider Dokumentationen zum SAP BW Berechtigungskonzept Die technische Dokumentation des Datenflusses und speicherung Das Dateneigentümerkonzept Das Antrags-, Test- und Freigabeverfahren Das interne Kontrollsystem Die Prüferberechtigungen im SAP BW Die Einordnung des SAP BI in die SAP Netweaver Architektur Risikolandkarte eines BW-Systems Prüfen der Basissicherheit eines BW-Systems Tabellenprotokollierung Auswertung Standardprofile Weitere wichtige Prüfungshandlungen Prüfen des Datenflusses und der Datenablage in Quellsystemen Technische Kopplung des BW-Systems mit den Quellsystemen Inhaltsverzeichnis Seite III

4 RFC-Verbindungen und Benutzer Schnittstellenbenutzer im SAP BW Schnittstellenbenutzer im SAP Quellsystem DataSources Extraktoren Extraktorenchecker Prüfung des Datenflusses und der Datenablage im BW-System PSA-Tabellen Überprüfung des Datenflusses ausgewählter InfoProvider Berechtigungen im Reporting Konzept der Reporting-Berechtigungen Welche Berechtigungssystematik wird genutzt Der BEx-Analyzer Query-Auswahl im BEx-Analyzer Reporting-Berechtigungen S_RS_COMP und S_RS_COMP Ablauf der BW-Reporting Berechtigungsprüfung Ebenen der Berechtigungssteuerung Analyseberechtigungen Aufbau der Analyseberechtigungen Spezialmerkmale für die Analyseberechtigungen Die Berechtigung 0BI_ALL Vorgehensweise bei der Prüfung von Reporting-Berechtigungen Prüfungsrelevante InfoObjects Prüfungsrelevante InfoProvider Analyseberechtigungen Technische Informationen Abkürzungen aus dem Bereich SAP BW Wichtige Transaktionscodes in SAP BW Wichtige Tabellen in SAP BW Glossar Wichtige Icons in BW Inhaltsverzeichnis Seite IV

5 Abbildungsverzeichnis Abb. 1: Operative und informative Umgebung im Unternehmen Abb. 2: Wesentliche Unterschiede zwischen einem OLTP- und OLAP-System Abb. 3: Stark vereinfachter Aufbau des SAP NetWeaver Abb. 4: Datenfluss von den Quelldaten zu den InfoProvidern (Quelle: SAP) Abb. 5: Anzeige eines InfoCubes über die Datawarehouse Workbench (Transaktion RSA1) Abb. 6: Übersicht über die Objekte des BW 7.x Abb. 7: Integration von BI in SAP NetWeaver Quelle: SAP AG Abb. 8: BW-Komponenten Quelle: SAP AG Abb. 9: Risikolandkarte eines BW-Systems Abb. 10: Datenfluss eines BW-Systems (Quelle: SAP ) Abbildungsverzeichnis Seite V

6 Literaturverzeichnis DSAG Arbeitskreis Revision Arbeitsgruppe Datenschutz (2003). Leitfaden Datenschutz für SAP BW Release 3.1 vom 28. November Heilig, Loren; Kessler, Thorsten; Knötzle, Thilo (2011). SAP NetWeaver BW & SAP BusinessObjects. SAP PRESS, Bonn. John, Peter; Kiener, Peter (2012). Berechtigungen in SAP NetWeaver BW. 2. Auflage. SAP PRESS, Bonn. Mehrwald, Christian: (2010). Datawarehousing mit SAP BW erweiterte Auflage. dpunkt.verlag, Heidelberg. Literaturverzeichnis Seite VI

7 1 Checklisten 1.1 Datenschutz Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 1 Datenschutz 2 Existieren in Ihrem Unternehmen datenschutzrechtliche Richtlinien für die Speicherung und Nutzung der im BW System gespeicherten Daten? Die Nutzung sensibler SAP-BW-Daten sollte in einer Richtlinie festgelegt werden. Kapitel / Seite 3.1/ 11 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 2 Datenschutz 2 Werden die Gesetze und Richtlinien zur Nutzung des BW-Systems eingehalten? Gesetzliche Vorgaben und interne Richtlinien müssen eingehalten werden. Kapitel / Seite 3.1/ Dokumentation Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 3 Dokumentation 3 Existieren die erforderlichen Dokumentationen? Sind diese vollständig und aktuell? Die erforderlichen Dokumentationen dienen als Sollvorgabe für die Prüfung des BW-Systems. Diese sollten alle vorhanden, vollständig und aktuell sein. Praktische Prüfung Kapitel / Seite 5 / Risikolandkarte eines BW-Systems Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 4 Risikolandkarte 3 Erstellen Sie als Prüfungsgrundlage eine auf Ihren Betrieb zugeschnittene Risikolandkarte Ihres BW- Systems. Im Kapitel 8 sind mögliche Risiken eines Standard- BW-Systems dargestellt. Durch Anpassung dieser Risiken erhalten Sie einen Rahmen für mögliche Prüfungshandlungen. Kapitel / Seite 8/ Prüfen der Basissicherheit eines BW-Systems Ps- Thema Risiko Prüfschritt Kapitel / Seite Nr. Vorgabe oder Erläuterung 5 Tabellenprotokollierung 1 Ist die Tabellenprotokollierung eingeschaltet? 9.1/ 35 Die Protokollierung ist für das Produktivsystem für alle Mandanten zu aktivieren. Ebenso ist die Protokollierung für Importe von Tabelleninhalten zu akti- 1 Checklisten Seite 1 von 128

8 vieren. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 6 Standardprofildardprofile 2 Wurden im produktiven BW-System kritische Stan- vergeben? Die Profile SAP_ALL, SAP_NEW, S_A.System und S_RS_ALL sollten im produktiven System an keinen Benutzer (außer Notfallbenutzer) vergeben werden. Kapitel / Seite 9.2/ 37 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 7 Gesetzeskritischtigungen 1 Wurden im produktiven BW-System kritische Berech- vergeben? Berechtigungen Berechtigungen zum Löschen von Änderungsprotokollen Löschen von Tabellenprotokollen Debuggen mit Replace und zum Ausführen von ABAP-Quelltexten über RFC sind im Produktivsystem (außer Notfallbenutzer) nicht zu vergeben. Kapitel / Seite 9.3 / Datenfluss und Datenablage in Quellsystemen Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 8 RFC- k. A. Welche RFC-Verbindung werden für die Kommunikation Verbindungen vom BW-System genutzt und welche Benutzer sind dort hinterlegt? Mit diesem Prüfpunkt bekommen Sie einen Überblick, welche Quellsysteme an das BW-System angeschlossen sind. Kapitel / Seite / 39 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 9 Schnittstellenbenutzefil 2 Welcher Benutzertyp und welches Berechtigungspro- sind dem Schnittstellenbenutzer im SAP BW zuge- im SAP BW ordnet? Im SAP BW muss ein Systembenutzer (nicht Dialog oder Service) angelegt sein, standardmäßig ist das BWREMOTE (Benutzername kann aber beliebig gewählt werden). Der Benutzer sollte das Berechtigungsprofil S_BI-WHM_RFC besitzen, welches im SAP BW Auslieferungsumfang für diesen Benutzer vorgesehen ist. Zusätzlich können noch weitere Berechtigungen erforderlich sein (siehe SAP-Hinweis ). Kapitel / Seite / 41 1 Checklisten Seite 2 von 128

9 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 10 Schnittstellen benutzer Quellsystem zugeordnet? im SAP Quellsystem 2 Welcher Benutzertyp und welches Berechtigungsprofil sind dem Schnittstellenbenutzer im SAP- Dieser Benutzer sollte als Kommunikations- oder Systembenutzer eingerichtet sein und das Berechtigungsprofil S_BI-WX_RFC besitzen, das im SAP Standard für diesen Benutzer vorgesehen ist. Zusätzlich können noch weitere Berechtigungen erforderlich sein (SAP-Hinweis ). Kapitel / Seite / 43 Ps- Thema Risiko Prüfschritt Kapitel / Seite Nr. Vorgabe oder Erläuterung 11 DataSources 2 Wer darf DataSources im Quellsystem pflegen? 10.2/ 45 Die DataSources sollten nur von den BW- Administratoren gepflegt werden können. Kapitel / Seite 10.3/ 49 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 12 Extraktoren 2 Ist das Pflegen von Extraktoren im Produktivsystem möglich? Das Pflegen von Extraktoren sollte im produktiven Quellsystem nicht möglich sein. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 13 Extraktorchecker 2 Wer besitzt Berechtigungen, um sich sensible Daten über den Extraktorchecker anzusehen? Diese Berechtigung sollte nur die BW-Administration besitzen. Kapitel / Seite 10.4 / 51 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 14 ExtraktorchecketaSources 2 Wer hat mit dem Extraktorchecker sensible Da- aufgerufen? Es ist zu klären, ob diese Mitarbeiter dazu organisatorisch berechtigt waren und ob die Zugriffe aufgabenbezogen erfolgten. Kapitel / Seite 10.4 / Datenfluss und Datenablage im BW-System Ps- Thema Risiko Prüfschritt Kapitel / Seite Nr. Vorgabe oder Erläuterung 15 PSA- 2 Wer kann sich PSA-Tabellen anzeigen lassen? 11.1/ 56 Tabellen Durch den lesenden Zugriff auf PSA-Tabellen können sensible Informationen (z.b. Gehälter, Bilanzinformationen) offengelegt werden. 1 Checklisten Seite 3 von 128

10 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 16 Datenrequests 2 Laufen Datenrequests für DataSources fehlerfrei durch? Gibt es Richtlinien in denen der Umgang mit fehlerhaften Requests geregelt ist? Häufige fehlerhafte Datenrequests können ein Indiz für technische Probleme zwischen Quell- und BW- System sein. Fehlerhafte Requests müssen bereinigt werden, um die Datenkonsistenz zwischen Quellund BW-System zu gewährleisten. Kapitel / Seite 11.1/ 56 Ps- Thema Risiko Prüfschritt Kapitel / Seite Nr. Vorgabe oder Erläuterung 17 PSA- 2 Wer kann die Inhalte von PSA-Tabellen modifizieren? 11.1/ 56 Tabellen Durch diese Berechtigung können Informationen in PSA-Tabellen manipuliert werden. Manipulierte Informationen werden dann entsprechend unkontrolliert im BW-System weiterverarbeitet. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 18 PSA- 2 Gibt es häufig Änderungen an PSA-Tabellen die zu Tabellen kritischen DataSources gehören? Häufige Änderungen können ein Hinweis auf technische Probleme odermanipulative Vorgänge sein. Kapitel / Seite 11.1/ 56 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 19 PSA- 2 Werden PSA-Tabellen in regelmäßigen Abständen Tabellen gelöscht? Nicht gelöschte PSA-Tabellen erhöhen das Risiko von unerlaubten Zugriffen auf sensible Informationen. Kapitel / Seite 11.1/ 56 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 20 Datenfluss ausgewählter Info- näher untersucht werden sollten? Provider 2 Gibt es im Datenfluss für ausgewählte InfoProvider sensible Quellen oder Verarbeitungsschritte, die Bei sensiblen Datenquellen sollte die Herkunft und die Qualität der Daten geprüft werden. Kapitel / Seite 11.2/ 62 1 Checklisten Seite 4 von 128

11 1.7 Analyseberechtigungen Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 21 Berechti- k. A. Welche Berechtigungssystematik ist im zu prüfenden gungs- BW-System aktiv? Dieser Prüfschritt ist nur für BW- systematik Releases 7.0 bis 7.2x relevant. Für BW-Releases 7.0 bis 7.2x ist der Prüfschritt wichtig, um zu wissen nach welcher Berechtigungssystematik geprüft werden muss. Wichtig: In diesem Prüfmanual werden nur die Prüfschritte nach der neuen Systematik erläutert. Kapitel / Seite 12.2/ 65 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 22 0BI_ALL 2 Wem ist die Analyseberechtigung 0BI_ALL zugewiesen und kann damit auf alle berechtigungsrelevanten InfoObjects zugreifen? Diese kritische Berechtigung darf nur Personen zugeordnet werden, die von ihrem Aufgabengebiet her zur Anzeige/Auswertung aller Daten berechtigt sind. Kapitel / Seite / 84 Ps- Thema Risiko Prüfschritt Kapitel / Seite Nr. Vorgabe oder Erläuterung 23 Berechti- 2 Welche InfoObjects sind berechtigungsrelevant? / 87 gungsrele- vante InfoObjects Die InfoObjects, in denen besonders schutzwürdige Unternehmens- oder Personendaten gespeichert sind, wurden als berechtigungsrelevant gekennzeichnet. Ps- Thema Risiko Prüfschritt Kapitel / Seite Nr. Vorgabe oder Erläuterung 24 Prüfungsrelevante k. A. Welche InfoProvider sind prüfungssrelevant? / 88 InfoProvider InfoProvider stellen die auszuwertenden Daten zur Verfügung, daher stellt die Grundlage jeder Prüfung von Reporting-Berechtigungen das Wissen um die zu prüfenden Daten dar. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 25 Kritische 2 Existieren im BW-System Queries mit sensiblen Informationen? Queries Es kann für die Prüfung relevant sein, die sensiblen Queries zu den InfoProvidern im Vorweg einer Berechtigungsprüfung zu ermitteln. Kapitel / Seite / 88 1 Checklisten Seite 5 von 128

12 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 26 Zugriffsberechtigung 2 Wer hat Zugriffsberechtigungen auf ausgewählte InfoProvider? auf ausgewählte Die Berechtigungsvergabe sollte mit den OrganisatifoProvidegaben Inonsstrukturen des Unternehmens und den Sollvor- übereinstimmen. Kapitel / Seite / 88 Ps- Thema Risiko Prüfschritt Kapitel / Seite Nr. Vorgabe oder Erläuterung 27 Analyse- k. A. Welche Analyseberechtigungen existieren? / 96 berechti- gungen Mit diesem Prüfschritt verschafft man sich einen Überblick über die vergebenen Analyseberechtigungen, um kritische Berechtigungen zu identifizieren und deren Zuordnung zu Benutzern zu analysieren. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 28 Analyse- k. A. Wurden generierte Analyseberechtigungen Benutzern berechti- zugeordnet? gungen Der Einsatz von generierten Analyseberechtigungen für wichtige Organisationselemente (z.b. Kostenstelle, Buchungskreis) ist zu empfehlen, um einen automatisierten Abgleich der Berechtigungsvergabe zwischen ERP- und BW-System zu erreichen. Kapitel / Seite / 96 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 29 Analyse- 2 Wurden Analyseberechtigungen Benutzern manuellzugeordnetberechtigungen Grundsätzlich sollte die Vergabe der Analyseberechtigungen über Rollen und nicht über manuelle Zuordnungen erfolgen, um eine höhere Transparenz in der Berechtigungsvergabe zu erreichen. Kapitel / Seite / 96 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 30 Analyse- k. A. Welchen Benutzern sind Analyseberechtigungen über berechti- Rollen zugeordnet? gungen Grundsätzlich sollte die Vergabe der Analysebe- rechtigungen über Rollen und nicht über manuelle Zuordnungen erfolgen, um eine höhere Transparenz in der Berechtigungsvergabe zu erreichen. Die Rollenvergabe sollte den Sollvorgaben des Berechtigungskonzeptes entsprechen. Kapitel / Seite / 96 1 Checklisten Seite 6 von 128

13 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 31 Analyse- 2 Welchen Benutzern sind unternehmenskritische Analyseberechtigungen berechti- zugeordnet? gungen Die Zuordnung sollte den Sollvorgaben des Berechtigungskonzeptes entsprechen. Kapitel / Seite / 96 1 Checklisten Seite 7 von 128

14 Hintergrundinformationen 0 Hintergrundinformationen Seite 8 von 128

15 2 Data-Warehouse-System 2.1 Data-Warehouse-System Ein Data-Warehouse-System ist eine unabhängige Anwendungsumgebung mit zugehöriger Datenbank, die vor allem der Bereitstellung von Informationen aus unterschiedlichsten Datenquellen dient und flexible Abfragen und Analysen ermöglicht. Ein solches System kann auf allen Mitarbeiterebenen im Unternehmen eingesetzt werden (Manager, Abteilungsleiter und alle sonstigen Mitarbeiter). Definition Data-Warehouse-System 2.2 Anforderungen an ein Data-Warehouse-System Entscheidungsträger benötigen einen schnellen und dauerhaften Zugriff auf entscheidungsrelevante Informationen. Ein Zugriff auf Informationen aus den unterschiedlichsten Quellsystemen sollte über einen einzigen "Single Point of Entry" möglich sein. Es müssen effiziente Analyse- und Visualisierungsmöglichkeiten zur Verfügung stehen, die den Bedürfnissen unterschiedlicher Benutzergruppen Rechnung tragen. 2.3 OLTP- und OLAP-Systeme Online Transaction Processing (OLTP) bezeichnet ein Benutzungsprinzip von Datenbanksystemen, bei dem die Verarbeitung von Transaktionen, das heißt Lese- und Schreiboperationen auf kurzfristig veränderlichen Datenbeständen im Vordergrund steht. Online Analytical Processing (OLAP) wird neben dem Data-Mining zu den analytischen Informationssystemen gezählt und im Rahmen von Entscheidungsund Management-Informationssystemen zu den hypothesengestützten Analysemethoden zugeordnet. Mit einer multidimensionalen Betrachtung dieser Daten kann man ein fundiertes und entscheidungsunterstützendes Analyseergebnis gewinnen. Unterschied zwischen OLTP und OLAP 2 Data-Warehouse-System Seite 9 von 128

16 Abb. 1: Operative und informative Umgebung im Unternehmen Ziel Prioritäten OLTP-System (operative Umgebung) Unterstützung der Abwicklung von Geschäftsprozessen Hohe Verfügbarkeit, hoher Datendurchsatz OLAP-System (informative Umgebung) Analyse der Daten zur Informationsgewinnung Einfache Benutzung, flexibler Zugriff Datensicht Detailliert Meist aggregiert Alter der Daten Aktuell Historisch Datenbestand 6-18 Monate 2 7 Jahre Archivierung Ja Ja Zugriff auf Daten Datenstruktur Einfügen, Ändern, Löschen und Lesen Relational (Tabellen, hohe Normalisierung) Lesen (nur selten Änderungen) Multidimensional (Sternschema) Integration aus verschiedenen Modulen Minimal umfassend Abb. 2: Wesentliche Unterschiede zwischen einem OLTP- und OLAP-System 2 Data-Warehouse-System Seite 10 von 128

17 3 Rechtliche Grundlagen Ein BW-System muss nicht so strenge gesetzliche Anforderungen erfüllen wie ein operatives System, in dem Finanztransaktionen abgewickelt werden. Da in diesem System aber auch Finanzdaten des Unternehmens in aggregierter Form gespeichert werden und diese als Grundlage betriebswirtschaftlicher Entscheidungen dienen können, müssen trotzdem einige gesetzliche Anforderungen erfüllt werden. 147 AO Ordnungsvorschriften für die Aufbewahrung von Unterlagen 257 HGB Aufbewahrung von Unterlagen, Aufbewahrungsfristen 239 HGB Führung der Handelsbücher (Radierverbot) 91 Abs.2 AktG Einrichtung eines Überwachungssystems Ein BW-System muss nicht so strenge gesetzliche Anforderungen erfüllen wie ein operatives System. 3.1 Datenschutz 2 Die rechtlichen Anforderungen an ein SAP BW-System sind im Wesentlichen von der Art der verarbeiteten Daten abhängig. Wird das BW-System als Erweiterung eines operativen Systems genutzt und werden keine personenbezogenen Daten ausgewertet, kann sich die Prüfung auf das Berechtigungskonzept beschränken. Voraussetzung ist, dass der Zweck, der Datenumfang, die Speicherdauer und der zugriffsberechtigte Personenkreis nicht ausgeweitet werden. SAP BW ist Bestandteil des ABAP-Stacks des SAP-Netweaver (siehe Abb. 2) mit dem bekannten Berechtigungskonzept. Dieses wurde um Berechtigungsobjekte für Extraktion, Administration, Datenzugriff und Reporting erweitert. Die Sicherheitsfunktion in SAP BW konzentriert sich jedoch nicht vorwiegend auf Transaktionscodes oder Aktivitäten, sondern auf die Daten selbst. Abb. 3: Stark vereinfachter Aufbau des SAP NetWeaver Dieser Abschnitt ist ein Exzerpt aus dem Leitfaden Datenschutz für SAP BW herausgegeben von der DSAG Arbeitskreis Revision Arbeitsgruppe Datenschutz Release 3.1 vom 28. November Rechtliche Grundlagen Seite 11 von 128

18 Im Sinne des Datenschutzrechts findet im Business Warehouse eine Nutzung der vorgelagerten Daten statt, mit Ausnahme der Auswertungserstellung erfolgen alle anderen Prozesse der Datenverarbeitung in den vorgelagerten operativen Systemen. Speicherung personenbezogener Daten Werden jedoch personenbezogene Daten aus verschiedenen Systemen zusammengeführt ist dieses bezüglich der Zweckbindung rechtlich anders zu bewerten. Zulässig sind in diesem Zusammenhang eine erneute Erlaubniserteilung der Betroffenen oder die Anonymisierung ( 3 BDSG, Weitere Begriffsbestimmungen) aller personenbezogenen Daten. Kann nicht mehr auf die Einzelperson rückgeschlossen werden (Anonymisierung), sind die datenschutzrechtlichen Bestimmungen nicht mehr anwendbar. Bei einer Pseudonymisierung hingegen bleibt das Datenschutzrecht anwendbar, da die Daten zwar zunächst für den Betrachter anonym sind, aber der zugehörige Personenbezug jederzeit über Zuordnungstabellen wieder hergestellt werden kann. Zu klären ist hier, wer im Besitz der Zuordnungstabelle ist und damit die Möglichkeit hat, den direkten Personenbezug wieder herzustellen. Zur Bewertung des BW-Systems ist also vor der Prüfung zu klären, ob personenbezogene, pseudonyme oder anonyme Daten an das BW übergeben werden und welche dieser drei Datenklassen in der Basis vorgehalten bzw. ausgewertet werden. Prüffelder Daraus können folgende Prüffelder abgeleitet werden: a. Datenübergabe an das BW-System b. Speicherung der Daten in der Basis c. Art und Umfang der von den InfoCubes bereitgestellten Sichten und Auswertungen. zu a) Datenübergabe ans BW Selbst wenn an das BW nur anonymisierte Daten übergeben werden und das Datenschutzrecht hierauf und auf den Umgang mit diesen Daten im BW keine Anwendung findet, bleibt dennoch zu prüfen, ob bestehende Betriebsvereinbarungen oder besondere gesetzliche Regelungen die anonyme Weitergabe und Nutzung reglementieren. Sollen personenbezogene oder pseudonymisierte Daten an das BW weitergegeben werden, so ist bereits im Vorfeld der Datenübergabe zu prüfen, ob Rechtsvorschriften (besondere Geheimhaltungspflichten z. B. ärztliche Schweigepflicht, Vertraulichkeit der Personalakte oder Fernmelde-, Bank-, Steuergeheimnis) oder im Bereich der Personaldatenverarbeitung bestehende Betriebsvereinbarun-gen oder Bestimmungen des Datenschutzrechts vorhanden sind, die die Übergabe einschränken oder gar verbieten. 3 Rechtliche Grundlagen Seite 12 von 128

19 Eine solche Prüfung ist insbesondere erforderlich, wenn das BW-System nicht nur zur Entlastung des operativen Systems eingesetzt wird, sondern z. B. die Zwecke, der Datenumfang, die Speicherungsdauer, die Auswertungsmöglichkeiten oder der zugriffsberechtigte Personenkreis mit entsprechenden Berechtigungen ausgedehnt werden. zu b) Vorhalten von Daten in der Basis Die Datenbasis ist zu unterscheiden in PSA und DSO-Objekt. Die PSA dient im Wesentlichen der kurzfristigen Zwischenspeicherung der ins BW geladen Daten, bevor sie in der endgültigen BW-Datenbasis (DSO-Objekt) abgelegt werden. Damit sind insbesondere für die PSA technisch/organisatorische Maßnahmen und im Hinblick auf die kurzfristige Speicherung der Grundsatz der Datenvermeidung und Datensparsamkeit zu beachten. Das führt in der Regel dazu, dass die Daten nach erfolgreichem Hochladen in die DSO-Objekte in der PSA zu löschen sind. Bei den DSO-Objekten ist darüber hinaus insbesondere die Speicherdauer im Hinblick auf die Geschäftszwecke und die damit verbundene Erforderlichkeit zu beachten. Die Erforderlichkeit ergibt sich hierbei aus den mit dem BW verfolgten Zwecken. Dabei ist in diesem Zusammenhang auch regelmäßig der Umfang der gespeicherten Daten zu überprüfen. PSA und DSO-Objekte zu c) Art und Umfang der von den InfoCubes bereitgestellten Sichten und Auswertungen Bei der Prüfung stehen folgende datenschutzrechtliche Grundprinzipien im Vordergrund: Zweckbindung Klärung der Reichweite der vorhandenen Rechtsgrundlage der operativen Systeme für das BW Schaffung neuer Rechtsgrundlagen, z. B. durch Einwilligung oder vertragliche Regelungen (s. 28 Abs. 1 BDSG) Transparenz der Datenverarbeitung Qualität (Datenintegrität und konsistenz) 3 Rechtliche Grundlagen Seite 13 von 128

20 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 1 Datenschutz 2 Existieren in Ihrem Unternehmen datenschutzrechtliche Richtlinien für die Speicherung und Nutzung der im BW System gespeicherten Daten? Die Nutzung sensibler SAP-BW-Daten sollte in einer Richtlinie festgelegt werden. Ist eine datenschutzrechtliche Richtlinie im Unternehmen vorhanden, ist diese auf Aktualität und auf Einhaltung zu prüfen. Ist eine Richtlinie nicht vorhanden und werden im BW-System datenschutzrelevante Informationen gespeichert, ist eine entsprechende Richtlinie vom Datenschutzbeauftragten in Zusammenarbeit mit dem Fachbereich und der BW-Administration erarbeitet werden. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 2 Datenschutz 2 Werden die Gesetze und Richtlinien zur Nutzung des BW-Systems eingehalten? Gesetzliche Vorgaben und interne Richtlinien müssen eingehalten werden. Die Customizing-Einstellungen sowie die Berechtigungsvergabe des BW- Systems sind auf der Grundlage der gesetzlichen Vorgaben und internen Richtlinien zu prüfen. 3 Rechtliche Grundlagen Seite 14 von 128

21 4 Technische Grundlagen eines BW-Systems 4.1 Der Datenfluss im SAP NetWeaver BW Die nachfolgende Abbildung stellt den Datenfluss von den Quelldaten bis zu den InfoProvidern dar. Der Datenfluss beschreibt welche Objekte und Prozesse benötigt werden, um Daten aus einer beliebigen Quelle ins BW zu übertragen um auf deren Grundlage Analysen durchführen und Reports erzeugen zu können. Man erkennt, dass auch Quelldaten aus nicht SAP-Systemen (z.b. Excel- Dateien) in das BW übertragen werden können. Die korrekte Übertragung von Informationen aus Nicht-SAP-Systemen ist ein wichtiger Prüfpunkt. Die Metadatenbeschreibung der Quelldaten wird durch DataSources abgebildet. Jede Aktivierung einer DataSource ist mit der Anlage einer PSA-Tabelle verbunden. Diese bilden die Eingangsablage des BW-Systems. Die Informationen werden unverändert in der Feldstruktur des Quellsystems gespeichert und können, sofern die entsprechenden Berechtigungen vorhanden sind, vor der Weiterverarbeitung verändert werden. Unter Anwendungen von Transformationen werden die Daten aus dem Quellformat ins Zielformat überführt. Mit Transformationen können Daten aus mehreren Quellen konsolidiert und bereinigt werden. Die stichprobenartige Überprüfung der Richtigkeit der Transformationen ist ebenfalls ein wichtiger Prüfungsaspekt. InfoObjects sind die atomaren Bestandteile des BW. Sie bilden die Informationen in strukturierter Form ab, die als Bausteine zum Aufbau von InfoProvidern benötigt werden. InfoProvider bestehen aus InfoObjects und bilden persistente Datenablagen auf deren Basis Analysen und Reports durchgeführt werden. InfoProvider können auch Einfluss auf die Fortschreibung der Daten anderer InfoProvider haben. Über Datentransferprozesse (DTP) werden Daten von einem persistenten Objekt auf ein anderes übertragen. Mögliche Quellen sind DataSources oder InfoProvider, mögliche Ziele InfoProvider oder Open Hub Destinationen (externe Systeme) sein. Der Datenfluss im BW-System ist sehr komplex und damit für den Prüfer nicht einfach zu analysieren. Für den Prüfer stellen sich u.a. folgende Fragen: Welche Daten sind auf welchem Wege in das technische Objekt übertragen worden? Welche Daten aus Datenmodelle? dem ERP-System bilden die Basis der BW- Welche Informationen aus Subsystemen wurden über welche Schnittstelle geliefert? Wie wurden die Ursprungsdaten verdichtet? Datenfluss InfoObjects InfoProvider Datentransferprozesse (DTP) Fragestellungen für den Prüfer 4 Technische Grundlagen eines BW-Systems Seite 15 von 128

22 Nach welchen Regeln erfolgte eine Transformation der Daten? Wie wurden Berechtigungen im BW-System vergeben? Abb. 4: Datenfluss von den Quelldaten zu den InfoProvidern (Quelle: SAP) Transaktion RSA1 4.2 Die Objekte der Modellierung Die Datenmodellierung umfasst alle Aktivitäten vom Anlegen der angeforderten Berichtsstrukturen bis zur Installation des Datenflusses mit allen notwendigen Transformationen von den Datenquellen bis zu den Berichten. Die Grundtransaktion des SAP BW, die Transaktion RSA1 (Data Warehousing Workbench), ist ein unerlässliches Werkzeug für den Prüfer, um sich einen Überblick über die Datenmodellierung bzw. den Datenfluss zu verschaffen. Nachfolgende Abbildung zeigt einen typischen Datenmodellierungsfluss (Kreditoren Einzelposten) im SAP BW durch Aufruf der Transaktion RSA1 (Punkt InfoProvider ). 4 Technische Grundlagen eines BW-Systems Seite 16 von 128

23 Abb. 5: Anzeige eines InfoCubes über die Datawarehouse Workbench (Transaktion RSA1) m Gegensatz zum SAP-ERP-System werden Daten nicht nur in Tabellen gespeichert, sondern durch Objekte, Funktionen und Prozessketten entsprechend den fachlichen Anforderungen modelliert und in komplexen Datenstrukturen abgelegt. In der folgenden Übersicht werden die einzelnen Objekte in ihrer Funktionsweise kurz beschrieben. Symbol Objektname Funktion InfoObject Kleinstes (atomares) Modellierungsobjekt. Kann eine Kennzahl oder ein Merkmal darstellen. Übersicht über die BW- Objekte DataStore-Objekt (DSO) Tabellenartiges Datenziel, das der Ablage von konsolidierten und bereinigten Bewegungsdaten auf Belegebene (atomare Ebene) dient. Ein DS-Objekt beschreibt einen konsolidierten Datenbestand aus einer oder mehreren InfoSources. Dieser Datenbestand kann mit einer BEx Query ausgewertet werden. Es enthält einen Schlüssel (z.b. Belegnummer, -position) sowie Daten- 4 Technische Grundlagen eines BW-Systems Seite 17 von 128

24 felder, die als Kennzahlen auch Charakterfelder (z.b. Kunde) enthalten können. Die Daten eines DS-Objektes können per Delta-Fortschreibung in InfoCubes und/oder weiteren DS-Objekten im selben System oder systemübergreifend fortgeschrieben werden. Im Gegensatz zur mehrdimensionalen Datenablage bei InfoCubes werden die Daten in DS-Objekten in transparenten, flachen Datenbanktabellen abgelegt. InfoCube In sich geschlossenes multidimensionales Datenziel zur Nutzung in der Reportingebene. Zentrales Element für Berichte und Analysen. Der InfoCube ist das mit Abstand wichtigste Datenziel in der BW- Modellierung. Er kann sowohl als Datenziel als auch als InfoProvider eingesetzt werden und ist für schnelle Analysen über große Datenmengen optimiert. Ein InfoCube ist physischer Datenspeicher, der aus einer Anzahl von relationalen Tabellen besteht, die nach dem Sternschema zusammengestellt sind: eine große Faktentabelle im Zentrum und mehrere sie umgebende Dimensionstabellen. Seine Struktur wird durch InfoObjects definiert. Semantisch partitionierte Objekte (SPO) (ab BW 7.3) Er beschreibt einen (aus Reportingsicht) in sich geschlossenen Datenbestand z.b. eines betriebswirtschaftlichen Bereichs. Dieser Datenbestand kann mit der BEx Query ausgewertet werden. SPO s werden nicht über einen Datenladeprozess gefüllt, sondern über DS-Objekte oder InfoCubes. 4 Technische Grundlagen eines BW-Systems Seite 18 von 128

25 Hierin können die Daten innerhalb eines Datenzieles aufgesplittet werden in kleiner Teilobjekte ( Partitionierung ), z.b. nach Kalenderjahr. Dies erfolgt meist aus Gründen der Performance. Technisch besteht das SPO aus mehreren einzelnen DS- Objekten, den Partitionen. In der Workbench ist aber nur ein DS- Objekt sichtbar. HybridProvider (ab BW 7.3) HybridProvider sind eine Mischform aus InfoCube und DS-Objekt. Die Daten aus den Quellsystemen können hier wie in einem VirtualProvider in Echtzeit angezeigt werden ( Realtime Data Acquisition ). Der Unterschied ist aber, dass die Daten hier im BW gespeichert werden, während der VirtualProvider die Daten immer wieder neu lädt. Werden die Daten neu in das DS- Objekt geladen, so können sie sofort im Reporting genutzt werden (noch bevor die Fortschreibung in den InfoCube abgeschlossen ist). Zwei Arten von HybridProvidern sind möglich: InfoCube mit DS-Objekt InfoCube mit VirtualProvider CompositeProvider (ab BW 7.3) Ein CompositeProvider ist ein InfoProvider, der Daten aus mehreren Analytischen Indizes oder weiteren InfoProvidern zusammenführt (per Union oder Inner Join oder Left Outer Join) und für Reporting und Analyse zur Verfügung stellt. Dieser Provider kann nur eingesetzt werden, wenn eine SAP-HANA- Datenbank oder ein SAP NetWeaver BW Accelerator im Einsatz ist. 4 Technische Grundlagen eines BW-Systems Seite 19 von 128

26 TransientProvider (ab BW 7.3) VirtualProvider TransientProvider werden nicht über die BW Workbench modelliert und ihre Daten werden auch nicht ins BW repliziert. Das Reporting erfolgt über den TransientProvider direkt auf den Daten. Datengrundlage kann z.b. sein: Klassische ERP InfoSets (TA SQ01) Eine DataSource der BusinessSuite Ein analytischer Index des Analyseprozess-Designers Der TransientProvider übernimmt automatisch die Struktur der Quelle. Mit den BEx-Tools kann auf den TransientProvider zugegriffen werden. InfoProvider, dessen Bewegungsdaten nicht im Objekt selbst gespeichert werden. Diese werden für Analyse und Reporting direkt bereitgestellt. Die Daten können über einen DTP (Datentransfer-Prozess), ein BAPI oder einen Funktionsbaustein geladen werden. RemoteCube MultiProvider InfoCube, dessen Bewegungsdaten nicht im Business Warehouse verwaltet werden, sondern extern. Im BW wird nur die Struktur des RemoteCube definiert. Die Daten werden zum Reporting über ein BAPI aus einem anderen System gelesen. Der RemoteCube ist eine Form des VirtualProviders. Typ eines InfoProviders, der Daten aus mehreren InfoProvidern zusammenführt und sie gemeinsam für das Reporting zur Verfügung stellt. Der MultiProvider enthält selbst keine Daten; seine Daten ergeben sich ausschließlich aus den zugrundelie- 4 Technische Grundlagen eines BW-Systems Seite 20 von 128

27 genden InfoProvidern, die per Union-Operation zusammengefasst werden. Er kann sich aus verschiedenen Kombinationen von InfoProvidern zusammensetzen. InfoSet MultiProvider sind wie InfoProvider die Objekte bzw. Sichten, die reportingrelevant sind. Datenziel ohne Datenhaltung, das Daten aus mehreren InfoCubes verbinden kann. Ein InfoSet beschreibt Datenquellen, die in der Regel als Joins von DSO- Objekten oder InfoObjects definiert werden. InfoSource Im InfoSet Builder werden InfoSets angelegt und geändert. Auf der Grundlage von InfoSets können Berichte mit Hilfe des Query Designers definiert werden. Menge aller verfügbaren Daten zu einem Geschäftsvorfall oder einer Art von Geschäftsvorfällen (z.b. Kostenstellenrechnung). Eine InfoSource ist eine zu einer Einheit zusammengefasste Menge von logisch zusammengehörigen Informationen. InfoSources können Bewegungsdaten und Stammdaten (Attribute, Texte und Hierarchien) umfassen. Sie ist immer eine Menge von logisch zusammengehörigen InfoObjects. Die Struktur, in der diese abgelegt sind, heißt Kommunikationsstruktur. Bis Release BW 3.5 waren Info- Sources fester Bestandteil eines Datenflusses zwischen DataSource und erstem Datenziel. In BW 7.x werden diese nicht mehr zwingend benötigt. 4 Technische Grundlagen eines BW-Systems Seite 21 von 128

28 Transformation Objekt zur Verknüpfung mehrerer Objekte zu einem Datenfluss und zur Datenumformung. Mit Release BW 7.x sind die Transformationen das zentrale Element, um Daten zwischen einer Quelle und einem Ziel innerhalb eines BW- Datenmodells umzuformen. Sie lösen die Übertragungs- und Transformationsregeln ab. Transformationen steuern die Weiterverarbeitung der Daten zwischen zwei Ob-jekten. Hierbei können die Daten weiter aufbereitet werden, z.b.: Konstante: Der Wert wird ohne Konvertierung in das InfoObject geschrieben. Formel: Hierüber werden Kennzahlen berechnet. Feldroutine: Feldwerte werden über ABAP- Coding ermittelt. Stammdaten nachlesen: Für einen Wert wird ein zusätzliches Attribut ausgelesen und gespeichert (z.b. zu einer Materialnummer die Bezeichnung). Zeitumrechnung: Datumswerte können in andere Einheiten umgerechnet werden (z.b. Datum in Jahr). Übertragungsregel Aus DataStore: Wie bei Stammdaten können auch Werte aus DS-Objekten nachgelesen werden. Mit Release BW 7.0 von der Transformation abgelöstes Objekt, das zur Übertragung von Daten aus dem 4 Technische Grundlagen eines BW-Systems Seite 22 von 128

29 Quellsystem an ein Datenziel genutzt wurde. Die Zuordnung einer DataSource zu einer InfoSource findet mit Hilfe der Über-tragungsregeln im SAP BW statt. Übertragungsregeln ordnen die Felder der DataSource den InfoObjects zu, die die InfoSource bilden. Eine umfassende Bibliothek mit Transformationsfunktionen, die die betriebswirtschaftliche Logik darstellen, kann an diesem Punkt genutzt werden. Fortschreibungsregel Datentransferprozess (DTP) DataSource Persistant Staging Area (PSA) Mit Release BW 7.0 von der Transformation abgelöstes Objekt, das zur Übertragung von Daten zwischen Datenzielen genutzt wurde. Die SAP BW-Fortschreibungsregeln verarbeiten den Datenfluss von Info- Sources zu den Datenzielen (InfoObjects, DS-Objekten, InfoCubes, Semantisch partitionierte Objekte und HybridProvider). Objekt zur Ausführung einer Transformation. Es steuert die Übertragung zwischen zwei Objekten, z.b. DataSource InfoProvider InfoProvider InfoProvider Objekt zur Beschreibung einer Datenquelle. Entweder manuell im BW- System angelegt oder durch Replikation aus einem an BW angeschlossenen SAP-Quellsystem erstellt. Anstelle einer mehrdimensionalen Struktur wird bei der Übertragung der Daten in SAP BW eine flache Struktur (Tabelle) verwendet. DataSources enthalten die Felddefinitionen der Quelldaten. Wenn eine DataSource aktiviert wird, wird neben ihrer Struktur auch die PSA-Tabelle angelegt, in der die geladenen Daten noch nicht in der 4 Technische Grundlagen eines BW-Systems Seite 23 von 128

30 InfoPackage InfoArea Prozesskette Abb. 6: Übersicht über die Objekte des BW 7.x BW-Semantik als Ausprägungen von InfoObjects, sondern unverändert in der Feldstruktur des Quellsystems gespeichert werden (Eingangsablage). Objekt zur Ausführung einer Datenanforderung aus dem Quellsystem. Objekt zur Organisation der Datenmodelle (vergleichbar mit einem Ablage-Ordner) Objekt zur automatisierten Durchführung eines Ladeprozesses entlang eines Datenflusses. Darin werden u.a. InfoPackages und DTPs zum Starten des Ladens eingesetzt. Klassifikation der InfoProvider 4.3 Die InfoProvider In SAP BW werden analysierbare Objekte (Objekte, die für Queries genutzt werden können) als InfoProvider bezeichnet. Sie dienen dazu, die Daten dem Endanwender in einer für Berichte aufbereiteten Form zur Verfügung zu stellen. Es gibt zwei InfoProvider-Arten: InfoProvider, die physische Daten enthalten (Datenziele) - InfoObjects - (O)DS-Objekte - InfoCubes - Semantisch partitionierte Objekte (ab BI 7.3) - HybridProvider (ab BI 7.3) InfoProvider, die keine physischen Daten enthalten - MultiProvider - InfoSets - VirtualProvider - RemoteCubes - CompositeProvider (ab BI 7.3) - TransientProvider (ab BI 7.3) 4 Technische Grundlagen eines BW-Systems Seite 24 von 128

31 Gefüllt werden die Datenziele mit den Daten, die über die DataSources aus den Quellsystemen ausgelesen und in den PSA-Tabellen zwischengespeichert werden. Die Aufbereitung der Daten erfolgt über die InfoSource und Transformation. 4 Technische Grundlagen eines BW-Systems Seite 25 von 128

32 5 Dokumentationen zum SAP BW Berechtigungskonzept Soll-Vorgaben für BW- Prüfung Technische Dokumentation Erweiterung des Dateneigentümerkonzeptes um BW-Spezifika Jede Prüfung benötigt ihre Soll-Vorgaben, so auch die Prüfung des BW- Systems. Da hier die Unternehmensdaten zusammenfließen und äußerst umfassende Auswertungsmöglichkeiten gegeben sind, müssen strikte Vorgaben für die technische Dokumentation des Datenflusses und -speicherung das Dateneigentümerkonzept, das Antrags-, Test- und Freigabeverfahren, die schriftliche Dokumentation, die unternehmenseigenen Anpassungen bzgl. eigener Berechtigungsobjekte, die technische Rollenkonzeption, das Sicherheitskonzept und für das Interne Kontrollsystem vorhanden sein. Die technische Dokumentation des Datenflusses und speicherung Der Datenfluss und die Datenablage im BW-System müssen schriftlich dokumentiert sein. Es muss nachvollziehbar sein, welche Daten über welche Wege ins BW-System gelangen und in welchen Strukturen diese gespeichert werden. Diese Dokumentation ist Voraussetzung, damit der Prüfer die Ordnungsmäßigkeit des BW-Systems beurteilen kann. Das Dateneigentümerkonzept Das Dateneigentümerkonzept regelt, wer für die Genehmigung der Berechtigungs-vergaben für Transaktionen, Berechtigungsobjekte, Organisationsebenen und Rollen verantwortlich ist. Auch sind hier die konkreten Aufgaben der Dateneigentümer beschrieben. Für ein BW-System muss dieses Konzept erweitert werden. Berechtigungen werden hier nicht auf Transaktionsebene vergeben, sondern maßgeblich auf Datenebene. Daher ist die Matrix der Verantwortlichkeiten um die BW-Spezifika zu erweitern. Welche dies sind, ist abhängig vom definierten internen Kontrollsystem und von der Sensibilität der Daten. So kann die Dateneigentümerschaft sowohl auf InfoArea-, InfoCubeund/oder Feldebene (Merkmale) definiert werden, außerdem auch auf Ebene der Analyseberechtigungen. Jegliche Berechtigungsausprägung (Rollenänderungen oder zuweisungen) auf diese Elemente müssen explizit vom Dateneigentümer genehmigt werden. 5 Dokumentationen zum SAP BW Berechtigungskonzept Seite 26 von 128

33 Das Antrags-, Test- und Freigabeverfahren Das Antragsverfahren ist um die BW-Elemente zu erweitern, die im Dateneigentümerkonzept definiert wurden. Das Testverfahren für Berechtigungen ist dahingehend zu ändern, dass auch Negativtests für den Zugriff auf sensible Daten durchgeführt werden. Erweiterung des Antragsverfahrens um BW- Elemente Die Dokumentation Das gesamte Konzept der Berechtigungsvergabe einschließlich der dazugehörigen Customizing- und Sicherheitseinstellungen muss ausführlich und nachvollziehbar dokumentiert sein. Ausführliche und nachvollziehbare Dokumentation Unternehmenseigene Anpassungen Berechtigungs- und sicherheitsseitig lässt BW umfassende kundeneigene Anpassungen zu. Dies können sowohl eigene Berechtigungsobjekte sein, als auch Einstellungen im Customizing. Diese Anpassungen sind ausführlich zu dokumentieren. Ausführliche Dokumentation der unternehmensspezifischen Anpassungen Das technische Rollenkonzept Das technische Rollenkonzept ist um die BW-Spezifika zu erweitern. Hier ist z.b. mit aufzunehmen, wie mit dem Wert : umzugehen ist. Auch ist hier zu beschreiben, wie die eigenen Berechtigungsobjekte in Rollen genutzt werden dürfen. Erweiterung des technischen Rollenkonzeptes um BW-Spezifika Das Konzept für Analyseberechtigungen Analyseberechtigungen stellen den zentralen Schutz der Daten im Reporting dar. Um sie strukturiert verwalten und vergeben zu können, ist ein Konzept zu erstellen das festlegt, wie sie technisch aufgebaut werden und wie die Namenskonventionen sind. Die Analyseberechtigungen sind mit in das Dateneigentümerkonzept zu integrieren. Das Sicherheitskonzept Das Sicherheitskonzept ist eng mit dem Berechtigungskonzept verbunden. Dort sind Einstellungen und Überwachungen definiert, die Auswirkungen auf Berechtigungen haben. Daher ist im Zuge einer Berechtigungsprüfung auch das Sicherheitskonzept zu sichten. Integration der Analyseberechtigungen in das Dateneigentümerkonzept Sicherheitskonzept definiert Einstellungen und Überwachungen Das interne Kontrollsystem Die Erweiterung des internen Kontrollsystems um die BW-Spezifika bedeutet maßgeblich, den lesenden Zugriff auf sensible Daten zu überwachen. Verantwortlich für die Erstellung und Überwachung des internen Kontrollsystems sind die Dateneigentümer. Nur durch ein explizites IKS ist ein dauerhafter Schutz der Unternehmensdaten im BW gewährleistet. Erweiterung des IKS um BW-Spezifika 5 Dokumentationen zum SAP BW Berechtigungskonzept Seite 27 von 128

34 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 3 Dokumentation 2 Existieren die erforderlichen Dokumentationen? Sind diese vollständig und aktuell? Die erforderlichen Dokumentationen dienen als Sollvorgabe für die Prüfung des BW-Systems. Diese sollten alle vorhanden, vollständig und aktuell sein. 5 Dokumentationen zum SAP BW Berechtigungskonzept Seite 28 von 128

35 6 Die Prüferberechtigungen im SAP BW Um eine fundierte Prüfung des BW-Systems vornehmen zu können, ist es für den Prüfer erforderlich, über ausreichende Zugriffsberechtigungen zu verfügen. Nachfolgend werden alle relevanten Zugriffsberechtigungen in tabellarischer Form aufgelistet. Die Prüferberechtigungen für Transaktionen und Berechtigungsobjekte sind nach Prüfungsziel in zwei Gruppen aufgeteilt. Analyse der Modellierung und des Datenflusses Analyse der Berechtigungen Alle Berechtigungsobjekte sind so ausgeprägt, dass nur Leseberechtigungen vergeben werden. Wichtiger Hinweis: Eine Prüferrolle mit den erforderlichen und im Nachfolgenden aufgeführten Berechtigungen (Transaktionen und Berechtigungsobjekte) kann vom PRev- Online-Portal heruntergeladen werden. Notwendige Prüferberechtigungen für die Prüfung eines BW-Systems Prüferrolle als Download verfügbar Prüferrelevante Transaktionen zur Analyse der Modellierung und des Datenflusses RSA1 RSECADMIN RSD1 RSDODSD RSDCUBE RSISET RSDHYBR RSDMPROM RSU3 RSANWB RSDD_LTIP RSLIMO Modellierung - DW Workbench Analyseberechtigungen InfoObjects ODS-Objekte InfoCubes InfoSets HybridProvider MultiProvider Fortschreibungsregeln Analyseprozesse Analytische Indizes CompositeProvider 6 Die Prüferberechtigungen im SAP BW Seite 29 von 128

36 Prüfungsrelevante Berechtigungsobjekte zur Analyse der Modellierung und des Datenflusses S_RSEC S_RS_ADMWB S_RS_DS S_RS_DTP S_RS_HIER S_RS_ICUBE S_RS_IOBC S_RS_IOBJ Infrastruktur der Analyseberechtigungen Data Warehousing Workbench - Objekte Data Warehousing Workbench - DataSource Data Warehousing Workbench - Data Transfer Process Data Warehousing Workbench - Hierarchie Data Warehousing Workbench - InfoCube Data Warehousing Workbench - InfoObjectCatalog Data Warehousing Workbench - InfoObject S_RS_IOMAD Data Warehousing Workbench - Stammdaten pflegen S_RS_ISET S_RS_ISNEW S_RS_ISOUR S_RS_ISRCM S_RS_MPRO S_RS_ODSO S_RS_OHDST S_RS_PC S_RS_TR RSANPR Zusätzlich ab NetWeaver 7.3 S_RS_DMOD S_RS_LPOA S_RS_HYBR Data Warehousing Workbench - InfoSet Data Warehousing Workbench - InfoSource Data Warehousing Workbench - InfoSource (flex. Fortschr.) Data Warehousing Workbench - InfoSource (direkte Fortschr.) Data Warehousing Workbench - MultiProvider Data Warehousing Workbench - DataStore-Objekt Data Warehousing Workbench - Open Hub Destination Data Warehousing Workbench - Prozessketten Data Warehousing Workbench - Transformation Berechtigung für Analyseprozesse Datenfluss Semantisch partioniertes Objekt HybridProvider Zusätzlich ab NetWeaver 7.3 beim Einsatz des BW Accelerators oder SAP HANA S_RS_AINX S_RS_CPRO Analytischer Index CompositeProvider Die Aktivität ist jeweils mit 03 (Anzeigen) auszuprägen. Die nachfolgenden 6 Die Prüferberechtigungen im SAP BW Seite 30 von 128

37 Objekte verfügen jeweils über ein Feld Teilobjekt. Sollen keine betriebswirtschaftlichen Daten angezeigt werden, so sind diese Felder mit allen verfügbaren Werten auszuprägen, außer dem Wert DATA. S_RS_DS S_RS_ICUBE S_RS_IOBJ S_RS_ISET S_RS_ISOUR S_RS_ISRCM S_RS_MPRO S_RS_ODSO S_RS_LPOA S_RS_HYBR Alle weiteren Felder sind mit einem * auszuprägen. Prüfungsrelevante Transaktionen zur Analyse der Berechtigungsvergabe SUIM SU01 / SU01D PFCG SE16 / SPRO / SM30 Benutzerinformationssystem Anzeige einzelner Benutzer Anzeige von Rolleninformationen Anzeige von Customizing-Einstellungen 6 Die Prüferberechtigungen im SAP BW Seite 31 von 128

38 Prüfungsrelevante Berechtigungsobjekte zur Analyse der Berechtigungsvergabe S_ADDRESS1 S_APPL_LOG S_DEVELOP S_TABU_DIS S_USER_AGR S_USER_AUT S_USER_GRP S_USER_PRO S_USER_SYS Business Address Services: Adreßtyp1 Anwendungs-Log ABAP Workbench Tabellenpflege (über Standardtools wie zb SM30) Berechtigungswesen: Prüfung für Rollen Benutzerstammpflege: Berechtigungen Benutzerstammpflege: Benutzergruppen Benutzerstammpflege: Berechtigungsprofil Benutzerstammpflege: System für zentrale Benutzerpflege Die Aktivität ist jeweils mit 03 (Anzeigen) und (soweit möglich) mit 08 (Änderungsbelege anzeigen) auszuprägen. Alle anderen Felder sind mit * auszuprägen. Beim Objekt S_TABU_DIS ist zu beachten, dass mit der *-Ausprägung alle Tabellen eingesehen werden können, also auch die PSA-Tabellen mit den betriebswirtschaftlichen Daten. Soll dies ausgeschlossen werden so darf die Berechtigungsgruppe &NC& nicht berechtigt werden. 6 Die Prüferberechtigungen im SAP BW Seite 32 von 128

39 7 Die Einordnung des SAP BI in die SAP Netweaver Architektur Seit der SAP NetWeaver Version 7.0 ist das Business Warehouse ein integrativer Bestandteil der SAP Basis. Mit SAP NetWeaver Business Intelligence (BI) steht u.a. eine integrierte Ober-fläche für die Modellierung, die Datenbereitstellung und Reporting- und Analyseprozesse zur Verfügung. Die folgende Grafik zeigt, wo BI innerhalb von SAP NetWeaver positioniert ist. Abb. 7: Integration von BI in SAP NetWeaver Quelle: SAP AG Das zentrale Werkzeug für Data Warehousing-Aufgaben im BI ist die Data Warehousing Workbench. Das Data Warehousing im BI beinhaltet folgende Funktionen: Datenextraktion und Datenladen aus den Quellsystemen Transformation und Datenspeicherung Modellierung und Datenbereitstellung für das Reporting Administration der BI-Objekte und -Prozesse Data Warehousing Workbench Die BI Plattform bildet die gemeinsame Oberfläche für die einzelnen Analysekomponenten wie den OLAP Prozessor, Planungsanwendungen und das MetaData Repository. Der Business Explorer (BEx) ist das Werkzeug für flexibles Reporting- und Analysefunktionen. Er bietet Zugriff auf die Informationen im SAP BW über das SAP Enterprise Portal, über das Intranet (Web Application Design) oder über mobile Endgeräte. Business-Explorer (BEx) 7 Die Einordnung des SAP BI in die SAP Netweaver Architektur Seite 33 von 128

40 Abb. 8: BW-Komponenten Quelle: SAP AG 7 Die Einordnung des SAP BI in die SAP Netweaver Architektur Seite 34 von 128

41 8 Risikolandkarte eines BW-Systems In der folgenden Abbildung ist die Risikolandkarte eines BW-Systems dargestellt. Diese Übersicht der möglichen Risiken bildet den Rahmen für die vorgestellten Prüfungshandlungen innerhalb dieses Prüfmanuals. Abb. 9: Risikolandkarte eines BW-Systems Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 4 Risikolandkarte 2 Erstellen Sie als Prüfungsgrundlage eine auf Ihren Betrieb zugeschnittene Risikolandkarte Ihres BW-Systems. Die erforderlichen Dokumentationen dienen als Sollvorgabe für die Prüfung des BW-Systems. Diese sollten alle vorhanden, vollständig und aktuell sein. 9 Prüfen der Basissicherheit eines BW-Systems Zu einer umfassenden Prüfung eines BW-Systems gehört auch die Beurteilung der Basissicherheit des Systems. 9.1 Tabellenprotokollierung SAP bietet die Möglichkeit, Änderungen an Tabellen zu protokollieren. Somit kann nachvoll-zogen werden, welche Benutzer wann in den Tabellen Datensätze verändert, hinzugefügt oder gelöscht haben. Aus Gründen der Systemperformance ist es allerdings nicht sinnvoll, alle Tabellen des Systems protokollieren zu lassen. Tabellenprotokollierung HGB und GoBD-relevanter Tabellen 8 Risikolandkarte eines BW-Systems Seite 35 von 128

42 Protokollierung unternehmenseigener Tabellen Die Tabellenprotokollierung ist somit ein MUSS für Unternehmen. Ist diese nicht aktiviert, so wird gegen gesetzliche Vorgaben verstoßen. Insbesondere sind auch die unternehmenseigenen Tabellen hiervon betroffen. Eigene Tabellen mit rechnungslegungsrelevanten Inhalten müssen ebenso protokolliert werden wie die Standardtabellen von SAP. Grundsätzliche Voraussetzung für die Protokollierung von Tabellen ist das Setzen des Para-meters rec/client auf ALL oder auf die entsprechende Mandantennummer. Ob die Protokollierung für einzelne Tabellen in SAP aktiv ist, kann man über folgende Wege prüfen: Transaktion SE13 Tabelle DD09L Report RDDPRCHK In der Tabelle DD09L wird im Feld PROTOKOLL festgelegt, ob eine Tabelle protokolliert wird. Es ist daher sinnvoll, die Tabelle DD09L ebenfalls in die Protokollierung aufzunehmen. Nähere Informationen zur Tabellenprotokollierung kann man aus den SAP-Hinweisen 1916 und entnehmen. Ferner ist es wichtig, dass unternehmenseigene Tabellen (Namensraum Y*, Z*), die rechnungslegungsrelevante Informationen speichern, ebenfalls in die Protokollierung aufgenommen werden Auswertung Die Tabellenprotokollierung kann mit dem Report RSTBHIST oder RSVTPROT ausgewertet werden. 9 Prüfen der Basissicherheit eines BW-Systems Seite 36 von 128

43 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 5 Risikolandkarte 1 Ist die Tabellenprotokollierung eingeschaltet? Die Protokollierung ist für das Produktivsystem für alle Mandanten zu aktivieren. Ebenso ist die Protokollierung für Importe von Tabelleninhalten zu aktivieren. Überprüfen Sie, ob die Tabellenprotokollierung für das Produktivsystem aktiviert wurde! Rufen Sie im Produktivsystem die Transaktion SA38 (Menüpfad System Dienste Reporting) auf und lassen Sie sich den Report RSPFPAR anzeigen (alternativ die Transaktion RSPFPAR). In der Selektionsmaske geben Sie im Feld Profileparameter den Parameter rec/client ein (Kleinschreibung beachten). Der Parameter muss den Wert ALL enthalten oder alle produktiven Mandanten. Überprüfen Sie, ob für das Produktivsystem die Protokollierung für Importeaktiviert wurde! Rufen Sie die Transaktion SA38 (Menüpfad System Dienste Reporting) auf, und lassen Sie sich den Report RSTMSTPP anzeigen. Tragen Sie im Selektionsfeld System den dreistelligen Namen des Produktivsystems ein (kann ermittelt werden über System Status Datenbankdaten Name). Suchen Sie in der Ergebnisliste nach dem Parameter RECCLIENT. Der Parameter-Wert sollte auf ALL stehen (=Protokollierung für alle Mandanten). 9.2 Standardprofile Folgende Standardprofile sind in einem BW-System mit besonderen Risiken verbunden: SAP_ALL: SAP_ALL / SAP_NEW Kritische Standardprofile in SAP-Systemen 9 Prüfen der Basissicherheit eines BW-Systems Seite 37 von 128

44 S_RS_ALL Kritisches Standardprofil im SAP-BW Das SAP-Standardprofil SAP_ALL umfasst alle Berechtigungen des SAP- Systems. Es umfasst z.b. alle Berechtigungen des Basis-Moduls (Benutzer anlegen und verwalten, die komplette Rechtevergabe, Einstellen der Systemparameter), die Berechtigungen fürs Customizing und für die Entwicklung (komplette ABAP-Berechtigungen) sowie al-le Berechtigungen des Businesswarehouse (BW). Eine Funktionstrennung (z.b. für die Administration zur Vergabe von Berechtigungen, Abwicklung von Geschäftsprozessen, Realisierung eines IKS, etc.) ist mit diesem Profil nicht mehr möglich. Des Weiteren sind Zugriffsrechte enthalten, mit denen gegen geltende Gesetze ver-stoßen werden kann, z.b. elektronisches Radieren und das Löschen von Änderungs-belegen. Daher darf dieses Profil in Produktivsystemen nicht vergeben werden. SAP_NEW: Das Profil SAP_NEW wird nach einem Releasewechsel eingesetzt. Dieses Sammelprofil umfasst Einzelprofile, die für die jeweils neu hinzukommenden Berechtigungsob-jekte Berechtigungen enthalten. Dieses Profil ist Benutzern nur übergangsweise nach einem Releasewechsel zuzuordnen. S_A.SYSTEM: Das Profil S_A.SYSTEM umfasst die Komplettberechtigungen für die Basis, u. a. die gesamte Berechtigungsvergabe und die Komplettberechtigungen für die Entwick-lungsumgebung. Das Profil ist im Produktivsystem keinem Benutzer zuzuordnen. S_RS_ALL: Das Profil S_RS_ALL umfasst alle Berechtigungen des Business Warehouses. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 6 Standardprofile 1 Wurden im produktiven BW-System kritische Standardprofile vergeben? Die Profile SAP_ALL, SAP_NEW, S_A.System und S_RS_ALL sollten im produktiven System an keinen Benutzer (außer Notfallbenutzer) vergeben werden Analysieren Sie die Zuordnung der kritischen Profile durch die Transaktion SUIM. Neben der stichtagsbezogenen Auswertung ist die Analyse der Änderungsbelege der Berechtigungen ebenso wichtig. 9.3 Weitere wichtige Prüfungshandlungen Folgende Punkte sollten ebenfalls im Rahmen einer Basissicherheitsprüfung überprüft werden: Benutzer- und Berechtigungsverwaltung 9 Prüfen der Basissicherheit eines BW-Systems Seite 38 von 128

45 Entwicklertätigkeiten im Produktivsystem Vergabe von gesetzeskritischen Berechtigungen - Löschen von Tabellenprotokollen oder Änderungsbelegen - Debuggen mit Replace - ABAP-Quelltexte über RFC ausführen Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 7 Gesetzeskritische Berechtigungen 1 Wurden im produktiven BW-System gesetzeskritische Berechtigungen vergeben? Berechtigungen zum Löschen von Änderungsprotokollen Löschen von Tabellenprotokollen Debuggen mit Replace und zum Ausführen von ABAP-Quelltexten über RFC sind im Produktivsystem (außer Notfallbenutzer) nicht zu vergeben. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen In diesem Kapitel werden die wichtigsten Analyseschritte vorgestellt, um die Sicherheit des Datenflusses und der Datenablage in Quellsystemen zu überprüfen Technische Kopplung des BW-Systems mit den Quellsystemen RFC-Verbindungen und Benutzer Das BW-System kommuniziert mit anderen SAP -Systemen über eine technische RFC-Verbindung. In diesen Verbindungen sind bereits Benutzerkonten mit Kennwörtern fest hinterlegt. Dies ist notwendig, um eine automatisierte Kommunikation zu ermöglichen. Allerdings birgt dies auch die Gefahr, dass mit diesen RFC-Verbindungen Anmeldungen an die jeweiligen Systeme ohne explizite Kennworteingabe möglich sind. Eine Liste aller existierenden RFC-Verbindungen erhält man über die Transaktion SM59 oder die Tabelle RFCDES (einschränken auf Verbindungstyp 3). 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 39 von 128

46 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 8 RFC- Verbindungen im BW- System k. A. Welche RFC-Verbindung werden für die Kommunikation vom BW-System genutzt und welche Benutzer sind dort hinterlegt Mit diesem Prüfpunkt bekommen Sie einen Überblick, welche Quellsysteme an das BW- System angeschlossen sind. Überprüfen der RFC- Verbindungen zwischen BW und den Quellsystemen Zur Durchführung des Prüfschritts rufen Sie die Transaktion RSA13 auf (alternativ die Transaktion RSA1, Punkt Modellierung Quellsysteme ). In der Spalte techn. Name wird der Name der RFC-Verbindung angezeigt, in der Spalte Objektinformationen ob das System aktiv ist. In nachfolgender Abbildung ist z.b. das System IDES ECC Mandant 800 (RFC-Verbindung T90CLNT800) aktiv. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 40 von 128

47 Den hinterlegten Benutzer ermitteln Sie über die Tabelle RFCDES im Feld Optionen. Dort zeigt der Parameter U= an, welcher Benutzer eingetragen ist: Schnittstellenbenutzer im SAP BW Im SAP BW muss ein Systembenutzer (nicht Dialog oder Service) angelegt sein, standardmäßig ist das BWREMOTE (Benutzername kann aber beliebig gewählt werden). Der Benutzer sollte das Berechtigungsprofil S_BI-WHM_RFC besitzen, welches im SAP BW Auslieferungsumfang für diesen Benutzer vorgesehen ist. Zusätzlich können noch weitere Berechtigungen erforderlich sein (siehe SAP-Hinweis ). Dieses Profil gewährt dem Benutzer BWREMOTE den erforderlichen Zugang zur Extraktion aus einem OLTP-System. Das Profil bietet außerdem den erforderlichen Zugang, damit die Staging-Schritte die Daten in InfoCubes ablegen können. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 41 von 128

48 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 9 Schnittstellenbenutzer im SAP-BW 2 Welcher Benutzertyp und welches Berechtigungsprofil sind dem Schnittstellenbenutzer im SAP BW zugeordnet? Im SAP BW muss ein Systembenutzer (nicht Dialog oder Service) angelegt sein, standardmäßig ist das BWREMOTE (Benutzername kann aber beliebig gewählt werden). Der Benutzer sollte das Berechtigungsprofil S_BI-WHM_RFC besitzen, welches im SAP BW Auslieferungsumfang für diesen Benutzer vorgesehen ist. Zusätzlich können noch weitere Berechtigungen erforderlich sein (siehe SAP-Hinweis ). Überprüfung des Schnittstellenbenutzers im SAP BW System Ob der Benutzer als Kommunikations- oder Systembenutzer eingerichtet ist, können Sie über im SAP -BW-System über die Transaktionen SU01 oder SU01D überprüfen. Er sollte nicht als Dialog- oder Service-Benutzer definiert sein, da diese Benutzertypen für eine Dialoganmeldung genutzt werden können. Über die gleichen Transaktionen können Sie auch die Berechtigungen des für den Datenextrakt genutzten Benutzers ermitteln: 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 42 von 128

49 Schnittstellenbenutzer im SAP Quellsystem Des Weiteren muss in jedem SAP -System, von dem das SAP BW Daten holen kann (Quellsystem), ein Benutzer für diesen Datenabzug definiert sein. der Standardbenutzer hierfür ist BWALEREMOTE, er kann aber einen beliebigen Namen erhalten. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 10 Schnitt- 2 Welcher Benutzername, welcher Benutzertyp stellenbe- und welches Berechtigungsprofil sind dem nutzer im SAP- Quellsystem Schnittstellenbenutzer im SAP Quellsystem zugeordnet? Dieser Benutzer sollte als Kommunikations- oder Systembenutzer eingerichtet sein und das Berechtigungsprofil S_BI-WX_RFC besitzen, das im SAP Standard für diesen Benutzer vorgesehen ist. Zusätzlich können noch weitere Berechtigungen erforderlich sein (SAP-Hinweis ). Der Name kann über die RFC-Verbindung ermittelt werden, die für den Zugriff auf das Quellsystem genutzt wird. Zur Ermittlung des Benutzernamens rufen Sie die Transaktion SM59 auf und lassen Sie sich die RFC-Verbindung anzeigen, die zum Quellsystem zeigt. Im Register Anmeldung & Sicherheit finden Sie den Benutzernamen. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 43 von 128

50 Überprüfung des Schnittstellenbenutzers im SAP Quellsystem Dieser Benutzer sollte als Kommunikations- oder Systembenutzer eingerichtet sein und das Berechtigungsprofil S_BI-WX_RFC besitzen, welches im SAP Standard für diesen Benutzer vorgesehen ist. Zusätzlich können noch weitere Berechtigungen erforderlich sein (SAP-Hinweis ). Mit diesem Profil erhält der Benutzer die erforderlichen Rechte, um die Verbindung zum SAP BW-System herzustellen und Daten an dieses System zu übermitteln. Um den Benutzertyp und die Berechtigungen des für den Datenextrakt im Quellsystem genutzten Benutzers zu überprüfen, rufen Sie im SAP Quellsystem die Transaktion SU01 oder SU01D auf: 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 44 von 128

51 10.2 DataSources DataSources (=Datenquellen) beschreiben die Daten, die aus einem Quellsystem extrahiert werden sollen. Technisch enthält eine DataSource logisch zusammengehörige Felder, die in einer flachen Struktur, der Extraktstruktur, zur Datenübertragung ins SAP BW genutzt werden. DataSources werden im SAP Quellsystem gepflegt und ins SAP BW repliziert. Im SAP BW können 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 45 von 128

52 DataSources ebenfalls gepflegt werden, z.b. wenn die Quelle eine Datei im Betriebssystem ist. Werden Daten extrahiert, so wird für die Extraktion jeweils die DataSource angegeben. Diese legt über ihre Struktur die zu extrahierenden Daten fest: Anzeige der DataSources Die kundeneigenen sowie die im Standardumfang enthaltenen DataSources können Sie sich mit der Transaktion RSA6 anzeigen lassen. Tabellen der DataSources Alternativ können diese Informationen auch über die Tabellen ROOSOURCE Liste der DataSources ROOSOURCET Texte zu den DataSources abgerufen werden 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 46 von 128

53 Eine Einzelanzeige der DataSources ist über die Transaktion RSA2 möglich. Einzelanzeige der DataSources Dem Register Allgemeines können Sie eine Beschreibung der DataSource, die Benutzer-ID und den Zeitpunkt der letzten Änderung entnehmen. Aus dem Register Felder können Sie die Felder identifizieren, die aus dem Quellsystem extrahiert werden. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 47 von 128

54 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 11 Data- Sources 2 Wer darf DataSources im Quellsystem pflegen? Die DataSources sollten nur von den BW- Administratoren gepflegt werden können. Die Verwaltung der DataSources wird in den Quellsystemen durch zwei Berechtigungsobjekte gesteuert, welche der Klasse RO (Berechtigungen BW Service API) zugeordnet sind: Berechtigung zum Pflegen und Aktivieren von DataSources Im Folgenden wird dargestellt, wie man mit der Transaktion SUIM oder dem Report RSUSR002 überprüfen kann, wer DataSources im Quellsystem pflegen und aktivieren darf. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 48 von 128

55 Remote-Aktivierung von DataSources Diese Berechtigung ist erforderlich, wenn über die Business Content-Pflege im BI per Remote-Anmeldung (RFC) die zu einem Ladeszenario gehörenden DataSources des Service API (Objekttyp OSOD) aus dem Business Content übernommen wollen sollen Extraktoren Die Datenextraktion im SAP-System erfolgt über Extraktoren. Jeder DataSource ist ein Extraktor zugeordnet. Dies sind Funktionsbausteine, über welche die Daten ausgelesen werden. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 49 von 128

56 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 50 von 128

57 Analysiert man den Quelltext des Funktionsbausteins erkennt man im Abschnitt Tables welche Tabellen des Quellsystems Grundlage für den Extraktor bzw. die DataSource sind. Die DataSource 0FI_AP_1 besitzt die Beschreibung Kreditoren Verkehrszahlen. Wer sich in den Tabellenstrukturen des SAP-Quellsystems auskennt weiß, dass in der Tabelle LFC1 die Verkehrszahlen der Kreditoren gespeichert sind. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 12 Extraktoren 2 Ist das Pflegen von Extraktoren im Produktivsystem möglich? Das Pflegen von Extraktoren sollte im produktiven Quellsystem nicht möglich sein. Ermittlung der Datengrundlage des Extraktors Die Pflege von Extraktoren (=Funktionsbausteinen) darf im Produktivsystem nicht möglich sein. Dies wird dadurch erreicht, dass die Anwendungsentwicklung ausgeschlossen wird. Dies erfolgt über drei Sicherheitsmechanismen: Setzen der Systemänderbarkeit auf Nicht änderbar (Prüfen mit Report RSWBO004) Keine Entwicklerschlüssel im Produktivsystem (Prüfen mit Tabelle DEVACCESS) Keine Vergabe von Berechtigungen zur Anwendungsentwicklung (Berechtigungsobjekt S_DEVELOP, Aktivitäten 01 / 02) 10.4 Extraktorenchecker Mit dem Extraktorenchecker ist es für den Administrator oder Entwickler möglich, Extraktoren auf ihre Funktionsfähigkeit zu prüfen. Bei dieser Prüfung können auch die extrahierten betriebswirtschaftlichen Daten eingesehen werden. Dieses ist eine sehr sensible Funktionalität, da es dadurch z.b. möglich ist in einem HCM-System Personal- und Gehaltsdaten auszulesen. Aufgerufen wird der Extraktionschecker mit der Transaktion RSA3. Keine Vergabe der Pflegeberechtigung von Extraktoren im Produktivsystem! Der Extraktorchecker - eine datenschutzsensible Transaktion 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 51 von 128

58 Anzeigen einer DataSource Zum Anzeigen der Daten einer DataSource (im obigen Beispiel 0HR_PY_1 Abrechnungsergebnisse) klicken Sie auf die Schaltfläche Extraktion. Nach der Extraktion werden drei neue Schaltflächen angezeigt: ALV-Grid, Liste und Log. Über die Schaltflächen ALV-Grid und Liste werden die extrahierten Daten angezeigt. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 52 von 128

59 Wie man sieht, können pro Personalnummer und Leistungsart ausgezahlte Beträge eingesehen werden. Daher ist aus Datenschutzgesichtspunkten der Extraktorchecker ein sensibles Werkzeug. Die Berechtigungen zur Anzeige der extrahierten Daten (DataSources) sollten daher nach dem Minimalprinzip vergeben werden. Welche Berechtigungen hierbei geprüft werden, wird im Funktionsbaustein des Extraktors festgelegt. Es kann daher nicht garantiert werden, dass für alle betriebswirtschaftlichen Daten korrekte Berechtigungsprüfungen implementiert sind. Daher ist diese Transaktion nur an den Personenkreis zu vergeben, der für die fehlerfreie Datenübertragung (technisch und inhaltlich) verantwortlich ist. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 13 Extraktorchecker 2 Wer besitzt Berechtigungen, um sich sensible Daten über den Extraktorchecker anzusehen? Diese Berechtigung sollte nur die BW- Administration besitzen. Die grundlegende Berechtigung zum Anzeigen von Daten der DataSources wird wieder über das Berechtigungsobjekt S_RO_OSOA gesteuert. Wer diese Berechtigungen besitzt kann über den Report RSUSR002 oder über die Transaktion SUIM ermittelt werden. Berechtigung zum Anzeigen einer DataSource 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 53 von 128

60 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 14 Extraktorchecker 2 Wer hat mit dem Extraktorchecker sensible DataSources aufgerufen? Es ist zu klären, ob diese Mitarbeiter dazu organisa-torisch berechtigt waren und ob die Zugriffe aufgabenbezogen erfolgten. Protokollierung der Nutzung des Extraktorcheckers Protokolle über die Nutzung des Extraktorcheckers werden im Anwendungs- Log gespeichert. Dieses wird über die Transaktion SLG1 aufgerufen. In der Selektionsmaske kann auf die Transaktion RSA3 eingegrenzt werden. Im Log wird angezeigt, wer zu welchem Zeitpunkt diese Transaktion mit welcher DataSource ausgeführt hat. 10 Prüfen des Datenflusses und der Datenablage in Quellsystemen Seite 54 von 128

61 11 Prüfung des Datenflusses und der Datenablage im BW-System In diesem Kapitel werden die wichtigsten Analyseschritte vorgestellt, um die Sicherheit des Datenflusses und der Datenablage eines BW-Systems zu überprüfen. 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 55 von 128

62 11.1 PSA-Tabellen PSA-Tabellen die Eingangsablage eines BW Systems Das SAP BW empfängt Daten aus einem oder mehreren Quellsystemen, wobei es sich hierbei um SAP- als auch SAP-fremde Systeme handeln kann. Die aus den Quellsystemen über Datenextraktoren hochgeladenen Dateien werden im SAP BW in eine für das Unternehmen aussagefähige Form gebracht, d.h. sie werden zu Informationen aufbereitet. Den Datenfluss veranschaulicht die nachfolgende Grafik. Abb. 10: Datenfluss eines BW-Systems (Quelle: SAP ) Anhand der Grafik erkennt man, dass die Persistent Staging Area-Tabellen (PSA-Tabellen) die physische Eingangsablage für die Daten aus den Quellsystemen ist. Die Speicherung der Daten erfolgt in transparenten, relationalen Datenbanktabellen des SAP BW. Das Datenformat bleibt in der PSA-Tabelle im Wesentlichen unverändert zum Quellsystem, d.h. es erfolgen keinerlei Verdichtungen oder Transformationen. Unter Umständen können Konvertierungen notwendig werden, um eine Einheitlichkeit der Daten im SAP BW zu gewährleisten, z.b. wenn das Datumsformat im Quellsystem von dem im SAP BW verwendeten Format JJJJMMTT abweicht. Eine DataSource - eine PSA- Tabelle Es wird pro DataSource eines Quellsystems eine PSA-Tabelle angelegt. Die Daten der Anforderung werden in der PSA-Tabelle im Format der Transferstruktur der DataSource abgelegt. Zusätzlich enthält die PSA-Tabelle Systemfelder. Bei jeder Änderung der Transferstruktur wird eine neue PSA- Tabelle generiert. PSA-Tabellen werden im Namensraum /BI* angelegt. Der Tabellenname wird auto-matisch generiert, z.b. /BIC/B Durch das Anzeigen einer 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 56 von 128

63 PSA-Tabelle mit einer Tabellenanzeigetransaktion kann der vollständige Inhalt angezeigt werden. Man erkennt, dass über PSA-Tabellen auch der Zugriff auf sensible Daten möglich ist. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 15 PSA- Tabellen 2 Wer kann sich PSA-Tabellen anzeigen lassen? Durch den lesenden Zugriff auf PSA-Tabellen können sensible Informationen (z.b. Gehälter, Bilanzinformationen) offengelegt werden. Beim Anzeigen der PSA-Tabellen mittels z.b. SE16 werden die Tabellenanzeigeberechtigungen geprüft. Standardmäßig sind die PSA-Tabellen keiner Tabellenberechtigungsgruppe zugeordnet. Das bedeutet, sie werden über die Berechtigungsgruppe &NC& geschützt. Benutzer mit einer Anzeigeberechtigung auf diese Gruppe können sich über die PSA-Tabellen sämtliche Daten im BW- System anzeigen lassen. Um zu prüfen, wer sich PSA-Tabellen anzeigen lassen kann, müssen Sie mit der Transaktion SUIM oder dem Report RSUSR002 ermitteln, wem folgendes Berechtigungsobjekt zugeordnet ist: Berechtigung zur Anzeige von PSA-Tabellen Berechtigungsobjekt S_TABU_DIS Aktivität 03 (Anzeigen) Berechtigungsgruppe &NC& 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 57 von 128

64 Schutz sensibler Daten in PSA-Tabellen Ändern der Inhalte von PSA-Tabellen Zum Schutz des Anzeigens sensibler Daten können zwei Maßnahmen getroffen werden: 1. Berechtigungen auf die Tabellenberechtigungsgruppe &NC& werden nicht vergeben. 2. Die PSA-Tabellen mit den sensiblen Inhalten werden expliziten Berechtigungsgruppen zu geordnet. Es ist zu beachten, dass nach jeder Änderung der Transferstruktur eine neue PSA-Tabelle angelegt wird und dieser der Gruppe zuzuordnen ist. Noch kritischer als die Berechtigung zum Anzeigen ist die Berechtigung zum Ändern von PSA-Tabellen vor der Übertragung der Daten in die Datenziele. Dies kann erforderlich sein, wenn z.b. fehlerhafte Datensätze übertragen werden. Es können aber auch relativ einfach Manipulationen an den Daten vorgenommen werden. Daher ist diese Berechtigung nur sehr restriktiv zu vergeben. Ein Ändern der PSA-Tabellen ist nur möglich, wenn die Daten noch nicht in ein Datenziel übertragen wurden. Um eine PSA-Tabelle zu modifizieren ruft man die Administrator Workbench (Transaktion RSA1) auf und markiert die zur PSA-Tabelle zugehörige DataSource. Mit der Funktionstaste STRG+UMSCHALT+F6 kann man sich die bereits verarbeiteten Datenrequests ansehen: Aus dieser Ansicht können Sie sich als Prüfer schnell ein Bild darüber machen, ob Datenrequests zu ausgewählten kritischen DataSources fehlerfrei durchlaufen. 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 58 von 128

65 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 16 Datenrequest 2 Laufen Datenrequests für DataSources fehlerfrei durch? Gibt es Richtlinien in denen der Umgang mit fehlerhaften Requests geregelt ist? Häufige fehlerhafte Datenrequests können ein Indiz für technische Probleme zwischen Quellund BW-System sein. Fehlerhafte Requests müssen bereinigt werden, um die Datenkonsistenz zwischen Quell- und BW-System zu gewährleisten. Man wählt nun einen Request und ein Datenpaket aus Und ist nun in der Ansicht der in den PSA-Tabellen gespeicherten Daten. Durch Klicken auf ein Feld eines Datensatzes kommt man in die Änderungsmaske und kann jetzt Daten manipulieren. 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 59 von 128

66 So sieht der Datensatz nach der Manipulation aus. Die Personalnr. wurde von auf geändert. Es wird deutlich, dass PSA-Tabellen besonders gegen Veränderungen geschützt werden müssen. Der Zugriff auf diese Daten ist nur sehr eingeschränkt zu vergeben, da hier z.b. nicht nach Organisationsebenen berechtigt werden kann. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 17 PSA- Tabellen 2 Wer kann die Inhalte von PSA-Tabellen modifizieren? Durch diese Berechtigung können Informationen in PSA-Tabellen manipuliert werden. Manipulierte Informationen werden dann entsprechend unkontrolliert im BW-System weiterverarbeitet. Berechtigung zum Ändern von PSA-Tabellen Folgende Berechtigung wird zum Ändern von PSA-Tabellen benötigt: Berechtigungsobjekt S_RS_DS Aktivität 23 (Daten der PSA pflegen) Teilobjekt zur DataSource Quellsystem DataSource DATA <Name des Quellsystems> <Technische Bezeichnung der DataSource> An wen diese Berechtigung vergeben wurde, können Sie wie gewohnt mit der Transaktion SUIM oder dem Report RSUSR002 ermitteln. 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 60 von 128

67 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 18 PSA- Tabellen 2 Gibt es häufig Änderungen an PSA-Tabellen die zu kritischen DataSources gehören? Häufige Änderungen können ein Hinweis auf technische Probleme odermanipulative Vorgänge sein. Für einen Prüfer ist wichtig, nicht nur Snapshot-Informationen (stichstagsbezogen) auszuwerten sondern auch Veränderungen über die Zeit (verlaufsbezogen) zu analysieren. Welche Datensätze von PSA-Tabellen manuell geändert wurden, wird in der Tabelle RSERRORHEAD gespeichert. Zum Request wird die Nummer des geänderten Datensatzes, der letzte Änderer und die Uhrzeit gespeichert. Nicht nur Snapshot- Informationen sondern auch Veränderungen über die Zeit analysieren. Der UTC-Zeitstempel zeigt an, wann der Datensatz geändert wurde. Er ist allerdings als Zahl mit Tausenderpunkten formatiert. Im oberen Beispiel ist der Zeitstempel wir folgt zu lesen: Maske: JJ.JJM.MTT.hhm.mss Tabelleneintrag: Zeitstempel: :13:17 (17. Oktober 2013 um 15:13:17 Uhr) Wichtig! Was geändert wurde, wird nicht protokolliert. Um zu ermitteln, welche Daten geändert wurden, muss über die Anforderungsnummer (Request) ermittelt werden, zu welcher DataSource die PSA- Tabelle gehört. Hierzu werden folgende Tabellen benötigt: Tabelle RSERRORHEAD Inhalt Änderungsinformationen an PSA-Tabellen RSTSODSREQUEST Zuordnung des Requests zum ODS RSDSTS Zuordnung Transferstruktur zur PSA-Tabelle Diese drei Tabellen können mit dem QuickViewer (Transaktion SQVI) verknüpft und deren Inhalte analysiert werden. Die Verknüpfung der Tabellen ist in der folgenden Abbildung dargestellt. Veränderungen an PSA- Tabellen mit dem Quick- Viewer analysieren 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 61 von 128

68 In der folgenden Abbildung ist das Ergebnis einer QuickView-Abfrage dargestellt. Zusätzlich zu den Informationen die in der Tabelle RSERRORHEAD gespeichert sind, wurde nun ermittelt, welche DataSource von diesen Änderungen betroffen ist. Man erkennt, dass Änderungen an Abrechnungsdaten vorgenommen wurden. PSA-Tabellen sollten nach der Verarbeitung in regelmäßigen Abständen gelöscht werden (über Prozessketten), um das Risiko des unkontrollierten Zugriffs zu verringern. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 19 PSA- Tabellen 2 Werden PSA-Tabellen in regelmäßigen Abständen gelöscht? Nicht gelöschte PSA-Tabellen erhöhen das Risiko von unerlaubten Zugriffen auf sensible Informationen Überprüfung des Datenflusses ausgewählter InfoProvider In den vorangegangenen Prüfschritten wurden einzelne Stationen des Datenflusses aus dem Quellsystem in das SAP BW überprüft. Es ist aber ebenso wichtig, sich den gesamten Datenfluss darstellen zu lassen, um zu erkennen aus welchen Quellen Informationen kommen und in welchen Informationseinheiten des SAP BW diese gespeichert werden. 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 62 von 128

69 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 20 Datenfluss ausgewählter InfoProvider 2 Gibt es im Datenfluss für ausgewählte InfoProvider sensible Quellen oder Verarbeitungsschritte, die näher untersucht werden sollten? Bei sensiblen Datenquellen sollte die Herkunft und die Qualität der Daten geprüft werden. Um sich einen Datenfluss im BW System anzeigen zu lassen, verwenden Sie die AdministratorWorkbench (Transaktion RSA1) und wählen das zu untersuchende Objekt aus (in unserem Beispiel Mitarbeitergenaue Abrechnungsdaten ). Anzeige des Datenflusses von InfoProvidern Über das Kontextmenü (rechte Maustaste) können Sie nun den Punkt Datenfluss anzeigen auswählen und bekommen eine graphische Darstellung des Datenflusses zu diesem InfoCube. 11 Prüfung des Datenflusses und der Datenablage im BW-System Seite 63 von 128

70 Man erkennt, dieser InfoCube wird aus zwei Quellen gespeist. Aus einem SAP- System (IDES ECC Mandant 800) und einem externen Datenträger (BWHR Flat Files). Da es sich um wichtige und sensible Abrechnungsdaten handelt, würde man in einem Prüfschritt die Datenherkunft und-qualität des Datenträgers analysieren. 12 Berechtigungen im Reporting In diesem Kapitel werden die wichtigsten Analyseschritte vorgestellt, um die vergebenen Analyseberechtigungen zu überprüfen. 12 Berechtigungen im Reporting Seite 64 von 128

71 12.1 Konzept der Reporting-Berechtigungen Berechtigungen im Reporting unterscheiden sich, wie bereits in der Einleitung erwähnt, maßgeblich von Berechtigungen, die in OLTP-Systemen vergeben werden. In OLAP-Systemen werden Berechtigungen nicht funktionsbasierend, sondern auf Dateninhaltzugriffe vergeben. In der nachfolgenden Tabelle werden die wesentlichen Unterschiede zwischen beiden Konzepten verdeutlicht. OLTP-System (z.b. SAP ERP) Transaktionsberechtigungen legen fest, auf welche Funktionen der Benutzer zugreifen darf. Objekt: S_TCODE Mit Berechtigungsobjekten wird festgelegt, welche Daten innerhalb der Transaktion angezeigt / gepflegt werden dürfen. OLAP-System (SAP BW) Über Berechtigungen auf Queries wird festgelegt, auf welche Daten ein Anwender zugreifen darf. Objekt: S_RS_COMP Analyseberechtigungen legen fest, auf welche Daten innerhalb der Query zugegriffen werden darf(buchungskreis, Kostenstellen etc.). Unterschiede der Berechtigungsvergabe zwischen OLTP- und OLAP-Systemen 12.2 Welche Berechtigungssystematik wird genutzt. Mit dem SAP BW-Release 7.0 wurde das alte Berechtigungskonzept von einem neuen Konzept der sogenannten Reporting-Berechtigungen abgelöst. Die Reporting-Berechtigungen regeln, auf welche Daten innerhalb einer Query der Benutzer Zugriff hat, indem auf die berechtigungsrelevanten InfoObjects berechtigt wird. Bis zum BW-Release 7.2x kann weiterhin die alte Systematik eingesetzt werden, die bis BW-Release 3.5 genutzt wurde. Ab Release 7.30 werden nur noch Analyseberechtigungen unterstützt. In der folgenden Tabelle sind die wesentlichen Unterschiede zwischen beiden Berechtigungssystematiken dargestellt. Kategorie Pflege Prüfung Dimensionen Reportingberechtigungen 3.x Ein eigenes RSR-Klassen- Berechtigungsobjekt zur Berechtigungsanalyse wird angelegt. Berechtigungsobjekte müssen für die Prüfung auf einem InfoProvider zusätzlich angeschaltet werden. Begrenzung auf zehn Felder innerhalb eines Berechtigungsobjektes. Analyseberechtigungen BW 7.x Berechtigungen werden direkt als Analyseberechtigungen erstellt. Jedes berechtigungsrelevante Merkmal eines InfoProviders wird zur Prüfung herangezogen (Eindeutigkeit!) Beliebige Anzahl von Info-Objects; als OLAP- Schranke gilt es, nicht mehr als zehn berechti- Unterschiede zwischen alter und neuer Berechtigungssystematik. 12 Berechtigungen im Reporting Seite 65 von 128

72 Hierarchien Standardberechtigungen Gültigkeit Zusammenfassung Berechtigungen auf Hierarchien werden abseits der Merkmalswerte angelegt und gepflegt. Sie müssen über eine eindeutige ID, die nichts über den Inhalt der Berechtigung aussagt, in Profile eingepflegt werden. Auch für die Ausführung einer Query werden Standardobjekte wie S_RS_HIER, S_RS_MPRO, S_RS_ISET usw.geprüft. Somit liegt keine klare Trennung der Berechtigungen im Modellierungs- und Reportingbereich vor. Die Gültigkeit einer Berechtigung wird durch die Rollenpflege gesteuert. Die wenigen BW- Transaktionen wurden mit dem klassischen Berechtigungssystem abgesichert. Für das Reporting wurden fast keine vordefinierten Berechtigungsobjekte ausgeliefert. gungsrelevante Merkmale je Query zu verwenden. Hierarchien werden direkt mit den Merkmalswerten gepflegt und sind somit gleichwertig zu Werte- oder Intervallberechtigungen. Berechtigungen auf InfoProvider und Aktivitäten werden durch die dafür eingeführten und verpflichtend zu berechtigten Spezialmerkmale 0TCAIPROV und 0TCAACTVT abgedeckt. Es kann eine beliebige, aber verpflichtende Gültigkeit über 0TCAVALID vergeben werden. Dabei sind Muster, bestimmte Zeiträume etc. erlaubt. Das neue Berechtigungskonzept ist anders als sein Vorgänger konzipiert. Es schützt die Datensicht. Bei den Analyseberechtigungen müssen die InfoObjects einzeln als berechtigungsrelevant gekennzeichnet werden. Die Generierung der Berechtigungen wird protokolliert. (RSE- 12 Berechtigungen im Reporting Seite 66 von 128

73 Quelle: Auszug aus John, Kiener (2012) CADMIN) Bevor mit dem Prüfen der Berechtigungen begonnen werden kann, muss geprüft werden, welches Verfahren zur Berechtigungsvergabe eingesetzt wird. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 21 Berechtigungssystematik 2 Welche Berechtigungssystematik ist im zu prüfenden BW-System aktiv? Dieser Prüfschritt ist nur für BW-Releases 7.0 bis 7.2x relevant. Für BW-Releases 7.0 bis 7.2x ist der Prüfschritt wichtig, um zu wissen nach welcher Berechtigungssystematik geprüft werden muss. Wichtig: In diesem Manual werden nur die Prüfschritte nach der neuen Systematik erläutert. Welches Verfahren zur Berechtigungsvergabe aktuell genutzt wird, kann über das Customizing ermittelt werden. Rufen Sie hierfür die Transaktion SPRO auf klicken Sie auf die Schaltfläche SAP Referenz-IMG. Wählen Sie dann den folgenden Pfad aus und klicken auf den Eintrag Analyseberechtigungen: Konzept auswählen: 12 Berechtigungen im Reporting Seite 67 von 128

74 Alternativ kann diese Information auch mit der Transaktion RSCUSTV23 oder über die Tabelle RSECADMINC abgerufen werden. In der Selektionsmaske der Tabelle müssen Sie das Feld Customizing ID auf den Wert BW enschränken. Im weiteren Verlauf des Beitrags wird nur auf die neue Berechtigungskonzeption eingegangen. Frontend für Reporting Anwender der BEx- Analyzer 12.3 Der BEx-Analyzer Die am häufigsten verwendeten Frontends für Reporting-Anwender sind der BEx-Analyzer (Business Explorer), der in MS Excel integriert ist, und der Zugriff auf Queries über ein Portal. Wird der BEx-Analyzer genutzt, so stehen unter Add-Ins dessen Funktionen zur Verfügung. Über die Schaltfläche Öffnen kann der Benutzer die Query auswählen, die ausgeführt werden soll. 12 Berechtigungen im Reporting Seite 68 von 128

75 Mit der Schaltfläche Rollen werden ihm seine Menürollen angezeigt mit den dort hinterlegten Verzeichnisstrukturen und Queries. Mit der Schaltfläche InfoAreas kann sich der Benutzer die Struktur anzeigen lassen, die in der Modellierung in der Transaktion RSA1 angelegt wird. Diese Schaltfläche kann auch ausgeblendet werden. Welche InfoAreas und InfoProvider dem Benutzer hier angezeigt werden, wird mit den Berechtigungsobjekten S_RS_COMP und S_RS_COMP1 berechtigt. Query-Auswahl im BEx-Analyzer mit Berechtigung auf alle InfoAreas und InfoProvider: Query-Auswahl im BEx-Analyzer mit eingeschränkter Berechtigung: 12 Berechtigungen im Reporting Seite 69 von 128

76 Query-Auswahl im BEx-Analyzer Mit dem Berechtigungsobjekt S_RS_FOLD wird gesteuert, ob ein Benutzer im BEx-analyzer bei der Query-Auswahl den Button InfoAreas angezeigt bekommt oder ob dieser ausgeblendet wird. Soll der Button InfoAreas ausgeblendet werden, so ist das Feld SUP_FOLDER auf den Wert X zu setzen. Berechtigung: Ansicht für den Benutzer: Der Button InfoAreas wird durch die Berechtigung ausgeblendet Reporting-Berechtigungen S_RS_COMP und S_RS_COMP1 Welche Queries ein Benutzer ausführen darf wird mit den Berechtigungsobjekten S_RS_COMP und S_RS_COMP1 gesteuert. Maßgeblich werden die Berechtigungen gesteuert über die Angabe der InfoProvider und InfoAreas, auf die ein Benutzer zugreifen darf. Dies wird mit S_RS_COMP gesteuert. Das Objekt enthält folgende Felder: S_RS_COMP Aktivität (ACTVT) Legt fest, ob ein Benutzer Queries nur ausführen oder auch anlegen, ändern oder löschen darf: 01 Queries anlegen 02 Entwurf der Queries ändern 03 Entwurf der Queries anzeigen 06 Queries löschen 12 Berechtigungen im Reporting Seite 70 von 128

77 16 Queries ausführen InfoArea (RSINFOAREA) InfoCube (RSINFOCUBE) Name (ID) einer Reporting- Komponente (RSZCOMPID) Legt fest, auf welche InfoAreas ein Benutzer zugreifen darf. Legt fest, auf welche InfoProvider ein Benutzer zugreifen darf. Wichtig: Der Benutzer benötigt für alle InfoProvider auch jeweils eine Berechtigung für eine darüberliegende InfoArea, ansonsten ist kein Zugriff auf den InfoProvider möglich. Legt fest, auf welche Queries ein Benutzer zugreifen darf. Für Queries existieren häufig Namenskonventionen, über die z. B. Queries mit sensiblen Daten abgegrenzt werden können. Typ einer Reporting- Komponente (RSZCOMPTP) CKF Berechnete Kennzahl Berechnete Kennzahlen bestehen aus Formeldefinitionen, in welche Basiskennzahlen, eingeschränkte oder bereits berechnete Kennzahlen einfließen RKF Eingeschränkte Kennzahl Eingeschränkte Kennzahlen können durch eine oder mehrere Merkmalsselektionen eingeschränkt werden. sie kann sowohl eine Basiskennzahl, eine berechnete Kennzahl oder eine bereits eingeschränkte Kennzahl sein. STR Struktur (Template) Eine Struktur bildet das Grundgerüst für die Achse einer Tabelle (Zeilen oder Spalten). Sie besteht aus Strukturbestandteilen. Man unterscheidet zwischen Kennzahlstrukturen und Merkmalsstrukturen. VAR Variable Variablen sind Parameter einer Query, die im BEx Query Designer definiert und erst beim Ausführen der Query mit Werten gefüllt werden. 12 Berechtigungen im Reporting Seite 71 von 128

78 REP Query Dies sind die eigentlichen Abfragen, mit denen die Endanwender arbeiten. QVW Query View Ein Query View enthält einen Ausschnitt oder einen Navigationszustand einer Query oder eines externen InfoProviders. Zu einer Query können beliebig viele Views definiert werden. Endanwender benötigen den Wert REP in diesem Feld. Werden Views genutzt dann auch den Wert QVW. Die nachfolgende Berechtigung gestattet das Ausführen aller Queries und Query Views aus den InfoProvidern 0HR* und ZHR*, die in der InfoArea ZHR* liegen. Mit dem Berechtigungsobjekt S_RS_COMP1 kann auf den Ersteller einer Query berechtigt werden. Beispiel: Der FI-Modulbetreuer BMEYER erstellt Queries für die Finanzbuchhaltung. Alle Mitarbeiter der Finanzbuchhaltung sollen auf diese Queries zugreifen können. Andere Abteilungen sollen keinen Zugriff auf diese Queries haben. Diese Anforderung kann mit dem Berechtigungsobjekt S_RS_COMP1 abgebildet werden. Das Berechtigungsobjekt enthält folgende Felder: S_RS_COMP1 Aktivität (ACTVT) Legt fest, ob ein Benutzer Queries nur ausführen oder auch ändern oder löschen darf: 02 Entwurf der Queries ändern 03 Entwurf der Queries anzeigen 06 Queries löschen 16 Queries ausführen Die Aktivität 01 entfällt, da bei der Anlage bzw. dem Erzeugen von Queries eine Prüfung auf den Besitzer /Owner nicht erforder- 12 Berechtigungen im Reporting Seite 72 von 128

79 lich ist. Name (ID) einer Reporting- Komponente (RSZCOMPID) Legt fest, auf welche Queries ein Benutzer zugreifen darf. Für Queries existieren häufig Namenskonventionen, über die z. B. Queries mit sensiblen Daten abgegrenzt werden können. Typ einer Reporting- Komponente (RSZCOMPTP) CKF Berechnete Kennzahl Berechnete Kennzahlen bestehen aus Formeldefinitionen, in welche Basiskennzahlen, eingeschränkte oder bereits berechnete Kennzahlen einfließen RKF Eingeschränkte Kennzahl Eingeschränkte Kennzahlen können durch eine oder mehrere Merkmalsselektionen eingeschränkt werden. sie kann sowohl eine Basiskennzahl, eine berechnete Kennzahl oder eine bereits eingeschränkte Kennzahl sein. STR Struktur (Template) Eine Struktur bildet das Grundgerüst für die Achse einer Tabelle (Zeilen oder Spalten). Sie besteht aus Strukturbestandteilen. Man unterscheidet zwischen Kennzahlstrukturen und Merkmalsstrukturen. VAR Variable Variablen sind Parameter einer Query, die im BEx Query Designer definiert und erst beim Ausführen der Query mit Werten gefüllt werden. REP Query Dies sind die eigentlichen Abfragen, mit denen die Endanwender arbeiten. QVW Query View Ein Query View enthält einen Ausschnitt oder einen Navigationszu- 12 Berechtigungen im Reporting Seite 73 von 128

80 stand einer Query oder eines externen InfoProviders. Zu einer Query können beliebig viele Views definiert werden. Endanwender benötigen den Wert REP in diesem Feld. Werden Views genutzt dann auch den Wert QVW. Besitzer (Owner) einer Reporting-Komponente (RSZOWNER) Legt fest, auf wessen Queries ein Benutzer zugreifen darf. S_RS_COMP1 benötigt im Gegensatz zu S_RS_COMP keine Angaben zu InfoArea und InfoProvider, da diese bereits über das Objekt S_RS_COMP definiert wurden. S_RS_COMP und S_RS_COMP1 müssen beide vergeben werden. Wichtig! Es müssen immer für beide Objekte S_RS_COMP und S_RS_COMP1 Berechtigungen vergeben werden! Warum SAP nicht gleich ein Berechtigungsobjekt definiert hat, in dem alle Felder enthalten sind, hat historische Gründe und wird im SAP-Hinweis näher erläutert. Die nachfolgende Berechtigung legt fest, dass alle Queries und Views des Benutzers BMEYER ausgeführt werden dürfen Ablauf der BW-Reporting Berechtigungsprüfung In der nachfolgenden Darstellung ist der Ablauf einer BW-Reporting- Berechtigungsprüfung schematisch dargestellt. 12 Berechtigungen im Reporting Seite 74 von 128

81 Anfrage Benutzer Ergebnis Standardberechtigungen (S_RS_COMP + S_RS_COMP1) Analyseberechtigungen direkt oder über S_RS_AUTH zugeordnet Analytical Engine Datenbeschaffung (Cache, BWAccelerator, HANA, DB etc.) Der Benutzer stellt im BW-System eine Anfrage. Bevor diese von der Analytic- Engine bearbeitet wird, wird geprüft, ob der Benutzer berechtigt ist bestimmte Queries aufzurufen (Abgleich der Berechtigungsobjekte S_RS_COMP und S_RS_COMP1) und auf welche Dateninhalte (S_RS_AUTH) er zugreifen kann Ebenen der Berechtigungssteuerung Folgende Ebenen der Berechtigungssteuerung werden in SAP-BW eingesetzt. Systemberechtigungen Funktionale Berechtigungen Analyseberechtigungen Menüberechtigungen Diese sorgen dafür, dass ein Benutzer mit dem BW-System kommunizieren und grundsätzlich auf ihm arbeiten kann. Versorgen den Benutzer mit den Anwendungsfunktionen, die er für seinen spezifischen Aufgabenbereich benötigt. Diese steuern, welche Daten einem Benutzer für seine Berichtsaufgaben zur Verfügung stehen. Ermöglichen ein aufbereitetes Angebot der Es gibt vier Ebenen der Berechtigungssteuerung in SAP-BW 12 Berechtigungen im Reporting Seite 75 von 128

82 verfügbaren Berichtsthemen in strukturierten Bäumen. Im Folgenden werden der Aufbau und die Prüfung von vergebenen Analyseberechtigungen näher erläutert Analyseberechtigungen Alle Benutzer, die sich Daten von berechtigungsrelevanten Merkmalen in einer Query anzeigen lassen möchten, benötigen Analyseberechtigungen Aufbau der Analyseberechtigungen Verwaltet werden die Analyseberechtigungen über die Transaktion RSECAD- MIN. In der Einstiegsmaske der Transaktion RSECADMIN kann über das Register Berechtigungen, Schaltfläche Pflege zur Anzeige der Analyseberechtigungen gesprungen werden (Transaktion RSECAUTH). 12 Berechtigungen im Reporting Seite 76 von 128

83 1. Schritt 2. Schritt Eine Analyseberechtigung enthält InfoObjects, denen Werte zugeordnet werden können. Die InfoObjects zur Berechtigung werden hier angezeigt. Durch einen Doppelklick auf ein InfoObject werden die definierten Werte angezeigt. 12 Berechtigungen im Reporting Seite 77 von 128

84 Doppelklick auf Eintrag Analyseberechtigungen bestehen aus 1 bis n InfoObjects (Merkmalen / Dimensionen), denen konkrete Werte zugeordnet werden können. In nachfolgender Abbildung ist die Berechtigung ZCUST_1000 dargestellt. Sie enthält das InfoObject 0CUSTOMER sowie die Spezialmerkmale 0TCAACTVT und 0TCAIPROV. 12 Berechtigungen im Reporting Seite 78 von 128

85 Wird einem Benutzer diese Berechtigung zugeordnet, so zieht sie automatisch in den InfoProvidern, in denen das InfoObject 0CUSTOMER verwendet wird. 12 Berechtigungen im Reporting Seite 79 von 128

86 Zu den einzelnen InfoObjects müssen jeweils Werte hinterlegt werden, die berechtigt werden sollen. Zur obigen Berechtigung wurden zu den drei InfoObjects folgende Werte hinterlegt: Bedeutet, dass nur auf Debitoren mit den Kundennummern zugegriffen werden kann. Bedeutet, dass die Daten gelesen (Aktivität 03) und Abfragen ausgeführt (Aktivität 16) werden können. Bedeutet, dass auf die Daten aller InfoProvider zugegriffen werden kann, die im Intervall 0 Z* liegen. Wird einem Benutzer diese Berechtigung zugeordnet, so erhält er Zugriff auf die Kunden mit den Kundennummern aus den InfoProvidern 0 Z*. In einer Berechtigung können immer mehrere Angaben zu einem Wert hinterlegt werden: Feld Including/Excluding Wert "I" (inklusiv): der angegebene Einzelwert oder Bereich wird selektiert 12 Berechtigungen im Reporting Seite 80 von 128

87 Wert "E" (exklusiv): der angegebene Einzelwert oder Bereich wird von der Selektion ausgeschlossen. Voreinstellung ist "I". Feld Operator (häufigste Operatoren) Wert EQ (Equal): Angabe eines Einzelwertes Wert BT (Between): Angabe eines Intervalls Wert CP (Contains Pattern): Maskierte Eingabe: Suche nach Mustern Feld Technischer Merkmalswert (von) In diesem Feld wird der Einzelwert (bei EQ und CP) bzw. der von-wert (bei BT) eingegeben. Feld Technischer Merkmalswert (bis) In diesem Feld wird der bis-wert (bei BT) angegeben. Auch in den Analyseberechtigungen können Hierarchieberechtigungen verwendet werden. Sie werden in den Analyseberechtigungen direkt ins Register Hierarchieberechtigungen eingetragen: 12 Berechtigungen im Reporting Seite 81 von 128

88 Spezialmerkmale für die Analyseberechtigungen Zusätzlich zu den betriebswirtschaftlichen Berechtigungen auf InfoObject- Ebene existieren sog. Spezialmerkmale (0TCA*). Diese müssen zwingend mit berechtigt werden, da ansonsten keine Queries ausgeführt werden können. Dies sind: Aktivität (0TCAACTVT) InfoProvider (0TCAIPROV) Gültigkeit (0TCAVALID) Zur Anzeige dieser Merkmale wird die Transaktion RSA1 genutzt, Ordner InfoObjects: 12 Berechtigungen im Reporting Seite 82 von 128

89 Grundvoraussetzung für den Einsatz der Analyseberechtigungen ist, dass diese Merkmale als Berechtigungsrelevant markiert sind. In einer Analyseberechtigung sind diese Spezialmerkmale daher immer enthalten. Eine typische Berechtigung auf Kostenstellen (InfoObject 0COSTCENTER) hätte somit folgende Ausprägung: Merkmal Aktivität (0TCAACTVT) Mit dem Merkmal Aktivität (0TCAACTVT) kann die Berechtigung auf verschiedene Aktivitäten eingegrenzt werden. Als rein lesender Anwender wird die Aktivität 03 (Lesen) benötigt. Für die integrierte Planung muss zusätzlich die Aktivität 02 (Ändern) vergeben werden 12 Berechtigungen im Reporting Seite 83 von 128

90 Merkmal InfoProvider (0TCAIPROV) Mit dem Merkmal InfoProvider (0TCAIPROV) kann die Berechtigung auf einzelne InfoProvider eingeschränkt werden. Das Merkmal bildet mit seinen Stammdaten und dem Hierarchiemerkmal für InfoArea die Struktur der InfoProvider-Ablage in der Data Warehousing Workbench ab. So ist es möglich, auch Berechtigungen für ganze InfoAreas zu erteilen. In vielen Fällen ist dies nicht notwendig, da die Berechtigung für die InfoProvider über das Berechtigungsobjekt S_RS_COMP eingegrenzt wird und der Datenzugriff über die Analyseberechtigungen auf InfoObject-Ebene. Daher ist eine *-Ausprägung in einer Berechtigung zu diesem Merkmal nicht zwingend als kritisch anzusehen und bedeutet nicht automatisch, dass ein Zugriff auf alle InfoProvider möglich ist! Merkmal Gültigkeit (0TCAVALID) Mit dem Merkmal Gültigkeit (0TCAVALID) kann die Gültigkeit einer Berechtigung eingeschränkt werden. Dies bedeutet, sie kann vom Zeitraum her eingeschränkt werden. Eine *-Berechtigung bedeutet, dass uneingeschränkt die Daten aller Zeiträume angezeigt werden. Um einen Zeitraum einzuschränken macht es Sinn, die verschiedenen Operatoren und Muster zu nutzen. Für die Muster gilt: * Steht für beliebig viele Zeichen + Steht für genau ein Zeichen Um z.b. die Berechtigung auf genau ein Jahr einzuschränken (z.b. für die Jahresabschlussprüfer), müsste folgender Berechtigungsinhalt angegeben werden: Including/Excluding Operator von bis I BT BI_ALL enthält alle berechtigungsrelevanten InfoObjects Die Berechtigung 0BI_ALL Die Analyseberechtigung 0BI_ALL ist eine Standardberechtigung im SAP BW. Sie wird nicht manuell gepflegt sondern automatisch generiert. Sie enthält alle berechtigungsrelevanten InfoObjects. 12 Berechtigungen im Reporting Seite 84 von 128

91 Wird ein InfoObject neu als berechtigungsrelevant markiert so wird automatisch auch 0BI_ALL neu generiert inkl. diesem InfoObject. Eine manuelle Pflege dieser Berechtigung ist nicht möglich, es wird die Fehlermeldung Berechtigung 0BI_ALL ist im SAP-Namensraum. Anlegen und Ändern nicht möglich ausgegeben. 0BI_ALL kann auch manuell mit dem Report RSEC_GENERATE_BI_ALL neu generiert werden. Da durch Vergabe dieser Berechtigung der Zugriff auf alle Daten möglich ist (entsprechende Berechtigungen auf die InfoProvider und Queries vorausgesetzt), ist die Vergabe als kritisch anzusehen. Sie darf nur Personen zugeordnet werden, die von ihrem Aufgabengebiet her zur Anzeige / Auswertung aller Daten berechtigt sind. Die Vergabe von 0BI_ALL ist als kritisch anzusehen 12 Berechtigungen im Reporting Seite 85 von 128

92 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 22 Berechtigungssystematik 2 Wem ist die Analyseberechtigung 0BI_ALL zugewiesen und kann auf alle berechtigungsrelevanten InfoObjects zugreifen? Diese kritische Berechtigung darf nur Personen zu-geordnet werden, die von ihrem Aufgabengebiet her zur Anzeige/Auswertung aller Daten berechtigt sind. Um zu ermitteln, wem diese Analyseberechtigung zugeordnet ist, sind zwei Prüfungen erforderlich. Die Ergebnisse sind additiv zu betrachten. 1. Auswertung über das Benutzerinfosystem Fragen Sie den Wert 0BI_ALL zum Berechtigungsobjekt S_RS_AUTH ab: 2. Auswertung der manuellen Zuordnung Lassen Sie sich mit SE16 die Tabelle RSECUSERAUTH anzeigen und geben Sie die nachfolgende Selektion ein. Es werden alle Benutzer angezeigt, denen diese Berechtigung manuell zugeordnet wurde Vorgehensweise bei der Prüfung von Reporting-Berechtigungen Die Prüfung der Reporting-Berechtigungen erfolgt in mehreren Schritten. Da für InfoProvider und Analyseberechtigungen keine Auswertungsreports exis- 12 Berechtigungen im Reporting Seite 86 von 128

93 tieren, müssen die Tabellen, in denen die Informationen gespeichert werden, für die Prüfung genutzt werden. Nachfolgend sind die einzelnen Prüfungsschritte aufgeführt. Für die Abfragen wurde der QuickViewer genutzt. Alternativ können die Tabellen auch exportiert und z.b. mit MS Access ausgewertet werden Prüfungsrelevante InfoObjects Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 23 Berechtigungsrelevante InfoObjects 2 Welche InfoObjects sind berechtigungsrelevant? Die InfoObjects, in denen besonders schutzwürdige Unternehmens- oder Personendaten gespeichert sind, wurden als berechtigungsrelevant gekennzeichnet. In diesem Schritt ist zu bewerten, ob die als berechtigungsrelevant markierten InfoObjects dem erforderlichen Schutz der Daten entsprechen. Berechtigungsrelevant können Merkmale, Navigationsattribute und Zeitmerkmale sein. Da die Eigenschaften dieser InfoObjects jeweils in verschiedenen Tabellen gespeichert werden, sind folgende drei Tabellen für die Prüfung heranzuziehen: RSDVCHA RSDATRNAV RSDVTIM Merkmalskatalog Navigationsattribute Zeitmerkmale Zu prüfen ist jeweils das Feld Berechtigungsrelevant (AUTHRELFL). Enthält dieses den Wert X in der aktiven Version so ist das InfoObject berechtigungsrelevant. Durch eine Verknüpfung mit der Tabelle RSDIOBJT (Texte zu InfoObjects) können die berechtigungsrelevanten InfoObjects transparent dargestellt werden: 12 Berechtigungen im Reporting Seite 87 von 128

94 Prüfungsrelevante InfoProvider Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 24 Berechtigungsrelevante InfoObjects 2 Welche InfoProvider sind prüfungsrelevant? InfoProvider stellen die auszuwertenden Daten zur Verfügung, daher stellt die Grundlage jeder Prüfung von Reporting-Berechtigungen das Wissen um die zu prüfenden Daten dar. Ermittlung in welchen InfoProvidern prüfungsrelevante Daten abgespeichert sind InfoProvider stellen die auszuwertenden Daten zur Verfügung, daher stellt die Grundlage jeder Prüfung von Reporting-Berechtigungen das Wissen um die zu prüfenden Daten dar. Hierfür ist zu ermitteln, welche Daten in welchen InfoProvidern gespeichert werden, welche also prüfungsrelevant sind. Dieser Schritt ist für jeden InfoProvider-Typ einzeln durchzuführen, da die Informationen jeweils in verschiedenen Tabellen abgelegt sind. Folgende Tabellen werden benötigt: InfoProvider InfoCubes RemoteCubes VirtuelleCubes MultiProvider HybridProvider Erforderliche Tabellen RSDCUBE Auflistung der InfoCubes Feld CUBETYPE gibt an, um welchen Typ es sich handelt: A B H R M P V RSDCUBET AggregateCube Standard-InfoCube HybridProvider Remote-InfoCube MultiProvider Append virtueller InfoProvider 12 Berechtigungen im Reporting Seite 88 von 128

95 ODS-Objekte MultiCubes InfoSets Semantisch partitionierte Objekte InfoObjects Die zu den InfoCubes und MultiCubes gehörenden Texte RSDCUBEIOBJ InfoObjects in Cube's RSDIOBJT Texte zu den InfoObjects RSDODSO Auflistung aller ODS-Objekte RSDODSOT Zu den ODS-Objekten gehörenden Texte RSDODSOIOBJ InfoObjects in ODS-Objekten RSDIOBJT Texte zu den InfoObjects RSDCUBEMULTI An Multiprovider beteiligte InfoProvider RSQISET Auflistung aller InfoSet s RSQISETT Texte zu den InfoSet s RSQTOBJ Tabellenobjekte in InfoSet s RSDODSOT Zu den ODS-Objekten gehörenden Texte RSLPO Verzeichnis der semantisch partitionierten Objekte (inkl. Name des beliefernden InfoProviders) RSLPOT Texte zu semantisch partitionierten Objekte RSDIOBJ Auflistung aller InfoObjects RSDIOBJT Texte zu den InfoObjects CompositeProvider RSDDCOPR Verzeichnis der CompositeProvider Transiente Provider RSDDCOPRXREF Analytische Indizes in Composite Providern RSDDCOPRT Texte zu Composite Providern RSLTIP Verzeichnis transienter Provider RSLTIPXREF 12 Berechtigungen im Reporting Seite 89 von 128

96 Objekte in transienten Providern RSLTIPT Texte zu transienten Providern Nachfolgende Abbildung zeigt exemplarisch die QuickView-Abfrage zur Ermittlung der InfoObjects in den InfoCubes. Für die anderen InfoProvider-Typen ist entsprechend vorzugehen. Als Listen- und Selektionsfelder empfiehlt sich folgende Kombination: 12 Berechtigungen im Reporting Seite 90 von 128

97 Als Ergebnis werden alle InfoCubes mit allen InfoObjects inkl. Bezeichnungen angezeigt: 12 Berechtigungen im Reporting Seite 91 von 128

98 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 25 Kritische Queries 2 Existieren im BW-System Queries mit sensiblen Informationen? Es kann für die Prüfung relevant sein, die sensiblen Queries zu den InfoProvidern im Vorweg einer Berechtigungsprüfung zu ermitteln. Ermittlung Queries mit Zugriff auf sensiblen Daten Häufig werden Queries nach der Namenskonvention so definiert, dass Queries mit sensiblen Daten (z.b. Einzelpostenanzeige für Kostenstellen) anhand des Namensraumes ermittelt werden können. Daher kann es für die Prüfung relevant sein, die sensiblen Queries zu den InfoProvidern im Vorwege zu ermitteln. Dazu werden die folgenden Tabellen miteinander verknüpft: RSZCOMPDIR RSZCOMPIC RSZELTTXT Liste der Queries Zuordnung von Queries zu InfoProvidern Texte der Queries In einer QuickView werden die Tabellen folgendermaßen verknüpft: Geben Sie im Feld Name (ID) die Namenskonvention für Queries mit sensiblen Daten ein Zu den InfoProvidern werden die Queries angezeigt: 12 Berechtigungen im Reporting Seite 92 von 128

99 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 26 Zugriffsberechtigung auf ausgewählte InfoProvider 2 Wer hat Zugriffsberechtigungen auf ausgewählte InfoProvider? Die Berechtigungsvergabe sollte mit den Organisationsstrukturen des Unternehmens und den Sollvorgaben übereinstimmen. Die Prüfung der Berechtigungen auf InfoProvider kann auf zwei Wegen erfolgen: Über das Benutzerinfosystem Über die Tabellen mit den Berechtigungsinformationen Berechtigung auf InfoProvider Prüfung der Berechtigungen auf InfoProvider über das Benutzerinfosystem Je nach Prüfungsfragestellung können die nachfolgenden Abfragen in zwei Reports abgebildet werden: RSUSR002 RSUSR070 Welche Benutzer verfügen über die Berechtigung? In welchen Rollen ist die Berechtigung enthalten? Die InfoProvider werden mit dem Berechtigungsobjekt S_RS_COMP berechtigt. Die Werte für die Felder Aktivität und Typ einer Reporting- Komponente sind bei Abfragen auf Reporting-Berechtigungen immer gleich. Im Feld InfoCube werden die InfoProvider abgefragt (alle Typen, nicht nur die InfoCubes) 12 Berechtigungen im Reporting Seite 93 von 128

100 Auswertung der Reporting- Berechtigungen über Tabellen Prüfung der Berechtigungen auf InfoProvider über Tabellen Die Auswertung der Reporting-Berechtigungen kann auch über die Tabellen erfolgen, in denen die Rolleninformationen gespeichert werden. Folgende Tabellen sind erforderlich: AGR_1251 Berechtigungswerte in Rollen AGR_USERS Rollenzuordnungen zu Benutzern Die Tabellen werden über den Rollennamen verknüpft. Nachfolgend werden die Felder angezeigt, die für die Darstellung und Selektion genutzt werden sollten. 12 Berechtigungen im Reporting Seite 94 von 128

101 Bei der Selektion muss das Feld Kennzeichen, ob Objekt gelöscht ist auf Gleich Leer und das Feld Berechtigungsobjekt auf S_RS_COMP eingegrenzt werden. Das Ergebnis enthält die Auflistung aller Benutzer mit Berechtigungen auf S_RS_COMP. Hier kann je nach Fragestellung weiter eingegrenzt werden. 12 Berechtigungen im Reporting Seite 95 von 128

102 Auswertung der Analyseberechtigungen in vier Schritten Überblick verschaffen über die vorhandenen Analyseberechtigungen Prüfen, ob generierte Analyseberechtigungen zugeordnet wurden Prüfen, ob Analyseberechtigungen manuell zugeordnet wurden Prüfen der Analyseberechtigungen über S_RS_AUTH Analyseberechtigungen Um die Analyseberechtigungen auszuwerten sind mehrere Schritte durchzuführen: Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 27 Analyseberechtigungen k. A. Welche Analyseberechtigungen existieren im BW-System? Mit diesem Prüfschritt verschafft man sich einen Überblick über die vergebenen Analyseberechtigungen, um kritische Berechtigungen zu identifizieren und deren Zuordnung zu Benutzern zu analysieren. Zur Beantwortung diese Frage werden die Tabellen genutzt, in denen die Analyseberechtigungen gespeichert werden. Diese werden in folgenden Tabellen gespeichert: RSECVAL RSECHIE RSECTXT Analyseberechtigungen Werte Hierarchie-Berechtigungen Texte zu Analyseberechtigungen Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 28 Analyseberechtigungen k. A. Wurden generierte Analyseberechtigungen Benutzern zugeordnet? Der Einsatz von generierten Analyseberechtigungen für wichtige Organisationselemente (z.b. Kostenstelle, Buchungskreis) ist zu empfehlen, um einen automatisierten Abgleich der Berechtigungsvergabe zwischen ERP- und BW-System zu erreichen. Zuordnung generierter Analyseberechtigungen Berechtigungswerte für Analyseberechtigungen können auch in anderen Systemen erzeugt und dann ins BW übertragen werden. Klassische Anwendungsbereiche sind Kostenstellenberechtigungen und Berechtigungen aus dem HCM. Hiermit wird erreicht, dass Benutzer die gleichen Daten im BW-System wie in den Transaktionen der Anwendung sehen dürfen bzw. nicht sehen dürfen, auch wenn die Berechtigungskonzepte unterschiedlich sind. 12 Berechtigungen im Reporting Seite 96 von 128

103 Analyseberechtigungen können über ODS-Objekte generiert werden (Vorlagen: 0TCA_DS*). Die Benutzerzuordnungen dieser generierten Berechtigungen werden aus den ODS-Objekten in die Tabelle RSECAUTHGENERATD fortgeschrieben. Diese Tabelle ist für die Prüfung zu nutzen. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 29 Analyseberechtigungen k. A. Welche Analyseberechtigungen wurden Benutzern manuell zugeordnet? Grundsätzlich sollte die Vergabe der Analyseberechtigungen über Rollen und nicht über manuelle Zu-ordnungen erfolgen, um eine höhere Transparenz in der Berechtigungsvergabe zu erreichen. Zusätzlich zur Nutzung des Berechtigungsobjektes S_RS_AUTH besteht auch die Möglichkeit, Analyseberechtigungen manuell zu Benutzern zuzuordnen. Hierbei werden die Analyseberechtigungen nicht über das gängige Berechtigungskonzept (über Rollen) zugeordnet, sondern in einer gesonderten Berechtigungsverwaltung gespeichert. Zu den manuellen Benutzerzuordnungen ist zu prüfen, wem aktuell Berechtigungen zugeordnet sind. Diese sind in der Tabelle RSECUSERAUTH gespeichert. Hierbei ist zu beachten, dass die beiden Konzepte (Manuelle Zuordnung der Berechtigungen / Zuordnung über S_RS_AUTH) nicht vermischt werden sollten, da dies sehr zu Lasten der Transparenz geht. Auch ist zu bedenken, dass bei Berechtigungsauswertungen (z.b. mit RSUSR002 / RSUSR070) die manuell zugeordneten Analyseberechtigungen nicht mit beachtet werden. Grundsätzlich sollte das Prinzip der herkömmlichen Berechtigungsvergabe über S_RS_AUTH dem der manuellen Pflege vorgezogen werden. Durch die Nutzung von Rollen ergibt sich eine sehr viel höhere Flexibilität hinsichtlich der Zuordnung der Berechtigungen. Insbesondere bei größeren Benutzerzahlen ergibt sich hinsichtlich der Verwaltung und der aufwändigen Auswertung ein sehr hoher Aufwand. Manuelle Zuordnung von Analyseberechtigungen 12 Berechtigungen im Reporting Seite 97 von 128

104 Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 30 Analyseberechtigungen k. A. Welchen Benutzern sind Analyseberechtigungen über Rollen zugeordnet. Grundsätzlich sollte die Vergabe der Analyseberechtigungen über Rollen und nicht über manuelle Zuordnungen erfolgen, um eine höhere Transparenz in der Berechtigungsvergabe zu erreichen. Die Rollenvergabe sollte den Sollvorgaben des Berechtigungskonzeptes entsprechen. Zuordnung von Analyseberechtigungen über Rollen Die Auswertung der Analyseberechtigungen kann auch über die Tabellen erfolgen, in denen die Rolleninformationen gespeichert werden. Folgende Tabellen sind erforderlich: AGR_1251 AGR_USERS Berechtigungswerte in Rollen Rollenzuordnungen zu Benutzern Die Tabellen werden über den Rollennamen verknüpft. Nachfolgend werden die Felder angezeigt, die für die Darstellung und Selektion genutzt werden sollten. 12 Berechtigungen im Reporting Seite 98 von 128

105 Bei der Selektion muss das Feld Kennzeichen, ob Objekt gelöscht ist auf Gleich Leer und das Feld Berechtigungsobjekt auf S_RS_AUTH eingegrenzt werden. Das Ergebnis enthält die Auflistung aller Benutzer mit Berechtigungen auf S_RS_AUTH. Hier kann je nach Fragestellung weiter eingegrenzt werden. Ps- Nr. Thema Risiko Prüfschritt Vorgabe oder Erläuterung 31 Analyseberechtigungen k. A. Welchen Benutzern sind unternehmenskritische Analyseberechtigungen zugeordnet? Die Zuordnung sollte den Sollvorgaben des Berechtigungskonzeptes entsprechen.. 12 Berechtigungen im Reporting Seite 99 von 128

106 Prüfen von Zuordnungen ausgewählter Analyseberechtigungen Im Rahmen der Prüfung kann es erforderlich sein, explizit einzelne Zuordnungen von Analyseberechtigungen zu ermitteln. Hierfür wird das Benutzerinfosystem genutzt: RSUSR002: Welche Benutzer verfügen über die Berechtigung? RSUSR070: In welchen Rollen ist die Berechtigung enthalten? Die Analyseberechtigungen werden mit dem Berechtigungsobjekt S_RS_AUTH berechtigt. Im einzigen Feld des Objektes wird die gesuchte Analyseberechtigung eingetragen: 12 Berechtigungen im Reporting Seite 100 von 128