Quel est le meilleur moyen de centraliser et de sécuriser les chaînes de connexion?

Question

Quel est le meilleur moyen de centraliser et de sécuriser les chaînes de connexions utilisées par les applications? Dans mon environnement, nous avons de nombreuses applications internes. Chaque application nécessite une ou plusieurs chaînes de connexion pour accéder à la base de données. Nous avons pour objectif de centraliser toutes ces chaînes de connexion (en particulier les noms d'utilisateur et les mots de passe SQL) afin de pouvoir changer les mots de passe à un endroit donné au lieu de 35 fichiers .config, entrées de registre, etc. différents.

Nous utilisons actuellement un composant développé localement, qui extrait les informations de chaîne de connexion d'une base de données d'accès. Il couvre la nécessité de la centralisation mais n'est pas particulièrement sécurisé. De plus, nous avons des applications écrites dans des langages classiques tels que asp, vb6, delphi, c ++, .net, de sorte que la solution doit pouvoir être utilisée par toutes ces applications.

Quelqu'un at-il une idée de la façon de mieux faire cela ou devons-nous revoir notre approche en ce qui concerne la manière dont nos applications accèdent à la base de données.

Answer 1

Vous pouvez utiliser le serveur Windows pour créer des utilisateurs autorisés à accéder à votre base de données SQL Server. Ensuite, vous pouvez utiliser le login Windows intégré dans les chaînes de connexion.

BTW Le stockage de mots de passe dans des bases de données publiques publiques les rend non pertinents. Même comme ils n'existent pas.

Answer 2

La société pour laquelle je travaille a utilisé une situation similaire via une base de données SQL Server. Nous avons fini par créer une dll .net compatible COM pour simplifier et sécuriser l'API dans la base de données et pour nous assurer que la même logique est utilisée entre les packages asp, .Net et DTS classiques. Cela a très bien fonctionné pour nous pendant un an et, même si nombre d’agents de refactoring que beaucoup d’entre nous aimeraient faire, nous avons été très utiles pour résoudre des problèmes tels que les migrations de serveurs ou les changements de noms.

Je pense que vous êtes sur le bon chemin; cependant, je recommanderais les modifications suivantes:

• Essayez de passer à un vrai serveur de base de données. L’accès est excellent pour MS Office, mais pas pour quelque chose de cette envergure.
• Créez une console d'administration permettant de vérifier qui ajoute et modifie des informations (sécurisez qui a également accès à quels paramètres).
• Générez une DLL compatible COM afin qu'elle puisse être utilisée par d'autres systèmes de manière sécurisée et cohérente.

EDIT:

Ce que j’ai remarqué après avoir travaillé pendant des années dans un système comme celui-ci, c’est que cela vous lie légèrement à certaines solutions. De nombreux outils (par exemple, nHibernate, Elmah, etc. dans le monde .Net) sont réellement limités lorsque la chaîne de connexion ne figure plus dans les fichiers de configuration. Beaucoup peuvent être facilement modifiés pour utiliser votre API; Cependant, il faut plus de temps pour déterminer si vous souhaitez l'utiliser. Juste un FYI sur cela.

Answer 3

N’est-il pas possible de passer à Windows Integrated Security dans les chaînes de connexion, vous n’avez donc pas à vous préoccuper autant de la sécurité (sauf si vous devez sécuriser l’emplacement réel de la connexion).