Discussion :

[khouja]

Bonjour,

Je développe une application qui utilise une base de données MySql.
Je vais la deployer chez un client, mais je veux pas qu'il puisse connaitre le nombre de tables ni leurs noms (ce qui est possible si tu vois dans C:\Program Files\MySQL\MySQL Server 5.0\data\MaBase).

Encore pire, tu peux voir meme la syntaxe SQL des vues en ouvrant les fichiers C:\Program Files\MySQL\MySQL Server 5.0\data\MaBase\arc\vue1

Y a t il une solution pour :
- soit crypter les noms et le contenus des tables et des vues
- soit rendre la base dans un seul fichier comme Sql Server ou Access

Merci

[mydb_server]

Si je comprends bien, tes tables sont créées avec comme moteur de stockage MyISAM. Si tu n'as pas de contrainte particulière concernant le moteur de stockage de tes tables, tu pourras les créer avec, par exemple, comme moteur de stockage en InnoDB, et ton problème sera résolu.

[qi130]

Si tu n'as pas de contrainte particulière concernant le moteur de stockage de tes tables, tu pourras les créer avec, par exemple, comme moteur de stockage en InnoDB, et ton problème sera résolu.

Cette solution ne résoud absolument rien ! Outre le fait que le nom des tables est celui des fichiers FRM, InnoDB induit des contraintes (pas de full-text search par exemple).

De plus, depuis la version 5 de MySQL, le SGBD dispose et met à disposition des tables système qui contiennent les noms des bases, tables, colonnes, etc...

En définitive, le problème exposé demeure entier, sans que j'en comprenne l'utilité

[mydb_server]

Je sais bien que cette solution ne résout pas tout le problème, mais permet au moins de répondre à une partie du besoin de khouja.

[Sivrît]

En gros, avec MySQL ce n'est pas possible, car quel que soit le moteur, la définition des tables est toujours dans un fichier à son nom. Ce qu'il y aurait peut-être de mieux à faire, ce serait de ne pas utiliser un serveur MySQL pleinement installé, mais plutôt un serveur embarqué dans l'application que cette dernière démarrerait directement (pas en tant que service), et avec ses fichiers de données dans les répertoires de l'application elle-même. Ça ferait un bon compromis.

Au delà de ça, tout avoir dans un unique fichier n'aidera pas vraiment en terme de confidentialité, et ce même pour une autre base que MySQL. Un SGBDR n'est pas fait pour protéger d'un utilisateur ayant un accès à la machine en local avec les pleins pouvoirs. De ce point de vue là, le problème est insoluble, comme celui des systèmes de protection des jeux vidéos, de la copie des fichiers musicaux, etc. La question est plutôt de savoir à quel point on est prêt à se compliquer la vie pour compliquer celle de l'attaquant (qui est aussi, ne le perdons pas de vue, l'utilisateur), et combien ça coute.


Éventuellement, pourquoi ne pas se tourner plutôt vers SQLite ? Avec peut-être la possibilité de chiffrer son fichier. Où de le modifier pour qu'il le fasse.

Sinon, utiliser MySQL proxy (ou directement des fonctions dans le code) pour obfusquer les noms des tables et des colonnes, et peut-être chiffrer leur contenu. Et tant qu'à faire ajouter des tables inutiles pour masquer leur nombre réel...
Je crois que pour avoir oser proposer quelque chose comme ça je mérite un

Bref, est-ce que ça en vaut vraiment la peine, dans la mesure où ces solutions ne sont pas pour autant à toute épreuve ?