[Sécurité] Utilisateur géré par le serveur BDD ou dans la table relationnelle ?

[Scoha]

Bonjour,

Je me pose une question de choix technique/logique/applicatif. J'ai un intranet celui-ci à plusieurs utilisateurs, vaut il mieux gérer ses utilisateurs dans la base de donnée avec leur mot de passe et login ou plutôt du coté d'une table relationnel?
En sachant qu'il peut avoir X utilisateurs se connectant à cette base et que dans tout les cas le mot de passe est crypté.
Pour ma part je ne sais pas si mon choix à été bon jusque maintenant mais je géré toujours les utilisateurs dans une table relationnel, je n’arrive pas à voir si y a des avantages ou des contraintes suivant l'une ou l'autre des méthodes.


Merci de m'éclaircir.

[gk14fire]

Quand tu parles de gérer les utilisateurs dans la base de données, c'est à dire affecter un utilisateur MySQL à chaque utilisateur de l'application ?

Si c'est cela, je ne crois pas que ce soit judicieux. Il vaut mieux que tu conserves ton mode de fonctionnement actuel : une table utilisateur qui contient l'ensemble des utilisateurs ayant accès à l'application.

[Scoha]

Envoyé par gk14fire

Quand tu parles de gérer les utilisateurs dans la base de données, c'est à dire affecter un utilisateur MySQL à chaque utilisateur de l'application ?

Oui

Bah personnellement j'ai le même avis que toi, seulement pour le client ca lui semble pas normal limite une grosse lacune de connaissance de ma part, à savoir que c'est une application pour le ministère de la défense.

Ce que j'aimerai c'est avoir les avis des personnes ayant utilisé l'une ou l'autre des méthodes et pourquoi, je voudrais leur fournir une explication concrète qui tienne la route et pas seulement un parce que .

[al1_24]

D'un point de vue de sécurité, il est préférable en effet d'affecter un utilisateur SGBD par personne se connectant ou au moins gérer des profils différents de manière que tous les utilisateurs n'aient pas les mêmes privilèges sur tous les objets de la base de données.

Ce que j'avais fait dans une ancienne application, c'était un système à plusieurs niveaux :

• Une table des utilisateurs, accessible en lecture seule à un utilisateur générique, donnant le profil de l'utilisateur
• A l'ouverture de l'application, saisie des identifiants de l'utilisateur,
  vérification des identifiants à l'aide de la session SGBD générique.
• Si l'identifiant est reconnu, ouverture d'une session SGBD avec le profil de l'utilisateur pour la suite des opérations.

[Scoha]

Merci pour vos réponses, mais un plus gros débat m'enchanterai un peu plus

[cboun94]

bonjour,

Laisser la base se charger de l'identification des utilisateurs, ça peut être intéressant du point de vue de la sécurité, mais ça semble franchement horrible question maintenance ... surtout pour un intranet (avec un paquet d'utilisateurs). Sans compter qu'il faut un admin de base de donnée pour administrer les utilisateur de l'appli : c'est légèrment disproportionné

L'utilisation d'une table est plus simple et plus logique (à mon goût). On peut avoir le même niveau de sécurité : pas d'accès direct à la table des utilisateur, utilisation de procédure qui prend en paramètre le couple login + mdp (crypté ? ou hash ?) qui retourne un boolean.


Sinon, il reste toujours la sécurité intégrée géré par SQL Serveur avec les comptes windows, mais c'est avec SQL Serveur

[ylarvor]

Il faut savoir que le LOGIN de bases de données ne correspond pas à un utilisateur mais à une application qui accède à la base.
Ensuite, le USER permet d'affecter des droits sur les tables en fonction du rôle affecté au login dans l'application. Il peut y avoir un LOGIN qui a le droit de modifier et un login qui n'a que le droit de lire. Par conséquent, le USER du premier login aura le droit de modifier, le second USER aura le droit de lire.