Archiv verlassen und diese Seite im Standarddesign anzeigen : Frage zu lokaler Datenbank
Ein Hi an alle Wissenden,
Ich stehe gerade vor dem Problem in eine Anwendung (c# als Basis) eine Datenbank einbinden zu wollen, die aber wohl auf nem Server liegen soll, der aber nicht zwingend nen SQL Server zur Verfügung stellt.
Sprich ich hatte da an SQL CE gedacht. Jetzt ist das ja eigentlich nicht multiuser-tauglich (zumindest hab ich das gelesen). Also gehen vermutlich keine parallelen Zugriffe (was vermutlich eher selten ist aber vorkommen könnte)
Jetzt habe ich mir überlegt das sdf file einfach bei Bedarf lokal zu kopieren (da sind nicht wirklich viele Daten drinnen, ich will nur aus Gründen von einem SQL/JSON Format weg weil ich die Daten da drin immer verschlüsseln müsste) und dann von lokal zu öffnen.
Kann das Probleme machen? Sprich wenn gerade zu dem Zeitpunkt ein user auf dem server auf das file zugreift und es just in dem Moment kopiert wird - was passiert dann mit den Zugriffen (lesend wie schreibend). Bleibt da was hängen was dann lokal blockieren/stören könnte oder ist das egal?
PatkIllA
2020-08-21, 14:38:02
und dann schreibst du die Datei wieder zurück?
Wir machen das mit SQLite und das klappt erstaunlich gut auch im Mehrbenutzerbetrieb.
Wie soll eine Datenbank dein Problem mit dem Verschlüsseln lösen?
lumines
2020-08-21, 17:38:55
Ich stehe gerade vor dem Problem in eine Anwendung (c# als Basis) eine Datenbank einbinden zu wollen, die aber wohl auf nem Server liegen soll, der aber nicht zwingend nen SQL Server zur Verfügung stellt.
Was bedeutet das überhaupt? Dass die Datenbank nicht mit der Anwendung auf dem gleichen Server laufen soll, hört sich jetzt erst einmal nicht ungewöhnlich an. Eventuell wird einfach erwartet, dass ihr für die Datenbank einen separaten Server nutzt oder man euch den bereitstellt.
Man kann natürlich auch viel mit SQLite und Co. machen, aber in so einem Fall würde ich einmal ganz genau nachfragen, wie überhaupt die Umgebung aussieht. Das scheint ja nicht so ganz klar zu sein.
Monger
2020-08-21, 17:56:55
Ich hab so viele Fragen... Wieso glaubst du, dass es sicherer ist ganze Datenbank zu kopieren statt sie abzufragen? Warum denkst du ne SQL DB ist nicht multiuserfähig?
Das Dateisystem ist auf jeden Fall NICHT threadsicher. Die meisten Datenbanken kennen nen Export bzw. Backup, der auch mitten im laufenden Betrieb geht. Aber im laufenden Betrieb reintegrieren... Das ist heiß.
Ah sorry, am Wochenende ganz vergessen hier mal reinzuschauen.
Zu euren Fragen:
Ich hole nur Daten aus der DB. Da muss nichts zurück geschrieben werden.
Bisher hatte ich dafür XML Dateien im Einsatz. Da dort aber mittlerweile als sensible eingestufte Daten drinnen stehen müsste ich alles verschlüsseln und auch von der Usability würde ich ne Datenbank bevorzugen.
Schreibend zugreifen tut auf die Daten nur eine Person (der Admin) und da darf auch immer nur ein Admin gleichzeitig was ändern (weil die sich sonst gegenseitig Daten überschreiben würden). Der hätte die Daten auf dem Fileserver editiert.
Das man ne DB auch anderweitig öffnen kann ist mir schon bewusst. Nur halt für den Wald- und Wiesenhonk nicht. Bei XML siehts das ja ganz anders aus. File öffnen und alle Daten werden einem präsentiert. So einfach soll es halt nicht sein.
SQLite hatte ich gar nicht mehr auf dem Schirm. Langsam werde ich wohl alt oder bin mittlerweile schon zu lange in meiner propriotären Welt unterwegs. :freak:
Und wo wir gerade dabei sind. Kann man so ner SQLite DB ein Passwort zuweisen, dass man sie nicht so einfach öffnen kann?
@Monger:
Warum denkst du ne SQL DB ist nicht multiuserfähig?
Das hatte ich irgendwo gelesen. Nur finde ich jetzt selbst die Aussage nicht mehr. Was ich dazu finde ist jetzt eher das Gegenteil. Vielleicht hab ich mich da einfach verlesen :freak:
Jetzt habe ich gerade hier ne Tabelle gefunden wo die verschiedenen Systeme gegenüber gestellt werden:
http://erikej.blogspot.com/2011/01/comparison-of-sql-server-compact-4-and.html
Damit scheint es bei meinen Ansprüchen ja dann egal zu sein ob ich nun SQL Compact 4 oder SQLite nutze. Beides unterstützt kein LINQ :freak:
Also dann doch eher SQL Compact 3.5? :confused:
Edit: @Monger hier stehts:
https://stackoverflow.com/questions/45060242/sqlce-compact-database-multi-user-over-network
Unfortunately The short answer is no. SQLCE is single user/instance by design.
Screemer
2020-08-24, 14:12:18
Sqlite DBS sind eine große File ohne encryption. Löst also dein Problem der vertraulichen Daten nicht wirklich. Außerdem ist es eigentlich nicht für Client-Server-Anwendungen gedacht. Sprich die DB liegt immer Lokal. Standardmäßig gibt es auch keinen auth an der DB. Gibt allerdings Extensions dafür. Mit entsprechend Dateisystem kannst du natürlich den Zugriff auf die DB für Benutzer beschränken.
Ich habe schon häufiger firebird/firedb für kleine Projekte genutzt. Leichtgewichtig und frei. Mit https://github.com/ansiboy/ALinq kann man wohl linq nutzen. Hab ich aber keine Erfahrung damit
Sqlite DBS sind eine große File ohne encryption. Löst also dein Problem der vertraulichen Daten nicht wirklich. Außerdem ist es eigentlich nicht für Client-Server-Anwendungen gedacht. Sprich die DB liegt immer Lokal. Standardmäßig gibt es auch keinen auth an der DB. Gibt allerdings Extensions dafür. Mit entsprechend Dateisystem kannst du natürlich den Zugriff auf die DB für Benutzer beschränken.
Ich habe schon häufiger firebird/firedb für kleine Projekte genutzt. Leichtgewichtig und frei. Mit https://github.com/ansiboy/ALinq kann man wohl linq nutzen. Hab ich aber keine Erfahrung damit
Und fireDb hat Passwortschutz und ist Multi-User tauglich?
SQLite scheint zumindest kein Problem mit multi-user Zugriff zu haben (zumindest nicht im überschaubaren Maße. Wir reden hier vllt. von 20-50 usern, die vermutlich nie gleichzeitig auf die Daten zugreifen wollen). LINQ tauglich scheint SQLite mittlerweile wohl auch zu sein (obwohl LINQ Tauglichkeit für mich kein Ausschlusskriterium ist. Vertrauter bin ich eh eher mit SQL als mit LINQ)
Edit: Lese ich das richtig, dass FireDB ne cloud-basierte Lösung von Google ist? Das wäre dann eher ein Ausschlusskriterium.
PatkIllA
2020-08-24, 15:15:54
soll der User denn das Passwort jedes mal eingeben?
Der .NET Wrapper von SQLite kann auch Verschlüsselung. Bleibt aber auch immer noch die Frage nach wo das Passwort herkommt.
Monger
2020-08-24, 15:24:04
Das man ne DB auch anderweitig öffnen kann ist mir schon bewusst. Nur halt für den Wald- und Wiesenhonk nicht.
Mach mal eine DB mitm Text Editor auf. Da ist erstaunlich viel Klartext drin.
Security by Obscurity ist Mist. Bitte nicht. Nimm ne leichtgewichtige DB, sorg dafür dass der Server nur das mitteilt was er mitteilen darf.
lumines
2020-08-24, 15:42:06
Ich hole nur Daten aus der DB. Da muss nichts zurück geschrieben werden.
Bisher hatte ich dafür XML Dateien im Einsatz. Da dort aber mittlerweile als sensible eingestufte Daten drinnen stehen müsste ich alles verschlüsseln und auch von der Usability würde ich ne Datenbank bevorzugen.
[...]
Das man ne DB auch anderweitig öffnen kann ist mir schon bewusst. Nur halt für den Wald- und Wiesenhonk nicht. Bei XML siehts das ja ganz anders aus. File öffnen und alle Daten werden einem präsentiert. So einfach soll es halt nicht sein.
So einfach ist es aber, auch mit SQLite. Der ganze Gag hinter diesen Datenbanken ist ja, dass sie sich so einfach handhaben und öffnen lassen.
Für SQLite:
$ sqlite3 test.db "CREATE TABLE testtable (id INTEGER PRIMARY KEY, test TEXT); INSERT INTO testtable(test) VALUES('test123')"
$ file test.db
test.db: SQLite 3.x database, last written using SQLite version 3027002
$ sqlite3 test.db "SELECT * FROM testtable"
1|test123
Schreibend zugreifen tut auf die Daten nur eine Person (der Admin) und da darf auch immer nur ein Admin gleichzeitig was ändern (weil die sich sonst gegenseitig Daten überschreiben würden). Der hätte die Daten auf dem Fileserver editiert.
Du meinst jetzt aber diese temporären Dateien, die aus der Datenbank geholt werden, oder?
Mir ist das ganze Konstrukt aber auch noch immer nicht so ganz klar. Warum kann man nicht einfach eine Datenbank auf einem anderen Server aufziehen und dann über das Netzwerk bereitstellen, der Anwendung Zugriff erlauben und parallel dazu auch dem Admin entsprechende Rechte geben? Wenn es nur darum geht die Daten sicher zu übertragen, dann wäre TLS als Transportverschlüsselung zur Datenbank sicher sinnvoll und würde dein Problem ziemlich sicher lösen.
Für mich hört sich das mit der lokalen Datenbank irgendwie nach einem riesigen Workaround an und schafft mehr Probleme als es eigentlich löst. Ich mag SQLite, aber das hört sich hier wirklich nicht nach der richtigen Lösung an.
Wenn es um eine Einsparung von Lizenzkosten geht, dann sollte man vielleicht über PostgreSQL als Alternative zum MS SQL Server nachdenken.
Ich kann leider nicht davon ausgehen, dass ein DB Server bereit gestellt werden kann. Auch das Zugriffsrechte konfiguriert werden können kann ich nicht garantieren. Ich muss von einer Minimallösung ausgehen. Das wird ne Lösung für kleinere Abteilungen in Konzernen. Die müssen sich mit ihrer IT rumärgern aber bekommen zu 95% keine Unterstützung und eher Steine in den Weg gelegt als anders herum. Denen wird maximal ein Fileserver sprich Netzlaufwerk zur Verfügung gestellt.
Mit meiner bisherigen XML Lösung war das machbar. Nur wollte ich davon halt weg und hab mich gefragt welche DB Lösung man unter diesen Umständen einsetzen kann.
Gut, wenn die Sicherheit bei den vorhanden DB Lösungen auch so schlecht ist dann muss ich die Daten halt zusätzlich verschlüsseln. Nur von der XML Lösung will ich wirklich weg wenn möglich.
soll der User denn das Passwort jedes mal eingeben?
Der .NET Wrapper von SQLite kann auch Verschlüsselung. Bleibt aber auch immer noch die Frage nach wo das Passwort herkommt.
Ähm, ich mag mich irren aber bei Mysql konnte man damals ne DB nur öffnen wenn man ein Passwort hatte ... oder war das der htaccess Schutz, oder phpmyadmin ... man das ist auch schon wieder 15 Jahre her :uponder:
PatkIllA
2020-08-24, 17:52:01
Ähm, ich mag mich irren aber bei Mysql konnte man damals ne DB nur öffnen wenn man ein Passwort hatte ... oder war das der htaccess Schutz, oder phpmyadmin ... man das ist auch schon wieder 15 Jahre her :uponder:Das ist ja auch normal bei einer Serverdatenbank. Wenn man allerdings lokale Rechte auf dem Server hat kann man auch in die Dateien gucken.
Ich meine nur, dass deine Anwendung die Daten ja auch lesen muss. Dabei ist es egal ob es das Passwort für die Serverdatenbank ist oder der Schlüssel für die Datenbank.
Wenn du das in die Anwendung codierst, dann kommt da auch jedes Skriptkiddie ran. .NET Assemblies lassen sich zu sehr gut lesbaren Quelltext dekompilieren.
Beim SQL Server könnte der User automatisch über die Domäne authentifiziert werden und so kommen nur die Benutzer/Gruppen an die Daten die entsprechend im Server eingetragen werden. Und nur der Admin dürfte schreiben.
Im Moment klingt deine Sicherheit eher so nach ROT13.
Ich muss aber gestehen, dass ich etwas auf dem Level nach Protest und Hinweis in der Admindoku auch schon umgesetzt habe.
Screemer
2020-08-24, 19:41:24
Edit: Lese ich das richtig, dass FireDB ne cloud-basierte Lösung von Google ist? Das wäre dann eher ein Ausschlusskriterium.
hatte im kopf, dass der alte name von firebird eben firedb war. sorry da lag ich falsch. obiges bezog sich auf firebird.
lumines
2020-08-24, 20:40:39
Ich kann leider nicht davon ausgehen, dass ein DB Server bereit gestellt werden kann. Auch das Zugriffsrechte konfiguriert werden können kann ich nicht garantieren. Ich muss von einer Minimallösung ausgehen. Das wird ne Lösung für kleinere Abteilungen in Konzernen. Die müssen sich mit ihrer IT rumärgern aber bekommen zu 95% keine Unterstützung und eher Steine in den Weg gelegt als anders herum. Denen wird maximal ein Fileserver sprich Netzlaufwerk zur Verfügung gestellt.
Mit meiner bisherigen XML Lösung war das machbar. Nur wollte ich davon halt weg und hab mich gefragt welche DB Lösung man unter diesen Umständen einsetzen kann.
Also gerade wenn da mit sensiblen Daten hantiert wird, würde ich doch davon ausgehen, dass irgendjemand dort Datenbanken administrieren kann und die auch richtig einstellen kann.
Ganz nebenbei: Da du ganz konkret ein Netzlaufwerk ansprichst, kann ich dir jetzt schon sagen, dass das mit SQLite und Co. nicht funktionieren wird. Die Entwickler raten ganz stark davon ab:
If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.
Quelle: https://www.sqlite.org/whentouse.html
Das Problem wirst du aber auch immer mit Netzlaufwerken haben. Keine Lösung wird damit zuverlässig funktionieren.
Im Grunde kann das alles nur funktionieren, wenn du einen Dump der Datenbank ziehst und rüberkopierst, womit man wieder auf dem gleichen Stand wie bei deiner XML-Lösung ist.
Gut, wenn die Sicherheit bei den vorhanden DB Lösungen auch so schlecht ist dann muss ich die Daten halt zusätzlich verschlüsseln. Nur von der XML Lösung will ich wirklich weg wenn möglich.
Auch das wird dir nichts bringen:
Wenn du das in die Anwendung codierst, dann kommt da auch jedes Skriptkiddie ran. .NET Assemblies lassen sich zu sehr gut lesbaren Quelltext dekompilieren.
Kann ich bestätigen. Been there, done that ...
Das ist ja auch normal bei einer Serverdatenbank. Wenn man allerdings lokale Rechte auf dem Server hat kann man auch in die Dateien gucken.
Ich meine nur, dass deine Anwendung die Daten ja auch lesen muss. Dabei ist es egal ob es das Passwort für die Serverdatenbank ist oder der Schlüssel für die Datenbank.
Wenn du das in die Anwendung codierst, dann kommt da auch jedes Skriptkiddie ran. .NET Assemblies lassen sich zu sehr gut lesbaren Quelltext dekompilieren.
Beim SQL Server könnte der User automatisch über die Domäne authentifiziert werden und so kommen nur die Benutzer/Gruppen an die Daten die entsprechend im Server eingetragen werden. Und nur der Admin dürfte schreiben.
Im Moment klingt deine Sicherheit eher so nach ROT13.
Ich muss aber gestehen, dass ich etwas auf dem Level nach Protest und Hinweis in der Admindoku auch schon umgesetzt habe.
Ok, wir reden hier von Ingenieuren, die froh sind einen Mauszeiger von A nach B schubsen zu können. Da fehlt es von vorne bis hinten an IT KnowHow. Da ist jeder Script-Kiddi meilenweit voraus.
Ansonsten könnte ich C++ Code einbinde, der mir das Passwort liefert. Das könnte dann wohl schwierig sein den zu Deassemblieren.
Aber wie gesagt, mehr als einen Texteditor können die Leute nicht bedienen - wenn überhaupt.
@lumines
Da gehts doch um Schreibzugriffe. Die hätte ich ja nicht. Vielleicht probier ich die Lösung einfach mal und lasse es drauf ankommen. Ist ja weit entfernt von hoch frequenter Nutzung.
lumines
2020-08-24, 22:35:39
Ansonsten könnte ich C++ Code einbinde, der mir das Passwort liefert. Das könnte dann wohl schwierig sein den zu Deassemblieren.
Aber wie gesagt, mehr als einen Texteditor können die Leute nicht bedienen - wenn überhaupt.
Ich kann dir garantieren, dass das keine gute Annahme ist. Deine Anwendung wird ziemlich sicher nicht nur durch die Hände der eigentlichen Nutzer gehen.
@lumines
Da gehts doch um Schreibzugriffe. Die hätte ich ja nicht. Vielleicht probier ich die Lösung einfach mal und lasse es drauf ankommen. Ist ja weit entfernt von hoch frequenter Nutzung.
Ich würde es jedenfalls nicht machen.
Alternativ könnte man sicher auch schnell eine read-only-REST-API für Teile der Datensätze erstellen. So könntest du einerseits z.B. für deine Anwendung SQLite nutzen, aber einige Daten noch halbwegs zivilisiert nach außen verfügbar machen. Ein Client (den man dann einfach separat mitliefert) müsste in deinem Fall ja nicht einmal eine GUI haben und einfach nur die Daten für den Admin auf seinen lokalen Rechner dumpen, wenn ich den Anwendungsfall richtig verstehe. Das wäre wahrscheinlich auch vergleichsweise einfach abzusichern.
Aber für REST brauch ich doch nen Webserver?! :confused:
Noch mal: Ich darf nicht davon ausgehen, dass die IT irgend etwas installiert oder einstellt weil das machen sie meist nicht (Sicherheitsbedenken, zu faul oder inkompetent ... sucht euch was aus). Die IT ist meist auch nach Timbuktu oder dergleichen ausgelagert, sehr träge und versteht oft auch gar nicht was man will. Ich selbst darf da auch nicht an die Systeme - was ja klar ist.
Ich lade die Daten aus der DB auch nur beim Öffnen der App. Danach erfolgt kein Zugriff mehr. Die Datenmenge ist überschaubar. Was ich lade sind User-Projekt Beziehungen und Projekteinstellungen. Es geht quasi darum externen Mitarbeitern nicht zu ermöglichen Einsicht zu nehmen welche Projekte von der Firma noch bearbeitet werden. Die App ist nur eine Plattform um Projekte zu konfigurieren und User diesen dann zuzuweisen um damit eine andere Software zu starten, die von meiner App über Umgebungsvariablen und Aufrufparametern konfiguriert wird. Nix wildes also.
Es gibt meist nur einen Admin, der alle paar Tage vllt. mal eine Anpassung an den Daten vornimmt. Hinzu kommen vllt. 10 bis 30 User, die die App 2-3x täglich nutzen um die Software zu starten. Da gibt es seltenst parallele Zugriffe. Bisher lief es immer so ab, dass die XML Files auf dem Netzwerklaufwerk lagen und kurz ausgelesen wurden. Gab es kollidierende Zugriff hat die App jede halbe Sekunden einen erneuten Zugriff probiert bis es klappt. Das hat bisher problemlos funktioniert.
Exxtreme
2020-08-25, 17:20:17
Schreibend zugreifen tut auf die Daten nur eine Person (der Admin) und da darf auch immer nur ein Admin gleichzeitig was ändern (weil die sich sonst gegenseitig Daten überschreiben würden). Der hätte die Daten auf dem Fileserver editiert.
Und in zwei Jahren kommt die neue Anforderung, dass mehrere Leute was reinschreiben müssen. :freak: Merke: Systeme, die produktiv genutzt werden bleiben niemals(!) klein und übersichtlich. :D
Ansonsten hätte ich spontan auch Sqlite gesagt. Es gibt auch noch H2, die ist aber in Java geschrieben. Diese hat aber den Vorteil, dass sie sowohl lokal wie auch als Server fungieren kann. Java könnte aber in der C#/C++-Welt ein K.O.-Kriterium sein.
Ach ja, Verschlüsselung lieber in der Anwendung machen und die Daten bereits verschlüsselt persistieren falls das Datenbank-System keine Verschlüsselung kennt. Und verlass dich nicht drauf, dass die Daten nur deshalb "sicher" sind bloß weil Ingenieure keinen Plan von IT haben.
PatkIllA
2020-08-25, 17:25:11
Ganz nebenbei: Da du ganz konkret ein Netzlaufwerk ansprichst, kann ich dir jetzt schon sagen, dass das mit SQLite und Co. nicht funktionieren wird. Die Entwickler raten ganz stark davon ab:
Quelle: https://www.sqlite.org/whentouse.html
Das Problem wirst du aber auch immer mit Netzlaufwerken haben. Keine Lösung wird damit zuverlässig funktionieren.SQLite über Netzlaufwerk funktioniert überraschend gut. Empfehlung mag ich aber auch nicht aussprechen.
lumines
2020-08-25, 19:27:59
SQLite über Netzlaufwerk funktioniert überraschend gut. Empfehlung mag ich aber auch nicht aussprechen.
Ich sag einmal so, schlechter als XML-Dateien zu synchronisieren wird es nicht sein, aber man sollte eben auch kein ACID erwarten, weil Netzlaufwerke auch gar nicht die Features korrekt implementieren, die dafür notwendig wären. Für unwichtige Daten oder private Nutzung ist das wahrscheinlich in Ordnung und natürlich sehr komfortabel (gerade wenn man regelmäßige Backups macht), aber bei Software für andere Unternehmen wäre ich da schon sehr vorsichtig.
Aber für REST brauch ich doch nen Webserver?! :confused:
Also irgendetwas sollte man doch schon voraussetzen können.
Aber ich glaube auch, dass ich die ganze Anwendung irgendwie falsch verstanden habe. Mir ist gerade eben erst klar geworden, dass deine Anwendung wahrscheinlich komplett clientseitig läuft und du den "State" als XML-Dateien über ein Netzlaufwerk (CIFS?) synchronisierst. Ich bin davon ausgegangen, dass du irgendwo einen zentralen Server bekommst und nur das Problem hast, dass man dir dort keine separate Datenbank bereitstellen will.
Noch mal: Ich darf nicht davon ausgehen, dass die IT irgend etwas installiert oder einstellt weil das machen sie meist nicht (Sicherheitsbedenken, zu faul oder inkompetent ... sucht euch was aus). Die IT ist meist auch nach Timbuktu oder dergleichen ausgelagert, sehr träge und versteht oft auch gar nicht was man will. Ich selbst darf da auch nicht an die Systeme - was ja klar ist.
Na ja, sie installieren ja mindestens deine Anwendung auf den Rechnern.
Ich lade die Daten aus der DB auch nur beim Öffnen der App. Danach erfolgt kein Zugriff mehr. Die Datenmenge ist überschaubar. Was ich lade sind User-Projekt Beziehungen und Projekteinstellungen. Es geht quasi darum externen Mitarbeitern nicht zu ermöglichen Einsicht zu nehmen welche Projekte von der Firma noch bearbeitet werden. Die App ist nur eine Plattform um Projekte zu konfigurieren und User diesen dann zuzuweisen um damit eine andere Software zu starten, die von meiner App über Umgebungsvariablen und Aufrufparametern konfiguriert wird. Nix wildes also.
Ich meine, wenn die Anwendung wirklich so simpel ist, kannst du natürlich auch einfach zwei Builds deiner Anwendung ausliefern. Einmal die volle Version für den Admin mit Schreib- und Lesefunktionen und einmal für die Nutzer, die nur read-only-Funktionen hat und dann beten, dass niemand auf die Idee kommt die Datenbank abseits der Anwendung anzufassen. So kann dann sowieso nur eine Person in die Datenbank schreiben. Auch da muss man natürlich hoffen, dass es nicht zwei Admins gibt.
Ach ja, Verschlüsselung lieber in der Anwendung machen und die Daten bereits verschlüsselt persistieren falls das Datenbank-System keine Verschlüsselung kennt.
Was allerdings wieder ganz eigene Fallstricke mit sich bringt, weil die Datenbank hier auf einem Netzlaufwerk liegen soll.
Ein kleiner Funfact: Die allermeisten, verschlüsselten Datenformate sind nicht sicher auf Netzlaufwerken, Cloud-Speichern etc. nutzbar, auf denen die Daten von Dritten in irgendeiner Form modifiziert werden können. Man braucht dagegen authentifizierte Verschlüsselung und selbst dann gibt es noch haufenweise Probleme, die man sich damit einhandeln kann. So etwas sicher zu designen ist absolut nicht trivial. Daran sind schon viele andere Leute gescheitert. Von daher würde ich nicht davon ausgehen, dass medi sich so etwas einmal schnell aus dem Ärmel schlackern kann. Mal ganz davon abgesehen, dass er sowieso keine Sicherheit bekommt, wenn er den Schlüssel einfach in der Anwendung einbettet.
Sehr interessant ist in dem Kontext dieser Audit zu gocryptfs: https://defuse.ca/audits/gocryptfs.htm
Ein Auszug:
We found that gocryptfs provides excellent confidentiality against a passive adversary, i.e. one that does not tamper with the encrypted files. On the other hand, we found that gocryptfs provides no security at all against an active adversary who can modify the ciphertexts while having read access to any subdirectory of the mounted filesystem. Against a less-powerful active adversary who can modify the ciphertexts but has no access to the mounted filesystem, gocryptfs keeps file contents secret and provides imperfect integrity protection. In at least one case, imperfections in the integrity protections lead to a break of confidentiality. It is possible that the integrity imperfections lead to further confidentiality breaks depending on which applications are using the filesystem.
Die gleichen Probleme haben z.B. auch bei den ersten Versionen der Keepass-Passwortdatenbank zu relativ schwerwiegenden Sicherheitsproblemen geführt, wenn man die Datenbank auf einem Netzlaufwerk genutzt hat, auf das auch andere Personen Schreibzugriff haben. Das ist kein isoliertes Beispiel, sondern ein allgemeines Problem mit unauthentifizierter Verschlüsselung auf solchen Datenspeichern.
Man kann es drehen und wenden, aber Daten gerade auf einem Netzlaufwerk zu teilen ist fundamental unsicher, selbst wenn man die Daten vermeintlich richtig verschlüsselt. Man hantiert da mit sehr subtilen, kryptografischen Problemen, welche die meisten Leute so tiefgreifend gar nicht verstehen.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.