Im SAP-System basieren Drucklisten auf sogenannten Spool-Auftr\u00e4gen (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\u00e4t liegt demnach im benutzer\u00fcbergreifenden Zugriff auf fremde Spools. Hieraus entsteht auch die Wichtigkeit eines Spool-Konzepts. Da es in der Praxis aber nicht immer m\u00f6glich ist, dass Benutzer nur Zugriff auf ihre eigenen Spool-Auftr\u00e4ge erhalten, wird in diesem Blogbeitrag betrachtet, warum dann ein Spool-Konzept wichtig ist und wie m\u00f6gliche L\u00f6sungsans\u00e4tze aussehen k\u00f6nnen.<\/p>\n\n
Was ist ein SAP Spool-Auftrag?<\/h2>\n\n
In einem SAP-System wird ein Druckauftrag in einem sogenannten Spool-Auftrag, oder kurz Spool, ger\u00e4tespezifisch aufbereitet und bis zur Reorganisation in der Datenablage f\u00fcr tempor\u00e4re sequenzielle Daten (kurz: TemSe) vorgehalten. In der TemSe werden Objekte gespeichert, welche in der Regel nicht dauerhaft im System gehalten werden. Dies erm\u00f6glicht unter anderem eine Druckvorschau ohne, dass eine erneute Aufbereitung der Daten notwendig ist.<\/p>\n\n
![\"\"](\"https:\/\/www.xiting.de\/wp-content\/uploads\/2021\/02\/abbildung-1-sap-spool-auftrag-1024x872.png\")
\nDie Notwendigkeit eines SAP-Spool-Konzepts<\/h2>\n\n
In einem SAP-System werden alle Datenzugriffe \u00fcber ein Berechtigungskonzept geregelt. Hierbei werden SAP-Benutzern entsprechende Berechtigungsrollen zugewiesen, welche idealerweise nach Best Practice<\/a> erstellt wurden. Die eigentlichen Berechtigungen sind dort in Form von Berechtigungsobjekten \u2013 mit konkreten Wertauspr\u00e4gungen f\u00fcr die zugeh\u00f6rigen Berechtigungsfelder \u2013 erfasst.\u00a0 So ist es m\u00f6glich Datenzugriffe in SAP restriktiv zu vergeben.\u00a0<\/p>\n\n Dies gilt es auch f\u00fcr Spool-Zugriffe zu ber\u00fccksichtigen, da diese unter Umst\u00e4nden Daten mit hohem Schutzbedarf enthalten. Ein Beispiel daf\u00fcr, w\u00e4re ein Mitarbeiter der Finanzbuchhaltung, welcher Zugriff auf sensible Bilanzdaten hat und einen Spool erzeugt. Mitarbeiter aus anderen Bereichen, welche prinzipiell zwar keine Berechtigung f\u00fcr die Einsicht haben, k\u00f6nnten bei fehlendem Zugriffsschutz auf Spools, dennoch indirekt Daten einsehen, welche nicht f\u00fcr Sie bestimmt sind.\u00a0<\/p>\n\n Daher ist es zun\u00e4chst einmal grunds\u00e4tzlich empfehlenswert, wenn jeder Benutzer nur seine eigenen Spools sehen kann und h\u00f6chstens eine begrenzte Anzahl an Keyusern einen benutzer\u00fcbergreifenden Zugriff besitzt. Organisationsbedingt besteht allerdings oftmals die Notwendigkeit, dass Benutzer auch auf Spools anderer zugreifen m\u00fcssen. Dies kann bspw. auch im Zuge der Hintergrundverarbeitung \u2013 \u00fcber die Transaktion SM37 \u2013 notwendig sein. Ausgaben werden hier als Spools aufbereitet und k\u00f6nnen daher den Zugriff auf fremde Spools erforderlich machen. Folglich gilt es in diesem Fall den benutzer\u00fcbergreifenden Spool-Zugriff konzeptionell zu erfassen und anschlie\u00dfend technisch umzusetzen.\u00a0<\/p>\n\n F\u00fcr die Spool-Zugriffssteuerung sind vor allem zwei Berechtigungsobjekte n\u00e4her zu betrachten. Das erste Berechtigungsobjekt ist S_ADMI_FCD. Dieses regelt den Zugriff auf fremde Spools \u00fcber die Wertauspr\u00e4gung SP01 oder SP0R. Erg\u00e4nzend hierzu wird \u00fcber das zweite Berechtigungsobjekt S_SPO_ACT geregelt, auf wessen Spools in welcher Form zugegriffen werden kann. Dabei regelt das zugeh\u00f6rige Feld SPOACTION die Zugriffsart. Bei der Berechtigungspr\u00fcfung des Objekts S_SPO_ACT wird zudem unterschieden, ob Spools mit einer dedizierten Berechtigung gesch\u00fctzt sind.\u00a0<\/p>\n\n Ungesch\u00fctzt sind dabei prinzipiell alle Spools, die nicht explizit mit einer Berechtigung gesch\u00fctzt wurden. In diesem Fall erfolgt eine Verprobung des zugeh\u00f6rigen Berechtigungsfeldes SPOAUTH nur, wenn der Zugriff nicht vom Eigent\u00fcmer des Spools selbst ausgef\u00fchrt wird. Das Berechtigungsfeld wird dann auf den Benutzernamen des Spool-Eigent\u00fcmers verprobt. Ein pauschaler Zugriff f\u00fcr alle ungesch\u00fctzten Spools kann mit der Auspr\u00e4gung __USER__ f\u00fcr das Berechtigungsfeld SPOAUTH erteilt werden.\u00a0<\/p>\n\n Im Gegensatz dazu, erfolgt bei einem explizit gesch\u00fctzten Spool die \u00dcberpr\u00fcfung des Berechtigungsfeldes SPOAUTH immer, auch beim Eigent\u00fcmer des Spools selbst. Das Berechtigungsfeld wird dabei mit dem definierten Wert f\u00fcr die Berechtigung des Spools, einem sogenannten \u201cIdentifier\u201d, verprobt. Wichtige Wertauspr\u00e4gungen f\u00fcr diese Berechtigungsobjekte zur Erstellung eines benutzer\u00fcbergreifenden Spool-Konzepts sind in der folgenden \u00dcbersicht festgehalten.<\/p>\n\n Die Spools eines Benutzers k\u00f6nnen \u00fcber den Benutzerparameter SAU und einen beliebigen Wert gesch\u00fctzt werden. Dabei sollte aber beachtet werden, dass dies nur in der Dialogverarbeitung zuverl\u00e4ssig funktioniert, da der Parameter beispielsweise programmspezifisch \u00fcbersteuert werden kann oder bei Nutzung von bestimmten Funktionsbausteinen auch ignoriert wird. Daher sollte die Verwendung und Vorgabe der Spool-Berechtigungen ausschlie\u00dflich \u00fcber die benutzerspezifischen Druckvorgaben erfolgen. Der vordefinierte Wert der Spool-Berechtigung kann \u00fcber 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\u00e4glich 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\u00e4\u00dfig erneut zu \u00fcbertragen.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t Umfassende Zugriffe auf fremde Spools sollten also in jedem Fall ausschlie\u00dflich \u00fcber dedizierte Spool-Rollen bereitgestellt werden, um einen entsprechenden Schutz sicherstellen zu k\u00f6nnen. Wie das in der Praxis aussehen kann, wird im Folgenden anhand zwei m\u00f6glicher L\u00f6sungsoptionen dargestellt.\u00a0<\/p>\n\n Da ungesch\u00fctzte Spools wie oben beschrieben immer den Benutzernamen des Spool-Eigent\u00fcmers verproben, w\u00e4re eine Zugriffssteuerung durch Benutzergruppierungen m\u00f6glich. Hierf\u00fcr ist eine Definition der entsprechenden Gruppierungen in den Fachbereichen notwendig, welche die Grundlage f\u00fcr eine Bereitstellung der notwendigen Rollen darstellt. F\u00fcr jede Gruppierung wird dabei eine Benennung als \u201cIdentifier\u201d festgelegt werden, welcher im Rollennamen zur Differenzierung verwendet wird. F\u00fcr eine effiziente Pflege des Berechtigungsfeldes SPOAUTH, empfiehlt es sich dieses als Organisationsebene hochzustufen. Da das Feld nur im zugeh\u00f6rigen Objekt S_SPO_ACT verwendet wird und lediglich den Zugriff auf fremde Spools regelt, sind negative Seiteneffekte ausgeschlossen. Weiter gilt f\u00fcr jedes Zugriffsszenario bzw. jede Benutzergruppe, die identifiziert und definiert wurde, eine entsprechende Rolle zu erstellen.<\/p>\n\n F\u00fcr eine bessere Kontrolle bietet sich an jedes Zugriffsszenario auch als Orgset im Modul Role Replicator<\/a> der Xiting Authorizations Management Suite<\/a>, kurz XAMS<\/a>, 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.<\/p>\n\n Bei dieser L\u00f6sungsoption ist eine saubere Definition der Benutzergruppierung ma\u00dfgeblich. Weiter muss diese aufgrund von Eintritt-, Austritt- und \u00dcbertrittszenarien stetig \u00fcberpr\u00fcft und aktualisiert werden. Dies kann zur Folge haben, dass regelm\u00e4\u00dfige Rollenanpassungen notwendig sind, da diese benutzerspezifische Informationen beinhalten. Eine Hilfestellung zur Verwaltung und Dokumentation kann dabei die XAMS<\/a> bieten.<\/p>\n\n F\u00fcr die zweite L\u00f6sungsoption wird ebenfalls die Verprobung des Feldes SPOAUTH im Berechtigungsobjekt S_SPOACT genutzt. Die Zugriffsszenarien werden dabei nach Hierarchiestufe definiert. F\u00fcr diese Gruppierungen kann die Aufbauorganisation oder das bestehende Rollenkonzept eine Hilfestellung bieten. Im Anschluss gilt es wieder f\u00fcr alle Szenarien dedizierte Rollen bereitzustellen. Hierf\u00fcr muss anhand einer Namenskonvention ein \u201cIdentifier\u201d festgelegt werden, welcher auch im Rollennamen zur Differenzierung und Wertauspr\u00e4gung im Feld SPOAUTH verwendet wird. Analog zur L\u00e4nge der Benutzernamen im SAP, kann dieser eine maximale L\u00e4nge von 12 Zeichen enthalten. Wie oben beschrieben, kann jedem Benutzer allerdings nur eine Spool-Berechtigung zugewiesen werden. Aus diesem Grund m\u00fcssen hierarchische Zugriffe ebenfalls \u00fcber die Namenskonvention ber\u00fccksichtigt werden. So soll beispielsweise ein Manager alle Spools seiner Sachbearbeiter einsehen k\u00f6nnen, aber nicht umgekehrt.<\/p>\n\n Die definierten Spool-Berechtigungen werden den Usern dann im Benutzerparameter SAU hinterlegt. Die Pflege des Parameters kann in einem Excel f\u00fcr die Benutzer vordefiniert werden und \u00fcber das XAMS-Modul Role Replicator<\/a> einfach importiert werden. Wie oben beschrieben m\u00fcssen die Vorgaben dann abschlie\u00dfend in die benutzerspezifischen Druckvorgaben \u00fcberf\u00fchrt werden, sodass das Attribut unabh\u00e4ngig von der Ausf\u00fchrungsart gesetzt wird.<\/p>\n\n Weiter gilt es nun f\u00fcr jede Benutzergruppe in der Transaktion PFCG<\/a> noch eine entsprechende Rolle zu erstellen, welche im Rollenmen\u00fc die Transaktion SP01 enth\u00e4lt und die ben\u00f6tigten Berechtigungsobjekte als Vorschlagswerte \u00fcber die SU24 bereitstellt. Welche Vorteile eine nachhaltige SU24-Optimierung generell liefern kann, kann in diesem Blogbeitrag<\/a> nochmal nachgelesen werden.<\/p>\n\n F\u00fcr diese L\u00f6sungsoption ist eine saubere Definition des Benutzerparameters SAU und der anschlie\u00dfende Transfer in die benutzerspezifischen Druckvorgaben ma\u00dfgeblich. Da pro Benutzer immer nur ein Wert \u00fcber den Benutzerparameter vorbelegt werden kann, ist zu beachten, dass es schwierig ist komplexe Spool-Zugriffsszenarien dar\u00fcber zu realisieren.\u00a0<\/p>\n\n Im Idealfall sollte jeder Benutzer im SAP-System nur Zugriff auf seine eigenen Spools erhalten. Da dies allerdings nicht immer m\u00f6glich ist, m\u00fcssen Zugriffe auf benutzer\u00fcbergreifende Spools konzeptionell geregelt werden, um unerlaubten Zugriff auf sensible Daten zu sch\u00fctzen. Die Konzeption und Umsetzung eines solchen Spool-Konzepts ist sehr anspruchsvoll, da es technische Einschr\u00e4nkungen mit hierarchischen Strukturen zu vereinen gilt. Als L\u00f6sungsoption wurden zwei m\u00f6gliche Beispiele f\u00fcr die Umsetzung pr\u00e4sentiert. F\u00fcr den Erfolg eines Konzepts ist dabei in jedem Fall eine saubere Definition der jeweiligen Zugriffs-Szenarien absolut ma\u00dfgeblich. Unter Umst\u00e4nden sind jedoch stetige Aktualisierungen und \u00dcberpr\u00fcfungen notwendig, dabei kann unser XAMS-Modul Role Replicator<\/a> die Dokumentation sowie die Verwaltung unterst\u00fctzen und erleichtern.\u00a0<\/p>\n\n Der Role Replicator<\/a> ist nur eines von sieben umfangreichen Modulen der Xiting Authorizations Management Suite (XAMS)<\/a> und bietet noch viele weitere Funktionalit\u00e4ten. Wenn Sie mehr dazu erfahren m\u00f6chten, nehmen Sie gerne an unseren Webinaren<\/a> teil oder kontaktieren Sie uns f\u00fcr weitere Informationen zu unseren umfassenden Services<\/a> im Bereich SAP Security.<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":" SAP Beratung anfragen Im SAP-System basieren Drucklisten auf sogenannten Spool-Auftr\u00e4gen (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\u00e4t liegt demnach im benutzer\u00fcbergreifenden Zugriff auf […]<\/p>\n","protected":false},"author":27,"featured_media":13466,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[1826],"tags":[1395,1391,1392,1393,1394,1396],"class_list":["post-13449","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit","tag-sap-druckauftrag","tag-sap-spool","tag-sap-spool-konzept","tag-spool","tag-spool-auftrag","tag-spool-berechtigungen"],"acf":[],"yoast_head":"\nBerechtigungspr\u00fcfungen bei Spool-Zugriffen<\/h2>\n\n
![\"\"](\"https:\/\/www.xiting.de\/wp-content\/uploads\/2021\/02\/abbildung-2-berechtigungsobjekte-fuer-die-spool-zugriffssteuerung-1024x570.png\")
\nDas Sch\u00fctzen von Spools<\/h2>\n\n
L\u00f6sungsoptionen f\u00fcr ein Spool-Konzept<\/strong><\/h2>\n\n
Spool-Zugriffe durch Benutzergruppierung<\/strong><\/h3>\n\n
![\"\"](\"https:\/\/www.xiting.de\/wp-content\/uploads\/2021\/02\/abbildung-3-hochgestuftes-berechtigungsfeld-spoauth-mit-definiertem-identifier-fi_sachbearb-1024x302.png\")
\nSpool-Zugriffe nach Hierarchiestufe<\/strong><\/h3>\n\n
![\"\"](\"https:\/\/www.xiting.de\/wp-content\/uploads\/2021\/02\/abbildung-4-beispiel-fuer-eine-hierarchische-spool-zugriffssteuerung-1024x590.png\")
\nFazit<\/strong><\/h2>\n\n