IT-Grundschutzhandbuch 1998

IT-Grundschutzhandbuch 1998
IT-Grundschutzhandbuch
9.2
Datenbanken
Datenbanken
Beschreibung
Datenbanksysteme (DBS) sind ein weithin
akzeptiertes Hilfsmittel zur rechnergestützten
Organisation, Erzeugung, Manipulation und
Verwaltung großer Datensammlungen. Ein DBS
besteht aus dem sogenannten Datenbankmanagement-System (DBMS) und einer gewissen
Anzahl von Datenbanken. Eine Datenbank ist eine
Sammlung von Daten, welche Fakten über eine
spezielle Anwendung der realen Welt repräsentiert.
Das DBMS fungiert dabei als Schnittstelle zwischen den Benutzern und einer Datenbank. Es
stellt sicher, daß die Benutzer auf ihre Daten effizient und unter zentralisierter Kontrolle
zugreifen können, und daß die Daten dauerhaft vorhanden sind.
Der Einsatz von Datenbankmanagement-Systemen in der IT ist inzwischen nicht mehr
wegzudenken. Die Flut von Daten, die erfaßt, verarbeitet und ausgewertet werden müssen, kann
ohne ein DBMS nicht mehr bewältigt werden. Die Konzeption einer Datenbank und eines DBMS
basiert auf einem sogenannten Datenbankmodell. Nachfolgend werden die wichtigsten
Datenbankmodelle kurz beschrieben:
Hierarchisches Datenbankmodell
Es ist die älteste existierende Variante und wird auch als Datenbankmodell der ersten Generation
bezeichnet. Die Organisation der Datenbank erfolgt in Form einer Baumstruktur. Die Knoten
bzw. Blätter einer solchen Struktur sind Dateien. Ein Knoten/Blatt hat genau einen Vorgänger.
Der Zugriff auf die Daten erfolgt immer sequentiell. Die Zugriffspfade sind durch die
Baumstruktur (bzw. Dateistruktur) festgelegt.
Relationales Datenbankmodell
Das relationale Datenbankmodell basiert auf einer strikten Trennung von Daten und
Zugriffsmöglichkeiten. Die Daten werden in Form von Tabellen abgelegt, wobei eine Zeile einem
Datensatz entspricht (dieser wird Tupel genannt) und eine Spalte einem Attribut des Datensatzes.
Tupel können nun mit anderen Tupeln aus anderen Tabellen in einer Beziehung stehen, was durch
entsprechende Relationen gekennzeichnet wird. Im Gegensatz zum hierarchischen sind dem
relationalen Datenbankmodell keine Grenzen hinsichtlich der Zugriffsmöglichkeiten auf Daten
gesetzt.
Die in allen relationalen Datenbanksystemen zur Verfügung stehende Datenbanksprache ist SQL
(Standard Query Language), die durch die ISO standardisiert ist.
Objektorientiertes Datenbankmodell
Objektorientierte Datenbankmodelle stellen eine Erweiterung klassischer Datenbankmodelle dar
und verwenden einen objektorientierten (OO) Ansatz. Dieser zeichnet sich dadurch aus, daß
Objekte mit ähnlichen Eigenschaften zu Klassen zusammengefaßt und diese wiederum zu
Klassenhierarchien gruppiert werden können. Nur definierte Methoden können die Objekte
verändern, und der Mechanismus der Vererbung von Methoden und Attributen ist dabei ein
zentraler Punkt des OO-Ansatzes. Weiterhin sind neben den Standarddatentypen wie z. B.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 1
Datenbanken
IT-Grundschutzhandbuch
"Integer" oder "Character" auch Typkonstruktore möglich, so daß komplexe Werte definiert
werden können.
Dieses Kapitel berücksichtigt ausschließlich Datenbanken, die auf dem relationalen
Datenbankmodell basieren, da dies das derzeit am meisten verbreitete Datenbankmodell ist.
Ein Datenbanksystem steht im allgemeinen nicht nur einem Benutzer exklusiv zur Verfügung,
sondern es muß die parallele Verarbeitung verschiedener Benutzeraufträge (sogenannte
Transaktionen) ermöglichen und dabei einen gewissen Grad an Fehlertoleranz gewährleisten.
Wesentlich dafür ist die Einhaltung der folgenden vier Eigenschaften, die unter dem ACIDPrinzip bekannt sind:
-
Atomarität (Atomicity)
Eine Transaktion wird aus der Sicht des Benutzers nur vollständig oder gar nicht
ausgeführt. Sollte es bei der Ausführung zu einem Fehler bzw. Abbruch kommen, werden
alle bereits getätigten Änderungen an der Datenbank wieder zurückgenommen. Dies wird
durch geeignete Recovery-Mechanismen des Datenbanksystems sichergestellt.
-
Konsistenz (Consistency)
Alle Integritätsbedingungen der Datenbank werden eingehalten, d. h. eine Transaktion
überführt eine Datenbank immer von einem konsistenten Zustand in einen anderen
konsistenten Zustand. Dies kann u. a. durch eine geeignete Synchronisationskontrolle des
Datenbanksystems gewährleistet werden.
-
Isolation (Isolation)
Jede Transaktion läuft isoliert von anderen Transaktionen ab und ist in jeder Hinsicht
unabhängig von anderen. Dazu gehört auch, daß jeder Transaktion nur diejenigen Daten
aus der Datenbank zur Verfügung gestellt werden, die Teil eines konsistenten Zustands
sind.
-
Persistenz (Durability)
Falls eine Transaktion erfolgreich beendet und dies dem Benutzer auch gemeldet wurde,
überleben die in der Datenbank erzeugten Effekte (falls es solche gibt) jeden danach
auftretenden Hard- oder Softwarefehler (es sei denn, die Festplatte mit der Datenbank wird
zerstört).
Diese Eigenschaften muß das Transaktionssystem des DBMS gewährleisten, was mittlerweile bis
auf wenige Ausnahmen von allen kommerziellen DBMSen erfüllt wird.
Datenbanksysteme stellen Standardsoftware dar, d. h. sie werden von den unterschiedlichsten
Herstellern auf dem Markt angeboten. Soll eine Datenbank zur Verarbeitung von Daten
eingesetzt werden, so ist im ersten Schritt eine geeignete Standardsoftware auszuwählen. Die
zugehörigen Gefährdungen und Maßnahmen aus dem Kapitel 9.1 Standardsoftware sind deshalb
zusätzlich zu beachten.
Datenbanken können nicht losgelöst von der Umgebung betrachtet werden, in der sie eingesetzt
werden. Ein Stand-alone PC ist ebenso denkbar, wie ein Großrechnerumfeld oder vernetzte UnixSysteme. Dementsprechend sind in Abhängigkeit des Einsatzumfeldes die Gefährdungen und
Maßnahmen der Kapitel 5 Nicht Vernetzte Systeme, Kapitel 6 Vernetzte Systeme und Kapitel 7
Datenübertragungseinrichtungen zu berücksichtigen. Auf eine Wiederholung von Gefährdungen
und Maßnahmen dieser Kapitel wird hier aus Redundanzgründen verzichtet, es sei denn, sie sind
von besonderer Wichtigkeit.
Teil 1 - Kapitel 9.2 - Seite 2
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Gefährdungslage
Für den IT- Grundschutz von Datenbanken werden die folgenden Gefährdungen angenommen:
Höhere Gewalt:
- G 1.1
Personalausfall
Organisatorische Mängel:
- G 2.3
Fehlende, ungeeignete, inkompatible Betriebsmittel
- G 2.22
Fehlende Auswertung von Protokolldaten
- G 2.26
Fehlendes oder unzureichendes Software-Test- und Freigabeverfahren
- G 2.38
Fehlende oder unzureichende Aktivierung von DatenbankSicherheitsmechanismen
- G 2.39
Komplexität eines DBMS
- G 2.40
Komplexität des Datenbankzugangs/-zugriffs
- G 2.41
Mangelhafte Organisation des Wechsels zwischen den Datenbank-Benutzern
- G 2.57
Nicht ausreichende Speichermedien für den Notfall
Menschliche Fehlhandlungen:
- G 3.6
Gefährdung durch Reinigungs- oder Fremdpersonal
- G 3.16
Fehlerhafte Administration von Zugangs- und Zugriffsrechten
- G 3.23
Fehlerhafte Administration eines DBMS
- G 3.24
Unbeabsichtigte Datenmanipulation
Technisches Versagen:
- G 4.26
Ausfall einer Datenbank
- G 4.27
Unterlaufen von Zugriffskontrollen über ODBC
- G 4.28
Verlust von Daten einer Datenbank
- G 4.29
Datenverlust einer Datenbank bei erschöpftem Speichermedium
- G 4.30
Verlust der Datenbankintegrität/-konsistenz
Vorsätzliche Handlungen:
- G 5.9
Unberechtigte IT-Nutzung
- G 5.10
Mißbrauch von Fernwartungszugängen
- G 5.18
Systematisches Ausprobieren von Paßwörtern
- G 5.64
Manipulation an Daten oder Software bei Datenbanksystemen
- G 5.65
Verhinderung der Dienste eines Datenbanksystems
Maßnahmenempfehlungen
Zur Realisierung des IT-Grundschutzes wird empfohlen, die notwendigen Maßnahmenbündel
("Bausteine") wie in Kapitel 2.3 und 2.4 beschrieben umzusetzen.
Es ist sinnvoll, den Datenbank-Server in einem separaten Serverraum aufzustellen. Zu
realisierende Maßnahmen sind in Kapitel 4.3.2 beschrieben. Sollte ein als Büro genutzter Raum
gleichzeitig als Serverraum dienen müssen, so sind zusätzlich die in Kapitel 4.3.1 beschriebenen
Maßnahmen zu realisieren.
Wird der Datenbank-Server in einem Schutzschrank aufgestellt, ist auch das Kapitel 4.4
Schutzschränke zu beachten.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 3
Datenbanken
IT-Grundschutzhandbuch
Darüber hinaus sind im Bereich Datenbanken im wesentlichen die folgenden Schritte
durchzuführen:
1.
Anforderungen an die Datenbanksoftware ermitteln
Zu Beginn muß ein Anforderungskatalog für Standardsoftware erstellt werden, so daß eine
geeignete Datenbanksoftware ausgewählt werden kann (M 2.80 und M 2.124).
2.
Schulung der Administratoren
Bevor die Datenbanksoftware produktiv eingesetzt werden kann, sollten die zuständigen
Administratoren zum Betrieb des Datenbanksystems geschult werden (M 3.11). Dies sollte
nach Möglichkeit bereits vor deren Beschaffung geschehen.
3.
Erstellung eines Datenbankkonzeptes
Vor dem Einsatz der Datenbanksoftware sollte ein Datenbankkonzept erstellt werden,
welches sowohl die Installation und Konfiguration der Datenbanksoftware selbst, ein
ausreichendes Benutzerkonzept, als auch die anwendungsspezifische Datenbank beinhalten
sollte. Je nach Volumen und Einsatzbereich der Datenbank, sowie der gewählten
Datenbank-Standardsoftware kann ein solches Konzept sehr umfangreich sein (M 2.125,
M 2.129, M 2.128 und M 2.126).
4.
Betrieb der Datenbank
Die Inbetriebnahme und der eigentliche Betrieb des Datenbanksystems bedeuten neben der
Umsetzung des Konzeptes eine permanente Kontrolle des DBMS, um die Verfügbarkeit,
die Datenintegrität sowie den Schutz vertraulicher Daten sicherstellen zu können. Die
hierfür wichtigsten Maßnahmen betreffen die Punkte Dokumentation (M 2.25, M 2.31,
M 2.34), Administration (M 2.130, M 2.133 und die aufgeführten Maßnahmen für Hardund Software) sowie Nutzung der Datenbank (M 2.65, M 3.18).
5.
Notfallvorsorge
Neben den allgemein zu diesem Komplex gehörenden Maßnahmen gilt es insbesondere, die
datenbankspezifischen Gegebenheiten zu berücksichtigen, um bei einem System- respektive
Datenbankcrash den Anforderungen hinsichtlich des verkraftbaren Datenverlusts sowie der
Wiederanlaufzeit der Datenbank zu genügen (M 6.32, M 6.49, M 6.50).
Nachfolgend wird das Maßnahmenbündel für den Bereich Datenbanken vorgestellt.
Organisation:
- M 2.22 (2)
- M 2.25 (1)
- M 2.31 (1)
- M 2.34 (1)
- M 2.80 (1)
- M 2.111 (2)
- M 2.124 (1)
- M 2.125 (1)
- M 2.126 (1)
- M 2.127 (2)
- M 2.128 (1)
- M 2.129 (1)
- M 2.130 (1)
- M 2.131 (1)
- M 2.132 (1)
Hinterlegen des Paßwortes
Dokumentation der Systemkonfiguration
Dokumentation der Benutzer und Berechtigungsprofile
Dokumentation der Veränderungen an einem bestehenden System
Erstellung eines Anforderungskatalogs für Standardsoftware
Bereithalten von Handbüchern
Geeignete Auswahl einer Datenbank-Software
Installation und Konfiguration einer Datenbank
Erstellung eines Datenbanksicherheitskonzeptes
Inferenzprävention
Zugangskontrolle einer Datenbank
Zugriffskontrolle einer Datenbank
Gewährleistung der Datenintegrität
Aufteilung von Administrationstätigkeiten bei Datenbanksystemen
Regelung zur Einrichtung von Datenbankbenutzern/-benutzergruppen
Teil 1 - Kapitel 9.2 - Seite 4
Version 1998
IT-Grundschutzhandbuch
Datenbanken
- M 2.133 (2)
- M 2.134 (2)
- M 2.135 (3)
Kontrolle der Protokolldateien eines Datenbanksystems
Richtlinien für Datenbank-Anfragen
Gesicherte Datenübernahme in eine Datenbank
Personal:
- M 3.4
- M 3.5
- M 3.10
- M 3.11
Schulung vor Programmnutzung
Schulung zu IT-Sicherheitsmaßnahmen
Auswahl eines vertrauenswürdigen Administrators und Vertreters
Schulung des Wartungs- und Administrationspersonals
(1)
(1)
(1)
(1)
Hardware/Software:
- M 4.1 (1) Paßwortschutz für IT-Systeme
- M 4.7 (1) Änderung voreingestellter Paßwörter
- M 4.67 (3) Sperren und Löschen nicht benötigter Datenbank-Accounts
- M 4.68 (1) Sicherstellung einer konsistenten Datenbankverwaltung
- M 4.69 (2) Regelmäßiger Sicherheitscheck der Datenbank
- M 4.70 (3) Durchführung einer Datenbanküberwachung
- M 4.71 (2) Restriktive Handhabung von Datenbank-Links
- M 4.72 (2) Datenbank-Verschlüsselung (optional)
- M 4.73 (2) Festlegung von Obergrenzen für selektierbare Datensätze
Kommunikation:
- M 5.58 (1) Installation von ODBC-Treibern
Notfallvorsorge:
- M 6.32 (1)
- M 6.48 (2)
- M 6.49 (1)
- M 6.50 (1)
- M 6.51 (3)
Regelmäßige Datensicherung
Verhaltensmaßregeln nach Verlust der Datenbankintegrität
Datensicherung einer Datenbank
Archivierung von Datenbeständen
Wiederherstellung einer Datenbank
r
Version 1998
Teil 1 - Kapitel 9.2 - Seite 5
Datenbanken
G 1.1
IT-Grundschutzhandbuch
Personalausfall
Durch Krankheit, Unfall, Tod oder Streik kann ein nicht vorhersehbarer Personalausfall
entstehen. Desweiteren ist auch der Personalausfall bei einer regulären Beendigung des Arbeitsverhältnisses zu berücksichtigen, insbesondere wenn die Restarbeitszeit z. B. durch einen
Urlaubsanspruch verkürzt wird.
In allen Fällen kann die Konsequenz sein, daß entscheidende Aufgaben aufgrund des Personalausfalls im IT-Einsatz nicht mehr wahrgenommen werden. Dies ist besonders dann kritisch, wenn
die betroffene Person im IT-Bereich eine Schlüsselstellung einnimmt und aufgrund fehlenden
Fachwissens anderer nicht ersetzt werden kann. Störungen des IT-Betriebs können die Folge sein.
Beispiel: Aufgrund längerer Krankheit blieb der Netzadministrator vom Dienst fern. In der
betroffenen Firma lief das Netz zunächst fehlerfrei weiter. Nach zwei Wochen jedoch war
nach einem Systemabsturz niemand in der Lage, den Fehler zu beheben. Dies führte zu
einem Ausfall des Netzes über mehrere Tage.
Teil 1 - Kapitel 9.2 - Seite 6
Version 1998
IT-Grundschutzhandbuch
G 2.3
Datenbanken
Fehlende, ungeeignete, inkompatible Betriebsmittel
Eine nicht ausreichende Bereitstellung von Betriebsmitteln kann einen IT-Betrieb erheblich
beeinträchtigen. Störungen können sich aus einer nicht ausreichenden Menge benötigter Betriebsmittel oder deren nicht termingerechter Bereitstellung ergeben.
Ebenso kann es vorkommen, daß ungeeignete oder sogar inkompatible Betriebsmittel beschafft
werden, die infolgedessen nicht eingesetzt werden können.
Beispiele:
-
Für den neu angemieteten Datex-P-Anschluß wird vergessen, das Entgelt für die Einrichtung an den Betreiber zu überweisen mit der Folge, daß der Anschluß nicht freigeschaltet
wird. Das IT-Verfahren, das diesen Anschluß nutzen soll, kann daher nur mit Verspätung
in Betrieb genommen werden.
-
Ein ungeeignetes Betriebsmittel ist zum Beispiel eine graphische Benutzeroberfläche, die
auf einem nicht ausreichend leistungsfähigen Rechner installiert werden soll.
-
Ein Beispiel für inkompatible Betriebsmittel sind Verbindungskabel unterschiedlicher PinBelegung zum Anschluß von Druckern.
-
Für den Betrieb einer Datenbank unter der neu beschafften Datenbanken-Standardsoftware
ist im zugehörigen Rechner nicht genügend Hauptspeicher vorhanden oder der Plattenplatz
reicht nicht aus.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 7
Datenbanken
G 2.22
IT-Grundschutzhandbuch
Fehlende Auswertung von Protokolldaten
Protokolldaten dienen dem Zweck, nachträglich feststellen zu können, ob Sicherheitsverletzungen
im IT-System stattgefunden haben oder ob ein solcher Versuch unternommen wurde. Daher
können Protokolldaten für die Täterermittlung im Schadensfall genutzt werden. Eine weitere
wichtige Funktion der Protokolldaten ist die Abschreckung. Werden Protokolldaten regelmäßig
ausgewertet, können vorsätzliche Angriffe auf ein IT-System frühzeitig erkannt werden. Findet
die Auswertung der Protokolldaten jedoch nicht oder nur unzureichend statt und wird dies
bekannt, verliert sich die Abschreckungswirkung vollständig.
Teil 1 - Kapitel 9.2 - Seite 8
Version 1998
IT-Grundschutzhandbuch
G 2.26
Datenbanken
Fehlendes oder unzureichendes Software-Test- und
Freigabeverfahren
Wird neue Software nicht oder nur unzureichend getestet und ohne Installationsvorschriften
freigegeben, kann es passieren, daß Fehler in der Software nicht erkannt werden oder daß die
notwendigerweise einzuhaltenden Installationsparameter nicht erkannt bzw. nicht beachtet
werden. Diese Software- oder Installationsfehler, die aus einem fehlenden oder unzureichenden
Software-Test- und Freigabeverfahren resultieren, stellen eine erhebliche Gefährdung für den ITBetrieb dar.
Im Vertrauen auf eine problemlose Installation neuer Software wird oftmals übersehen, daß
mögliche Schäden in keinem Verhältnis zu dem Aufwand stehen, den ein geordnetes Test- und
Freigabeverfahren erfordert. Programme werden unzureichend getestet und mit Fehlern in eine
Produktionsumgebung eingebracht. Die Fehler wirken sich in der Folge störend auf den bis zu
diesem Zeitpunkt problemlosen Betrieb aus.
Beispiele für solche Schäden werden nachfolgend aufgezeigt:
-
Programme oder Programm-Updates lassen sich nicht sinnvoll nutzen, da für ein annehmbares Verarbeitungstempo mehr Ressourcen (z. B. Hauptspeicher, Prozessorkapazität) als erwartet benötigt werden. Wird dies nicht im Test erkannt, kann dies zu
erheblichen Fehl- oder Folgeinvestitionen führen. Nicht selten führten Entscheidungen
gegen weitere Investitionen dazu, daß ein Softwareprodukt zwar gekauft und bezahlt,
jedoch nie benutzt wurde.
-
Eingeübte Arbeitsabläufe werden nach Installation neuer Software maßgeblich behindert.
Der mit der Installation des Programms beabsichtigte Nutzen stellt sich erst bedeutend
später ein, da die Mitarbeiter im Vorfeld nicht geschult bzw. nicht über die neuen
Funktionen des Programms informiert wurden.
-
Durch das Einspielen eines neuen Updates einer DBMS-Standardsoftware, das mit Fehlern
behaftet ist, steht die Datenbank nicht mehr zur Verfügung und es kann zu einem
Datenverlust kommen.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 9
Datenbanken
G 2.38
IT-Grundschutzhandbuch
Fehlende oder unzureichende Aktivierung von DatenbankSicherheitsmechanismen
Jede Datenbank-Standardsoftware stellt in der Regel eine Reihe von Sicherheitsmechanismen
bereit, mittels derer die Daten vor unberechtigtem Zugriff o. ä. geschützt werden können. Sie sind
jedoch nicht unbedingt automatisch aktiv, sondern müssen vom Datenbank-Administrator
meistens manuell eingeschaltet werden. Wird davon kein Gebrauch gemacht, so kann weder die
Vertraulichkeit noch die Integrität der Daten gewährleistet werden. In diesem Fall ist es dann
meistens nicht möglich, solche Schutzverletzungen zu erkennen und zu protokollieren. Der
Verlust bzw. die Manipulation von Daten bis hin zur Zerstörung der Datenbank selbst kann die
Folge sein.
Beispiel: Bei der Datenbank MS Access ist die Aktivierung des Paßwortschutzes optional.
Hierdurch kann es auf einfache Weise zu einem unberechtigten Zugang zum
Datenbanksystem und damit auch zu einem unberechtigten Zugriff auf die dort
gespeicherten Daten kommen. Eine Kontrolle der Datenbanknutzung ist in diesem Fall
nicht möglich.
Teil 1 - Kapitel 9.2 - Seite 10
Version 1998
IT-Grundschutzhandbuch
G 2.39
Datenbanken
Komplexität eines DBMS
Die Auswahl und der Einsatz einer Datenbank-Standardsoftware erfordert sorgfältige Planung,
Installation und Konfiguration des Datenbank-Managementsystems (DBMS), um einen
störungsfreien Einsatz zu gewährleisten. Die Vielzahl möglicher Gefährdungen sollen durch die
nachfolgenden Beispiele verdeutlicht werden.
Auswahl einer ungeeigneten Datenbank-Standardsoftware
-
Es wird ein DBMS ausgewählt, welches in der geplanten Einsatzumgebung nicht lauffähig
ist. Dies kann daraus resultieren, daß das DBMS an ein bestimmtes Betriebssystem
gebunden ist oder die Mindestanforderungen an die Hardware nicht erfüllt werden.
-
Das ausgewählte DBMS stellt ein Sicherheitsrisiko dar, weil die vom Hersteller zur
Verfügung gestellten Sicherheitsmechanismen nicht ausreichen, um die geforderte
Verfügbarkeit, Integrität und Vertraulichkeit der Daten zu gewährleisten.
Fehlerhafte Installation bzw. Konfiguration der Datenbank-Standardsoftware
-
Es können sich weitere Gefährdungen ergeben, wenn die vom Hersteller empfohlenen
Sicherheitsmaßnahmen falsch oder gar nicht durchgeführt werden.
Beispiel: Die Kontrolldateien eines Datenbanksystems werden nicht gespiegelt bzw. die
gespiegelte Kontrolldatei wird nicht auf einer anderen Festplatte abgelegt. Ein Plattencrash
führt dabei unweigerlich zur Zerstörung der Datenbank.
-
Die physischeVerteilung der Daten ist unzureichend (falls das DBMS eine physikalische
Verteilung vorsieht).
Beispiel: In einer Oracle-Datenbank gibt es eine maximal zulässige Anzahl Dateien pro
Tablespace. Werden nun alle Daten im System-Tablespace verwaltet, so können keine
Dateien mehr hinzugefügt werden, wenn diese maximale Anzahl erreicht ist. Da im
System-Tablespace auch das Data Dictionary abgelegt ist, kann dieses Problem nur über
eine komplette Neu-Installation der Datenbank behoben werden.
-
Durch falsche Parametereinstellungen kann der Zugriff auf bestimmte Daten verhindert
werden.
Beispiel: Durch eine falsche Ländereinstellung in einer Datenbank-Software kann die
Darstellung von Umlauten unmöglich gemacht werden.
Fehlerhafte Konzeption der Datenbank
-
Fehlende Relationen zwischen einzelnen Tabellen können zu einem Verlust der
Datenkonsistenz bzw. der Datenbankintegrität führen.
-
Werden anwendungsspezifische Daten nicht physikalisch voneinander getrennt gespeichert,
kann ein Ausfall einer einzigen Festplatte zu einem Komplettausfall aller Anwendungen
führen.
-
Werden keine Datenbanktrigger oder Stored Procedures eingesetzt, kann es zu
Inkonsistenzen der Daten kommen, wenn die Anwendung dies nicht selbst berücksichtigt.
-
Durch eine mangelhafte Konzeption des Einsatzes von Datenbanktriggern und Stored
Procedures kann es zu einem Verlust der Datenintegrität oder unkontrollierten
Datenmanipulationen kommen.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 11
Datenbanken
G 2.40
IT-Grundschutzhandbuch
Komplexität des Datenbankzugangs/-zugriffs
Die Benutzer greifen über ein Datenbankmanagementsystem (DBMS) auf eine oder mehrere
Datenbanken zu. Dabei können sie dies direkt tun oder aber von einer Anwendung aus. Um die
Integrität einer Datenbank zu gewährleisten, müssen alle Datenbankzugriffe von einer zentralen
Stelle aus kontrolliert werden. Aufgrund der Komplexität solcher Zugriffe können die folgenden
Probleme entstehen.
Fehlerhafte Konzeption der Benutzerumgebung
-
Ist der Berechtigungsumfang für die Benutzer zu restriktiv definiert, kann dies dazu führen,
daß sie bestimmte Arbeiten nicht durchführen können.
-
Ist der Berechtigungsumfang für die Benutzer dagegen zu umfangreich, kann dies dazu
führen, daß Daten unberechtigt manipuliert bzw. eingesehen werden können. Dadurch
werden die Integrität und Vertraulichkeit der Datenbank verletzt.
-
Wird es den Benutzern erlaubt, direkt auf die Datenbank zuzugreifen (im Gegensatz zum
Zugriff aus einer Anwendung heraus), so besteht das Risiko des Integritätsverlustes der
Datenbank durch Datenmanipulationen, deren Auswirkungen die Benutzer nicht
abschätzen können.
-
Werden Datenbankobjekte von den darauf zugreifenden Anwendungen nicht explizit durch
ein entsprechendes Berechtigungs- und Zugriffskonzept geschützt, so besteht das Risiko,
daß die Datenbankobjekte selbst manipuliert werden (Manipulation von Feldern einer
Tabelle, Manipulation von Tabellen-Indizes etc.). Dies kann zur Zerstörung der Datenbank
führen.
Remote-Zugriff auf Datenbanken
-
Wird die Datenbank in einem Netz zur Verfügung gestellt, so können durch mangelnde
Sicherheitsvorkehrungen im Bereich des Remote-Zugriffs auf die Datenbank sowohl Daten
manipuliert als auch unberechtigt eingesehen werden. Auch dies verletzt die Integrität und
Vertraulichkeit der Datenbank.
Datenbankabfragen
-
Die Menge aller möglichen Datenbankabfragen muß für jeden Benutzer eingeschränkt sein
bzw. bestimmte Abfragen müssen explizit verboten werden. Ist dies nicht der Fall, kann
dies (insbesondere bei statistischen Datenbanken) zum Verlust der Vertraulichkeit
schutzbedürftiger Daten führen.
-
Werden Datenbankabfragen innerhalb einer Anwendung nicht gemäß des SQL-Standards
formuliert, so kann dies dazu führen, daß sie vom DBMS nicht bearbeitet werden können
und zurückgewiesen werden (insbesondere beim Einsatz von DBMS'en verschiedener
Hersteller).
-
Bei der Verwendung von nicht exakt formulierten Datenbankabfragen kann dies dazu
führen, daß durch eine Änderung der Datenbankobjekte die Datenbankabfrage plötzlich
falsche oder unerwartete Ergebnisse liefert.
Beispiel: Die Abfrage "SELECT * FROM Tabelle" liefert alle Attribute bzw. Felder eines
Tupels bzw. Datensatzes. Wird nun ein Feld in der Tabelle hinzugefügt oder gelöscht, so
hat dies u. U. fatale Auswirkungen auf eine Anwendung, in der eine solche Datenbankabfrage benutzt wird.
Teil 1 - Kapitel 9.2 - Seite 12
Version 1998
IT-Grundschutzhandbuch
G 2.41
Datenbanken
Mangelhafte Organisation des Wechsels von Datenbank-Benutzern
Teilen sich mehrere Benutzer einer Datenbank den gleichen Arbeitsplatz, so besteht die Gefahr
von ungewollten oder gezielten Datenmanipulationen, wenn der Wechsel zwischen den Benutzern
nicht organisiert ist bzw. der Wechsel nicht ordnungsgemäß durchgeführt wird. Auch ist dann die
Vertraulichkeit der Daten nicht mehr gewährleistet.
Beispiel: Wird eine Anwendung, die auf eine Datenbank zugreift, vor einem Benutzerwechsel
nicht ordnungsgemäß verlassen, so führen die unterschiedlichen Berechtigungsprofile der
betroffenen Benutzer zu den o. g. Gefährdungen. Auch wird dabei der
Protokollmechanismus der Datenbank unterlaufen, da dieser die Datenmodifikationen und
Aktivitäten der aktiven Benutzerkennung festhält. Diese Kennung stimmt aber in einem
solchen Fall nicht mit dem tatsächlichen Benutzer überein.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 13
Datenbanken
G 2.57
IT-Grundschutzhandbuch
Nicht ausreichende Speichermedien für den Notfall
Wenn Daten nach ihrer Zerstörung wiederhergestellt werden müssen, ist es vielen Fällen
notwendig, die gesicherten Daten zunächst auf getrennten Speichermedien wiedereinzuspielen.
Dies ist insbesondere bei komplexeren Datenstrukturen wie z. B. bei Datenbanken notwendig, da
die Wiederherstellung nicht immer reibungslos und fehlerfrei funktioniert. Wird die hierfür
benötigte Speicherkapazität nicht für den Notfall vorgehalten, kann es durch übereiltes Handeln
während des Notfalls zu weiteren Datenverlusten kommen.
Beispiel: In einem Unternehmen mit einer großer Datenbank-Applikation wurde die Datenbank
als inkonsistent vom Datenbankmanagementsystem (DBMS) gemeldet. Daraufhin nahm
das Systemmanagement die Datenbank außer Betrieb und restaurierte den letzten
gesicherten Datenbestand im Produktionssystem. Von der scheinbar korrupten Datenbank
wurden nur Log- und Konfigurationsdateien vorher gesichert. Durch diese Aktion gingen
alle Datenänderungen seit der letzten Sicherung verloren, da aufgrund eines bis dahin
unbekannten Fehlers im DBMS das Nachfahren der Änderungen nicht möglich war. Die
Analyse der Log- und Konfigurationsdateien ergab dann, daß die Datenbank in
Wirklichkeit gar nicht inkonsistent gewesen war. Hätte ausreichend Plattenplatz zur
Verfügung gestanden, um die Rekonstruktion parallel durchzuführen, wäre das alte
produktive System ohne Datenverlust nach Erkennung und Behebung der nur scheinbaren
Inkonsistenz wieder einsatzbereit gewesen.
Teil 1 - Kapitel 9.2 - Seite 14
Version 1998
IT-Grundschutzhandbuch
G 3.6
Datenbanken
Gefährdung durch Reinigungs- oder Fremdpersonal
Die Gefährdung durch Reinigungs- und Fremdpersonal erstreckt sich von der unsachgemäßen
Behandlung der technischen Einrichtungen, über den Versuch des "Spielens" am IT-System ggf.
bis zum Diebstahl von IT-Komponenten.
Beispiele: Durch Reinigungspersonal kann versehentlich eine Steckverbindung gelöst werden,
Wasser kann in Geräte gelangen, Unterlagen können verlegt oder sogar mit dem Abfall
entfernt werden.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 15
Datenbanken
G 3.16
IT-Grundschutzhandbuch
Fehlerhafte Administration von Zugangs- und Zugriffsrechten
Zugangsrechte zu einem IT-System und Zugriffsrechte auf gespeicherte Daten und IT-Anwendungen dürfen nur in dem Umfang eingeräumt werden, wie sie für die Wahrnehmung der Aufgaben erforderlich sind. Werden diese Rechte fehlerhaft administriert, so kommt es zu
Betriebsstörungen, falls erforderliche Rechte nicht zugewiesen wurden, bzw. zu Sicherheitslücken, falls über die notwendigen Rechte hinaus weitere vergeben werden.
Beispiel: Durch eine fehlerhafte Administration der Zugriffsrechte hat ein Sachbearbeiter die
Möglichkeit, auf die Protokolldaten zuzugreifen. Durch gezieltes Löschen einzelner Einträge ist es ihm daher möglich, seine Manipulationsversuche am Rechner zu verschleiern,
da sie in der Protokolldatei nicht mehr erscheinen.
Teil 1 - Kapitel 9.2 - Seite 16
Version 1998
IT-Grundschutzhandbuch
G 3.23
Datenbanken
Fehlerhafte Administration eines DBMS
Wird ein Datenbankmanagementsystem (DBMS) nachlässig oder fehlerhaft administriert, kann
dies folgende Gefährdungen nach sich ziehen:
-
Verlust von Daten,
-
(gezielte oder unbeabsichtigte) Datenmanipulation,
-
unberechtigter Zugang zu vertraulichen Daten,
-
Verlust der Datenbankintegrität,
-
Crash der Datenbank und
-
Zerstörung der Datenbank.
Die oben aufgeführten Gefährdungen können durch zu großzügig vergebene Rechte für die
Benutzer, durch eine unregelmäßige oder gar keine Datenbanküberwachung, durch mangelhafte
Datensicherungen, durch ungültige, aber noch nicht gesperrte Kennungen usw. hervorgerufen
werden.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 17
Datenbanken
G 3.24
IT-Grundschutzhandbuch
Unbeabsichtigte Datenmanipulation
Je umfangreichere Zugriffsberechtigungen auf eine Datenbank für die Anwender bestehen, um so
größer ist auch das Risiko einer unbeabsichtigten Datenmanipulation. Dies kann prinzipiell von
keiner Anwendung verhindert werden. Die grundsätzlichen Ursachen für unbeabsichtigte
Datenmanipulationen können z. B. sein:
-
mangelhafte oder fehlende Fachkenntnisse,
-
mangelhafte oder fehlende Kenntnisse der Anwendung,
-
zu umfangreiche Zugriffsberechtigungen und
-
Fahrlässigkeit (z. B. das Verlassen des Arbeitsplatzes ohne korrekte Beendigung der
Anwendung).
Teil 1 - Kapitel 9.2 - Seite 18
Version 1998
IT-Grundschutzhandbuch
G 4.26
Datenbanken
Ausfall einer Datenbank
Steht eine Datenbank, z. B. aufgrund von Hardware- oder Software-Problemen bzw. durch
Sabotage, nicht mehr zur Verfügung, so kann dies je nach Einsatzzweck und Bedeutung der
Datenbank weitreichende Folgen haben. Sämtliche Anwendungen, die auf die Daten der
Datenbank angewiesen sind, können nicht mehr benutzt werden und fallen ebenfalls aus. Die
Benutzer solcher Anwendungen können ihre Aufgaben nur noch teilweise oder gar nicht mehr
wahrnehmen, falls sie diese nicht mit manuellen Mitteln erfüllen können. Je nach Art der
Aufgaben, die nur mittels IT-Unterstützung unter Benutzung der Datenbank ausgeführt werden
können, sind folgende Konsequenzen möglich:
-
wirtschaftlicher Schaden,
-
Sicherheitsrisiken, die bis hin zu Beeinträchtigungen im persönlichen Bereich führen
können (z. B. bei medizinischen Datenbanken),
-
bedingte oder komplette Handlungsunfähigkeit.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 19
Datenbanken
G 4.27
IT-Grundschutzhandbuch
Unterlaufen von Zugriffskontrollen über ODBC
Existierende Zugangs- oder Zugriffskontrollen einer Datenbank können unterlaufen werden, wenn
auf die Datenbank außerhalb einer Anwendung über ODBC (Open Database Connectivity)
zugegriffen wird und bei der Installation der ODBC-Treiber Fehler gemacht wurden. In diesem
Fall kann ein Schutz vertraulicher Daten nicht mehr gewährleistet werden, ebenso ist auch die
Manipulation von Daten ohne weiteres möglich.
Teil 1 - Kapitel 9.2 - Seite 20
Version 1998
IT-Grundschutzhandbuch
G 4.28
Datenbanken
Verlust von Daten einer Datenbank
Ein Verlust von Daten einer Datenbank kann auf vielfältige Art und Weise verursacht werden.
Dies kann sich von ungewollten Datenmanipulationen (z. B. durch das unbeabsichtigte Löschen
von Daten) über einen Verlust durch einen Crash der Datenbank bis hin zu gezielten Angriffen
erstrecken.
Dadurch ist die Verfügbarkeit und die Vollständigkeit der Daten nicht mehr gewährleistet, und es
kann zu folgenden Konsequenzen kommen:
-
Bestimmte Anwendungen, die auf die Daten der Datenbank angewiesen sind, können ggf.
nicht mehr oder nicht mehr in vollem Umfang ausgeführt werden.
-
Der Informationsgehalt der Daten in ihrer Gesamtheit geht verloren.
-
Es entsteht ein hoher Aufwand, um die zerstörten Daten wiederzubeschaffen.
Je nach Ursache des Datenverlustes kann es schwer bis unmöglich sein festzustellen, welche
Daten nicht mehr vorhanden sind. Dies kann weitere wirtschaftliche Schäden oder
Sicherheitsrisiken nach sich ziehen.
Beispiel: Bei Änderungen des Datenmodells müssen zunächst die alten Tabellen und Strukturen
gesichert und dann gelöscht werden. Anschließend werden die neuen Tabellen angelegt.
Danach müssen die alten Datenbestände konvertiert und in die geänderten Tabellen
eingespielt werden. Durch Fehler bei diesen Abläufen kann es schnell passieren, daß Daten
verloren gehen oder sich nicht mehr einspielen lassen.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 21
Datenbanken
G 4.29
IT-Grundschutzhandbuch
Datenverlust einer Datenbank bei erschöpftem Speichermedium
Jedes Speichermedium kann nur begrenzt viele Daten aufnehmen. Dies gilt auch für eine
Datenbank, die für die dauerhafte Speicherung ihrer Daten auf ein physikalisches
Speichermedium zurückgreifen muß. Ist dieses erschöpft, kann es zu einem Crash der Datenbank
und einem Verlust von Daten kommen. Die sich daraus ergebenden Konsequenzen werden in
G 4.28 Verlust von Daten einer Datenbank beschrieben.
Die Kapazität des Speichermediums kann aus verschiedenen Gründen plötzlich erschöpft sein,
z. B. durch Fehler in Anwendungsprogrammen, erhöhtem Speicherbedarf der Benutzer oder auch
durch einen gezielten Angriff, bei dem vorsätzlich der vorhandene Speicherplatz reduziert wird,
um z. B. eine Protokollierung zu verhindern.
Teil 1 - Kapitel 9.2 - Seite 22
Version 1998
IT-Grundschutzhandbuch
G 4.30
Datenbanken
Verlust der Datenbankintegrität/-konsistenz
Ein Verlust der Datenbankintegrität/-konsistenz bedeutet, daß die Daten in der Datenbank zwar
noch vorhanden sind, aber einen fehlerhaften oder sinnlosen Wert angenommen haben. Dadurch
können die Daten nicht mehr korrekt verarbeitet werden. Dies kann auf vielfältige Art und Weise
verursacht werden, von ungewollten Datenmanipulationen (z. B. durch das unbeabsichtigte
Ändern von Daten) über eine fehlerhafte Synchronisationskontrolle der Transaktionen bis hin zu
gezielten Angriffen.
Dadurch kann es zu folgenden Konsequenzen kommen:
-
Bestimmte Aufgaben, die auf die korrekten Daten der Datenbank angewiesen sind, können
ggf. nicht mehr oder nicht mehr in vollem Umfang durchgeführt werden.
-
Der Informationsgehalt der Daten in ihrer Gesamtheit wird verfälscht.
-
Es entsteht ein hoher Aufwand, um die Datenintegrität und Datenkonsistenz der Datenbank
wiederherzustellen.
Je nach Ursache der Verletzung der Datenbankintegrität/-konsistenz kann es schwer bis
unmöglich sein festzustellen, welche Daten verändert wurden. Dies kann weitere wirtschaftliche
Schäden oder Sicherheitsrisiken nach sich ziehen.
Beispiel: Aus Platzmangel und Zeitdruck wurde auf einem Unix-Server eine Datei einer
Datenbank im /tmp-Dateisystem angelegt. Dieses wurde durch einen cron-Job über Nacht
gelöscht, so daß daraufhin die gesamte Datenbank nicht mehr nutzbar war.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 23
Datenbanken
G 5.9
IT-Grundschutzhandbuch
Unberechtigte IT-Nutzung
Ohne Mechanismen zur Identifikation und Authentisierung von Benutzern ist die Kontrolle über
unberechtigte IT-Nutzung praktisch nicht möglich. Selbst bei IT-Systemen mit einer
Identifikations- und Authentisierungsfunktion in Form von Benutzer-ID- und Paßwort-Prüfung ist
eine unberechtigte Nutzung denkbar, wenn Paßwort und zugehörige Benutzer-ID ausgespäht
werden.
Um das geheimgehaltene Paßwort zu erraten, können Unbefugte innerhalb der Login-Funktion ein
mögliches Paßwort eingeben. Die Reaktion des IT-Systems gibt anschließend Aufschluß darüber,
ob das Paßwort korrekt war oder nicht. Auf diese Weise können Paßwörter durch Ausprobieren
erraten werden.
Viel erfolgversprechender ist jedoch die Attacke, ein sinnvolles Wort als Paßwort anzunehmen
und alle Benutzereinträge durchzuprobieren. Bei entsprechend großer Benutzeranzahl wird damit
oft eine gültige Kombination gefunden.
Falls die Identifikations- und Authentisierungsfunktion mißbräuchlich nutzbar ist, so können
sogar automatisch Versuche gestartet werden, indem ein Programm erstellt wird, das systematisch alle möglichen Paßwörter testet.
Beispiel: 1988 nutzte der Internet-Wurm eine Schwachstelle der betroffenen Unix-Betriebssysteme aus, um gültige Paßwörter zu finden, obwohl die gültigen Paßwörter verschlüsselt
gespeichert waren. Dazu probierte ein Programm sämtliche Eintragungen eines
Wörterbuches aus, indem es sie mit der zur Verfügung stehenden Chiffrierfunktion
verschlüsselte und mit den abgespeicherten verschlüsselten Paßwörtern verglich. Sobald
eine Übereinstimmung gefunden war, war auch ein gültiges Paßwort erkannt.
Teil 1 - Kapitel 9.2 - Seite 24
Version 1998
IT-Grundschutzhandbuch
G 5.10
Datenbanken
Mißbrauch von Fernwartungszugängen
Bei unzureichend gesicherten Fernwartungszugängen ist es denkbar, daß Hacker Zugang zum
Administrierungsport des IT-Systems erlangen. Sie können somit nach Überwindung des
Anlagenpaßwortes ggf. alle Administrationstätigkeiten ausüben. Der entstehende Schaden kann
sich vom vollständigen Anlagenausfall, über schwerste Betriebsstörungen, den Verlust der
Vertraulichkeit aller auf der Anlage vorhandenen Daten bis hin zum großen direkten finanziellen
Schaden erstrecken.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 25
Datenbanken
G 5.18
IT-Grundschutzhandbuch
Systematisches Ausprobieren von Paßwörtern
Zu einfache Paßwörter lassen sich durch systematisches Ausprobieren herausfinden.
Beispiel: Eine Untersuchung von Klein (Klein, Daniel V. 1990, USENIX Security Workshop
Proceedings, Portland August 1990) an 15000 Accounts ergab eine Erfolgsquote von
24,2 %, wobei folgende Möglichkeiten für ein Paßwort ausprobiert wurden:
ca. 130 Variationen des Login Namens (Vor- und Zuname) und anderer persönlicher Daten
aus dem /etc/passwd File, häufige Namen, Namen von bekannten Personen, Namen und
Orte aus Filmen, von Sportereignissen und aus der Bibel, gebräuchliche Schimpfwörter
und Wörter aus Fremdsprachen, verschiedene Variationen dieser Wörter, wie z. B.
Umwandlung Groß-Kleinschreibung, Einfügen von Sonder- und Kontrollzeichen,
Umkehrung der Buchstabenreihenfolge, wiederholte Buchstaben (z. B. aaabbb) oder
häufige Abkürzungen (z. B. rggbv für die Farben des Regenbogens) und Paare aus zwei
kurzen Wörtern.
Alle diese Kombinationen und mehr lassen sich mit Hilfe des Public Domain Programms crack
von jedem Benutzer eines Unix-Systems, auf dem die Paßwortdatei frei zugänglich ist,
ausprobieren. Darüber hinaus ist die Wahrscheinlichkeit, ein Paßwort durch systematisches
Probieren aller Kombinationen zu finden, bei zu kurzen Paßwörtern groß.
Teil 1 - Kapitel 9.2 - Seite 26
Version 1998
IT-Grundschutzhandbuch
G 5.64
Datenbanken
Manipulation an Daten oder Software bei Datenbanksystemen
Durch ein gezieltes Manipulieren von Daten werden diese vorsätzlich verfälscht oder
unbrauchbar gemacht. Die entsprechenden Folgen sind in G 4.28 Verlust von Daten einer
Datenbank und G 4.30 Verlust der Datenbankintegrität/-konsistenz beschrieben.
Werden die Dateien einer Datenbank oder der Datenbankstandardsoftware gezielt gelöscht oder
verändert, so führt dies zur vorsätzlichen Zerstörung des gesamten Datenbanksystems (siehe
G 4.26 Ausfall einer Datenbank).
Es ist prinzipiell nicht verhinderbar, daß Benutzer mit den entsprechenden Zugangs- und
Zugriffsberechtigungen gezielt Datenmanipulationen durchführen oder eine Datenbank zerstören
können. Ist es außerdem möglich, die Zugangs- und Zugriffsberechtigungen zu umgehen (z. B.
durch eine fehlerhafte Administration des DBMS), so können sich auch unberechtigte Benutzer
Zugang zur Datenbank verschaffen und dort Manipulationen vornehmen.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 27
Datenbanken
G 5.65
IT-Grundschutzhandbuch
Verhinderung der Dienste eines Datenbanksystems
Ein solcher Angriff zielt darauf ab, die IT-Benutzer daran zu hindern, die Funktionen und Dienste
eines Datenbanksystems benutzen zu können, die ihnen normalerweise zur Verfügung stehen.
Neben den in G 5.28 Verhinderung von Diensten aufgeführten Beispielen, kann dies im Bereich
Datenbanken zusätzlich z. B. dadurch erreicht werden, daß große Datenmengen selektiert werden,
deren Auswertung das gesamte Datenbanksystem lahmlegt, oder daß die Datensätze durch
Sperren blockiert werden.
Teil 1 - Kapitel 9.2 - Seite 28
Version 1998
IT-Grundschutzhandbuch
M 2.22
Datenbanken
Hinterlegen des Paßwortes
Verantwortlich für Initiierung: Leiter IT
Verantwortlich für Umsetzung: IT-Benutzer
Ist der Zugriff auf ein IT-System durch ein Paßwort geschützt, so müssen Vorkehrungen getroffen werden, die bei Abwesenheit eines Mitarbeiters, z. B. im Urlaubs- oder Krankheitsfall, seinem
Vertreter den Zugriff auf das IT-System ermöglichen. Zu diesem Zweck ist das aktuelle Paßwort
durch jeden Mitarbeiter an einer geeigneten Stelle (in einem geschlossenen Umschlag) zu
hinterlegen und bei jeder Änderung des Paßwortes zu aktualisieren. Wird es notwendig, dieses
hinterlegte Paßwort zu nutzen, so sollte dies nach dem Vier-Augen-Prinzip, d. h. von zwei Personen gleichzeitig, geschehen.
Bei einem Telearbeiter ist sicherzustellen, daß dessen Paßwörter auch in der Institution hinterlegt
werden, damit im Notfall sein Vertreter auf die im Telearbeitsrechner gespeicherten Daten
zugreifen kann.
Bei allen von Administratoren betreuten Systemen, insbesondere bei vernetzten Systemen, ist
durch regelmäßige Überprüfung sicherzustellen, daß das aktuelle Systemadministrator-Paßwort
hinterlegt ist.
Ergänzende Kontrollfragen:
-
Sind die hinterlegten Paßwörter vollständig und aktuell?
-
Ist die ordnungsgemäße Verwendung eines hinterlegten Paßwortes geregelt?
-
Wird anhand der Aktualisierungen der hinterlegten Paßwörter die Wechselsystematik
kontrolliert?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 29
Datenbanken
M 2.25
IT-Grundschutzhandbuch
Dokumentation der Systemkonfiguration
Verantwortlich für Initiierung: IT-Sicherheitsmanagement, Leiter IT
Verantwortlich für Umsetzung: Administrator
Planung, Steuerung, Kontrolle und Notfallvorsorge des IT-Einsatzes basieren auf einer aktuellen
Dokumentation des vorhandenen IT-Systems. Nur eine aktuelle Dokumentation der
Systemkonfiguration ermöglicht im Notfall einen geordneten Wiederanlauf des IT-Systems.
Bei einem Netzbetrieb ist die physikalische Netzstruktur (vgl. M 5.4 Dokumentation und
Kennzeichnung der Verkabelung) und die logische Netzkonfiguration zu dokumentieren. Dazu
gehören auch die Zugriffsrechte der einzelnen Benutzer (siehe M 2.31 Dokumentation der
zugelassenen Benutzer und Rechteprofile) und der Stand der Datensicherung. Dabei ist auf
Aktualität und Verständlichkeit der Dokumentation zu achten, damit auch ein Vertreter die
Administration jederzeit weiterführen kann, ebenso wie auf eine sichere Aufbewahrung der
Unterlagen, um deren Verfügbarkeit im Bedarfsfall zu gewährleisten.
Ergänzende Kontrollfragen:
-
Ist die vorhandene Dokumentation aktuell?
-
Kann aufgrund der Dokumentation die Administration weitergeführt werden?
Teil 1 - Kapitel 9.2 - Seite 30
Version 1998
IT-Grundschutzhandbuch
M 2.31
Datenbanken
Dokumentation der zugelassenen Benutzer und Rechteprofile
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Die Dokumentation dient der Übersicht über die zugelassenen Benutzer, Benutzergruppen und
Rechteprofile und ist Voraussetzung für Kontrollen.
Es soll jede der folgenden drei Dokumentationsmöglichkeiten genutzt werden:
-
vorgegebene Administrationsdateien des Systems,
-
individuelle Dateien, die vom zuständigen Administrator verwaltet werden,
-
in Papierform.
Dokumentiert werden sollen insbesondere
-
die zugelassenen Benutzer mit folgenden Angaben: zugeordnetes Rechteprofil (ggf. Abweichungen vom verwendeten Standard-Rechteprofil), Begründung für die Wahl des Rechteprofils (und ggf. der Abweichungen), Erreichbarkeit des Benutzers, Zeitpunkt und Grund
der Einrichtung, Befristungen,
-
die zugelassenen Gruppen mit den zugehörigen Benutzern, Zeitpunkt und Grund der Einrichtung, Befristung.
Ergänzende Kontrollfragen:
-
Sind Aufzeichnungen über die zugelassenen Benutzer und Gruppen und deren Rechteprofile vorhanden?
-
Sind die Aufzeichnungen aktuell?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 31
Datenbanken
M 2.34
IT-Grundschutzhandbuch
Dokumentation der Veränderungen an einem bestehenden System
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Um einen reibungslosen Betriebsablauf zu gewährleisten, muß der Administrator einen Überblick
über das System haben bzw. sich verschaffen können. Dieses muß auch für seinen Vertreter
möglich sein, falls der Administrator unvorhergesehen ausfällt. Der Überblick ist auch Voraussetzung, um Prüfungen des Systems (z. B. auf problematische Einstellungen, Konsistenz bei
Änderungen) durchführen zu können.
Daher sollten die Veränderungen, die Administratoren am System vornehmen, dokumentiert
werden, nach Möglichkeit automatisiert. Dieses gilt insbesondere für Änderungen an Systemverzeichnissen und -dateien.
Bei Installation neuer Betriebssysteme oder bei Updates sind die vorgenommenen Änderungen
besonders sorgfältig zu dokumentieren. Möglicherweise kann durch die Aktivierung neuer oder
durch die Änderung bestehender Systemparameter das Verhalten das Verhalten des IT-Systems
(insbesondere auch Sicherheitsfunktionen) maßgeblich verändert werden.
Unter Unix müssen ausführbare Dateien, auf die auch andere Benutzer als der Eigentümer
Zugriff haben oder deren Eigentümer root ist, vom Systemadministrator freigegeben und dokumentiert werden (siehe auch M 2.9 Nutzungsverbot nicht freigegebener Software). Insbesondere
müssen Listen mit den freigegebenen Versionen dieser Dateien geführt werden, die außerdem
mindestens das Erstellungsdatum, die Größe jeder Datei und Angaben über evtl. gesetzte s-Bits
enthalten. Sie sind Voraussetzung für den regelmäßigen Sicherheitscheck und für Überprüfungen
nach einem Verlust der Integrität.
Ergänzende Kontrollfragen:
-
Werden Logbücher über Systemveränderungen geführt?
-
Sind die Aufzeichnungen aktuell und vollständig?
-
Kann aufgrund der Aufzeichnungen die Administration weitergeführt werden?
Teil 1 - Kapitel 9.2 - Seite 32
Version 1998
IT-Grundschutzhandbuch
M 2.80
Datenbanken
Erstellung eines Anforderungskataloges für Standardsoftware
Verantwortlich für Initiierung: Leiter Fachabteilung
Verantwortlich für Umsetzung: Fachabteilung, Leiter IT
Zur Lösung einer Aufgabe, die mit IT bearbeitet wird, bietet der Markt meist eine Vielzahl
gleichartiger Standardsoftwareprodukte an. In ihrer Grundfunktionalität vergleichbar,
unterscheiden sie sich jedoch in Kriterien wie Anschaffungs- und Betriebskosten,
Zusatzfunktionalitäten, Kompatibilität, Administration, Ergonomie und IT-Sicherheit.
Anforderungskatalog
Für die Auswahl eines geeigneten Produktes muß daher zunächst ein Anforderungskatalog erstellt
werden. Der Anforderungskatalog sollte u. a. zu den folgenden Punkten Aussagen enthalten:
-
Funktionale Anforderungen, die das Produkt zur Unterstützung der Aufgabenerfüllung
der Fachabteilung erfüllen muß. Die für die Fachaufgabe relevanten Einzelfunktionalitäten
sollten hervorgehoben werden.
Verkürzte Beispiele:
- Textverarbeitung mit den Zusatzfunktionen Einbinden von Graphiken,
Makroprogrammierung,
Rechtschreibprüfung
und
Silbentrennung.
Makroprogrammierung muß abschaltbar sein, Rechtschreibprüfung muß in Englisch,
Französisch und Deutsch verfügbar sein. Die spezifizierten Textformate müssen imund exportiert werden können.
- Datenbank (Front-End und Back-End) für Multi-User-Betrieb mit Unterstützung der
Standardabfragesprache SQL und graphischer Bedienoberfläche
- Terminplaner
zur
Koordinierung
und
Kontrolle
von
Terminen
der
Abteilungsangehörigen mit integrierter Terminabstimmung, automatischem Versand
von Einladungen und Aufgaben- und Prioritäten-Listen, Schnittstelle zum hausinternen
Mailprogramm
-
IT-Einsatzumgebung, diese wird einerseits beschrieben durch die Rahmenbedingungen,
die durch die vorhandene oder geplante IT-Einsatzumgebung vorgegeben werden, und
andererseits durch die Leistungsanforderungen, die durch das Produkt an die
Einsatzumgebung vorgegeben werden.
Verkürzte Beispiele:
- Vorgegebene IT-Einsatzumgebung: Unter Novell 3.11 vernetzter PC, 80486-Prozessor,
8 MB Hauptspeicher, 500 MB Festplattenkapazität, Diskettenlaufwerk, CD-ROMLaufwerk, MS-DOS 6.0, Produkt darf maximal 50 MB der Festplatte belegen, es muß
unter Windows 3.11 laufen und netztauglich sein.
-
-
Leistungsanforderungen: Das Textverarbeitungsprogramm X benötigt 16 MB
Festplattenplatz, läuft auf einem PC ab 80386-Prozessor, 8 MB Hauptspeicher,
Windows 3.11.
Kompatibilitätsanforderungen zu anderen Programmen oder IT-Systemen, also
Migrationsunterstützung und Aufwärts- und Abwärtskompatibilität.
Verkürzte Beispiele:
Version 1998
Teil 1 - Kapitel 9.2 - Seite 33
Datenbanken
IT-Grundschutzhandbuch
- Datenbestände aus der vorhandenen Datenbank XYZ müssen übernommen werden
können.
- Die Funktionen A, B, C müssen bei Versionswechseln erhalten bleiben.
- Der Datenaustausch mit dem Unix-System XYZ muß möglich sein.
-
Performanceanforderungen beschreiben die erforderlichen Leistungen hinsichtlich
Durchsatz und Laufzeitverhalten. Für die geforderten Funktionen sollten möglichst genaue
Angaben über die maximal zulässige Bearbeitungszeit getroffen werden.
Verkürzte Beispiele:
- Die maximale Antwortzeit bei Ausführung von Funktion X darf 2 Sekunden nicht
überschreiten.
- Die Verschlüsselungsrate sollte auf einem 486 DX 33 mindestens 60 KB/sec betragen.
- Andere gleichzeitig verarbeitete Prozesse dürfen durch das Produkt maximal um 30%
verlangsamt werden.
-
Interoperabilitätsanforderungen, d. h. die Zusammenarbeit mit anderen Produkten über
Plattformgrenzen hinweg muß möglich sein.
Verkürzte Beispiele:
- Versionen des Textverarbeitungsprogramms sollen für Windows-, Unix- und
Macintosh-Plattformen verfügbar sein. Dokumente sollen auf einem Betriebssystem
erstellt und auf einem anderen weiterverarbeitet werden können.
- Das Textverarbeitungsprogramm
zusammenarbeiten können.
-
muß
mit
dem
eingesetzten
Zuverlässigkeitsanforderungen betreffen die Stabilität des
Fehlererkennung und Toleranz sowie Ausfall- und Betriebssicherheit.
Mailprogramm
Produktes,
also
Verkürzte Beispiele:
- Fehleingaben des Benutzers müssen erkannt werden und dürfen nicht zum
Programmabbruch oder Systemabsturz führen.
- Die Datenbank muß über Mechanismen verfügen, die es erlauben, bei einem
Systemabbruch mit Zerstörung der Datenbank alle Transaktionen zu rekonstruieren
(Roll-Forward).
-
Konformität zu Standards, dies können internationale Normen, De-facto-Standards oder auch
Hausstandards sein.
Verkürzte Beispiele:
-
Das Produkt muß der EU-Bildschirmrichtlinie 90/270/EWG entsprechen.
- Die Implementation eines Token-Ring-LANs muß konform sein zur Norm ENV 41110.
- Das Produkt muß dem X/Open-Standard entsprechen.
-
Einhaltung von internen Regelungen und gesetzlichen Vorschriften (z. B. ausreichender
Datenschutz bei der Verarbeitung personenbezogener Daten)
Teil 1 - Kapitel 9.2 - Seite 34
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Verkürzte Beispiele:
- Das
Produkt
muß
den
Buchführungssysteme genügen.
Grundsätzen
ordnungsmäßiger
DV-gestützter
- Da personenbezogene Daten verarbeitet werden, müssen die Bestimmungen des
Bundesdatenschutzgesetzes mit den implementierten Funktionen erfüllt werden können.
-
Anforderungen an die Benutzerfreundlichkeit, die durch die leichte Bedienbarkeit,
Verständlichkeit und Erlernbarkeit gekennzeichnet ist, also insbesondere durch die Güte
der Benutzeroberfläche sowie die Qualität der Benutzerdokumentation und der
Hilfefunktionen.
Verkürzte Beispiele:
- Eine Online-Hilfefunktion muß implementiert sein.
- Die Benutzeroberfläche muß so gestaltet sein, daß ungelernte Kräfte innerhalb von
zwei Stunden in die Benutzung eingewiesen werden können.
- Die Benutzerdokumentation und die Benutzeroberfläche sollten in der Landessprache
vorliegen.
-
Anforderungen an die Wartbarkeit ergeben sich für den Anwender hauptsächlich aus der
Fehlerbehandlung des Produktes.
Verkürzte Beispiele:
- Der Administrationsaufwand darf nicht zu hoch sein.
- Der Anbieter muß eine Hotline für Fragen anbieten.
- Das Produkt muß einfach zu installieren und zu konfigurieren sein.
- Das Produkt muß einfach zu deinstallieren sein.
-
die Obergrenze der Kosten, die durch die Beschaffung dieses Produktes verursacht
würden, werden vorgegeben. Dabei müssen nicht nur die unmittelbaren
Beschaffungskosten für das Produkt selber einbezogen werden, sondern auch Folgekosten,
wie z. B. eine Aufrüstung der Hardware, Personalkosten oder notwendige Schulungen.
Verkürzte Beispiele:
- Das Produkt darf maximal 15000.- DM kosten.
- Die Schulungskosten dürfen 2000.- DM nicht überschreiten
-
Aus den Anforderungen an die Dokumentation muß hervorgehen, welche Dokumente in
welcher Güte (Vollständigkeit, Verständlichkeit) erforderlich sind.
Verkürzte Beispiele:
- Die Benutzerdokumentation muß leicht nachvollziehbar und zum Selbststudium
geeignet sein. Die gesamte Funktionalität des Produktes ist zu beschreiben.
- Die Systemverwalterdokumentation muß Handlungsanweisungen für mögliche Fehler
enthalten.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 35
Datenbanken
-
IT-Grundschutzhandbuch
Bezüglich der Softwarequalität können Anforderungen gestellt werden, die von Herstellererklärungen über das eingesetzten Qualitätssicherungsverfahren, über ISO 9000 ff.
Zertifikate bis hin zu unabhängigen Softwareprüfungen nach ISO 12119 reichen.
Verkürzte Beispiele:
- Der Softwareerstellungsprozeß des Herstellers muß nach ISO 9000 zertifiziert sein.
- Die Funktionalität des Produktes muß unabhängig gemäß ISO 12119 überprüft worden
sein.
-
Sollen durch das Produkt IT-Sicherheitsfunktionen erfüllt werden, sind sie in Form von
Sicherheitsanforderungen zu formulieren (vgl. M 4.42 Implementierung von
Sicherheitsfunktionalitäten in der IT-Anwendung). Dies wird nachfolgend noch
ausführlich erläutert.
Sicherheitsanforderungen
Abhängig davon, ob das Produkt Sicherheitseigenschaften bereitstellen muß, können im
Anforderungskatalog Sicherheitsfunktionen aufgeführt werden. Typische Sicherheitsfunktionen,
die hier in Frage kommen, seien kurz erläutert. Weitere Ausführungen findet man in den ITSEC.
-
Identifizierung und Authentisierung
In vielen Produkten wird es Anforderungen geben, diejenigen Benutzer zu bestimmen und zu
überwachen, die Zugriff auf Betriebsmittel haben, die vom Produkt kontrolliert werden. Dazu muß nicht
nur die behauptete Identität des Benutzers festgestellt, sondern auch die Tatsache nachgeprüft werden,
daß der Benutzer tatsächlich die Person ist, die er zu sein vorgibt. Dies geschieht, indem der Benutzer
dem Produkt Informationen liefert, die fest mit dem betreffenden Benutzer verknüpft sind.
-
Zugriffskontrolle
Bei vielen Produkten wird es erforderlich sein sicherzustellen, daß Benutzer und Prozesse, die für diese
Benutzer tätig sind, daran gehindert werden, Zugriff auf Informationen oder Betriebsmittel zu erhalten,
für die sie kein Zugriffsrecht haben oder für die keine Notwendigkeit zu einem Zugriff besteht.
Desgleichen wird es Anforderungen bezüglich der unbefugten Erzeugung oder Änderung (einschließlich
Löschung) von Informationen geben.
-
Beweissicherung
Bei vielen Produkten wird es erforderlich sein sicherzustellen, daß über Handlungen, die
von Benutzern bzw. von Prozessen im Namen solcher Benutzer ausgeführt werden,
Informationen aufgezeichnet werden, damit die Folgen solcher Handlungen später dem
betreffenden Benutzer zugeordnet werden können und der Benutzer für seine Handlungen
verantwortlich gemacht werden kann.
-
Protokollauswertung
Bei vielen Produkten wird sicherzustellen sein, daß sowohl über gewöhnliche Vorgänge als
auch über außergewöhnliche Vorfälle ausreichend Informationen aufgezeichnet werden,
damit durch Nachprüfungen später festgestellt werden kann, ob tatsächlich
Sicherheitsverletzungen vorgelegen haben und welche Informationen oder sonstigen
Betriebsmittel davon betroffen waren.
Teil 1 - Kapitel 9.2 - Seite 36
Version 1998
IT-Grundschutzhandbuch
-
Datenbanken
Unverfälschbarkeit
Bei vielen Produkten wird es erforderlich sein sicherzustellen, daß bestimmte Beziehungen
zwischen unterschiedlichen Daten korrekt bleiben und daß Daten zwischen einzelnen
Prozessen ohne Änderungen übertragen werden.
Daneben müssen auch Funktionen bereitgestellt werden, die es bei der Übertragung von Daten
zwischen einzelnen Prozessen, Benutzern und Objekten ermöglichen, Verluste, Ergänzungen oder
Veränderungen zu entdecken bzw. zu verhindern, und die es unmöglich machen, die angebliche oder
tatsächliche Herkunft bzw. Bestimmung der Datenübertragung zu ändern.
-
Zuverlässigkeit
Bei vielen Produkten wird es erforderlich sein sicherzustellen, daß zeitkritische Aufgaben genau zu dem
Zeitpunkt durchgeführt werden, zu dem es erforderlich ist, also nicht früher oder später, und es wird
sicherzustellen sein, daß zeitunkritische Aufgaben nicht in zeitkritische umgewandelt werden können.
Desgleichen wird es bei vielen Produkten erforderlich sein sicherzustellen, daß ein Zugriff in dem
erforderlichen Moment möglich ist und Betriebsmittel nicht unnötig angefordert oder zurückgehalten
werden.
-
Übertragungssicherung
Dieser Begriff umfaßt alle Funktionen, die für den Schutz der Daten während der Übertragung über
Kommunikationskanäle vorgesehen sind:
-
Authentisierung
-
Zugriffskontrolle
-
Datenvertraulichkeit
-
Datenintegrität
-
Sende- und Empfangsnachweis
Einige dieser Funktionen werden mittels kryptographischer Verfahren realisiert.
Über die ITSEC hinaus können weitere Sicherheitsanforderungen an Standardsoftware konkretisiert werden.
-
Datensicherung
An die Verfügbarkeit der mit dem Produkt verarbeiteten Daten werden hohe Anforderungen gestellt. Unter diesen Punkt fallen im Produkt integrierte Funktionen, die
Datenverlusten vorbeugen sollen wie die automatische Speicherung von
Zwischenergebnissen oder die automatische Erstellung von Sicherungskopien vor der
Durchführung größerer Änderungen.
-
Verschlüsselung
Verschlüsselung dient der Wahrung der Vertraulichkeit von Daten. Bei vielen Produkten
wird es erforderlich sein, Nutzdaten vor einer Übertragung oder nach der Bearbeitung zu
verschlüsseln und sie nach Empfang oder vor der Weiterverarbeitung zu entschlüsseln.
Hierzu ist ein anerkanntes Verschlüsselungsverfahren zu verwenden. Es ist sicherzustellen,
daß die zur Entschlüsselung benötigten Parameter (z. B. Schlüssel) in der Weise geschützt
sind, daß kein Unbefugter Zugang zu diesen Daten besitzt.
-
Funktionen zur Wahrung der Datenintegrität
Für Daten, deren Integritätsverlust zu Schäden führen kann, können Funktionen eingesetzt
werden, die Fehler erkennen lassen oder sogar mittels Redundanz korrigieren können.
Meist werden Verfahren zur Integritätsprüfung eingesetzt, die absichtliche Manipulationen am
Version 1998
Teil 1 - Kapitel 9.2 - Seite 37
Datenbanken
IT-Grundschutzhandbuch
Produkt bzw. den damit erstellten Daten sowie ein unbefugtes Wiedereinspielen von Daten zuverlässig
aufdecken können. Sie basieren auf kryptographischen Verfahren (siehe M 5.36 Verschlüsselung
unter Unix und M 4.34 Einsatz von Verschlüsselung, Checksummen oder Digitalen
Signaturen).
-
Datenschutzrechtliche Anforderungen
Wenn mit dem Produkt personenbezogene Daten verarbeitet werden sollen, sind über die
genannten Sicherheitsfunktionen hinaus zusätzliche spezielle technische Anforderungen zu
stellen, um den Datenschutzbestimmungen genügen zu können.
Stärke der Mechanismen
Sicherheitsfunktionen werden durch Mechanismen umgesetzt. Je nach Einsatzzweck müssen diese
Mechanismen eine unterschiedliche Stärke besitzen, mit der sie Angriffe abwehren können. Die
erforderliche Stärke der Mechanismen ist im Anforderungskatalog anzugeben. Nach ITSEC
unterscheidet man drei verschiedene Mechanismenstärken:
-
niedrig:
bietet
Bedienungsfehler.
-
mittel:
bietet Schutz gegen Angreifer mit beschränkten Gelegenheiten oder
Betriebsmitteln.
-
hoch: kann nur von Angreifern überwunden werden, die über sehr gute Fachkenntnisse,
Gelegenheiten und Betriebsmitteln verfügen, wobei ein solcher erfolgreicher Angriff als
normalerweise nicht durchführbar beurteilt wird.
Schutz
gegen
zufällige
unbeabsichtigte
Angriffe,
z. B.
Beispiele für Anforderungen zu Sicherheitseigenschaften
Nachfolgend werden für einige wichtige Sicherheitsfunktionen Beispiele genannt, aus denen
typische Anforderungen an Sicherheitseigenschaften deutlich werden.
Soll das Produkt über einen Identifizierungs- und Authentisierungsmechanismus verfügen,
können beispielsweise folgende Anforderungen gestellt werden:
-
Der Zugang darf ausschließlich über eine definierte Schnittstelle erfolgen. Dabei kann z. B.
ein Anmeldemechanismus zum Einsatz kommen, der eine eindeutige Benutzerkennung und
ein Paßwort verlangt. Wird beim Zugang zum IT-System bereits die Identität des
Benutzers sichergestellt, ist eine anonyme Paßworteingabe ausreichend. Andere
Möglichkeiten sind Verfahren, die auf dem Besitz bestimmter "Token" beruhen, wie z. B.
einer Chipkarte.
-
Das Zugangsverfahren selbst muß die sicherheitskritischen Parameter, wie Paßwort,
Benutzerkennung, usw., sicher verwalten. So dürfen aktuelle Paßwörter nie unverschlüsselt
auf den entsprechenden IT-Systemen gespeichert werden.
-
Das Zugangsverfahren muß definiert auf Fehleingaben reagieren. Erfolgt zum Beispiel
dreimal hintereinander eine fehlerhafte Authentisierung, ist der Zugang zum Produkt zu
verwehren oder alternativ sind die zeitlichen Abstände, nach denen ein weiterer
Zugangsversuch erlaubt wird, sukzessiv zu vergrößern.
-
Das Zugangsverfahren muß das Setzen bestimmter Minimalvorgaben für die
sicherheitskritischen Parameter zulassen. So sollte die Mindestlänge eines Paßwortes sechs
Teil 1 - Kapitel 9.2 - Seite 38
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Zeichen, die Mindestlänge einer PIN drei Ziffern betragen. Ggf. ist auch die Syntax für
Paßwörter vorzugeben.
Soll das Produkt über eine Zugriffskontrolle verfügen, können beispielsweise folgende
Anforderungen gestellt werden:
-
Das Produkt muß verschiedene Benutzer unterscheiden können.
-
Das Produkt muß je nach Vorgabe Ressourcen einzelnen autorisierten Benutzer zuteilen
können und Unberechtigten den Zugriff gänzlich verwehren.
-
Mittels einer differenzierten Rechtestruktur (lesen, schreiben, ausführen, ändern, ...) sollte
der Zugriff geregelt werden können. Die für die Rechteverwaltung relevanten Daten sind
manipulationssicher vom Produkt zu verwalten.
Soll das Produkt über eine Protokollierung verfügen, können folgende Anforderungen sinnvoll
sein:
-
Der Mindestumfang, den das Produkt protokollieren können muß, sollte parametrisierbar
sein. Beispielsweise sollten folgende Aktionen protokollierbar sein:
- bei Authentisierung: Benutzerkennung, Datum und Uhrzeit, Erfolg, ...,
- bei der Zugriffskontrolle: Benutzerkennung, Datum und Uhrzeit, Erfolg, Art des Zugriffs,
was wurde wie geändert, gelesen, geschrieben, ...,
- Durchführung von Administratortätigkeiten,
- Auftreten von funktionalen Fehlern.
-
Die Protokollierung darf von Unberechtigten nicht deaktivierbar sein. Die Protokolle selbst
dürfen für Unberechtigte weder lesbar noch modifizierbar sein.
-
Die Protokollierung muß übersichtlich, vollständig und korrekt sein.
Soll das Produkt über eine Protokollauswertung verfügen, können folgende Anforderungen
sinnvoll sein:
-
Eine Auswertefunktion muß nach den bei der Protokollierung geforderten Datenarten
unterscheiden können (z. B. "Filtern aller unberechtigten Zugriffe auf alle Ressourcen in
einem vorgegebenen Zeitraum").
Die Auswertefunktion muß auswertbare ("lesbare") Berichte erzeugen, so daß keine
sicherheitskritischen Aktivitäten übersehen werden.
Soll das Produkt über Funktionen zur Unverfälschbarkeit verfügen, könnte beispielsweise
folgende Anforderung gestellt werden:
-
Ein Datenbank-Managementsystem muß über Möglichkeiten zur Beschreibung von Regeln
bestimmter Beziehungen zwischen den gespeicherten Daten verfügen (z. B. referentielle
Integrität). Außerdem müssen geeignete Mechanismen existieren, die verhindern, daß es
durch Änderungen der Daten zu Verstößen gegen diese Regeln kommt.
Soll das Produkt über Funktionen zur Datensicherung verfügen, können beispielsweise folgende
Anforderungen gestellt werden:
-
Es muß konfigurierbar sein, welche Daten wann gesichert werden.
-
Es muß eine Option zum Einspielen beliebiger Datensicherungen existieren.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 39
Datenbanken
IT-Grundschutzhandbuch
-
Die Funktion muß das Sichern von mehreren Generationen ermöglichen.
-
Datensicherungen von Zwischenergebnissen aus der laufenden Anwendung sollen möglich
sein.
Soll das Produkt über eine Verschlüsselungskomponente verfügen, sind folgende Anforderungen
sinnvoll:
-
Der implementierte Verschlüsselungsalgorithmus sollte - beim Einsatz in Behörden - vom
BSI anerkannt sein. Hier empfiehlt sich eine individuelle Beratung durch das BSI.
Außerhalb der Behörden ist bei mittlerem Schutzbedarf der DES geeignet.
-
Das Schlüsselmanagement muß mit der Funktionalität des Produktes harmonieren. Dabei
sind insbesondere grundsätzliche Unterschiede der Algorithmen zu berücksichtigen:
- symmetrische Verfahren benutzen einen geheimzuhaltenden Schlüssel für die Ent- und
Verschlüsselung,
- asymmetrische Verfahren benutzen einen öffentlichen Schlüssel für die Verschlüsselung
und einen privaten (geheimzuhaltenden) für die Entschlüsselung.
-
Das Produkt muß die sicherheitskritischen Parameter wie Schlüssel sicher verwalten. So
dürfen Schlüssel (auch mittlerweile nicht mehr benutzte) nie ungeschützt, das heißt
auslesbar, auf den entsprechenden IT-Systemen abgelegt werden.
Soll das Produkt über Mechanismen zur Integritätsprüfung verfügen, sind folgende Anforderungen
sinnvoll:
-
Das Produkt führt bei jedem Programmaufruf einen Integritätscheck durch.
-
Bei der Datenübertragung müssen Mechanismen eingesetzt werden, mit denen absichtliche
Manipulationen an den Adreßfeldern und den Nutzdaten erkannt werden können. Daneben
darf die bloße Kenntnis der eingesetzten Algorithmen ohne spezielle Zusatzkenntnisse nicht
ausreichen, unerkannte Manipulationen an den obengenannten Daten vorzunehmen.
Werden personenbezogene Daten mit dem Produkt verarbeitet, können beispielsweise folgende
datenschutzrechtlichen Anforderungen gestellt werden:
-
Das Produkt darf keine freie Abfrage für Datenauswertungen zulassen. Die Auswertungen
von Datensätzen müssen auf bestimmte Kriterien einschränkbar sein.
-
Es muß parametrisierbar sein, daß für bestimmte Dateien Änderungen, Löschungen oder
Ausdrucke von personenbezogenen Daten nur nach dem Vier-Augen-Prinzip möglich sind.
-
Die Protokollierung muß parametrisierbar sein, so daß aufgezeichnet werden kann, wer
wann an welchen personenbezogenen Daten welche Änderungen vorgenommen hat.
-
Die Übermittlung personenbezogener Daten muß durch geeignete Stichprobenverfahren
festgestellt und überprüft werden können (BDSG, § 10). Die Art der Stichprobe muß sich
individuell einstellen lassen.
-
Das Produkt muß das Löschen von personenbezogenen Daten ermöglichen. Ersatzweise
muß das Sperren personenbezogener Daten möglich sein, um ihre weitere Verarbeitung
oder Nutzung einzuschränken bzw. zu verhindern.
Teil 1 - Kapitel 9.2 - Seite 40
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Bewertungsskala
Um einen Vergleich verschiedener Produkte im Sinne einer Nutzwertanalyse durchführen zu
können, müssen Kriterien vorhanden sein, wie die Erfüllung der einzelnen Anforderungen
gewertet wird. Dazu ist es erforderlich, vorab die Bedeutung der einzelnen Anforderungen für die
angestrebte IT-gestützte Aufgabenerfüllung quantitativ oder qualitativ zu bewerten.
Diese Bewertung kann beispielsweise in drei Stufen vorgenommen werden. In der ersten Stufe
wird festgelegt, welche im Anforderungskatalogs geforderten Eigenschaften notwendig und
welche wünschenswert sind. Wenn eine notwendige Eigenschaft nicht erfüllt ist, wird das
Produkt abgelehnt (sogenanntes K.O.-Kriterium). Das Fehlen einer wünschenswerten Eigenschaft
wird zwar negativ gewertet, dennoch wird aber das Produkt aufgrund dessen nicht zwingend
abgelehnt.
Als zweite Stufe wird die Bedeutung der geforderten wünschenswerte Eigenschaft für die
Aufgabenerfüllung angegeben. Dies kann z. B. quantitativ mit Werten zwischen 1 für niedrig und
5 für hoch erfolgen. Notwendige Eigenschaften müssen nicht quantitativ bewertet werden. Ist dies
aber aus rechnerischen Gründen erforderlich, müssen sie auf jeden Fall höher bewertet werden als
jede wünschenswerte Eigenschaft (um die Bedeutung einer notwendigen Eigenschaft
hervorzuheben, kann sie z. B. mit 10 bewertet werden).
In der dritten Stufe wird ein Vertrauensanspruch für die Korrektheit Aufgabenerfüllung der
geforderten Eigenschaften angegeben (z. B. mit Werten zwischen 1 für niedrig und 5 für hoch).
Anhand des Vertrauensanspruchs wird später entschieden, wie eingehend die Eigenschaft getestet
wird. Der Vertrauensanspruch der Sicherheitsmechanismen muß entsprechend ihrer
Mechanismenstärke bewertet werden, beispielsweise kombiniert man
-
Mechanismenstärke niedrig
mit
Vertrauensanspruch 1
-
Mechanismenstärke mittel
mit
Vertrauensanspruch 3
-
Mechanismenstärke hoch
mit
Vertrauensanspruch 5
Diese Orientierungswerte müssen im Einzelfall verifiziert werden.
Beispiele:
Auszugsweise sollen für einige typische Standardsoftwareprodukte Sicherheitsanforderungen
erläutert werden:
Textverarbeitungsprogramm:
Notwendige Sicherheitseigenschaften:
- Automatische Datensicherung im laufenden Betrieb von Zwischenergebnissen
Wünschenswerte Sicherheitseigenschaften:
- Paßwortschutz einzelner Dateien
- Verschlüsselung einzelner Dateien
- Makroprogrammierung muß abschaltbar sein
Dateikompressionsprogramm:
Notwendige Sicherheitseigenschaften:
Version 1998
Teil 1 - Kapitel 9.2 - Seite 41
Datenbanken
IT-Grundschutzhandbuch
- Im Sinne der Datensicherung dürfen nach Kompression zu löschende Dateien erst dann
vom Kompressionsprogramm gelöscht werden, wenn die Kompression fehlerfrei
abgeschlossen wurde.
- Vor der Dekomprimierung einer Datei muß deren Integrität überprüft werden, damit z. B.
Bitfehler in der komprimierten Datei erkannt werden.
Wünschenswerte Sicherheitseigenschaften:
- Paßwortschutz komprimierter Dateien
Terminplaner:
Notwendige Sicherheitseigenschaften:
- Eine sichere Identifikation und Authentisierung der einzelnen Benutzer muß erzwungen
werden, z. B. über Paßworte.
- Eine Zugriffskontrolle für die Terminpläne der einzelnen Mitarbeiter ist erforderlich.
- Zugriffsrechte müssen für Einzelne, Gruppen und Vorgesetzte getrennt vergeben werden
können.
- Eine Unterscheidung zwischen Lese- und Schreibrecht muß möglich sein.
Wünschenswerte Sicherheitseigenschaften:
- Eine automatisierte Datensicherung in verschlüsselter Form ist vorzusehen.
Reisekostenabrechnungssystem:
Notwendige Sicherheitseigenschaften:
- Eine sichere Identifikation und Authentisierung der einzelnen Benutzer muß erzwungen
werden, z. B. über Paßworte.
- Eine Zugriffskontrolle muß vorhanden und auch für einzelne Datensätze einsetzbar sein.
- Zugriffsrechte müssen für Benutzer, Administrator, Revisor und Datenschutzbeauftragter
getrennt vergeben werden können. Eine Rollentrennung zwischen Administrator und
Revisor muß durchführbar sein.
- Datensicherungen müssen so durchgeführt werden können, daß sie verschlüsselt abgelegt
werden und nur von Berechtigten wiedereingespielt werden können.
- Detaillierte Protokollierungsfunktionen müssen verfügbar sein.
Wünschenswerte Sicherheitseigenschaften:
- Ein optionaler Integritätscheck für zahlungsrelevante Daten sollte angeboten werden.
Beispiel für eine Bewertungsskala:
Eine Fachabteilung will für Datensicherungszwecke ein Komprimierungsprogramm beschaffen.
Nach der Erstellung eines Anforderungskataloges könnten die dort spezifizierten Eigenschaften
wie folgt bewertet werden:
Teil 1 - Kapitel 9.2 - Seite 42
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Eigenschaft
korrekte
Kompression
Dekompression
notwendig
wünschenswert
Bedeutung
Vertrauensanspruch
und
X
10
5
Erkennen von Bitfehlern in einer
komprimierten Datei
X
10
2
Löschung von Dateien nur nach
erfolgreicher Kompression
X
10
3
DOS-PC, 80486, 8 MB
X
10
5
Windows-tauglich
X
2
1
Durchsatz bei 50 MHz über 1 MB/s
X
4
3
Kompressionsrate über 40% bei
Textdateien des Programms XYZ
X
4
3
Online-Hilfefunktion
X
3
1
10
5
2
5
Maximale Kosten 50.- DM pro
Lizenz
Paßwortschutz für komprimierte
Dateien (Mechanismenstärke hoch)
X
X
Ergänzende Kontrollfragen:
-
Wer wird bei der Erstellung des Anforderungskatalogs beteiligt?
-
Wer entscheidet, ob ein Produkt Sicherheitsfunktionen beinhalten muß?
-
Gibt es einheitliche Vorgaben, wie eine Nutzwertanalyse aufgebaut sein muß?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 43
Datenbanken
M 2.111
IT-Grundschutzhandbuch
Bereithalten von Handbüchern
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement
Bei der Beschaffung von Informationstechnik, egal ob es sich um Hardware oder Software
handelt, müssen die zugehörigen Handbücher und technischen Referenzen in ausreichender
Anzahl mitbeschafft werden.
Im Lieferumfang von IT-Produkten ist zunehmend keine weiterführende Dokumentation mehr
enthalten, sondern es werden neben Online-Hilfen nur noch Installationshilfen und einführende
Texte mitgeliefert. Dieser eingeschränkte Umfang an Dokumentationshilfen ist insbesondere bei
auftretenden Fehlern unzureichend. Es ist daher darauf zu achten, daß die erforderlichen
Handbücher, technische Referenzen und Fehlerkataloge zusätzlich beschafft werden. Hierbei muß
nicht ausschließlich auf die vom Hersteller angebotene Literatur zurückgegriffen werden.
Alle Handbücher zu einem IT-Produkt müssen jederzeit in der Anwendungsumgebung verfügbar
sein. Beispielweise müssen die Handbücher zu einem Server-Betriebssystem bei diesem Server
aufbewahrt werden, und nicht in einer evtl. geschlossenen Bibliothek. Bei der Notfallplanung ist
der Zugriff auf diese Literatur einzuplanen (siehe M 6.3 Erstellung eines Notfall-Handbuches).
Kontrollfragen:
-
Welche Handbücher gibt es zu den eingesetzten IT-Produkten?
-
Wo werden die Handbücher verwahrt? Sind sie jederzeit verfügbar?
Teil 1 - Kapitel 9.2 - Seite 44
Version 1998
IT-Grundschutzhandbuch
M 2.124
Datenbanken
Geeignete Auswahl einer Datenbank-Software
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: IT-Sicherheitsmanagement, Administrator
Bei der Beschaffung neuer Datenbank-Software besteht die Möglichkeit, diese von vornherein so
auszuwählen, daß im späteren Betrieb mit nur geringem personellen und organisatorischen
Zusatzaufwand ein hohes Maß an Sicherheit erreicht werden kann.
Zu Beginn muß der Einsatzbereich und Verwendungszweck des Datenbanksystems geklärt
werden, um die Anforderungen bezüglich der Verfügbarkeit, der Integrität und der Vertraulichkeit
formulieren zu können. Weiterhin sind die Anforderungen hinsichtlich der zu verarbeitenden
Datenmengen, der Verarbeitungsgeschwindigkeit und des Durchsatzes zu quantifizieren. Daraus
leiten sich die zu erfüllenden Eigenschaften für die zu beschaffende Datenbank-Software ab, wie
z. B. Verfügbarkeit für bestimmte Hardware-Plattformen bzw. Betriebssysteme oder Umfang von
notwendigen Sicherheitsmechanismen. In diesem Planungsstadium kann bereits erkannt werden,
ob und in welchem Maße für den späteren Betrieb des Datenbanksystems Hardware nach- bzw.
umgerüstet werden muß. Anhand der Verfügbarkeitsanforderungen sind auch die benötigten
Überwachungsmöglichkeiten zu definieren, d. h. es muß festgelegt werden, welche
Datenbankzustände in welcher Form erkennbar sein sollen (z. B. durch eine Protokollierung in
einer Datei), sowie die Art der Benachrichtigung verantwortlicher Personen bzw.
Personengruppen über kritische Zustände der Datenbank (z. B. durch eine Meldung an der
Konsole).
Für die Beschaffung einer Datenbank-Software sollten insbesondere die folgenden Punkte
berücksichtigt werden:
-
Die Datenbank-Software muß über eigene geeignete Mechanismen zur Identifikation und
Authentisierung der Benutzer verfügen (siehe M 2.128 Zugangskontrolle einer
Datenbank).
-
Die Datenbank-Software muß über geeignete Mechanismen zur Ressourcenbeschränkung
verfügen (siehe M 4.73 Festlegung von Obergrenzen).
-
Falls in der Datenbank vertrauliche Daten verwaltet werden sollen, so muß einem
unberechtigten Zugriff vorgebeugt werden können. Die zu beschaffende DatenbankSoftware muß in diesem Fall entsprechende Zugriffskontrollmechanismen zur Verfügung
stellen (siehe M 2.129 Zugriffskontrolle einer Datenbank).
Es sollte auch die Zusammenfassung mehrerer Benutzer mit gleichen Zugriffsrechten zu
Gruppen möglich sein. Eine Unterscheidung zwischen der Gruppe der Administratoren und
der Gruppe der Benutzer ist dabei obligatorisch. Weiterhin sollte eine Trennung von
verschiedenen Administrator-Rollen unterstützt werden (siehe M 2.131 Aufteilung von
Administrationstätigkeiten bei Datenbanksystemen).
-
Es gibt Datenbanken mit unterschiedlich starken Zugriffsschutzmechanismen. Ähnliche
Sicherheitsmechanismen können dabei auch in unterschiedlicher Granularität angeboten
werden. Im Vorfeld ist zu klären, welcher Zugriffsschutz erforderlich ist und welche
Datenbank-Software den definierten Sicherheitsanforderungen entspricht. Maßgeblich
hierfür sind die Möglichkeiten, Zugriffsrechte auf Datenbankobjekte und die Daten selbst
einzuschränken.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 45
Datenbanken
IT-Grundschutzhandbuch
Beispiele:
- Den Anwendern kann das Recht entzogen werden, Datenbankobjekte (z. B. Tabellen)
anzulegen oder zu modifizieren.
- Die Anwender können zwar eine lesende Zugriffsberechtigung auf eine Tabelle erhalten,
gleichzeitig können aber modifizierende Zugriffsrechte ausgeschlossen werden.
- Für bestimmte Tabellen oder bestimmte Felder einer Tabelle kann der Zugriff je nach
Anwender verboten werden.
- Anwender erhalten keinerlei Zugriffsberechtigungen auf Datensätze mit bestimmten
Merkmalen (z. B. ein Sachbearbeiter aus Bonn hat keinen Zugriff auf die Daten eines
Sachbearbeiters aus Köln).
-
Einige Hersteller bieten sowohl die Möglichkeit der Definition von Gruppen als auch die
von Rollen an. Dadurch kann eine differenziertere Zugriffskontrolle auf die
Datenbankobjekte realisiert werden. Im Vorfeld sind die diesbezüglichen Anforderungen zu
klären und mit den zur Auswahl stehenden Datenbank-Softwareprodukten abzugleichen.
-
Die Datenbank-Software muß ebenfalls hinsichtlich ihrer Überwachungs- und
Kontrollmechanismen überprüft werden. Die diesbezüglichen Anforderungen müssen
definiert und mit den Leistungsprofilen der Produkte abgeglichen werden (Beispiele siehe
M 2.133 Kontrolle der Protokolldateien eines Datenbanksystems bzw. M 2.126
Erstellung eines Datenbanksicherheitskonzeptes).
-
Es muß geprüft werden, ob die Datenbank-Software eine Rollentrennung zwischen
Administrator und Revisor unterstützt. Es muß möglich sein, die Rolle eines Revisors
einzurichten, der als einziger in der Lage ist, die Protokolldateien auszuwerten und zu
löschen. Dies verhindert potentielle Manipulationen durch den Datenbank-Administrator.
-
Zum Schutz der Datenbankintegrität muß die Datenbank-Software über ein vollständiges
Transaktionssystem verfügen, welches dem ACID-Prinzip genügt. Diese Anforderung wird
heutzutage von allen wesentlichen relationalen DBMSen erfüllt.
-
Es müssen Mechanismen zur Datensicherung der Datenbank vorhanden sein (siehe M 6.49
Datensicherung einer Datenbank).
Im Vorfeld muß in diesem Zusammenhang geklärt werden, welche Möglichkeiten
hinsichtlich der Datensicherung die Datenbank-Software zur Verfügung stellen muß. So
wird beispielsweise eine partielle Datenbanksicherung nicht für alle am Markt erhältlichen
Produkte angeboten. Im konkreten Fall gilt es also zu prüfen, ob das erstellte
Datensicherungskonzept mit den zur Verfügung stehenden Mechanismen auch umgesetzt
werden kann.
Anhand dieser Kriterien müssen die zur Auswahl stehenden Datenbanksysteme geprüft und
bewertet werden. Es ist dann diejenige Software auszuwählen, die die spezifischen Anforderungen
am besten erfüllt. Weitergehende Anforderungen müssen entweder durch Zusatzprodukte oder
durch Eigenentwicklung abgedeckt werden. Es sollte jedoch schon vor der Beschaffung abgeklärt
werden, zu welcher Datenbank-Software welche Zusatzprodukte verfügbar sind, um nicht auf
teure Eigenentwicklungen zurückgreifen zu müssen.
Von den meisten Datenbankmanagementsystemen sind in der Regel mehrere unterschiedliche
Versionen auf dem Markt erhältlich. Dabei unterscheiden sich auch die einzelnen Versionen
desselben DBMS in ihrer Funktionalität, u. a. auch in sicherheitsrelevanten Bereichen. Der starke
Teil 1 - Kapitel 9.2 - Seite 46
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Wettbewerb führt dazu, daß einige Hersteller auch noch nicht vollausgereifte Software ausliefern,
bei der dann mit Fehlern und eingeschränkter Funktionalität gerechnet werden muß.
In einer Testphase sollte deshalb überprüft werden, ob die ausgewählte Datenbank-Software die
erforderlichen Funktionen in der vorgegebenen Einsatzumgebung auch erfüllt. Dies gilt
insbesondere für die Anforderungen an die Performance und die benötigten Mechanismen zur
Notfallvorsorge.
Vor der Beschaffung sollten auch Erfahrungen aus vergleichbaren Installationen herangezogen
werden.
Ergänzende Kontrollfragen:
-
Wurden die Anforderungen an die Datenbank-Software formuliert und dokumentiert?
-
Wurde eine Bewertung der relevanten Datenbanksysteme anhand dieser Anforderungen
durchgeführt?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 47
Datenbanken
M 2.125
IT-Grundschutzhandbuch
Installation und Konfiguration einer Datenbank
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Grundsätzlich muß zwischen der Erstinstallation einer Datenbank-Software und der Installation
auf bestehenden Datenbanksystemen unterschieden werden.
Da bei der erstmaligen Installation einer Datenbank-Software noch keine Benutzer auf die
Datenbank zugreifen wollen und auch noch keine Altdaten vorhanden sind (es sei denn in anderen
Datenbanksystemen), gestaltet sich dies relativ unproblematisch und stört den normalen ITBetrieb kaum.
Für Installationen auf bestehenden Systemen sollten dagegen die Arbeiten wenn möglich
außerhalb der regulären Arbeitszeiten erfolgen, um Behinderungen des normalen IT-Betriebs
weitestgehend zu minimieren. In jedem Fall sollten die Benutzer über bevorstehende Arbeiten
informiert werden, um sie auf eventuell mögliche Störungen oder längere Antwortzeiten hinzuweisen.
Die Installation und Konfiguration einer Datenbank gliedert sich in die folgenden Aktivitäten:
1.
Installation der Datenbank-Software
Vor der Installation der Datenbank-Software ist zu überprüfen, ob das IT-System entsprechend
der Planung vorbereitet wurde, z. B. genügend Speicherplatz zur Verfügung steht und die notwendigen Betriebssystemeinstellungen vorgenommen wurden.
Bei der Installation der Datenbank-Software sind die Installationsanweisungen des Herstellers zu
befolgen. Wenn möglich, sollten die vom Hersteller vorgeschlagenen Default-Einstellungen
übernommen werden. Dies gilt vor allem für technische Parameter, die z. B. die Größe verschiedener interner Tabellen des DBMS steuern. Für Parameter, die sich auf sicherheitsrelevante
Eigenschaften beziehen, muß u. U. von den vorgegebenen Werten abgewichen werden.
Die Installation der Datenbank-Software ist geeignet zu dokumentieren. Dies gilt insbesondere für
Abweichungen von den vom Hersteller vorgeschlagenen Default-Einstellungen, die ausführlich zu
begründen sind.
Sollen vom Hersteller angebotene optionale Funktionalitäten genutzt werden, so ist während der
Installation darauf zu achten, daß sie auch entsprechend eingerichtet werden.
Alle Tätigkeiten in diesem Schritt werden vom fachlich übergreifenden Administrator durchgeführt.
2.
Erstellen der Datenbank
Bereits bei der Erstellung der Datenbank sind Parameter anzugeben, die später während des
Betriebs des Datenbanksystems nicht mehr geändert werden können. Die Bedeutung dieser
Parameter und die geeignete Auswahl ihrer Werte werden in den Installationsunterlagen und
Handbüchern des Herstellers ausführlich erläutert und sind dort entsprechend nachzulesen.
Dem Installationshandbuch bzw. Administrationshandbuch sind außerdem Hinweise über
eventuell erforderliche Nacharbeiten nach der Erstellung der Datenbank zu entnehmen.
Auch dieser Vorgang ist im Rahmen einer Dokumentation festzuhalten.
Teil 1 - Kapitel 9.2 - Seite 48
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Alle Tätigkeiten in diesem Schritt werden vom fachlich übergreifenden Administrator durchgeführt, wobei ihm die anwendungsspezifischen Administratoren beratend zur Seite stehen müssen
(z. B. um die Größe der Datenbank festlegen zu können).
3.
Konfiguration der Datenbank
Im dritten Schritt ist das Benutzer- und Gruppenkonzept sowie das ggf. zum Einsatz kommende
Rollenkonzept umzusetzen. Dazu erstellt der fachlich übergreifende Administrator die einzelnen
Berechtigungsprofile und legt alle Gruppen sowie die administrativen Benutzerkennungen (für die
anwendungsspezifischen Administratoren) an. Dabei sind die in M 2.132 Regelung für die
Einrichtung von Datenbankbenutzern/-benutzergruppen festgelegten Regelungen anzuwenden
und zu überprüfen. Hängen die entsprechenden Zugriffsberechtigungen von einzelnen
Datenbankobjekten ab, können diese natürlich erst dann definiert werden, wenn die
Datenbankobjekte auch existieren (siehe Schritt 4).
Falls die Datenbank-Software eine Verteilung der Daten auf mehrere Dateien oder Festplatten
unterstützt, sind zusätzliche Parametereinstellungen vorzunehmen, die das Anlegen dieser Dateien
respektive der zugehörigen Speicherbereiche festlegen.
Alle vorgenommenen Einstellungen sind detailliert zu dokumentieren (siehe M 2.25 Dokumentation der Systemkonfiguration).
Alle Tätigkeiten in diesem Schritt werden vom fachlich übergreifenden Administrator durchgeführt.
4.
Erstellen und Konfigurieren von Datenbankobjekten
Gemäß des Datenbanksicherheitskonzeptes (siehe M 2.126 Erstellung eines Datenbanksicherheitskonzeptes) werden im letzten Schritt die Datenbankobjekte der einzelnen Anwendungen angelegt. Dieser Vorgang sollte wenn möglich durch den Einsatz von Skripten automatisiert und protokolliert werden. Nach Anlage der Datenbankobjekte sind die notwendigen
Zugriffsberechtigungen für Rollen, Gruppen und Benutzer zu ergänzen. Ebenso können jetzt die
konkreten Benutzer anhand der existierenden Berechtigungsprofile erstellt werden.
Alle Tätigkeiten in diesem Schritt werden von den anwendungsspezifischen Administratoren
durchgeführt.
Ergänzende Kontrollfragen:
-
Werden die Benutzer über die bevorstehende Installation informiert?
-
Sind vor Erstellen der Datenbank alle erforderlichen Parameter und deren Werte bekannt,
die während der Installation benötigt werden?
-
Sind alle Nacharbeiten bekannt, die nach der Erstellung der Datenbank durchgeführt
werden müssen?
-
Wurde der Installationsvorgang, die Erstellung und Konfiguration der Datenbank sowie der
Datenbankobjekte dokumentiert?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 49
Datenbanken
M 2.126
IT-Grundschutzhandbuch
Erstellung eines Datenbanksicherheitskonzeptes
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: IT-Sicherheitsmanagement
Da eine zentrale Datenhaltung über einen längeren Zeitraum hinweg einen zentralen und
kritischen Aspekt des Informationsmanagements einer Behörde bzw. eines Unternehmens
darstellt, kommt der Erstellung eines Datenbankkonzeptes eine besondere Bedeutung zu. Ein
Datenbankkonzept beschäftigt sich mit den notwendigen Vorarbeiten zum eigentlichen Betrieb der
Datenbank und sollte deshalb immer ein Datenbanksicherheitskonzept enthalten, welches auch
den laufenden Betrieb untersucht.
Werden die Daten nicht ausreichend geschützt, kann es zu einem Verlust der Vertraulichkeit,
Verfügbarkeit oder der Integrität kommen. Um diesem vorzubeugen, ist es unumgänglich, ein
schlüssiges Datenbanksicherheitskonzept zu erstellen.
Um die Sicherheit einer Datenbank zu gewährleisten, muß ein geeignetes
Datenbankmanagementsystem (DBMS) eingesetzt werden. Damit ein DBMS effektiven Schutz
bieten kann, müssen folgende grundlegende Bedingungen erfüllt sein. Das DBMS muß
-
auf einer umfassenden Sicherheitspolitik aufsetzen,
-
im IT-Sicherheitskonzept der Organisation eingebettet sein,
-
korrekt installiert und
-
korrekt administriert werden.
Direkte Zugriffe auf die Datenbank (z. B. über SQL-Interpreter wie SQL*Plus) dürfen nur für
administrative Nutzer zugelassen werden, um Manipulationen an den Daten bzw.
Datenbankobjekten (z. B. Tabellen und Indizes) zu verhindern. Datenbankobjekte dürfen
ausschließlich über spezielle Kennungen kontrolliert modifiziert werden. Dementsprechend muß
das DBMS über ein geeignetes Zugriffs- und Zugangskonzept verfügen (siehe M 2.129
Zugriffskontrolle einer Datenbank und M 2.128 Zugangskontrolle einer Datenbank). BenutzerKennungen, die nur über eine Anwendung Datenmodifikationen durchführen können, dürfen
keinen direkten Zugang zur Datenbank erhalten, während Kennungen zur Verwaltung der
Datenbankobjekte der kontrollierte direkte Zugriff erlaubt sein muß.
Weiterhin müssen folgende wichtige Aspekte in einem Datenbanksicherheitskonzept geregelt
werden:
-
Die physische Speicherung bzw. Spiegelung der Datenbankdateien (z. B. der DBMSSoftware, der Datenbank an sich oder der Protokolldateien) sowie deren Verteilung ist
festzulegen, um z. B. die Verfügbarkeit und Ausfallsicherheit zu erhöhen. Aus
Sicherheitsgründen sollten gespiegelte Kontrolldateien beispielsweise auf verschiedenen
Festplatten abgelegt sein. Der Ausfall einer Platte bedeutet dann nicht gleichzeitig den
Verlust aller Kontrolldateien. Falls die Datenbankobjekte einer Anwendung in eigenen
Datendateien abgelegt werden, so sollte man bei der Verteilung der Datendateien darauf
achten, daß bei einem Ausfall einer Festplatte nicht alle Anwendungen betroffen sind.
Beispiel:
Eine Datenbank verwaltet die Daten zweier Anwendungen, mit jeweils einer Datendatei für
die Tabellen und Indizes. Die Datendateien können beliebig auf vier Festplatten verteilt
werden.
Teil 1 - Kapitel 9.2 - Seite 50
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Eine ungünstige Verteilung der Datendateien sieht folgendermaßen aus:
Festplatte 1: Ablage der Datendateien für die Indizes beider Anwendungen
Festplatte 2: Ablage der Datendateien für die Tabellen der ersten Anwendung
Festplatte 3: Ablage der Datendateien für die Tabellen der zweiten Anwendung
Festplatte 4: Bei einem Ausfall der ersten Festplatte wären somit beide Anwendungen betroffen und
könnten nicht mehr genutzt werden.
Eine günstigere Verteilung der Datendateien erhält man dagegen so:
Festplatte 1: Ablage der Datendateien für die Indizes der ersten Anwendung
Festplatte 2: Ablage der Datendateien für die Tabellen der ersten Anwendung
Festplatte 3: Ablage der Datendateien für die Indizes der zweiten Anwendung
Festplatte 4: Ablage der Datendateien für die Tabellen der zweiten Anwendung
Bei einem Ausfall einer beliebigen Festplatte wäre immer nur eine Anwendung betroffen.
-
Es muß eine regelmäßige Prüfung des tatsächlich anfallenden Datenvolumens bzw. des
Zuwachses des Datenvolumens im späteren laufenden Betrieb durchgeführt werden, um
den benötigten Speicherplatz auch für zukünftige Bedürfnisse geeignet dimensionieren zu
können.
-
Geeignete Mechanismen zur Datensicherung müssen angewendet werden (siehe M 6.49
Datensicherung einer Datenbank).
-
Der Einsatz von Überwachungs- und Kontrollmechanismen ist festzulegen, d. h. ob und in
welchem Umfang Datenbankaktivitäten protokolliert werden sollen. Hier stellt sich u. a. die
Frage, ob beispielsweise nur der Zeitpunkt einer Datenmodifikation festgehalten wird, oder
ob auch die Modifikation selbst protokolliert werden soll (siehe M 2.133 Kontrolle der
Protokolldateien eines Datenbanksystems).
Für die Konzeption und den Betrieb eines Datenbanksystems muß geeignetes Personal zur
Verfügung stehen. Der zeitliche Aufwand für den Betrieb eines Datenbanksystems darf nicht
unterschätzt werden. Alleine die Auswertung der angefallenen Protokolldaten nimmt
erfahrungsgemäß viel Zeit in Anspruch. Ein Datenbank-Administrator muß fundierte Kenntnisse
über die eingesetzte DBMS-Software besitzen und auch entsprechend geschult werden.
Ergänzende Kontrollfragen:
-
Wurden die Sicherheitsziele für den Einsatz eines Datenbanksystems formuliert und
dokumentiert?
-
Ist ein direkter Zugriff auf die Datenbanken über eine interaktive Abfragesprache
ausgeschlossen?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 51
Datenbanken
M 2.127
IT-Grundschutzhandbuch
Inferenzprävention
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Zum Schutz personenbezogener und anderer vertraulicher Daten eines Datenbanksystems ist
grundsätzlich jedem Benutzer nur der Zugriff auf diejenigen Daten zu gestatten, die für seine
Tätigkeiten notwendig sind. Alle anderen Informationen, die sich zusätzlich in der Datenbank
befinden, sind vor ihm zu verbergen.
Zu diesem Zweck müssen die Zugriffsberechtigungen auf Tabellen bis hin zu deren Feldern
definiert werden können. Dies kann mittels Verwendung von Views und Grants durchgeführt
werden (vgl. M 2.129 Zugriffskontrolle einer Datenbank). Damit ist es einem Benutzer nur
möglich, die für ihn bestimmten Daten einzusehen und zu verarbeiten. Stellt er Datenbankabfragen, die auf andere Informationen zugreifen wollen, werden diese vom DBMS zurückgewiesen.
Im Zusammenhang mit statistischen Datenbanken, die Daten über Personengruppen, Bevölkerungsschichten oder ähnliches enthalten, treten dagegen andere Schutzanforderungen auf. In einer
statistischen Datenbank unterliegen die einzelnen, personenbezogenen Einträge dem Datenschutz,
statistische Informationen sind jedoch allen Benutzern zugänglich.
Hier gilt es zu verhindern, daß aus Kenntnissen über die Daten einer Gruppe auf die Daten eines
individuellen Mitglieds dieser Gruppe geschlossen werden kann. Es muß außerdem verhindert
werden, daß durch das Wissen der in der Datenbank gespeicherten Informationen bzw. der
Ablagestrukturen der Daten in der Datenbank die Anonymität dieser Daten durch entsprechend
formulierte Datenbankabfragen umgangen werden kann (z. B. wenn die Ergebnismenge einer
Datenbankabfrage nur einen Datensatz beinhaltet). Diese Problematik wird Inferenzproblem, der
Schutz vor solchen Techniken Inferenzprävention genannt.
Auch wenn die Daten einer statistischen Datenbank anonymisiert sind, kann durch Inferenztechniken der Personenbezug zu bestimmten Datensätzen wiederhergestellt werden. Eine
Zurückweisung bestimmter Anfragen (z. B. Anfragen mit nur einem oder wenigen Ergebnistupeln) reicht im allgemeinen nicht aus, da auch die Verweigerung einer Antwort durch das
DBMS Informationen beinhalten kann.
Durch das Erstellen verschiedener Statistiken kann die Anonymität der Daten ebenfalls verloren
gehen. Ein solcher indirekter Angriff zielt darauf ab, aus mehreren Statistiken Rückschlüsse auf
die persönlichen Daten eines einzelnen Individuums ziehen zu können. Eine Schutzmaßnahme ist
in diesem Fall, die Freigabe von sogenannten sensitiven Statistiken nicht zu erlauben, was als
unterdrückte Inferenzprävention bezeichnet wird. Eine weitere Möglichkeit ist die Verzerrung
solcher Statistiken durch kontrolliertes Runden (gleiche Statistiken sind gleich zu runden) oder die
Beschränkung auf statistisch relevante Teilmengen mit der Auflage, daß gleiche Anfragen immer
Bezug auf die gleichen Teilmengen nehmen. Dieses Verfahren wird als verzerrende
Inferenzprävention bezeichnet.
Werden weitergehende Anforderungen an die Vertraulichkeit der Daten gestellt, ist deren Verschlüsselung erforderlich (vergleiche M 4.72 Datenbank-Verschlüsselung).
Ergänzende Kontrollfragen:
-
Wurden die Vertraulichkeitsanforderungen an das Datenbanksystem erfaßt und dokumentiert?
Teil 1 - Kapitel 9.2 - Seite 52
Version 1998
IT-Grundschutzhandbuch
-
Datenbanken
Sind die vertraulichen Daten ausreichend vor unbefugtem Zugriff geschützt?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 53
Datenbanken
M 2.128
IT-Grundschutzhandbuch
Zugangskontrolle einer Datenbank
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Die Datenbank-Software muß über geeignete Mechanismen zur Identifikation und Authentisierung der Benutzer verfügen, um eine wirkungsvolle Zugangskontrolle zu gewährleisten (siehe
M 2.132
Regelung
für
die
Einrichtung
von
Datenbankbenutzern/
-benutzergruppen).
Generell sollte man für normale Benutzer den Zugang zu einer Produktionsdatenbank über einen
interaktiven SQL-Interpreter unterbinden. Auf solche Datenbanken sollte ausschließlich ein
indirekter Zugang über die entsprechenden Anwendungen möglich sein. Die einzige Ausnahme
bilden hier Datenbankkennungen zu Administrationszwecken.
Remote-Zugänge zu Datenbanken sollten äußerst restriktiv gehandhabt werden. Ist diese Art des
Zugangs nicht zwingend erforderlich, so sind diese zu unterbinden. Ansonsten sollte nur
denjenigen Benutzern ein Remote-Zugang ermöglicht werden, die diesen auch tatsächlich
benötigen. Andere Benutzer dürfen nicht in der Lage sein, sich selbst einen Remote-Zugang zu
verschaffen. Keinesfalls darf ein Remote-Zugang ohne Angabe einer gültigen Benutzerkennung
und Eingabe eines Paßwortes möglich sein.
Ergänzende Kontrollfragen:
-
Werden die Kennungen einzelner Benutzer zur Zugangskontrolle direkt verwaltet? Falls ja,
aus welchem Grund erfolgt keine Verwaltung über Gruppen?
-
Gibt es Benutzerkennungen, die direkten Zugang zu einer Datenbank haben? Falls ja, aus
welchem Grund haben sie direkten Zugang?
-
Wurden die Möglichkeiten des Remote-Zugangs für die derzeit im Einsatz befindlichen
Datenbanken geprüft und ggf. deaktiviert?
Teil 1 - Kapitel 9.2 - Seite 54
Version 1998
IT-Grundschutzhandbuch
M 2.129
Datenbanken
Zugriffskontrolle einer Datenbank
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Um einen wirkungsvollen Schutz der Vertraulichkeit und Integrität der Daten einer Datenbank zu
erreichen, müssen eine Reihe von Maßnahmen umgesetzt werden. Neben einer Zugangskontrolle
der Datenbank, die in M 2.128 Zugangskontrolle einer Datenbank beschrieben wird, sind dies im
wesentlichen die folgenden Möglichkeiten der Zugriffskontrolle:
-
Schutz der Datenbankobjekte
Es sollte eine logische Zuordnung der Datenbankobjekte, also der Tabellen, Indizes,
Datenbankprozeduren, etc., zu den Anwendungen erfolgen, die diese Objekte benutzen. Die
daraus entstehenden Gruppen von Datenbankobjekten je Anwendung werden eigens hierfür
einzurichtenden Kennungen zugeordnet. Damit können die Zugriffsberechtigungen der
Datenbankobjekte so eingestellt werden, daß nur über diese speziellen Kennungen eine
Modifikation der Objekte stattfinden kann. Greifen mehrere Anwendungen auf dieselben
Datenbankobjekte zu, sollten diese als eigene Gruppe isoliert werden.
Werden beispielsweise die Daten zweier Anwendungen A und B in der Datenbank
verwaltet, so legt man zwei Datenbankkennungen AnwA und AnwB an. Alle
Datenbankobjekte, die eindeutig der Anwendung A zugeordnet werden können, werden mit
der Datenbankkennung AnwA angelegt und verwaltet. Analog wird mit den
Datenbankobjekten von Anwendung B verfahren.
Ein Beispiel für ein zentrales Datenbankobjekt, das von beiden Anwendungen benutzt wird,
sei eine Tabelle, die alle ansteuerbaren Drucker beinhaltet. Datenbankobjekte dieser
Kategorie sollten nicht einer Kennung der Anwendungen (AnwA oder AnwB) zugeordnet
werden, statt dessen sollten solche Datenbankobjekte unter einer eigenen Kennung (z. B.
Druck) zusammengefaßt und mit dieser zentralen Kennung verwaltet werden.
Diese speziellen Kennungen sind nicht personenbezogen. Statt dessen erhalten eigens
hierfür autorisierte Personen (z. B. der Datenbankadministrator oder der Administrator der
zugehörigen Anwendung) das Paßwort der benötigten Kennung, falls Modifikationen an
den Datenbankobjekten vorgenommen werden müssen.
-
Schutz der Daten
Durch eine Definition von Views können spezielle Benutzer-Sichten erzeugt werden, so daß
die Daten der Datenbank nach bestimmten Kriterien sichtbar gemacht bzw. unsichtbar
gehalten werden. Über einen View wird explizit festgelegt, welche Felder aus einer oder
mehreren Tabellen ein Benutzer zu sehen bekommt. Durch die restriktive Vergabe von
Zugriffsrechten (den im folgenden beschriebenen Grants) auf solche Views können
vertrauliche Daten vor unberechtigtem Zugriff geschützt werden.
Es müssen Zugriffsrechte (Grants) auf Tabellen, Views oder sogar einzelne Felder
einer Tabelle vergeben werden. Diese Rechte sind immer an bestimmte Benutzer, Rollen
oder Benutzergruppen gebunden. Zugriffsrechte sollten jedoch immer für Benutzergruppen
oder Rollen und nicht für einzelne Personen vergeben werden, da dies sonst bei einer
großen Anzahl von Benutzern zu einem hohen administrativen Aufwand führt. Es können
Zugriffsberechtigungen lesender (read), ändernder (update), löschender (delete) oder neu
einfügender (insert) Art unterschieden werden. Mit der Vergabe von
Version 1998
Teil 1 - Kapitel 9.2 - Seite 55
Datenbanken
IT-Grundschutzhandbuch
Zugriffsberechtigungen sollte so sparsam wie möglich umgegangen werden, da man sonst
sehr schnell den Überblick über die aktuellen Zugriffsrechte verliert und damit
Sicherheitslücken geschaffen werden. Insbesondere sollte die Möglichkeit, Rechte an alle
zu vergeben (GRANT ... TO PUBLIC), nicht genutzt werden.
Im allgemeinen ist es nur dem Besitzer eines Datenbankobjektes erlaubt, Zugriffsberechtigungen an andere Benutzer weiterzugeben. Einige Datenbanksysteme stellen jedoch
die Möglichkeit zur Verfügung, daß der Besitzer eines Datenbankobjektes auch das Recht,
Zugriffsrechte weiterzugeben, an andere Benutzer vergeben kann. Von dieser Möglichkeit
sollte nur in begründeten Ausnahmefällen Gebrauch gemacht werden, da man auf diese
Weise die Kontrolle über den Zugriff auf die Daten bzw. die Datenbankobjekte verliert.
-
Restriktiver Datenzugriff über Anwendungen
Anwendungen sollten einen restriktiven Zugriff auf die Daten unterstützen, d. h. in
Abhängigkeit der Benutzerkennung und der Gruppenzugehörigkeit sollten nur diejenigen
Funktionalitäten und Daten zur Verfügung gestellt werden, die ein Benutzer für die
Ausführung seiner Aufgaben benötigt. Eine Form der Realisierung ist hier die Verwendung
von sogenannten Stored Procedures.
Stored Procedures sind Abfolgen von SQL-Anweisungen, die in der Datenbank
voroptimiert gespeichert werden. Beim Aufruf einer Stored Procedure müssen nur ihr
Name und eventuelle Parameter angegeben werden, um die dahinterstehenden SQLAnweisungen auszuführen. Dies hat zum einen den Vorteil, daß nicht die gesamten SQLAnweisungen zum Datenbankserver übertragen werden müssen, was bei komplexeren
Operationen die Netzbelastung vermindert. Zum anderen kann das Datenbanksystem die
SQL-Anweisungen in einer optimierten Form ablegen, so daß sie schneller ausgeführt
werden. Die stärkste Einschränkung bei der Rechtevergabe ist die Vergabe von
Zugriffsrechten auf Stored Procedures statt auf Tabellen oder Views. Wenn Zugriffsrechte
nur auf Stored Procedures vergeben werden, können die Benutzer nur die von den
Datenbankverantwortlichen ausgewählten Operationen ausführen.
Beispiele:
1)
In MS Access können verschiedene Berechtigungen vergeben werden, die sich entweder auf
die Datenbank selbst (Öffnen/Ausführen, Exklusiv, Verwalten) oder auf die Tabellen und
Abfragen beziehen (Daten lesen, Daten aktualisieren, Daten löschen, Daten einfügen).
Diese Berechtigungen können dann unterschiedlichen Benutzern oder Benutzergruppen
zugeordnet werden. Standardmäßig sind bei MS Access die Gruppen "Administratoren"
und "Benutzer" eingerichtet, wobei die Gruppe "Benutzer" die Berechtigungen "Daten
lesen" und "Daten aktualisieren" für Tabellen und Abfragen und die Berechtigung
"Öffnen/Ausführen" für Datenbanken enthält. Für eine detailliertere Kontrolle der
Zugriffsrechte können eigene Gruppen definiert werden, an die unterschiedliche
Berechtigungen vergeben werden können. Dies kann im Menü Extras unter Zugriffsrechte
und Benutzer und Gruppenkonten durchgeführt werden.
2)
In einer Oracle-Datenbank kann mit dem folgendem Kommando die Gruppe "Abteilung_1"
erstellt werden:
CREATE ROLE Abteilung_1 IDENTIFIED BY <Paßwort>;
Im folgenden Beispiel wird der Gruppe "Abteilung_1" die Berechtigung erteilt, eine
Verbindung zur Datenbank herzustellen sowie eine Session zu eröffnen:
Teil 1 - Kapitel 9.2 - Seite 56
Version 1998
IT-Grundschutzhandbuch
Datenbanken
GRANT CONNECT, CREATE SESSION TO Abteilung_1;
Im folgenden Beispiel würde derselben Gruppe die Berechtigung gegeben, ein SELECT auf
die Tabelle "Test" durchzuführen:
GRANT SELECT ON Test TO Abteilung_1;
Im folgenden Beispiel würde dieser Gruppe die Berechtigung erteilt, für die Spalte
"Kommentar" der Tabelle "Test" Änderungen durchzuführen:
GRANT UPDATE (Kommentar) ON Test TO Abteilung_1;
3)
Ein Beispiel für eine Stored Procedure unter Oracle mit PL/SQL Anweisungen sieht wie
folgt aus:
PROCEDURE Example (PArtikelnr IN NUMBER, PPreis OUT NUMBER) IS
BEGIN
BEGIN <<Block>>
SELECT preis INTO PPreis
FROM TabB
WHERE artikelnr=PArtikelnr
END Block;
END;
Die Prozedur "Example" liest aus der Tabelle TabB den Preis eines Artikels nach Angabe
der Artikelnummer. Mitarbeiter, die auf die Tabelle TabB ausschließlich mit dieser
Methode zugreifen können sollen, erhalten nur das Nutzungsrecht für die Stored Procedure
und keinerlei Rechte auf die Tabelle. Damit werden z. B. auch zeitaufwendige
Suchoperationen verhindert.
Ergänzende Kontrollfragen:
-
Wurden die Datenbankobjekte vor unberechtigtem Zugriff geschützt?
-
Wurden Views für die einzelnen Benutzer definiert und dokumentiert?
-
Wurden Zugriffsrechte auf die Daten vergeben und dokumentiert?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 57
Datenbanken
M 2.130
IT-Grundschutzhandbuch
Gewährleistung der Datenbankintegrität
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator, Verantwortliche der einzelnen IT-Anwendungen
Die Integritätssicherung und -überwachung in einer Datenbank soll die Korrektheit der
zugehörigen Daten bzw. einen korrekten Zustand der Datenbank gewährleisten. Die folgenden
Techniken sind zur Vermeidung inkorrekter Daten bzw. Zustände innerhalb einer Datenbank zu
beachten:
-
Zugriffskontrolle
Damit ist der Schutz der betreffenden Datenbank vor unautorisiertem Zugriff mittels der
Vergabe von Zugriffsrechten gemeint, wie in M 2.129 Zugriffskontrolle einer Datenbank
beschrieben. Damit wird dem manipulativen Ändern von Daten bzw. Datenbankobjekten
(wie z. B. Tabellen) vorgebeugt.
Verantwortlich für die Umsetzung der Zugriffskontrolle ist der Datenbankadministrator.
Auf eine detaillierte Ausführung wird an dieser Stelle verzichtet und statt dessen auf die
Maßnahme M 2.129 Zugriffskontrolle einer Datenbank verwiesen
-
Synchronisationskontrolle
Die Synchronisationskontrolle dient der Verhinderung von Inkonsistenzen, die durch einen
parallelen Zugriff auf denselben Datenbestand entstehen können. Es gibt dazu verschiedene
Techniken, wie z. B. das Sperren von Datenbankobjekten (Locking) oder die Vergabe von
Zeitstempeln (Timestamps).
Verantwortlich für die Umsetzung sind die Verantwortlichen der IT-Anwendungen,
insofern ein zusätzlicher Mechanismus zur Verfügung gestellt werden muß, der über die
Möglichkeiten des DBMS hinausgeht.
Auf eine detaillierte Ausführung wird verzichtet, da im allgemeinen jedes DBMS eine
Synchronisationskontrolle durchführt. Vom Einsatz eines DBMS, welches dies nicht leisten
kann, wird dringend abgeraten.
-
Integritätskontrolle
Hierunter fällt die Vermeidung semantischer Fehler bzw. semantisch unsinniger Zustände
der Datenbank durch Einhaltung und Überwachung der geforderten Integritätsbedingungen.
Diese können sich auf einzelne Relationen beziehen oder mehrere Relationen miteinander in
Beziehung setzen (referentielle Integrität). Beispiele sind die Angabe eines Primärschlüssels
für eine Relation, die Definition von Wertebereichen zu den einzelnen Attributen oder die
Formulierung spezieller Bedingungen mittels einer assertion-Klausel.
Dies kann durch das DBMS automatisch mittels eines Monitors überprüft werden, der
z. B. durch die Verwendung von Triggern oder Stored Procedures realisiert werden kann.
Damit sind prinzipiell beliebige Transaktionen möglich, jedoch werden diejenigen vom
DBMS zurückgewiesen, die die Datenbank-Konsistenz verletzen würden.
Verantwortlich für die Umsetzung sind die Verantwortlichen der IT-Anwendungen
respektive der fachliche Administrator, falls es sich um eine Umsetzung der
Integritätsbedingungen in Form von Relationen, Primärschlüsseln oder allgemeinen
Datenbankobjekten handelt.
Teil 1 - Kapitel 9.2 - Seite 58
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Im Rahmen der Konzeption einer IT-Anwendung sind zu erstellen
-
ein Datenmodell, welches neben den Datenbankobjekten auch deren Beziehungen
untereinander abbildet, und
-
ein Fachkonzept, welches u. a. Bedingungen beschreibt, unter denen Daten
manipuliert werden dürfen.
Im Rahmen der Realisierung einer IT-Anwendung sind die folgenden Punkte zu beachten:
-
Die konkrete Umsetzung des in der konzeptionellen Phase definierten Datenmodells
muß festgelegt werden. Hierzu gehören die Definition und Anlage von Tabellen,
Indizes, Wertebereichen usw.
-
Die Definition von Triggern oder Stored Procedures erfolgt im Rahmen der
Realisierung des Fachkonzepts. Trigger und Stored Procedures können dabei sowohl
innerhalb der Anwendung (in den Programmen), als auch der Datenbank (für
Tabellen) Verwendung finden. Trigger, die auf Datenbankebene eingesetzt werden,
wirken unabhängig von darüberliegenden Anwendungen und sind aus diesem Grund
zentral zu verwalten.
Beispiel: Trigger 'Update' für eine Tabelle:
Immer wenn ein Datensatz der Tabelle geändert wird, dann sind die für den Trigger
definierten Anweisungen auszuführen. Eine dieser Anweisungen kann der Aufruf
einer Stored Procedure sein.
Im Rahmen von Anwendungen kann eine Integritätssicherung durch einen geeigneten Einsatz von
Commit bzw. Rollback für das Betätigen bzw. Widerrufen von Transaktionen realisiert werden.
Ergänzende Kontrollfragen:
-
Werden alle oben angegebenen Techniken zur Integritätssicherung eingesetzt?
-
Wurden die Integritätsbedingungen mit den Verantwortlichen der einzelnen ITAnwendungen abgestimmt?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 59
Datenbanken
M 2.131
IT-Grundschutzhandbuch
Aufteilung von Administrationstätigkeiten bei Datenbanksystemen
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: IT-Sicherheitsmanagement, Administrator
Um einen geordneten Betrieb von Datenbanksystemen zu ermöglichen, sind Administratoren zu
bestimmen. Diesen obliegt neben allgemeinen Administrationsarbeiten insbesondere die
Benutzerverwaltung einschließlich der Verwaltung der Zugriffsrechte. Zusätzlich sind sie für die
Sicherheitsbelange der betreuten Datenbanksysteme zuständig.
Neben den in M 2.26 Ernennung eines Administrators und eines Vertreters und M 3.10 Auswahl
eines vertrauenswürdigen Administrators und Vertreters genannten Maßnahmen sind speziell für
Datenbanksysteme folgende Dinge zu beachten.
Es sollten grundsätzlich zwei verschiedene Administrator-Rollen unterschieden werden:
-
die fachlich übergreifende Administration der Datenbank-Software und
-
die Administration der anwendungsspezifischen Belange.
Diese beiden Aufgaben sollten von verschiedenen Personen durchgeführt werden, um eine
Trennung der anwendungsspezifischen und fachlich übergreifenden Administration einer
Datenbank zu erreichen.
Der grundsätzliche Betrieb des DBMS, die Durchführung der Datensicherungen oder die
Archivierung von Datenbeständen sind beispielsweise Bestandteil der fachlich übergreifenden
Datenbankadministration.
Bei der anwendungsspezifischen Administration werden dagegen die Erfordernisse der einzelnen
Anwendungen an die Datenbank bearbeitet. Dies kann z. B. die Verwaltung der zugehörigen
Datenbankobjekte, die Unterstützung der Benutzer bei Problemen bzw. Fragen oder die
Verwaltung der entsprechenden Datenbankkennungen beinhalten. Letzteres ist allerdings nur dann
möglich, wenn die Verwaltung der Datenbankennungen je Anwendung über ein entsprechendes
Berechtigungskonzept durch die Datenbank-Software unterstützt wird, also von den fachlich
übergreifenden Berechtigungen getrennt werden kann.
Der fachlich übergreifende Administrator richtet die für die anwendungsspezifischen Belange
zuständigen Administratorkennungen mit den zugehörigen Berechtigungen ein. Dazu gehört
insbesondere das Recht, Datenbanken anzulegen. Die Rechtevergabe für die einzelnen Benutzer
sollte dagegen für jede anwendungsspezifische Datenbank getrennt durchgeführt werden und zwar
vom jeweils zuständigen anwendungsspezifischen Administrator.
Ergänzende Kontrollfragen:
-
Sind die Administrator-Rollen getrennt worden?
-
Welche Administratoren sind für die fachlich übergreifende Administration der DatenbankSoftware und welche für die Administration der anwendungsspezifischen Belange benannt
worden?
-
Wie ist die Zusammenarbeit zwischen den Administratoren geregelt? Sind deren Aufgaben
und Zuständigkeitsbereiche schriftlich fixiert?
Teil 1 - Kapitel 9.2 - Seite 60
Version 1998
IT-Grundschutzhandbuch
M 2.132
Datenbanken
Regelung für die Einrichtung von Datenbankbenutzern/
-benutzergruppen
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Für die Einrichtung von Benutzern/Benutzergruppen in einer Datenbank bilden die Voraussetzung für eine angemessene Vergabe von Zugriffsrechten (siehe M 2.129 Zugriffskontrolle
einer Datenbank) und für die Sicherstellung eines geordneten und überwachbaren Betriebsablaufs. Im allgemeinen erhält dazu jeder Datenbankbenutzer eine interne Datenbankkennung,
über die ihn das Datenbanksystem identifiziert. Damit können nur autorisierte Personen auf die
Datenbank zugreifen.
In Anlehnung an M 2.30 Regelung für die Einrichtung von Benutzern / Benutzergruppen sollte
ein Formblatt existieren, um von jedem Benutzer bzw. für jede Benutzergruppe zunächst die
erforderlichen Daten abzufragen:
-
Name, Vorname,
-
Vorschlag für die Benutzerkennung (wenn nicht durch Konventionen vorgegeben),
-
Organisationseinheit,
-
Erreichbarkeit (z. B. Telefon, Raum),
-
ggf. Projekt,
-
ggf. Anwendungen, die benutzt werden sollen und auf das Datenbanksystem zugreifen,
-
ggf. Angaben über die geplante Tätigkeit im Datenbanksystem und die dazu erforderlichen
Rechte sowie die Dauer der Tätigkeit,
-
ggf. Restriktionen auf Zeiten, Zugriffsberechtigungen (für bestimmte Tabellen, Views etc.),
eingeschränkte Benutzerumgebung,
-
ggf. Zustimmung von Vorgesetzten.
Es sollte eine begrenzte Anzahl von Rechteprofilen festgelegt werden. Ein neuer Benutzer wird
dann einem oder mehreren Profilen zugeordnet und erhält damit genau die für seine Tätigkeit
erforderlichen Rechte. Dabei sind die datenbankspezifischen Möglichkeiten bei der Einrichtung
von Benutzern und Gruppen zu beachten. Es ist sinnvoll, Namenskonventionen für die Benutzerund Gruppenkennungen festzulegen (z. B. Benutzer-ID = Kürzel Organisationseinheit || lfd.
Nummer).
Dabei können Benutzer-, Rollen- und Gruppenprofile benutzt werden. Soweit möglich, sollten
jedoch keine benutzerspezifischen Profile verwendet werden, da dies bei einer großen Anzahl von
Benutzern zu einem hohen administrativen Aufwand führt. Bei der Definition von Gruppenprofilen muß man zwischen restriktiven und großzügigen Berechtigungsprofilen abwägen.
Werden die Gruppenprofile zu restriktiv gehandhabt, muß eine große Anzahl von Gruppen
verwaltet werden, was zu einem hohen administrativen Aufwand führt. Werden die Gruppenprofile dagegen zu großzügig definiert, kann es zu Redundanzen zwischen verschiedenen Gruppen
kommen oder zur Einräumung von unnötig umfangreichen Rechten, was wiederum zur
Verletzung der Vertraulichkeit von Daten führen kann.
In der Regel muß jedem Benutzer eine eigene Datenbankkennung zugeordnet sein, es dürfen nicht
mehrere Benutzer unter derselben Kennung arbeiten.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 61
Datenbanken
IT-Grundschutzhandbuch
Normalerweise besteht zwischen der Datenbankkennung und der Benutzerkennung des zugrundeliegenden Betriebssystems keine Verbindung. Einige Hersteller bieten in ihrer DatenbankSoftware jedoch die Möglichkeit an, die Betriebssystemkennung in das Datenbanksystem zu
übernehmen. Dies erspart den Anwendern eine Paßwortabfrage für den Zugang zur Datenbank,
falls diese sich bereits mit Ihrer eigenen Betriebssystemkennung angemeldet haben.
So können beispielsweise unter Oracle sogenannte OPS$-Kennungen verwendet werden. Eine
solche Kennung setzt sich aus dem Präfix "OPS$" und der Betriebssystemkennung des Anwenders zusammen. Nur wenn sich ein Anwender mit seiner Betriebssystemkennung am Datenbanksystem anmeldet, wird kein Paßwort vom DBMS abgefragt. Meldet sich der Anwender
dagegen unter einer anderen Kennung an, so erfolgt eine Paßwortabfrage.
Diese Möglichkeit beinhaltet allerdings die Gefahr, daß bei einer Schutzverletzung auf
Betriebssystemebene (z. B. das Knacken des entsprechenden Paßwortes) der Zugriff auf die
Datenbank nicht mehr verhindert werden kann. Der Schutz der Datenbank ist demnach stark von
der Sicherheit des zugrundeliegenden Betriebssystems abhängig. Dabei handelt es sich im
allgemeinen nicht um das üblicherweise sichere Betriebssystem des Datenbank-Servers, sondern
um das eines Clients, der unter Umständen wesentlich schwächer geschützt ist. Deshalb wird von
der Verwendung dieser Möglichkeit abgeraten, statt dessen sollte bei der Forderung nach einer
einfachen Handhabung für die Benutzer (Stichwort Single-Sign-On) der Einsatz eines
Zusatzproduktes zur zentralen Benutzerverwaltung für den gesamten IT-Betrieb erwogen werden
(z. B. ISM Access Master von Bull). Aber auch hier müssen die konkreten Sicherheitsanforderungen mit dem entsprechenden Zusatzprodukt abgeglichen werden.
Ergänzende Kontrollfragen:
-
Welche organisatorischen Regelungen zur Einrichtung von Datenbankbenutzern bzw.
-benutzergruppen gibt es?
-
Wurden Namenskonventionen für die Benutzer- und Gruppenkennungen festgelegt?
-
Wurden Rechteprofile angelegt?
Teil 1 - Kapitel 9.2 - Seite 62
Version 1998
IT-Grundschutzhandbuch
M 2.133
Datenbanken
Kontrolle der Protokolldateien eines Datenbanksystems
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator, Revisor
Die in einem Datenbanksystem mögliche Protokollierung bzw. Auditierung ist in einem sinnvollen
Umfang zu aktivieren. Werden zuviele Ereignisse protokolliert, wird die Performance der
Datenbank negativ beeinflußt und die Protokolldateien wachsen stark an. Es muß also immer
zwischen dem Bedürfnis, möglichst viele Informationen zur Sicherheit der Datenbank zu
sammeln, und der Möglichkeit, diese Informationen zu speichern und auszuwerten, abgewogen
werden.
Dabei sind insbesondere folgende Vorkommnisse von Interesse:
-
Anmeldezeiten und -dauer der Benutzer,
-
Anzahl der Verbindungen zur Datenbank,
-
fehlgeschlagene bzw. abgewiesene Verbindungsversuche,
-
Auftreten von Deadlocks innerhalb des Datenbanksystems,
-
I/O-Statistik für jeden Benutzer,
-
Zugriffe auf die Systemtabellen (siehe auch M 4.69 Regelmäßiger Sicherheitcheck der
Datenbank),
-
Erzeugung neuer Datenbankobjekte und
-
Datenmodifikationen (evtl. mit Datum, Uhrzeit und Benutzer).
Die Protokollierung sicherheitsrelevanter Ereignisse ist als Sicherheitsmaßnahme allerdings nur
dann wirksam, wenn die protokollierten Daten auch ausgewertet werden. Daher sind die
Protokolldateien in regelmäßigen Abständen durch einen Revisor auszuwerten. Ist es
organisatorisch oder technisch nicht möglich, einen unabhängigen Revisor mit der Auswertung
der Protokolldateien zu betrauen, ist eine Kontrolle der Tätigkeiten des Administrators nur schwer
möglich.
Die Protokolldaten müssen regelmäßig gelöscht werden, um ein übermäßiges Anwachsen der
Protokolldateien zu verhindern. Sie dürfen allerdings nur dann gelöscht werden, wenn die
Protokolldateien vorher ausgewertet und kontrolliert wurden. Dies kann manuell oder automatisch
geschehen, falls entsprechende Werkzeuge zur Verfügung stehen.
Weiterhin ist der Zugriff auf die Protokolldateien strikt zu beschränken. Einerseits muß
verhindert werden, daß Angreifer ihre Aktionen durch nachträgliche Änderung der
Protokolldateien verbergen können, andererseits könnten über die gezielte Auswertung von
Protokolldateien Leistungsprofile der Benutzer erstellt werden. Deshalb dürfen beispielsweise
Änderungen überhaupt nicht vorgenommen werden können und lesender Zugriff darf nur den
Revisoren gestattet werden.
Um die Auswertung der Protokolldaten zu vereinfachen, können vom Datenbank-Administrator
zusätzliche Tools eingesetzt werden, die eine automatisierte Überwachung durchführen. Solche
Produkte können beispielweise die Log-Dateien von Datenbanksystemen nach vorgegebenen
Mustern auswerten und bei Bedarf einen Alarm erzeugen.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 63
Datenbanken
IT-Grundschutzhandbuch
Weitere Maßnahmen, die in diesem Zusammenhang beachtet werden müssen, sind in M 2.64
Kontrolle der Protokolldateien zu finden.
Ergänzende Kontrollfragen:
-
Wer wertet die Protokolldateien aus? Findet das Vier-Augen-Prinzip Anwendung?
-
Können die Aktivitäten des Administrators ausreichend kontrolliert werden?
-
Wird das IT-Sicherheitsmanagement bei Auffälligkeiten unterrichtet?
Teil 1 - Kapitel 9.2 - Seite 64
Version 1998
IT-Grundschutzhandbuch
M 2.134
Datenbanken
Richtlinien für Datenbank-Anfragen
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Anwendungsentwickler
Die relationale Datenbanksprache SQL (Standard Query Language) ist eine international
standardisierte Sprache für relationale Datenbanksysteme, die eine weite Verbreitung erfahren hat
und in den meisten DBMS implementiert ist. Mittels SQL können sowohl Modifikationen der
Daten (UPDATE, INSERT, DELETE), als auch der Datenbankobjekte formuliert (CREATE,
ALTER, DROP) sowie Informationen abgefragt werden (SELECT). Um einen sicheren Betrieb
eines Datenbanksystems zu gewährleisten, sollten die folgenden Grundsätze in einer Richtlinie für
Datenbank-Anfragen beschrieben sein.
-
SQL-Anfragen sollten so exakt wie möglich formuliert werden. Dies gilt insbesondere für
SQL-Anfragen, die aus Anwendungen heraus gestellt werden. So führt beispielsweise die
SQL-Anweisung
SELECT * FROM <Tabelle> WHERE <Bedingung>
bei Änderungen des Tabellenschemas (Hinzufügen bzw. Löschen von Feldern oder Vertauschen der Reihenfolge von Feldern) unweigerlich zu Fehlern oder sogar zu einem
Absturz der zugehörigen Anwendung.
-
Felder sollten immer explizit angegeben werden. Damit ist sichergestellt, daß die Daten in
der erwarteten Reihenfolge zur Verfügung stehen und beispielsweise nur diejenigen Daten
selektiert werden, die man tatsächlich benötigt.
Beispiel:
Eine Tabelle besteht aus den folgenden Feldern (mit den zugehörigen Datentypen):
Artikelnummer
NUMBER(10)
Nettopreis
NUMBER(10,2)
ArtikelbezeichnungVARCHAR(30)
Verwendungszweck
VARCHAR(200)
Es wird das neue Feld "Bestellnummer" vom Typ NUMBER(8) hinzugefügt. Das Feld
wird aus Gründen der optimalen Speicherausnutzung nicht am Ende, sondern an die zweite
Stelle der Tabelle plaziert. Die neue Tabelle sieht also wie folgt aus:
Artikelnummer
NUMBER(10)
Bestellnummer
NUMBER(8)
Nettopreis
NUMBER(10,2)
ArtikelbezeichnungVARCHAR(30)
Verwendungszweck
VARCHAR(200)
In einem solchen Fall würde eine SELECT-*-Anweisung in einer Anwendung im
schlimmsten Fall zu einem Absturz führen, da die Daten automatisch in der angegebenen
Feldreihenfolge selektiert werden. Im obigen Beispiel würde dann nicht nur das Problem
auftreten, daß die Tabelle um ein Feld ergänzt wurde (dessen Daten zusätzlich selektiert
würden), sondern, daß durch die Veränderung der Feldreihenfolge die Daten nicht mehr in
der ursprünglichen Reihenfolge selektiert würden. Dies führt unweigerlich zu Typkonflikten und einem möglichen Programmabsturz.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 65
Datenbanken
-
IT-Grundschutzhandbuch
Für einschränkende Datenbankanfragen (WHERE-Klausel) ist die Reihenfolge der angegebenen Selektionsbedingungen von großer Bedeutung. Die WHERE-Klausel sollte so
formuliert werden, daß als erstes diejenige Bedingung angegeben wird, die die kleinstmögliche Ergebnismenge selektiert und erst zum Schluß die Bedingung greift, die die
größte Ergebnismenge liefern würde. Auf diese Weise wird die Performance des Datenbanksystems optimiert, da sich durch die geschickte Anordnung der Selektionsbedingungen
der Suchvorgang erheblich verkürzen läßt. Das gleiche gilt analog für Datenbankanfragen,
die über mehrere Tabellen hinweg formuliert werden (sogenannte Joins).
Es sei an dieser Stelle erwähnt, daß Datenbankmanagementsysteme bereits häufig
Datenbankanfragen selbständig optimieren. Oft werden sogar mehrere Optimierungsstrategien zur Auswahl angeboten, die über verschiedene Parameter ausgewählt werden
können. Werden diese sogenannten Optimizer vom DBMS verwendet, kann dies allerdings
dazu führen, daß sorgfältig formulierte Datenbankabfragen intern vom DBMS nicht in der
erwarteten Art und Weise abgearbeitet werden.
In diesem Zusammenhang bieten einige Datenbankmanagementsysteme die Möglichkeit,
die Abarbeitung von Datenbankanfragen zu untersuchen (z. B. in Oracle mit EXPLAIN
oder für Ingres mittels SETOEP). Desweiteren besteht die Möglichkeit, über sogenannte
HINTS in der Datenbankanfrage deren Abarbeitung explizit zu definieren und somit den
Optimizer im Prinzip auszuschalten. Von dieser Möglichkeit sollte allerdings so wenig wie
möglich Gebrauch gemacht werden.
Welche Optimizer das DBMS unterstützt sowie deren Vor- und Nachteile sind in den
Handbüchern des DBMS normalerweise dokumentiert. Falls mehrere Optimizer zur
Auswahl stehen, sollte beim Administrator nachgefragt werden, welcher Optimizer eingesetzt wird.
-
Im Falle von Joins sollte zusätzlich beachtet werden, daß die Zuordnung von Feldern zu
den Tabellen eindeutig erfolgt.
Beispiel:
TabA:
ID
Herstellernr.
NUMBER(4)
NUMBER(6)
TabB:
ID
Artikelnr.
Preis
Bezeichnung
NUMBER(4)
NUMBER(10)
NUMBER(10,2)
VARCHAR(30)
SELECT TabA.ID, TabB.Bezeichnung, TabB.Preis
FROM
TabA, TabB
WHERE TabA.ID=TabB.ID
Das Feld "ID" ist in beiden Tabellen vorhanden und muß deshalb bei der Datenbankanfrage explizit mit dem zugehörigen Tabellennamen angegeben werden. Andernfalls ist
die Eindeutigkeit der Auswahl nicht mehr sichergestellt und die Datenbankanfrage wird mit
einer entsprechenden Fehlermeldung abgebrochen.
Alle anderen Felder sind in diesem Fall eindeutig zuordenbar. Eine explizite Angabe des
zugehörigen Tabellennamens für jedes Feld wird von SQL nicht gefordert. Trotzdem
Teil 1 - Kapitel 9.2 - Seite 66
Version 1998
IT-Grundschutzhandbuch
Datenbanken
sollten für die einzelnen Felder die eindeutige Zuordnung zur Tabelle erfolgen, wie im
obigen Beispiel für die Felder "Preis" und "Bezeichnung" der Tabelle TabB. Nur so können
unvorhergesehene Probleme vermieden werden.
Das Hinzufügen eines Feldes "Bezeichnung" für TabA würde im obigen Beispiel zu keinen
Problemen führen. Dies wäre jedoch nicht der Fall, wenn die SQL-Anweisung die
Zuordnung der Felder zu den Tabellen nicht explizit beinhalten würde. Es wäre nicht mehr
eindeutig, ob das Feld "Bezeichnung" von TabA oder TabB selektiert werden soll, da beide
Tabellen nach der Änderung von TabA ein Feld mit diesem Namen haben. Die SQLAnweisung würde mit einer Fehlermeldung abgebrochen.
-
Existieren Views auf Tabellen, so sollten diese auch für die Formulierung von Datenbankanfragen benutzt werden.
-
Alle Datenbanktransaktionen sollten explizit mit einem COMMIT bestätigt werden. Falls
das DBMS ein automatisches COMMIT unterstützt, sollte dieses nicht aktiviert werden,
da es sonst u. U. zu ungewollten Inkonsistenzen in der Datenbank kommen kann.
Beispiel: Mehrere einzelne Modifikationen gehören logisch zusammen, werden aber
automatisch durch ein COMMIT bestätigt. Kommt es nun zu einem unkontrollierten Abbruch der Transaktion und infolgedessen zu einem Rollback, sind die zuerst ausgeführten
Operationen bereits bestätigt und verbleiben in der Datenbank, während der Rest noch gar
nicht durchgeführt werden konnte.
-
Zur Vermeidung von Sperrkonflikten oder gar Deadlocks ist für jede fachliche Datenbank
eine Sperrstrategie festzulegen (z. B. hierarchisches Sperren oder explizites Sperren aller
Tabellen am Anfang der Transaktion).
-
Anwendungsentwickler sollten nach jeder SQL-Anweisung den Fehlerstatus prüfen, so daß
die Anwendung so früh wie möglich auf eingetretene Fehler reagieren kann.
-
Falls das DBMS bestimmte systemspezifische Kommandos unterstützt, mit denen beispielsweise die Protokollierung ausgeschaltet oder das Locking-Verfahren verändert
werden kann, sollten die Berechtigungen für diese Kommandos den Benutzern entzogen
werden. Hier ist also im Vorfeld genau zu klären, welche systemspezifischen Einstellungen
bzw. Kommandos von den Benutzern bzw. den Anwendungsentwicklern geändert bzw.
benutzt werden dürfen.
-
Bei der Entwicklung von Anwendungen sollten alle Datenbankzugriffe in einem Modul
oder einem bestimmten Teil des Programmcodes zusammengefaßt werden, da sonst zur
Überprüfung der obigen Grundsätze der gesamte Programmcode des Anwendungssystems
herangezogen werden müßte. Hierdurch wird die Wartung und Pflege des
Anwendungssystems, z. B. bei Änderungen des Datenmodells, erleichtert.
Ergänzende Kontrollfragen:
-
Sind Richtlinien für Datenbank-Anfragen erstellt worden?
-
Sind den Anwendungsentwicklern die Richtlinien für Datenbank-Anfragen bekannt?
-
Wie wird die Einhaltung dieser Richtlinien überprüft?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 67
Datenbanken
M 2.135
IT-Grundschutzhandbuch
Gesicherte Datenübernahme in eine Datenbank
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
In vielen Datenbanksystemen besteht aus Anwendungssicht die Notwendigkeit, Daten aus anderen
Systemen zu übernehmen. Dabei lassen sich prinzipiell die beiden folgenden Kategorien
unterscheiden:
-
Erst- oder Altdatenübernahme
Dies betrifft die Übernahme von Daten aus Altsystemen, wenn beispielsweise ein neues
Datenbanksystem beschafft wurde und produktiv eingesetzt werden soll. Hierbei ist insbesondere sicherzustellen, daß
-
die Daten in einem Format vorliegen, das in die Zieldatenbank übernommen werden
kann,
-
die Daten vollständig sind, d. h. für alle Felder, die in der Zieldatenbank gefüllt
werden sollen, müssen Daten zur Übernahme zur Verfügung gestellt werden, und
-
die Konsistenz und Datenintegrität der Datenbank gewährleistet ist.
Im Vorfeld der Datenübernahme ist ein Konzept zu erstellen, wie die zu übernehmenden
Daten aufbereitet werden müssen und wie die Übernahme konkret durchgeführt werden
soll. Weiterhin ist unbedingt eine Komplettsicherung der Altdaten vorzunehmen. Erfolgt
die Datenübernahme in mehreren Schritten, sollte vor jedem einzelnen Schritt eine unabhängige Datensicherung durchgeführt werden.
-
Regelmäßige Datenübernahme
Befinden sich in der Zieldatenbank bei einer Datenübernahme bereits Daten, die nicht
verändert werden dürfen, oder werden in regelmäßigen Zeitabständen Daten in eine
Datenbank übernommen, so
-
ist vor der Datenübernahme eine Komplettsicherung der Datenbank durchzuführen,
-
sollte die Datenübernahme wenn möglich außerhalb der regulären Betriebszeiten
stattfinden,
-
müssen die betroffenen Benutzer von der bevorstehenden Datenübernahme rechtzeitig informiert werden, insbesondere dann, wenn mit Einschränkungen hinsichtlich
der Verfügbarkeit oder des Antwortzeitverhaltens zu rechnen ist,
-
ist vor der ersten Datenübernahme ein Konzept zu erstellen, wie die zu übernehmenden Daten aufbereitet werden müssen bzw. wie die Übernahme konkret
durchzuführen ist. Insbesondere muß in diesem Konzept berücksichtigt werden, wie
Konflikte zwischen den bereits existierenden Daten in der Zieldatenbank und den zu
übernehmenden Daten vermieden werden, d. h. inwieweit die Integrität und
Konsistenz der Zieldatenbank gewahrt bleibt. Desweiteren sind Vorkehrungen zu
treffen, um eine mehrfache Übernahme der gleichen Daten zu verhindern.
Vor der Durchführung einer Datenübernahme ist festzulegen, was beim Auftreten von Fehlern zu
unternehmen ist. Dies beinhaltet z. B., ob beim Auftreten eines fehlerhaften Datensatzes mit dem
nächsten Satz fortgefahren werden kann, oder ob die komplette Datenübernahme abgebrochen
Teil 1 - Kapitel 9.2 - Seite 68
Version 1998
IT-Grundschutzhandbuch
Datenbanken
werden muß. Weiterhin ist festzulegen, wie die Datenübernahme nach einem Abbruch wieder
aufgesetzt wird.
Ergänzende Kontrollfragen:
-
Wurde ein Konzept zur Datenübernahme erstellt?
-
Erfolgt vor einer Datenübernahme eine Komplettsicherung der Datenbank?
-
Werden die Benutzer bei einer Datenübernahme rechtzeitig und umfassend informiert?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 69
Datenbanken
M 3.4
IT-Grundschutzhandbuch
Schulung vor Programmnutzung
Verantwortlich für Initiierung: Leiter Personal, Vorgesetzte
Verantwortlich für Umsetzung: Vorgesetzte, Verfahrensverantwortliche
Durch unsachgemäßen Umgang mit IT-Anwendungen hervorgerufene Schäden können vermieden
werden, wenn die Benutzer eingehend in die IT-Anwendungen eingewiesen werden. Daher ist es
unabdingbar, daß die Benutzer vor der Übernahme IT-gestützter Aufgaben ausreichend geschult
werden. Dies betrifft sowohl die Nutzung von Standardprogrammpaketen als auch von speziell
entwickelten IT-Anwendungen.
Darüber hinaus müssen auch bei umfangreichen Änderungen in einer IT-Anwendung
Schulungsmaßnahmen durchgeführt werden.
Stehen leicht verständliche Handbücher zu IT-Anwendungen bereit, so kann anstelle der
Schulung auch die Aufforderung stehen, sich selbständig einzuarbeiten. Eine wesentliche
Voraussetzung dazu ist allerdings die Bereitstellung ausreichender Einarbeitungszeit.
Ergänzende Kontrollfragen:
-
Werden Mitarbeiter, die eine IT-gestützte Aufgabe neu übernehmen sollen, ausreichend
geschult? Wird ein Schulungsplan für die Einführung einer neuen IT-Anwendung erstellt?
-
Welche IT-Anwendungen sind seit der letzten Überprüfung neu hinzugekommen? Wie
wurden die Mitarbeiter eingearbeitet? Welche Schulungsveranstaltungen haben Mitarbeiter
seitdem besucht?
Teil 1 - Kapitel 9.2 - Seite 70
Version 1998
IT-Grundschutzhandbuch
M 3.5
Datenbanken
Schulung zu IT-Sicherheitsmaßnahmen
Verantwortlich für Initiierung: Vorgesetzte, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Vorgesetzte, IT-Sicherheitsmanagement
Die überwiegende Zahl von Schäden im IT-Bereich entsteht durch Nachlässigkeit. Um dies zu
verhindern, ist jeder einzelne zum sorgfältigen Umgang mit der IT zu motivieren. Zusätzlich sind
Verhaltensregeln zu vermitteln, die ein Verständnis für die IT-Sicherheitsmaßnahmen wecken.
Insbesondere sollen folgende Themen in der Schulung zu IT-Sicherheitsmaßnahmen vermittelt
werden:
-
Sensibilisierung für IT-Sicherheit
Jeder Mitarbeiter ist auf die Notwendigkeit der IT-Sicherheit hinzuweisen. Das Aufzeigen
der Abhängigkeit der Behörde bzw. des Unternehmens und damit der Arbeitsplätze von
dem reibungslosen Funktionieren der IT-Systeme ist ein geeigneter Einstieg in die
Sensibilisierung. Darüber hinaus ist der Wert von Informationen herauszuarbeiten,
insbesondere unter den Gesichtspunkten Vertraulichkeit, Integrität und Verfügbarkeit.
Diese Sensibilisierungsmaßnahmen sind in regelmäßigen Zeitabständen zu wiederholen,
evtl. auch durch praktische Hinweise z. B. in der Hauspost.
-
Die mitarbeiterbezogenen IT-Sicherheitsmaßnahmen
Zu diesem Thema sollen die IT-Sicherheitsmaßnahmen vermittelt werden, die in einem
IT-Sicherheitskonzept erarbeitet wurden und von den einzelnen Mitarbeitern umzusetzen
sind. Dieser Teil der Schulungsmaßnahmen hat eine große Bedeutung, da viele
IT-Sicherheitsmaßnahmen erst nach einer entsprechenden Schulung und Motivation
effektiv umgesetzt werden können.
-
Die produktbezogenen IT-Sicherheitsmaßnahmen
Zu diesem Thema sollen die IT-Sicherheitsmaßnahmen vermittelt werden, die inhärent mit
einem Softwareprodukt verbunden sind und bereits im Lieferumfang enthalten sind. Dies
können neben Paßwörtern zur Anmeldung, der Pausenschaltung durch Bildschirmschoner
auch Möglichkeiten der Verschlüsselung von Dokumenten oder Datenfeldern sein.
Hinweise und Empfehlungen über die Strukturierung und Organisation von Dateien, die
Bewegungsdaten enthalten, können die Vergabe von Zugriffsrechten erleichtern und den
Aufwand zu Datensicherung deutlich reduzieren.
-
Das Verhalten bei Auftreten eines Computer-Virus auf einem PC
Hier soll den Mitarbeitern vermittelt werden, wie mit Computer-Viren umzugehen ist.
Mögliche Inhalte dieser Schulung sind (siehe M 6.23 Verhaltensregeln bei Auftreten eines
Computer-Virus):
-
Erkennen des Computer-Virusbefalls
Wirkungsweise und Arten von Computer-Viren
Sofortmaßnahmen im Verdachtsfall
Maßnahmen zur Eliminierung des Computer-Virus
Vorbeugende Maßnahmen
Version 1998
Teil 1 - Kapitel 9.2 - Seite 71
Datenbanken
-
IT-Grundschutzhandbuch
Der richtige Einsatz von Paßwörtern
Hierbei sollen die Bedeutung des Paßwortes für die IT-Sicherheit sowie die
Randbedingungen erläutert werden, die einen wirksamen Einsatz eines Paßwortes erst
ermöglichen (vgl. auch M 2.11 Regelung des Paßwortgebrauchs).
-
Die Bedeutung der Datensicherung und deren Durchführung
Die regelmäßige Datensicherung ist eine der wichtigsten IT-Sicherheitsmaßnahmen in
jedem IT-System. Vermittelt werden soll das Datensicherungskonzept (s. Kapitel 3.4
Datensicherungskonzept) der Behörde bzw. des Unternehmens und die von jedem
einzelnen durchzuführenden Datensicherungsaufgaben. Besonders bedeutend ist dies für
den PC-Bereich, in dem jeder Benutzer selbst die Datensicherung verantwortlich
durchführen muß.
-
Der Umgang mit personenbezogenen Daten
An den Umgang mit personenbezogene Daten sind besondere Anforderungen zu stellen.
Mitarbeiter, die mit personenbezogenen Daten (sowohl in IT-Systemen als auch in Akten)
arbeiten müssen, sind für die gesetzlich erforderlichen Sicherheitsmaßnahmen zu schulen.
Dies
betrifft
den
Umgang
mit
Auskunftsersuchen,
Änderungsund
Verbesserungswünschen der Betroffenen, gesetzlich vorgeschriebene Löschfristen, Schutz
der Vertraulichkeit und die Übermittlung der Daten.
-
Die Einweisung in Notfallmaßnahmen
Sämtliche Mitarbeiter (auch nicht unmittelbar mit IT befaßte Personen wie Pförtnerdienst
oder Wachpersonal) sind in bestehende Notfallmaßnahmen einzuweisen. Dazu gehört die
Erläuterung der Fluchtwege, die Verhaltensweisen bei Feuer, der Umgang mit
Feuerlöschern, das Notfall-Meldesystem (wer als erstes wie zu benachrichtigen ist) und der
Umgang mit dem Notfall-Handbuch.
-
Vorbeugung gegen Social Engineering
Die Mitarbeiter sollen auf die Gefahren des Social Engineering hingewiesen werden. Die
typischen Muster solcher Versuche, über gezieltes Aushorchen an vertrauliche
Informationen zu gelangen, ebenso wie die Methoden, sich dagegen zu schützen, sollten
bekannt gegeben werden. Da Social Engineering oft mit der Vorspiegelung einer falschen
Identität einhergeht, sollten Mitarbeiter regelmäßig darauf hingewiesen werden, die
Identität von Gesprächspartnern zu überprüfen und insbesondere am Telefon keine
vertraulichen Informationen weiterzugeben.
Ergänzende Kontrollfragen:
-
Welche Themen bzgl. IT-Sicherheitsmaßnahmen wurden schon geschult?
-
Werden neue Mitarbeiter entsprechend in die IT-Sicherheitsmaßnahmen eingewiesen?
-
Welche Schulungsmaßnahmen werden in welchen Intervallen angeboten?
-
Decken die Inhalte der Schulungsmaßnahmen die erforderlichen Gebiete ab?
Teil 1 - Kapitel 9.2 - Seite 72
Version 1998
IT-Grundschutzhandbuch
M 3.10
Datenbanken
Auswahl eines vertrauenswürdigen Administrators und Vertreters
Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, Leiter Personal, Leiter IT, TKAnlagen-Verantwortlicher, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Den IT-System- oder TK-Anlagen-Administratoren und deren Vertretern muß vom Betreiber
großes Vertrauen entgegengebracht werden können. Sie haben - in Abhängigkeit vom eingesetzten
System - weitgehende und oftmals alle Befugnisse. Administratoren und ihre Vertreter sind in der
Lage, auf alle gespeicherten Daten zuzugreifen, ggf. zu verändern und Berechtigungen so zu
vergeben, daß erheblicher Mißbrauch möglich wäre.
Das hierfür eingesetzte Personal muß sorgfältig ausgewählt werden. Es soll regelmäßig darüber
belehrt werden, daß die Befugnisse nur für die erforderlichen Administrationsaufgaben verwendet
werden dürfen.
Ergänzende Kontrollfragen:
-
Wie wurde die Zuverlässigkeit des Administrators bzw. seines Stellvertreters festgestellt?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 73
Datenbanken
M 3.11
IT-Grundschutzhandbuch
Schulung des Wartungs- und Administrationspersonals
Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, Leiter Personal, Leiter IT, TKAnlagen-Verantwortlicher, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Vorgesetzte
Das Wartungs- und Administrationspersonal sollte mindestens soweit geschult werden, daß
-
alltägliche Administrationsarbeiten selbst durchgeführt,
-
einfache Fehler selbst erkannt und behoben,
-
Datensicherungen selbsttätig durchgeführt und
-
die Eingriffe von externem Wartungspersonal nachvollzogen
werden können.
Entsprechende Schulungen werden in der Regel von den Herstellern der IT-Systeme bzw. TKAnlagen angeboten. Administratoren von TK-Anlagen sollten außerdem in der Lage sein,
-
das Betriebsverhalten der TK-Anlage mit Hilfe der Kontrollanzeigen an den Geräten zu
beurteilen,
-
die TK-Anlage selbständig außer- und in Betrieb nehmen zu können.
Teil 1 - Kapitel 9.2 - Seite 74
Version 1998
IT-Grundschutzhandbuch
M 4.1
Datenbanken
Paßwortschutz für PC und Server
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: IT-Benutzer
Der Paßwortschutz eines IT-Systems soll gewährleisten, daß nur solche Benutzer einen Zugriff
auf die Daten und IT-Anwendungen erhalten, die eine entsprechende Berechtigung nachweisen.
Unmittelbar nach dem Einschalten des IT-Systems muß der Berechtigungsnachweis erfolgen.
Kann der Benutzer die erforderliche Berechtigung nicht nachweisen, so verhindert der
Paßwortschutz den Zugriff auf das IT-System.
Realisiert werden kann der Paßwortschutz an einem IT-System auf verschiedene Weise:
-
Die meisten BIOS-Varianten bieten die Installation eines Boot-Paßwortes an. Bei Fehleingaben wird der Bootvorgang nicht fortgesetzt. Ein BIOS-Paßwort ist nicht schwer zu
überwinden, schützt aber vor Zufallstätern, sollte also zumindest überall da eingesetzt
werden, wo keine besseren Zugriffsschutzmechanismen vorhanden sind (siehe auch unten:
BIOS-Paßwortschutz).
-
Gute Betriebssysteme enthalten bereits Zugriffsschutzmechanismen. In den meisten Fällen
müssen diese aber noch aktiviert werden, beispielsweise durch die Vergabe von Paßwörtern
für alle Benutzer. Näheres hierzu findet sich in den betriebssystem-spezifischen
Bausteinen.
-
Es wird Zusatzhardware oder -software installiert, die vor dem eigentlichen Start des
Rechners ein Paßwort abfragt und bei falscher Paßworteingabe die weitere Nutzung des
IT-Systems verhindert.
Für den Umgang mit Paßwörtern sind die Hinweise in M 2.11 Regelung des Paßwortgebrauchs
zu beachten, insbesondere ist das Paßwort regelmäßig zu ändern.
BIOS-Paßwortschutz
Moderne BIOS-Varianten bieten eine Vielzahl von Sicherheitsmechanismen an, mit denen sich die
Benutzer oder die Systemadministration vertraut machen sollten. Auf keinen Fall sollten aber
ungeschulte Benutzer BIOS-Einträge verändern, da hierdurch schwerwiegende Schäden
verursacht werden können.
-
Paßwortschutz: Bei den meisten BIOS-Varianten kann ein Paßwortschutz aktiviert werden.
Dieser kann verhältnismäßig einfach überwunden werden, sollte aber auf jeden Fall benutzt
werden, wenn keine anderen Zugriffsschutzmechanismen zur Verfügung stehen. Meist
kann ausgewählt werden, ob das Paßwort vor jedem Rechnerstart oder nur vor Zugriffen
auf die BIOS-Einstellungen überprüft werden soll. Teilweise können sogar verschiedene
Paßwörter für diese Prüfungen benutzt werden. Um zu verhindern, daß Unbefugte die
BIOS-Einstellungen ändern, sollte das Setup- oder Adminstrator-Paßwort immer aktiviert
werden.
Mit einigen (leider wenigen) BIOS-Varianten kann zusätzlich der Zugriff auf die
Diskettenlaufwerke durch ein Paßwort geschützt werden. Dies sollte benutzt werden, um
das unbefugte Aufspielen von Software oder das unbemerkte Kopieren von Daten zu
verhindern.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 75
Datenbanken
IT-Grundschutzhandbuch
-
Boot-Reihenfolge: Als Bootfolge sollte immer “C,A” eingestellt werden. Dies schützt vor
der Infektion mit Boot-Viren, falls versehentlich eine Diskette im Laufwerksschacht
vergessen wird, und spart Zeit und schont das Diskettenlaufwerk.
-
Virenschutz, Virus-Warnfunktion: Wird diese Funktion aktiviert, verlangt der Rechner vor
einer Veränderung des Bootsektors eine Bestätigung, ob diese durchgeführt werden darf.
Ergänzende Kontrollfragen:
-
Ist auf den betroffenen Rechnern ein Paßwortschutz installiert?
-
Welche BIOS- Sicherheitsmechanismen sind aktiviert?
Teil 1 - Kapitel 9.2 - Seite 76
Version 1998
IT-Grundschutzhandbuch
M 4.7
Datenbanken
Änderung voreingestellter Paßwörter
Verantwortlich für Initiierung: TK-Anlagen-Verantwortlicher,
Leiter IT
IT-Sicherheitsmanagement,
Verantwortlich für Umsetzung: Administrator
Viele IT-Systeme, TK-Anlagen und Netzkoppelelemente (bspw. ISDN-Router, Sprach-DatenMultiplexer etc.) besitzen nach der Auslieferung durch den Hersteller noch voreingestellte
Standardpaßwörter. Diese sollten als erstes durch individuelle Paßwörter ersetzt werden. Hierbei
sind die einschlägigen Regeln für Paßwörter zu beachten (vgl. M 2.11 Regelung des
Paßwortgebrauchs).
Achtung: Bei einigen TK-Anlagen werden vorgenommene Änderungen der Konfiguration nur im
RAM abgelegt. Dies gilt auch für Paßwortänderungen. Daher ist nach einer solchen Operation
stets eine Datensicherung vorzunehmen und eine neue Sicherungskopie zu erstellen. Unterbleibt
dies, so ist nach einem "Restart" der Anlage wieder das Standardpaßwort gültig. Weiterhin sollte
überprüft werden, ob nach Einrichten eines neuen Paßworts das Standardpaßwort tatsächlich
seine Gültigkeit verloren hat und nicht weiterhin für den Systemzugang genutzt werden kann.
Ergänzende Kontrollfragen:
-
Ist die Anlage noch mit einem Standardpaßwort versehen?
-
Wurden die Sicherungskopien nach der Vergabe und Speicherung des individuellen Paßworts angelegt?
-
Ist der Systemzugang mit dem Standardpaßwort nach der Eingabe eines neuen Paßworts
weiterhin möglich?
-
Werden die einschlägigen Regeln zum "Paßwort-Handling" beachtet?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 77
Datenbanken
M 4.67
IT-Grundschutzhandbuch
Sperren und Löschen nicht benötigter Datenbank-Accounts
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Datenbank-Accounts, die über einen längeren Zeitraum nicht benutzt werden, sollten gesperrt und
später - falls möglich - gelöscht werden. Bei der Sperrung bzw. auf jeden Fall vor dem Löschen
eines Datenbank-Accounts sollte der betroffene Benutzer informiert werden.
Wenn ein neu einzurichtender Benutzer seinen Datenbank-Account nur für einen befristeten
Zeitraum benötigt, sollte dieser auch nur befristet eingerichtet werden, falls die Datenbank eine
solche Möglichkeit zur Verfügung stellt. Es kann vorteilhaft sein, Accounts grundsätzlich nur
befristet einzurichten und in regelmäßigen Abständen (z. B. jährlich) bei Bedarf zu verlängern.
Ist absehbar, daß ein Benutzer einer Datenbank längere Zeit abwesend ist (durch Urlaub,
Krankheit, Abordnung, o. ä.), so sollte sein Account für diese Zeit im Datenbanksystem gesperrt
werden, so daß das Arbeiten unter seiner Benutzerkennung für diese Zeit nicht mehr möglich ist.
Es muß sichergestellt sein, daß der Datenbankadministrator alle längeren Abwesenheitszeiträume
von Benutzern mitgeteilt bekommt. Sinnvollerweise sollte dies im Rahmen der üblichen
Abwesenheitsmeldungen über die Personalstelle erfolgen.
Darüberhinaus sollte die Datenbankadministration schnellstmöglichst über das endgültige
Ausscheiden eines Benutzers informiert werden. Spätestens am letzten Arbeitstag des Benutzers
ist dessen Account zu sperren.
Ergänzende Kontrollfragen:
-
Existieren organisatorische Regelungen für befristete Datenbank-Accounts, insbesondere
dann, wenn das Datenbanksystem das Einrichten solcher Accounts nicht unterstützt?
-
Wie wird überprüft, welche Datenbank-Accounts länger nicht benutzt wurden?
-
Wird regelmäßig geprüft, welche Datenbank-Accounts nicht mehr benötigt werden?
-
Wird der Datenbankadministration mitgeteilt, wenn Benutzer der Datenbank für längere
Zeit abwesend bzw. ausgeschieden sind?
Teil 1 - Kapitel 9.2 - Seite 78
Version 1998
IT-Grundschutzhandbuch
M 4.68
Datenbanken
Sicherstellung einer konsistenten Datenbankverwaltung
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement, Administrator
Verantwortlich für Umsetzung: Administrator
Die Datenbankadministrator-Kennung unterliegt prinzipiell keinerlei Beschränkungen bei der
Nutzung des Datenbanksystems, was die Gefahr von Fehlern oder Mißbrauch erhöht. Deshalb
sollte auch der Datenbankadministrator neben seiner Administrator-Kennung eine normale
Benutzer-Kennung erhalten und nur dann unter der Administrator-Kennung arbeiten, wenn es
notwendig ist.
Durch Aufgabenteilung, Regelungen und Absprache ist sicherzustellen, daß Administratoren
keine inkonsistenten oder unvollständigen Eingriffe vornehmen. Dabei sollten folgende
Bedingungen erfüllt sein:
-
Die Art und Weise der Durchführung von Änderungen sowie deren Dokumentation ist
festzulegen.
-
Art, Umfang und Grund der Änderungen sind zu beschreiben.
-
Änderungen an Datenbankobjekten oder Daten sind prinzipiell durch den Verantwortlichen
der IT-Anwendung genehmigungspflichtig. Handelt es sich dabei um ein zentrales
Datenbankobjekt, so erfordert eine Änderung die Zustimmung aller Verantwortlichen der
betroffenen IT-Anwendungen.
-
Der Zeitpunkt der geplanten Änderungen ist festzulegen und bekanntzugeben.
-
Vor der Durchführung von Änderungen muß die Datenbank komplett gesichert werden.
Um den Mißbrauch weitgehend einzuschränken und Inkonsistenzen zu vermeiden, sollten
zusätzlich alle Datenbankobjekte einer Anwendung unter die Verwaltung einer eigens für die
jeweilige Anwendung eingerichteten Benutzerkennung gestellt werden. Änderungen an den
Datenbankobjekten bleiben somit diesen speziellen Benutzer-Kennungen vorbehalten, so daß
selbst unter der Administrator-Kennung der Datenbank keine Modifikationen vorgenommen
werden können. Kenntnis über das Paßwort dieser speziellen Benutzer-Kennungen sollte nur
derjenige Datenbankadministrator haben, der für die Administration der entsprechenden
anwendungsspezifischen Belange verantwortlich ist.
Beispiel:
In einer Datenbank werden die Daten von drei Anwendungen A, B und C verwaltet. Alle
Datenbankobjekte, die ausschließlich der Anwendung A zuzuordnen sind, werden unter der
Datenbank-Benutzerkennung AnwA eingerichtet und nur über diese Kennung verwaltet. Analog
wird mit den Datenbankobjekten der anderen beiden Anwendungen verfahren. Auf diese Weise
können an den Datenbankobjekten der drei Anwendungen nur mittels der jeweiligen DatenbankBenutzerkennung Modifikationen vorgenommen werden (unter der Voraussetzung, daß die
Zugriffsrechte entsprechend restriktiv definiert wurden).
Datenbankobjekte, die von mindestens zwei der drei Anwendungen benötigt werden, sollten unter
einer zentralen Datenbank-Kennung eingerichtet und verwaltet werden.
Das entsprechende Paßwort der drei anwendungsspezifischen Kennungen ist nur demjenigen
Administrator bekannt, der für die Verwaltung und Pflege der Datenbankobjekte der jeweiligen
Anwendung verantwortlich ist. Das Paßwort für die Datenbank-Kennung, über die die zentralen
Datenbankobjekte verwaltet wird, ist dagegen keinem dieser Administratoren bekannt, sondern
Version 1998
Teil 1 - Kapitel 9.2 - Seite 79
Datenbanken
IT-Grundschutzhandbuch
unterliegt der Obhut eines weiteren Administrators. Auf diese Weise kann verhindert werden, daß
die Administratoren der jeweiligen Anwendungen Modifikationen an zentralen Datenbankobjekten
vornehmen können, die unter Umständen die Funktionalität der anderen Anwendungen
beeinträchtigen könnte.
Ergänzende Kontrollfragen:
-
Wie ist sichergestellt, daß Eingriffe des Datenbankadministrators nicht zu Inkonsistenzen
führen?
-
Haben alle Datenbankadministratoren
eingeschränkten Rechten?
-
Werden standardmäßig die zusätzlichen Benutzer-Kennungen benutzt?
Teil 1 - Kapitel 9.2 - Seite 80
eine
zusätzliche
Benutzer-Kennung
mit
Version 1998
IT-Grundschutzhandbuch
M 4.69
Datenbanken
Regelmäßiger Sicherheitscheck der Datenbank
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Der Datenbankadministrator sollte regelmäßig, jedoch mindestens einmal monatlich einen
Sicherheitscheck des Datenbanksystems durchführen. Folgende Punkte sollten dabei u. a. geprüft
werden, wobei die mit (*) markierten Punkte meist durch entsprechende Skripte automatisiert
werden können:
-
Sind die erforderlichen und geplanten Sicherungs- und Sicherheitsmechanismen aktiv und
greifen sie auch?
-
Gibt es Datenbank-Benutzer ohne Paßwort? (*)
-
Gibt es Benutzer, die längere Zeit das Datenbanksystem nicht mehr benutzt haben?
-
Wer darf bzw. kann außer dem Datenbank-Administrator auf die Dateien der DatenbankSoftware bzw. auf die Dateien der Datenbank auf Betriebssystemebene zugreifen? (*)
-
Wer hat außer dem Datenbank-Administrator Zugriff auf die System-Tabellen?
-
Wer darf mit einem interaktiven SQL-Editor auf die Datenbank zugreifen?
-
Welche Benutzerkennungen haben modifizierende Zugriffsrechte auf die Datenbankobjekte
der Anwendungen? (*)
-
Welche Benutzerkennungen haben lesende und / oder modifizierende Zugriffsrechte auf die
Daten der Anwendungen? (*)
-
Welche Benutzer besitzen die gleichen Rechte wie der Datenbank-Administrator? (*)
-
Verfügt das Datenbanksystem über ausreichend freie Ressourcen? (*)
Anmerkung:
System-Tabellen sind die Tabellen, mittels derer die Datenbank selbst verwaltet wird. In diesen
Tabellen werden beispielsweise die einzelnen Datenbankobjekte, die Datenbankkennungen, die
Zugriffsberechtigungen sowie die Zuordnungen von Dateien zu Speichermedien verwaltet. Die
System-Tabellen werden vom DBMS selbst bei der Erstellung einer Datenbank erzeugt. Eine
Modifikation dieser Tabelleninhalte ist prinzipiell immer mit Datenbankkennungen möglich, die
Administratorrechte besitzen. Werden die Daten der System-Tabellen durch UPDATE-,
INSERT- oder DELETE-Kommandos modifiziert, besteht ein hohes Risiko, daß die Datenbank
zerstört wird. Aus diesem Grund sollte man auf die Vergabe von modifizierenden Rechten auf die
System-Tabellen verzichten. Selbst ein lesender Zugriff sollte beschränkt werden, da über die
System-Tabellen alle Informationen der Datenbank ermittelt werden können.
Ergänzende Kontrollfragen:
-
Wann wurde der letzte Sicherheitscheck durchgeführt?
-
Werden die Durchführung und die Ergebnisse der Sicherheitschecks dokumentiert?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 81
Datenbanken
M 4.70
IT-Grundschutzhandbuch
Durchführung einer Datenbanküberwachung
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Um die Verfügbarkeit, die Datenbankintegrität und die Vertraulichkeit der Daten gewährleisten
zu können, ist eine regelmäßige Datenbanküberwachung erforderlich. Die wesentlichen Punkte,
die es dabei zu beachten gilt, werden im folgenden kurz erläutert.
Die Datenbank ist in regelmäßigen Zeitabständen hinsichtlich einer möglichen Fragmentierung zu
überprüfen, um gegebenenfalls Maßnahmen wie z. B. eine Reorganisation der Datenbank planen
und durchführen zu können.
Datenbanksysteme verwalten den ihnen zur Verfügung gestellten Speicherplatz in der Regel in der
Form von Blöcken fester Größe. Wenn Sätze in eine leere Tabelle eingefügt werden, werden neue
Blöcke für diese Tabelle reserviert und mit den Datensätzen gefüllt. Bei diesem Neuanlegen ist es
möglich, die Blöcke (mit Ausnahme des letzten) fast vollständig zu nutzen.
Werden im späteren Betrieb Datensätze gelöscht, wird der von ihnen belegte Speicherplatz in den
Blöcken freigegeben. Dieser Platz kann dann grundsätzlich für andere Datensätze genutzt werden.
Da die Datensätze aber alle unterschiedliche Längen haben, kann in der Regel ein freier
Speicherbereich nicht zu 100 % ausgenutzt werden. Dadurch entsteht durch die Datenänderungen
im Laufe der Zeit eine immer größere Anzahl kleiner Lücken in den Blöcken der Datenbank, die
meist nicht mehr genutzt werden können. Diese Lücken entstehen nicht nur durch DELETE- und
INSERT-Operationen, sondern auch durch UPDATEs, da ein Datensatz nicht mehr an derselben
Stelle gespeichert werden kann, wenn sich seine Länge geändert hat.
Das Vorhandensein solcher Lücken erhöht nicht nur den Speicherbedarf, sondern verlangsamt
auch Datenbankoperationen, da Datensätze oder freier Speicherplatz erst in einem größeren
Plattenbereich gesucht werden müssen.
Der Grad der Fragmentierung in den Blöcken einer Tabelle kann durch den Vergleich zwischen
der Menge der Daten in den Datensätzen in der Tabelle und dem von den Blöcken der Tabelle
belegtem Speicherplatz festgestellt werden. Auswertungen über den Fragmentierungsgrad werden
für einige DBMSe auch von der mitgelieferten Administrationssoftware oder von
Zusatzprodukten unterstützt.
Sollte die Fragmentierung der Datenbank aufgrund einer der oben genannten Gründe zu groß
werden, muß eine Reorganisation durchgeführt werden. Dies kann z. B. manuell erfolgen, in dem
zuerst alle Daten der Datenbank exportiert, dann alle Tabellen neu berechnet und angelegt und
schließlich alle Daten in die neue Datenbank wieder importiert werden. Für manche DBMSe sind
auch Hilfsprogramme zum Defragmentieren von Tabellen erhältlich.
Ebenso sind die Datenbankdateien regelmäßig hinsichtlich ihres Füllgrades zu überprüfen, um
rechtzeitig Maßnahmen wie z. B. eine Erweiterung der Speicherkapazitäten planen und
durchführen zu können. Manche DBMSe erlauben es dem Administrator durch Definition
bestimmter Parameter bereits beim Anlegen der Tabellen einer zu starken und zu raschen
Fragmentierung vorzubeugen. So kann für eine Tabelle von vornherein eine bestimmte Menge
zusammenhängender Blöcke reserviert werden, in denen zusätzlich bereits freier Platz für
Änderungen im Betrieb bereitgehalten wird.
Teil 1 - Kapitel 9.2 - Seite 82
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Beispiel:
Bei einer Oracle Datenbank wird jeder Tabelle eine feste Anzahl von Extents zugeordnet. Der
Begriff Extent wird im Oracle Sprachgebrauch als logische Größeneinheit verwendet. Die Daten
einer Tabelle werden in mindestens einem Extent abgelegt. Sobald die Kapazität eines Extents
ausgeschöpft ist, legt das DBMS automatisch ein weiteres Extent an. Beim Erstellen einer
Tabelle können dabei folgende Werte definiert werden:
-
Größe des ersten Extent in Bytes
-
Größe des zweiten Extents in Bytes
-
Wachstum aller weiteren Extents in Prozent, wobei diese Zahl in Relation zur Größe des
zweiten Extents steht.
-
Maximale Anzahl an Extents, die für die Tabelle angelegt werden dürfen.
-
Mit dem Parameter PCTFREE wird festgelegt, wieviel Prozent der neuen Blöcke für
spätere Änderungen freigehalten werden.
Es muß ebenfalls regelmäßig überprüft werden, ob das Datenvolumen tatsächlich in dem Maße
anwächst wie es ursprünglich angenommen wurde. Wächst es langsamer, werden unnötige
Speicherressourcen gebunden, die anderweitig verwendet werden könnten. Wächst es schneller,
kann es unter Umständen zu Speicherengpässen kommen.
Darüber hinaus ist die Auslastung der Datenbank ist regelmäßig zu prüfen, insbesondere im
Hinblick auf die eingestellten Obergrenzen (siehe M 4.73 Festlegung von Obergrenzen).
Welche Informationen für eine konkrete Datenbanküberwachung relevant sind, hängt von deren
spezieller Funktionsweise, also von der eingesetzten Datenbank-Standardsoftware ab.
Dementsprechend sind auch individuelle Maßnahmen einzuleiten, die die Datenbankkonfiguration
dahingehend modifizieren, daß sie den Anforderungen hinsichtlich Zugriffsgeschwindigkeiten,
durchzuführender Transaktionen usw. gerecht wird.
Eine Automatisierung der Datenbanküberwachung kann mittels Skripten durchgeführt werden.
Eine Voraussetzung ist allerdings, daß die Informationen in auswertbarer Form von der
eingesetzten Datenbanksoftware zur Verfügung gestellt werden.
Ergänzende Kontrollfragen:
-
Werden die Datenbankdateien, wichtige Tabellen und die Auslastung der Datenbank
regelmäßig überprüft?
-
Sind die Überwachungszeiträume angemessen definiert?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 83
Datenbanken
M 4.71
IT-Grundschutzhandbuch
Restriktive Handhabung von Datenbank-Links
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Über sogenannte Datenbank-Links (DB-Links) besteht die Möglichkeit, von einer Datenbank aus
auf die Daten einer anderen Datenbank zuzugreifen. Um einen angemessenen Schutz der Daten zu
gewährleisten, sollte diese Technik jedoch nur dann verwendet werden, wenn dies unbedingt
notwendig ist.
Um die Berechtigungen eines Benutzers bei der Verwendung von DB-Links kontrollieren zu
können, ist ein entsprechendes Konzept hinsichtlich der Definition von Benutzer-Kennungen
erforderlich. So erhält ein Benutzer prinzipiell die Möglichkeit, auf eine fremde Datenbank
zuzugreifen, wenn dort die gleiche Benutzer-Kennung existiert, mit der sich der Benutzer an der
lokalen Datenbank anmeldet. Einen weitergehenderen Schutz erhält man durch die Möglichkeit,
einen DB-Link mit expliziter Angabe einer Benutzer-Kennung und eines Paßwortes zu erstellen.
Prinzipiell ist zunächst einmal jeder Benutzer der Datenbank befugt, solche DB-Links zu erstellen
(unter der Voraussetzung, daß er in der Lage ist, das entsprechende CREATE-Kommando
auszuführen). Im allgemeinen sollte jedoch nur der Administrator das Recht besitzen, DB-Links
zu erstellen. Insbesondere gilt dies für DB-Links, die von allen Datenbankbenutzern genutzt
werden dürfen (sogenannte PUBLIC DB-Links). Die Berechtigung zur Erstellung von DB-Links
sollte dagegen für normale Benutzerkennungen explizit nicht vergeben werden.
Weiterhin sollte die Anzahl von parallel nutzbaren DB-Links eines Benutzers begrenzt werden,
um die Belastung der Datenbankserver unter Kontrolle halten zu können. Ansonsten kann ein
Angreifer dies ausnutzen, um die Verfügbarkeit der Datenbankserver zu reduzieren oder diese
sogar vollständig lahmzulegen.
Eine Dokumentation der vom Administrator angelegten DB-Links ist unabdingbar. Die
Dokumentation sollte neben der Verbindungsart (über eine spezielle Benutzerkennung oder unter
der Voraussetzung, daß die jeweilige aktuelle Datenbankkennung ebenfalls für die verbundene
Datenbank angelegt wurde) auch beinhalten, welcher Benutzerkreis in der Lage ist, den
entsprechenden DB-Link zu nutzen. Wie bereits erwähnt, steht ein DB-Link, der als PUBLIC
definiert wurde, allen Datenbankkennungen zur Verfügung.
Ergänzende Kontrollfragen:
-
Existiert ein Konzept zur Definition von Benutzer-Kennungen und inwieweit ist darin die
mögliche Verwendung von DB-Links berücksichtigt?
-
Welche Benutzer-Kennungen sind berechtigt, DB-Links zu erstellen?
-
Existiert ein Konzept zur Verwendung von DB-Links? Falls ja, wurde es umgesetzt?
Teil 1 - Kapitel 9.2 - Seite 84
Version 1998
IT-Grundschutzhandbuch
M 4.72
Datenbanken
Datenbank-Verschlüsselung
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator, Anwendungsentwickler
In Abhängigkeit von der Art der in einer Datenbank gespeicherten Informationen und den sich
daraus ergebenden Anforderungen an deren Vertraulichkeit und Integrität kann es notwendig
werden, diese Daten zu verschlüsseln. Dabei kann zwischen einer Online- und einer OfflineVerschlüsselung unterschieden werden:
-
Bei einer Online-Verschlüsselung werden die Daten während des laufenden Betriebs verund entschlüsselt, ohne daß die betroffenen Benutzer davon etwas merken. Dafür können
Tools eingesetzt werden, mit denen entweder auf Betriebssystemebene die gesamte
Festplatte verschlüsselt wird, oder solche, mit denen nur die Anwendungsdaten der
Datenbank verschlüsselt werden.
-
Bei einer Offline-Verschlüsselung werden die Daten erst nach ihrer Bearbeitung
verschlüsselt und vor ihrer Weiterverarbeitung wieder entschlüsselt. Dies wird im
allgemeinen mit Tools durchgeführt, die nicht in das Datenbanksystem integriert sind, und
kann insbesondere für Datensicherungen oder Datenübertragungen sinnvoll sein. Dabei ist
zu beachten, daß genügend Platz auf der Festplatte vorhanden ist, da die Ver- bzw.
Entschlüsselung nur dann erfolgreich ausgeführt werden kann, wenn auf der Festplatte
genügend Platz für das Original und die verschlüsselte Version der Datenbank verfügbar
ist.
Darüber hinaus besteht die Möglichkeit, Daten weiterhin im Klartext in der Datenbank
abzuspeichern, beim Zugriff über ein Netz jedoch eine verschlüsselte Datenübertragung zu
realisieren. Dies kann z. B. durch die Secure Network Services der Oracle SQL*Net
Produktfamilie durchgeführt werden.
Welche Daten mit welchem Verfahren zu verschlüsseln sind, ist am besten bereits bei der
Auswahl der Datenbank-Standardsoftware festzustellen (siehe M 2.124 Geeignete Auswahl einer
Datenbank-Software). Dabei sollten die Anforderungen hinsichtlich der Verschlüsselung von
Datenbeständen mit den entsprechenden Leistungsmerkmalen der Datenbank-Software verglichen
werden. Als Mindestanforderung sollte sie in jedem Fall sicherstellen, daß die Paßwörter der
Benutzer-Kennungen der Datenbank verschlüsselt abgelegt sind.
Falls die Anforderungen durch keine der am Markt verfügbaren Datenbank-Standardsoftware
abgedeckt werden können, sollte man den Einsatz von Zusatzprodukten prüfen, um die
entsprechende Sicherheitslücke zu schließen. Falls auch keine Zusatzprodukte erhältlich sind,
muß ein Konzept für die Umsetzung einer Verschlüsselungsstrategie erstellt werden, das im
Unternehmen bzw. in der Behörde umgesetzt wird.
Ergänzende Kontrollfragen:
-
Werden von der Datenbank oder durch Zusatzprodukte geeignete Techniken zur
Verschlüsselung bereitgestellt?
-
Sind die Verantwortlichen über ein ordnungsgemäßes Schlüsselmanagement informiert?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 85
Datenbanken
M 4.73
IT-Grundschutzhandbuch
Festlegung von Obergrenzen
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator, Anwendungsentwickler
Um den Zugriff auf ein Datenbanksystem besser kontrollieren zu können und um die Performance
zu verbessern, ist die Festlegung von Obergrenzen für bestimmte Parameter sinnvoll. Dabei sind
vor allem die folgenden Punkte zu beachten:
Festlegung von Obergrenzen für selektierbare Datensätze
Insbesondere wenn große Datenmengen in einer Datenbank abgelegt wurden, sollte eine maximale
Anzahl von Datensätzen definiert werden, die im Rahmen eines Datenzugriffs selektiert werden
können.
Existieren solche Obergrenzen nicht, so kann ein Benutzer gezielt oder unbeabsichtigt beliebig
umfangreiche Selects durchführen. Dies behindert nicht nur den einzelnen Benutzer in seiner
Arbeit, sondern führt auch bei allen anderen Benutzern der Datenbank zu langen Wartezeiten.
Werden die Datensätze dabei selektiert, um diese zu modifizieren, so sind sie solange für alle
anderen Benutzer gesperrt, bis diese Transaktion beendet ist.
Die Obergrenzen müssen im Rahmen der Anwendungen definiert werden, die auf die Datenbank
zugreifen. Dabei müssen geeignete Kontrollen bzw. Sperren realisiert werden, die die Einhaltung
der Obergrenzen überwachen. Stellt eine Anwendung Suchfunktionalitäten bereit, so sollte die
uneingeschränkte Suche generell abgelehnt und die Eingabe von Suchkriterien gefordert werden.
Festlegung von Ressourcenbeschränkungen
Eine weitere Möglichkeit, die von einigen Herstellern angeboten wird, ist die Unterstützung von
Ressourcenbeschränkungen in Bezug auf die Benutzung einer Datenbank. So können
beispielsweise die Anzahl von Anmeldungen pro Benutzerkennung, der maximale Anspruch auf
CPU-Zeit pro Anmeldung, die Gesamtdauer einer Datenbankverbindung, die maximal zulässige
inaktive Zeit während einer Anmeldung und vieles mehr definiert werden.
Beispiele:
Mit folgendem Kommando wird in einer Oracle-Datenbank für die Datenbankkennung "Meier"
der temporäre Tablespace "Temp" auf 100 MB begrenzt:
ALTER USER Meier TEMPORARY TABLESPACE Temp QUOTA 100M ON Temp;
Mit dem nachfolgenden Befehl wird ein Profile "Tester" erstellt, das die Anzahl der Sessions, die
maximale CPU-Zeit pro Session, die maximale Zeit einer Datenbankverbindung und die
maximale Leerlaufzeit (IDLE) begrenzt. Dieses Profile kann dann einzelnen Benutzern
zugeordnet werden.
CREATE PROFILE Tester LIMIT
SESSIONS PER USER 2,
CPU_PER_SESSION 6000,
IDLE_TIME
30,
CONNECT_TIME
500;
Eine Ingres-Datenbank erlaubt beispielsweise für Benutzer und Gruppen das Setzen von Grenzen
für die maximale Ein- und Ausgabe je Abfrage oder für die Anzahl von Sätzen pro Abfrage.
Teil 1 - Kapitel 9.2 - Seite 86
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Weiterhin kann auch die Anzahl der Benutzer beschränkt werden, die gleichzeitig auf die
Datenbank zugreifen dürfen. Durch deren Begrenzung mittels Parametereinstellungen im DBMS
kann gewährleistet werden, daß die maximal zur Verfügung stehende Zahl an Lizenzen für die
Datenbank-Software nicht überschritten wird. Außerdem verursachen viele parallel zugreifende
Benutzer eine hohe Arbeitslast, dem der Datenbankserver eventuell nicht gewachsen ist, wodurch
sich die durchschnittliche Dauer einer Transaktion verlängert. Ist in diesem Fall aus bestimmten
Gründen eine Erweiterung der Ressourcen des Datenbanksystems nicht möglich oder nicht
gewünscht, schafft hier eine Begrenzung der maximal möglichen parallelen Benutzerzugriffe
ebenfalls Abhilfe.
Die diesbezüglichen Anforderungen sollten bereits während der Auswahl einer DatenbankStandardsoftware geklärt werden, um gegebenenfalls ein Konzept zur Umsetzung der
Ressourcenbeschränkungen zu erstellen (siehe M 2.124 Geeignete Auswahl einer DatenbankSoftware).
Ergänzende Kontrollfragen:
-
Wird die Einhaltung von Obergrenzen in den Anwendungen kontrolliert und umgesetzt?
-
Wird eine uneingeschränkte Suche in den Anwendungen prinzipiell unterbunden?
-
Wurden die Anforderungen an eine Ressourcenbeschränkung der Datenbank formuliert und
dokumentiert?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 87
Datenbanken
M 5.58
IT-Grundschutzhandbuch
Installation von ODBC-Treibern
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
ODBC (Open Database Connectivity) legt zwischen Datenbankanwendungen und dem jeweiligen
Datenbankprotokoll eine zusätzliche Schicht (und ist somit kein eigenes Datenbankprotokoll).
Durch die Installation des zur Datenbank passenden ODBC-Treibers wird zwischen Anwendung
und Datenbank eine einheitliche Schnittstelle geschaffen, über die die Kommunikation (Absetzen
von Datenbankanfragen, Lesen von Daten) zur Datenbank abgewickelt wird. Die zugehörige
ANSI-SQL-konforme SQL-Schnittstelle ermöglicht das Erstellen von Anwendungen, ohne auf die
jeweiligen Datenbankspezifika unterschiedlicher Produkte Rücksicht nehmen zu müssen. Bei
einem Wechsel der Datenbank-Software muß deshalb die Anwendung nicht angepaßt werden,
sondern es reicht aus, den ODBC-Treiber auszutauschen. Ursprünglich für Microsoft-Produkte
entwickelt, hat sich ODBC inzwischen als Standard etabliert. ODBC-Treiber sind für alle
gängigen Datenbanken unterschiedlichster Hersteller erhältlich.
Bei der Installation von ODBC-Treibern ist darauf zu achten, daß keine Sicherheitslücken
hinsichtlich der Zugangskontrolle zum Datenbanksystem entstehen.
Beispiel:
Für MS Access Datenbanken ist die Verwendung von Benutzerkennungen optional. Wird
allerdings die Zugangskontrolle aktiviert, so werden die Benutzerkennungen über eine separate
MS Access Datenbank, die sogenannte Systemdb verwaltet, die auch als eigene Datei
abgespeichert wird.
Bei der Installation eines ODBC-Treibers für eine MS Access Datenbank wird die Systemdb
nicht automatisch integriert. Die Default-Einstellungen während der Installation sind nämlich
dergestalt, daß eine eventuell existierende Systemdb unberücksichtigt bleibt. Wurde also während
der Installation des ODBC-Treibers die Systemdb nicht explizit angegeben, so führt dies dazu,
daß für Datenbankabfragen mittels ODBC keine Identifizierung seitens der Systemdb gefordert
wird. Somit wird die Zugangskontrolle unterlaufen.
Um dies zu verhindern, kann regelmäßig geprüft werden, ob die Systemdb integriert ist. Da dieser
Mechanismus jedoch jederzeit wieder rückgängig gemacht bzw. manipuliert werden kann, ist eine
Verschlüsselung einer MS Access Datenbank die sicherere Lösung. In diesem Fall schlägt ein
Zugriff ohne die Systemdb immer fehl. Dafür muß die in MS Access integrierte Verschlüsselung
aktiviert werden (unter Extras/Zugriffsrechte/Datenbank ver-/entschlüsseln). In diesem Fall
schlägt ein Zugriff über die ODBC-Schnittstelle fehl, da die Systemdb auch für den
Verschlüsselungsmechanismus benötigt wird.
Ergänzende Kontrollfragen:
-
Wurde ein ODBC-Treiber für die Datenbank installiert? Wenn ja, wurde auf die optionalen
Installationsparameter und ihre Auswirkungen geachtet?
Teil 1 - Kapitel 9.2 - Seite 88
Version 1998
IT-Grundschutzhandbuch
M 6.32
Datenbanken
Regelmäßige Datensicherung
Verantwortlich für Initiierung: IT-Sicherheitsmanagement, Leiter IT
Verantwortlich für Umsetzung: Administrator, IT-Benutzer
Zur Vermeidung von Datenverlusten müssen regelmäßige Datensicherungen durchgeführt
werden. In den meisten Rechnersystemen können diese weitgehend automatisiert erfolgen. Es sind
Regelungen zu treffen, welche Daten von wem wann gesichert werden. Empfehlenswert ist die
Erstellung eines Datensicherungskonzepts.
Abhängig von der Menge und Wichtigkeit der laufend neu gespeicherten Daten und vom möglichen Schaden bei Verlust dieser Daten ist folgendes festzulegen:
-
Zeitintervall
Beispiele: täglich, wöchentlich, monatlich,
-
Zeitpunkt
Beispiele: nachts, freitags abends,
-
Anzahl der aufzubewahrenden Generationen,
Beispiel: Bei täglicher Komplettsicherung werden die letzten sieben Sicherungen aufbewahrt, außerdem die Freitagabend-Sicherungen der letzten zwei Monate.
-
Umfang der zu sichernden Daten
Am einfachsten ist es, Partitionen bzw. Verzeichnisse festzulegen, die bei der regelmäßigen
Datensicherung berücksichtigt werden. Eine geeignete Differenzierung kann die
Übersichtlichkeit vergrößern sowie Aufwand und Kosten sparen helfen.
Beispiel: selbsterstellte Dateien und individuelle Konfigurationsdateien.
-
Speichermedien (abhängig von der Datenmenge)
Beispiele: Bänder, Kassetten, Disketten, Spiegelung auf 2. Platte,
-
Vorherige Löschung der Datenträger vor Wiederverwendung (Bänder, Kassetten)
-
Zuständigkeit für die Durchführung (Administrator, Benutzer)
-
Zuständigkeit für die Überwachung der Sicherung, insbesondere bei automatischer
Durchführung (Fehlermeldungen, verbleibender Platz auf den Speichermedien)
-
Dokumentation der erstellten Sicherungen (Datum, Art der Durchführung der Sicherung /
gewählte Parameter, Beschriftung der Datenträger)
Wegen des großen Aufwands können Komplettsicherungen in der Regel höchstens einmal täglich
durchgeführt werden. Die seit der letzten Sicherung erstellten Daten können nicht wiedereingespielt werden. Daher und zur Senkung der Kosten sollen zwischen den Komplettsicherungen
regelmäßig inkrementelle Sicherungen durchgeführt werden, das heißt, nur die seit der letzten
Komplettsicherung neu erstellten Daten werden gesichert. (Werden zwischen zwei
Komplettsicherungen mehrere inkrementelle Sicherungen durchgeführt, können auch jeweils nur
die seit der letzten inkrementellen Sicherung neu erstellten Daten gesichert werden.)
Eine inkrementelle Sicherung kann häufiger erfolgen, zum Beispiel sofort nach Erstellung
wichtiger Dateien oder mehrmals täglich. Die Vereinbarkeit mit dem laufenden Betrieb ist
sicherzustellen.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 89
Datenbanken
IT-Grundschutzhandbuch
Für eingesetzte Software ist in der Regel die Aufbewahrung der Originaldatenträger und deren
Sicherungskopien ausreichend. Sie braucht dann von der regelmäßigen Datensicherung nicht
erfaßt zu werden.
Alle Benutzer sollten über die Regelungen zur Datensicherung informiert sein, um ggf. auf
Unzulänglichkeiten (zum Beispiel zu geringes Zeitintervall für ihren Bedarf) hinweisen oder
individuelle Ergänzungen vornehmen zu können (zum Beispiel zwischenzeitliche Spiegelung
wichtiger Daten auf der eigenen Platte). Auch die Information der Benutzer darüber, wie lange
die Daten wiedereinspielbar sind, ist wichtig. Werden zum Beispiel bei wöchentlicher
Komplettsicherung nur zwei Generationen aufbewahrt, bleiben in Abhängigkeit vom Zeitpunkt
des Verlustes nur zwei bis drei Wochen Zeit, um die Wiedereinspielung vorzunehmen.
Falls bei vernetzten Rechnern nur die Server-Platten gesichert werden, ist sicherzustellen, daß die
zu sichernden Daten regelmäßig von den Benutzern oder automatisch dorthin überspielt werden.
Der Ausdruck von Daten auf Papier ist keine angemessene Art der Datensicherung.
Ergänzende Kontrollfragen:
-
Sind alle Daten eines Rechners gesichert?
-
Wird der Datensicherungsvorgang dokumentiert?
-
Ist der Datensicherungsvorgang konform zu einem vorhandenen Datensicherungskonzept?
Teil 1 - Kapitel 9.2 - Seite 90
Version 1998
IT-Grundschutzhandbuch
M 6.48
Datenbanken
Verhaltensregeln nach Verlust der Datenbankintegrität
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator, Datenbank-Benutzer
Falls sich das Datenbanksystem in nicht vorgesehener Weise verhält (zum Beispiel undefiniertes
Systemverhalten, nicht auffindbare Tabellen oder Datensätze, veränderte Tabelleninhalte,
unerklärlich langes Antwortzeitverhalten), kann ein Verlust der Datenbankintegrität vorliegen, der
unter Umständen auch durch mißbräuchliche Nutzung des Systems verursacht wurde (zum
Beispiel unautorisierte Administration, Veränderungen der Systemeinstellungen, Überschreiten
der maximal zulässigen Connects).
Dann sollten die Benutzer folgende Punkte beachten:
-
Ruhe bewahren!
-
Benachrichtigen Sie den Datenbankadministrator.
-
Greifen sie nicht mehr auf die Datenbank zu.
Der Datenbankadministrator sollte folgende Schritte durchführen:
-
Benachrichtigung aller betroffenen Benutzer,
-
Herunterfahren des Datenbanksystems,
-
Hochfahren des Datenbanksystems im Exklusiv-Modus (falls dies vom Datenbanksystem
unterstützt wird),
-
Sichern aller Dateien, die Aufschluß über die Art und Ursache des aufgetretenen Problems
geben könnten (z. B. ob tatsächlich ein Angriff erfolgt ist und auf welche Weise der
Angreifer eindringen konnte), d. h. insbesondere Sichern aller relevanten Protokolldateien,
-
Überprüfung und ggf. Zurücksetzen der Zugriffsrechte auf Systemtabellen,
-
Überprüfung der Datenbanksoftware auf sichtbare Veränderungen, z. B. Erstellungsdatum
und Größe der entsprechenden Dateien (Da diese von einem Angreifer auch wieder auf ihre
Ursprungswerte zurückgesetzt werden können, sollte die Integrität der Dateien mit
Prüfsummenverfahren überprüft werden.),
-
ggf. Löschen der Datenbanksoftware und Wiedereinspielen der Original-Dateien von
schreibgeschützten Datenträgern (vgl. M 6.21 Sicherungskopie der eingesetzten Software). Programme aus existierenden Datensicherungen sollten nicht wiedereingespielt
werden, die diese den Fehler schon enthalten können),
-
Überprüfung der Protokolldateien nach Auffälligkeiten (in Zusammenarbeit mit dem
Revisor),
-
Benachrichtigung der Benutzer mit der Bitte, ihre Bereiche auf Unregelmäßigkeiten zu
prüfen.
Falls Daten gelöscht oder unerwünscht geändert wurden, können diese aus den Datensicherungen
wiedereingespielt werden (siehe M 6.51 Wiederherstellung einer Datenbank).
Ergänzende Kontrollfragen:
-
Werden die Benutzer regelmäßig darüber informiert, daß bei Auftreten von Unregelmäßigkeiten sofort der Datenbankadministrator benachrichtigt werden muß?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 91
Datenbanken
IT-Grundschutzhandbuch
-
Wird diese Regelung auch angewendet?
-
Gibt es Datenbankadministratoren mit entsprechenden Kenntnissen?
Teil 1 - Kapitel 9.2 - Seite 92
Version 1998
IT-Grundschutzhandbuch
M 6.49
Datenbanken
Datensicherung einer Datenbank
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Die Sicherung der Daten eines Datenbanksystems kann in aller Regel nicht mit den Datensicherungsprogrammen auf Betriebssystemebene vollständig abgedeckt werden. Letztere bilden in
den meisten Fällen lediglich das Bindeglied, um die zu sichernden Daten auf ein Sicherungsmedium zu schreiben. Zur Sicherung des DBMS und der Daten müssen dagegen für die
meisten Datenbankprodukte zusätzlich die jeweiligen Dienstprogramme des DBMS eingesetzt
werden.
Die einfachste Möglichkeit einer Datenbanksicherung, die zugleich die sicherste darstellt, ist eine
Komplettsicherung der Datenbank in heruntergefahrenem Zustand. Dabei werden alle zur
Datenbank gehörenden Dateien auf dem Sicherungsmedium gesichert. Meist ist dieses Vorgehen
allerdings aus Gründen der Verfügbarkeitsanforderungen an die Datenbank oder aufgrund des zu
sichernden Datenvolumens nicht durchführbar.
Eine Alternative zur oben beschriebenen Komplettsicherung ist eine Online-Sicherung der
Datenbank. Die Sicherung erfolgt dann während des laufenden Betriebs, d. h. die Datenbank muß
nicht heruntergefahren werden. Die Nachteile dieser Sicherungsart sind, daß Inkonsistenzen nicht
explizit ausgeschlossen werden können, und daß auch in diesem Fall bei einer Zerstörung der
Datenbank eine (Offline-) Komplettsicherung existieren muß, auf der aufbauend die OnlineSicherungen zurückgespielt werden können. Online-Sicherungen sollten aus diesem Grund nur
dann durchgeführt werden, wenn eine permanente Verfügbarkeit der Datenbank gefordert ist. Auf
eine Offline-Komplettsicherung, die in vertretbar großen Zeitabständen durchgeführt werden
kann, sollte trotzdem nicht verzichtet werden.
Partielle Datenbanksicherungen stellen eine weitere Möglichkeit dar. Sie sollten immer dann
verwendet werden, wenn das zu sichernde Datenvolumen zu groß ist, um eine vollständige
Sicherung durchführen zu können. Dies kann daraus resultieren, daß die Kapazitäten der Sicherungsmedien nicht ausreichen oder daß der zur Verfügung stehende Zeitrahmen je Sicherung nicht
genügt, um eine vollständige Sicherung durchführen zu können.
Falls möglich, so sollten in jedem Fall alle Transaktionen zwischen zwei Offline-Komplettsicherungen archiviert werden. Oracle bietet dazu beispielsweise die Möglichkeit an, indem der
sogenannte ARCHIVE-Mode für die Datenbank aktiviert wird. Transaktionen werden bei Oracle
in sogenannten Log-Dateien protokolliert, von denen es mehrere gibt. Diese werden nacheinander
beschrieben und sobald alle Log-Dateien voll sind, so wird wieder die erste Log-Datei
überschrieben. Der ARCHIVE-Mode erstellt von diesen Log-Dateien eine Sicherungskopie, bevor
sie wieder überschrieben werden. Auf diese Art und Weise können bei einer Zerstörung der
Datenbank alle Transaktionen komplett rekonstruiert werden. Auch hierfür ist allerdings die
Existenz einer Komplettsicherung der Datenbank die Voraussetzung. Die Dauer eines solchen
Recovery wächst mit der Anzahl der zurückzuspielenden Archiv-Log-Dateien an.
Für die Datensicherung eines Datenbanksystems muß ein eigenes Datensicherungskonzept erstellt
werden. Einflußfaktoren für ein solches Konzept sind:
-
Verfügbarkeitsanforderungen an die Datenbank
Wenn beispielsweise eine Datenbank werktags rund um die Uhr zur Verfügung stehen
muß, so kann eine Komplettsicherung nur am Wochenende durchgeführt werden, da dies
im allgemeinen ein Herunterfahren der Datenbank erfordert.
Version 1998
Teil 1 - Kapitel 9.2 - Seite 93
Datenbanken
-
IT-Grundschutzhandbuch
Datenvolumen
Das gesamte zu sichernde Datenvolumen muß mit den zur Verfügung stehenden Sicherungskapazitäten verglichen werden. Dabei muß festgestellt werden, ob die Sicherungskapazitäten (z. B. ein DAT-Tape pro Sicherungslauf) für das entsprechende Datenvolumen
der Datenbank ausreichend dimensioniert sind.
Falls dies nicht der Fall ist, muß ein Konzept zur Teilsicherung des Datenvolumens erstellt
werden. Dies kann z. B. bedeuten, daß die Daten einzelner Anwendungen oder einzelner
Bereiche der Datenbank immer im Wechsel gesichert werden bzw. nur die aktuellen
Änderungen. Die Möglichkeiten einer Teilsicherung hängen von der verwendeten
Datenbank-Software ab.
-
Maximal verkraftbarer Datenverlust
Hier muß festgelegt werden, ob bei einer Zerstörung der Datenbank der Datenverlust eines
Tages verkraftbar ist, oder ob die Datenbank bis zur letzten Transaktion wiederherstellbar
sein muß. Dies ist im allgemeinen bei einer hohen Anforderung an die Verfügbarkeit bzw.
Integrität der Daten der Fall.
-
Wiederanlaufzeit
Auch die maximal zulässige Zeitdauer des Wiederherstellens der Datenbank nach einem
Absturz muß festgelegt werden, um den Verfügbarkeitsanforderungen zu genügen.
-
Datensicherungsmöglichkeiten der Datenbank-Software
Im allgemeinen werden von einer Datenbank-Standardsoftware nicht alle denkbaren
Datensicherungsmöglichkeiten unterstützt, wie z. B. eine partielle Datenbanksicherung. Im
konkreten Fall gilt es also zu prüfen, ob das erstellte Datensicherungskonzept mit den zur
Verfügung stehenden Mechanismen auch umgesetzt werden kann.
Anhand dieser Informationen kann ein Konzept für die Datensicherung der Datenbank erstellt
werden. In diesem Sicherungskonzept wird u. a. festgelegt (siehe hierzu auch Kapitel 3.4
Datensicherungskonzept)
-
wer für die ordnungsgemäße Durchführung von Datensicherungen zuständig ist,
-
in welchen Zeitabständen eine Datenbanksicherung durchgeführt wird,
-
in welcher Art und Weise die Datenbanksicherung zu erfolgen hat,
-
zu welchem Zeitpunkt die Datenbanksicherung durchgeführt wird,
-
die Spezifikation des zu sichernden Datenvolumens je Sicherung.
-
wie die Erstellung von Datensicherungen zu dokumentieren ist, und
-
wo die Datensicherungsmedien aufbewahrt werden.
Beispiel:
Sicherung von Montag bis Samstag:
-
Startzeit: morgens um 3.00h
Es erfolgt eine vollständige Sicherung der Daten, wobei die Datenbank nicht heruntergefahren, sondern die Möglichkeit der Online-Sicherung des DBMS genutzt wird.
Sicherung am Sonntag
Teil 1 - Kapitel 9.2 - Seite 94
Version 1998
IT-Grundschutzhandbuch
-
Datenbanken
Startzeit: morgens um 3.00h
Die Datenbank wird heruntergefahren und es erfolgt eine Komplettsicherung der
Datenbank.
Ergänzende Kontrollfragen:
-
Existiert eine Dokumentation, wie im Falle eines Absturzes der Datenbank diese wiederherzustellen ist?
-
Ist für die Institution ein aktuelles Datensicherungskonzept für den Bereich Datenbanken
dokumentiert?
-
Wie werden Mitarbeiter über den sie betreffenden Teil des Konzepts unterrichtet?
-
Wird die Einhaltung dieses Konzepts kontrolliert?
-
Wie werden Änderungen der Einflußfaktoren berücksichtigt?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 95
Datenbanken
M 6.50
IT-Grundschutzhandbuch
Archivierung von Datenbeständen
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Ist eine Archivierung von Daten eines Datenbanksystems erforderlich, so muß dazu ein entsprechendes Konzept erstellt werden, um die Datenbestände zu einem späteren Zeitpunkt wieder
zur Verfügung stellen zu können. Hierbei sind folgende Punkte zu berücksichtigen:
Archivierung
-
Die zur Verfügung stehenden Archivierungsmöglichkeiten müssen identifiziert werden.
-
Es muß dokumentiert werden, welches Datenmodell den zu archivierenden Daten zugrunde
liegt.
-
Der Zeitpunkt der Archivierung ist zu dokumentieren.
-
Aufbau, Systematik und Ordnungskriterien des Archivs müssen spezifiziert werden.
-
Für alle Archivierungsmedien ist anhand von Herstellerangaben und Erfahrungswerten eine
maximale Lebensdauer zu bestimmen. Entsprechend dessen müssen Zeitpunkte für die
Auffrischung des archivierten Datenbestandes festgelegt werden.
-
Die geforderte Verfügbarkeit der archivierten Datenbestände ist zu überprüfen und gegebenenfalls an die konkreten Anforderungen anzupassen. Es kann beispielsweise gefordert
sein, archivierte Datenbestände der letzten sechs Monate kurzfristig zur Verfügung zu
stellen, während Datenbestände älteren Datums nur auf Anfrage und mit längeren Vorlaufzeiten wiedereingespielt werden müssen. Dieses Kriterium hat u. a. Auswirkungen auf
die Wahl des Archivierungsmediums sowie auf die Art und Weise der Archivierung. Bei
hohen Verfügbarkeitsanforderungen muß evtl. ein redundantes Archiv geführt werden.
-
Es muß sichergestellt sein, daß vorgegebene Aufbewahrungsfristen eingehalten werden.
Wiedereinspielen
-
Der aktuelle Datenbestand darf von dem archivierten Datenbestand nicht beeinflußt werden.
-
Für die Wiedereinspielung von archivierten Datenbeständen muß genügend Speicherplatz
zur Verfügung gestellt werden.
-
Der archivierte Datenbestand muß wiederherstellbar sein, auch wenn sich zwischenzeitlich
das Datenmodell geändert hat. In diesem Fall muß das Datenmodell zum
Archivierungszeitpunkt bekannt sein, um den alten Stand wiederherstellen zu können.
-
Wenn die wiedereingespielten Daten von einer Anwendung verarbeitet werden sollen, muß
auch von dieser Anwendung eine Version vorhanden sein, die das "alte" Datenmodell
unterstützt.
-
Es muß sporadisch überprüft werden, ob sich der archivierte Datenbestand wiedereinspielen läßt.
Bei der Archivierung von Datenbeständen, die personenbezogene Daten enthalten, muß darüber
hinaus berücksichtigt werden, daß die Betroffenen ein Recht auf Berichtigung, Sperrung bzw.
Löschung der über sie gespeicherten Daten haben. Um dies zu gewährleisten, sind entsprechende
technisch-organisatorische Verfahren zu entwickeln. Insbesondere müssen auch nach dem
Teil 1 - Kapitel 9.2 - Seite 96
Version 1998
IT-Grundschutzhandbuch
Datenbanken
Wiedereinspielen alter Datenbestände vorher durchgeführte Berichtigungen, Sperrungen bzw.
Löschungen erhalten bleiben.
Ergänzende Kontrollfragen:
-
Existiert eine Dokumentation, wie beim Wiedereinspielen von archivierten Datenbeständen
zu verfahren ist?
-
Ist für die Institution ein aktuelles Archivierungskonzept dokumentiert?
-
Wie werden Änderungen der Einflußfaktoren berücksichtigt?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 97
Datenbanken
M 6.51
IT-Grundschutzhandbuch
Wiederherstellung einer Datenbank
Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator
Es ist ein Konzept zu erstellen, wie das Wiedereinspielen von Datenbanksicherungen
durchzuführen ist. Dem Konzept zugrunde gelegt werden müssen
-
das Datensicherungskonzept (siehe M 6.49 Datensicherung einer Datenbank) und
-
die möglichen Fehlersituationen, die ein Wiedereinspielen von Datenbanksicherungen
erforderlich machen können.
Anhand dieser beiden Punkte ist abzuleiten, welche Datenbanksicherungen in welcher Form
wiedereingespielt werden müssen.
Die Wiederherstellung einer Datenbank ist eine komplexe Aufgabe, die ein äußerst sorgfältiges
Vorgehen und viel Übung erfordert. Trotzdem sollte immer damit gerechnet werden, daß eine
Wiederherstellung nicht reibungslos und fehlerfrei funktionieren wird. Daher sollte die zerstörte
Datenbank nicht durch ein einfaches Zurückspielen der Datenbanksicherung überschrieben
werden.
Häufig läßt sich die für korrupt gehaltene Datenbank wieder bereinigen. Um jedoch die
Wiederanlaufzeit zu minimieren, sollte parallel zur Fehlersuche mit der Wiederherstellung der
Datenbank in einem getrennten Speicherbereich begonnen werden. Auch wenn sich die
beschädigte Datenbank nicht mehr reparieren läßt, sollte sie dennoch erhalten bleiben, um sie
analysieren und die Fehlerursache feststellen zu können.
Bei der Wiederherstellung sollte die Datenbanksicherung daher zuerst auf getrennten
Speichermedien eingespielt werden. Dabei ist zu beachten, daß hierfür das gleiche Volumen an
Speicherkapazität benötigt wird wie für die defekte Datenbank.
Diese Speicherkapazitäten müssen für den Notfall vorgehalten werden, um einem Verlust der
Datenbankintegrität vorzubeugen und die Verfügbarkeitsanforderungen zu erfüllen. Ist dies nicht
möglich, so ist festzulegen, auf welche Weise kurzfristig die erforderlichen Speicherkapazitäten
zur Verfügung gestellt werden können. Selbstverständlich darf dies nicht zu einem zusätzlichen
Datenverlust führen, wenn beispielsweise Festplattenbereiche mit anderen Daten gelöscht werden
sollen, um die erforderlichen Ressourcen für das Wiedereinspielen der Datenbanksicherung zur
Verfügung zu stellen. Müssen aufgrund mangelnder Speicherkapazitäten andere Daten gelöscht
werden, so sind diese sorgfältig zu sichern, damit gewährleistet werden kann, daß die Daten nach
Abschluß der Restaurierungsmaßnahme wieder ordnungsgemäß zur Verfügung stehen.
Für den Fall, daß keine vollständige Restaurierung der Datenbank notwendig ist, sondern
lediglich einzelne Datenbestände wiederherzustellen sind, so ist ein Wiedereinspielen der Daten
immer getrennt von den Originaldatenbeständen durchzuführen. Auch hier sind dann
entsprechende Speicherkapazitäten erforderlich. Es ist an dieser Stelle sinnvoller, hierfür parallel
eine eigene Datenbank einzurichten, damit die Datenbestände der Originaldatenbank auf jeden
Fall unbeeinfußt bleiben. Dies gilt selbst dann, wenn die Möglichkeit besteht, die Daten in der
Originaldatenbank gesondert einzuspielen.
Ergänzende Kontrollfragen:
-
Wurde ein Konzept zum Wiedereinspielen von Datenbanksicherungen erstellt?
-
Wann wurde das Wiedereinspielen von Datenbanksicherungen das letzte Mal geübt?
Teil 1 - Kapitel 9.2 - Seite 98
Version 1998
IT-Grundschutzhandbuch
-
Datenbanken
Werden für den Notfall genügend Speichermedien bereitgehalten?
Version 1998
Teil 1 - Kapitel 9.2 - Seite 99
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement