La meilleure façon de stocker un mot de passe de base de données dans un script de démarrage/fichier de configuration ?

Question

Ainsi, nos applications de serveur Web doivent se connecter à la base de données et certaines autres applications disposent de scripts de démarrage qui s'exécutent au moment du démarrage.

Quelle est la meilleure façon de stocker le nom/mot de passe de ces applications, en termes de

• sécurité, par ex.peut-être que nous ne voulons pas que les administrateurs système connaissent le mot de passe de la base de données
• maintenabilité, par ex.rendre la configuration facile à modifier lorsque le mot de passe change, etc.

les solutions Windows et Linux sont appréciées !

Answer 1

La meilleure façon de sécuriser votre mot de passe est de cesser d’en utiliser un.Utilisez une connexion fiable :Comment:Connectez-vous à SQL Server à l'aide de l'authentification Windows dans ASP.NET 2.0.Ensuite, vous n'avez rien à cacher - publiez votre web.config et votre source dans le monde entier, ils ne peuvent toujours pas accéder à votre base de données.

Si cela ne fonctionne pas pour vous, utilisez le système de cryptage de configuration dans ASP.NET.

Answer 2

PostgreSQL propose un bonne solution pour ce genre de situation dans leur documentation.Essentiellement, vous utilisez ssh pour relier un port de votre machine au port du serveur PostgreSQL sur la machine distante.Celui-ci comporte trois étapes d'authentification :

1. Restreindre l'accès au port local, par exemple en autorisant uniquement un utilisateur particulier à s'y connecter.
2. Configurez une connexion sans mot de passe à l'hôte PostgreSQL avec ssh en tant qu'utilisateur particulier.
3. Autoriser l'utilisateur à se connecter en SSH à avoir un accès local à PostgreSQL sans mot de passe.

Cela réduit la sécurité quant à savoir si vos comptes d'utilisateurs sont sécurisés et si votre configuration ssh est solide, et vous n'avez pas besoin d'un mot de passe stocké n'importe où.

Modifier:Je dois ajouter que cela fonctionnera avec n'importe quelle base de données qui écoute un port TCP/IP.Il se trouve que cela est décrit dans PostgreSQL.Et vous souhaiterez qu'iptables (ou l'équivalent hors Linux) fasse les restrictions de port.Voir ce.

Answer 3

Je suis d'accord avec Lomaxx :si quelqu'un est déjà sur le serveur ou y a un large accès (comme un administrateur système), le jeu est pratiquement terminé.L’idée serait donc d’utiliser un serveur en qui vous avez confiance et qui est sécurisé dans la mesure où vous le souhaitez.Spécifiquement:

• Vous devez faire confiance aux administrateurs système
• Vous devez faire confiance à toute autre personne qui exécute du code sur le même serveur (c'est pourquoi l'hébergement partagé est un grand non-non pour moi)

Au-delà de cela, les variables d'environnement semblent être un choix populaire pour stocker ces types d'informations d'identification, car cela signifie que l'accès à la source uniquement (par exemple en compromettant la boîte de développement) ne la révèle pas directement et peut également être joliment localisée pour chaque serveur (développement, test, etc.).

Answer 4

du texte brut ?S'ils se trouvent sur votre serveur, j'espère que celui-ci est suffisamment sécurisé pour ne pas autoriser tout accès non autorisé.Si des personnes peuvent accéder à vos fichiers de configuration sur le serveur, quelque chose s'est mal passé bien plus tôt.

Answer 5

clarification:en termes de sécurité, de maintenabilité (par ex.si le login doit changer, puis-je le retrouver plus tard, etc.)

@lomax :peut-être que je ne veux pas que tout le monde ait accès au serveur physique (par ex.administrateurs système) pour voir le mot de passe.

Merci!

Answer 6

Dans la plupart des cas, je pense qu'il suffit de masquer le mot de passe dans un fichier texte brut (par ex.avec base64).Vous ne pouvez pas protéger complètement un mot de passe stocké contre un administrateur système déterminé disposant d'un accès root, il n'est donc pas vraiment nécessaire d'essayer.Cependant, un simple obscurcissement protège contre la révélation accidentelle du mot de passe à un internaute.

Une alternative plus complexe consiste à mettre en place un serveur de mots de passe sécurisé dédié qui :

• fournit un service de décryptage de mot de passe
• stocke en fait les mots de passe pour les utiliser par d'autres serveurs moins sécurisés

Selon les protocoles réseau utilisés, cela peut ne pas protéger contre un administrateur système malveillant avec tcpdump.Et cela ne protégera probablement pas non plus contre un administrateur système déterminé doté d'un débogueur.À ce stade, il est peut-être temps d’envisager quelque chose comme les tickets Kerberos.

Answer 7

Vous pouvez intégrer une clé de cryptage symétrique dans votre binaire et demander à ce binaire de lire un nom d'utilisateur/mot de passe crypté à partir d'un fichier sur le disque lors de son démarrage.

Cependant, ce n’est pas vraiment plus qu’un obscurcissement, puisque votre code est susceptible d’être stocké quelque part dans un référentiel source.

Je suggérerais que vous seriez mieux servi pour contrôler l'accès à vos serveurs à la fois physiquement et sur le réseau à l'aide d'un pare-feu et d'une bulle de réseau privé, et stocker les mots de passe en clair (ou encodés en base 64) sur un disque avec des autorisations verrouillées. à l'utilisateur exécuté pour votre application Web.

Vous pouvez également verrouiller le serveur de base de données pour n'accepter que les connexions de vos machines d'application Web par IP.

En fin de compte, votre problème est que la clé (votre paire nom d'utilisateur/mot de passe DB) doit être disponible pour une utilisation programmatique et sans surveillance par vos applications Web.