Abgesehen von der Performance sehe ich persönlich da jetzt kein Problem.
Na, das "Problem" ist, das die Sicherheitsstufe nicht erhöht wird. Die Daten sind zwar verschlüsselt, aber der Verschlüsselungsschlüssel
ist im SELECT-Statement im Klartext sichtbar.
Allerdings könnte man sich da auch perverse Geschichten ausdenken, um das nicht so offensichtlich zu machen. Man könnte z.B. der Crypt-UDF-
DLL über andere Kanäle (SSL) einen Schlüssel übergeben. Aber auch das ist nur ein 'security by obscurity', denn da die UDF meines Wissens nach für jeden Sichtbar ist, könnte ein Angreifer in jedem Fall (sofern ein Feldinhalt im Klartext bekannt ist) den Schlüssel brutfortzen (Achtung! Wechstaben nicht verbuckseln!).
Als Spielerei, und um Kunden zu beeindrucken, sollte das aber allemal reichen. Nebenbei ist es auch halbwegs sicher, also man kann nicht einfach in die Daten reinglotzen.
Eine andere Möglichkeit wäre die Verwendung von virtuellen Tabellen, wenn es sich nicht um allzu große Datenbestände handelt. Ich hab diese Technik mal bei einem Passwort-Manager eingesetzt (da gibt's in der Regel keine Tausende von Einträgen), der mit einer Firebird-Embedded arbeitet:
Du hast in der
DB alles verschlüsselt. Bei Programmstart werden virtuelle Tabellen mit den entschlüsselten Daten angelegt, um die Daten durchsuchen zu können. Bei Programmende werden die Daten der virtuellen Tabelle wieder verschlüsselt und in die ursprünglichen Tabellen zurückgeschrieben, die virtuellen Tabellen werden entfernt. Ein abschließendes Backup und Restore sorgt für eine aufgeräumte Datenbank.
Größere Firmen bzw. die gebräuchlichsten ERP-Systeme verwenden in der Regel sowieso keinen Firebird-Server, soweit ich das überhaupt beurteilen kann. Was mir bislang an Firmen-DBs untergekommen ist, war ausnahmslos nicht verschlüsselt.