Muss es schmerzhaft sein, SoD-Konflikte und SAP-Ansprüche neu zu ordnen?

Auf der Konferenz "SAP Security - Tipps für die Sicherheit" habe ich meine Erkenntnisse aus den Projekten zur Umstrukturierung von SoD und Berechtigungen sowie aus der täglichen Arbeit im Rahmen der Managed Services mit Ihnen geteilt. Für diejenigen unter Ihnen, die nicht an der Konferenz teilnehmen konnten, habe ich eine kurze Zusammenfassung vorbereitet.

Zu Beginn haben wir uns gefragt, was der Grund für die Entscheidung sein könnte, ein solches Projekt wie das Projekt zur Neuordnung von Ansprüchen in Angriff zu nehmen. Beispiele für Szenarien sind:

 

1. 1. Das Unternehmen hat Erfahrungen mit Datenverluste oder Betrug die sich aus zu weit gefassten Nutzerrechten ergeben.
      Wir haben durch Zufall von dem Vorfall erfahren. Von wie vielen Vorfällen haben wir nicht erfahren
   2. Im Produktionssystem ist ein Fehler aufgetreten - unbeabsichtigtes menschliches Versagen. Waren die Berechtigungen zu weit gefasst? Wissen wir, wie wir den Fehler reproduzieren können? Speichert das System Protokolle und wissen wir, wie wir sie lesen können?
   3. Unübersichtlichkeit der SAP-Rollen, Verlust des Gefühls der Kontrolle über die Rollen. Fügen Sie neue Berechtigungen zu Rollen hinzu, entfernen Sie keine Berechtigungen. Ergebnis: jeder hat Zugang zu (fast) allem.

1.  

1.  

SoD-Konzepte

Wir wurden auch an die grundlegenden SoD-Konzepte erinnert - vom Allgemeinen zum Besonderen:

Deadline	Definition
SoD-Matrix	eine Reihe von definierten und beschriebenen Kompetenzkonflikten in einem bestimmten Bereich (z.B. FI, TR, SD, HR, Basis)
SoD-Konflikt	kritische Kombination von mindestens zwei Geschäftsprozessen (z. B. Gehaltsabrechnung + Änderung des Bankkontos, Eröffnung von Buchungsperioden + Freigabe von Dokumenten zur Zahlung, Systemkonfiguration + Transportimport)
Risiken	Beschreibung des SoD-Konflikts aus betriebswirtschaftlicher Sicht und der möglichen Konsequenzen, die sich aus den übertragenen Befugnissen ergeben
Prozess	Geschäftsbetrieb (z. B. Eröffnung einer Buchungsperiode, Freigabe von Dokumenten zur Zahlung)
Berechtigungs-ID	definierte Transaktionen, Berichte, Tabellen, d.h. die Werte von SAP-Feldern, die von der Engine der im SAP-System definierten und konfigurierten Matrix überprüft werden. Alles, was wir als „kritisch” in den Berechtigungen der kontrollierten Benutzer erfassen wollen
Abhilfemaßnahmen	Kontrolle der Risiken, zu denen bestimmten Nutzern der Zugang entzogen/aufrechterhalten werden sollte; die Kontrollen können manuell, kompensatorisch oder automatisch nach dem „Vier-Augen-Prinzip” erfolgen”
SOD Aufgabentrennung	d.h. jeder Mitarbeiter führt nur seinen Teil des Prozesses aus und niemand ist berechtigt, über seine Aufgaben hinaus zu handeln!

PRU-Planung

Bei der Planung einer PRU sollten mindestens die folgenden fünf Phasen eingeplant werden:

 

1. 1. Analyse aktuelle SoD-Konflikte, Berechtigungsprobleme, Status von Rollen, Status von Verfahren
   2. Planung Aufgaben und Verantwortlichkeiten in der PRU, das neue Berechtigungskonzept
   3. Konfiguration neue Rollen, Feuerwehrmann
   4. Tests/Pilot
   5. Beginn der Produktion - Hyperpflege, Dokumentation hat ihre Besitzer, Abmilderungen

1.  

1.  

1.  

1.  

Im Laufe des Projekts warten eine ganze Reihe von Herausforderungen und Fallstricken auf uns, zum Beispiel wenn wir kritische Zugriffe auf das SAP-System analysieren und feststellen, wer ein zugewiesenes SAP_ALL-Profil hat....

Für den Einzelnen ist es vielleicht nicht so einfach, auf einen so breiten und bequemen Zugang zu verzichten. Das Argument: „Ich bin ein Hauptnutzer und benötige im Notfall einen breiten Zugang, wenn es einen Notfall im System gibt”.
Eine weitere Überraschung betrifft einen anderen wichtigen Aspekt des Projekts. Nun, das Projekt zur Reorganisation von Autorisierung und SoD ist ein eminent interdisziplinäres Projekt. Um ein perfektes Projektteam zu bilden, müssen wir sowohl die fachlichen als auch die technischen Nutzer (Autorisierungsteam, Modulberater, Entwickler, Basis) einbeziehen und die Aufgaben aufteilen. Leider wird bei Projekten, die den Namen „Autorisierung” tragen, der Projektverantwortliche häufig den IT-Teams zugeordnet:

Beispiele für die Kombination von SAP-Standardwerkzeugen mit Werkzeugen der SAST Suite

Sobald die Themenverantwortlichen und Aufgaben für jede Projektphase definiert sind, ist es wichtig, sich über die geeigneten Werkzeuge Gedanken zu machen, die in einem Befähigungs- und SoD-Umstrukturierungsprojekt nützlich sein können. Es lohnt sich, einen Blick auf die von SAP und auf dem Markt verfügbaren Tools zu werfen, die zeitaufwendige Arbeiten zu reduzieren und zu automatisieren Projektteam. Im Folgenden gebe ich Beispiele für die Gegenüberstellung von SAP-Standardwerkzeugen mit Werkzeugen der SAST Suite.

1. SoD Konfliktmatrix - oder unsere Autorisierungsmaschine. Beginnen wir unsere Aktivitäten mit der Erfassung und Dokumentation der kritischen Prozesse in der Organisation.
   SAP-StandardKonfiguration von „kritischen Kombinationen” und „kritischen Berechtigungen” in SUIM. Überprüfung nur auf der Ebene des Tcode-Zugriffs (Transaktion).
   SAST-SuiteVorgefertigte SOD-Konfliktbibliothek (mehr als 300 definierte Konflikte) pro SAP-Modul. Überprüfung auf der Ebene des Tcode-Zugriffs + Anspruchsobjekt + Wert der Felder des Anspruchsobjekts
2. SAP-Rollenmanagement - während eines Reorganisationsprojekts für Berechtigungen werden häufig neue Rollen erstellt oder bestehende Rollen geändert.
   SAP-StandardRollen nach Bedarf erstellen und ändern und (ggf.) Positionen definieren - PFCG
   SAST-Suite: gebrauchsfertige Rollenvorlagen (die über den SAP-Standardtransport in das System hochgeladen werden) - unterteilt in betriebswirtschaftliche Rollen, technische Rollen, SAP-Module und Jobrollen
   Ergebnis: Standardisierte Rollenbenennungskonvention + Umfassende Rollenbeschreibung.
3. SAP-Rollenmanagement - Bei schnell wachsenden Unternehmen kommt es zu Mini-Rollout-Projekten. Dann müssen neue Berechtigungen für neue Organisationsebenen organisiert werden.
   SAP-Standard: Es müssen Referenzrollen erstellt werden, aus denen abgeleitete Rollen mit neuen Organisationsebenen erstellt werden - Rollen kopieren + manuelle Änderung in der PFCG.
   SAST Suite: Definition von Referenzrollen + Erstellung von Orgsets mit Werten der neuen Organisationsebenen + automatische Erstellung abgeleiteter Rollen.
   Automatische Erstellung von Rollen mit neuen Organisationsebenen:
   Ergebnis: nach der Definition der Werte im Orgset, automatische Erstellung einer Rolle mit dem Namen: YFI_C_AC00:AA-DAILY, wobei die Organisationsebenen ergänzt werden.
4. Trace - wir verwenden diese Funktion, um die Aktionen eines Benutzers im System anhand der verwendeten Berechtigungen zu verfolgen.
   SAP-Standard: ST01 oder SM20 (Sicherheitsauditprotokoll), SU53, STUSOBTRACE
   SAST Suite: Möglichkeit, die Verfolgung beliebiger Benutzer von einem einzigen Dashboard aus zu starten + vollständige Daten über durchgeführte Aktivitäten + Erstellung einer Rolle aus einer Spur.
   Benutzerverfolgung + Erstellung einer Rolle mit verwendeten Berechtigungen + Anzeige fehlender Berechtigungen
   Ergebnis: Erstellung einer Rolle aus einem Trace für einen ausgewählten Benutzer.

Zusammenfassung

Wir sollten die verbleibenden Herausforderungen des Projekts zur Neuordnung der Ansprüche nicht vergessen:

• Begriff des Anspruchs - Pflege - dieses Dokument ist ein „lebender Organismus”
• Prozesse der Berechtigungs- und Benutzerverwaltung
• Identifizierung von Bereichsverantwortlichen und Rollen
• Zyklische Überprüfungen von SoD und Ansprüchen - mindestens einmal pro Jahr
• Aufrechterhaltung der Kontinuität des neuen Berechtigungssystems und des SoD

Kontaktieren Sie uns bitte

Sollten Sie an einem der behandelten Themen besonders interessiert sein, können Sie mich gerne kontaktieren.