Kritische Berechtigungen und Funktionstrennungskonflikte (SoD-Konflikte) sind Alltag für Berechtiger. Das macht den Umgang damit aber nicht weniger herausfordernd. Vor allem, weil in jedem Unternehmen andere Berechtigungen als kritisch gelten können. Wir erklären, wie Sie kritische Berechtigungen erkennen und wie Sie das Risiko minimieren können.
Grob gesagt gelten Berechtigungen als kritische, wenn sie entweder das System selbst gefährden oder die Integrität der Daten innerhalb des Systems. Dabei gibt es einige Berechtigungsobjekte und vor allem Berechtigungskombinationen, die immer ein Risiko darstellen und deshalb nur sehr restriktiv vergeben werden dürfen (oder auch gar nicht – in Produktivsystemen etwa). Dazu kommen aber auch Berechtigungen, die nur für bestimmte Branchen als kritisch eingestuft werden – etwa, wenn branchenspezifische Gesetzgebung besonderen Schutz verlangt. Und schließlich kann und sollte auch jedes Unternehmen selbst ein Sicherheits- und Berechtigungskonzept haben, dass individuelle Regelungen zu kritischen Berechtigungen enthält.
Kritische Berechtigungen: System, User, Daten
Grundlegend gibt es drei große Einfallstore für Sicherheitsrisiken in einem SAP-System: das System selbst, die Userverwaltung und die Daten, mit denen das System operiert. Die Gefahr von Sicherheitsverstößen steigt, wenn die falschen User Berechtigungen haben, mit denen sie das System manipulieren, User verwalten oder Daten ohne zusätzliche Kontrollinstanz (4-Augen-Prinzip) verändern können.
Wichtig: Auch „harmlose“ Berechtigungsobjekte können zu einem Sicherheitsrisiko werden – wenn ihre Ausprägung oder die Kombination mit anderen Objekten zu einer Überberechtigung führt.
Kritische Systemberechtigungen
Geht es um das SAP-System selbst, sind beispielsweise Berechtigungen zum Debuggen, Entwicklerberechtigungen, Berechtigungen zum Verwalten von Hintergrundjobs, Transportberechtigungen, Spool-Berechtigungen oder auch Berechtigungen zum Anlegen und Verwalten von RFC-Verbindungen kritisch. Das ist aber nur eine kleine Auswahl.
Berechtigungsobjekte, die systemseitig ein Risiko bergen können, sind etwa (beispielhafte, unvollständige Aufzählung!):
- S_BTCH_ADM
- S_BTCH_JOB
- S_BTCH_NAM
- S_ADMI_FCD
- S_LOG_COM
- S_RZL_ADM
- S_SPO_ACT
- S_SPO_DEV
- S_DEVELOP
- S_DBG
- S_TRANSPRT
Je nach Ausprägung erlauben diese Berechtigungsobjekte Änderungen an den Systemeinstellungen, u.a. auch an den Sicherheitseinstellungen. Sie sollten deshalb so selten und so eingeschränkt wie möglich vergeben werden.
Kritische Berechtigungen Userverwaltung
Wer User anlegen, löschen oder verwalten kann, kann theoretisch auch nicht autorisierten Personen Zugriff zum System und den darin verarbeiteten Daten gewähren. Besonders riskant ist das, wenn der User nicht nur die Rechte für die User-, sondern auch für die Rollenverwaltung hat. Damit könnte er beispielsweise seinen eigenen User mit Rollen ausstatten, die ihm weit mehr Rechte gewähren, als er braucht und haben sollte.
Achtung: Das betrifft auch Profile. User könnten sich selbst und anderen Usern so beispielsweise auch die Profile SAP_ALL und SAP_New zuweisen.
Potenziell kritische Berechtigungen hinsichtlich der Userverwaltung verstecken sich zum Beispiel in folgenden Berechtigungsobjekten (beispielhafte, unvollständige Aufzählung!):
- S_USER_AUT
- S_USER_GRP
- S_USER_VAL
- S_USER_PRO
Aber auch Transaktionscodes wie SU01 und natürlich PFCG sollten ausschließlich User- bzw. Berechtigungsadministratoren vorbehalten sein.
Auch hier gilt: Das Risiko liegt oft in der Kombination verschiedener Ausprägungen oder Berechtigungsobjekte.
Kritische Daten-Zugriffe
System-Berechtigungen und User-/Rollenverwaltung bergen vor allem Sicherheitsrisiken für die Verfügbarkeit und Integrität des Systems. Doch darüber hinaus gilt es auch, Unternehmensdaten und -prozesse zu schützen.
Wer beispielsweise im Produktivsystem weitreichende Tabellenänderungsrechte hat, kann Unternehmensdaten manipulieren und u.U. auch hohen wirtschaftlichen Schaden anrichten. Das gilt auch für Berechtigungen zum Beispiel zum Öffnen und Schließen von Buchungsperioden und ähnliches.
Kritische Berechtigungen hinsichtlich der Daten verstecken sich (zusätzlich zu unzähligen fach- und modulspezifischen Berechtigungsobjekten) etwa in:
- S_TCODE
- S_TABU_DIS
- S_TABU_CLI
- S_TABU_NAM
Um die Sicherheitsrisiken in diesem Bereich zu minimieren, ist ein gutes Berechtigungskonzept nötig. Das regelt, welche Berechtigungen User konkret brauchen, wer potenziell kritische Zugriffe bekommen darf und wie diese überwacht bzw. gemindert werden.
Funktionstrennung: SoD-Konflikte vermeiden
Um eine hohe Datensicherheit zu gewährleisten, arbeiten wir im SAP-System mit Rollenkonzepten, die klare Funktionstrennungen (Segregation of Duty (SoD)) vorsehen. Das bedeutet zum Beispiel: Wer eine Bestellung tätigen darf, darf sie nicht freigeben. Um für diese sensitiven Funktionen Kontrollinstanzen zu installieren, gilt das 4- oder 6-Augen-Prinzip. Dafür bauen wir für jede Funktion eine separate Einzelrolle. Dieses Konzept geht aber nur auf, wenn die Einzelrollen auch tatsächlich nie gleichzeitig vergeben werden.
Das wird dann wichtig, wenn Sie mit Sammel- oder Businessrollen arbeiten. Achten Sie darauf, dass hier keine Einzelrollen zusammengefasst werden, deren Berechtigungen in Kombination zu einem SoD-Konflikt führen können.
Kritische Berechtigungen aufdecken
Sie wissen jetzt also grob, wie Sie kritische Berechtigungen erkennen. Doch wie finden Sie heraus, ob in Ihrem System kritische Berechtigungen oder Berechtigungskombinationen vergeben sind bzw. welche und wie viele? Dafür gibt es mehrere Möglichkeiten:
- Einsatz von externen Dritt-Tools
- Analyse über SAP GRC
- Analyse über SUIM bzw. Report RSUSR008_009_NEW
Alle drei Optionen setzen allerdings voraus, dass Sie ein Sicherheitsregelwerk definiert haben. Das ist nicht zwingend Ihre Aufgabe als Berechtiger. Es ist aber durchaus möglich, dass Sie damit konfrontiert werden. Als Grundlage können Sie den Prüfleitfaden der DSAG zu Rate ziehen.
Gut zu wissen: Über den Report RSUSR_UP_AND_DOWNLOAD_FOR_CA können Sie das Regelwerk aus dem ABAP-System (SUIM) downloaden, in Excel ergänzen und wieder uploaden.
Sowohl die Dritt-Tools wie auch der SUIM-Report prüfen nun wahlweise auf User- oder Rollenebene, ob die Berechtigungen und Berechtigungskombinationen, die im Regelwerk als kritisch definiert sind, aktuell vergeben sind.
Kritische Berechtigungen beheben oder vermeiden
Ihnen liegt jetzt also eine detaillierte Auswertung über kritische Berechtigungen in Ihrem (Produktiv)System vor. Jetzt gilt es, diese zu analysieren. Gleichen Sie dazu im ersten Schritt Ihre Auswertung mit dem vorhandenen Berechtigungskonzept ab: Im besten Fall ist darin genau definiert, wer kritische Berechtigungen und Berechtigungskombinationen haben darf. Bei diesen Fällen müssen Sie nicht weiter tätig werden.
Bei allen kritischen Berechtigungen, die nicht im Berechtigungskonzept (oder einem separaten Sicherheitskonzept) dokumentiert sind, müssen Sie handeln. Diese Fälle fallen Ihnen sonst spätestens bei einer Wirtschaftsprüfung, einem Audit auf die Füße.
Folgende Möglichkeiten haben Sie, um mit kritischen Berechtigungen umzugehen:
- Berechtigungskonzept erweitern. Möglicherweise ist das Berechtigungskonzept veraltet und enthält noch keine Erkenntnisse zu neuen Berechtigungsobjekten. Dann gilt es, das jetzt nachzuholen.
- Rollen entziehen, die zu SoD-Konflikten oder kritischen Berechtigungskombinationen führen. Prüfen Sie, ob der User diese Rollen wirklich braucht. Häufig erfolgte einfach keine Abgrenzung, wenn der User einen neuen Aufgabenbereich übernommen hat. So hat er die Rollen für seine neue Tätigkeit, aber auch noch die für seinen alten Job. Letztere können problemlos entzogen werden. Braucht der User einzelne Berechtigungen aus den alten Rollen weiterhin, müssen Sie entweder neue Rollen bauen bzw. bestehende erweitern (mit Berechtigungskonzept abgleichen) oder der User muss ggf. auf Notfall-User (Firefighter) zurückgreifen, deren Nutzung sauber dokumentiert und kontrolliert wird.
- Berechtigungen aus Rollen entfernen. Hier gilt dasselbe: Wenn der User auf die als kritisch eingestuften Berechtigungen tatsächlich angewiesen ist, müssen entweder das Rollenkonzept und dann die Rolle(n) angepasst werden. Oder der User muss auf einen Firefighter ausweichen.
- Risiken mitigieren. Ihr Sicherheitsregelwerk sollte auch Mitigationen enthalten für den Fall, dass Berechtigungen zwar als kritisch eingestuft, aber bewusst vergeben werden. Sie können dann Richtlinien/Profile nutzen, um ein Risiko zu mitigieren. Beispiel: Debug-Berechtigungen gelten als kritisch, mit der Mitigationsregel „nur für Entwickler vorproduktiv“ dürfen sie die Rechte aber in einer vorproduktiven Entwicklerrolle verbauen.