Quand vous aurez terminé cette page, cliquez ici pour voir le code VBA qui permet de récupérer le nom de l'utilisateur courant, ainsi que les groupes auxquels il appartient.
Un autre excellent site sur la sécurité Access se trouve ici
Sous Access, il est tout à fait possible de sécuriser ses bases de données contre le piratage et l'indiscrétion. Mais ceci recquiert certaines connaissances, et, bien souvent, il n'est pas nécessaire de recourir à la sécurité intégrée d'Access, sauf cas assez rares, mais voici comment procéder :
Lorsque vous utilisez Access, mais pas sa sécurité, vous êtes considéré comme l'administrateur.
Pour suivre ces étapes, créez une base de données "TestSecu.MDB".
L'étape préléminaire avant de commencer à s'occuper de la sécurité est de vous attribuer un mot de passe. Pour ce faire :
- Outils/Sécurité/Gestion des utilisateurs et des groupes
- Cliquez sur l'onglet "Changer le mot de passe"
(C'est ici que vous voyez qui vous êtes : administrateur)
- Nouveau mot de passe : adm
- Confirmation : adm
Voilà. Dès maintenant, vous êtes toujours l'administrateur, mais vous avez un mot de passe. Pour vous en rendre compte :
- Quittez Access
- Revenez dans Access
Si vous utilisez Access 97 ou antérieur, vous devez immédiatement entrer votre mot de passe. Si vous utilisez Access 2000, vous devez ouvrir une base de données pour que le mot de passe (adm) vous soit demandé.
Revenez donc dans TestSecu.MDB, et vous avez donc dû entrer votre mot de passe. Attention donc : N'oubliez pas votre mot de passe, sinon, Access va devenir inutilisable.
Bien. Nous avons donc réussi a bloquer l'entrée dans Access, mais la sécurité Access ne se borne pas du tout à cette petite mise en jambes.
Une fois dans votre base de données TestSecu.MDB, créer une table T_Client, qui contient un seul champ : NomClient, et un seul enregistrement : Dupont (une table toute simple donc).
Maintenant, l'exercice consiste à vous restreindre à vous même certains droits sur la table.
- Allez dans Outils/Sécurité/Autorisations d'accès
- Dans Nom d'utilisateur/Groupe : Sélectionnez Administrateur
(Pas compliqué, c'est le seul utilisateur...)
- Dans Nom de l'objet, choissez T_Client
(Pas compliqué, c'est la seule table...)
En dessous, vous avez pas mal de cases à cocher : Ce sont les différentes restrictions possibles pour cette table :
> Ouvrir/Exécuter : (pas active, car ce n'est que pour les
formulaires et états)
> Lire la structure : aller en mode création
> Modifier la structure : ajouter ou modifier des champs
> Administrer : Justement : C'est avoir le droit ou non de
changer ces autorisations dont nous sommes en train de nous occuper
> Lire les données : Ouvrir la table pour voir les données
> Modifier les données : Ouvrir la table pour modifier les
données
> Ajouter des données : Possibilité ou ou non d'ajouter de
nouveaux enregistrements (clients en l'occurence)
> Supprimer des données : En l'occurence : Supprimer des
clients
Bien. Et bien, nous allons nous couper l'herbe sous les pieds : Enlevez TOUTES les coches pour l'administrateur !
Maintenant, si on fait OK, on peut s'imaginer qu'on n'a même plus le droit de VOIR le contenu de la table, plus rien, nada !
ET BIEN NON... A notre grande surprise, on peut, tout autant qu'avant ouvrir la table T_Client... Il faut peut-être fermer Access et le rouvrir ? Non, non. Rien n'y fera...
En fait, dans Access, il n'y a pas que des utilisateurs : Il y a aussi des groupes. Et, chaque utilisateur fait partie d'un groupe. Ne vous inquiétez pas, on va apprendre à les créer, ces fameux groupes.
Mais avant celà, il faut savoir qu'il existe 2 groupes par défat lors de l'installation d'Access :
- Le groupe "Utilisateurs"
- Le groupe "Administrateurs"
Et, vous l'avez deviné, l'administrateur fait parte du groupe... des Administrateurs !
Alors donc, pour restreindre effectivement l'accès à T_Client, il faut AUSSI que le groupe des Administrateurs n'aie plus aucune case cochée pour la table T_Client :
- Allez dans Outils/Sécurité/Autorisations d'accès
- Cliquer sur le bouton radio Lister : Groupes
- Choisissez dans la Zone Nom d'utilisateur/Groupe : administrateurs
- Choisissez dans la partie de droite : T_Client
- Enlevez TOUTES les coches
Voilà... Là, au moins, ça devrait marcher : L'administrateur n'a plus aucun droit sur la table T_Client, et le groupe dans Administrateurs non plus. Cliquez sur OK
Essayez d'accéder à T_Client... MAIS MAIS MAIS... On peut ENCORE y accéder ! C'est infernal !
(mais peut-être que non, ça dépend. Admettons que vous arriviez encore à y accéder)
En fait, et c'est la dernière subtilité, je vous le jure... TOUS les utilisateurs, y compris l'administrateur, DOIVENT faire partie du groupe des Utilisateurs.... Voilà ou le bât blesse... Alors retournez dans Outils/Sécurité/Autorisations d'accès, et enlevez toutes les coches pour le groupe des Utilisateurs pour la table T_Client (vous savez comment faire maintenant)
Cette fois c'est bon ! Ouf ! Lorsque vous essayez d'ouvrir T_Client, vous obtenez le message d'erreur : "Impossible de lire les définitions; Pas d'autorisation de lecture des définitions pour la table ou la requête T_Client" (Message d'Access 2000 qui peut différer de 97)
Si vous n'avez pas ce message, vous avez sans doute loupé une étape.
Pour
mieux comprendre pourquoi il suffit de faire partie d'un groupe pour avoir des
autorisations, prenons un exemple bien réel. Imaginez que vous allez chercher
un billet de train. Vous demandez au guichetier si vous avez droit à une
réduction parce que vous vous appelez Marc Dupont. Il vous dit que non. Tout à
coup, vous lui sortez votre carte de membre de l'amicale les joueurs de Bowling
de Bordeaux. Il vous dit que ce groupe n'a pas de réduction non plus. Mais vous
l'informez que vous faites également partie des scouts. Alors, il vous Octroie
une réduction de 25%. Donc, Marc Dupont n'a pas de privilège, le groupe
"Bowling" non plus, mais le groupe "Scouts", a 25%, donc
Marc Dupont à une réduction de 25%.
Lorsque
vous voulez restreindre des droits de l'administrateur, vous devez restreindre
les droits de l'utilisateur Administrateur, du groupe des administrateurs ET du
groupe des Utilisateurs. Pour le moment, nous voici donc avec une base de
données TestSecu.MDB, pourvue d'une table T_Client, Contenant Dupont, et que
nous ne pouvons plus Accéder...
Ces restrictions ne vont pas faire long feu : L'administrateur étant en quelque sorte le bon dieu de la sécurité Access, il va pouvoir se remettre à lui même toutes les autorisations possibles sur T_Client, sans le moindre problème
Donc, jouer à se mettre et à s'enlever les autorisations à soi-même... Ce n'est pas très efficace. Imaginons Monsieur Boulier, Excellent comptable, mais qui n'a pas à fourrer son nez dans la liste des clients (sinon, il fait des remarques désagréables... ;-) )
Il s'agit donc de lui retirer SERIEUSEMENT tout accès à la table T_Client. En tant qu'administrateur, nous allons créer l'utilisateur Boulier, et l'empêcher d'entrer dans T_Client :
- Allez dans Outils/Sécurité/Gestion des utilisateurs et des groupes
- Cliquez sur l'onglet "Utilisateurs"
- Cliquez sur "Nouveau..."
- Nom : Boulier N° Personnel : 1111
et OK
(Ce n'est pas son mot de passe, c'est son PID (Personal
IDentifier), nous verrons plus tard à quoi ça sert)
Dans la liste déroulante "Nom :", vous pouvez dont maintenant choisir entre Administrateur et Boulier. Choissez Boulier
En bas dans "Membre du groupe", à gauche vous avez donc la liste des groupes, et a droite . "Utilisateur inscrit dans", vous avez la liste des groupes dans lequel Boulier est inscrit. Bon pour l'instant, il n'est inscrit que dans les Utilisateurs. D'ailleurs, si vous choisissez dans la liste "Nom :" Administrateur, vous verriez qu'il est inscrit dans les Utilisateurs ET dans les administrateurs.
Bien. Donc, monsieur Boulier fait partie des utilisateurs. Et comme le groupe de Utilisateurs n'a plus aucun droit sur la table T_Client, ça va simplifier les choses, car maintenant, il va s'agir de retirer TOUTES les coches d'autorisations pour Boulier également. Vous vous rappelez ? Outils/Sécurité/Autorisations d'accès etc... Allez-y, faites-le.(vous allez peut-être constater que Boulier n'avait aucune autorisation d'accès. Tant mieux)
Maintenant, quittez Access, et revenez dedans, revenez dans la base de données TestSecu, et entrez comme Nom : Boulier (pas administrateur)
Lorsque vous êtes entré, essayez d'aller dans T_Client... HO HO Mauvais gag... Vous ne pouvez pas ! Vous monsieur Boulier, on a OSE vous empêcher d'aller dans T_Client ! Votre sang ne fait qu'un tour, et comme vous n'êtes pas né de la dernière pluie, vous filez dans Outils/Sécurité/Autorisations d'accès, et vous vous remettez à vous même (Boulier), toutes les autorisations pour T_Client !
Sale surprise, Monsieur Boulier ! Lorsque vous cliquez sur OK, vous avez le message d'erreur : "Vous ne pouvez pas changer les autorisations pour T_Client. Pour changer les autorisations d'accès, Vous devez avoir l'autorisation Administrer, etc...".
Et voilà... Autant l'administrateur pouvait faire ce qu'il voulait, autant ce pauvre monsieur Boulier se voit fermer la porte de T_Client de manière ferme et définitive ! Qu'a donc comme solution monsieur Boulier ? Supplier à l'administrateur de bien vouloir lui donner un tout petit accès à T_Client...
Finalement, monsieur Boulier trouve que ce n'est pas si mal, toute cette sécurité. Il va en profiter. Quittez Access et Loguez-vous sous Boulier. Entrez dans TestSecu.
Créez une nouvelle table Dans laquelle vous mettez 2 champs : NomSalarie et Salaire. Sauvegardez sous T_Salaire, et entrez 2 enregistrements : Dupont, 4500 et Martin, 6800.
Le contenu de cette table est bien entenu tout à fait confidentiel. Le propiétaire de cette table est Boulier, car c'est lui qui l'a créé. On peut s'en rendre compte en allant dans :
Outils/Sécurité/Autorisations d'accès/Changer le propriétaire
T_Client appartient à l'administrateur, et T_Salaire appartient à Boulier.
En qualité de propriétaire, Boulier, peut en fait s'amuser à changer les droits sur sa table pour qui il veut. Nous allons voir ça : C'est à dire que nous allons créer un nouvel utilisateur Lagaffe. Comme Boulier n'a pas le droit de créer des nouveaux utilisateurs (vous pouvez essayer malgré tout rien que pour le fun), mais vous allez devoir quitter Access et revenir sous Administrateur (mot de passe adm si vous l'aviez oublié). Allez-y !
Revenez dans Access, dans Test Secu.MDB, et créez l'utilisateur Lagaffe, avec le N° personnel 2222, qui fera partie des Utilisateurs... Je suppose que vous savez comment faire (sinon, remontez dans ce document pour voir comment on a créé Boulier).... Allez-y ! (ne vous occupez pas des droits de Lagaffe sur T_Salaire)
Bien. Quittez Access, et revenez dans TestSecu sous Boulier.
HA HA HA ! Vous dites-vous, en tant que Boulier. Moi, je n'ai pas le droit d'aller voir les clients, mais je peux vous garantir que Lagaffe ne verra pas ma table T_Salaire !
Joignant le geste à la parole, vous sautez sur Outils/Sécurité/Autorisations d'accès, et vous enlevez hargneusement toutes les autorisations de Lagaffe sur votre table chérie T_Salaire ! (d'ailleurs, vous constatez sans doute qu'a la base Lagaffe n'avait aucun droit sur votre table). Tiens, pendant que vous y êtes, profitez-en pour vous assurez que le groupe des Utilisateurs n'a non plus aucun droit sur votre table T_Salaire.
Quittez Access et revenez dans Access, TestSecu, logué sous Lagaffe
Lagaffe essaie donc d'accéder à la table T_Salaire, et ... HO HO ... Message d'erreur. Impossible d'y accéder. Mais comme il connait un peu la sécurité, il va essayer de s'octroyer quelques droits sur T_Salaire... Mais vous pouvez essayer, c'est peine perdue, Access va refuser obstinément de donner des droits à Lagaffe...
Donc, Si Lagaffe veut accéder à la table T_Salaire, pas le choix, il faut qu'il s'adresse à Monsieur Boulier.
Mais attention : Il n'y a pas que le propriétaire qui peut modifier ses droits sur T_Salaire... Quels que soient les efforts consentis par Mr Boulier, l'administrateur pourra toujours se remettre les droits sur T_Salaire à lui-même... Oui, maiiiis, c'est un problème : Monsieur Boulier fait toute confiance quant aux compétences techniques de l'administrateur, mais il n'a AUCUNE envie que l'administrateur aie accès, ne fût-ce qu'en lecture à T_Salaire... Alors, on fait quoi ?
Les informations concernant la sécurité (L'administrateur, son mot de passe, Boulier, Lagaffe) sont stocké dans un fichier à part, nommé System.MDW (Microsoft Database Workgroup - Workgroup = Groupe de travail), et placé dans le dossier
C:\Program File\Microsoft Office\Office
Ce qui se passe, c'est qu'apparemment, quand on utilise ce System.MDW, on dirait bien que l'administrateur garde ses qualités "divines" contre vents et marées. Et, plus grave, (j'ai testé), admettons que Lagaffe s'empare simplement de TestSecu.MDB, et ramène cette base chez lui, il sera bien évidemment administrateur... Et donc, ce ne sera pas difficile pour lui de se remettre les droits sur la chère table T_Salaire de Boulier... C'est donc inacceptable.
Si je dis celà, c'est parce qu'en fait, on n'est pas obligé de se servir de Sysem.MDW. Il est possible de demander à Access d'utiliser un AUTRE fichier de groupe de travail.
Faisons-le.
Pour ce faire, vous devez exécuter un programme utilitaire installé dans
C:\Program Files\Microsoft Office\Office\1036
(Pour Access 2000. Je vous laisserai chercher le même fichier
pour la version 97)
et qui répond au doux nom de WRKGADM.EXE (Workgroup administration)
Lorsque vous lancez ce fichier, il vous informe que vous travaillez actuellement avec le fichier de groupe de travail System.MDW.
Nous allons en créer un nouveau. Cliquez sur Créer
Nom : Lechef
Compagnie : World Company
Identificateur : 1234
OK
Comme nom de fichier de groupe de travail, choisissez : C:\SECUWORLDCOMPANY.MDW
OK, et confirmez. Vous devriez avoir le message "Vous avez créé avec succès le fichier d'information de groupe de travail C:\SECUWORLDCOMPANY.MDW"
OK, et quitter Wrkadm.exe.
Dès maintenant, lorsque vous entrerez dans Access la prochaine fois, il va se référer à ce NOUVEAU fichier de groupe de travail SECUWORLDCOMPANY.MDW au lieu de SYSTEM.MDW. Ce qui fait que d'une part, vous n'aurez plus à vous identifier, puisque vous serez de nouveau administrateur, et que vous n'aurez pas de mot de passe, et, d'autre part, les utilisateurs Boulier et Lagaffe n'existeront plus...
OK. Entrez dans Access, et Ouvrez TestSecu.MDB. Vous ne devez pas entrez de mot de passe donc...
Bien
bien bien... Nous en sommes donc ici : Vous êtes administrateur (par défaut),
et vous venez d'entrer dans TestSecu.MDB. Si vous allez dans les options de
sécurité, vous constaterez que Lagaffe et Boulier ont disparu, ce qui est
normal, puisque vous utilisez maintenant le fichier de groupe de travail
nouvellement créé : Secuworldcompany.MDW (qui ne contient donc que
l'utilisateur Administrateur, le groupe Administrateurs et le groupe
Utilisateurs, qui sont les gens et les groupes par défaut qu'il y avait au
début, dans System.MDW). Dans ce TestSecu, vous avez donc 2 tables : T_Salaire,
qui appartient à Boulier, et T_Client, qui appartient à l'administrateur...
Lagaffe n'ayant rien.
Il se passe donc in phénomène fort intéressant dans Outils/Sécurité/Autorisations d'accès, onglet Changer le propriétaire : La table T_Client appartient bien à l'administrateur, mais T_Salaire appartient à ... Inconnu... Boulier n'étant pas inscrit dans Secuworldcompany.mdw.
Mais c'est ici que tout change : Vous, en tant qu'administrateur, même si vous ne vous êtes pas encore attribué un mot de passe, vous ne pouvez PAS du tout ouvrir T_Salaire, NI MEME changer vos droits sur T_salaire !
C'est seulement maintenant qu'on constate que Boulier est vraiment le maître de sa table...
Mais ce n'est pas tout. Admettons que notre administrateur aie donc eu la sagesse d'utiliser Secuworldcompany.mdw à la place du groupe de travail par défaut. Maintenant, admettons que Lagaffe, bien mal intentionné, s'empare de la base de données TestSecu.MDB : Et bien, même chez lui, il ne pourra PAS lire T_Salaire, ni s'octroyer des droits dessus.
Admettons qu'il s'empare également de Secuworldcompany.mdw pour le replacer chez lui, et l'utilise. A ce moment là, oui, il peut se loguer sous Boulier, et voir le contenu de T_Salaire. Ceci pour dire l'importance du mot de passe. Boulier A TOUT INTERET à se créer un mot de passe, car jusque-là, quand on se loguait sous Boulier, il n'y avait pas de mot de passe.
Bien bien, tout celà... Mais Lagaffe, décidément pas tombé de la dernière pluie, met en place un plan machiavélique : Il prend simplement la base de données TestSecu.MDB, et l'ouvre chez lui... Comme il est administrateur, il a le droit de créer tous les utilisateurs qu'il veut... Alors donc, il va recréer Boulier... HA HA HA ! Il fallait y penser... Le Hic, c'est que quand il va créer Boulier, il VA DEVOIR également mettre le MEME PID (N° d'identification) que le Boulier d'origine (si vous ne vous rappelez plus de quoi il s'agit, remontez dans le document, et allez revoir la création de Boulier, vous verrez qu'un moment, il y a ce fameux N° que l'on doit créer, et qui était alors 1111).
Voilà à quoi sert ce fameux numéro PID, à éviter qu'on recrée facilement un même utilisateur avec le même PID qui s'octroie les mêmes droits que l'original.
Et la boucle est bouclée. A ce stade, la base de données est parfaitement sécurisée, à tout points de vue ! Boulier peut dormir sur ses deux oreilles : On peut voler la base de données, mais personne, jamais, ne verra ce qui se passe dans la table T_Salaire !
Etonnant, non ?
PS : Pour réutiliser le fichier de groupe de travail par défaut, vous lancez Wrkadm.exe, et vous cliquez sur Joindre, et vous cliquez sur parcourir, pour rechoisir system.MDW