Protection de la BD Firebird

[saidus]

Bonjour !!
j'ai creer une ptite application avec C++Builder qui Commande une base de donnee Firebird .. le Probleme est que la majorite des traitement que j'ai fais sont sur la base (Procedure et trigger ) .. ya il un moyen d'interdir pour les gens de l'exterieur de dumper (d'explorer ) ma base a l'aide d'un outil qlqnk (ibExpert ou autre )(Protection par mot de passe ...)
MERCI

[sillycoder]

La solution serait :
- n'utilise pas les login et mots de passe par défaut pour l'administrateur
- utilise la gestion des utilisateurs qui te permettra de réduire les droits pour ces utilisateurs car après tu pourras restreindre leurs possibilités et ne les activer que si nécessaire avec les
GRANT tels que GRANT SELECT,UPDATE ou GRANT EXECUTE par exemple

[jean-jacques varvenne]

il est totalement impossible de protéger le contenu de la base de données si le client à la base de données sur sa machine.

même les mots de passe et autre ne servent à rien à partir du moment ou le fichier "gdb" ou "fdb" est accessible à l'utilisateur.

maintenant, de fait, si le client n'a aucun accès direct, oui, les mots de passes et la gestion des droits utilisateurs sont sûrs.

ils existent des possibilités, mais cela est complexe et comme tout est accessible, avec du temps, il est toujours possible de casser toutes les protections.

le mieux est donc de tout programmer en C, mais cela peut dans certain cas ralentir considérablement les traitements et augmenter fortement le trafic réseaux.

sinon, un "serveur" séparé, sans clavier, moniteur, port usb, etc... tiendrait au mieux 10 minutes face à un "bricoleur" averti, mais tiendrait des années face à un utilisateur lambda, puisque la base elle même n'est pas sur sa machine et il n'y aurait accès que par réseaux, lui interdissant donc (faut bien sûr préparer la machine, en linux de préférence) un accès direct au fichier de la base de données et surtout au fichier de sécurité qui enregistrent les mots de passes et autres.

en résumé, c'est couteux en temps et en argent pour un résultat somme toute très mitigé.

[pascal_legrand]

Si le besoin est de masquer le code source, il me semble qu'il est possible de faire un update sur le champ RDB$PROCEDURE_SOURCE de la table RDB$PROCEDURES car c'est le champ RDB$PROCEDURE_BLR qui contient le code compilé (idem pour RDB$TRIGGERS)

Cette méthode est naturellement non supportée et devrait être précédée par des tests intensifs à tous les niveaux (backup, restaure, ddl, dml, ...) avant même d'y penser

Slts
PAscal

[_skip]

D'après ce que j ai lu à ce sujet, le mieux qu'on puisse faire est de créer un ROLE SYSDBA avec aucun accès.
Mais ça bloquera tout juste un petit curieux car c'est très simple à contourner