Was fehlt euch in Firebird?

[colaflasche]

was ist dieses Feature?
- Column-Based-Encryption

Habe eine Vorstellung, aber kannst du das kurz erläutern?

Man kann eine einzelne Spalte in einer Tabelle verschlüsseln, oder mehrere.
So kann man z.B. die Konto-Nr. verschlüsseln und nur, wenn man den Schlüssel hat, kann man sie entschlüsseln.
Man kann dabei aber auch einen Vorgabewert vergeben, was ein User sehen soll, der den Schlüssel nicht besitzt.
So kann man zumindest die Daten zumindest selektieren, ohne Mecker zu bekommen und man sieht die Spalten, die man sehen darf:

create table table-name (column-name data-type encrypt [[with] key_name] [decrypt default value], …)

Gibt man keinen Default an, würde eine SQL-Abfrage einen Fehler ausgeben, wenn man eine Spalte selektiert, für die man keinen Key hat.


@bfuerchau:
Sehr ausführliche und gute Ausführung! Das ist mir bewusst, daher gehe ich auch den Weg, den Du beschrieben hast. Aber jedes mal, wenn ich das mache denke ich mir "Das wäre schön, wenn der das selbst regeln könnte". Daher habe ich das mal mit aufgeführt.
Ich sehe ja auch die Vorteile im aktuellen Verfahren. Wenn man z.B. in seiner CTE eine Stored Procedure selektiert und damit Daten manipuliert kann es ja auch gewünscht sein, dass die immer wieder ausgeführt wird.

[martin.koeditz]

Hi colaflasche,

Man kann eine einzelne Spalte in einer Tabelle verschlüsseln, oder mehrere.
So kann man z.B. die Konto-Nr. verschlüsseln und nur, wenn man den Schlüssel hat, kann man sie entschlüsseln.
Man kann dabei aber auch einen Vorgabewert vergeben, was ein User sehen soll, der den Schlüssel nicht besitzt.
So kann man zumindest die Daten zumindest selektieren, ohne Mecker zu bekommen und man sieht die Spalten, die man sehen darf:

create table table-name (column-name data-type encrypt [[with] key_name] [decrypt default value], …)

Gibt man keinen Default an, würde eine SQL-Abfrage einen Fehler ausgeben, wenn man eine Spalte selektiert, für die man keinen Key hat.

Das ist auf jeden Fall interessant und würde mir ebenfalls an diversen Stellen weiterhelfen. Vielleicht kommt das ja, wenn man nett bittet...

Dank und Gruß
Martin

[bfuerchau]

Ich habe bereits mit FB 2.1 wichtige Daten mit den Standard-Encryption-Verfahren verschlüsselt, die mittels Windows-API zur Verfügung stehen.
Häufig sind dies XML-Konfigurationen, die ich in einem BLOB komprimiert und verschlüsselt abgelegt habe.
Ich sehe da ein Problem von verschlüsselten Daten bei der Indexsuche, da ja wohl im Prinzip erst verschlüsselt und dann gesucht werden kann. Wie verhält sichdas dann zu Like und Similar-Suchen oder Collation-Zugriffen (z.B. caseinsensitiv)?

Die o.g. Beiträge verdeutlichen doch sehr, dass es den Schutz generell nicht gibt, da ich eben auch durch Angriffe auf den Frontend, der die Daten ja im Klartext anzeigen muss, durchaus Massendaten abziehen kann.
Oder glaubt ihr, bei den ganzen Datendiebstählen der letzten Zeit hat sich jemand ins Office bemüht um die Daten zu klauen?
Nein, das sind i.W. die Frontends der User die dem Zugriff letztendlich Tür und Tor öffnen.

Hier kann man nur in der Anwendung Verhaltensauffälligkeiten prüfen.
Wird eine Anwendungsabfrage eines Users in sehr kurzer Zeit auffällig oft wiederholt?
Wobei das ja auch nicht sicher ist, da Automatismen eben das User-Verhalten (Tippgeschwindigkeit) emulieren können.

[colaflasche]

Ich sehe da ein Problem von verschlüsselten Daten bei der Indexsuche, da ja wohl im Prinzip erst verschlüsselt und dann gesucht werden kann. Wie verhält sichdas dann zu Like und Similar-Suchen oder Collation-Zugriffen (z.B. caseinsensitiv)?

ich habe es noch nicht selbst verwendet, weil wir ausschließlich den Firbird einsetzen, von daher kann ich wenig dazu sagen.
Ich war aber mal auf einer Roadshow von Embacadero, wo das Feature vorgestellt wurde. Das hat Begehrlichkeiten geweckt.

Aus der Doku vom Interbase:
Note: When working with encrypted columns, the MIN, MAX, BETWEEN, and ORDER BY operations cannot use an index based on those fields due to the nature of the index key that is formed from the encrypted field value. So while the index is not useful for the above operations, it is still useful for equality matches and JOIN operations

Das ist jetzt auch nicht so das Killerfeature, wofür ich meinen Firebird hergeben würde, aber wenn ich drei wünsche Frei hätte, wäre das einer davon.

Aktuell verschlüsseln wir auch die daten und schreiben sie in einen Blob, aber sie müssen jedes mal runtergeladen werden und dann da verarbeitet werden. Das wäre schöner, das in der gewohnten SQL-Sprache zu machen.

[colaflasche]

Das ist auf jeden Fall interessant und würde mir ebenfalls an diversen Stellen weiterhelfen. Vielleicht kommt das ja, wenn man nett bittet...

Dann vote mal :

http://tracker.firebirdsql.org/browse/CORE-6459


Wo bfuerchau eben "similar to" erwähnte, PCRE wünsche ich mir auch noch .

[bfuerchau]

Was ist PCRE mal ausgesprochen?

BI-Analysen leben von Inidizes. Meine Abfrageanalysen bilden zur Laufzeit die fraglichen Indizes, was dann tatsächlich eine Verschlüsselung ausschließt.

[Gerd]

Was ist PCRE mal ausgesprochen? ...

+1


Viele Grüße
Gerd

[bfuerchau]

Ich glaube, dafür bin ich zu blöd.

Noch ein Nachtrag zu obiger Verschlüsselung:
Welchen Sinn hat denn die Verschlüsselung wenn ich dann auch andere Vergleiche wie >, <, >=, <=, <> oder between nicht per Index optimieren kann?

[martin.koeditz]

Noch ein Nachtrag zu obiger Verschlüsselung:
Welchen Sinn hat denn die Verschlüsselung wenn ich dann auch andere Vergleiche wie >, <, >=, <=, <> oder between nicht per Index optimieren kann?

Ob es wirklich keine Lösung dafür gibt, weiß ich nicht. Aber verschlüsselte Daten muss ich nicht unbedingt vergleichen können. Mir geht es viel mehr um praktische Anwendungen z.B. im Bezug auf die DSGVO. Ein Geburtsdatum oder eine Mobilfunknummer könnte ich so "verstecken" und nur berechtigten Personen zur Ansicht geben. Selbst Administratoren hätten somit keinen Zugriff auf diese Daten. Das kann man bis zur TÜV-Zertifizierung weiterspinnen.

Gruß
Martin

[bfuerchau]

Die meisten Lösungen dieser Art werden auch ohne Verschlüsselung durch die Anwendung bereits über Berechtigungssysteme durchgeführt.
In meiner ERP-Welt gibt es den Begriff des "App-Users".
Dieser User hat die ausschließliche Berechtigung an der Datenbank, alle Objekte der DB sind durch Berechtigungen so geschützt, dass nur der App-User Zugriff hat.
Der normale User merkt davon nichts. Er meldet sich an und bekommt nur das zusehen, was konfigurierbar zugelassen ist.
Dazu Bedarf es eben auch keiner komplizierten Berechtigung auf Objektebene.
Ein Zugriff auf die DB ist ohne die Anwendung ausgeschlossen.

Ich habe es schon erlebt, wenn plötzlich, ohne Kenntnis der Anwendung, an den Berechtigungen der DB-Objekte gedreht wird, dass dann die Anwendung durchaus unverständliche Ergebnisse liefert.
Dazu gehört auch das Verbergen von Informationen durch Berechtigungen.
Ein User benötigt die Daten nicht und sieht sie dadurch auch nicht, aber das gerade ausführende Programm dann doch.

Auch mein des öfteren erwähntes BI-System hat entsprechende Berechtigungen durch zusätzliche Datenfilter (z.B. Mandantentrennung) als auch die Möglichkeit, Spalten direkt auszublenden. Klar ist dann aber auch, dass der Bericht des berechtigten Users A für den nicht berechtigten User B nicht funktioniert, da die benötigte Spalte einfach nicht existiert.

Die DSGVO schreibt keine Verschlüsselung vor, sondern ist nur eine der Möglichen Maßnahmen:
https://dsgvo-gesetz.de/themen/verschluesselung/