Zugriff auf Datenbankdatei verhindern

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Byte
User
Beiträge: 63
Registriert: Dienstag 26. September 2006, 07:04

Donnerstag 10. Mai 2007, 16:06

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
User
Beiträge: 205
Registriert: Freitag 30. Juni 2006, 12:56

Donnerstag 10. Mai 2007, 17:41

Du erstellst einen Benutzer unter dem der DB Daemon läuft und nur der hat Zugriff auf die DB Dateien.
LG
Byte
User
Beiträge: 63
Registriert: Dienstag 26. September 2006, 07:04

Donnerstag 10. Mai 2007, 19:17

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Donnerstag 10. Mai 2007, 20:39

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 11. Mai 2007, 08:32

Byte hat geschrieben: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.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Freitag 11. Mai 2007, 08:43

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.
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 11. Mai 2007, 08:54

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 ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Freitag 11. Mai 2007, 13:57

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 :-D
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 11. Mai 2007, 15:13

Sr4l hat geschrieben:es gibt auch noch cStringIO ist die schnellee Variante, aber ich bleibe lieber bei pure Python wenns geht :-D
Wieso? cStringIO ist schneller und hat quasi keine Nachteile (außer du willst den Quellcode patchen).
My god, it's full of CARs! | Leonidasvoice vs Modvoice
BlackJack

Freitag 11. Mai 2007, 15:33

`StringIO` gibt's auch ausserhalb von CPython. Solange ich keine Geschwindigkeitsprobleme habe, benutze ich bei `StringIO` und auch bei `pickle` die Pythonvarianten.
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 11. Mai 2007, 15:37

Leonidas hat geschrieben:cStringIO ist schneller und hat quasi keine Nachteile
Gibt es da nicht noch irgendwelche Probleme mit unicode??? Irgendwas war da mal...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 11. Mai 2007, 15:42

BlackJack hat geschrieben:`StringIO` gibt's auch ausserhalb von CPython.
Kompromiss:

Code: Alles auswählen

try:
    import cStringIO as StringIO
except ImportError:
    import StringIO
My god, it's full of CARs! | Leonidasvoice vs Modvoice
joost
gelöscht
Beiträge: 134
Registriert: Sonntag 29. April 2007, 13:28

Freitag 11. Mai 2007, 16:07

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.
[color=green][size=75]Never use idle.pyw, if you need sys.stdin[/size][/color]
Benutzeravatar
jens
Moderator
Beiträge: 8461
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 11. Mai 2007, 16:13

joost hat geschrieben: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?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Byte
User
Beiträge: 63
Registriert: Dienstag 26. September 2006, 07:04

Freitag 11. Mai 2007, 19:38

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
Antworten