Lesezugriffe in SAP Systemen mit Read Access Logging (RAL) protokollieren

Roland Dittrich

26. September 2016 um 13:37 Antworten

Sehr geehrte Damen und Herren,

ich habe unserer IT vorgeschlagen, mit Hilfe von Read Access Logging (RAL) den Zugriff auf sensible SAP-Daten zu protokollieren.

Leider wurde mein Vorschlag negativ entschieden.

Begründung:
Es kann nicht einfach alles „protokolliert“ werden.
Jede Protokollierung hat eine Auswirkung auf die Performance des Systems und man muss genau definieren welche Daten protokolliert werden müssen, denn die Performance hängt von der von Ihnen protokollierten Datenmenge und der Komplexität ab.

RAL ist nicht geeignet als Standardlösung für generelles Logging– wenn dann sollte hier eine gezielte Aktivierung stattfinden, bei kritischen Daten und Zugriffen bzw. betrieblichen und oder gesetzlichen Vorgaben… um die Performance eines Systems nicht unnötig zu belasten.

SAL (Security Audit Log): erfüllt ebenfalls eine gewisse Protokollierung u.a. auf Transaktionsebene (Gerade im Offshoring Bereich wichtig) und ist als Measure Plan Maßnahme ohnehin vorgesehen

Frage:
Sehen Sie auch Performanceprobleme durch eine RAL-Leseprotokollierung?
Ist RAL ist nicht geeignet als Standardlösung für generelles Logging?
Ist SAL (Security Audit Log) eine bessere Lösung?

Meine Meinung:
SAP ist weltweit eines der am weitesten verbreiteten ERP-SystemeERP-Systeme und damit auch einer der wichtigsten Speicherorte für sensible Informationen. Die vermeintliche Gewissheit, dass die Daten innerhalb des SAP-Systems gut geschützt sind, führt bei vielen Verantwortlichen zu einem trügerischen Sicherheitsgefühl. Sobald die Informationen nämlich exportiert werden, ergeben sich zahlreiche Sicherheitsrisiken – und dies geschieht in den meisten Unternehmen täglich. Das sind typische Anwendungsszenarien aus der Praxis, die zu entsprechenden Sicherheitslücken führen:
Mitarbeiter exportieren täglich Daten aus SAP und versenden diese als Dokumente an andere Abteilungen oder Partner – ohne böse Absicht, einfach weil es schneller geht. Sobald die Daten jedoch die geschützte SAP-Umgebung verlassen, enthält das so entstandene Dokument keinerlei Sicherheitsinformationen aus dem SAP-System mehr.
Die exportierten Dokumente werden zudem häufig auf Mobilgeräte geladen und dort oder in der Cloud ungesichert gespeichert, was einen unberechtigten Zugriff von außen ermöglicht.
Manche Unternehmen lassen zudem externe Partner auf ihr SAP-System zugreifen – beispielsweise bei der Zusammenarbeit mit einer Wirtschaftsprüfungsgesellschaft oder auch externen IT-Firmen. Diese exportiert dann ebenfalls Daten aus SAP. Dabei hat das Unternehmen keinerlei Informationen darüber, welche Daten in Form von Dokumenten exportiert und wie diese bei den Geschäftspartnern gespeichert werden.
Eine weitere potenzielle Gefahr ist der automatische Versand von Dokumenten aus SAP – beispielsweise Gehaltsabrechnungen. Obwohl Personaldaten nach dem Datenschutzgesetz streng vertraulich zu behandeln sind, werden bei diesem Versand entsprechend vertrauliche Informationen ohne Schutz versendet.
Die bisherigen Beispiele beschreiben unbeabsichtigte Sicherheitsverstöße. Dazu kommen aber auch gezielte Sicherheitsverletzungen, bei denen Mitarbeiter Daten aus SAP exportieren und mitnehmen, wenn sie beispielsweise das Unternehmen wechseln oder entsprechende Informationen an Wettbewerber verkaufen. Immer wieder kommt es vor, dass entsprechende Daten, wie Materiallisten, Rezepturen und Baupläne oder ähnliche Informationen zum Verkauf angeboten werden.
Auch bei einer Expansion ins Ausland steigt die Gefahr von Diebstahl geistigen Eigentums (wie Bauanleitungen, CAD-Zeichnungen, Materiallisten, etc.) – ob durch den externen Zugriff oder die Weitergabe der Informationen durch Mitarbeiter. Viele deutsche Unternehmen, die beispielsweise nach Asien expandieren, denken daher über Zugriffsbeschränkungen nach. Die Mitarbeiter müssen zwar vor Ort SAP nutzen, die Datenexporte können aber beschränkt werden.

Andre Tenbuss

21. November 2016 um 11:38 Antworten

Hallo Herr Dittrich,

vielen Dank für Ihren Kommentar und Ihre Nachricht. Grundsätzlich unterscheidet sich das Security Audit Log vom Read Access Logging hinsichtlich der Betrachtungsrichtung. Während das Security Audit Log genutzt wird, um Aktivitäten gezielter Nutzer zu protokollieren, wird das Read Access Logging genutzt um generelle Lesezugriffe auf gezielte Daten zu protokollieren. Hier ist die Einschränkung des Security Audit Logs (auf bestimmte Benutzer oder Benutzergruppen) ebenso sinnvoll, wie auch die eingeschränkte Nutzung des Read Access Loggings.

Ihre Kollegen haben Recht mit der Aussage, dass Read Access Logging lediglich für die gezielte Überwachung von ausgewählten Daten vorgesehen ist. Eine Protokollierung aller Datenzugriffe ist hier meiner Meinung nach nicht der stärkste Hebel, unabhängig von der Performance. Viele Unternehmen kämpfen mit den von Ihnen beschriebenen Szenarien, nicht genau zu wissen, welche Daten aus den eigenen Systemen abgezogen werden. Es gibt nun verschiedene Wege und Technologien diesem Problem entgegen zu treten. Ein wichtiger Leitsatz ist hier immer: Prävention ist wichtiger, als Forensik.

Der stärkste Hebel ist in meinen Augen ein gutes Berechtigungskonzept. Frei nach dem Motto Vorsicht ist besser als Nachsicht, ist es einfacher mittels Einschränkung der Berechtigungen z.B. den Export von Daten zu unterbinden. In Grenzfällen lässt sich beispielsweise ein Firefighter-Werkzeug (z.B. SAP GRC 10) für protokollierte Zugriffe auf kritische Transaktionen einsetzen. Hier muss jedoch immer auch abgewogen werden, dass eine große Anzahl an Protokollen auch einen entsprechenden Prüfungsaufwand mit sich bringt. Es gibt nichts schlimmeres, als die Einführung eines solchen Systems ohne entsprechende Kontrolle der Protokolle. Das spricht sich schneller im Unternehmen herum, als viele denken.

Den perfekten Weg, die von Ihnen beschriebenen Punkte in Angriff zu nehmen gibt es leider nicht. Das hat vor allem damit zu tun, wie wertvoll bestimmte Informationen sind bzw. wie kritisch ein Missbrauch dieser Informationen für das Unternehmen wäre. In der Regel versuchen die Unternehmen einen individuellen Break-Even-Point zwischen den Kosten für Maßnahmen zu Steigerung der Sicherheit und den (oft subjektiv bewerteten) Kosten für eintretende Sicherheitsvorfälle zu finden. Das daraus abgeleitete Budget wird dann möglichst sinnvoll zur Steigerung der IT-Sicherheit eingesetzt.

Konnte ich Ihre Fragen beantworten bzw. sind diese Informationen für Sie hilfreich? Kommen Sie gerne auch direkt auf mich zu, wenn Sie weitere Fragen z.B. zum Read Access Logging oder dem Security Audit Log haben. Gerne stehe ich auch für andere Fragen zur IT-Sicherheit zur Verfügung.

Viele Grüße
Andre Tenbuß