Suche
Close this search box.

Warum ist die Änderungsprotokollierung mittels Audit Logging in der SAP HANA Datenbank so wichtig?

Die Protokollierung in SAP HANA ist mindestens genauso wichtig wie in anderen Applikationen auch. Sie dient der Nachvollziehbarkeit von Änderungen jeglicher Art. Diese können einerseits aus Sicht der finanziellen Rechnungslegung, aufgrund regulatorischer Anforderungen oder aus operativen Gründen relevant sein. Insbesondere in den letzten Jahren ist eine zunehmende Sensibilisierung für Cybersecurity Risiken zu beobachten.

In SAP HANA ist standardmäßig die Änderungsprotokollierung inaktiv. Sie müssen zudem individuell definieren, was protokolliert werden soll. Außerdem muss dabei auch der Speicherort der Protokolle und die Verfahrensweise mit den protokollierten Ereignissen definiert werden. Nicht zuletzt zu Revisionszwecken muss eine angemessene Protokollierung sichergestellt sein, um Kontrollnachweise erbringen zu können. Im Mittelpunkt stehen allen voran kritische Aktivitäten, die unmittelbaren Einfluss auf die Datenintegrität und -konsistenz haben können. Aus Kontrollsicht lassen sich die Aktivitäten wie folgt untergliedern:

Abbildung 1: kritische Aktivitäten aus Kontrollsicht

Was ist für die Protokollierung relevant?

Ein Berechtigungskonzept ist das zentrale Element für bspw. die Zugriffsverwaltung oder Verantwortlichkeiten bei der Berechtigungsvergabe. Alle Operationen, welche Rollen oder Privilegien vergeben, sind grundsätzlich relevant, um deren Angemessenheit beurteilen zu können. Nicht sachgemäße Berechtigungen stellen immer ein Risiko dar, wenn diese über den eigentlichen Verantwortungsbereich des Anwenders hinausgehen. Programmtechnische Änderungen können u. a. direkt in der Produktion erfolgte Modifikationen an Objekten des SAP HANA Repository sein. Dabei ist nicht auszuschließen, dass folglich Änderungen ohne ausreichende Tests und möglicherweise ohne Freigabe vorgenommen werden. In der Konsequenz kann dies negative Effekte auf die Datenverarbeitung haben. Gleich verhält es sich mit Änderungen der Systemkonfiguration, einschließlich der Protokollierung selbst, mit potentiellen Auswirkungen auf den Betrieb der SAP HANA Datenbank.

Eine höhere Gewichtung ist inzwischen den Cybersecurity Risiken beizumessen. Unternehmen sind häufiger denn je Ziele von bspw. externen Angriffen, bei denen sensible Daten gestohlen oder gar manipuliert werden. Das gefährdet nicht nur die Reputation des Unternehmens, sondern kann auch größeren Schaden verursachen und sich auf die Business Continuity auswirken. Entsprechend wichtig sind Abwehrmaßnahmen, die in Echtzeit Unregelmäßigkeiten identifizieren (z. B. mit SAP Enterprise Thread Detection) und ein rasches Handeln ermöglichen. Die Grundlage sind dafür einerseits definierte Muster, andererseits die Logs. Dazu zählt natürlich das SAP HANA Audit Log als eine von vielen Quellen.

Audit Logging – was ist (technisch) möglich, was nicht

Beim SAP HANA Audit Logging wird zwischen dem Audit Log und den Audit Policies unterschieden. Das Audit Log ist das Änderungsprotokoll mit allen Ereignissen wie sie gemäsß Audit Policies aufgezeichnet werden. Mit Hilfe von Audit Policies lässt sich sehr präzise definieren, welche Ereignisse für die Protokollierung relevant sind. Seien es Änderungen von Objektdefinitionen, wie Tabellen, Views und Prozeduren, klassische Datenmanipulationen von Tabelleneinträgen oder Änderungen betrieblicher Natur (z. B. Sicherheitsparameter, Berechtigungen, Lizenzierung, oder Backup). Mittlerweile sind dem fast keine Grenzen mehr gesetzt, was zu protokollieren ist. Audit Policies können einzeln aktiviert oder deaktiviert werden. Sie erfassen nebst erfolgreich ausgeführten Aktivitäten auch nicht ausgeführte Aktivitäten. Das kann vor allem im Cybersecurity-Umfeld für die Authentifizierung (d. h. CONNECT Statement) interessant sein. Weiterhin lässt sich in Audit Policies ein Kontext definieren, d. h. das relevante SQL Schema oder Objekt sowie Benutzer. Die protokollierten Ereignisse werden auf Basis des „Audit Levels“ klassifiziert, was für die Verarbeitung in einem Security Incident und Event Management (SIEM) Tool nützlich ist. Die Ablage wird mittels Audit Trail konfiguriert – sei es das syslog, ein csv File oder – wie für Tenants standardmäßig ausgewählt – eine Datenbanktabelle.

Jedoch gibt es auch Situationen bzw. Szenarien, die technisch bedingt keine Protokollierung erlauben. Dies sind typischerweise Operationen die nicht während der Laufzeit der SAP HANA Datenbank erfolgen. Im Wesentlichen unterscheidet man hierbei in folgende 3 Typen:

  • Upgrade einer SAP HANA-Instanz
  • Direkte Änderungen in der Systemkonfiguration auf OS Level 
  • Änderungen vom SYSTEM Benutzer Passwort in der SYSTEMDB (wenn sich der “nameservers” im emergency mode befindet)

Wie das Audit Logging aktiviert wird

Grundsätzlich gibt es mehrere Wege, um die Audit Policies zu konfigurieren:

  • SAP HANA Cockpit
  • SAP HANA Studio
  • Web-based Development Workbench
  • HDBSQL

Als zentrale Administrationsoberfläche verwenden heute Unternehmen meist das SAP HANA Cockpit. Inzwischen liefert SAP auch vordefinierte Audit Policies aus, welche sich im SAP HANA Cockpit unvermittelt übernehmen, anpassen oder erweitern lassen. Es sollte dabei aber immer nochmals geprüft werden, ob diese Audit Policies den eigenen Anforderungen genügen. Eine weitere Möglichkeit ist die direkte Ausführung eines CREATE AUDIT POLICY SQL Statements, sei es mittels Secure Shell (ssH) oder im SAP HANA Database Explorer.

Das SAP HANA Studio und die Web-based Development Workbench (ehemals Web IDE) sind grundsätzlich ebenfalls nützliche Tools für die Audit Konfiguration. Allerdings ist unlängst bekannt, dass das SAP HANA Repository und folglich XS Classic Anwendungen und das SAP HANA Studio obsolet sind und nicht mehr weiterentwickelt werden.

Weitere Informationen sind unter SAP Note 2465027 – Deprecation of SAP HANA extended application services, classic model and SAP HANA Repository zu finden.

Was ist Best Practice für die Audit Konfiguration?

Zuallererst sollten grundsätzlich die Zuständigkeiten für die Pflege der Audit Konfiguration (Systemprivileg AUDIT ADMIN) und Pflege des Audit Logs (Systemprivileg AUDIT OPERATOR) voneinander getrennt sein aufgrund des vorliegenden Funktionstrennungskonflikts. Seit SAP HANA 2.0 SPS04 gibt es das neue Systemprivileg AUDIT READ für die Auswertung des Audit Logs.

Die Ablage des Audit Logs sollte immer datenbankspezifisch im selbigen Tenant erfolgen. Im produktiven Tenant ist üblicherweise bereits ein Berechtigungskonzept vorhanden, das bereits einen angemessenen Zugriffsschutz gewährleistet. Außerdem werden Änderungen an der Audit Konfiguration über die Mandatory Self-Auditing Policy aktiviert. Dies ist die einzige Audit Policy, die nicht explizit aktiviert werden muss, sondern immer im Hintergrund aktiv ist.

Vor allem bei Landschaften mit mehr als einem Tenant in einer Instanz besteht die Möglichkeit einzelne Parameter der Audit Konfiguration (wie z. B. das Audit Trail) zentral in der SYSTEMDB zu pflegen. Das bedeutet allerdings nicht, dass Audit Policies zentral für alle Tenants aktiviert werden können. Das muss weiterhin in den Tenants selbst erfolgen.

Welche Audit Policies in der Produktion aktiv sein sollten

Um den zu Beginn erläuterten Anforderungen gerecht werden zu können, sollten, wie unten dargestellt, mindestens folgende Audit Policies in der Produktion aktiv sein. Weitere Audit Policies können situationsbedingt erforderlich sein.

Abbildung 2: Eigene Darstellung der Audit Policies sowie ihr Zweck der Protokollierung

Im speziellen Fall der Tabellenänderungen ist es wichtig, dass Sie das richtige ABAP-Datenbankschema spezifizieren sowie explizit den technischen Schnittstellenbenutzer für die Produktivdaten ausschließen. Somit ist sichergestellt, dass jede Datenmanipulation innerhalb jenes Schemas erfasst wird, jedoch nicht solche, die über die ABAP-Applikation erfolgen. Die Konsequenz wäre sonst zwangsläufig ein schnell überfülltes Audit Log. Der Schnittstellenbenutzer selbst kann nicht protokolliert werden, da in Audit Policies bisher nur der Datenbankbenutzer explizit angegeben werden kann, jedoch kein Applikations- oder XS-Benutzer (obwohl diese mit protokolliert werden).

Wie Xiting Ihnen weiterhelfen kann

Wenn beispielsweise aus operativen Gründen der SYSTEM Benutzer weiter verwendet wird oder die Berechtigungsadministration und Fehleranalyse in der SAP HANA Datenbank eine Herausforderung ist, unterstützen wir Sie gerne mit unserer Softwarelösung Xiting Authorizations Management Suite (XAMS) und stellen Ihnen die notwendigen Hilfsmittel in Ihrer gewohnten Umgebung zur Verfügung. Dies sind zum Beispiel:

Abbildung 3: Unterstützung der XAMS im Bereich SAP HANA

Erst mit dem Release des Service Pack 16 der XAMS wurden weitere Berichtsfunktionalitäten zur Auditkonfiguration zur Verfügung gestellt:

Abbildung 4: Berichtsfunktion zur Auditkonfiguration in XAMS mit Service Pack 16

Xiting besitzt ebenfalls mehrjährige Erfahrung in der Implementation von SAP HANA-Berechtigungskonzepten. Ein Bestandteil davon ist ebenso die Definition und Aktivierung von SAP HANA Audit Policies.

Haben wir Ihr Interesse geweckt? Zögern Sie nicht uns zu kontaktieren und wir erzählen Ihnen gern mehr. Weitere Informationen finden Sie in den Xiting SAP HANA Services.

Weitere Informationen zum Auditing in SAP HANA finden Sie unter SAP Note 2499866 – Auditing Activity in SAP HANA Systems – SAP ONE Support Launchpad.

Erik Trouillet
Kontakt

Nehmen Sie Kontakt mit uns auf!

Haben Sie Fragen zu unseren Produkten?

+41 43 422 8803
[email protected]
+49 7656 8999 002
[email protected]
+1 855 594 84 64
[email protected]
+44 1454 838 785
[email protected]
Kontakt
Webinare

Besuchen Sie unsere Live-Webinare und lernen Sie von unseren Experten mehr zu SAP-Berechtigungen, XAMS, SAP IDM und zu vielen weiteren Themen im Kontext von SAP Security.

Hier anmelden