Firebird Datei- und Metadatensicherheit

Wenn Sie über diese Seite gestolpert sind und nichts über Firebird wissen, nutzen Sie bitte diesen Link: www.firebirdsql.org

Dieser Artikel beschreibt die Sicherheit von Firebird-Datenbankdateien und insbesondere den Zugriff auf die in diesen Dateien gespeicherten Metadaten. Er wurde als Antwort auf häufige Fragen in den Firebird-Listen zu diesen Themen geschrieben. Der Artikel vermeidet technische Besonderheiten. Informationen zum Sichern von Dateien in Ihrem jeweiligen Betriebssystem finden Sie in der entsprechenden Dokumentation zu diesem Betriebssystem. Informationen zum Anwenden der Benutzer- und Objektsicherheit in Firebird-Datenbanken finden Sie in der Dokumentation auf der Firebird-Website (siehe oben) oder dem käuflich erwerbbaren The Firebird Book von Helen Borrie.

Damit eine Anwendung (ein Benutzer) auf eine Firebird-Datenbank zugreifen kann, muss sie eine Verbindung zum Firebird-Serverprozess herstellen. Beim Empfang einer Verbindungsanforderung authentifiziert der Serverprozess die Benutzeranmeldeinformationen gegenüber den in der Sicherheitsdatenbank definierten Serverbenutzern. Wenn die Authentifizierung erfolgreich ist, gewährt der Server der Anwendung Zugriff auf jede angeforderte Datenbank und verwendet dann die in dieser Datenbank definierten Rollen und Berechtigungen, um eine differenzierte Zugriffssteuerung für Objekte in dieser Datenbank bereitzustellen.

Der Benutzer, der eine Verbindung zur Datenbank herstellt, benötigt zu keinem Zeitpunkt direkten Zugriff auf die Datenbankdatei selbst. Der gesamte Zugriff erfolgt über den Serverprozess, der bei Bedarf auf die Datenbankdatei zugreift, um Anforderungen zu erfüllen. Es ist der Server, der den Zugriff auf den angemeldeten Benutzer gemäß den für diesen Benutzer in dieser Datenbank definierten Berechtigungen einschränkt oder zulässt.

Jede Firebird-Serverinstallation hat einen “SYSDBA” -Benutzer. Dieser Benutzer hat uneingeschränkten Zugriff auf alle für diesen Server verfügbaren Datenbanken. Datenbankspezifische Berechtigungen werden beim Zugriff auf die Datenbank mit SYSDBA effektiv ignoriert. Wenn Sie eine Datenbank zum ersten Mal auf einen Server kopieren, können Sie mit SYSDBA die Berechtigungen an die Benutzer und Anforderungen des Servers anpassen. Dies bedeutet jedoch auch, dass ich, wenn ich direkten Zugriff auf eine Datenbankdatei habe, diese Datei von einem Server kopieren kann, auf dem ich das SYSDBA-Kennwort möglicherweise nicht kenne, auf einen anderen Server, auf dem ich das SYSDBA-Kennwort kenne, und somit uneingeschränkten Zugriff auf sie erhalte die Datenbank.

Wie Sie dieser Beschreibung entnehmen können, basiert die Firebird-Sicherheit auf der Annahme, dass der Firebird-Serverprozess in einer ausreichend sicheren Umgebung ausgeführt wird. Firebird selbst trifft keine Vorkehrungen, um externe Sicherheit zu gewährleisten. Sobald eine Person physischen Zugriff auf eine Datenbankdatei hat, gibt es keine effektive Möglichkeit, diesen Benutzer daran zu hindern, alle Daten (und Metadaten) in dieser Datei zu lesen.

Dies bedeutet, dass Installationen aus Gründen einer angemessenen Sicherheit sicherstellen sollten, dass die Datenbankdateien angemessen gesichert sind. In den meisten Fällen bedeutet dies, dass der Firebird-Serverprozess als sein eigener spezifischer Betriebssystembenutzer ausgeführt werden sollte und nur dieser Benutzer (und wahrscheinlich der Administrator / Root-Benutzer) direkten Betriebssystemzugriff auf die Datenbankdateien haben sollte. Die Datenbankdateien sollten sich nicht in Verzeichnissen befinden, auf die über das Netzwerk oder andere lokale Benutzer als speziell autorisiertes Personal zugegriffen werden kann.

Damit die Sicherheit effektiv ist, wird es auch bevorzugt, dass der Servercomputer an einem sicheren Ort gespeichert wird, um physische Manipulationen zu verhindern, die es nicht autorisierten Benutzern ermöglichen könnten, über die Einschränkungen des Betriebssystems hinaus auf die Festplatte zuzugreifen.

Die obige Erklärung hilft Entwicklern jedoch nicht unbedingt, die Datenbanken für die Verteilung und Installation an Remote-Standorten geschrieben haben und möglicherweise das in ihren Datenbanken enthaltene geistige Eigentum schützen möchten. Solche Bedenken können speziell die Metadaten (Tabellenstrukturen und -beziehungen, gespeicherte Prozeduren und Trigger) umfassen, können aber auch spezifische Daten enthalten, die in einigen Tabellen enthalten sind. Diese Bedenken stellen den Hauptzweck dieses Artikels dar.

Ein Entwickler erstellt eine Datenbank (und normalerweise eine zugehörige Clientanwendung) für die Installation auf Servern an Remotestandorten. An solchen Standorten hat eine Person an diesem Standort normalerweise vollen Zugriff auf den Computer, auf dem der Firebird-Server ausgeführt wird, um Sicherungen und andere Wartungsaufgaben ausführen zu können. Wie in den Hintergrundinformationen beschrieben, bietet der direkte Zugriff auf die Datenbankdatei die Möglichkeit, vollständigen und uneingeschränkten Zugriff auf alle Informationen in der Datenbank zu erhalten - sowohl auf Daten als auch auf Metadaten.

In solchen Fällen vertraut der Entwickler den Benutzern an diesen Remotestandorten möglicherweise nicht, um das in der Datenbank dargestellte geistige Eigentum vertraulich zu behandeln. Es besteht die Befürchtung, dass die Benutzer die Datenbank für ihre eigenen Zwecke zurückentwickeln oder dass diese Remotestandorte nicht die Sicherheit gewährleisten, die erforderlich ist, um den unbefugten Zugriff auf die Datenbank zu verhindern.

Dies führt zu den allgemeinen Fragen in den Firebird-Listen wie folgt:

Firebird (zumindest bis Version 1.5) bietet keine integrierten Verschlüsselungsfunktionen. Die einfache Antwort auf diese beiden Fragen lautet, dass dies mit den aktuellen Funktionen von Firebird nicht möglich ist. Ein Benutzer, der direkten Zugriff auf die Datei erhalten kann, erhält Zugriff auf alle Details in dieser Datei.

In erster Linie ist keine Problemumgehung möglich, da der Server selbst die Metadaten lesen muss. In der zweiten Instanz ist es durchaus möglich, clientseitige Verschlüsselungs- / Entschlüsselungsfunktionen zu implementieren, aber dann verlieren Sie die Fähigkeit, Datenbankindizes und Suchfunktionen effektiv zu nutzen - und die Schlüsselverwaltung bleibt ein Hauptproblem (siehe unten).

Es gibt wirklich nur eine mögliche Lösung für diese Anforderungen: Hosten Sie die Datenbank und den Server an Ihrem eigenen Standort und lassen Sie die Clients über DFÜ- oder Interneteinrichtungen usw. eine Remoteverbindung zu Ihrem Server herstellen. Terminalserverfunktionen (Windows oder Linux / Unix) könnten eine nützliche Möglichkeit sein, solche Anforderungen zu implementieren.

Auf diese Weise behalten Sie die Kontrolle über die Datenbankdatei und können den Zugriff auf die verschiedenen Funktionen und Strukturen Ihrer Datenbank mithilfe der üblichen internen Firebird-Sicherheitsfunktionen (Rollen und Berechtigungen usw.) einschränken.

Es gibt eine spezielle Version des Firebird-Servers, die als “eingebettet” (engl. embedded) bezeichnet wird. Dies ist eine spezielle Clientbibliothek, die den Server selbst enthält. Wenn eine Anwendung eine Verknüpfung zu dieser Bibliothek herstellt, wird der Server geladen und der direkte Zugriff auf alle Datenbanken ermöglicht, auf die auf dem lokalen Computer zugegriffen werden kann. Diese Version des Servers verwendet keine Sicherheitsdatenbank. Der während der “Anmeldung” angegebene Benutzername (es erfolgt keine Kennwortauthentifizierung) wird zum Verwalten des Benutzerzugriffs auf Datenbankobjekte (über SQL-Berechtigungen) verwendet. Wenn dieser Benutzername jedoch SYSDBA (oder der Eigentümer der Datenbank) lautet, ist der uneingeschränkte Zugriff möglich möglich.

Die Verwendung des Embedded-Modus ist nützlich für Entwickler, die einfach zu verteilende Einzelbenutzeranwendungen erstellen möchten, die keine Sicherheit benötigen.

Aus dieser kurzen Beschreibung geht hervor, dass die Installation eines eingebetteten Server-Clients auf einem Server, auf dem andere Datenbanken gehostet werden, ein großes Sicherheitsrisiko darstellen kann. In Wirklichkeit ist das Risiko nicht größer als wenn der eingebettete Client nicht existiert hätte.

Wenn eine Anwendung den eingebetteten Server lädt, arbeitet der Server im Sicherheitskontext der Anwendung (und damit des Benutzers). Dies bedeutet, dass der eingebettete Server nur auf Datenbankdateien zugreifen kann, auf die der Benutzer direkt über das Betriebssystem zugreifen kann. Es ist in jedem Fall eine schlechte Nachricht, einem nicht vertrauenswürdigen Benutzer Zugriff auf die Installation von Programmen auf einem sicheren Server zu gewähren. Vorausgesetzt, Sie haben die entsprechenden Dateiberechtigungen für sichere Datenbanken angegeben, ist der eingebettete Server selbst keine Bedrohung.

Die Bedrohung kommt von all den anderen Dingen, die der Benutzer installieren könnte.

Die Tatsache, dass der eingebettete Server vorhanden ist, dient nur dazu, hervorzuheben, was beim direkten Zugriff auf eine Datenbankdatei möglich ist, insbesondere in einer Open Source-Umgebung. Wenn es nicht schon existiert hätte, wäre es sicherlich möglich, dass jemand eine gleichwertige Fähigkeit kompiliert.

Verschiedene andere Formen der Sicherheit durch Verschleierung wurden vorgeschlagen. Solche Dinge wie spezielle Ereignisse, die beim An- und Abmelden ausgelöst werden, um Benutzerfunktionen aufzurufen, um den Zugriff zu verhindern oder zu verweigern. Solche Funktionen bieten möglicherweise eine begrenzte Verwendung für Closed-Source-Systeme, bei denen die Unklarheit der Implementierung dazu beiträgt, genau zu verbergen, wie Informationen geschützt werden. Bei einem Open-Source-System besteht die Problemumgehung für solche Hacks darin, einfach eine eigene Version des Servers zu erstellen, die das Ereignis oder den Code umgeht, der den Zugriff verhindert. In einem Open-Source-System ist es schwierig, Dunkelheit zu bieten.

Überlegen Sie auch, was passiert, wenn Sie Ihre kompilierten ausführbaren Dateien verteilen. Kompilierte Programme sind gute Beispiele für Dunkelheit. Es wird (normalerweise) keine Verschlüsselung verwendet, alle Schritte des Codes können von jedem mit Zeit und Wissen analysiert werden, und tatsächlich stehen Dekompilierer zur Verfügung, die diesen Prozess unterstützen. Sobald eine Person herausfindet, mit welchen Bibliotheken Ihr Code kompiliert wurde, beschleunigt das Isolieren der Ergebnisse auf nur Ihren eigenen “geheimen” Code den gesamten Prozess erheblich. Haben Sie an Borland, Microsoft oder an jemanden geschrieben, der verlangt, dass er seine kompilierten Binärdateien irgendwie verschlüsselt?

Meine bisherigen Kommentare waren auf die Idee einer starken Sicherheit gerichtet, und ich denke, das Konzept der Sicherheit durch Verschleierung wurde mit einiger Verachtung geschrieben. Manchmal ist jedoch nur schwache Sicherheit alles, was Sie wollen. Manchmal sind die Daten einfach nicht so wertvoll. Sie möchten den gelegentlichen Browser stoppen und ihn für den fortgeschritteneren Dieb zumindest unpraktisch machen.

Ich habe solche Schemata selbst an verschiedenen Orten angewendet. Oft macht es keinen Sinn, Twofish, AES oder was auch immer auf solche Schemata zu werfen, weil es um starke Verschlüsselung geht. Sie sind mit einem hohen Verarbeitungsaufwand und Komplikationen im Zusammenhang mit der Aufrechterhaltung der Sicherheit verbunden. Ein einfaches XOR gegen eine bekannte Zeichenfolge (den Schlüssel) kann ausreichend sein. Wenn der Schlüssel vom Dieb entdeckt werden kann, spielt es keine Rolle, ob Sie eine schwache oder eine starke Verschlüsselung verwendet haben. Das Spiel ist trotzdem vorbei.

Die Sache mit Sicherheit durch Verschleierung ist, dass sie unklar sein muss! Wenn Firebird eine Art Verschlüsselung in seine Lese- und Schreibvorgänge auf der Festplatte implementieren würde, wäre dies nicht unklar, da es sich um ein Open-Source-Projekt handelt. Es würde fast keine Zeit dauern, die Quelle neu zu kompilieren, um den bereitgestellten Schlüssel zu ermitteln, und alles geht verloren.

Wenn Sie diese Funktion wirklich benötigen, erhalten Sie die Firebird-Quelle, fügen Ihren eigenen undurchsichtigen Code in die Lese- und Schreibmethoden der Festplatte ein und kompilieren Ihre eigene Variante des Firebird-Servers. (Ein solcher Code könnte durch Dekompilieren der ausführbaren Datei entdeckt werden, aber es braucht einen ziemlich ernsthaften Dieb, um dies zu versuchen.)

Versuchen Sie vorher herauszufinden, ob dies Ihr Problem tatsächlich lösen würde, wenn der Benutzer zusammen mit der Datenbank auch eine Kopie der speziell kompilierten ausführbaren Dateien erstellt. oder wenn es einem Benutzer weiterhin möglich ist, die Geheimnisse direkt von Ihrem laufenden Server zu extrahieren.

Es gibt auch die philosophische Frage, warum Sie ein Open-Source-Datenbankserverprodukt zum Erstellen einer Closed-Source-Datenbank auswählen würden. Viele Menschen haben zu dem Projekt beigetragen, weil sie der festen Überzeugung sind, dass Open Source der beste Weg ist, Software bereitzustellen.

Vor allem aber, wenn es um die Speicherung von Benutzerdaten geht, bin ich fest davon überzeugt, dass die Benutzer auf der Möglichkeit bestehen sollten, auf ihre eigenen Daten zuzugreifen - was häufig die Notwendigkeit einschließt, die Strukturen und Prozesse zu verstehen, über die Sie verfügen gebaut (die Metadaten). Wenn Sie Ihr Geschäft aufgeben oder anderweitig nicht mehr verfügbar sind, kann es von entscheidender Bedeutung sein, dass die Benutzer zumindest ihre eigenen Daten (in geeigneten Formaten) extrahieren können, um auf alternative Systeme umsteigen zu können.

Können Sie den Benutzern vertrauen, dass sie Ihr geistiges Eigentum respektieren, während Sie noch im Geschäft sind und verfügbar sind? Stellen Sie die notwendigen Dienstleistungen und Einrichtungen bereit und hoffentlich auch. Wenn nicht, besteht eine gute Chance, dass Sie wenig tun können, um sie zu stoppen.

Das Problem war, dass zu viele Menschen die Sicherheit nicht verstehen und wie schwierig es ist, sie gut zu machen. Bedauerlicherweise gab es viele Softwareprodukte, die solche Missverständnisse begünstigten, indem sie eher Dunkelheit als echte Sicherheit implementierten. Erleben Sie die Anzahl der Unternehmen in der Umgebung, die “Datenwiederherstellungs”-Dienste anbieten. Damit ist gemeint, dass die vermeintliche Sicherheit verdeckter Daten umgangen oder verletzt wird.

Verschlüsselung ist kein Allheilmittel für die Sicherheit. Wenn Sie nicht die Kontrolle über die Umgebung haben (die Hardware, das Betriebssystem und die gesamte auf diesem System ausgeführte Software), haben Sie keine Kontrolle über die Sicherheit - unabhängig davon, welche Verschlüsselungsschemata möglicherweise vorhanden sind. Dies ist der Fall, wenn Sie Ihre Datenbank an Remoteserverinstallationen verteilen.

Wenn Sie die Daten oder Metadaten in Ihrer Datenbank wirklich schützen müssen, müssen Sie die Kontrolle über die Datenbankdatei und die Umgebung behalten, in der auf sie zugegriffen wird. Keine andere Lösung bietet Ihnen das gleiche Sicherheitsniveau.

Ich möchte mich bei den verschiedenen Personen bedanken, die diesen Artikel überprüft und kommentiert haben. Ich möchte mich auch bei den vielen Personen bedanken, die zur Firebird-Supportliste beitragen, aus der viele Informationen in diesem Artikel stammen.

Die exakte Dokumenthistorie — beginnend bei Version 0.5 — ist im Git-Repository des firebird-documentation-Repository zu finden; siehe https://github.com/FirebirdSQL/firebird-documentation

Ich habe versucht, dieses Dokument zum Zeitpunkt des Schreibens korrekt zu machen, kann jedoch nicht garantieren, dass keine Fehler vorliegen. Sicherheit ist ein komplexes Thema, bei dem Sicherheit für Ihr Produkt oder Ihre Installation wichtig ist. Sie sollten professionellen Rat einholen.

Ich mache für die Verwendung dieses Dokuments keine besonderen Einschränkungen. Es steht Ihnen frei, dieses Dokument zu reproduzieren, zu ändern oder zu übersetzen. Geänderte Versionen des Dokuments sollten jedoch mit den vorgenommenen Änderungen und dem Namen des Autors der Änderung versehen werden (damit mein Name nicht mit Texten in Verbindung steht, die ich nicht geschrieben habe). --G.W.

Mitwirkende: Daniel Albuschat – siehe Dokumenthistorie.

Teile erstellt von Daniel Albuschat unterliegen dem Copyright © 2009. Alle Rechte vorbehalten.

Mitwirkende: Martin Köditz – siehe Dokumenthistorie.

Teile erstellt von Martin Köditz unterliegen dem Copyright © 2020. Alle Rechte vorbehalten. Kontakt zum Mitwirkenden: martin dot koeditz at it dash syn dot de.