Discussion :

[Skylle]

Bonjour à tous ,

Voilà je viens de créer un programme et je voudrais savoir comment je peut protéger les identifiant de ma connexion à la base de donnée en cas de décompilation , car un utilisateur mal intentionné pourra se connecté à ma base de donnée .

L'utilisateur s'inscrit sur le site et télécharge le programme et rentre ses id un peu comme skype .

Voilà merci !

[tomlev]

Tu ne peux pas les protéger complètement. Même si tu les chiffres, il faudra les déchiffrer pour les utiliser, et si ton application peut les déchiffrer, un utilisateur de la machine avec les compétences nécessaires le pourra aussi, c'est inévitable. La protection de la base de données ne peut pas reposer uniquement sur le client, car il est impossible de sécuriser complètement le client.

Il faut donc sécuriser au niveau de la BdD elle-même. Si le client a accès directement à la base, tu peux configurer le compte utilisé pour qu'il n'ait que les permissions strictement nécessaires au fonctionnement du client. Eventuellement, plutôt que de faire des requêtes directement, passe par des procédures stockées, et configure les permissions du client pour qu'il ne puisse rien faire d'autre qu'appeler ces procédures stockées.

Sinon, la meilleure option consiste sans doute à créer un service web (avec WCF par exemple) qui accède à la BDD, et le client passe par ce service web au lieu de se connecter directement à la BDD.

[Skylle]

Sinon, la meilleure option consiste sans doute à créer un service web (avec WCF par exemple) qui accède à la BDD, et le client passe par ce service web au lieu de se connecter directement à la BDD.

Je suis partant pour cette option là mais est ce tu pourrais développer un peu plus s'il te plaît et quelqu’un d'autre d'ailleurs .

Merci

[tomlev]

Je suis partant pour cette option là mais est ce tu pourrais développer un peu plus s'il te plaît et quelqu’un d'autre d'ailleurs .

Bah en gros tu as un service, c'est à dire une sorte de programme qui s'exécute sur un serveur, qui répond à des requêtes (HTTP en général) envoyées par le client, et qui s'occupe d'aller chercher ou modifier les données dans la DB. De cette façon le client n'accède pas à la DB et ne peut donc pas faire d'opération "interdites". Tu peux faire ça avec WCF (il y a quelques tutos sur Developpez) ou ASP.NET Web API

Je ne peux pas t'en dire beaucoup plus, cherche des tutos sur le net

[Kropernic]

Bonjour,

Je me permets d'intervenir car j'essaie également de me renseigner plus en détail sur ce sujet.

Personnellement, développant uniquement des programmes internes pour l'entreprise où je bosse, j'utilise l'authentification de windows pour connecter les utilisateurs à la DB et ils ont uniquement le droit d'exécuter certaines procédures stockées.
Concrètement, à chaque application correspond un groupe Active Directory (AD) et à chaque groupe AD correspond un login SQL (et le user qui va avec). De cette manière, je suis certain qu'il n'y a pas de problème.

Mais j'aimerais mieux comprendre cette histoire de webservice. En gros, on a donc un programme intermédiaire qui sert de messager entre l'application client et la DB. Mais ça ne fait que reporter les problèmes de sécurité sur le webservice non ? Là aussi quelqu'un de malintentionné pourra j'imagine tenter des attaques sur la DB non ?

Ce que je veux dire, c'est que, peu importe qu'on passe par un webservice ou non, si on fait par exemple des requêtes "en direct" en concaténant le code sql, la DB sera vulnérable aux injections SQL.

D'où la question par rapport à l'affirmation de Tomlev :

Sinon, la meilleure option consiste sans doute à créer un service web (avec WCF par exemple) qui accède à la BDD, et le client passe par ce service web au lieu de se connecter directement à la BDD.

Est-ce vraiment la meilleure option ou juste une mode du moment ? En quoi est-ce préférable au fait d'accéder directement à la DB en gérant les droits pour ne pouvoir exécuter que les procédures stockées appropriées ?

[tomlev]

Mais j'aimerais mieux comprendre cette histoire de webservice. En gros, on a donc un programme intermédiaire qui sert de messager entre l'application client et la DB. Mais ça ne fait que reporter les problèmes de sécurité sur le webservice non ? Là aussi quelqu'un de malintentionné pourra j'imagine tenter des attaques sur la DB non ?

Bah pour commencer il ne pourra pas atteindre directement la DB, donc il ne pourra pas faire des choses qui n'étaient pas prévues dans le WebService. De ce point de vue, ce n'est ni mieux ni moins bien que de donner des permissions seulement sur certaines procédures stockées.

Ce que je veux dire, c'est que, peu importe qu'on passe par un webservice ou non, si on fait par exemple des requêtes "en direct" en concaténant le code sql, la DB sera vulnérable aux injections SQL.

Non, tu n'as pas compris ce que je voulais dire ; il n'est pas question de passer une requête SQL au service web. Tu lui demandes par exemple de te renvoyer les données d'un client ou d'ajouter un produit au catalogue (sous n'importe quelle forme, mais typiquement en XML ou JSON), et c'est le service qui sait comment répondre à cette demande, et qui s'occupe de faire des requêtes sur la DB. Le client n'a même pas à connaitre la structure de la DB.

Est-ce vraiment la meilleure option ou juste une mode du moment ? En quoi est-ce préférable au fait d'accéder directement à la DB en gérant les droits pour ne pouvoir exécuter que les procédures stockées appropriées ?

En plus de la sécurité (mais comme tu l'as justement fait remarquer, on peut obtenir à peu près la même sécurité avec des PS), ça a surtout comme grand intérêt que les clients ne savent pas comment les données sont stockées. Tu vas me dire : et alors ?

Eh bien, supposons que tu as 15 applications clientes différentes qui se connectent directement à la base de données en faisant des requêtes SQL. Un beau jour, tu décides de faire une petite modification du schéma de données de la DB. Résultat, tu as 15 applications à modifier, et à déployer en coordination avec le déploiement de la modif sur le serveur; bref, beaucoup de boulot pour juste une petite modif...

Alors que si les clients passaient par un service, tu aurais juste à modifier le service, la modification serait transparente du point de vue des clients.

Donc en résumé, l'intérêt est de masquer au client les détails de l'implémentation du serveur. C'est un peu comme l'encapsulation en POO, mais reporté au niveau de l'infrastructure...