Discussion :

[FadeToBlack]

Bonjour à tous,

JE dois mettre en production, dans quelques semaines, une appli qui se connecte à une BDD.

Bien évidemment, je dois masquer les identifiants de connexions pour plus de sécurité.

J'ai une courte recherche sur les modules existants pouvant contribuer à cela (Keyring, passlib, cartography, python-decouple). JE suis sûr qu'il en existe d'autres....

Auriez-vous un avis sur ces modules, et/ou des conseils pour d'autres?

Je vous remercie d'avance.

Bonne journée

[chatGPT]

Il est important de masquer les identifiants de connexion à la base de données pour des raisons de sécurité, car si ces informations sont compromises, cela peut avoir des conséquences graves.

Voici mon avis sur les modules que vous avez mentionnés :

Keyring : Il s'agit d'un module Python qui permet de stocker des informations sensibles, telles que des identifiants de connexion, de manière sécurisée sur le système d'exploitation. Keyring est une bonne option si vous voulez stocker les identifiants de connexion en dehors du code source de votre application.

Passlib : Il s'agit d'un module Python qui fournit des outils de hachage et de chiffrement pour stocker et vérifier les mots de passe. Bien que cela puisse être utile pour protéger les mots de passe des utilisateurs, cela ne résout pas le problème de stockage des identifiants de connexion à la base de données.

Cartography : Il s'agit d'un outil qui permet de configurer des variables d'environnement pour les applications. Bien que cela puisse aider à stocker les identifiants de connexion en dehors du code source de votre application, il ne fournit pas de fonctionnalités de sécurité supplémentaires.

Python-decouple : Il s'agit d'un module qui permet de stocker des paramètres de configuration dans des fichiers externes. Cela peut être utile pour stocker les identifiants de connexion en dehors du code source de votre application. Python-decouple peut également être utilisé pour gérer d'autres paramètres de configuration de votre application.

En dehors de ces modules, vous pouvez également envisager d'utiliser des variables d'environnement pour stocker les identifiants de connexion, ou de stocker les informations de connexion dans un fichier de configuration qui n'est pas inclus dans votre code source. Il est également important de prendre des mesures pour protéger la sécurité de votre application en général, telles que l'utilisation d'un pare-feu et la mise à jour régulière de votre application avec les dernières mises à jour de sécurité.

[papajoker]

bonjour

Je dirais que ici le problème, c'est que nous dis pas ce qu'est ton appli ! pour un serveur, un fichier texte externe suffit largement, pour une appli cliente alors oui il faut passer par du chiffrement.

[FadeToBlack]

Bonjour papajoker,

En fait le questionnement avait surtout un caractère généraliste et ne s'inscrivait pas forcément dans le concret.

Mais effectivement, j'ai un projet en cours de création d'un Dashboard avec Pandas/Polars combiné à Plotly et Dash (donc en web).

Cette base récupère les données d'une base PostgreSQL sur un autre serveur.

C'est un projet interne à mon entreprise et ne sera jamais destiné à l'externe. En théorie, je n'ai pas trop de risque de sécurité. Mais je me suis posé la question de savoir comment "protéger/sécuriser" les identifiants à d'autres serveurs (ici, une BDD) si par hasard un petit malin se prenait d'aller voir mon code.

J'ai fait quelques recherche sur le net, et j'ai trouvé plein de lib. Donc du coup, je me suis demandé quels étaient les inconvénients et les avantages de chacunes. Mais c'est une tache relativement compliquée. Je me suis donc tourné vers le forum, histoire de voir si des avis pourraient m'être donnés.

Je ne sais pas si mes explications éclairent mieux la problématique.

Bonne journée à vous

[wiztricks]

J'ai fait quelques recherche sur le net, et j'ai trouvé plein de lib. Donc du coup, je me suis demandé quels étaient les inconvénients et les avantages de chacunes. Mais c'est une tache relativement compliquée. Je me suis donc tourné vers le forum, histoire de voir si des avis pourraient m'être donnés.

Il serait préférable de vous tourner vers Mr Sécurité de la boite et/ou l'administrateur des bases de données: ce sont eux qui définissent les exigences et valident les solutions à mettre en œuvre.

- W

[FadeToBlack]

Bonsoir,

Pour ce qui est de notre SSI, la seule chose qui m'ait demandé c'est que les identifiants de BDD ne soit pas visible dans le code. Que les mots de passe en base soient chiffrés. Et pour les bases un peu sensible, qu'elles soient entièrement chiffrés.
Mais pour ce qui est des outils, on fait comme on veut, surtout que nous n'avons pas d'admin BDD. Et c'est la première appli que je fais en python qui sera connectée à une BDD.

Sinon, soit elles n'ont pas de BDD soit c'est sous symfony....

[wiztricks]

Pour ce qui est de notre SSI, la seule chose qui m'ait demandé c'est que les identifiants de BDD ne soit pas visible dans le code. Que les mots de passe en base soient chiffrés. Et pour les bases un peu sensible, qu'elles soient entièrement chiffrés.

A priori, le seul qui semble faire le job dans la liste est keyring.
Reste à trouver des qui l'ont mis en place/utilisé "en vrai" pour avoir un avis.

Ceci dit, je ne comprends pas le besoin: les informations de connexion à la base de donnée sont dans un fichier de configuration (pas dans le code) propriété d'un utilisateur. On peut donc en interdire l'accès à tout lambda non privilégié et auditer les accès des comptes privilégiés.

Côté BDD, on peut aussi donner un accès à cet utilisateur que lorsqu'il se connecte depuis une adresse IP "interne".
note: si on utilise un truc comme keyring et qu'on se connecte au compte utilisateur, on pourra accéder au fichier ou récupérer les informations de connexion en codant un peu => on peut aussi empêcher l'utilisateur de se connecter en session interactive.

- W

[binarygirl]

Ceci dit, je ne comprends pas le besoin: les informations de connexion à la base de donnée sont dans un fichier de configuration (pas dans le code) propriété d'un utilisateur. On peut donc en interdire l'accès à tout lambda non privilégié et auditer les accès des comptes privilégiés.

Moi aussi, je cherche à comprendre le besoin et le risque qu'on cherche à éviter, qui n'est pas clairement exprimé.

J'imagine que dans la tête du SSI, le but est d'éviter qu'un fichier de config sensible soit committé accidentellement dans un repo, qui peut être ouvert à d'autres personnes que les développeurs, voire à des entités externes à la société...
Une technique possible serait de passer par des variables d'environnement, et même containeriser l'application avec Docker par exemple. Il est possible de lancer un container avec une ligne de commande incluant ces variables d'environnement. Un exemple ici. Il y a aussi Docker secrets mais pour les swarm, pas les containers stand-alone à ma connaissance.

Il est vrai que si l'application souffre d'une vulnérabilité (injection SQL notamment), il peut être possible sous certaines conditions pour un attaquant d'uploader un webshell et fouiller dans les fichiers. Dans ce cas de figure, trouver les credentials et uploader un script ad hoc permettrait effectivement d'accéder à la DB et d'exfiltrer des données.
Pour bien faire les choses, il y a d'autres mesures à mettre en place, par exemple autoriser les connexions à la DB seulement au départ d'une IP bien précise et pas de l'extérieur, utiliser un compte non privilégié pour la DB c'est à dire autre que root ou sa comme on le voit trop souvent.

[wiztricks]

J'imagine que dans la tête du SSI, le but est d'éviter qu'un fichier de config sensible soit committé accidentellement dans un repo, qui peut être ouvert à d'autres personnes que les développeurs, voire à des entités externes à la société...

On commite depuis des environnements de développement, on déploie des applications sur des systèmes de production et ces 2 environnements n'ont pas les mêmes exigences/règles de sécurité.

- W