Bundesamt für Sicherheit in der Informationstechnik

M 2.134 Richtlinien für Datenbank-Anfragen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Entwickler

Die relationale Datenbanksprache SQL (Structured Query Language) ist eine international standardisierte Sprache für relationale Datenbanksysteme ( DBS ), die eine weite Verbreitung erfahren hat und in den meisten Datenbankmanagementsystemen ( DBMS ) implementiert ist. Der Sprachumfang wird in zyklisch überarbeiteten Normen ( ANSI SQL-92, ANSI SQL-99, ANSI SQL-2003) festgelegt. Mittels SQL können sowohl Modifikationen der Daten (UPDATE, INSERT, DELETE), als auch der Datenbankobjekte (CREATE, ALTER, DROP) formuliert, sowie Informationen abgefragt werden (SELECT).

Es müssen Richtlinien für eine effiziente, wartbare und nachvollziehbare Programmierung von Datenbankabfragen erstellt und im Rahmen der Programmierung umgesetzt werden. Folgende Grundsätze sollten in dieser Richtlinie beschrieben sein:

  • Anfragen an die Datenbank sollten möglichst nicht direkt auf Tabellen, sondern über Views und Prozeduren ausgeführt werden. Einerseits kann dadurch der Schutz der Daten besser gewährleistet werden (siehe M 2.129 Zugriffskontrolle einer Datenbank ). Andererseits kann sichergestellt werden, dass den Benutzern die notwendigen Informationen in entsprechender Formatierung und Menge zur Verfügung gestellt werden. Zusätzlich können diese Views und Prozeduren in eine eigene DB ausgelagert werden und Benutzer sowie Anwendungen können nur auf diese ausgelagerte DB Zugriff erhalten. Die Daten in den Tabellen sind dann außer über die Prozeduren und Views der ausgelagerten DB nur einem speziellen Benutzerkreis zugänglich (Administratoren, etc.).
  • SQL-Anfragen sollten exakt und explizit in Anlehnung an das DB-Modell formuliert werden. Dabei sollten alle erfragten Felder explizit angegeben und der "*"-Operator vermieden werden. Damit ist sichergestellt, dass die Daten in der erwarteten Reihenfolge zur Verfügung gestellt und nur diejenigen Daten selektiert werden, die tatsächlich benötigt werden.
    Beispiel:
    Ein DB-Modell enthält eine Tabelle mit den Feldern "Artikelnummer", "Artikelbezeichnung", "Verwendungszweck" und "Nettopreis". Im Zuge einer Erweiterung der Applikation wird hinter dem "Verwendungszweck" ein weiteres Feld mit dem Namen "Bestellnummer" eingefügt. Aus Gründen der optimalen Speicherausnutzung fügt das DBMS das neue Feld jedoch nicht dort, sondern an die zweite Stelle hinter "Artikelnummer" ein. Weil die Daten mit Hilfe einer SELECT-*-Anweisung abgefragt werden, liefert die Datenbank die Informationen in einer anderen Reihenfolge zurück, als die Applikation sie erwartet. Dies führt bei der Applikation zu Problemen, deren Ursache zunächst nicht erkennbar ist.
  • Bei einschränkenden Datenbankanfragen (WHERE-Klausel) ist die Reihenfolge der angegebenen Selektionsbedingungen von großer Bedeutung für die Ausführungsgeschwindigkeit. Die WHERE-Klausel sollte so formuliert werden, dass zuerst die Bedingung angegeben wird, die in kürzester Zeit die kleinstmögliche Ergebnismenge selektiert. Dabei sollte zuerst auf indizierte Felder zugegriffen werden, dann erst auf nicht-indizierte Felder, wobei hier Prüfungen auf Ziffern schneller sind als Prüfungen auf Texte. Das gleiche gilt analog für Datenbankanfragen, die über mehrere Tabellen hinweg formuliert werden (so genannte Joins).
    Viele DBMS optimieren bereits Datenbankanfragen selbständig. Oft werden zusätzlich sogar mehrere Optimierungsstrategien zur Auswahl angeboten, die über verschiedene Parameter ausgewählt werden können.
    Einige DBMS bieten die Möglichkeit, die Abarbeitung von Datenbankanfragen zu untersuchen (z. B. in Oracle mit EXPLAIN oder für Ingres mittels SETOEP). Des weiteren besteht die Möglichkeit, über so genannte HINTS in der Datenbankanfrage deren Abarbeitung explizit zu definieren und somit den Optimizer im Prinzip auszuschalten. Von dieser Möglichkeit sollte allerdings vorsichtig Gebrauch gemacht werden.
  • Welche Optimizer das DBMS unterstützt sowie deren Vor- und Nachteile sind in den Handbüchern des DBMS normalerweise dokumentiert. Der Einsatz alternativer Optimizer innerhalb eines DBMS sollte mit dem Administrator abgesprochen werden.
  • Im Falle von Joins sollte zusätzlich beachtet werden, dass die Zuordnung von Feldern zu den Tabellen eindeutig erfolgt.
  • Beispiel:



    Das Feld "ID" ist in beiden Tabellen vorhanden und muss 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 den jeweiligen Tabellen zuzuordnen. Eine explizite Angabe des zugehörigen Tabellennamens für jedes Feld wird von SQL nicht gefordert. Trotzdem sollte 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. 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 SQL-Anweisung würde mit einer Fehlermeldung abgebrochen.
  • 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 unter Umständen zu ungewollten Inkonsistenzen in der Datenbank kommen kann.
    Beispiel:
    Mehrere einzelne Modifikationen gehören logisch zusammen, werden aber nach der Ausführung jeder einzelnen Modifikation 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 dass die Anwendung so früh wie möglich auf eingetretene Fehler reagieren kann.
  • Berechtigungen auf systemspezifische Kommandos, mit denen beispielsweise die Protokollierung ausgeschaltet oder das Locking-Verfahren verändert werden kann, sollten Benutzern entzogen und auf Administratoren beschränkt werden.
  • Bei der Entwicklung von Anwendungen sollten alle Datenbankzugriffe in einem Modul oder einem bestimmten Teil des Programmcodes zusammengefasst werden, da sonst zur Überprüfung der obigen Grundsätze der gesamte Programmcode des Anwendungssystems herangezogen werden müsste. Hierdurch wird die Wartung und Pflege des Anwendungssystems, z. B. bei Änderungen des Datenmodells, erleichtert.

Prüffragen:

  • Gibt es Richtlinien für die Programmierung von Datenbankabfragen?

  • Sind Anfragen an die Datenbank gemäß Richtlinien über Views und Prozeduren statt direkt auf Tabellen auszuführen?

  • Fordern die Richtlinien für Datenbank-Anfragen, sofern Views und Prozeduren in eine eigene Datenbank ausgelagert werden, einen eingeschränkten Benutzerkreis für den Zugriff auf die Daten in deren Tabellen?

  • Umfassen die Richtlinien für Datenbank-Anfragen, dass SQL -Anfragen exakt und explizit in Anlehnung an das Datenbank-Modell unter Vermeidung des "*"-Operators zu formulieren sind?

  • Enthalten die Richtlinien für Datenbank-Anfragen, sofern deren Ausführungsgeschwindigkeit von Bedeutung ist, Anforderungen zur geeigneten Optimierung von Datenbankanfragen?

  • Fordern die Richtlinien für Datenbank-Anfragen im Falle von Joins bei der Datenbankanfrage immer eine eindeutige explizite Zuordnung von Feldern zu Tabellen?

  • Umfassen die Richtlinien für Datenbank-Anfragen, dass alle Datenbanktransaktionen explizit mit einem COMMIT zu bestätigen sind?

  • Ist in den Richtlinien für Datenbank-Anfragen eine Sperrstrategie zur Vermeidung von Sperrkonflikten festgelegt?

  • Existiert die Richtlinie, Berechtigungen für systemspezifische Kommandos auf der Datenbank nur an Administratoren zu vergeben?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK