Il existe d'autres façons de le faire. Cela dépend de qui, selon vous, vient après votre chaîne de connexion et du type d'accès et des niveaux de compétence qu'ils vont avoir. La chaîne de connexion est là, quelque part, peu importe comment vous essayez de la cacher.
Sachant que la chaîne de connexion pourrait être piratée, je suppose toujours qu'elle sera piratée et prends des précautions à l'autre bout.
Nous faisons plusieurs choses côté serveur de base de données pour nous assurer que même si la chaîne de connexion est compromise, les données sont toujours sécurisées.
- L'utilisateur associé à la chaîne de connexion n'a pratiquement aucune autorisation sur le serveur. Les seules autorisations dont ils disposent sont EXECUTE et CONTROL sur le SCHEMA qui contient les procédures stockées.
- Le seul accès dont dispose le frontal est via les procédures stockées. Nous n'autorisons jamais le frontal à envoyer des chaînes SQL.
- Les données sont conservées dans un schéma distinct de celui des exécutables, dans le schéma DATA, l'utilisateur associé à la chaîne de connexion n'a aucune autorisation, il ne peut pas la regarder, la sentir ou la toucher.
- Les procédures stockées délèguent des autorisations à un utilisateur sans connexion disposant de suffisamment d'autorisations pour exécuter la procédure. (AVEC EXÉCUTER COMME 'utilisateur sans connexion')
C'est à peu près tout ce que nous pouvons faire. Nous n'avons trouvé aucun moyen d'empêcher la chaîne de connexion d'être exposée d'une manière ou d'une autre.
En réponse à la question posée par Alex ci-dessous. (trop long pour un commentaire)
Noter. Ce qui suit est pour MS SQL Server, il peut s'appliquer à d'autres systèmes de SGBD mais je ne peux pas me porter garant pour les autres.
Une base de données contient un schéma, le schéma contient des objets de base de données tels que des tables, des vues, des procédures stockées. Le schéma vous permet de clôturer les objets de la base de données, par exemple, si vous aviez un groupe de tables que tout le monde était autorisé à voir, elles pourraient alors être intégrées dans un schéma COMMUN, si vous aviez des informations sur la paie que vous deviez sécuriser, vous pourriez mettre cela dans un schéma PAYROLL. Vous pouvez ensuite mettre différentes mesures de sécurité sur le SCHEMA en fonction du type d'objets qui s'y trouvent. Graphiquement, ils ressemblent à des dossiers sur un disque dur et sous eux se trouvent tous les objets de base de données qu'ils contiennent. Lorsque vous lancez votre serveur, plusieurs schémas sont créés automatiquement. Celui que vous connaissez le mieux est le schéma DBO. Vous ne le savez peut-être pas si votre administrateur l'a défini comme schéma par défaut.
Ce que nous faisons est de placer toutes les données dans un schéma DATA, cela signifie que seules les tables sont autorisées. Donc, si nous avions une base de données de paie, les tables de données entreraient dans un schéma appelé dataPayroll.
Une procédure stockée est un bloc ou des blocs de code SQL que le serveur de base de données peut exécuter lorsqu'il est appelé. Il peut renvoyer une table de données ou une valeur unique. Considérez-le comme une méthode en C#.
Les procédures stockées ont des paramètres d'entrée et de retour qui sont utilisés dans le code SQL. Les procédures stockées paramétrées constituent une défense solide contre les attaques par injection SQL.
Notre protocole indique que les procédures stockées et les vues sont toutes stockées dans un schéma précédé de "prog". Ainsi, dans le cas de la base de données de paie, tous les objets qui ne sont pas des données se trouvent dans le schéma progPayroll.
L'utilisateur défini par la chaîne de connexion ne dispose alors que des autorisations de contrôle et d'exécution sur le schéma "prog". Cela leur permet d'appeler la procédure stockée. L'utilisateur défini par la chaîne de connexion se voit refuser toutes les autres autorisations. Cet utilisateur se voit également refuser TOUTES les autorisations partout ailleurs. Dans la procédure stockée, l'autorisation d'accéder aux données est déléguée à un utilisateur NO LOGIN qui a l'autorisation de récupérer les données du schéma "data" à l'aide de la commande EXECUTE AS.
Il n'y a PAS de sql dans le front-end. Tous les programmeurs frontaux connaissent le nom des procédures stockées, les paramètres et les types et valeurs de retour.
De cette façon, même si l'attaquant parvient à démêler la chaîne de connexion de votre programme, il a encore beaucoup de travail à faire pour pouvoir faire quoi que ce soit à votre base de données puisque l'utilisateur dont il dispose ne peut exécuter qu'une procédure stockée.
Si vous n'avez aucune idée de quoi il s'agit, vous devez vraiment faire appel à un programmeur DB pour configurer votre système pour vous.
