Sécuriser une base de données

Sécuriser une base de données - VB/VBA/VBS - Programmation

Marsh Posté le 23-11-2005 à 17:16:41    

Bonjour,
 
Je monte une base de donnée et j'aimerais la sécurisée de la façon suivante":
 
Lorsque l'usager sélectionne la base de donnée en question un MsgBox apparraît afin qu'il puisse s'identifier et entrer son mot de passe. Si c'est l'administrateur qui s'identifie le Formulaire:" Menu Général Admin" ouvre avec la barre d'outil appropriée et si c'est l'invité qui s'identifie alors le Formulaire "F Menu Général Invité" va ouvrir avec sa propre barre d'outil.
Comment puis-je faire cela?
 Et est-ce une bonne façon de sécuriser une base de données sur un réseau????
 
Merci!!

Reply

Marsh Posté le 23-11-2005 à 17:16:41   

Reply

Marsh Posté le 23-11-2005 à 17:49:09    

Quelle base de données ?
 
MS Access (comme beaucoup d'autres) intègre déjà des fonctions de sécurité toutes prêtes.

Reply

Marsh Posté le 23-11-2005 à 18:12:17    

tegu a écrit :

Quelle base de données ?
 
MS Access (comme beaucoup d'autres) intègre déjà des fonctions de sécurité toutes prêtes.


 
 
C'est avec Access 2000.  Peut-on lors du démarrage de la base de données ouvrir un Formulaire distinct en en fonction de l'usager et de son mon de passe???

Reply

Marsh Posté le 23-11-2005 à 21:17:57    

Je suppose que oui, mais je doute que cela soit automatique grâce à une propriété.  
Il doit falloir coder tout ça pour que le programme s'adapte à son interlocuteur.
Les fonctions de base servent surtout à donner ou non accès à certains objets (formulaire, rapport, requete) en création, modif, supp, exécution en fonction du profil.

Message cité 1 fois
Message édité par tegu le 23-11-2005 à 21:18:18
Reply

Marsh Posté le 23-11-2005 à 22:58:07    

tegu a écrit :

Je suppose que oui, mais je doute que cela soit automatique grâce à une propriété.  
Il doit falloir coder tout ça pour que le programme s'adapte à son interlocuteur.
Les fonctions de base servent surtout à donner ou non accès à certains objets (formulaire, rapport, requete) en création, modif, supp, exécution en fonction du profil.


 
J'ai penser créer un formulaire de Démarrage qui vérifierait le nom de l'usager et son mot de passe Ex:
Private Sub Cmd_Validation_Click()
On Error GoTo Err_Cmd_Validation_Click
 
    Dim stDocName As String
    Dim stLinkCriteria As String
 
    If Nom_usager = "Admin" and Mot_de_Passe = "xxxxx" then  
 
    stDocName = "F Menu Général Admin"
    DoCmd.OpenForm stDocName, , , stLinkCriteria
     
   Else
    MsgBox "Le Nom de l'usager ou le mot de passe est incorrect, veuillez réessayer à nouveau"
 
Exit_Cmd_Validation_Clic:
    Exit Sub
 
Err_Cmd_Validation_Click:
    MsgBox Err.Description
    Resume Exit_Cmd_Validation_Clic
     
End Sub  
 
...quelque chose comme ça?!?...qu'en  penses-tu? Est-ce acceptable???
Merci  pour ta réponse...ça encourage les débutants comme moi!!!

Reply

Marsh Posté le 24-11-2005 à 09:54:17    

Je pense qu'il s'offre à toi deux possibilités principales.
La première est d'utiliser les sécurités intégrées et à ce moment tu n'as pas à faire de formulaire de saisie de profil, mais il te faudra te renseigner sur les fonctions qui permettent de le récupérer auprès du système de login Access. Il te faudra aussi paramétrer les droits d'accès des utilisateurs par groupes de travail dans ta base (menu Outils/Sécurité/...). Mais prends bien le temps de lire de la documentation avant de te lancer car cela peut vite devenir complexe et contraignant (le prix de la sécurité), voire dangereux pour ta base (déjà vu quelqu'un perdre l'accès à sa base en oubliant le mot de passe admin).
 
Une autre solution est de gérer toute la sécurité de manière manuelle en faisant, comme tu as commencé, un formulaire de saisie de profil et en subordonnant toutes les possibilités d'accès - aux menus et aux formulaires - aux droits alloués à l'utilisateur connecté. Cela nécessite beaucoup de code mais est quelques fois indispensable pour une totale personnalisation des niveaux de sécurité.
 
Je n'ai jamais vraiment mis en place de verrouillage total de mes applications, ni sous la première forme, ni sous la seconde, donc mes conseils ont leur limite.
J'espère néanmoins t'avoir donné des pistes satisfaisantes.

Reply

Marsh Posté le 24-11-2005 à 19:48:32    

tegu a écrit :

Je pense qu'il s'offre à toi deux possibilités principales.
La première est d'utiliser les sécurités intégrées et à ce moment tu n'as pas à faire de formulaire de saisie de profil, mais il te faudra te renseigner sur les fonctions qui permettent de le récupérer auprès du système de login Access. Il te faudra aussi paramétrer les droits d'accès des utilisateurs par groupes de travail dans ta base (menu Outils/Sécurité/...). Mais prends bien le temps de lire de la documentation avant de te lancer car cela peut vite devenir complexe et contraignant (le prix de la sécurité), voire dangereux pour ta base (déjà vu quelqu'un perdre l'accès à sa base en oubliant le mot de passe admin).
 
Une autre solution est de gérer toute la sécurité de manière manuelle en faisant, comme tu as commencé, un formulaire de saisie de profil et en subordonnant toutes les possibilités d'accès - aux menus et aux formulaires - aux droits alloués à l'utilisateur connecté. Cela nécessite beaucoup de code mais est quelques fois indispensable pour une totale personnalisation des niveaux de sécurité.
 
Je n'ai jamais vraiment mis en place de verrouillage total de mes applications, ni sous la première forme, ni sous la seconde, donc mes conseils ont leur limite.
J'espère néanmoins t'avoir donné des pistes satisfaisantes.


 
 
 
 
Bonjour,
 
 
J'ai plusieurs livres d'Access, et je trouve difficile  d'obtenir de l'information pour mettre en place un système de sécurité sur une base de données que l'on installe sur un réseau avec plusieurs utilisateurs...effectivement je vais devoir bien me renseigner.  J'ai commencer à faire des formulaires, requêtes et états distincts pour chaque usager (admin,responsable et invité) mais je m'apperçois que c'est très long...je dois recrééer plusieurs requêtes et états!!!!! Toutefois mon problème demeure, car le petit 'x', situé dans le coin droit de la fenêtre' demeure toujours accessible. Ainsi n'importe qui peut fermer le formulaire par ce 'x' finit par avoir accès à la base de données?!?  Et l'usager a besoin de ce 'x' pour fermer un état...   Y a-t-il un moyen pour remédier à ce problème??
 
Merci beaucoup pour ta collaboration!!!

Reply

Marsh Posté le 25-11-2005 à 11:49:16    

Que l'utilisateur ait accès à la fenêtre de base dedonnées n'est pas forcément un gros problème s'il n'a pas les droits pour lire ou modifier la structure des formulaires et des états (voir droits d'accès accordés aux utilisateurs).
Cette fenêtre peut aussi être masquée (macro/ExecuterCommande/MasquerFenêtre, par exemple) même si cela n'empêche pas un connaisseur de faire F11 pour la réafficher.
Je n'ai jamais eu besoin d'aller plus loin pour "sécuriser" mes prog Access mais il est aussi possible de paramétrer des droits (restrictions) sur la base de données elle-même (en plus des objets formulaires, requetes, etc.).
 
La sécurité n'est pas une simple fonctionnalité qu'on implémente en 2 minutes. Cela nécessite une bonne réflexion et beaucoup de travail.
Généralement si l'on ne veut pas le faire correctement - car trop long, trop compliqué - il vaut mieux ne rien faire, ou juste un minimum.
 
Et encore tu n'en es pas à implémenter des algos de cryptographie... :)

Reply

Marsh Posté le 25-11-2005 à 17:03:23    

tegu a écrit :

Que l'utilisateur ait accès à la fenêtre de base dedonnées n'est pas forcément un gros problème s'il n'a pas les droits pour lire ou modifier la structure des formulaires et des états (voir droits d'accès accordés aux utilisateurs).
Cette fenêtre peut aussi être masquée (macro/ExecuterCommande/MasquerFenêtre, par exemple) même si cela n'empêche pas un connaisseur de faire F11 pour la réafficher.
Je n'ai jamais eu besoin d'aller plus loin pour "sécuriser" mes prog Access mais il est aussi possible de paramétrer des droits (restrictions) sur la base de données elle-même (en plus des objets formulaires, requetes, etc.).
 
La sécurité n'est pas une simple fonctionnalité qu'on implémente en 2 minutes. Cela nécessite une bonne réflexion et beaucoup de travail.
Généralement si l'on ne veut pas le faire correctement - car trop long, trop compliqué - il vaut mieux ne rien faire, ou juste un minimum.
 
 
Merci beaucoup pour tes conseils...je vais prendre le temps de bien étudier le fonctionnement de sécurité des droits de chaque usager, sur l'accès aux objets de la base de données
 
Et encore tu n'en es pas à implémenter des algos de cryptographie... :)


Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed