Digitale Finanztransformation im Finanzwesen

Die digitale Transformation erreicht das Finanzwesen – mit KI-gestützten Zukunftsprognosen oder neuen Technologien, etwa um Entscheidungsszenarien zu simulieren.

Derzeit ist das Finanzwesen jedoch häufig noch von wiederkehrenden manuellen Aufgaben geprägt und selten auf proaktive Unterstützung unternehmerischer Entscheidungen ausgerichtet. Dadurch sind viele Expert*innen durch Routinetätigkeiten gebunden und stehen für wichtigere Aufgaben nicht zur Verfügung.

Eine Automatisierung kann im Rahmen einer Digitalisierungsstrategie Raum für wertschöpfende Tätigkeiten schaffen. Um von einem reaktiven zu einem proaktiven Finanzmanagement zu gelangen, sind jedoch durchgängige Konzepte, integrierte Systeme und vor allem eine neue Datenkultur gefragt.

Insbesondere beim Thema digitale Finanztransformation kommt es darauf an, die Entwicklungsstufen auf dem Weg in die Zukunft strukturiert und in einer logisch aufbauenden Reihenfolge zu beschreiten. Denn wenn die Basis nicht sauber umgesetzt ist, funktionieren später zum Beispiel intelligente Analysen nicht.

Die 4 Dimensionen der digitalen Finanztransformation

Die erste Dimension – Financial Platform

Die Grundlagen der Finanzbuchhaltung sind in erster Linie gesetzlicher und damit auch steuerrechtlicher Natur. Diese Basis wird durch die Finance Module und dessen Funktionsumfang heute zuverlässig im Standard abgebildet.

Dennoch gibt es eine Reihe digitaler Einstiegspunkte in Basis Finanzprozessen, wie z.B. automatisierte Verarbeitung von Eingangs- und Ausgangsrechnungen, Intelligente, prognosebasierte Cashflow-Steuerungsmodule, integrierte Forecast- und Budgetplanungen oder die Integrationen von Online-Kreditlimit-Prüfungen können die Basisprozesse erweitern. In den meisten Unternehmen werden diese Lösungen bislang jedoch nur vereinzelt umgesetzt.

Ein weiterer Ausbau dieser neuen Prozesse würde jedoch Kosten oder Außenstände deutlich reduzieren und Aufarbeitungszeit für Monats- und Jahresabschlüsse spürbar reduzieren.

Die zweite Dimension – Datenintegration über Datenplattformen

In den Bereichen Vertrieb, Produktion, E-Commerce oder Service entstehen heute Daten für die Kosten- und Leistungsrechnung wesentlich sind und daher zusammengeführt werden müssen. Häufig begnügt sich das Finance & Controlling noch mit komprimierten Datenexporten auf Basis finanzbuchhalterischer Sachdimensionen und verzichten dabei auf tiefergreifende Details.

Sind jedoch die wesentlichen Daten nicht synchronisiert, macht sich dies beispielsweise in einer Differenz zwischen buchhalterischen und tatsächlichen Lagerbestand bemerkbar. Ungeachtet des Erklärungsbedarfs im Rahmen des Jahresabschlusses ergeben sich daraus oft weitere Probleme. Dazu gehören etwa ein hoher Aufwand für Abgleich und Korrektur, falsche Disposition und Warenbestellungen.

Ein unternehmensweit einheitliches Business Intelligence (BI)-System könnte solche Schwierigkeiten per Mausklick aus der Welt schaffen. Hierzu ist jedoch eine einheitliche Datenbasis für alle Unternehmensbereiche notwendig, als zentraler, validierter Datenpool, auf den alle Auswertungen der Fachbereiche in Zukunft laufen. Für viele Unternehmen ist es daher an der Zeit, Initiative zu ergreifen und die unterschiedlichsten Ansätze in diese Richtung zu lenken.

Die dritte Dimension – Data Analytics

Das Ziel der meisten Unternehmen besteht darin, Unsicherheiten in der Planung zu reduzieren und vorausschauende Prognosen zu treffen.

Planung bedeutet also Unsicherheiten zu minimieren und die Zukunft so realitätsnah wie möglich zu antizipieren. In diesem Kontext zielt der Begriff „vorausschauende Planung“ darauf ab, die Sicherheit und Exaktheit der Unternehmensplanung durch den Einsatz datengetriebener Analyseverfahren weiter zu erhöhen.

Dabei ist das Ziel die Integration aller Teilplanungen in eine automatisierte integrierte Unternehmensplanung, die ein konsistentes Szenario über alle Teilbereiche hinweg ermöglicht. Diese Form des Planungsmodells gilt heute als State-of-the-Art in der Unternehmensplanung.

Ein modernes Planungsmodell zeichnet sich dadurch aus, dass es neben internen auch externe Einflussfaktoren einbezieht. Hierzu zählen aktuelle Konjunkturdaten der Absatzmärkte, Marktforschungsdaten, Rohstoffpreisänderungen, Modellwechsel beim Wettbewerber oder politische Einflussfaktoren.

Bei Predictive Analytics werden historische Unternehmensdaten, teils unter Hinzunahme externer Informationsquellen und Einflussfaktoren, auf wiederkehrende Muster und Zusammenhänge untersucht. Damit lässt sich die Entwicklung wichtiger Unternehmenskennzahlen, wie etwa Produktabsatz oder Umsatz, wesentlich genauer prognostizieren. Hierbei erkennt künstliche Intelligenz nicht nur Muster in komplexen Datenbeständen, sondern ist darüber hinaus auch in der Lage, auf Basis der gesammelten Erkenntnisse neue Prognosen zu erstellen.

Die vierte Dimension – Prozessautomatisierung

Durch die erhöhte Anzahl der zu integrierenden Datentöpfe und komplexen Prozessen, steigt allerdings auch die Notwendigkeit zur Automatisierung dieser Prozesse.

Die Automatisierungen sorgen für einen sicheren Datenaustausch zwischen den Systemen und deren kontinuierlichen Abgleich. Da häufig geeignete Werkzeuge fehlen oder unzureichend sind, verwenden viele Controller*innen einen großen Teil ihrer Arbeitszeit dafür, Informationen zu konsolidieren und manuell Daten zu vergleichen. Sofern es gelänge, diese Vorgänge zu automatisieren, entstünde mehr Raum für Aufgaben, die einen Mehrwert bringen, um Strategien zu entwickeln und laufend zu überwachen.

Ein vielversprechender Ansatz ist die Robotic Process Automation (RPA). Dabei übernimmt ein Software-Roboter typische wiederkehrende Arbeitsschritte eines Mitarbeiters. Zum Beispiel dort, wo eine direkte Systemanbindung nicht möglich ist. RPA eignet sich generell, um Daten aus Altsystemen auszulesen oder um Datenexporte zu automatisieren, wie etwa für X-Rechnungen und deren automatisierten Versand.

Waren bisher vor allem statische, stark regelgebundene Prozesse automatisierbar, lassen sich mit KI-Technologien wie Text-, Sprach- oder Bilderkennung nun auch variantenreiche und dynamische Prozesse automatisieren.

Nachteile der digitalen Belegverarbeitung

Obwohl die digitale Belegverarbeitung viele Vorteile und Einsparungen bietet, gibt es auch Nachteile, über die sich jedes Unternehmen, dass sich mit dem Thema Digitalisierung beschäftigt, im Klaren sein sollte.

Je nach System und Unternehmensgröße ist die Umstellung auf eine digitale Buchhaltung mit einem nicht unerheblichen Zusatzaufwand verbunden. Hierbei besteht die größte Herausforderung darin, eingefahrene Routinen und langjährig bestehende Prozesse aufzubrechen und neu zu definieren.

Grundsätzlich müssen Mitarbeiter frühzeitig in die Planungen eingebunden werden und die Gelegenheit erhalten in das neue System hineinwachsen. Dies gilt insbesondere für ältere Mitarbeiter, um mögliche Ängste oder sogar Ablehnung gegenüber dem neuen System vorzubeugen. Hierzu müssen alle neuen Abläufe intensiv geschult und insbesondere in der Anfangsphase sorgsam kontrolliert werden. Dabei ist Geduld und Stehvermögen sehr wichtig, da sich der Aufwand nach der Einführung und Einarbeitungszeit erst langfristig bemerkbar machen wird. Aufkommende Fragen lassen sich in dieser Zeit meist durch den Anbietersupport schnell beantworten.

Da gemäß (GoBD) alle Buchhaltungsdokumente für einen Zeitraum von 10 Jahren aufzubewahren sind und im Bedarfsfall schnell zugreifbar sein müssen, ist häufig auch die Anschaffung neuer Hard- und Softwarelösungen notwendig.

Hinzu kommen gesetzliche Sicherheitsanforderungen für die Datenverarbeitung hinsichtlich Schutz der Daten insbesondere vor Verlust, Manipulation, Hackerangriffen und unbefugtem Zugriff mit der Notwendigkeit von entsprechenden weiteren Investitionen in leistungsfähige und erprobte Firewall- sowie Backup- und Recovery-Lösungen.

Trotz der beschriebenen Nachteile hat die Umstellung auf eine digitale Belegverarbeitung auf lange Sicht die besseren Perspektiven, als das gute alten Papier und der Ordner im Schrank.

Das papierlose Büro ist nur eine Frage der Zeit – erfordert aber ein Umdenken

Die Vorteile einer papierlosen elektronischen Belegverarbeitung sind überzeugend:

    • Reduzierung der Kosten für das Unternehmen durch Einsparung von Arbeitszeit, Büromaterial und Porto
    • Reduzierung der Steuerberaterkosten durch weniger Sortier-, Schreib- und Abstimmaufwand
    • Konkurrenzvorteil gegenüber Mitbewerbern

Dennoch will niemand bei der Umstellung auf papierlose Lösungen der Erste sein – weder Unternehmen noch Steuerberater. Oft herrscht immer noch die Meinung vor, dass die Buchhaltung seit vielen Jahren so gemacht wird und das auch so bleiben wird.

Dabei sind heute bereits alle gesetzlichen und technischen Hürden genommen worden und interessante Lösungen verfügbar. Zudem fordert die neue Buchhaltungsrichtlinie GoBD sogar explizit die papierlose Archivierung, was derzeit aber häufig noch ignoriert wird.

Dennoch sehen derzeit noch viele Unternehmen davon ab, diesen Weg zu gehen, denn das papierlose Büro, bei dem sämtliche Arbeitsprozesse der Buchhaltung auf rein digitalem Weg organisiert und gespeichert werden, erfordert auch eine Umstellung und Modernisierung bestehender Prozesse. Hier ist ein Umdenken dringend erforderlich.

Die Vorteile der digitalen Belegverarbeitung

In den meisten Unternehmen werden heute immer noch Ausgangsrechnungen ausgedruckt und per Post zum Empfänger geschickt, der die Rechnung dann häufig wieder einscannt, um sie zu archivieren. Und dies obwohl der Weg, die Verwaltungs- und Buchhaltungsprozesse in eine rein digitale Welt zu bringen, vom Gesetzgeber bereits geebnet und ja sogar gefordert wurde. So sind im Umsatzsteuergesetz und in den GoBD die Pflichten von Unternehmen genau festgelegt, welche auf papierlose Rechnungslegung umstellen wollen.

Die wichtigsten Gründe für Unternehmen auf digitalisierte Verwaltungsprozesse umzustellen lauten:

    • Kostenersparnis bei Büromaterial, Lagerräume und Transportkosten
    • Zeitersparnis bei der Erfassung und Buchung der Belege durch OCR-Texterkennung
    • Kosten- und Zeitersparnis durch Verminderung von Recherche- und Suchaufwänden als Folge der digitalen Verfügbarkeit
    • Freiwerdende Personalkapazitäten können an anderer Stelle gewinnbringend eingesetzt werden
    • Verfügbarkeit von Belegen und Daten zu jeder Zeit und an jedem Ort
    • Optimierte Workflows machen sich sowohl intern als auch extern bei Dienstleistern bemerkbar z.B. beim digitalen Austausch der Unterlagen mit dem Steuerberater oder dem Buchhaltungsbüro
    • Zudem lässt sich auch die Kommunikation mit Kunden, Partnern und Lieferanten in papierloser Form zeitgemäßer gestalten

Vorüberlegungen zur Umstellung auf die digitale Belegverarbeitung

Im Rahmen der Vorüberlegungen zur Umstellung auf die digitale Belegverarbeitung sollte zunächst immer geprüft werden, wo die papierlosen Belege zukünftig verarbeitet, archiviert und gesichert werden sollen – lokal oder in der Cloud.

Soll dies lokal geschehen, ist häufig auch die Anschaffung neuer Hard- und Softwarelösungen notwendig, da alle Buchhaltungsdokumente gemäß (GoBD) für einen Zeitraum von 10 Jahren aufzubewahren sind und im Bedarfsfall schnell zugreifbar sein müssen.

Hinzu kommen gesetzliche Sicherheitsanforderungen für die Datenverarbeitung hinsichtlich Schutz der Daten insbesondere vor Verlust, Manipulation, Hackerangriffen und unbefugtem Zugriff mit der Notwendigkeit von entsprechenden weiteren Investitionen in leistungsfähige und erprobte Firewall- sowie Backup- und Recovery-Lösungen.

Sofern die notwendige IT-Infrastruktur noch nicht vorhanden ist, kann dies ein Unternehmen insbesondere, wenn kein eigenes IT-Personal beschäftigt wird, schnell überfordern oder unangemessene Kosten verursachen.

In diesem Fall ist eine Online Buchhaltungslösung in der Cloud als die bessere Alternative anzusehen. Eine solche Online Buchhaltung, die über einen normalen Webbrowser bedient wird, ist schnell eingerichtet. Für den Aufbau und den Betrieb der notwendigen IT-Infrastruktur sorgt der jeweilige Anbieter. Hierzu gehört auch die regelmäßige Sicherung der Daten. Zur Erhöhung der eigenen Sicherheit ist es jedoch immer ratsam seine gesamten Buchhaltungsdaten regelmäßig komplett herunterzuladen und nochmals lokal zu sichern. Zudem sollte darauf geachtet werden, dass die Server in Deutschland stehen und nur eine verschlüsselte Datenübertragung zulassen.

Vor diesem Hintergrund sollte genau überlegt werden für welche Form der digitale Belegverarbeitung – lokal oder in der Cloud – man sich entscheidet.

Vorschriften zur digitalen Belegverarbeitung

Eine digitale Belegverarbeitung muss zwingend den Grundsätzen zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) entsprechen.

Hierzu hat das Bundesministerium der Finanzen (BMF) am 14.11.2014 ein Schreiben verfasst, das für Veranlagungszeiträume gilt, die nach dem 31. Dezember 2014 beginnen. Einige wichtige Vorschriften hieraus lauten:

    • Unbare Geschäftsvorfälle wie Ein- und Ausgangsrechnungen sind zeitnah, d.h. hier innerhalb von zehn Tagen, zu erfassen. (vgl. hierzu Tz. 47)
    • Elektronische Belege müssen nach bestimmten Ordnungsprinzipien geordnet sein und gemäß der gesetzlichen Fristen aufbewahrt werden. (vgl. hierzu Tz. 54)
    • Belege in Papierform oder in elektronischer Form sind zeitnah, d.h. möglichst unmittelbar nach Eingang oder Entstehung gegen Verlust zu sichern (vgl. hierzu Tz. 67)
    • Sind aufzeichnungs- und aufbewahrungspflichtige Daten, Datensätze, elektronische Dokumente und elektronische Unterlagen im Unternehmen entstanden oder dort eingegangen, sind sie auch in dieser Form aufzubewahren und dürfen vor Ablauf der Aufbewahrungsfrist nicht gelöscht werden. (vgl. hierzu Tz. 119)
    • Der Verzicht auf einen Papierbeleg darf die Möglichkeit der Nachvollziehbarkeit und Nachprüfbarkeit nicht beeinträchtigen. (vgl. hierzu Tz. 141)
    • Für den Zeitraum der Aufbewahrungsfrist muss gewährleistet und nachgewiesen sein, dass das in der Dokumentation beschriebene Verfahren dem in der Praxis eingesetzten Verfahren voll entspricht. (vgl. hierzu Tz. 154) Die Verfahrensdokumentation hat folgende Punkte zu enthalten:
      • Aufzeichnungen zum internen Kontrollsystem
      • Konzept der Datensicherung
      • Abkürzungsverzeichnis in der Finanzbuchhaltung
      • Dokumentation von System- und Verfahrensänderungen
      • eingesetzte Software
    • Positivtestate zur Ordnungsmäßigkeit der Buchführung und damit zur Ordnungsmäßigkeit DV-gestützter Buchführungssysteme werden weder im Rahmen einer steuerlichen Außenprüfung noch im Rahmen einer verbindlichen Auskunft erteilt. Somit können alle auf dem Markt verfügbaren Systeme genutzt werden. (vgl. hierzu Tz. 180)

Die Angaben in Klammern beziehen sich auf die Textziffern des oben genannten BMF-Schreibens vom 14.11.2014 zu den GoBD.

Neufassung der GoBD vom 28. November 2019

Das Bunderministerium für Finanzen (BMF) hat die seit 2014 geltenden GoBD aktualisiert. Die neuen Regelungen gelten ab dem 1.1.2020, können freiwillig aber auch schon früher angewendet werden.

Bereits im Juli 2019 hatte das BMF eine aktualisierte Fassung der GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) veröffentlicht, dieses Schreiben aber „aufgrund weiteren Abstimmungsbedarfs“ wieder zurückgezogen. Mit dem BMF-Schreiben vom 28.11.2019 wurden die geänderten GoBD nun offiziell neu gefasst.Für die Steuerpflichtigen ergeben sich durch die GoBD-Überarbeitung fast ausschließlich Verbesserungen und Klarstellungen im Vergleich zum BMF-Schreiben aus dem Jahr 2014.

 

Die Neufassung der GoBD zum 1.1.2020 berücksichtigt, dass sich seit der Erstveröffentlichung die digitalen Möglichkeiten weiter verändert haben, u.a:

    • Abfotografieren von Belegen mit Smartphones ist nun ausdrücklich erlaubt (dies gilt auch für Belege, die im Ausland entstanden sind bzw. wenn die Buchführung ins Ausland verlagert wurde).
    • Bei der Definition von DV-System findet nun auch die Cloud-Technologie Berücksichtigung.

Bei der Umwandlung von Belegen in ein Inhouse-Format führen die neuen GoBD eine Erleichterung ein. Unter folgenden Voraussetzungen kann auf die Aufbewahrung der Ursprungsfassung (wie bisher erforderlich) verzichtet werden:

    • Es wird keine bildliche oder inhaltliche Veränderung vorgenommen.
    • Bei der Konvertierung gehen keine sonstigen aufbewahrungspflichtigen Informationen verloren.
    • Die ordnungsgemäße und verlustfreie Konvertierung wird dokumentiert (Verfahrensdokumentation).
    • Die maschinelle Auswertbarkeit und der Datenzugriff durch die Finanzbehörde werden nicht eingeschränkt; dabei ist es zulässig, wenn bei der Konvertierung Zwischenaggregationsstufen nicht gespeichert, aber in der Verfahrensdokumentation so dargestellt werden, dass die retrograde und progressive Prüfbarkeit sichergestellt ist.

Die wesentlichen Änderungen umfassen im Einzelnen:

    • Bildliche Erfassung durch mobile Geräte zulässig
      Durch den neuen, einheitlichen Begriff „bildliches Erfassen“ (statt bisher „Scannen“) wird aktuellen technischen Entwicklungen zum Fotografieren Rechnung getragen. Damit existieren nun auch die notwendigen Rahmenbedingungen für ein mobiles ersetzendes Scannen. Derartige Fotografien dürfen (trotz weiterhin bestehender Datenlokalisationsvorschriften wie § 146 Abs. 2 AO) auch im Ausland erstellt werden. Eine Verfahrensdokumentation ist weiterhin notwendig.
    • Werden Originaldateien in Inhouse-Formate konvertiert, müssen die ursprünglichen Dateien nicht mehr aufbewahrt werden
      Wurden früher Originaldateien in eigene Formate umgewandelt, mussten beide Versionen aufbewahrt werden; die konvertierte Version musste zudem als solche gekennzeichnet werden. Nach den neuen GoBD, Rz. 135, ist dies nun nicht mehr erforderlich, sofern die konvertierte Datei maschinell ausgewertet werden kann. Auch hier muss eine entsprechende Verfahrensdokumentation vorgelegt werden.
    • Aufbewahrung der strukturierten Daten anstelle der bildhaften Dokumente bei so genannten „Mehrstücken“ ausreichend
      Werden beispielsweise über eine Banking- oder Zahlungsdienstschnittstelle strukturierte Daten (Kontoeinzelumsätze) abgerufen, reicht die Aufbewahrung dieser strukturierten Daten aus. Inhaltsgleiche bildhafte Dokumente, z. B. PDF-Kontoauszüge oder E-Mails mit Umsatzübersichten, müssen nicht mehr aufbewahrt werden. Voraussetzung ist jedoch, dass sich die strukturierten Daten mindestens genauso gut auswerten lassen wie das bildhafte Belegdokument.Bei der Aufbewahrung von Hybrid-Formaten wie ZUGFeRD kommt es auf die tatsächliche Verarbeitung an. Wird die XML-Datei weiterverarbeitet, hat sie Belegfunktion und unterliegt der Aufbewahrungspflicht. In diesem Fall reicht es, die XML-Datei aufzubewahren. Werden jedoch die nachgelagerten Prozesse durch das bildhafte Dokument (PDF) belegt, müssen für Zwecke der maschinellen Auswertbarkeit beide Formate (PDF + XML) vorgehalten werden.
    • Fokus auf Einzelaufzeichnungspflicht und zeitgerechtes Buchen
      Im Hinblick auf die gesetzliche Pflicht zur Einzelaufzeichnung von baren Geschäftsvorfallen werden die Grundsätze zur Einzelaufzeichnungspflicht und zum zeitnahen Buchen in der Neufassung der GoBD nochmals explizit erwähnt. Es wird aber auch klargestellt, dass bare und unbare Geschäftsvorfälle kurzzeitig gemeinsam in einem Grundbuch festgehalten werden können, was insbesondere für Betriebe mit gemischten Zahlungsarten (z. B. Restaurants, Hotels) eine Erleichterung darstellt.
    • Aufbewahrungsvorschriften bei Systemmigrationen abgemildert
      Sofern noch nicht mit der Außenprüfung begonnen wurde, ist es im Falle eines Systemwechsels oder der Auslagerung von aufzeichnungs- und aufbewahrungspflichtigen Daten aus dem Produktivsystem ausreichend, wenn nach Ablauf des fünften Kalenderjahres, das auf die Umstellung folgt, nur noch der Z3-Zugriff (= Datenträgerbereitstellung) zur Verfügung gestellt wird.
    • Klarstellung zu Stornobuchungen
      Ursprüngliche Buchung und Stornobuchung im Buchführungssystem müssen verpflichtend aufeinander referenziert werden.

Weitere Informationen finden sich im BMF-Schreiben vom 28.11.2019 und weitere Erläuterungen im BMF, Schreiben v. 28.11.2019, IV A 4 – S 0316/19/10003 :001

Database Activity Monitoring zum Schutz vor Datenmissbrauch

Beim Database Activity Monitoring handelt ist sich um die Aufzeichnung und Analyse von Ereignissen oder Statistiken auf den Datenbanksystemen, um Informationen über die Systemnutzung und Performance in einer sauberen und verständlichen Form darzustellen. Das Ziel eines Database Activity Monitoring Systems ist die Erkennung von Sicherheits- oder Complianceverletzungen sowie die Formulierung von Empfehlungen zur Verbesserung der Administration, der Security und der Umsetzung von Complianceanforderungen

Database Activity Monitoring ist ein generelles Verfahren, um eine unabhängige Prüfung und Auswertung von verarbeiteten Daten und Aktivitäten zu ermöglichen. Dieses Verfahren wurde entwickelt, um nachfolgende Funktionen zur Verfügung zu stellen:

    • Sicherstellung der Erfüllung von Complianceanforderung über etablierte Security Policies und Betriebsverfahren
    • Aufspüren von bekannten und unbekannten Sicherheitslücken und Formulierung von Empfehlungen zur Verbesserung der Administration, der Security und der Umsetzung von Complianceanforderungen über etablierte Security Policies und Betriebsverfahren
    • Erkennung und Verhinderung von Abweichungen vom Normverhalten speziell der technischen und hoch privilegierten Accounts
    • Klärung der Frage nach dem tatsächlichen Verursacher von Datenbankaktionen

Somit zielt das Database Activity Monitoring auf grundlegende Fragen des Datenzugriffs mit dem Zweck der Identifikation Wer Wann Welche Daten geändert hat inkl. des originalen Datenkontextes. Z.B. “Wer hat auf eine Kreditkartennummer zugegriffen?“; “Wann hat jemand eine Kundenadresse geändert?”; “Wie war der Inhalt eines Datensatzes vor der Änderung?”; und “Welche Applikation ist für den Zugriffe auf sensitive Daten genutzt worden?” In der Vergangenheit lag der Focus des Database Activity Monitoring primär auf der Korrektheit von Finanzdaten und war ausgerichtet auf Anforderungen, die von externen Auditoren definiert worden sind. Inzwischen wurde das Database Activity Monitoring auf alle Typen von Daten einschließlich kritischer Personen- und Unternehmensdaten wie z.B. Kreditkarten- und Sozialverischerungsnummern, Finanz und Gesundheitsdaten sowie Corporate Financials ausgedehnt. Mit der zuneh-menden Anforderung zur Absicherung von persönlichen Daten und beschränktem Zugriff auf kritische Daten in Datenbanken, wurde das Database Activity Monitoring ausgeweitet auf privilegierte Nutzer wie Datenbankadministratoren (DBAs) und IT Professionals.

Mit der Verschiebung des Fokus des Database Activity Monitoring auf tiefere Analysen des Datenzugriffs, werden auch höhere Anforderungen hinsichtlich Performance, Skalierbarkeit und Reporting, Rollenteilung innerhalb des Systems sowie Zentralisierung der Administration über mehrere hundert oder tausend Datenbanken hinweg an die Database Activity Monitoring Systeme gestellt.

War Database Activity Monitoring bisher meist ein manueller Prozeß, der durch die Sammlung von Audit Daten des IT Security- und Auditpersonals geprägt war, dass zur Filterung und Klassifizierung von großen Logdatenmengen eigene Skripte und andere Methoden einsetzte, ist Database Activity Monitoring heute nicht mehr ein reines reaktives Prüfen Logdaten, sondern ist in der Lage Risiken und Bedrohungen der Vertraulichkeit und Integrität von Unternehmensdaten zu verringern.

Weil Hacker kontinuierlich neue Methoden entwicklen, um sich unautorisierten Zugriff auf sensitive Daten zu verschaffen, sind Unternehmen gezwungen neueste Sicherheitstechnologien und Real-time Protection zum Schutz ihrer Daten einzusetzen. Das bedeutet, dass seit Hacker nur wenige Sekungen benötigen, um sensitive Daten von einer Datenbank zu kopieren, ist es nicht mehr menschenmöglich solche Angriffe zum Zeitpunkt wenn sie stattfinden aufzuspüren. Daher ist heute Real-time Database Protection zu einer kritischen Anforderung geworden und wird zunehmend im Rahmen von Database Activity Monitoring Aktivitäten berücksichtigt.

Traditionell sind Network Intrusion Detection Systems (NIDS) darauf ausgelegt Angriffe auf das Netzwerk zu erkennen. IDS Systeme basieren auf der Identifikation von bekannten Angriffsmustern und Verhaltensanomalien. Die in jüngerer Zeit entwickelten Datenbank IDS/Third Party Database Activity Monitoring Systeme sind darauf ausgelegt worden, Datenbanken zu monitoren und abzusichern. Um heute auch kritische Personen- und Unternehmensdaten zu sichern ist eine Kombination aus Network IDS System und Datenbank IDS Systems typischerweise empfohlen.

In den weiteren Artikeln werden verschiedene Arten von potenziellen Angriffen auf Datenbanksysteme vorgestellt einschließlich der Möglichkeiten diese zu entdecken sowie die konzeptionelle Architektur von Database Activity Monitoring Systemen und die Herausforderungen, denen sich diese Database Activity Monitoring Lösungen stellen müssen sowie der Umfang des Database Activity Monitoring beschrieben.

Grundsätzlich kann ein erfolgreicher Schutz von Datenbanken nur durch einen klar definierten Prozess erfolgen, in dessen Verlauf Aufgaben aus unterschiedlichen Bereichen zu meistern sind. Diese Bereiche sollen nachfolgend genannt werden:

    • Discovery und Assessment
    • Riskmanagement und Mitigation
    • User-Rights Management
    • Database Activity Monitoring/Firewalling

Hierbei liefern die Antworten jedes Bereichs den Input für die nachfolgenden Bereiche. Z. B. fordert die SOX-Compliance einen Audit-Trail über alle Änderungen an den Finanzdaten eines Unternehmens. In diesem Fall werden die Ergebnisse aus dem Bereich Discovery und Assessment (u.a. Datenklassifzierung hier Finanzdaten) direkt als Kriterium im Bereich Database Activity Monitoring als Regel verwendet z.B. „Logge alle INSERT, UPDATE, DELETE auf allen Datenbanken in den Finanzdaten gespeichert sind“. Daneben können die Ergebnisse des Bereichs User-Rights Management im Bereich Database Activity Monitoring dazu genutzt werden die Frage zu beantworten „ob und wann auf sensible Daten von Usern einer Abteilung zugegriffen worden ist und welche Berechtigung sie dafür haben“.

Angriffe auf Datenbanksysteme

Angreifer/Angriffe lassen sich in zwei Kategorien einteilen:

1. Intruder/Insider

Intruder – Eine Person die Zugriff auf ein Computersystem erlangt und versucht wertvolle Informationen zu extrahieren.

Insider – Eine Person, die zur Gruppe der vertrauten Benutzer gehört und versucht mittels ihrer eigenen Zugriffsberechtigungen Informationen zu erlangen. Die Literatur gibt es zahlreiche Beispiele von solchen Attacken:

      • Ein Accountmanager ändert die die Adresse eines Kunden auf seine eigene Adresse, fordert einen neue Kreditkarte und PIN an, die dann an seine eigene Adresse geschickt wird, um damit Geld von den Kundenkonten abzuheben
      • Mitarbeiter stehlen und verkaufen Kreditabrechnungen ihrer eigenen Kunden

2.    Hierbei lassen sich drei Typen unterscheiden:

      • Getarnte User nutzen widerrechlich fremde Logoninformationen (User/Pwd), um sich Zugriff zu Enterprise Applikationen und Daten zu verschaffen
      • Legitime User haben zwar einen authorisierten Zugriff auf die Systeme, mißbrauchen aber ihre Zugriffsrechte, um sich Informationen anzusehen oder diese zu kopieren ohne dass diese für Ihre Arbeit notwendig sind
      • Verborgene User besitzen administrative Zugriffsrechte ohne diese für ihre Arbeit tatsächlich zu benötigen

Weitere Informationen zu diesem Thema finden sich in dem Artikel: Top-Datenbankbedrohungen.

Top-Datenbankbedrohungen

Nachfolgend eine Liste der häufigsten Bedrohungen denen Datenbanksysteme heute ausgesetzt sind:

    • Missbrauch legitimer Berechtigungen (Insider Angriffe) – Jeder berechtigte Benutzer kann auch legitime Datenbankberechtigungen für nicht autorisierte Zwecke missbrauchen. Hier gibt es zwei Risiken, die in Betracht zu ziehen sind. Das erste Risiko ist ein böswilliger Benutzer, der Datensätze vielleicht verkaufen möchte. Das zweite sogar häufigere Risiko ist ein fahrlässiger Benutzer, der große Datenmengen aus der Datenbank abruft, auf seinem Client-Gerät zu Arbeitszwecken speichert und die Daten damit Bedrohungen wie Trojanern, Laptopdiebstahl usw. aussetzt.
    • Missbrauch übermäßiger Berechtigungen (Nicht autorisierte Aktionen privilegierter User) – Anwendern bzw. Anwendungen denen Datenbankzugriffberechtigungen erteilt werden, die ihren Aufgabenbereich übersteigen, können diese Berechtigungen u.U. zu böswilligen Zwecken missbrauchen. Z.B. sind Datenbankadministratoren (DBA), die grundsätzlich über erweiterte Rechte zur Erfüllung ihrer Aufgaben verfügen, in der Lage unerkannt Aktivitäten auf der Datenbank durchzuführen, die nicht zur Erfüllung ihren Aufgaben gehören. Häufig werden Datenbankbenutzern auch nur übermäßige Berechtigungen erteilt, weil die Datenbankadministratoren nicht genügend Zeit haben, abgestufte Kontrollmechanismen für die Zugriffsberechtigungen einzelner Benutzer zu definieren und auf dem neuesten Stand zu halten. Die Folge ist, dass allen Benutzern oder großen Benutzergruppen allgemeine Standardzugriffsberechtigungen erteilt werden, die weit über die Anforderungen ihrer Aufgaben hinausgehen.
    • Missbräuchliche Berechtigungserweiterung (Privilegien Eskalation) – Erlangung von umfassenden Zugriffsrechten (z.B. Administrationsberechtigungen) durch einen normalen Benutzer indem Datenbank Schwachstellen ausgenutzt werden (abhängig vom DBMS). Solche Schwachstellen können in gespeicherten Prozedu-ren, integrierten Funktionen, Protokollimplementierungen und sogar in SQL-Statements auftreten. Mit diesen Berechtigungen könnte der böswillige Benutzer anschließend Prüfmechanismen umgehen, Daten manipulieren oder stehlen, unerlaubte Transaktionen durchführen etc.
    • Ausnutzen von Schwachstellen fehlerhaft konfigurierter Datenbanken – In der Praxis finden sich sehr häufig Datenbanken mit nicht gepatchten Schwachstellen und solche mit Standardkonten und Konfigurationsparameter. Angreifer werden Systeme typischerweise auf diese Schwachstellen hin prüfen, sodass hier die Gefahr einer Sicherheitsverletzung gegeben ist. Zudem ist während der Zeit, in der ein Datenbankanbieter einen Patch für eine bestimmte Schwachstelle entwickelt, die Datenbank einer Organisation nicht gegen Angreifer geschützt. Und selbst wenn ein Patch freigegeben worden ist, steht dieser u.U. noch nicht sofort zur Verfügung. Grundsätzlich sind beim Patchen einer Datenbank verschiedene Aspekte in Betracht zu ziehen. Zunächst muß eine Organisation den Patchvorgang für das System für diesen bestimmten Patch bewerten und verstehen, welche Auswirkungen sich auf das System ergeben. Der Patch könnte evtl. bereits vorhandenen Code beeinträchtigt oder eine Work-Around-Möglichkeit eröffnen. Zudem verursacht ein Patchvorgang immer Ausfallzeiten, in denen der Datenbankserver nicht für die Benutzer zur Verfügung steht. Große Unternehmen mit einer großen Anzahl von Datenbanken müssen eine zeitliche Abfolge für das Patching festlegen und Datenbanken eine Priorität zur Behebung der Schwachstelle zuordnen. Daher ist es üblich, dass sich Patching-Vorgänge in vielen Organisationen über Monate hinziehen – typischerweise werden zwischen 6 und 9 Monate benötigt (basierend auf von der Independent Oracle User Group – IOUG* durchgeführten Studien). Beim Patching-Vorgang spielen DBAs, System- und IT-Admins, Entwickler eine Rolle. Aus diesen Gründen bleiben Server oft noch Monate nach der Freigabe eines Patches angreifbar und können von einem Angreifer über Standardkonten und Konfigurationsparameter, die aus einer produktiv genutzten Datenbank nicht ent-fernt worden sind, ausgenutzt werden. Ein Angreifer könnte z.B. versuchen, über ein Standardkonto Zugriff auf die Datenbank zu erlangen. Schwache Audit-Parameter erläuben es einem Angreifer, Audit-Kontrollen zu umgehen oder Spuren seiner Aktivitäten zu verwischen. Schwache Authentifizierungsschemata ermöglichen es Angreifern, die Identität legitimer Datenbankbenutzer anzunehmen, indem Anmeldeinformationen gestohlen oder anderweitig erhalten werden, Nutzung eines Exploits, um Zugang zur OS Shell zu erhalten. Darüber kann dann der Code von Services/Daemons in der Art geändert werden, dass die zugreifenden Controls, Auditing oder Authentication Mechanismen deaktiviert werden. (abhängig vom DBMS)
    • SQL Injection – Bei einem SQL-Injection-Angriff werden typischerweise nicht autorisierte Datenbank-Statements in einen angreifbaren SQL-Datenkanal wie gespeicherte Prozeduren und Eingabeparameter von Web-Applikationen eingeleitet. Diese eingefügten Statements werden anschließend zur Datenbank weitergegeben und dort ausgeführt, wodurch Angreifer uneingeschränkten Zugriff zur gesamten Datenbank erlangen können.
    • Unzureichender Audit-Trail – Elementarer Bestandteil jeder Datenbankimplementierung sollte sein, alle vertraulichen und/oder ungewöhnlichen Datenbanktransaktionen automatisch aufzuzeichnen. Schwache Datenbank-Audit-Richtlinien stellen auf vielen Ebenen ein ernsthaftes organisatorisches Risiko dar.
      • Regulatorisches Risiko – Organisationen mit schwachen oder fehlenden Datenbank-Audit-Mechanismen werden zunehmend feststellen, dass sie behördlichen Regulierungsanforderungen nicht entsprechen.
      • Abschreckung –Datenbank-Audit-Mechanismen dienen dazu, Angreifer abzuschrecken, weil sie wissen, dass Datenbank-Audit-Aufzeichnungen Ermittlern Beweismaterialien liefern, um Eindringlin-gen eine Straftat nachzuweisen.
      • Erkennung und Wiederherstellung –Sicherheitsverletzungen können nach ihrem Auftreten durch Audit-Daten identifiziert werden und dienen der Zuordung zu bestimmten Anwendern und/oder Reparatur des Systems.
    • Schwachstellen in grundlegenden Audit-Merkmalen – Datenbanksoftware-Plattformen verfügen in der Regel über grundlegende Audit-Merkmale, welche allerdings häufig mehrere Schwachstellen aufweisen, die ihre Implementierung einschränken oder ausschließen.
      • Fehlende Benutzerüberwachung – Wenn Anwender über Web-Applikationen auf Datenbanken zugreifen, lassen sich spezifische Benutzeridentitäten mit nativen Auditmechanismen nicht identifizieren, da die Benutzeraktivitäten dem Web-Applikatios-Account zugeordnet werden. Missbräuchliche Datenbanktransaktionen in nativen Audit Logs lassen sich somit nicht auf den verantwortlichen Anwender zurückverfolgen.
      • Leistungseinbußen – Native Datenbank-Audit-Mechanismen belegen häufig erhebliche CPU- und Festplattenressourcen, weswegen viele Organisationen wegen der auftretenden Leistungseinbußen Audit-Funktionen zurücknehmen oder vollständig deaktivieren.
      • Pflichtentrennung – Anwender mit Administrationsrechten für den Datenbankserver können Audit- Funktionen einfach abschalten, um missbräuchliche Aktivitäten zu verschleiern. Daher sollten Audit-Pflichten idealerweise zwischen Datenbankadministratoren und der Datenbank-Server-Plattform getrennt sein.
      • Begrenzte Granularität –Native Audit-Mechanismen zeichnen häufig nicht alle erforderlichen Details, um Angriffe zu erkennen, den forensischen Nachweis zu führen sowie Systeme wiederherzustellen. Datenbank-Client-Anwendung, Quell-IP-Adressen, Query-Response-Attribute und fehlgeschlagene Abfragen als wichtiger Indikator für Ausspähungen vor einem Angriff werden z. B. von vielen nativen Mechanismen nicht aufgezeichnet.
      • Proprietäre Formate – Da sich Audit-Mechanismen und Logs einzelner Datenbankserver-Plattformen z.T. erheblich voneinander unterscheiden, ist es für Organisationen mit gemischten Datenbankumgebungen nahezu unmöglich, einheitliche, skalierbare Audit-Prozesse über das gesamte Unternehmen hinweg zu implementieren.
    • Denial of Service (DoS) – Dies bezeichnet eine allgemeine Angriffskategorie, in der Angriffe dazu führen, dass berechtigten Anwendern der Zugriff auf Netzwerk-Applikationen und Daten verweigert wird. Denial of Service (DoS)-Zustände lassen sich über zahlreiche verschiedene Techniken hervorrufen, wobei viele dieser Techniken die bereits erwähnten Schwachstellen ausnutzen. Ein DoS lässt sich z. B. verursachen, indem Schwachstellen der Datenbankplattform genutzt werden, um einen Server zum Absturz zu bringen (z.B. Initiierung von Buffer Overflows). Weitere verbreitete DoS-Techniken sind die Kompromittierung von Daten, eine Überflutung des Netzwerks mit Netzwerkverkehr und eine Überlastung von Serverressourcen (Speicher, CPU usw.). Ressourcenüberlastungen treten besonders häufig in Datenbankumgebungen auf. Die Motivationen, die hinter DoS-Angriffen stecken, sind ähnlich vielfältig. DoS-Angriffe kommen häufig in Zusammenhang mit Erpressungsversuchen vor, in denen ein Remote-Angriffs-Server die Datenbank wiederholt zum Absturz bringt, bis das Opfer Gelder auf ein internationales Bankkonto überweist. In anderen Fällen lassen sich DoS-Zustände auf eine Wurm-Infektion zurückführen. Unabhängig von der Ursache stellen DoS-Angriffe für viele Organisationen eine ernsthafte Bedrohung dar.
    • Schwachstellen im Datenbankkommunikationsprotokoll – In Datenbankkommunikationsprotokollen aller Datenbankanbieter werden immer mehr Sicherheitsschwachstellen entdeckt, wobei in den jeweiligen nativen Audit-Trails keine Aufzeichnungen dieser Aktivitäten vorhanden sind, weil sie Protokolloperationen nicht abdecken. Missbräuchliche Aktivitäten, die auf diese Schwachstellen abzielen, reichen von nicht autorisierten Zugriffen auf Daten bis zu Datenkompromittierungen und DoS-Angriffen.
    • Nicht autorisierte Kopien vertraulicher Daten – Häufig werden nicht alle Datenbanken ordnungsgemäß erfasst und gewartet. Neue Datenbanken werden erstellt ohne dass das Sicherheitsteam Kenntnis von diesen Datenbanken weiß. Werden nun vertrauliche Daten wie Transaktions-, Kunden- und Mitarbeiterdetails in diese Datenbanken kopiert werden, sind diese einem Sicherheitsrisiko ausgesetzt, sofern die erforderlichen Kontrollen nicht implementiert werden. Ein weiteres Beispiel sind alte Datenbanken, die vergessen und nicht in die Bewertung einbezogen wurden.
    • Unzureichend geschützte Backup-Daten – Oft sind Speichermedien mit Datenbank-Backups völlig ungeschützt. In der Vergangenheit wurden immer wieder Fälle bekannt, in denen Bänder und Festplatten von Datenbank-Backups gestohlen worden sind, was zu ernsthaften Sicherheitsverletzungen geführt hat.
    • Angriffe per Web Applikation – Applikationen, die mit einer Datenbank im Hintergrund arbeiten, können kompromittiert werden, um Zugriffsrechte zu erweitern und damit umfassenden Zugriff auf die Datenbankresourcen zu erlangen (z. B. per SQL Injection). Hier ist es notwendig, dass die Database Activity Monitoring Lösung statt dem Applikationsaccounts auch Zugriff auf den wirklichen Verursacher der Aktion hat.
    • Zugriff auf OS Ressourcen per Datenbankangriff – z.B. ermöglicht die Änderung des UTL_FILE_DIR Parameters bei Oracle der Prozedur SYS.UTL_FILE wichtige Files auf dem Betriebssystem zu überschreiben oder Daten zu extrahieren.
    • Password Angriffe („BruteForce-Attacken“) – Hier wird versucht Passworte zu erraten, indem zahlreiche Zei-chenkombinationen per Skript am DBMS ausprobiert werden oder DB Schwachstellen werden ausgenutzt.
    • Cross Site Scripting (XSS) – Zugriff auf die Datenbank durch Diebstahl von Logoninformationen von legitimen Benutzern einer Webapplikation indem Userdaten in der Datenbank gespeichert werden und später anderen Usern auf der Website unverschlüsselt angezeigt werden.

Obwohl Datenbankinformationen somit vielen verschiedenen Angriffen ausgesetzt sind, ist es dennoch möglich, Risiken durch eine Konzentration auf die wichtigsten Bedrohungen, erheblich zu reduzieren. Wenn es Organisationen gelingt, den oben beschriebenen wichtigsten Bedrohungen mittels geeigneten Maßnahmen wie gelebten Berechtigungskonzepten, Erfüllung der Anforderungen an sichere Datenbanksysteme, dem Einsatz von Database Activity Monitoring Lösungen etc.  zu begegnen, erfüllen sie damit globale Compliance-Anforderungen und bewährte Industriestandards bezüglich Datenschutz und Risikominimierung.

Konzeptionelle Architektur von Database Activity Monitoring Lösungen

Gegeben ist ein Log mit Wer hat Was mit Welchen Daten Wann und Wie getan. Ein Database Activity Monitoring System sollte in der Lage sein die Frage nach dem Warum zu beantworten. Database Activity Monitoring Systeme helfen Organisationen dabei:

    • Aufspüren/Verhindern von Einbruchsversuchen in die Systeme einschließlich Privileged User
    • Erstellung eines regelmäßigen Reports hinsichtliche Systemnutzung und Datenmodifikationen
    • Erkennung und Wiederherstellen von Datenbanksystemen im Falle von System- und Bedienungsfehlern

Die Basisarchitektur eines Database Activity Monitoring Systems ist in der nachfolgenden Grafik dargestellt. Dannach besteht das System aus drei wesentlichen Komponenten wie einem Logger, einem Analyzer, und einem Notifier. Der Logger zeichnet Informationen auf, wobei die Art der zu speichernden Information durch die Security Policies festgelegt wird. Der Analyzer analyisert das Log in der Art, ob es Securityverstösse gibt oder ob noch weitere Informationen geloggt werden sollten. Der Notifier hat die Aufgabe die Ergebnisse an den Analysten zu reporten.

Logger

Die Definition der Loggingmethode umfaßt die Definitionen der Event-Typen und den Umfang des Monitorings. Damit bestimmt der Logger Inhalt, Zeit, Ort, Methode und Häufigkeit des Datenbankloggings sowie andere wesentliche Bereiche des Systems. Z.B. hat der Ort des Loggings einen direkten Einfluß auf die Effizienz von Analyse und Datenbereitstellung. Daneben muß das System dafür Sorge tragen, dass die Loggdaten während des Auditprozesses gegenüber unberechtigten Zugriffen geschützt sind und zudem auch ausreichend viele Informationen geloggt werden, um letztendlich ein umfassendes Monitoring sicherzustellen. Insgesamt ist der definierte Log-Umfang für ein Database Activity Monitoring System ein kritischer Faktor, weil die Möglichkeiten der Analysten, zur Rekonstruktion von auffälligen Events ganz besonders vom Inhalt und Richtigkeit des Datenbanklogs abhängen.

Analyzer

Die Analyse ist durch zwei Hauptfaktoren definiert: Das Ziel der Analyse und deren Zeiten und Wiederholungen. Das Ziel der Analyse bezieht sich auf die generellen Ziele des Monitorings, die sich wiederum auf das Aufspüren von Securityverletzungen beziehen. Der Analyseprozeß folgt typischerweise den nachfolgenden 4 großen Zielen:

    • Entdecken von Notwendigkeiten zur Änderung von Systempolicies
    • Aufspüren von definierten Problemen und Anomalien
    • Bestimmung der Verantwortlichkeit von Useraktivitäten
    • Erstellung eines regelmäßigen Reportings hinsichtlich Systemnutzung und Datenmodifikationen

Die Häufigkeit der Analyse wird bestimmt durch die oben genannten Ziele und kann periodisch, auf Transactionshäufigkeiten und/oder Real-time erfolgen. Häufigere Analysen erhöhen zwar die Wahrscheinlichkeit Missbräuche frühzeitig zu entdecken und die Reaktionszeit zu reduzieren, was jedoch auch steigende Kosten zur Folge hat. Real-time Analyse bietet die höchste Analysehäufigkeit und ist aber gleichzeitig auch die teuerste Alternative, die typischerweise den kritischen Systemumgebungen vorbehalten ist. Periodische Analysen werden grundsätzlich genutzt, um einen allgemeinen Systemüberblick zu erhalten oder ein regelmäßiges Reporting zu unterstützen. Die Transactionshäufigkeitsmethode erführt immer nach einer bestimmten Anzahl von Transaktionen eine Analyse durch.

Notifier

Das Notifikationsystem unterstützt die verfügbaren Recherchertechniken in der Art, dass die Daten in einer Form dargestellt werden, die den Analysten ermöglicht potentielle Bedrohungen und Verletzungen von Policies frühzeitig aufzudecken und bereinigt die Daten auf Basis der definierten Regeln und Rechteebenen der jeweiligen Betrachter.
Dies dient der Sicherheit der Daten gegenüber Änderungen der Informationen, abhängig vom jeweiligen User, dessen Informations-Level und den Ergebnissen. Der Bereinigungprozeß entfernt alle Informationen, die nicht relevant sind oder deren Informations-Level höher ist als der auf den der jeweilige User Zugriff haben darf.

Dies erfolgt durch zwei Prinzipien: 1. Getrennte Privilegien – > Trennung der Verantwortlichkeiten (Separation of duties) und 2. Minimale Privilegien. Getrennte Privilegien schützen die Daten dadurch, dass mehr als ein Key oder eine Au-thentication für den Zugriff auf sensitive Daten notwendig ist. Z.B. ist mehr als ein privilegierter User notwendig, um den Zugriff auf kritische Logs zu erhalten. Das Prinzip der Minimalen Privilegien gewährleistet, dass nur wenige Zugriffsrechte vergeben werden. Z.B. können User bei ihrer Suche und dem Datenzugriff auf einzelne Bereiche der Datenbank eingeschränkt werden, wobei keinem User gestattet ist auf alle Datenbankeinträge zuzugreifen.