Konzepte der SAP Security

| Autor/in:Susanna Albrecht

Bei einer SAP-Security-Prüfung steht insbesondere die Berechtigungsvergabe im Mittelpunkt. Sie ermöglicht Benutzern erst die Arbeit am SAP-System, kann sich jedoch u. U. ungewollt zu Funktionstrennungskonflikten oder gar gesetzeskritischen Befugnissen aufsummieren. Daher sind regelmäßig Tools zur technischen Analyse einzusetzen, die den Status quo der Berechtigungsvergabe und somit die Grundlage für eine Optimierung liefern.

Eine vollumfängliche SAP-Sicherheitsüberprüfung ist hier jedoch noch nicht zu Ende. Zusätzlich untersucht der Auditor, ob die vier wichtigen Konzepte der SAP Security, namentlich das Dateneigentümer-, das Eigenentwicklungen-, das Berechtigungs- und das Notfalluserkonzept, den Anforderungen genügen. Jedes von ihnen sollte ein ausformuliertes Schriftstück darstellen, das zum einen alle Soll-Vorgaben zum jeweiligen Thema enthält und zum anderen mit dem vorgefundenen Ist-Zustand der Prüfung übereinstimmt.


Dateneigentümerkonzept

Wer über wertvolles, persönliches Eigentum verfügt, übernimmt hierfür Verantwortung – so wie bspw. ein Hausherr. Er entscheidet darüber, ob Veränderungen am Gebäude vorgenommen, Sichtschutzhecken im Garten gepflanzt oder überflüssige Altgeräte entsorgt werden müssen und lässt ggf. beim Verlust des Haustürschlüssels sofort ein neues Schloss einbauen. Möglicherweise verbietet er Besuchern, die nicht zur Verwandtschaft gehören, den Zutritt zum Schlafzimmer oder der Tochter, im Haus eine öffentliche Party zu feiern.

Ebenso verhält es sich mit dem Konzept der Dateneigentümerschaft. Hierbei übernimmt eine Person die Verantwortung für die Daten eines bestimmten Geltungsbereichs (z. B. SAP-System X oder Systemlandschaft Y) und achtet auf diese, als seien sie der eigene, kostbare Besitz. Er beantwortet gewissenhaft Fragen wie „Dürfen Daten verändert / eingesehen / gelöscht werden?“, „Wie wird bei einem Datenabfluss gehandelt?“, „Wer darf wie auf die Daten zugreifen und was mit ihnen machen?“.

Ein typisches Einsatzgebiet ergibt sich bei der Anforderung eines neuen SAP-Benutzers. Der Dateneigentümer prüft nun, ob der Beantragende und die zu berechtigende Person überhaupt jeweils dafür befugt sind, welche Daten betroffen wären, ob evtl. bereits ein SAP-User besteht, dem neue Rollen zugeteilt und alte entzogen werden können, ob der Datenzugriff zeitlich begrenzt werden kann etc.

Geeignet für diese verantwortungsvolle Aufgabe sind z. B. Fachbereichsleiter oder SAP Key User, die sich sowohl mit allen Datenzugriffsmöglichkeiten auskennen (modulübergreifend, via Report, direkt auf die Rohtabelle etc.) als auch mit den organisatorischen und technischen Schutzmaßnahmen. Per Unterschrift unter dem Dateneigentümerkonzept sollte die Zuständigkeit anerkannt werden und so ernst genommen werden und verbindlich gelten wie auch bspw. die Signatur unter dem Kaufvertrag eines Hauses.


Berechtigungskonzept

Das Berechtigungskonzept fixiert alle Anforderungen an die SAP-Berechtigungsvergabe.

In erster Linie sind rechtliche Grundlagen zu nennen und auf gesetzeskritische Berechtigungen konkret hinzuweisen, die nicht (bzw. allenfalls an den Notfallbenutzer) vergeben werden dürfen. Ein Beispiel ist die Berechtigung “Debugging mit Replace“, zu der das Objekt S_DEVELOP mit den Werten ACTVT = 02 und OBJTYPE = DEBUG legitimiert und worüber sich Daten per Hauptspeicheränderung manipulieren lassen. Das verstieße jedoch gegen § 239 HGB, das sogenannte „Radierverbot“.

In dem Zuge müssen daher auch die SAP-Standardbenutzer wie SAP* und DDIC betrachtet werden, die zum Teil über weitreichende Berechtigungen verfügen und ohne konzeptionell festgelegte Absicherung eine Gefahr darstellen.

Unter Beachtung des Minimalprinzips und der Funktionstrennung sind die verwendeten Rollen zu definieren und damit einhergehend Vorgaben zu ihrer Benennung, Struktur und Nutzung. Auch auf das Beantragungs- und Vergabeverfahren sollte ein genaues Augenmerk gerichtet werden, um Berechtigungskonflikten vorzubeugen, die vor allem durch wechselnde oder sich erweiternde Aufgabenbereiche von Mitarbeitern entstehen.

Für den Fall, dass dennoch solche Konflikte auftreten, sind regelmäßige Kontrollen als Teil eines internen Kontrollsystems festzuschreiben. Des Weiteren finden sich im Berechtigungskonzept Inhalte wie z. B. die Einbindung des Dateneigentümers, sicherheitsrelevante Systemeinstellungen, Vorgaben zur Pflege der Berechtigungsvorschlagswerte (Transaktion SU24) und Dokumentationspflichten.

 

 Notfalluserkonzept

Um in Notsituationen jederzeit vollumfänglich agieren zu können, ist ein SAP-Notfallbenutzer bereitzuhalten, der über alle Berechtigungen fürs gesamte SAP-System verfügt (typischerweise mittels Sammelprofil SAP_ALL). Das macht ihn allerdings nicht nur zu einer großen Hilfe, sondern gleichzeitig ausgesprochen gefährlich, sodass sein Einsatz über ein dediziertes Konzept genau zu regeln ist.

Vorab muss klargestellt werden, wobei es sich überhaupt um einen anerkannten „Notfall“ handelt und welche Szenarien die Aktivierung des hoch privilegierten Benutzers noch nicht rechtfertigen. Zudem darf er erst nach begründetem Antrag und nur im 4-Augen-Prinzip genehmigt und freigeschaltet werden. Nach Gebrauch ist er sofort wieder administrativ zu sperren.

Jede Aktion des Notfallbenutzers muss nachvollziehbar sein, was die entsprechende Konfiguration von Protokollierungskomponenten wie dem Security Audit Log voraussetzt. Im Nachgang des Einsatzes werden stets sämtliche Logdateien ausgewertet und alle Details in einer Dokumentation festgehalten.

Möglicherweise wird konzeptionell festgelegt, dass im Ernstfall auch an andere ausgewählte User eine erweiterte Berechtigungsvergabe erfolgen darf, das obliegt der Abwägung des Unternehmens.

 

Konzept für Eigenentwicklungen

Das Konzept für Eigenentwicklungen ist für jede Firma obligatorisch, in der eigene Software geschrieben wird. Es nennt Vorgaben bspw. zu Aufbau, Namensgebung und Dokumentation der Programmkomponenten, insbesondere aber auch zum Umgang mit sicherheitskritischen Aspekten. Dabei sollte die Formulierung nicht zu allgemein gehalten werden, sondern explizit auf die Besonderheiten der Programmierung in SAP eingehen.

Unabdingbar ist das Gebot, adäquate Berechtigungsprüfungen in jede ABAP-Eigenentwicklung zu implementieren. Hierfür wird der sogenannte AUTHORITY-CHECK genutzt, der die erforderlichen Berechtigungsobjekt-Ausprägungen abfragt und somit nur befugte Benutzer den Code ausführen lässt.

Darüber hinaus sollten kritische Befehle von vornherein verboten werden. Beispiele sind EXEC SQL, der einen direkten Zugriff auf Datenbanktabellen unter Umgehung bestimmter Sicherheitsmechanismen ermöglicht, und CLIENT SPECIFIED, mit dem auf Daten in anderen Mandanten zugegriffen werden kann.

Durch die Vorgabe, gewisse Hilfsprogramme zu verwenden, kann zudem bspw. die Datenkonsistenz bei Zugriffen geschützt (ENQUEUE- und DEQUEUE-Funktionsbausteine) oder Quellcode regelmäßig hinsichtlich Security überprüft werden (Codescanner).

Die vier wichtigen Konzepte der SAP Security erfordern erst einmal einen gewissen Aufwand. Sie müssen nicht nur abgestimmt, ausformuliert und bereitgestellt, sondern eben auch fortlaufend aktualisiert und vor allem aktiv gelebt werden. Dennoch ist der Return of Investment groß, denn sie wappnen für alle Fälle, liefern Revisionssicherheit, außerdem ein hohes Schutzpotenzial fürs SAP-System und somit auch für das Unternehmen selbst.