|
Datenbank: Divers • Version: 000 • Zugriff über: FireDac
Datenbank mit Tabellenverschlüsselung benötigt.
Hallo,
ich habe bei einem Kundenauftrag die Vorgabe, dass der Inhalt der Tabellen verschlüsselt sein muss. Passwort für die Entschlüsselung wird über die Software an den Datenbankserver übergeben. Damit soll vermieden werden, dass der Datenbankadministrator die Daten der Tabellen lesen, bzw. ändern kann. Kennt jemand einen Datenbankserver, der dies untersützt? Danke für Unterstützung. Gruß Johndoe |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
MS SQL Server kann das.
Oracle in größeren Editionen auch. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
:P Interbase
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
 http://www.ibexpert.net/ibe/index.ph...ptionPluginFB3Wobei bei firebird gleich die gesamte DB verschlüsselt ist, was aber auch keineswegs als Nachteil zu sehen ist, wenn die Anforderung des Kunden eben eine Verschlüsselung erfordert. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
postgreSQL kann da auch was:
https://www.postgresql.org/docs/8.1/...n-options.html und http://www.postgresonline.com/journa...-pgcrypto.htmlGrüße Klaus |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Du kannst auch die Daten der Felder verschlüsseln. Z. B. mit dem DEC ->
https://github.com/decfpc/DelphiEncryptionCompendium oder https://github.com/winkelsdorf/Delph...ionCompendium/ |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Auch sowas wie Abfragen mit Like und Wildcards geht auch nicht mehr. Da kann man gleich ohne DBMS arbeiten. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Hallo,
danke für die Hinweise. Bei MsSQL habe ich Informationen zur Version 2016 gefunden. Tabellenverschlüsselung, dass der DB Administrator das nicht lesen kann, bedeutet, dass man u.a. auf joins und where verzichten muss. Wie von Bernhard Geyer geschrieben, ist das nicht sinnvoll. Bei PostrgeSQL ist unter pgcrypto folgendes geschrieben. Zitat:
Problem ist, dass der Kunde ein Audit hat und man auf dieses Scenario besteht. Angeblich würde das Steuerrecht vorgeben, dass auch auch Änderungen vom DB Administrator nachvollzogen werden müssen, bzw. wenn dies nicht möglich ist unterbunden werden müssen. Nur mal so gefragt: Kennt jemand so eine Vorgabe, oder ist dass von den Auditoren eine Wunschvorstellung? |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
D.h. wenn Du von deinem Client die Daten verschlüsselt in dei Datenbank ablegst - dann hat das DBMS Probleme mit where, joins etc. Es kann die Daten schlichtweg nicht lesen. Wenn es eine Verschlüsselung ist, die vom DBMS unterstütz ist, dann kann das DBMS diese Daten bei SQL Abfragen auch entschlüsseln. Grüße Klaus |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Für den Preis kann man aber auch andere Datenbanken bekommen.
Sind wengistens Firmenanteile dabei? |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
https://firebirdsql.org/file/documen...ncryption.htmlhttps://github.com/FirebirdSQL/fireb...amples/dbcrypt |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Wenn also Änderungen vom DB Administartor nachvollzogen werden können, ist alles ok und man braucht keine Verschlüsselung? Wenn man Änderungen aber nicht nachvollziehen kann, dann verschlüsselt man die Daten einfach, denn damit kann man dann sicherstellen, dass der DB Administrator die nicht nachvollziehbaren Änderungen sehen und erkennen kann und damit nicht feststellen kann, dass sie nicht nachvollziehbar sind? Zugegeben: Etwas arg überspitzt formuliert. Aber mir scheint das nicht der richtige Ansatz zu sein. Alternativ könnte man dem DB Administartor doch einfach auch den Zugriff auf die DB untersagen / ihm keine entsprechenden Rechte geben, dann kann er auch nicht in die Daten schauen. Wenn man ihm jedoch Zugriff auf die Datenbank gewährt, so kann er auch die Daten in der Datenbank sehen, da die Verschlüsselung ja (höchstwahrscheinlich) für alle Datenbankanwender funktioniert. Oder anders formuliert: Wenn der DB Administartor die Daten in der Datenbank nicht lesen darf und sie deshalb verschlüsselt werden, so scheidet eine datenbankseitige Verschlüsselung aus, da sie ja letztlich für alle Anwender, also auch den DB Administrator, transparent ist, also nicht sichtbar. Verschlüsselt die Datenbank, so bekommen alle Anwender bei 'nem select * from tabelle die unverschlüsselten Daten zu sehen, auch der DB Administrator ist nur ein Anwender, wenn er auf die Daten schaut. Schaut man aber mit 'nem HEX-Editor ... an der Datenbank vorbei in die Daten, dann bekommt man nur "verschlüsseltes Gelumpe" zu sehen. Oder soll die Datenbank hergehen und die Daten nur entschlüsselt liefern, wenn eine bestimmte Software sie anfordert und andernfalls die verschlüsselten Daten? Das hieße dann: Die Verschlüsselung muss durch die Software erfolgen, damit ist eigentlich jede sinnvolle Arbeit mit der Datenbank hinfällig. Natürlich kann man Abfragen parametrisiert gestalten und über die Parameter dann die verschlüsselten Werte an die Abfragen geben. Aber, wie weiter oben schon erwähnt, wird es dann bei allem, was auch nur im Ansatz zu einer unscharfen Suche dient, wie like, between, Substrings aber auch Order By, dann eher "spaßig" werden oder zu unerwarteten Ergebnissen führen. Einzig funktionieren könnten dann noch exakte Abfragen auf Werte, wie z. B. technische Datensatzschlüssel, Namen in exakter Schreibweise. Alles andere wird gnadenlos scheitern. Zitat:
Wenn ich nicht will, dass der DB Administrator in die Daten schauen kann, dann untersage ich ihm den Zugriff auf die Daten Punkt Aber die Daten unlesbar und in letzter Konsequenz unbrauchbar zu machen, erscheint mir der falsche Ansatz. In Arbeitsverträgen ist für gewöhnlich geregelt, wer wo in welche Daten Einsicht nehmen darf und welche Folgen die Nichtbeachtung hat. Details regelt man über entsprechende Rechtevergaben für Datenbanken, Filesysteme ... Man stellt ja auch nicht sicher, dass jemand alle Emails aller Nutzer einsehen kann, indem man sie so verschlüsselt, das bestimmte Emails nur von einem bestimmten Nutzer gelesen werden können, aber nicht von den anderen. Bevor Du da jetzt weiterforschst, lass von Deinem Arbeitgeber erstmal definitiv klären, ob die "behauptete Rechtsgrundlage" eine "real existierende Rechtsgrundlage" ist, weise ihn schonmal auf die zu erwartenden Konsequenzen in Bezug auf die Nutzbarkeit der Software hin und lass ihn dann entscheiden, ob er den Auftrag überhaupt annehmen mag ;-) PS: Abgesehen davon kann man in "gewöhnlichen" Datenbanken per Grant Rechte vergeben. Wenn der DB Administrator keine Rechte auf die Tabellen mit Geschäftsdaten bekommen soll, dann kann man sie ihm ja per Revoke entziehen und damit kann er dann auch nicht mehr in die Daten schauen. Natürlich wird das den Umfang seiner Arbeitsmöglichkeiten einschränken, aber sicherlich seine Arbeit nicht unmöglich machen. (Achso: Der DB Administrator sollte in diesem Fall nicht das Recht haben, sich selbst beliebige Rechte zu erteilen ;-)) |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Schau dir mal die Preise für eine EE-Edition von Oracle an, die du hier benötigen würdest. Locker mal 47 k$ pro Prozessor .... |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Er ist ja für die Betreung zuständig, wenn er aber nix mehr darf. Wie steht es mit Backup? Wie mit evtl. nötigen Optimierungsmaßnahmen? Wie mit Zuweisen von Bereichtigungen für andere User... Ein solche Szenario müsste man als DB-Admin ablehnen. Zitat:
Auch ein Hex-Editor bringt nur Byte-Salat. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Hier müssten wir mal klären, was wir genau unter datenbankseitiger Verschlüsselung verstehen. Ich bin bisher davon ausgegangen, dass sie für alle Anwender transparent ist, also die Daten von der Datenbank selbst verschlüsselt in der Datenbankdatei abgelegt werden, aber bei der Auslieferung an den Anwender, unabhängig von der genutzten Software, unverschlüsselt von der Datenbank ausgegeben werden (ohne irgendeine extra Passworteingabe. Ok, eventuell eine etwas naive Ansicht ;-)) Wenn softwareseitig verschlüsselt wird, muss der DB Administrator natürlich das Passwort zum Entschlüsseln kennen, aber ob ihm das beim Anzeigen der Daten über irgendeine Datenbankoberfläche hilft, wage ich zu bezweifeln. Wenn softwareseitig verschlüsselt wird, muss jede Software, mit der die Daten angezeigt werden können, die entsprechende Funktionalität zur Entschlüsselung (ggfls. nach Passworteingabe) mitbringen, das ist eher unwahrscheinlich. Wenn man dem DB Administrator die Rechte auf einige Tabellen entzieht, wird sein Arbeit sicherlich eingeschränkt werden. Aber für ein Backup benötigt er nicht auf alle Tabellen Lese ... rechte. Er muss nur das Recht haben, ein Backup und ggfls. ein Restore machen zu dürfen. Dies ist unabhängig von den Rechten auf einzelne Tabellen. Und natürlich: Rechtevergabe durch den DB Administartor scheidet dann aus oder ist nur eingeschränkt möglich. Optimierungen, naja, eher schwierig. Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
https://docs.microsoft.com/de-de/sql...ql-server-2017 |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Es geht einfach gesprochen darum, dass man entweder Datenänderungen durch einen DB Administrator nachvollziehen, d.h. loggen kann. Direkt über den Datenbankserver. Ist dies nicht möglich, darf der DB Administrator keinen direkten Zugriff auf die Daten haben und diese nicht ändern können. Arbeitsverträge, etc. sind an sich eine schöne Sache. Lt. dem Auditor verlangt das Steuerrecht jedoch eine technische Lösung. Keine vertragliche. Es sollen auch keine Änderungen möglich sein über Backup + Restore in anderem Datenbankserver und Ändern + Backup + Restore zurück zum richtigen Datenbankserver. Theorie dahinter (Lt. Auditor): Auch wenn sich ein DB Administrator nicht an den Vertrag hält, muss man die Änderung, etc. nachvollziehen können. Ich lasse das jetzt mal so stehen und kommentiere das nicht. :zwinker: Wegen dem technischen Ansatz: Man geht davon aus, dass der Firmenintere Admin selbst den Datenbanksrver installiert, verwaltet und dass es nur einen Admin für alles gibt. Wie in vielen kleinen Firmen üblich. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Bernhard Geyer
Da steht folgender Hinweis: Transparente Datenverschlüsselung und FILESTREAM-Daten FILESTREAM-Daten werden nicht verschlüsselt, auch dann nicht, wenn TDE aktiviert ist. Bei der anderen Methode Allways encrypted sind folgende Hinweise Die Entschlüsselung findet über den Client statt. Das bedeutet, dass einige Aktionen, die nur serverseitig auftreten, nicht funktionieren, wenn Always Encrypted verwendet wird Führen Sie folgende Schritte durch, um die Spalte erfolgreich zu aktualisieren: Wählen Sie über die Anweisung SELECT die Datei aus der SSN-Spalte aus, und speichern Sie diese in einem Resultset in der Anwendung. Dadurch kann die Anwendung (Clienttreiber) die Spalte entschlüsseln. Fügen Sie über INSERT die Daten aus dem Resultset in SQL Server ein. Super bei Massenänderungen, wie z.B. Preisstufen in Artikeln. Alles über das Netzwerk kopieren. Weiters ist auch noch aufgeschrieben. Macht die Arbeit mit einem SQL Server nicht so wirklich sinnig. Aber egal, wenns gefordert wird. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Es geht doch letztlich darum, dass "irgendwer" an der Software vorbei, was in der Datenbank ändert. Man muss also sicherstellen, dass nur mit Hilfe der vorgesehenen Software auf die Datenbank zugegriffen wird und nur mit ihr Änderungen vorgenommen werden. Also muss man sicherstellen, dass mit Hilfe dieser Software alle Arbeiten erledigt werden können, die für die korrekte Arbeit erforderlich sind. Also z. B. auch das Anlegen und / oder Löschen von Datenbankusern ... Dann kann man ggfls. den DB Administrator "aussperren", wenn man softwareseitig für einen adäquaten Ersatz gesorgt hat. Aber das jetzt hier alles aufzuführen dürfte den Sinn der ursprünglichen Fragestellung deutlich überschreiten. Zitat:
Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Datenbankverschlüsselung macht nur dann einen Sinn, wenn das Passwort für die Entschlüsselung nur in der Anwendung vorhanden ist und nicht dem Administrator beim Kunden gegeben wird.
Entsprechende Konfiguration vom Datenbankserver beim Kunden kann man auch vergessen. Es wird nur die Standartinstallation ohne Anpassungen bzw. nachträglichem Aussperren vom Administrator geprüft. Lt. Auditor wird so geprüft, als ob jemand ohne viel Kenntnisse den Datenbankserver installiert und die Anwendung. Dann wird geprüft, ob in dieser Konstellation der DB Administrator an den Testdaten Änderungen machen kann, die nicht protkoliert sind und man den vorherigen Informationsstand wiederherstellen kann. Wäre letztes nicht Prüfungsobjekt, würde ich einfach alle Datensätze signieren und Aus die Maus. Reicht aber lt. Vorgaben nicht mehr aus, weil man muss ja nachvollziehen können, was vor der Änderung in der Zeile stand. Was alles im Bezug auf Datenbanken einzuhalten ist, wurde mir von einem der Auditoren als zweiseitiges Dokument vorgelegt. Rechtsvorgaben wurden aufgeführt, jedoch nicht mitgegeben, da dies einiges mehr an Text ist. Kurz zusammengefasst: siehe meine Ursprungsfrage. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Ich denke der Großteil der MS SQL-Server-Datenbanken nutzt keine FILESTREAMs Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Na toll.
Jetzt macht es für mich auch mehr Sinn, warum beim Audit das auch für die Warenwirtschaft gefordert wird. Rechnungen, Lagerbewegungen, etc. Alles Daten, die irgendwie was mit Steuern zu tun haben. Das dürfte noch lustig werden. Ich sollte eigentlich denen nur eine Software für die Kalkulation und Kalkulationsvergleiche erstellen, da dies im Moment noch schön einzeln in Excel Tabellen vorgenommen wird. Mal sehen, ob das auch im Audit bei denen Bemängelt wird. Gibt es für das Urteil ein Aktenzeichen? Würde mal gerne nachlesen, was da so vom Gutachter ausgesprochen wurde. Dann kann man sich eher darauf einstellen, was notwendig wird. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Da ich glaube, das das Thema mittlerweile doch eher von der Verschlüsselung weggeht und mehr in Richtung Transaktionslog .
mal ein Beispiel aus der Praxis was wir da machen 1. In jeder Tabelle werden für alle Schreibvorgänge redo und undo sqls per trigger erzeugt und in einer selbsterstellten Transaktionslog gespeichert -wenn es auf einer Tabelle einen Insert gab, dann wird genau dieser insert nur mit den eingefügten werten als redo sql gespeichert und der passende delete als undo -wenn es auf einer Tabelle einen delete gab, dann wird genau dieser delete als redo sql gespeichert und der passende insert mit den letzten Werten als undo -wenn es auf einer Tabelle einen update gab, dann wird genau dieser update mit den neuen Werten als redo sql gespeichert und der update mit den vorherigen Werten als undo -In Firebird lassen sich sclhe Trigger relativ einfach automatisiert erzeugen, wenn man mal das Prinzip verstanden hat und die new. und old. variablen liefern alles was man braucht -zusätzlich steht im Transaktionslog ein zeitstempel, der datenbankuser, der das gemacht hat und seine Transaktions ID und ebenso seine Connection ID 2. Damit die Trigger, die in der gleich Transaktion laufen, zeitnah weggeschrieben werden können, landen die alle zunächst mal in einer Transaktionslogtabelle in der Produktions DB 3. Damit diese Transaktionslogtabelle aber nicht die Produktionsdatenbank übertrieben aufbläht, werden die Transaktionslog Datensätze in einem eigenen serverbasierenden batch per execute statement on external in einer zweite Datenbank übertragen und danach in der Produktions DB gelöscht. Auch das ist transaktionssicher. 4. Für diese Transaktionslog DB kann du eine eigene Firebird Instanz auf einem anderen Server benutzen und der aus der ProduktionsDB schreibende User darf nur inserts, alles andere wird ihm verboten 5. Wenn du willst kann du in bestimmmten Zeiträumen die Transaktionslog DB umbenennen, zB LOG2018.fdb, LOG2017.fdb usw. und diese DBs dann als Readonly DB betreiben 6. Da im Transaktionlog neben den o.a. Daten auch Tabellenname und Primärschlüsselfeld in indizierten Feldern gespeichert werden, ist es exterm einfach, darüber alle SQLs zu finden, die zB die Rechnung mit PK 123 betroffen hat, auch wenn es diesen Datensatz aufgrund eines Deletes gar nicht mehr gibt (auch dieser delete mit daten wer das wann von wo gemacht hat steht im Log) 7. In der Realität hat diese Transaktionslog DB mit Daten eine mittelständischen Produktionsbetriebs (60 MA) in 7 Jahren ca 600GB erreicht, es ist aber ausnahmslos jeder vorhandene Datensatz protokolliert. 8. durch die Undo SQLs konnten wir auch schon versehentlich gelöschte Datensätze mit sehr vielen abhängigen Daten durch ausruf einer simplen Prozedur rückgängig machen, diese Prozedur braucht nur Datum, connection ID und Transaktions ID und hat zu dieser Transaktion alle Befehle im Undo in umgekehrter Reihenfolge wieder ausgeführt. 9. Die Frage ist also, ob dein Kunde durch eine Datenbankverschlüsselung irgendwelche Vorteile im Falle einer Prüfung hat oder ob er auf basis der geschilderten Informationssammlung in den Transaktionslogs jede noch so abstruse Frage innerhalb kurzer Zeit beantwortet bekommen kann. 10. Es hindert dich keiner daran, die daten in der externe Transaktionslog DB, die dort eingeführt werden, zusammen mit der Vorgänger Transaktionlogeintrag gemeinsam zu verschlüsseln und damit nichts anderes als eine sinnvolle Implementation einer Blockchain aufzubauen (falls ein vorgänger manipuliert würde, werden dieser und der Nachfolger einen anderen Verschlüsselungswert bekommen und dadurch ist der Zeitpunkt einer Manipulation im Transaktionslog nachvollziehbar, aber: Wenn der Inhaber des unternehmen mit dem Admin gemeinsam was verstecken will, dann geht das auch auf diesem Weg, ist aber wesentlich aufwändiger. 11. Die von dir geschilderten Urteile basieren ziemlich sicher auf einer Gastronomiesoftware, weil dort aufgrund des sehr hohen Anteils an Bareinnahmen ein ganz wichtiger Punkt der Kontrollierbarkeit fehlt. Derartige Entscheidungen haben nichts generelles mit Godb zu tun, weil es immer noch bewiesen werden muss, das beschissen wurde, glauben hilft den Prüfern da auch nicht. In normalen Handelsunternehmen kann es aber ausreichen, das dem Prüfer aufgrund einer anderen Prüfung bei einem Geschäftspartner eine Rechnung vorliegt, die nicht mit den Daten in deiner Wawi übereinstimmt, weil der Sachbearbeiter die nach Versand an den Kunden nicht korrekt per Rechnungskorrektur und Neuerstellung angepasst hat, sondern einfach mit korrigierten Werten übergebügelt hat, der Geschäftspartner aber ncoh die alte Version in seinen Dokumenten hat. Wenn deine Software dann die Veränderungen aufgezeichnet hat bist du auf jeden Fall außen vor, ob der Kunde die dann falsch bedient hat oder bewusst damit bescheissen wollte, ist dann nicht dein Problem. Wer aber mal mit einem Prüfer über ein Fahrtenbuch diskutiert hat, der weiß, wie schnell eine ganz banale Information aus den Daten dem Rest widerspricht (Beispiel: Laut Fahrtenbuch um 8 Uhr morgens zuhause losgefahren, aber um 9 Uhr in 300 km Entfernung getankt). Das du da evtl. die falsche Uhrzeit erfasst hast , weil deine Uhr falsch ging ist dem Prüfer egal, nach so was sucht er und dann gibt es nachträglich die 1% Regelung reingedrückt. Und auch in anderen Bereichen sind die Prüfer echt clever und suchen halt nach Mustern, die erfolg Versprechen, um Steuern nachzufordern. ich merke aber, ich schweife ab, zurück zum Thema: Wenn dein Kunde nicht gerade eine Kneipe hat und sehr viele Bareinnahmen, dann treffen viele Faktoren aus allgemeinen Urteilen zu dem Thema gar nicht auf Ihn zu. Trotzdem hilft es dir als Softwarehersteller, die Fähigkeiten deiner Software generell schon drin zu haben, alles nachvollziehen zu können, was da in der Datenbank drin ist. Eine simple Verschlüsselung der Datenbank oder der Tabellen bringt dafür gar nix, in gelöschter Datensatz in einer verschlüsselten DB ist immer noch weg und seine existenz kann auch nicht nachvollzogen werden, wenn der Admin mit im Boot ist. Verschlüsselung bringt etwas, um zum Beispiel es deinem Außendienstler, der den kompletten Kundenstamm auf seinem Laptop dabei hat, schwerer zu machen, das er sich zusammen mit diesen Daten bei einem Mitbewerber um eine Stelle zu bewerben. Das o.a. Beispiel läuft in anderen Prodjekten auch mit 2,5 Millionen Logeinträgen pro tag, die auf 160 Servern deutschlandweit erstellt werden und an 10 Server weiterverteilt werden müssen. Das setzt aber eine brauchbare für Firebird geeignete Hardware voraus, ist aber mit so eine Open Source Datenbank problemlos machbar, wenn man den richtigen fragt, wie es geht. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Hört sich interessant an.
Kann vermieden werden, dass ein DB Administrator den Trigger zeitweise deaktiviert oder löscht? Anderen Server, weil das Transaktionsprotokoll gross wird dürfte kein Problem sein. Im Bereich von Hardwareresourcen ist der sehr spendabel. Firebird hatte ich bisher nicht auf dem Radar. Ich hatte nur mal vor Jahren eine Anwendung als Demo gesehen, wo die fdb automatisch in viele kleine fdb Dateien aufgeteilt wurde. Sollte das Backup vereinfachen. Ist das Standart oder eine Eigenkreation? Gibt es bei Firebird eine gute Dokumentation zum runterladen oder eine Buchempfehlung? Wenn wir schon beim "Abschweifen" sind: Wie gut kann Firebird mit Blob Feldern umgehen? Gibt es da Geschwindigkeitsprobleme, wenn viele Blob Daten vorhanden sind? So ca. 80 % Datenbankanteil. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Trotzdem haben wir für Kunden auch spezielle Firebird Versionen erstellt, die das Abschalten der Datenbanktrigger deaktiviert, der Kunde mißtraute dabei nur einem ehemaligen Mitarbeiter, der sich mit einer Software in der selben Branche selbstständig gemacht hat und mit seinem InsiderknowHow fleissig Bestandskunden abgeworben hat und bis zu diesem Zeitpunkt beim Datenimport keine Restriktionen hatte. Dort wird aber demnächst die Database Encryption eingeführt, dann kann er das eh vergessen. Zitat:
Zitat:
Zitat:
Trotzdem sind die Sachen von Helen Borrie lesenswert, auch wenn die in erster Linie FB25 fokussieren, über die Releasenotes PDF in jeder Version kommt man schnell in das rein, was neu und wichtig ist https://www.ibphoenix.com/products/books/firebird_bookhttps://firebirdsql.org/en/books/Außerdem sind hier auch Referenz Dokus und Quickstart Guides https://firebirdsql.org/en/reference-manuals/Zitat:
http://blog.plasticscm.com/2008/09/f...ystem-for.htmlWie toll das Filesystem insbesondere unter Windows ist: Leg einfach mal 10 Millionen Datensätze in einem ordner an und versuche dann mit Bordmitteln wie explorer.exe eine davon zu löschen, viel spaß dabei für die nächsten Tage Wartezeit ... ;-) Das Erstellen eigener Tabellen für Blobs wie von Markus empfohlen machen wir immer so, wenn es sich dabei um zB Bilder und PDFs handelt, Memos oder kleinerer Kram aber eher nicht, weil Firebird kleinere Blobs inhalte anders speichert. Ein Referenzkunde (sehr großes Patentanwaltsbüro) speichert ca 2TB als PDFs in einer Datenbank. Die größte DB, von der ich vonanderen Kunden gehört habe, kommt aus dem Medizinumfeld und soll 15TB sein. Mit ganz simple Techniken (abruf der pdf Inhalte nicht direkt per select auf Tabelle, sondern immer per Stored Proc) kannst du mit eingebauten Techniken die PDFs ähnlich wie das oben erwähnte Transaktionslog jahreweise in eigene Readonly Datenbanken auslagern und deinen AbrufSP sucht passend zu den Metadaten des Datensatzes dann die passende DB raus. Damit haben wir bei dem oben genannten Kunden ca 2 Millionen odfs im ca 500GB Datenbanken abgelegt, brauchen beim täglichen Backup aber nur ca 20GB sichern und nicht 500GB, weil davon ca 490GB monatsweise ausgelagert sind. Diese PDF Archivdatenbanken können auch wieder ausgeagert sein, Kopien in der Cloub haben, bei High End Userzahlen auf replizierten Servern liegen etc. Im Oktober ist in Berlin eine Firebird Konferenz, da sind wir auch wieder dabei, wenn Leute vorher Lust auf eine öffentliche Schulung zu der Thematik haben, meldet euch einfach bei mir oder über info@ibexpert.de mit dem Betreff "Interesse öffentliche Firebird Schulung", ggf. koordinieren wir dann wieder mal eine Schulung zu dem Thema, gerne auch z.b. in Frankfurt, was für die meisten ja ganz gut erreichbar sein sollte. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Urteil ging es um eine Kassensoftware in Access. Da ist die Manipulationshürde gar nicht mal so hoch. Von Kommentatoren wird das Urteil aber allgemein so verstanden, dass die Datenbank egal ist. Und dass nicht nur Kassen betroffen sind. Das hat vermutlich der erwähnte Auditor so verstanden.-- P.S.: Eine vollverschlüsselte Firebird-Kassendatenbank kann man aber auch überlisten: morgens den Server anhalten, eine Kopie ziehen, dann kommt die Hochzeitsgesellschaft und den ganzen Vormittag wird kassiert. Z-Bon drucken, die Datenbank zurückspielen und das Geld in die Tasche stecken :) |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Hab den Thread überflogen. Worum geht es am Ende? Verschlüsselung wegen Geheimniswahrung oder Nachvollziehbarkeit?
Verschlüsselungsprobleme und Folgeeffekte (Nutzungseinschränkung) gibt es natürlich, wenn man jeder Spalte verschlüsselt. Das ist selbst bei Geheimniswahrung aber nicht notwendig. Es gibt idR. ein Modell und Nutzdaten, letztere müssen wahrscheinlich auch nur teilweise verschlüsselt werden. Wenn es "nur" um Nachvollziehbarkeit geht, müsste eine einzige Spalte diese garantieren (bzw. ein einziger Mechanismus, transaktionsbasiert, wie hier auch schon beschrieben), z.B. durch eine Signatur mit Zertifikat. Hab das praktisch noch nicht gemacht, aber es müsste einen Appserver geben, der "als letzter" einen Datensatz signiert. Dabei müsste er einen Rückgabewert über diesen Vorgang erhalten, den er bei der nächsten Signatur mit dem Vorgängersatz vergleicht, um Backup Hacks zu unterbinden. Referentielle Integrität und Constraints allgemein sind ja Grundfunktionen von ACID Datenbanken und bilden die beste Ausgangsbasis für solche Mechanismen. Ansonsten gibt es auch fertig Software wie schon angeklungen. Oracle bietet diverse Sachen an, z.B. Audit Vault, das gleich die Analyse der Audits mitliefert. Wahrscheinlich gibt es das auch kleinteiliger ohne das Endprodukt. Und ja, es kostet, weiß nicht, was diese Punkte immer sollen. Oder arbeitet hier jemand umsonst für seine Kunden? Spätestens für nicht triviale Anforderungen muss ein Kunde am Ende vielleicht etwas tiefer in die Tasche greifen. Die Problematik des Aufwands für eine "wasserdichte" Lösung wurde ja bereits angesprochen. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Wer übrigens kein Bock auf Steuerbescheisser in der Gastronomie hat, ganz einfacher Tip: niemals bar, immer nach Beleg fragen und per karte zahlen, dann wird es schwierig, für den Gastronomen die Einnahmen vor der Steuer zu verstecken. p.s.: Und wenn der Wirt dann behauptet, das sein Kartenlesegerät leider gerade jetzt nicht funktioniert, dann sagen, das man kein Bargeld hat, aber den Betrag auch gerne überweisen kann. Man glaubt gar nicht wie viele Kartenlesegeräte sich danach wieder ganz spontan selbst geheilt haben ... |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
ich mach das mittlerweile fast immer so, das große Inhalte wie pdf, jpg, png usw. in einer extra Tabelle sind und diese Inhalte sich eben auf verschiedene Datenbanken oder sogar Serverinstanzen verteilen, weil Terabyte DB immer normaler wird mit solchen Inhalten und das am Ende das zentrale Handling dadurch vereinfacht wird, wenn das nicht auf dutzenden Tabellen verteilt ist |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Danke schon einmal Tanja. |
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Die SP entschiedet im Hintergrund (anhand z.B. dem Datum) in welche Datenbank die Daten gespeichert bzw. aus welcher dieser geladen werden. Die eigentliche Anwendung muss so nur die Hauptdatenbank kennen.
|
AW: Datenbank mit Tabellenverschlüsselung benötigt.
Zitat:
Dateien rein und raus: mit IBExpert Scripting relativ simpel https://www.ibexpert.net/ibe/pmwiki....aIntoADatabasemit Delphi/Lazarus aber auch wenn man beim insert den parameter mit TBlobParam(qry.params[0]).loadfromfile füllt, geht je nach Komponente leicht anders, sollte aber schon mal helfen weiterzukommen ein wenig code zu einer möglichen sp, die dann jahresweise auf unterschiedliche firebird aliaseinträge gehen würde
Code:
create or alter procedure BRPGETDATEIX (
IDX bigint) returns ( ID bigint, TXT varchar(80), DATEI blob sub_type 0 segment size 80, TS timestamp) as declare variable jj integer; begin select datei.txt, datei.ts, datei.datei from datei where datei.id=:idx into :txt, :ts, :datei; jj=extract(year from ts); if (datei is null) then execute statement ('select datei from datei where id=:id') (ID:=IDX) on external 'brp'||jj as user 'SYSDBA' password '.....' into datei; if (datei is null) then execute statement ('select datei from datei where id=:id') (ID:=IDX) on external '1.2.3.4/3050:brp'||jj --wenn auf der lokalen instanz auch nix in datei ist, dann ggf extern nachschauen, zB auch in der cloud as user 'SYSDBA' password '.....' into datei; id=idx; suspend; when any do begin end --exception error '#BRPMSG#BRPDAT bzw BRPDATX nicht definiert oder nicht erreichbar#BRPEND#'; end |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 01:42 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz