Discussion :

[BOMBARDIER]

Bonjour à tous;

je suis en phase de reflexion sur une application qui tourne sous sql server avec VB. ma question est la suivante, pour tous ce sui est developpement sous VB je vais pouvoir générer mon fichier .exe et garder les code sources dans la maison, mais pour sql comment cacher les vues, les procedures les liens entre les tables....
merci d'avance

[Invité]

Quel intérêt ? Cacher la structure rendrait les données inaccessibles....

[BOMBARDIER]

je compte commercialiser le produit.....je ne veux pas communiquer mes codes sources aux clients.

[Invité]

Un MCD n'est pas vraiment un source...
Pour n'importe quel produit commercial, la structure des données est accessible.

Je ne sais pas comment ça se passe au niveau propriété, sûrement documenter le MCD et le mettre sous licence ?

[BOMBARDIER]

ce n'est pas assez je crois, dans la boite où je bosse on un ERP developpé sous sql server, mais on n'a accée qu'aux tables et leurs structures et bien sur pour les utilsateurs aux formulaires de saisie. le reste on ne peut pas visualiser, comment ces editeurs de ce logiciel on procédé alors?

[Invité]

C'est quoi "le reste" ?

[BOMBARDIER]

les PS, les vues, les triggers, le modele relationnel, .... mais je me dis aussi que tous ces elements on du etre codé en VB et que SQL server ne leur a servi que pour creer les tables. Ca peut etre possible comme scénario aussi non?

[Invité]

C'est tout à fait possible, et c'est ce que j'allais vous dire. Mais cela comporte aussi des risques (notamment pour l'intégrité des données). Il faudra assurer au niveau du support. Si quelqu'un touche aux données manuellement, la base a vite fait de partir en carafe...

Il faudra prévoir les interfaces d'administration de l'application (purges, historiques, modif etc...).

[BOMBARDIER]

JE TE REMRCIE
bonne aprème

[WOLO Laurent]

Il est impossible de cacher la structure de vos données avec la version 2000.
Les données seront toujours accessible avec le schema Information_schema qui est assessible depuis master.
Mais une avancée fulgurante a été ateinte avec la 2005.
Je vais inviter rudib,sqlpro et fadace a prendre part a cet discution

[rudib]

Bonjour,

On m'invite, j'arrive

Tu peux tout à fait protéger le code de tes vues, fonctions, procédures en les créant avec le mot-clé WITH ENCRYPTION.
Tu auras plus d'infos dans l'aide en ligne sous CREATE PROCEDURE par exemple.

En 2000 je n'ai pas entendu parler de moyen de décrypter le code, en 2005 on peut passer par une console DAC. Le code devrait toujours passer en mémoire et sera sans doute visible par un débogeur mémoire sur le serveur, mais j'imagine que tu n'en es pas là en terme de paranoïa

Donc garde le code source de tes objets ailleurs...

Si tu es sur 2005, tu peux aussi lire ceci :
http://msdn2.microsoft.com/fr-fr/library/ms187113.aspx

[Fabien Celaia]

C'est aussi possible avec la version 2000, mais cela comporte quelques risques. En fait, il suffit de "vider" la table syscomments. Les objets compilés sont stockés en "binaire" dans sysprocedures, mais le sp_helptext ou les outils de migration qui doivent, parfois, recompiler, utilisent aussi quelques fois la syscomments. Pas de données dans syscomments, pas de code visible.

[rudib]

sysprocedures existe dans SQL Server 6.5. Depuis la version 7 elle a été supprimée. Tout est dans syscomments.

WITH RECOMPILE existe en 2000, donc pas de souci.

[WOLO Laurent]

Et dans ces conditions, si vous videz la table syscomments, vous ne pourrez plus recompiler le code de vos procédures n'est ce pas ?

[rudib]

Si on vide syscomments, il n'y a plus rien... Le plan dexécution dans le cache de procédure peut-être, mais ça ne doit pas être très utile.

[david_chardonnet]

Certains éditeurs de progiciels mettent des noms de tables illisibles pour rendre leur schéma de BD moins évident. Une sorte d'obfuscation des noms. On doit pouvoir faire la même chose avec les noms de procédures stockées.

A mon avis ça demande pas mal d'organisation ou bien le développement d'un petit logiciel de "chiffrement de base de données".

Et je suis d'accord que pour les logiciels de gestion ça pose pas mal de soucis pour le reverse engineering que la concurrence pourrait venir faire.
Personnellement je n'aime pas donner des schémas qui m'ont demandé pas mal d'analyse.

[SQLpro]

pour WITH ENCRYPTION il est possible de trouver sur le net de outils de cracking. En effet à l'époque de cet encryptage la cryptographie informatique était considérée comlme arme de guerre, donc seul des algorithmes basiques pouvaient être utilisé. D'ou la possibilité de décrypter facilement.

De plus WITH ENCRYPTION peut être contourné par l'utilisateur sysserver...

Certains éditeurs (SAGE par exemple) utilisent une colonne de plus dans leur table ayant un checksum des données de la ligne. Le checksum est calculé depuis le client et vérifié dans un trigger. Si correspondance la données est effacée et la commande validée. Dans le cas contraire, la transaction est annulée.

A +

[kashue]

Desole de m'introduire dans le debat. Je suis loin de pouvoir fournir une solution pour le cryptage de la bdd.
Mais franchement le reverse engineering, c'est chiant au possible.
De plus, il y a rien de mieux qu'un client pour vous debusquez un bug.
Comment s'y retrouver pour depanner un client qui hurle au telephone si vous avez modifie, crypte et verouille votre logiciel? Apres cela depend de " l'envergure " de votre logiciel.

[SQLpro]

Sur un plan un peu différent du débat de départ, je conseille à tous mes clients de ne JAMAIS prendre un logiciel si l'éditeur n'est pas capable de présenter un modèle de données au moins physique, voir, si possible, logique.

En effet, si c'est bien l'éditeur qui est propriétaire de la structure de la base de données au titre du droit d'auteur, il n'en reste pas moins vrai que c'est le client qui met ses données dedans. Or il doit pouvoir à tout moment et sans l'aide de l'éditeur, extraire ses propres informations.
Que se passerait-il si l'éditeur faisait faillite ?

Donc, la protection de la base est totalement illusoire et à déconseiller si vous voulez commercialiser votre logiciel.
En revanche un rappel à la Loi, du style : "En vertu de l'article machin de la Loi truc, la copie d'une partie de la structure de la base de données du présent logiciel constitue une atteinte au droit d'auteur punissable de 2000 de prison et du fouet !!!"

A +

[cbleas]

Bonsoir,
je suis entièrement d'accord avec SQLPro car aujourd'hui l'ouverture d'une base de donnée vers l'extérieur est un obligatoire pour l'acheteur. Je pense que votre plus doit se trouver dans votre code VB qui lui doit etre parfaitement protégé (Ce qui n'est en réalite pas vraiment possible.)

Bonne soirée