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).

Schritt für Schritt::

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

#01:

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.

#02:

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).

#03:

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

#04:

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.