![]() |
AW: Datenbankverschlüsselung
Zitat:
WO ist denn wohl der Schlüssel für die verschlüsselte Datenbank gespeichert? Igendwo auf dem Rechner, wo und wie genau ist völlig egal denn der Datenbankserver (Software) startet ja ganz normal und für den Zugriff auf die Datenbankdatei(en) braucht er den Schlüssel. Würde der Server bei jedem Start nach einem Passwort fragen, dann könnte der Angriff abgewehrt werden. Aber der Server startet ja automatisch und niemand gibt ein Passwort ein. Der Windows Adminstrator hat bei vielen Datenbanken automatisch auch volle Zugriffsrechte für die Datenbank. Würde der Dieb nur die Festplatte stehlen sähe die Sache natürlich anderst aus. |
Was wäre denn das Problem, daß ein Dritter die Daten lesen könnte, oder daß der Auftraggeber die Daten nicht mehr hat?
Ich würde über einen Client die Daten absaugen, das fällt nur auf wenn ein entsprechendes Log geführt wird, und noch wichtiger wenn es auch gelesen wird. Zitat:
B.Brecht dreigroschenoper Gruß K-H P.S. Zitat:
|
AW: Datenbankverschlüsselung
Ich gehe davon aus, dass zumindest einer Clients das Passwort übertragen muss. Wenn man das Passwort neben der verschlüsselten Datenbank speichert, ist man selber Schuld. Es gibt aber auch Leute, die schließen Millionen im Tresor ein und hängen an die Tür einen Zettel mit der Zahlenkombination.
Also sx2008, ich gehe davon aus, dein Kommentar sollte ein Scherz werden. Puke |
AW: Datenbankverschlüsselung
Zitat:
Wenn die Mitarbeiter das Passwort eintippen müssen - es ihnen also bekannt sein muss - dann ist das auch unsicher. Server wegschließen und Zugriff auf die Daten über eine Zwischenschicht - niemals die Clients direkt mit dem Server kommunizieren lassen - die physisch getrennt auf einem eigenen System läuft und genauso geschützt wie der Server untergebracht ist. Die Kommunikation zwischen dem Server und der Zwischenschicht erfolgt über ein eigenes Netzwerk, getrennt vom Rest. Ansonsten fällt mir noch ein, die Festplatte/n vom Server unters Kopfkissen legen (das ist dann das sicherste Verfahren!) In diesem Zusammenhang auch ein interessanter Link mit massig Informationen zum Thema Sicherheit: ![]() |
AW: Datenbankverschlüsselung
Zitat:
Die gesamte Anforderung scheint mir hier ein wenig undurchsichtig, aber ich möchte noch schnell gesagt haben, dass RSA in diesem Anwendungsszenario eigentlich keine klassische Wahl ist (und wie erwähnt bitte NIE NIE NIE unter 1024bit). Um die Datenablage zu verschlüsseln bieten sich AES und 3DES an, symmetrische Verfahren sind einfach um Größenordnungen effizienter. |
AW: Datenbankverschlüsselung
Wenn das Merken eines Passworts unsicher ist...
Dann hab ich die Problemstellung falsch verstanden. Die Daten sind so sensibel, dass kein Mitarbeiter, bzw. Mensch, davon erfahren darf. Aber man braucht nur Onkel Puke zu fragen. Die Lösung: Lösch die Festplatte! Steck sie danach in die Mikrowelle. Beides kannst du neu kaufen. Aber die Daten sind auf jeden Fall sicher! Jetzt mal im Ernst Leute... Der RAM ist unsicher? Was hat das mit Einbruch zu tun? Ich dachte es geht um "normale" Datenbanken, die den Großteil der Daten auf der Festplatte verwalten. Aber auch dafür hat Onkel Puke die Lösung: Keine Computer mehr. Vielleicht nicht ganz in Mode, aber vielleicht sollte man sich unter den Umständen überlegen, ob man nicht einen Downgrade auf die Kommunikation mit dem Mund und die Speicherung im Kopf machen will. Dort sind die Daten dann auch wirklich sicher. Was heißt "Client und Server nicht direkt miteinander kommunizieren lassen"? Wir holen uns die Datenbank mit dem USB-Stick zum Client? Oder wird der Client über den NSA-Server mit dem Server verbunden? Übrigens ist die Verschlüsselung sicherer als der Kopfkissen-Trick! Gute Verschlüsselung hält Jahre - Der Ermordung der Person dauert höchstens ein paar Minuten. Gute Nacht Puke Edit: Danke, Sir Rufo! Endlich etwas Vernünftiges zu diesem Thema... Vor allem das mit dem AES und dem 3DES. Für ganz sensible Daten: 3AES! |
AW: Datenbankverschlüsselung
@Puke
Was nützt einem die tollste Verschlüsselung der Datenbank, wenn die ungeschützten Clients direkten Zugriff auf den Datenbank-Server haben? Bei einem Einbruch wird eben nicht der Server gestohlen, sondern es wird über einen Client / oder einen mitgebrachten Rechner in den Server eingebrochen und die Daten sind gestohlen. So sind diese nicht direkt miteinander verbunden: ![]() Und ich war es nicht, der von AES gesprochen hat Und du hast in einem Punkt recht: Es gibt keinen absoluten Schutz, sondern nur hohe und höhere Schwellen. Bei einem Sicherheitskonzept muss man sich aber vielschichtige Gedanken machen. Eine massive Tür mit x Schlössern und Riegeln in alle Richtungen bringt nichts, wenn die Wände nicht ebenso sicher sind. |
AW: Datenbankverschlüsselung
Was bringt es denn, wenn der Angreifer einen Client mit sich trägt, wenn der Server erstmal nach nem Passwort fragt, mit dem er die Dateien entschlüsseln kann. Natürlich sollte der Client das Passwort beim Ausschalten vergessen. Und der Server sollte das nach Arbeitsende auch irgendwie aus seinem Arbeitspeicher löschen/überschreiben.
.. Aber sonst hast du Recht. Die am schlechtesten geschützte Stelle wird ausgenutzt. Nur wenn alles gleicher Maßen gut geschützt wird, hat man ein sicheres System. Deswegen greifen "böse Menschen" fast nie die gutgeschützten Server wie Google, Facebook & Co. an, sondern lieber die privaten Clients mit den Sicherheitslücken im IE, Ihrem Java, usw. Viele schöne Grüße Puke |
AW: Datenbankverschlüsselung
Zitat:
|
AW: Datenbankverschlüsselung
Hallo,
danke erst einmal für die zahlreichen Beiträge. Leider beantwortet keiner meine Ursprungsfragen. Wie stabil ist eine aktuelle Interbase-Version? Und wie stabil ist eine aktuelle Interbase-Version mit Verschlüsselung? Zur eigentlichen Verschlüsselung nur so viel: der Datenbank-Schlüssel wird nicht auf dem Server und auch nicht auf dem Client gespeichert. Damit nützt es auch nichts, sich beim Bootvorgang irgendwo dazwischen zu klemmen. Lutz |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz