Zum Inhalt
Sie verwenden eine veraltete Dokumentation Zur aktuellen Version wechseln

# Sicherheitskomponenten der Datenbank

Datenbank

Die Sicherheit vor Datenverlust wird im Wesentlichen über die verwendeten Datenbanken (Oracle, SQL-Server) realisiert.

Ein 100%-er Schutz vor unbefugten Zugriff und Datenmanipulation ist allerdings nicht realisierbar, da auf der Ebene von Administratoren theoretisch immer Manipulationen möglich sind. Es ist daher sicherzustellen, dass Aktivitäten in bestimmten Bereichen der Datenbank protokolliert werden. So wird gewährleistest, dass alle manipulativen Aktionen an der Datenbank nachvollziehbar bleiben.

Zum Schutz der Daten vor unbefugtem Zugriff gibt es verschiedene Ansätze, die zum einen durch den Hersteller realisiert bzw. angeboten werden und zum anderen durch die internen Sicherheitsmaßnahmen des jeweiligen Kunden hinsichtlich Zugriffsberechtigung und Protokollierung auf die Datenbanken sicherzustellen sind. Hierzu erhält der Kunde von uns eine Handlungsempfehlung als Ergänzung zu den individuellen Sicherheitsmaßnahmen des Kunden.

Sicherheit vor unberechtigtem Zugriff auf Datenbankebene

Hier liegt der Schwerpunkt auf der Abschirmung der Anwendungsdaten gegen

- unbefugten Zugriff
- Manipulation
- Protokollierung bestimmter Handlungen in der Datenbank

Dabei wird auf ein zweistufiges Konzept gesetzt. Zur Umsetzung dieses Sicherheitskonzeptes ist die Verteilung von Administrator- bzw. Sicherheitsberechtigungen auf mindestens 2 verschiedene Personen (Datenbankadministrator und Auditor) zwingend erforderlich. Im Ergebnis dieser zwei Schritte kann der Datenbank-Administrator zwar die Datenmanipulationen durchführen, diese bleiben dem Auditor aber nicht verborgen und können vom Datenbank-Administrator auch nicht manipuliert werden.

Im Gegenzug kann der Auditor zwar alle Aktionen einsehen, hat aber kein Recht auf die Datenbank und kann somit die Daten nicht abändern.

Stufe 1:

Protokollierung aller DML-Aktionen(Datenmanipulationen) auf Verfahrenstabellen

Einrichtung DDL-Trigger

Im ersten Schritt werden alle (bzw. die durch den Kunden gewünschten, wichtigen Daten) Änderungen an den Daten protokolliert. Dies geschieht durch sogenannte Trigger, welche automatisch für die vorab festgelegten Verfahrenstabellen generiert werden. Diese Trigger sorgen dafür das Änderungen an den Verfahrensdaten in eine Protokolltabelle „weggeschrieben“ werden. Da diese Protokollierung, im Gegensatz zur Protokollierung der Anwendungsebene, ausschließlich auf Datenbankebene stattfindet, werden hier alle Änderungen erfasst, unabhängig ob diese vom Programm oder per direktem SQL Eingriff ausgelöst wurden. Es kann an dieser Stelle also nicht „gesehen“ werden wie diese Daten geändert wurden. Es wird aber bei jeder Änderung auf jeden Fall protokolliert! Je nach Umfang der Änderungen und der zu protokollierenden Daten, kann dies zu einer erheblichen Menge an Protokolleinträgen führen.

Die Auswertung der Daten erfolgt mit den entsprechenden Datenbankmitteln durch den Datenbankadministrator selbst oder einem anderen, vom Finanzverfahren unabhängigen, Programm.

Stufe 2:

Protokollierung von DDL-Aktionen(Änderungen an der Datendefinition) von Verfahrenstabellen

Einrichtung SQLServer Überwachung

- Überwachung DDL-Manipulation der Verfahrenstabellen

- Einrichtung einer Überwachung und einer Überwachungsspezifikation für die jeweilige Verfahrensdatenbank

/** Löschen bisheriger Überwachung ****/

USE master ;

GO

ALTER SERVER AUDIT [IFR_PROT_TRIGGER]

WITH (STATE = OFF);

DROP SERVER AUDIT [IFR_PROT_TRIGGER]

USE [VERFAHRENSDATENBANK]

GO

ALTER DATABASE AUDIT SPECIFICATION [DatabaseAuditSpecification_DDL_AKTIONEN]

WITH (STATE = OFF);

DROP DATABASE AUDIT SPECIFICATION [DatabaseAuditSpecification_DDL_AKTIONEN]

/** Anlegen einer neuen Überwachung ****/

USE master ;

GO

- Anlegen der Überwachung

CREATE SERVER AUDIT [IFR_PROT_TRIGGER]

TO FILE ( FILEPATH =

'[Pfad zum Audit-File]') --Pfad ergänzen

GO

- Aktivieren der Überwachung

ALTER SERVER AUDIT [IFR_PROT_TRIGGER]

WITH (STATE = ON);

- Anlegen der Datenbank-Überwachungsspezifikation

USE [VERFAHRENSDATENBANK]

GO

CREATE DATABASE AUDIT SPECIFICATION [DatabaseAuditSpecification_DDL_AKTIONEN]

FOR SERVER AUDIT [IFR_PROT_TRIGGER]

ADD (SCHEMA_OBJECT_CHANGE_GROUP),

ADD (AUDIT_CHANGE_GROUP)

WITH (STATE = ON)

GO

- Überwachung Lesezugriff auf AUDIT-FILES eine Server Instanz

- Einrichtung einer Überwachung

- und einer Überwachungsspezifikation

/** Löschen bisheriger Überwachung ****/

USE master ;

GO

ALTER SERVER AUDIT [AUDIT_UEBERWACHUNG]

WITH (STATE = OFF);

DROP SERVER AUDIT [AUDIT_UEBERWACHUNG]

USE master -- muss auf master-DB erfolgen

GO

ALTER DATABASE AUDIT SPECIFICATION [AUDIT_LESEN]

WITH (STATE = OFF);

DROP DATABASE AUDIT SPECIFICATION [AUDIT_LESEN]

/** Anlegen einer neuen Überwachung ****/

USE master ;

GO

- Anlegen der Überwachung

CREATE SERVER AUDIT [AUDIT_UEBERWACHUNG]

TO FILE ( FILEPATH =

'[Pfad zum Audit-File]') --Pfad ergänzen

GO

- Aktivieren der Überwachung

ALTER SERVER AUDIT [AUDIT_UEBERWACHUNG]

WITH (STATE = ON);

- Anlegen der Datenbank-Überwachungsspezifikation

USE [master]

GO

CREATE DATABASE AUDIT SPECIFICATION [AUDIT_LESEN]

FOR SERVER AUDIT [AUDIT_UEBERWACHUNG]

ADD (SELECT ON OBJECT::[sys].[fn_get_audit_file] BY [dbo]),

ADD (SELECT ON OBJECT::[sys].[fn_get_audit_file] BY [sys])

- Nutzer bei Bedarf anpassen oder Weitere ergänzen

WITH (STATE = ON)

GO

Im zweiten Schritt muss noch dafür gesorgt werden, dass entsprechend privilegierte Benutzer (Datenbank-Administrator,Datenbankbesitzer) diese Protokollierung aus der 1. Stufe nicht unbemerkt umgehen können. Dies geschieht dadurch, dass sämtliche Aktionen, welche die Datendefinition der Verfahrenstabellen in einer Datenbank ändern, mittels Audit (im SQL-Server Überwachung genannt) ebenfalls protokolliert werden. Zu diesen Änderungen zählt auch das Deaktivieren/Akivieren der Trigger aus der 1. Stufe. Diese Protokollierung zielt somit nicht darauf ab, die geänderten Werte einer Tabellenzeile zu dokumentieren, sondern den ausgeführten Prozess an sich. Es wird dadurch die Manipulation an sich nicht verhindert, aber sie wird als Datenbank-Aktivität protokolliert.

Die Protokollierung erfolgt direkt in ein Audit-File, welches im Filesystem abgelegt gespeichert wird. Der Ablageort im Filesystem des Kunden ist so mit Rechten zu versehen, dass der Datenbank-Administrator dieses nicht löschen oder manipulieren kann. Der Zugriff auf den Speicherort der Datei sollte auf folgende Weise eingeschränkt werden:

Das Dienstkonto der jeweiligen Datenbankinstanz muss über Lese- und Schreibberechtigungen verfügen.Für Auditoren sind in der Regel Lese- und Schreibberechtigungen erforderlich. Dabei wird angenommen, dass Auditoren Windows-Konten für die Verwaltung von Audit-Files (u. a. das Kopieren der Dateien auf andere Freigaben und das Erstellen von Sicherungen) darstellen. Für das Lesen von Audit-Files autorisierte Personen müssen über eine Leseberechtigung im SASKIA.H2R verfügen. SASKIA stellt zur Grundeinrichtung einer solchen SQL-Server Überwachung (mit Standardwerten) ein Skript zur Verfügung, welches durch den Datenbank-Administrator um die entsprechende Verfahrensdatenbank und den Speicherort des Audit-Files zu ergänzen und anschließend im SSMS auszuführen ist.

Für Oracle liegt eine solche Grundeinrichtung momentan noch nicht vor. Grundlegend kann aber durch den Datenbank-Administrator ein solches Audit auch selbst eingerichtet werden.

Um einer Manipulation schon bei der Erstinstallation des Auditing vorzubeugen, sollte die Einrichtung immer im 4-Augen-Prinzip (Auditor+Datenbank-Administrator) erfolgen. Anschließend ist eine Kontrolle der Funktionalität vorzunehmen.

Um eine eventuelle Manipulation frühzeitig zu erkennen, muss das Audit-File in regelmäßigen Abständen durch den Auditor geprüft werden. Anschließend kann dieses File in einen weiteren geschützten Verzeichnis archiviert werden.

28. August 2025
12. Juni 2025