Welches DBMS ist geeignet, um ein Schema privat zu halten, selbst wenn es „in freier Wildbahn“ installiert wird?

StackOverflow https://stackoverflow.com/questions/654758

Frage

Ich habe einen Anwendungsserver, der eine Verbindung zu einem Datenbankserver herstellt.Ich möchte Benutzern Installationsprogramme zur Verfügung stellen und mit einem moderaten Maß an Komfort darauf vertrauen können, dass das Datenbankschema sicher ist.

Ich verstehe, dass es einige Risiken gibt, die ich einfach akzeptieren muss, wenn ich den Computer, auf dem es installiert ist, nicht kontrolliere – eine entschlossene Person mit den richtigen Werkzeugen und Kenntnissen könnte direkt in den Speicher schauen und Informationen herausholen.

Anfangs dachte ich, mein Schwerpunkt würde einfach darin liegen, die Anmeldeinformationen zum Installationsprogramm hinzuzufügen, ohne dass sie trivial in einem Hex-Editor angezeigt werden.

Als ich jedoch mit der Recherche begann, erfuhr ich, dass PostGreSQL einfach eine textbasierte Konfigurationsdatei (pg_hba.conf) ändern kann, selbst wenn ich die Datenbank im Hintergrund installiere und dem Benutzer keine Anmeldeinformationen gebe Starten Sie den Server neu und ermöglichen Sie so den vollständigen Zugriff auf die Datenbank ohne Anmeldeinformationen.

Ist dieses Szenario in anderen DBMS gesichert?Wie schützen die meisten kommerziellen Produkte ihre Schemata in diesem Szenario?Würden die meisten Produkte eingebettete Datenbanken verwenden?

Bearbeiten:Ich gehe (vielleicht zu Unrecht) davon aus, dass einige Produkte auf Datenbanken basieren, die der Benutzer nie direkt berührt.Und ich sehe sie natürlich nie, weil sie es so konzipiert haben, dass der Benutzer es nicht tun muss – wahrscheinlich mithilfe einer eingebetteten Datenbank.

War es hilfreich?

Lösung

Die meisten kommerziellen Produkte schützen ihre Schemata nicht.Sie fallen in eines von zwei Lagern:

Entweder nutzen sie eine Unternehmensdatenbank für eine Schlüsselkomponente des Produkts (z. B. ein Lohn- und Gehaltsabrechnungssystem). In diesem Fall wird kein Versuch unternommen, das Schema/die Daten zu verbergen.In den meisten dieser Fälle benötigt der Kunde ohnehin Kontrolle über die Datenbank – um zu konfigurieren, wie die Datenbank gesichert wird, um eine Cluster-Umgebung erstellen zu können usw.

Der andere Fall ist, wenn Ihre „Datenbank“ nichts anderes als eine kleine Einstellungs- oder Speicherdatei für eine Desktop-Anwendung (z. B.die Verlaufs- und Lesezeichendatenbanken in Firefox).In diesem Fall sollten Sie einfach eine eingebettete Datenbank (wie SQLite, genau wie Firefox) verwenden und eine Streaming-Verschlüsselungsschicht hinzufügen (es gibt eine offizielle Version davon namens SEE) oder einfach die eingebettete Datenbank verwenden und die Verschlüsselungsschicht vergessen, da Der Benutzer muss zunächst seine eigenen Datenbanktools installieren, um die Datei lesen zu können.

Andere Tipps

Soweit ich mich erinnere, gibt es keine kommerziellen Produkte, die „schützen“ ihr Schema. Was wollen Sie das Schema gegen geschützt werden?

Beachten Sie folgende Punkte:

  • Schließlich ist die einzige Person, die alles in einem RDBMS schützen kann, ist der Datenbankserver-Administrator. Und Sie wollen das Schema gegen diese Person geschützt werden?

  • Wenn ich ein Kunde und ich hatte Meine Daten in Ihrem Schema, würde ich nicht nur wie, sondern erwarten zu können, es direkt sehen und zu konsumieren.

  • Haben Sie wirklich Ihr relationales Design schützen müssen? Ist es so interessant wirklich? Haben Sie etwas wert versteckt erfunden? Ich glaube wirklich nicht so. Und ich entschuldige mich im Voraus, wenn Sie haben.

EDIT: Zusätzlicher Kommentar:

Ich kümmere mich nicht um die meisten Datenbank Einbauten für die Produkte, die ich verwende. Das ist ein weiterer Grund, warum ich die meisten von ihnen denken, nehmen Sie keine Aktion, sie zu schützen. Die meisten von ihnen sind nicht so interessant.

Auf der einen Seite, ich bin der festen Überzeugung, dass die Nutzer nicht wissen müssen, oder über die Interna der Datenbank zu kümmern. Aber auf dem gleichen Niveau, als Entwickler, ich glaube nicht, dass es sich lohnt, zu versuchen, sie zu schützen. Verstecken sie von dem Benutzer, ja. Schützen Sie sie vor direktem Zugang in den meisten Fällen nicht. Und nicht, weil ich denke, dass es falsch ist Ihr Schema zu schützen. Es ist, weil ich denke, dass es eine sehr harte Sache zu tun ist, und es ist Ihre Zeit als Entwickler nicht wert.

Aber am Ende, wie bei jedem sicherheitsrelevanten Thema, das einzig richtige Antwort ist, zu wissen, was sind die Risiken beteiligt vs Kosten von der Sicherheitsmaßnahme umzusetzen.

Aktuelle Datenbank-Engines, eingebettete oder Server-Stil, ist nicht entwickelt, um einfach das Schema der Datenbank zu verbergen, und daher die Entwicklungskosten, es zu tun ist viel größer als das Risiko beteiligt, für die meisten Menschen.

Aber Ihr Fall könnte anders sein.

Was Problem versuchen Sie zu lösen? Nichts kann den DBA * stoppen zu tun, was er zu Standard-Datenbanken will, und wie andere haben darauf hingewiesen, es ist aktiv feindlich mit standortspezifischen Anforderungen wie Backups und Datenbank-Upgrades zu stören. Allenfalls können Sie den Inhalt Ihrer Datenbank verschlüsseln, aber selbst dann muss man einen Entschlüsselungs liefert Schlüssel für Ihre Anwendung tatsächlich läuft und ein motiviertes und feindlicher DBA kann es wahrscheinlich untergraben.

Die militärischen und geheimdienstlichen Gemeinschaften undoubtably Datenbanken haben, wo auch das Schema hoch eingestuft ist, aber ich weiß nicht, ob sie mit technischen Mitteln geschützt sind oder einfach nur große Männer mit Gewehren.

(*) DBA oder Systemadministrator kann Dateien wie pg_hba.conf ändern.

  

Wie die meisten kommerziellen Produkte   schützen ihre Schemata in dieser   Szenario?

Ich glaube nicht, die meisten kommerziellen Produkte alles tun, um ihr Schema zu schützen.

Wie ein eingebettetes DBMS jemand stoppen kann mit seiner Lagerung (Dateien in diesem nicht-Embedded-Hardware-Kontext) basteln, wenn eine solche Person physischen Zugriff auf das Gerät hat, wo dieses DBMS läuft? Sicherheit durch Unklarheit ist eine riskante Angelegenheit.

Diese Idee wird von den gleichen Problemen wie DRM leidet. Sie können nicht den Zugriff durch den entschlossenen verhindern, und Sie werden nur allgemeine Schmerzen verursachen und für Ihre Kunden leiden. Es einfach nicht tun.

SQLite wickelt sein gesamtes Datenbank-Format in eine einzige Datei, und Sie könnten möglicherweise verschlüsseln und entschlüsseln sie an Ort und Stelle. Der Fehler, natürlich, ist, dass Benutzer die Schlüssel müssen jetzt die Datenbank verwenden, und der einzige Weg, was passieren kann, wenn man es ihnen geben, vielleicht durch Hartcodierung es zur Compile-Zeit (Sicherheit durch Verschleierung) oder ein Telefon-home-Schema (ganz Reihe von Gründen, warum dies eine schlechte Idee ist). Plus jetzt werden sie dich hassen, weil sie jeden Versuch ein nützliches Backup-System vereitelt haben und sie bekommen schreckliche Leistung zu booten.

Außerdem niemand kümmert sich eigentlich um Schemata. Hass, es Ihnen zu brechen, aber Schema-Design ist nicht ein schwieriges Problem, und schon gar nie ein legitimer Wettbewerbsvorteil (außerhalb von vielleicht einige spezifischen Bereichen wie Wissensrepräsentation und Data Warehousing). Schemen ist in der Regel nicht wert in erster Linie zu schützen.

Wenn es wirklich so wichtig für Sie, anstatt eine gehostete Anwendung tun.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top