nicht angemeldet
Hallo Andreas,
Und wie gesagt ist es eh für den privaten Einsatz gedacht.
Das hält uns aber doch nicht davon ab darüber nachzudenken wie man es in einem größerem Rahmen angehen würde oder? :) Und was für einen größeren Rahmen gut genug ist, das muss für deine Home-Applikation erst recht gut sein.
Schon alleine der Upload ist ein Umweg von hinten durch die Nase ins Auge. Der direkte Weg ohne HTTP dazwischen ist kürzer und einfacher.
Da dies sowieso nur lokal läuft, sehe ich die Übertragung im Klartext nicht schlimm an.
Ich meine damit nicht die Übertragungszeit, sondern dass es unterwegs eine Menge Dinge, die schiefgehen können. Wenn du die Dateien auf einem direkterem Weg einliest, elimierst du Fehlerquellen.
Außerdem muss ich so nur überprüfen, ob die insert´s alle korrekt ausgeführt wurden und muss mich nicht darum kümmern, ob auch die Datei im Filesystem gelandet ist, falls ich alles in die DB ablege.
Du bist ja hart drauf. Checks machen eine Software langsamer. Alles was von einem User eingegeben wird muss auf Herz und Nieren geprüft werden, aber ein INSERT in die DB oder eine Schreiboperation ins Filesystem würde ich nicht mehr überprüfen, wenn sie ohne Fehlermeldung durchgelaufen ist.
Es gibt ja noch eine Tabelle mit den Metaangaben (id,metaangabe), sowie eine Tabelle für die Zuordnung "Metaangabe zur Datei" (metangabe_id,datei_id).
Hm..ich würde das in einer Tabelle machen, weil es nur eine 1:1 Relation ist.
Deine Version:
id, metaangabe, blob mit encoded file
Meine Version:
id, metaangabe, pfadangabe zum encoded file
Ich sichere (fast) täglich die relevanten Daten vom Rechner. Dazu gehören unter anderem auch alle Datenbanken und das htdocs Verzeichnis.
Ja wie sicherst du denn eine Datenbank? Klar zu Hause mit ein paar MBs brauchst du dir keine Gedanken machen, aber wir spielen ja großen Rahmen. Eine Datenbank mit "Haut und Haaren" zu backupen ist keine gute Idee, denn dan sichert man auch die Datenbank Programme, die Manuals und die Logfiles mit. Normalerweise ist ein Backup auf Platzersparnis optimiert und da haben solche Dinge nichts verloren, nur die reinen möglichst gut komprimierten Daten.
Und was mir auch wichtig ist, wie "sicher" man dieses Vorhaben umsetzen kann. Da weiss ich leider nicht genau Bescheid, ob das mySQL DECODE hinreichend sicher ist und was man anschließend shredden sollte.
Klar hilft das shredden, nachdem du die Datei in die DB geschrieben und vom Filesystem gelöscht hast. Und das ENCODE ist sehr sicher was
das dekodieren mit einer Brute Force Attacke angeht. Aber mal angenommen ich breche in deinem System ein. Ich würde als erstes in deinem Quelltext nach dem Passwort suchen, was du für das ENCODE verwendest und schon habe ich deine Daten. User und Passwort für die Datenbank stehen wahrscheinlich sogar in einer leicht zu findenen Konfig Datei.
Viel sicherer finde ich folgende Methode:
Wenn du eine neue Datei einpflegen willst, dann schreibst du sie ins Filesystem und verschlüsselst sie mit einem Passwort, dass du nur zum Zeitpunkt der Verschlüsselung eingibst. Dieses Passwort steht nirgends auf deinem Computer gespeichert, es existiert nur in deinem Kopf und ist höchstens mit altertümlichen Foltermethoden zu erlangen. Dann trägst du die Metaangaben + den Pfad zur Datei in die Datenbank ein und fertig. Jetzt sehe ich keine Möglichkeit mehr an deine Daten zu gelangen, wenn ich bei dir einbreche. Ich könnte bestenfalls deine Metaangaben dazu lesen. Und das shredden wird nebenbei auch komplett überflüssig.
Gruß,
Cruz