Zugriff auf Datenbankdatei verhindern

[Byte]

Hallo,

überlege gerade welche Möglichkeiten es gibt, eine Datenbankdatei vor Zugriffen, durch Passwort und Verschlüsselung zu schützen.

Die Datenbank enthält Umsatzdaten von privaten Konten, ein gewisser Schutz ist also angebracht.

Gibt es eine Lösung mit der sich das realisieren lässt?

Gruß Christian

[CrackPod]

Du erstellst einen Benutzer unter dem der DB Daemon läuft und nur der hat Zugriff auf die DB Dateien.
LG

[Byte]

Hi CrackPod,

eigentlich wollte ich keinen eigenen Server dafür verwenden. Mir schwebt da etwas wie sqlite oder MS Access (mdb) vor.

Ein Ansatz von mir ist eine sqlite datei in einem mit Truecrypt verschlüsselten Laufwerk zu speichern. Mit den Truecrypt Kommandozeilenbefehlen, könnte man dies sogar von Python steuern.

Gruß Christian

[Leonidas]

Du kannst beispielsweise in die Datenbank die Daten verschlüsselt speichern (was zugegebenermaßen etwas arg blöd ist) oder die Datenbank verschlüsselt, beispielsweise mit GnuPG oder mit PyCrypto. Hängt aber auch ab, wie sicher du es haben willst.

Ein anderer Ansatz der mir einfällt, aber nur geht wenn die Datenbank ausreichend klein ist: Daten in Datenabnk verschlüsselt speichern, neue Datenbank in :memory: öffnen und dort die Datenbank unverschlüsselt wieder aufbauen. Hmm, wobei ich zugeben muss, dass ich diese Idee auch nicht für sonderlich sicher halte.

[jens]

Ein Ansatz von mir ist eine sqlite datei in einem mit Truecrypt verschlüsselten Laufwerk zu speichern. Mit den Truecrypt Kommandozeilenbefehlen, könnte man dies sogar von Python steuern.

Nette Idee, hat aber zwei Hacken. Zum einen mußt du das Laufwerk ja einbinden, wenn du die DB nutzten willst. In dem Zeitraum kann ein normaler User auf die DB Datei zugreifen.
Zum anderen must du IMHO irgendwo das TC Passwort gespeichert haben. Das kann ein User einfach aus deinem Skript auslesen...

Vielleicht ist es noch am einfachsten die Daten in der DB zu verschlüsseln. Aber auch das hat zwei Hacken: Die DB Zugriffe werden langsam (Man sollte evtl. nur die wichtigsten Daten verschlüsseln).
Aber auch hier mußt du irgendwo den Key/Passwort speichern.

[Sr4l]

Ich würde nicht die Daten in der Datenbank verschlüsseln. Ist zu aufwendig dann die Datenbankfunktionen zu nutzen.
Ich würde bei SQLite die Datei als ganzes mit einem Passwort verschlüsseln und bei Programmstart gibt man das Passwort ein mit dem wird die Datenbankdatei wieder entschüselt. Diese Technik ist mindestens so unsicher wie alle anderen, aber es ist die einfachste.

Die entschlüsselte Datei würde ich als virtuelle Datei in den Arbeitsspeicher legen.

[jens]

Ah. Hab mir nochmal das Eingangsposting durchgelesen. In dem Fall kann man ja wirklich ein Passwort vom User abfragen und damit dann die Entschlüsselung starten.

Es ist natürlich schon einfacher, wenn man eine SQLite Datei hat, diese dann in TEMP zu entschlüsseln und am ende wieder zurück verschlüsseln. Allerdings hat man ein Problem. Die entschlüsselte Variante könnte man recht einfach wieder herstellen

Wenn man nur die Buchungstexte verschlüsselt, kann man noch ganz normal die DB Abfragen benutzten. Wenn man mehr Schutz haben möchte, könnte man natürlich auch buchungs Datum und Betrag verschlüsseln. Dann kann man aber nicht mehr die DB Funktionen richtig nutzten um gezielt Daten basierend auf Datum/Betrag raus zu finden.

Evtl. gibt es ja die Möglichkeit die SQLite Datei nur im Speicher zu entschlüsseln und die dann dem SQLite-DB-Modul zu Verfügung zu stellen?
In dem Fall muß man natürlich die ganze Datei ins RAM passen

[Sr4l]

Ich habe gelesen das geht. Ich werde mal suchen...

Habs: http://python.org/doc/2.4.1/lib/module-StringIO.html

es gibt auch noch cStringIO ist die schnellee Variante, aber ich bleibe lieber bei pure Python wenns geht

[Leonidas]

es gibt auch noch cStringIO ist die schnellee Variante, aber ich bleibe lieber bei pure Python wenns geht

Wieso? cStringIO ist schneller und hat quasi keine Nachteile (außer du willst den Quellcode patchen).

[BlackJack]

`StringIO` gibt's auch ausserhalb von CPython. Solange ich keine Geschwindigkeitsprobleme habe, benutze ich bei `StringIO` und auch bei `pickle` die Pythonvarianten.

[jens]

cStringIO ist schneller und hat quasi keine Nachteile

Gibt es da nicht noch irgendwelche Probleme mit unicode??? Irgendwas war da mal...

[Leonidas]

`StringIO` gibt's auch ausserhalb von CPython.

Kompromiss:

Code: Alles auswählen

try:
    import cStringIO as StringIO
except ImportError:
    import StringIO

[joost]

Unterbrechung:

Der Autor (?) von sqlite verweist darauf, dass Lese- und Schreibrechte seiner Datenbanken über die Lese- und Schreibrechte des OS organisiert werden können (dadurch, dass jeder Datenbank eben genau nur eine Datei zugeordnet ist). Das finde ich sehr praktisch und werde so vorgehen.

[jens]

Unterbrechung:...

Ja, das ist das normale "verhalten" von SQLite... Es öffnet die Datei selber... In diesem Fall, soll doch eine verschlüsselte DB von python aus geladen werden, im RAM entschlüsselt und dann SQLite vorgesetzt werden... Oder hab ich da was falsch verstanden?

[Byte]

Hi,

danke für die vielen Antworten!

Eine Standardlösung gibt es scheinbar nicht. Beim Verschlüsseln der Datenbankdatei, sehe ich Probleme, wenn das Programm abbricht oder der PC unvorhergesehen abgeschalten wird. Wenn beim beenden das Programm die temporäre Datei nicht mehr verschlüsseln kann, führt das zu Datenverlust und die unverschlüsselte Datei bleibt erhalten.

Da werde ich wohl noch ein wenig grübeln müssen.

Christian

[BlackJack]

Die Standardlösung ist in der Regel die Mechanismen vom Betriebssystem zu benutzen, in Verbindung mit der Benutzererwaltung der Datenbanksoftware.

Also im einfachsten Fall die Benutzerrechte vom Betriebssystem, oder Verschlüsselungstechniken dazwischen schalten wenn es noch sicherer sein soll.

[encbladexp]

Könnte man das Problem einer temorären Tabelle nicht über eine ":memory:" Datenbank von SQLite lösen? Hierdurch würde keine Temporäre Datei entstehen, ich weis nur ne ob man ne :memory: DB dann nachträglich einfach so speichern kann

mfg Betz Stefan

[Leonidas]

Könnte man das Problem einer temorären Tabelle nicht über eine ":memory:" Datenbank von SQLite lösen?

Siehe meinen Post, früher. Das Problem kann ja immernoch das Swappen sein, dann landet der Speicher immernoch auf der Festplatte. Aber das ist immerhin sicherer als gar nichts.