Business-Team arbeitet am PC mit Berechtigungskonzept

Warum ein gutes Berechtigungskonzept Zeit braucht

Wir gehen nächsten Monat live – kannst du mal eben schnell ein Berechtigungskonzept machen?“ Solche Anfragen bekommen unsere Compliance-Experten immer wieder.

Diese stellen sich dann immer die Frage: „Ob sie einer Applikations-Einführung auch nur einen Monat Zeit geben?“ Weil: Ein revisionssicheres Berechtigungskonzept, bei dem die Berechtigungen dem Prozessdesign des Unternehmens entsprechen und alle Prozesse richtlinienkonform sind und alle das tun können was sie tun sollen, schießt man nicht einfach aus der Hüfte. Es dauert seine Zeit. Wie übrigens alles, bei dem es im Interesse der Sicherheit auf besonders hohe Qualität ankommt.

Wer es eilig hat, startet zum Go-live gern mal mit SAP_ALL, damit es zum Einstieg bloß keine Berechtigungsprobleme gibt. In diesem Stadium dürfen dann alle alles machen – ein Alptraum für Datenschützer und Compliance-Manager und ein gefundenes Fressen für Wirtschaftsprüfer. Die Idee: Man reduziert die Berechtigungen einfach nachträglich. Nach und nach. Und nach. In der irrigen Annahme, die Prüfer werden diesen Faux Pas aus der Vergangenheit schon nicht finden.

Doch das ist mühsam und garantiert längst kein sicheres System. Vielmehr sind Findings vorprogrammiert. Ein besserer und oft (langfristig) deutlich kostengünstigerer Ansatz für ein revisionssicheres Berechtigungskonzept ist es, Prozesse, Richtlinien und Berechtigungen integriert zu betrachten. Das Ziel: Die Berechtigungen passen zu den Prozessen und sowohl Berechtigungen als auch Prozesse sind regelkonform.

So erreichen wir, dass das, was jemand SOLL und tut, ihm auch ERLAUBT ist.

Wie das funktioniert? Zunächst einmal etwas Hintergrund: Bei der Erstellung von Berechtigungskonzepten sind drei zentrale Unternehmensbereiche einzubeziehen, die sich gegenseitig beeinflussen.

  • Prozess-Dokumentation (Prozessdesign [= SOLL])
  • Richtlinien (Zugriffs-Risiko-Regelwerk [= ERLAUBT])
  • Ist-Situation (Berechtigungen [= IST] und Nutzungsdaten [= DARF])

Im Zentrum: die Vorgaben und Richtlinien. Im Idealfall entsprechen die Prozesse diesen Vorgaben und Richtlinien. Und ebenso die Berechtigungen, die wiederum den auch tatsächlich im Alltag genutzten entsprechen.

Die Ist-Situation ist vorzugsweise minimalistisch, entspricht aber dennoch dem Prozessdesign.

Die Prozess-Dokumentation spiegelt die gelebten Prozesse wieder. Die Berechtigungen spiegeln die Prozess-Dokumentation wieder. Und alles ist regelkonform. (Klingt banal, aber die Realität sieht häufig anders aus. Inkonsistenzen oder fehlende Aktualität führen z. B. zu Überberechtigungen, unerwünschte Prozessabläufe, Findings durch Prüfer und in der Folge zu aufwendigen Bereinigungsaufwänden).

Unsere Lösung:

Vorgaben und Richtlinien, Ist-Situation und Prozesse gleichermaßen berücksichtigen

  • Ausgehend von einzelnen Prozessschritten im Prozessdesign, die im SAP mittels einer Transaktion (oder App) ausgeführt werden, definieren wir in einem Zugriffs-Risiko-Regelwerk diejenigen Prozessschritte, die einzeln oder in Kombination gemäß den internen oder externen Richtlinien kritisch sind.
  • Zur Erstellung minimalistischer Berechtigungen greifen wir auf Nutzungsdaten aus der Vergangenheit zurück – denn die Berechtigungen, die ein Benutzer für die Ausführung von Transaktionen benötigt, sind ja bereits bekannt.
  • Berechtigungen und Nutzungsdaten passen im besten Fall zum Prozessdesign und dem Zugriffs-Risiko-Regelwerk. Wir sprechen in diesem Zusammenhang von einer gemeinsamen Entität: die Funktion. Über die gemeinsame Entität „Funktion“ können alle drei Bereiche bestenfalls miteinander technisch kommunizieren.

Schritt für Schritt:

So können Prozesse und Zugriffs-Risiko-Regelwerk miteinander harmonieren

In einem ersten Schritt werden die maximal ausführbaren Berechtigungen (DARF) anhand der Nutzungsdaten (IST) und ggf. mithilfe eines Tools (z. B. der XAMS (Xiting Authorizations Management Suite) erstellt. Diese werden nach Prozessschritten und Jobbeschreibungen gruppiert - Ergebnis: IST = DARF.

Parallel dazu werden die relevanten Richtlinien in eine technische Berechtigungssprache übersetzt und softwaregestützt (z. B. im SAP GRC Access Control oder ERP Maestro) abgelegt (ERLAUBT).

Dann werden die Berechtigungen (DARF) mit den Risiken (ERLAUBT) mithilfe einer softwareunterstützenden Risikoanalyse von Rollen und Benutzern abgeglichen.
Ergebnis: DARF = ERLAUBT.

Zuletzt erfolgt ein Abgleich der Nutzung (IST) oder der Berechtigungen (DARF) mit dem Prozessdesign (SOLL). Ergebnis: IST/DARF = SOLL.

Dadurch erreichen wir in letzter Konsequenz, dass die Prozesse regelkonform sind und Änderungen im Prozessablauf schnell in den Berechtigungen umgesetzt werden können.

 

Das klingt anstrengend?

Machen Sie es sich leicht. Nutzen Sie unsere Templates und unsere Erfahrung.

Aller Anfang ist schwer. Darum bringen wir einige Templates mit, die den Einstieg in ein gemeinsames Projekt vereinfachen:

  • Einzelrollen auf Transaktionscodeebene
  • Excel-Listen oder uploadfähige Files (für Risikoanalyse-Tools)
  • Prozess-Templates für viele Applikationen

Gemeinsam mit Ihnen, unseren GRC-Experten und Prozessberatern definieren wir

  • das Mapping der Funktionen zu Ihrem Prozessdesign
  • die Planung und Erstellung des initialen, bereinigten Setups
  • das Design Ihrer individuellen Prozesse zur kontinuierlichen Kommunikation (Analyse-Anpassung)

  Machen Sie es gleich von Anfang an richtig:  Mit regelkonformen Prozessen und einem (weitestgehend) wasserdichten Berechtigungskonzept und kontinuierlicher Überwachung vermeiden Sie Regelverstöße präventiv, ersparen Sie sich Stress beim Audit und genervte Berechtigungsadministratoren, Anwender und Manager. Auch wenn der große Wurf zu Beginn ein kleines bisschen länger als einen Monat dauert.

 

Haben Sie dazu noch Fragen? Sprechen Sie uns gerne an:
Datenschutz mit SAP

Björn Rolka

Associate Partner Bjoern.Rolka@ConVista.com
XS
SM
MD
LG
Share
Sprachauswahl Icon
We noticed your browser language is not German.
Do you want to switch to English?