Wie kann man es mit den Berechtigungen nicht übertreiben? – Kleinste Zugriffsanforderung in SAP

In der Welt der ERP-Systeme wie SAP ist die Frage der Benutzerrechte von entscheidender Bedeutung – nicht nur für die Sicherheit, sondern auch für die Effizienz des gesamten Unternehmens. Und doch kommt es in der Praxis häufig vor, dass Benutzer Zugriff auf eine viel größere Anzahl von Funktionen haben, als sie realistischerweise benötigen. Manchmal ’nur für den Fall‘, manchmal ‚weil es schneller ging‘, und manchmal hat sich einfach niemand die Mühe gemacht, das zu überprüfen.

Inzwischen gibt es ein Prinzip, das die Grundlage jeder Zugriffsverwaltungspolitik sein sollte:Das Prinzip der geringsten Rechte (Least Privilege Principle, LPP). Kurz gesagt: Ein Benutzer sollte genau so viele Privilegien haben, wie er zur Erfüllung seiner Aufgaben benötigt. Weder weniger noch mehr.

Eine Umfrage unter 225 Unternehmen ergab, dass 85 % der Berechtigungen in den letzten 90 Tagen nicht genutzt wurden und dass jeder dritte Benutzer Zugang zu Systemen hatte, die er überhaupt nicht nutzte. Diese Daten lassen keine Illusionen zu – überflüssiger Zugriff ist ein echtes und weit verbreitetes Problem. Die Mehrheit der Benutzer hat viel zu weitreichende Rechte, was nicht nur die Angriffsfläche vergrößert, sondern auch ein Audit-Risiko darstellt.

Warum ist das wirklich wichtig?

Das LPP-Prinzip ist nicht nur gesunder Menschenverstand – es ist eine der Säulen der Informationssicherheit und der Einhaltung von Vorschriften. Übermäßig weitreichende Befugnisse können die Folge sein:

• Betrug oder Datenmanipulation,
• versehentliche Fehler, die Prozesse unterbrechen oder Datenverluste verursachen,
• Verstoß gegen den Grundsatz der Aufgabentrennung (SoD),
• die Nichteinhaltung von Vorschriften wie RODO oder SOX,
• schwierigere Audits und größere Möglichkeiten für Cyberangriffe.

Geschichten aus dem Leben, oder wie es in der Praxis aussieht.

Sehen wir uns einige Beispiele für die Nichtanwendung des Prinzips des geringsten erforderlichen Zugriffs an:

Beispiel 1: Sachbearbeiter in der Buchhaltung mit vollem Zugriff auf den Rechnungsstellungszyklus

Die Person in der Finanzabteilung hatte Zugriff auf alle Transaktionen im Rechnungsstellungszyklus: von der Erfassung der Eingangsrechnungen (MIRO) über die Buchung der Belege (FB60) bis zur Genehmigung der Zahlungen (F110).

Risiko: Der Mitarbeiter könnte den gesamten Prozess selbst durchführen – von der Erstellung des Dokuments bis zur Ausführung der Überweisung. Ein solcher Zugriff verstößt gegen das Prinzip der Aufgabentrennung und erschwert es erheblich, später festzustellen, wer wofür verantwortlich war.

Lösung: Schränken Sie den Zugriff auf eine Rolle ein – z.B. nur MIRO oder nur FB60 – und weisen Sie die Zahlungsgenehmigung einem anderen Benutzer zu. Es lohnt sich, einen Workflow zu implementieren und die Verantwortlichen für die einzelnen Schritte des Prozesses klar zu definieren.

Beispiel 2: Mitarbeiter in der Einkaufsabteilung mit Zugriff auf die Verkaufsbedingungen

Der Sachbearbeiter im Einkauf hatte nicht nur Zugriff auf Bestellungen (ME21N, ME22N), sondern auch auf Verkaufskonditionen (VK11). Das Problem war, dass er diese Daten nicht benötigte und ihre Bearbeitung strategische Konsequenzen haben konnte.

Risiken: Unbefugte Änderung der Preispolitik – versehentlich oder absichtlich.

Lösung: Trennen Sie die Rollen von Einkauf und Verkauf klar voneinander und beschränken Sie den Zugriff auf die Daten nur auf die entsprechenden Einheiten.

Beispiel 3: Arbeitnehmer nach einem Arbeitsplatzwechsel

Nachdem er vom Lager in die Controlling-Abteilung gewechselt war, behielt der Mitarbeiter seine alten Ansprüche und erhielt neue. Das Ergebnis? Gleichzeitiger Zugriff auf Lagerdokumente und Kostendaten.

Risiken: Redundanter Zugriff auf Prozesse außerhalb der aktuellen Zuständigkeiten, mögliche SoD-Konflikte.

Lösung: Jeder Positionswechsel sollte eine vollständige Überprüfung der Berechtigungen nach sich ziehen – nicht nur das Hinzufügen neuer Rollen, sondern auch das Streichen überflüssiger Rollen.

Diese Beispiele zeigen, wie leicht es in der Praxis ist, zu viele Vollmachten zu erteilen – oft als Folge von Eile, mangelnder Überprüfung oder unüberlegten Rollenkombinationen. Jeder der beschriebenen Fälle macht deutlich, dass selbst scheinbar geringfügige Versäumnisse zu ernsthaften Risiken führen können, die sich durch die Anwendung des LPP-Prinzips leicht beseitigen lassen.

Wie handeln Sie nach dem LPP-Prinzip?

Die Anwendung des Prinzips des Least Required Access erfordert nicht nur ein Bewusstsein für die Risiken, sondern auch konkrete organisatorische und technische Maßnahmen – am besten systematisch und mit Blick auf die langfristige Sicherheit umgesetzt. Hier sind einige Vorschläge:

• Erstellen Sie Geschäftsrollen, die auf die tatsächlichen Verantwortlichkeiten zugeschnitten sind – keine unnötigen Transaktionen.
• Legen Sie organisatorische Felder fest und beschränken Sie den Umfang der Daten (z.B. auf ein bestimmtes Unternehmen oder Lager).
• Nutzen Sie durchdachte Genehmigungs- und Berechtigungsprüfungsverfahren – insbesondere bei einem Rollen- oder Positionswechsel.
• Überprüfen Sie SoD-Konflikte, bevor Sie Zugriff gewähren.
• Überprüfen Sie Ihre Ansprüche regelmäßig, z.B. alle 6 oder 12 Monate.
• Unterstützen Sie sich selbst mit SAP-Tools wie GRC Access Control, SUIM, ST03N oder Transaktionsprotokollen.

Und wenn Sie das Thema Zugang wirklich in den Griff bekommen wollen, lohnt es sich, zu speziellen Lösungen wie smartGRC (https://smartgrc.eu/) zu greifen. Mit diesen können Sie unter anderem:

• regelmäßige Überprüfungen von Ansprüchen durchführen,
• einen Workflow für die Gewährung und Genehmigung des Zugriffs einrichten,
• die SoD-Risikodatenbank verwalten, was die Kontrolle erheblich erleichtert und die Systemsicherheit verbessert.

LPP und Benutzererfahrung

Ein weit verbreiteter Mythos ist der Glaube, dass die Einschränkung von Autorität die Menschen weniger zufrieden stellt. In Wirklichkeit ist genau das Gegenteil der Fall.

Gut konzipierte Rollen – entsprechend den Zuständigkeiten und bereinigt von überflüssigen Transaktionen – machen Benutzer:

• die benötigten Funktionen schneller finden,
• nicht von unnötigen Optionen auf der Benutzeroberfläche überwältigt werden,
• sind weniger anfällig für Fehler, die durch versehentliches Klicken auf das „Falsche“ entstehen.

Das Prinzip des Least Access Required verbessert also nicht nur die Sicherheit, sondern auch die Benutzerfreundlichkeit des SAP-Systems. Es ist eine sauberere, klarere Oberfläche – und damit eine bessere Erfahrung für den Endbenutzer.

BVG und Sicherheitsvorschriften und -standards

Es sei auch daran erinnert, dass der Grundsatz des geringstmöglichen Zugriffs nicht nur eine gute Praxis ist, sondern auch eine der formalen Anforderungen vieler internationaler Standards und Vorschriften für Informationssicherheit und Datenschutz.

Hier sind einige Beispiele:

• ISO/IEC 27001 – verlangt, dass der Zugang zu Ressourcen auf der Grundlage der geschäftlichen Notwendigkeit kontrolliert wird.
• NIST SP 800-53 – identifiziert das Prinzip der geringsten Privilegien als primären Mechanismus zum Schutz von Informationssystemen.
• RODO/GDPR – verpflichtet dazu, den Zugriff auf personenbezogene Daten nur auf diejenigen zu beschränken, die sie tatsächlich benötigen (Minimierungsprinzip).
• SOX (Sarbanes-Oxley Act) – verlangt Zugangskontrollen im Zusammenhang mit der Integrität von Finanzberichten.

Die Einhaltung des LPP-Prinzips trägt daher nicht nur dazu bei, betriebliche Risiken zu minimieren, sondern auch die Einhaltung geltender Vorschriften und Standards zu gewährleisten, was bei Audits und externen Inspektionen entscheidend sein kann.

Was bringt Ihnen die Nutzung von LPP?

Bei der Umsetzung des Prinzips des Least Required Access geht es nicht nur um Compliance und Sicherheit. Es geht auch um eine Reihe greifbarer Vorteile:

• Weniger Probleme mit Audits – dank besserer Kontrolle des Zugriffs.
• Schnellere und klarere Kontrollen – strukturierte Rollen bedeuten weniger Ausnahmen, die übersetzt werden müssen.
• Geringere Kosten für die Zugriffsverwaltung – weniger zu verwaltende Rollen, weniger Anfragen an die IT-Abteilung.
• Größere Transparenz der Rechenschaftspflicht – es ist klar, wer für was verantwortlich ist.
• Weniger Benutzerfehler – denn sie haben nur Zugriff auf das, was sie wirklich brauchen.
• Ein „saubereres“ SAP-System – ohne überwucherte Rollen und historische Berechtigungen.

Schließlich der gesunde Menschenverstand als Maßstab

Das Prinzip des geringstmöglichen Zugriffs (Least Required Access) ist keine übertriebene Vorsichtsmaßnahme, sondern ein professioneller Ansatz für die Sicherheit bei SAP. Es schützt nicht nur Daten und Prozesse, sondern auch den Ruf des Unternehmens.

Es lohnt sich also, einen Moment darüber nachzudenken: Ist dieser Zugang wirklich notwendig? Wenn nicht, ist dies genau der richtige Zeitpunkt, um ihn einzuschränken.

Quellen:

1. Cloud Security Alliance. (2024). Mastering Least Privilege: Beschneiden Sie ungenutzten Zugriff, ohne Ecken und Kanten zu schneiden. Abgerufen von https://cloudsecurityalliance.org/blog/2024/05/30/mastering-least-privilege-cutting-unused-access
2. (n.d.). Was ist Least Privilege? Heruntergeladen von https://www.cyberark.com/what-is/least-privilege/
3. Edwards, M. (2025). Anhang A.5.3: Aufgabentrennung. Online. Abgerufen von https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
4. Nationales Institut für Standards und Technologie (NIST). (n.d.). Least Privilege. Heruntergeladen von https://csrc.nist.gov/glossary/term/least_privilege
5. (2024). Sichern Sie SAP mit effektiver Access Governance. Abgerufen von https://www.safepaas.com/articles/secure-sap-with-effective-access-governance/
6. (2025). Zugangszertifizierung: Ein ultimativer Leitfaden. Zluri. Abgerufen von https://www.zluri.com/blog/access-certification
7. (2024). Offizielle smartGRC Produktseite. Heruntergeladen von https://smartgrc.eu/