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...

[Kropernic]

Je n'ai encore jamais travaillé avec les webservices donc je cherche p-e des problèmes pour rien mais quelqu'un de malveillant et sachant un minimum ce qu'il fait (car on est bien d'accord que c'est une personne lambda qui posera problème) ne pourra-t-il pas "accéder" aux codes du webservice et y récupérer les identifiants de connexion ou que sais-je d'autre qui pourrait l'intéresser ?

L'argument de modification du schéma de DB est intéressant par contre.

A la première lecture, je me suis dit "C'est évident, il a raison !". Puis à y réfléchir, je suis de moins en moins convaincu. En respectant les bonnes pratiques, les modifications du schéma de la DB sont absolument sans conséquence pour les applications clientes. De fait, une application cliente ne devrait jamais effectuer de requêtes (via des PS ou non) directement sur des tables mais sur des vues. Et quand bien même, une règle/convention en DBA est de ne jamais modifier des colonnes avec des données de production. Si modification de schéma il y a, ce sont des colonnes ou des tables qui sont ajoutées. Et cela n'affecte donc pas l'application cliente.

Et personnellement, en tant que DBA, si j'ai un dev qui vient se plaindre parce que j'ai ajouté une colonne et que du coup, ses indexes ne sont plus juste parce qu'il a fait un SELECT * FROM LA_VUE/LA_TABLE, je l'envoi promener ^^.

[tomlev]

Je n'ai encore jamais travaillé avec les webservices donc je cherche p-e des problèmes pour rien mais quelqu'un de malveillant et sachant un minimum ce qu'il fait (car on est bien d'accord que c'est une personne lambda qui posera problème) ne pourra-t-il pas "accéder" aux codes du webservice et y récupérer les identifiants de connexion ou que sais-je d'autre qui pourrait l'intéresser ?

Pas si le service est correctement sécurisé... c'est le même problème que pour une BDD.

L'argument de modification du schéma de DB est intéressant par contre.

A la première lecture, je me suis dit "C'est évident, il a raison !". Puis à y réfléchir, je suis de moins en moins convaincu. En respectant les bonnes pratiques, les modifications du schéma de la DB sont absolument sans conséquence pour les applications clientes. De fait, une application cliente ne devrait jamais effectuer de requêtes (via des PS ou non) directement sur des tables mais sur des vues. Et quand bien même, une règle/convention en DBA est de ne jamais modifier des colonnes avec des données de production. Si modification de schéma il y a, ce sont des colonnes ou des tables qui sont ajoutées. Et cela n'affecte donc pas l'application cliente.

Et personnellement, en tant que DBA, si j'ai un dev qui vient se plaindre parce que j'ai ajouté une colonne et que du coup, ses indexes ne sont plus juste parce qu'il a fait un SELECT * FROM LA_VUE/LA_TABLE, je l'envoi promener ^^.

C'est pas faux. Cela dit l'approche service web donne quand même plus de souplesse. Je prenais l'exemple d'une modification du schéma de données, mais si c'est quelque chose de plus radical, genre un changement de SGBD, le fait d'avoir masqué la DB aux clients épargnera beaucoup de boulot pour la suite. Et puis toutes les technos clientes ne permettent pas de se connecter à un BDD. Par exemple une appli web en HTML/JS peut directement exploiter un service web REST, mais pas une DB SQL Server...

Je ne dis pas que c'est l'approche idéale dans toutes les situations, il faut voir au cas par cas selon les besoins, mais ça présente quand même un certain nombre d'avantages.

[Kropernic]

Merci pour ce complément d'information.

Je vais donc continuer à me pencher là-dessus car il n'est impossible que je sois amené un créer une application web dans peu de temps.

Et apparemment si j'ai bien compris, je serais forcé techniquement de passé par un web-service pour accéder à la DB.