Warum ein SAP Spool-Konzept so wichtig ist
Im SAP-System basieren Drucklisten auf sogenannten Spool-Aufträgen (kurz: Spools). Spools an sich sind dabei nicht von Grund auf kritisch zu sehen. Wenn diese aber sensible Daten mit entsprechendem Schutzbedarf enthalten, so muss sichergestellt werden, dass nur autorisierte Benutzer auch Zugriff auf jene Informationen erhalten. Die Kritikalität liegt demnach im benutzerübergreifenden Zugriff auf fremde Spools. Hieraus entsteht auch die Wichtigkeit eines Spool-Konzepts. Da es in der Praxis aber nicht immer möglich ist, dass Benutzer nur Zugriff auf ihre eigenen Spool-Aufträge erhalten, wird in diesem Blogbeitrag betrachtet, warum dann ein Spool-Konzept wichtig ist und wie mögliche Lösungsansätze aussehen können.
Table of Contents
Was ist ein SAP Spool-Auftrag?
In einem SAP-System wird ein Druckauftrag in einem sogenannten Spool-Auftrag, oder kurz Spool, gerätespezifisch aufbereitet und bis zur Reorganisation in der Datenablage für temporäre sequenzielle Daten (kurz: TemSe) vorgehalten. In der TemSe werden Objekte gespeichert, welche in der Regel nicht dauerhaft im System gehalten werden. Dies ermöglicht unter anderem eine Druckvorschau ohne, dass eine erneute Aufbereitung der Daten notwendig ist.
Die Notwendigkeit eines SAP-Spool-Konzepts
In einem SAP-System werden alle Datenzugriffe über ein Berechtigungskonzept geregelt. Hierbei werden SAP-Benutzern entsprechende Berechtigungsrollen zugewiesen, welche idealerweise nach Best Practice erstellt wurden. Die eigentlichen Berechtigungen sind dort in Form von Berechtigungsobjekten – mit konkreten Wertausprägungen für die zugehörigen Berechtigungsfelder – erfasst. So ist es möglich Datenzugriffe in SAP restriktiv zu vergeben.
Dies gilt es auch für Spool-Zugriffe zu berücksichtigen, da diese unter Umständen Daten mit hohem Schutzbedarf enthalten. Ein Beispiel dafür, wäre ein Mitarbeiter der Finanzbuchhaltung, welcher Zugriff auf sensible Bilanzdaten hat und einen Spool erzeugt. Mitarbeiter aus anderen Bereichen, welche prinzipiell zwar keine Berechtigung für die Einsicht haben, könnten bei fehlendem Zugriffsschutz auf Spools, dennoch indirekt Daten einsehen, welche nicht für Sie bestimmt sind.
Daher ist es zunächst einmal grundsätzlich empfehlenswert, wenn jeder Benutzer nur seine eigenen Spools sehen kann und höchstens eine begrenzte Anzahl an Keyusern einen benutzerübergreifenden Zugriff besitzt. Organisationsbedingt besteht allerdings oftmals die Notwendigkeit, dass Benutzer auch auf Spools anderer zugreifen müssen. Dies kann bspw. auch im Zuge der Hintergrundverarbeitung – über die Transaktion SM37 – notwendig sein. Ausgaben werden hier als Spools aufbereitet und können daher den Zugriff auf fremde Spools erforderlich machen. Folglich gilt es in diesem Fall den benutzerübergreifenden Spool-Zugriff konzeptionell zu erfassen und anschließend technisch umzusetzen.
Berechtigungsprüfungen bei Spool-Zugriffen
Für die Spool-Zugriffssteuerung sind vor allem zwei Berechtigungsobjekte näher zu betrachten. Das erste Berechtigungsobjekt ist S_ADMI_FCD. Dieses regelt den Zugriff auf fremde Spools über die Wertausprägung SP01 oder SP0R. Ergänzend hierzu wird über das zweite Berechtigungsobjekt S_SPO_ACT geregelt, auf wessen Spools in welcher Form zugegriffen werden kann. Dabei regelt das zugehörige Feld SPOACTION die Zugriffsart. Bei der Berechtigungsprüfung des Objekts S_SPO_ACT wird zudem unterschieden, ob Spools mit einer dedizierten Berechtigung geschützt sind.
Ungeschützt sind dabei prinzipiell alle Spools, die nicht explizit mit einer Berechtigung geschützt wurden. In diesem Fall erfolgt eine Verprobung des zugehörigen Berechtigungsfeldes SPOAUTH nur, wenn der Zugriff nicht vom Eigentümer des Spools selbst ausgeführt wird. Das Berechtigungsfeld wird dann auf den Benutzernamen des Spool-Eigentümers verprobt. Ein pauschaler Zugriff für alle ungeschützten Spools kann mit der Ausprägung __USER__ für das Berechtigungsfeld SPOAUTH erteilt werden.
Im Gegensatz dazu, erfolgt bei einem explizit geschützten Spool die Überprüfung des Berechtigungsfeldes SPOAUTH immer, auch beim Eigentümer des Spools selbst. Das Berechtigungsfeld wird dabei mit dem definierten Wert für die Berechtigung des Spools, einem sogenannten “Identifier”, verprobt. Wichtige Wertausprägungen für diese Berechtigungsobjekte zur Erstellung eines benutzerübergreifenden Spool-Konzepts sind in der folgenden Übersicht festgehalten.
Das Schützen von Spools
Die Spools eines Benutzers können über den Benutzerparameter SAU und einen beliebigen Wert geschützt werden. Dabei sollte aber beachtet werden, dass dies nur in der Dialogverarbeitung zuverlässig funktioniert, da der Parameter beispielsweise programmspezifisch übersteuert werden kann oder bei Nutzung von bestimmten Funktionsbausteinen auch ignoriert wird. Daher sollte die Verwendung und Vorgabe der Spool-Berechtigungen ausschließlich über die benutzerspezifischen Druckvorgaben erfolgen. Der vordefinierte Wert der Spool-Berechtigung kann über den SAP Standard Report RSTRANSPARAMSAU in die benutzerspezifischen Druckvorgaben transferiert werden. Pro Benutzer ist der Parameter nur einmal definiert, und exklusiv vorbelegt, allerdings kann dieser nachträglich angepasst werden und somit auch den Schutz von Spools aktiv beeinflussen. Bei Bedarf kann der Report auch als periodischer Hintergrundjob eingeplant werden, um die Vorgaben regelmäßig erneut zu übertragen.
Lösungsoptionen für ein Spool-Konzept
Umfassende Zugriffe auf fremde Spools sollten also in jedem Fall ausschließlich über dedizierte Spool-Rollen bereitgestellt werden, um einen entsprechenden Schutz sicherstellen zu können. Wie das in der Praxis aussehen kann, wird im Folgenden anhand zwei möglicher Lösungsoptionen dargestellt.
Spool-Zugriffe durch Benutzergruppierung
Da ungeschützte Spools wie oben beschrieben immer den Benutzernamen des Spool-Eigentümers verproben, wäre eine Zugriffssteuerung durch Benutzergruppierungen möglich. Hierfür ist eine Definition der entsprechenden Gruppierungen in den Fachbereichen notwendig, welche die Grundlage für eine Bereitstellung der notwendigen Rollen darstellt. Für jede Gruppierung wird dabei eine Benennung als “Identifier” festgelegt werden, welcher im Rollennamen zur Differenzierung verwendet wird. Für eine effiziente Pflege des Berechtigungsfeldes SPOAUTH, empfiehlt es sich dieses als Organisationsebene hochzustufen. Da das Feld nur im zugehörigen Objekt S_SPO_ACT verwendet wird und lediglich den Zugriff auf fremde Spools regelt, sind negative Seiteneffekte ausgeschlossen. Weiter gilt für jedes Zugriffsszenario bzw. jede Benutzergruppe, die identifiziert und definiert wurde, eine entsprechende Rolle zu erstellen.
Für eine bessere Kontrolle bietet sich an jedes Zugriffsszenario auch als Orgset im Modul Role Replicator der Xiting Authorizations Management Suite, kurz XAMS, zu definieren, um eine zentrale Stammdatenverwaltung und Dokumentation der definierten Benutzergruppierung im Spool-Umfeld innerhalb des Systems zu etablieren. Dies hat den Vorteil, dass die Datenbasis so stets aktuell gehalten wird und die Verwaltung der definierten Szenarien direkt im System erfolgen kann.
Bei dieser Lösungsoption ist eine saubere Definition der Benutzergruppierung maßgeblich. Weiter muss diese aufgrund von Eintritt-, Austritt- und Übertrittszenarien stetig überprüft und aktualisiert werden. Dies kann zur Folge haben, dass regelmäßige Rollenanpassungen notwendig sind, da diese benutzerspezifische Informationen beinhalten. Eine Hilfestellung zur Verwaltung und Dokumentation kann dabei die XAMS bieten.
Spool-Zugriffe nach Hierarchiestufe
Für die zweite Lösungsoption wird ebenfalls die Verprobung des Feldes SPOAUTH im Berechtigungsobjekt S_SPOACT genutzt. Die Zugriffsszenarien werden dabei nach Hierarchiestufe definiert. Für diese Gruppierungen kann die Aufbauorganisation oder das bestehende Rollenkonzept eine Hilfestellung bieten. Im Anschluss gilt es wieder für alle Szenarien dedizierte Rollen bereitzustellen. Hierfür muss anhand einer Namenskonvention ein “Identifier” festgelegt werden, welcher auch im Rollennamen zur Differenzierung und Wertausprägung im Feld SPOAUTH verwendet wird. Analog zur Länge der Benutzernamen im SAP, kann dieser eine maximale Länge von 12 Zeichen enthalten. Wie oben beschrieben, kann jedem Benutzer allerdings nur eine Spool-Berechtigung zugewiesen werden. Aus diesem Grund müssen hierarchische Zugriffe ebenfalls über die Namenskonvention berücksichtigt werden. So soll beispielsweise ein Manager alle Spools seiner Sachbearbeiter einsehen können, aber nicht umgekehrt.
Die definierten Spool-Berechtigungen werden den Usern dann im Benutzerparameter SAU hinterlegt. Die Pflege des Parameters kann in einem Excel für die Benutzer vordefiniert werden und über das XAMS-Modul Role Replicator einfach importiert werden. Wie oben beschrieben müssen die Vorgaben dann abschließend in die benutzerspezifischen Druckvorgaben überführt werden, sodass das Attribut unabhängig von der Ausführungsart gesetzt wird.
Weiter gilt es nun für jede Benutzergruppe in der Transaktion PFCG noch eine entsprechende Rolle zu erstellen, welche im Rollenmenü die Transaktion SP01 enthält und die benötigten Berechtigungsobjekte als Vorschlagswerte über die SU24 bereitstellt. Welche Vorteile eine nachhaltige SU24-Optimierung generell liefern kann, kann in diesem Blogbeitrag nochmal nachgelesen werden.
Für diese Lösungsoption ist eine saubere Definition des Benutzerparameters SAU und der anschließende Transfer in die benutzerspezifischen Druckvorgaben maßgeblich. Da pro Benutzer immer nur ein Wert über den Benutzerparameter vorbelegt werden kann, ist zu beachten, dass es schwierig ist komplexe Spool-Zugriffsszenarien darüber zu realisieren.
Fazit
Im Idealfall sollte jeder Benutzer im SAP-System nur Zugriff auf seine eigenen Spools erhalten. Da dies allerdings nicht immer möglich ist, müssen Zugriffe auf benutzerübergreifende Spools konzeptionell geregelt werden, um unerlaubten Zugriff auf sensible Daten zu schützen. Die Konzeption und Umsetzung eines solchen Spool-Konzepts ist sehr anspruchsvoll, da es technische Einschränkungen mit hierarchischen Strukturen zu vereinen gilt. Als Lösungsoption wurden zwei mögliche Beispiele für die Umsetzung präsentiert. Für den Erfolg eines Konzepts ist dabei in jedem Fall eine saubere Definition der jeweiligen Zugriffs-Szenarien absolut maßgeblich. Unter Umständen sind jedoch stetige Aktualisierungen und Überprüfungen notwendig, dabei kann unser XAMS-Modul Role Replicator die Dokumentation sowie die Verwaltung unterstützen und erleichtern.
Der Role Replicator ist nur eines von sieben umfangreichen Modulen der Xiting Authorizations Management Suite (XAMS) und bietet noch viele weitere Funktionalitäten. Wenn Sie mehr dazu erfahren möchten, nehmen Sie gerne an unseren Webinaren teil oder kontaktieren Sie uns für weitere Informationen zu unseren umfassenden Services im Bereich SAP Security.
- Auditkonformes Berechtigungskonzept – Einfach und Effizient mit XAMS - 8. Mai 2023
- Warum ein SAP Spool-Konzept so wichtig ist - 4. Februar 2021
- Produktive Testsimulation –Das neue Testing - 30. April 2020
