Fichier/coder-Décoder une base de données permet d'empêcher de rechercher des informations dans une base de données, par exemple avec un éditeur de texte. Seuls l'administrateur et le propriétaire d'une base de données peuvent se permettre de coder ou de décoder une base de données. J'ai testé : Une personne qui n'a pas l'autorisation d'administrer une base de données ne peut pas décoder cette base de données. Et si elle essaie par l'intermédiaire d'un traitement de texte de lire le .MDB, elle ne trouvera rien, même avec Edition/Rechercher.
Si les différents objets d'une base de données appartiennent à plusieurs personnes, seul l'administrateur peut coder/décoder cette base de données.
Les mots de passe peuvent ne contenir qu'un seul caractère, mais est case-sensitive.
Un groupe de ne peut pas avoir de mot de passe (ce qui est logique), et lors de la création d'une nouvelle personne par l'administrateur, il n'est pas proposé de mot de passe immédiatement, il faut le demander explicitement.
En réalité, le seul mot de passe obligatoire est celui du premier administrateur créé, dont le nom est Administrateur
Chaque objet (Table, requête, ... , et même la base de données) appartient à un propriétaire. Une base de données qui appartient à Durant, peut très bien avoir des objets qui appartiennent à Dupont, Martin, etc. Le propriétaire est juste en dessous de l'administrateur : Prenons l'exemple d'une table T_Client qui appartient à Dupont. Dupont a tous les privilèges sur cette table : Il peut définir qui peut la modifier, effacer ses enregistrements, l'administrer, etc.). Il peut également restreindre un administrateur (mais ça ne servira pas à grand-chose, parce qu'un administrateur a forcément tous les droits sur tout, il n'y qu'a se rendre les autorisations sur la table de Dupont).
Le propriétaire d'une base de données (groupe ou personne) est le seul habilité à changer le propriétaire de ses propres objets. Lorsque c'est l'administrateur qui décide de changer le propriétaire d'un objet qui ne lui appartient pas (ou même qui lui appartient d'ailleurs), il doit d'abord se donner l'autorisation d'accès Administrer, s'il ne l'avait pas déjà.
Lorsqu'une personne entre dans Access, et crée une base de données, par défaut, tous les objets qu'il crée lui appartiennent, ainsi que la base de données. On dirait bien que le propriétaire d'une base de données en tant qu'objet global est défini une fois pour toutes lors de la création de la base de données par la personne qui s'est loguée. La seule solution consisterait à récupérer tous les objets les uns après les autres et de les copier dans une base de données vierge avec le nouveau propriétaire.
Lorsque le propriétaire d'une base de données décide de donner un de ses objets à un autre propriétaire, il lui suffit d'aller dans Sécurité/Changer le propriétaire. Attention : Une fois le propriétaire changé, l'ancien propriétaire n'aura plus que les droits que le nouveau propriétaire (ou l'administrateur) voudra bien lui accorder sur ses anciens objets.
Attention : Quand on supprime l'utilisateur propriétaire d'un objet et qu'on rouvre la base de données qui contenait ces objets, ils n'ont plus de propriétaire
Les seuls utilisateurs que l'administrateur ne peut pas changer est Engine et Inconnu.
Heureusement, car ils détiennent les mots de passe et les codes SID des utilisateurs. Il détient les tables correspondantes dans les fichiers de groupe de travail (p.ex. System.mdw)
Il existe donc une table MSYSAccount (dans System.MDW) dont l'utilisateur est carrément Inconnu… C'est cette table qui contient les SID et les Passwords (on peut les voir mais en crypté)
Dans Access 2, il y avait un utilisateur Invité, un groupe invités, et un utilisateur Utilisateur. Nous n'en parlerons pas ici.
Groupes prédéfinis:
Utilisateur prédéfinis
Ces groupes et utilisateur prédéfinis ne peuvent pas s'effacer.
Le groupe Administrateurs a tous les privilèges. Chacun de ses membres peut enlever ses privilèges, mais c'est assez inutile, puisque n'importe quel autre membre du groupe des Administrateurs pourra les remettre sans autre.
A la base, le groupe des Utilisateurs a autant de droits que le groupe des Administrateurs. AInsi, comme chaque nouvel utilisateur fera forcément partie des Utilisateurs, la première des choses est de supprimer toutes les autorisations des Utilisateurs, et de créer un nouveau groupe dans lequel viendront les nouveaux utilisateurs.
Tout utilisateur, y compris l'administrateur, DOIT faire partie de ce groupe. Par défaut, le goupe "Utilisateurs" et l'utilisateur "Utilisateur" possède tous les privilèges.
Une technique de restriction d'accès aux objets consiste, comme tout nouvel utilisateur doit faire partie du groupe des utilisateurs, à supprimer toutes les autorisations pour le groupe utilisateur, et créer un nouveau groupe qui permettra de faire telle ou telle chose mais pas d'autres.
En réseau, un même utilisateur (avec le même mot de passe, donc), peut se loguer plusieurs fois en même temps.
Il est possible d'obtenir l'utilisateur courant :
MsgBox CurrentUser
Il FAUt qu'au moins une personne fasse partie du groupe des administrateurs. Par défaut, Access crée un utilisateur "Administrateur".
Par la suite, dès qu'on crée un utilisateur dans le groupe des administrateur, l'utilisateur "Administrateur" disparaît. Et lorsqu'on efface le dernier survivant du groupe des administrateurs, l'utilisateur "Administrateur" réapparaît, sans qu'on puisse le supprimer.
Ce groupe a disparu avec Access 97
Le bon sens devrait restreindre un maximum ce groupe
Access 97
Les informations concernant la sécurité se trouvent dans c:\windows\system\system.mdw, dans la table MSYSAccount. Les mots de passe et autre SID s'y trouvent en crypté.
Evidemment, lorsqu'on travaille en réseau, il faut que ce fichier se trouve sur le serveur, ou en tout cas un disque unique pour tout le monde. Pour changer le chemin d'accès par défaut de ce fichier, il faut aller dans RegEdit, aller dans
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\8.0\Access\Jet\3.5\Engines\Jet
Et donner comme nouvelle valeur de clé SystemDB, le nouvel emplacement de ce fichier
Access 97
Dans une entreprise d'une certaine taille, il est parfois pratique d'avoir plusieurs fichiers de groupes de travail (Divers groupes et utilisateurs). Ce fichier est par défaut C:\WINDOWS\SYSTEM\SYSTEM.MDW, qui est une base de données protégée, et qui contient les informations des utilisateurs et des groupes, ainsi que leur N° d'identification personnel (SID).
Remarque : Un SID contient entre 4 et 20 caractères alphanumériques (case-sensitives)
On peut créer autant de fichiers de groupe de travail que l'on désire.
Afin de se connecter à :\TESTSECU.MDW (par exemple) à la place de C:\WINDOWS\SYSTEM\SYSTEM.MDW, il s'agit d'abord de créer ce nouveau fichier. Pour ce faire, on doit exécuter le programme WRKADMIN.EXE, qui est représenté par Administrateur de groupe de travail dans Démarrer/Programmes/Office 97, et cliquer sur CREER.
Une fois ce TESTSECU.MDW créé, il s'agit de lancer Access en utilisant ce TESTSECU.MDW à la place de C:\WINDOWS\SYSTEM\SYSTEM.MDW. Pour ce faire, c'est toujours dans le programme WRKADMIN.EXE qu'on choisit cette fois JOINDRE, et jusqu'à nouvel ordre, Access va utiliser les infos de sécurité de TESTSECU.MDW.
Jusqu'à présent, on constate qu'il suffit de copier le fichier .MDB sur une autre machine pour avoir accès à tout. Pour empêcher cela, il suffit de changer le propriétaire de l'objet à sécuriser. Comme chaque utilisateur est pourvu d'un N° SID, il ne suffira pas de recréer l'utilisateur sur l'autre machine pour récupérer les accès. Il faudrait connaître le propriétaire ET son N° SID pour pouvoir le recréer. Ce qui serait utilie par exemple dans le cas ou on perd le fichier System.MDW.
L'exemple donné consiste à sécuriser de manière absolue la table T_Client d'une base de données appelée Commerce (aucune possibilité de lecture ni d'écriture)
A ce stade, qu'il s'agisse du propriétaire Gates, ou de l'administrateur, tous deux ont le droit de s'octroyer les droits qu'ils veulent sur T_Client
A ce stade, l'administrateur a encore tous les droits, ou en tout cas, il peut se les octroyer
Comment faire alors pour réaccéder à T_Client si on a perdu définitivement le fichier de groupe de travail (System.MDW par exemple) ?
Le problème est simple, la solution l'est moins.
Par exemple, nous avons une table T_Employe, pourvue du champ NomEmploye et Salaire. Nous désirons que L'utilisateur Patron aie accès aux 2 champs, mais nous désirons également que Larbinos, qui est secrétaire puisse avoir accès à la table T_Employe, mais seulement aux noms, pas aux salaires.
Le problème est que si Larbinos n'a pas d'accès a la table T_Employe, il n'aura pas accès du tout à aucune donnée, et s'il a accès à T_Employe, il pourra voir les salaires.
On pourrait lui créer une requête affichant certains champs et pas d'autres, mais c'est facile pour lui de recréer une autre requête plus complète.
En fait la solution consiste à rendre Patron propriétaire de T_Employe, et Patron supprime toutes les autorisations de Larbinos autant pour la requête que pour la table.
Ensuite, Patron modifie la requête en ajoutant juste avant le ; WITH OWNERACCESS OPTION. Ce simple fait autorisera Larbinos à accéder à la requête, mais pas à la table.
L'OWNERACCESS OPTION ne permettra pas à Larbinos de voir ni de changer la structure de la requête, puisque ses autorisations ne le lui permettent pas. En fait, cet OWNERACCESS OPTION est une sorte de passe-droit qui permet seulement une certaine marge de manœuvre dans les données, mais pas dans la structure (Créer des nouveaux enregistrements, éditer les existants, ou en effacer (Toujours dans la requête)).
Créer un nouveau Password s'il n'en existait pas encore :
CurrentDb.NewPassword "", "111"
Changer d'un Password pour un autre
CurrentDb.NewPassword "111", "222"
Supprimer le Password d'une base de données
CurrentDb.NewPassword "222", ""
Voici le code nécessaire pour avoir la liste de tous les groupes et des utilisateurs qui en font partie,
ainsi que la liste de tous les utilisateurs, et des groupes qui les hébergent :
Sub test()
Dim USRUtilisateur As User
Dim GRPGroupe As Group
Debug.Print "Collection des utilisateurs : "
For Each USRUtilisateur In DBEngine.Workspaces(0).Users
Debug.Print " " & USRUtilisateur.Name
Debug.Print " Appartient à ces groupes :"
For Each GRPGroupe In USRUtilisateur.Groups
Debug.Print " " & GRPGroupe.Name
Next GRPGroupe
Next USRUtilisateur
Debug.Print "Collection des groupes :"
For Each GRPGroupe In DBEngine.Workspaces(0).Groups
Debug.Print " " & GRPGroupe.Name
Debug.Print " a comme membres :"
For Each USRUtilisateur In GRPGroupe.Users
Debug.Print " " & USRUtilisateur.Name
Next USRUtilisateur
Next GRPGroupe
End Sub
Cette fonction permet de déterminer si l'utilisateur courant fait partie de tel ou tel groupe
Exemple d'appel :
If JeFaisPartieDuGroupe ("Direction") = True then
MsgBox "L'utilisateur courant fait partie de la direction"
End If
Function JeFaisPartieDuGroupe(VARGroupe As String) As Boolean
Dim USRUtilisateur As User
Dim GRPGroupe As Group
JeFaisPartieDuGroupe = False
For Each USRUtilisateur In DBEngine.Workspaces(0).Groups(VARGroupe).Users
If CurrentUser = USRUtilisateur.Name Then
JeFaisPartieDuGroupe = True
End If
Next USRUtilisateur
End Function