Zahlreiche Fälle aus der Vergangenheit zeigen auf, wie wichtig der Schutz der Daten eines Unternehmens vor Missbrauch und Diebstahl ist. In verschiedenen Bereichen eines Unternehmens kann es des Weiteren aus datenschutzrechtlichen Gründen erforderlich sein, Zugriffe auf bestimmte Daten zu überwachen. So müssen z.B. Banken sicherstellen, dass Zugriffe auf sensible Daten nur durch berechtigte Mitarbeiter durchgeführt werden. Auch in Krankenhäusern muss gewährleistet sein, dass auf Patientenakten nur ein bestimmter Personenkreis Zugriff erhält. Zahlreiche weitere Szenarien sind denkbar, die eine Überwachung definierter Daten erforderlich machen. Grundsätzlich dreht es sich in vielen Fällen um das Recht auf informationelle Selbstbestimmung oder den Schutz der Privatsphäre von Kunden und Patienten. Gesetzlich ist unter Umständen außerdem vorgeschrieben, dass auch Lesezugriffe auf sensible Daten nachweisbar protokolliert werden.
SAP Read Access Logging
Die SAP bietet Kunden mit dem Read Access Logging eine technische Möglichkeit die lesenden Zugriffe auf definierte Daten zu protokollieren. Während Änderungen immer schon in den Änderungsbelegen protokolliert wurden, war dies bisher ohne zusätzliche Anwendungen oder kundenindividuelle Entwicklungen für Lesezugriffe nicht der Fall. Read Access Logging ermöglicht eine flexible Konfiguration der Protokollierungsregeln sowie der Aufbewahrungsrichtlinien. Neben einer grundlegenden Auswertungsanwendung besteht außerdem die Möglichkeit über eine Schnittstelle (API) die Protokolle automatisiert auswerten zu lassen. Dabei steht es dem Unternehmen frei die Regeln so zu definieren, dass lediglich der Lesezugriff auf die Daten durch einen Benutzer protokolliert wird oder zusätzlich auch die angezeigten Daten.
Hervorzuheben ist bei dem Read Access Logging Framework, dass die Protokollierungsregeln nicht nur auf Datenbank- oder Feld-Ebene definiert werden können. So ist beispielsweise sogar eine Einschränkung auf Basis des Feldinhalts möglich, um nur Lesezugriffe auf einige definierte Datensätze einer Tabelle zu protokollieren.
In dem Strategieworkshop SAP Berechtigungen entwickeln wir für Sie eine Strategie zur Optimierung der SAP Sicherheit und Reduzierung der Betriebsaufwände.
Voraussetzungen und Einschränkungen für RAL
Eingeführt wurde das Read Access Logging mit dem SAP NetWeaver Application Server (ABAP) 7.40 SP02. SAP gibt in der Liste der bisher für die Lesezugriffsprotokollierung unterstützten Kanäle (Zugriffstechnologien) Remote Function Calls (RFC), Web-Dynpro-Applicationen und Web-Service-Aufrufe an. Dabei können bei RFC-Verbindungen sowohl server- als auch clientseitige Zugriffe protokolliert werden. Bei Web-Service-Aufrufen können außerdem sowohl die Daten der Anfrage als auch die zurückgelieferten Daten überwacht werden. Im Web-Dynpro-Bereich können alle kontextgebundenen Datenelemente überwacht werden. Eine Einschränkung gibt es hier lediglich bei den Elementen der F4-Hilfe, welche nicht mitprotokolliert werden können.
Was in der Zukunft geplant ist
Möglicherweise fragen Sie sich nun, wann die Liste der unterstützten Kanäle erweitert wird. Die SAP gibt an, dass für das SAP NetWeaver AS ABAP 7.40 SP04 bereits fest die Unterstützung eines ABAP-Dynpro-Kanals geplant ist. Weitere Kanäle werden dann ab SP05 folgen.
Planen Sie den Einsatz von Read Access Logging oder setzen Sie das Werkzeug bereits ein? Welche Erfahrungen haben Sie mit Anwendungen zur Lesezugriffsprotokollierung gemacht? Ich freue mich auf Ihre Kommentare und Anregungen.
5 Kommentare zu "Lesezugriffe in SAP Systemen mit Read Access Logging (RAL) protokollieren"
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.
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.
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ß
Hallo Herr Tenbuß,
gibt es auch die Möglichkeit neben den SOAP Web Services auch die REST Web Services aus der Transaktion SICF zu loggen?
Viele Grüße,
Erwin Wittmann
Hallo Herr Wittmann,
ich habe bei unseren Experten nachgefragt: Die Antwort ist davon abhängig, was mit dem Logging erreicht werden soll. Ggf. könnte die Richtung ICM-Logging hilfreich sein.
Viele Grüße aus der RZ10-Redaktion