La sécurité sous Access n'est pas une notion intuitive. Il est nécessaire de comprendre profondément son mécanisme afin de pouvoir la mettre efficacement en oeuvre. Une sécurité mal comprise ou mal implémentée revient à acheter un coffre fort sans serrure.
Dans ce didacticiel, nous n'allons aborder que le thème de la sécurité au niveau utilisateurs et groupes. Nous n'allons pas parler du mot de passe de la base de données, de la génération des fichiers MDE ni du mot de passe attribué au projet VBA. Ces notions font pourtant partie intégrante de la sécurité, mais la gestion des utilisateurs et des groupes est, vous allez le voir, un chapitre à elle seule.
Voyez cette page pour accéder aux utilisateurs, groupes et objets avec VBA
Sommaire
- Situation de base
- Présentation de votre société fictive
- Création de la base de données
- Exigences de sécurité
- Présentation des utilisateurs et des groupes
- Structure minimale
- Création d'un nouvel utilisateur
- Création du mot de passe de base de l'Administrateur
- L'identification est liée à Access, pas à la base de données
- La "restriction permissive" d'accès aux objets
- Les genres de restrictions possibles
- Supprimer toutes les autorisations pour une table
- Les propriétaires
- Groupes de travail
- Numéros d'identification par défaut
- Création d'un nouveau groupe de travail
- Récupération des accès par l'administrateur
- Résumé (voici un résumé des étapes à respecter pour obtenir une sécurisation "absolue" de votre base de données)
- Lancement d'une base automatiquement avec un certain groupe de travail
- Cryptage de la base de données
- Remarques générales sur la sécurité
- Remarque a propos d'Access 2007
Vous venez de terminer la réalisation d'une base de données, vous vous apprêtez à la placer sur un lecteur de réseau afin de permettre aux utilisateurs d'y accéder simultanément (jusqu'à 255 en théorie). Mais attention ! Justement pas tous les utilisateurs, mais seulement les personnées autorisées !
Nous allons voir comment il va être possible de préciser quels sont les utilisateurs qui ont le droit de faire quoi dans quel objet... Untel aura le droit de consulter telle table, mais pas telle autre. Unetelle n'aura pas le droit de visualiser telle table, mais aura le droit de voir et même d'effacer des enregistrement dans tel autre... Untelautre aura le droit d'exécuter telle macro, mais pas d'ouvrir tel formulaire.
Si votre souci est de simplement attribuer un mot de passe à la base de données (soit on a accès à tout, soit à rien), ce didacticiel n'est pas pour vous, car il suffit d'attribuer un mot de passe avec le menu Outils/Sécurité/Définir le mot de passe de la base de données.
Présentation de votre société fictive
Imaginons une petite entreprise : Fournitout, dirigée par André Manitou. Vous vous appelez Bernard Legrand et vous êtes l'administrateur du réseau et le fier auteur d'une base de données nommée Comptaciel.mdb que vous avez développé pour le service comptabilité. C'est la cheffe comptable, une dame pointilleuse, Céline Duchiffre qui vous l'a commandé. Elle travaille avec son apprenti, un certain Denis Gouillon (pas toujours très réveillé !). Il faut savoir que dans le département marketing, un certain Eugéne Petimalin a reçu dernièrement un blâme, et on craint qu'il tente un coup tordu !
Nous allons réduire au strict minimum la structure de cette base de données afin de facilement comprendre l'interaction entre les objets, les utilisateurs et les groupes. Les objets représentent les tables, requêtes, formulaires, états et macros (Modules exclus)
Céline Duchiffre vous a donc demandé de développer pour son service, une base de données de gestion des salaires et des dépenses de la société. On comprend que les données salariales sont plus confidentielles que les dépenses.
Création de la base de données
Vous avez alors créé Comptaciel.mdb, composée comme suit :
(Vous pouvez télécharger cette base de données ici)
Deux tables :
Deux requêtes, respectivement basées sur T_Depense et T_Salaire :
Deux formulaires, respectivement basées sur T_Depense et T_Salaire :
Et un état, basé sur la requête R_PetitSalaire, elle-même basée sur T_Salaire :
Lors de la livraison de la base de données, Céline Duchiffre précise qu'elle doit pouvoir accéder sans restriction à tous les objets, mais que son assistant Denis Gouillon n'a pas le droit de voir les salaires, mais qu'il a seulement l'autorisation de visualiser les dépenses sans rien pouvoir y changer.
Eugène PetiMalin n'a évidemment aucun droit dans cette base de données !
Le directeur André Manitou peut accéder théoriquement à la base de données, mais il n'a pas le temps de s'y intéresser.
Reste le délicat problème du concepteur de la base de données, c'est à dire vous, Bernard Legrand.
En effet, vous avez conçu la base et avez donc les pleins pouvoirs. Mais tout administrateur de réseau/concepteur de bases de données que vous êtes, vous n'avez pas forcément droit de regard sur des données confidentielles telles que les salaires !
Il vous faudra à un moment donné "passer les clés". Nous admettons que les données que vous pouvez voir dans les salaires actuellement ne sont que des données de test, qui seront corrigées ultérieurement par Céline Duchiffre, une fois que la sécurité sera correctement implémentée.
Tout ceci est possible ! Je ne prétends pas que ça va être simple, mais si vous suivez scrupuleusement le mode d'emploi qui suit, vous devriez arriver à vos fins.
Présentation des utilisateurs et des groupes
Lorsqu'on ne s'est pas encore occupé de la sécurité, toute personne utilisant Access s'appelle Administrateur, et fait partie de deux groupes à la fois : le groupe Administrateurs et Utilisateurs.
Pour vous en convaincre, ouvrez Access (mais nul besoin d'ouvrir une base de données), et allez dans le menu Outils/Sécurité/Gestion des utilisateurs et des groupes.
Vérifiez votre propre identité
Vous constatez qu'à côté du nom "Administrateur",
il y a une petite flèche qui vous permet de choisir quelqu'un d'autre.
Pour savoir qui vous êtes sans amiguité, cliquez sur l'onglet "Changer
le mot de passe" : 
Vous pouvez également voir qui vous êtes en allant dans le menu Outils/Sécurité/Autorisations d'Accès :
Nous allons apprendre à gérer les utilisateurs et les groupes, mais avant ça, il faut juste garder à l'esprit la structure minimale de la sécurité :
La structure par défaut du modèle de sécurité Access est donc la suivante :
Création d'un nouvel utilisateur
Rendez-vous dans le menu Outils/Sécurité/Gestion des utilisateurs et des groupes
Dans l'onglet Utilisateurs, cliquez sur Nouveau... Ecrivez votre nom (legrand) , mettez un numéro personnel, disons 1111 pour faire simple, et cliquez sur OK.
Le numéro personnel n'est PAS votre mot de passe. C'est en quelque sorte votre "empreinte génétique", celle qui pourra prouver par la suite que vous êtes le bon Legrand, et pas un usurpateur, mais nous verrons ça plus tard. (Constatez que Administrateur n'ayant pas été créé par nous, il semble ne pas avoir de numéro personnel. C'était juste une remarque en passant, vous comprendrez plus bas pourquoi je dis ça)
Pour l'instant, sachez juste que le numéro d'identification est obligatoire, se compose de lettres, chiffres ou signes de ponctuation, et qu'il doit comporter entre 4 et 20 caractères.
Vous pouvez à présent sélectionner l'un ou l'autre des
utilisateurs. 
Lorsque vous choisissez legrand, vous constatez qu'il
est alors inscrit dans le groupe des utilisateurs :
Maintenant, vous allez pouvoir vous "loguer" au choix sous Administrateur ou legrand. Pour ce faire, quittez Access. Revenez dans Access. Tiens... rien ne se passe ? Ouvrez votre base de données Comptaciel et... Il ne m'est toujours pas demandé de m'identifier.
Création du mot de passe de base de l'Administrateur
En réalité, ce n'est pas le fait d'avoir créé un utilisateur qui va faire apparaître la fenêtre de login (Et pourtant, ça m'aurait semblé plus logique). C'est le fait d'imposer un mot de passe à l'utilisateur Administrateur. Toute la sécurité à partir de maintenant se base sur ce simple fait.
Cliquez sur l'onglet Changer le mot de passe.
Comme il n'y avait pas de mot de passe auparavant, vous ne mettez rien dans l'ancien mot de passe, et vous écrivez adm comme nouveau mot de passe, et vous le confirmez. Cliquez sur OK.
Inutile de préciser qu'adm est un mot de passe très mauvais. Un bon mot de passe se compose de 8 caractères au minimum, et de préférence avec lettres et chiffres mélangés. Il semblerait que la limite de longueur d'un mot de passe soit de 14 caractères. Faites attention à certaines détails tels que les accents par exemple : si vous installez un mot de passe pourvu d'accent, et que vous devez vous loguer à l'occasion depuis un PC dont le clavier est américain, vous n'aurez pas d'accent disponible. Soyez également attentif à ce que la touche VERR MAJ ou CAPS LOCK (Majuscules) ne soit pas enfoncé.
Quittez Access. Rouvrez Access. A ce stade, il ne vous demande
pas encore de vous loguer, mais lorsque vous allez ouvrir Comptaciel.mdb,
c'est alors qu'il va vous présenter la boîte de dialogue suivante
: 
Vous devrez bien entendu écrire adm comme mot de passe. Attention ! Les minuscules et majuscules sont importantes.
L'identification est liée à Access, pas à la base de données
Il est crucial de comprendre que votre identification en tant qu'Administrateur est liée à votre poste de travail et pas à la base de données elle-même. En d'autres termes, si vous fermez et rouvrez Access, vous devriez avoir sous les yeux la boîte de login "Ouverture de session" présentée ici plus haut.
Or, bizarrement, ce n'est pas le cas ! Vous devez ouvrir une base de données pour que cette boîte de dialogue apparaisse ! Notez bien que je n'ai pas dit d'ouvrir Comptaciel expressément. L'ouverture de n'importe quelle base de données provoquera la demande d'identification. A vrai dire, même la création d'une nouvelle base de données provoque l'affichage de cette boîte ! Tout prête à penser que l'identification est liée à la base de données.
Il m'aurait paru plus logique que cette boîte de dialogue apparaisse dès le démarrage d'Access ! En fait, c'était le cas pour Access 97 et les versions précédentes. Je ne sais pas pourquoi Microsoft a modifié l'instant d'apparition de cette demande d'identification.
L'identification est donc liée a votre licence d'Access personnel. Si vous placez Comptaciel sur un lecteur réseau et que vous essayez de l'ouvrir depuis votre poste, le login vous sera demandé, tandis que sur un autre poste, il ne vous sera rien demandé du tout, et vous serez Administrateur.
Vous pouvez donc maintenant vous loguer indifféremment avec Administrateur ou legrand (Contrairement au mot de passe, les minuscules ou majuscules n'ont pas d'importance pour le nom). Si vous désirez tester ceci, quittez Access, rouvrez Access, et ouvrez Comptaciel (ou n'importe quelle autre base). Loguez-vous sous legrand. Attention : Legrand n'a pas de mot de passe (Ce n'est PAS 1111, je le rappelle).
Pour constater que vous êtes bien legrand, je vous rappelle qu'il faut aller dans le menu Outils/Sécurité/Gestion des utilisateurs et des groupes, et cliquer sur l'onglet "Changer le mot de passe".
Profitez-en pour lui attribuer le mot de passe leg.
Nous constatons donc à ce niveau que la sécurité n'est pas du tout accomplie, Mais avant de nous occuper de cet état de fait, nous allons parler de la restriction d'accès aux objets.
La "restriction permissive" d'accès aux objets
Il s'agit maintenant de restreindre l'accès aux objets, notamment les tables, car s'il nous est interdit de voir le contenu d'une table, on ne peut pas non plus ouvrir une requête, un formulaire ou un état basé sur cette même table.
Avant de créer d'autres utilisateurs, nous allons essayer de nous "couper l'herbe sous les pieds", c'est à dire, nous auto-interdire de voir la table T_Salaire.
Les permissions d'accès aux objets sont données aux utilisateurs et aux groupes.
Le système de restrictions utilisé par Access est un système permissif. C'est à dire que si l'accès à la table T_Salaire est interdit à un utilisateur, mais qu'il fait partie d'un groupe qui, lui, a l'autorisation nécessaire, alors donc, la personne POSSEDE le droit du groupe.
On peut très bien imaginer une personne faisant partie de 5 groupes : la personne est interdite d'accès à T_Salaire, ainsi que 4 groupes sur les 5, mais si le dernier groupe lui permet l'accès, alors, la voie est libre !
Pour définir les règles de restriction d'accès aux objets d'une base de données, il faut évidemment que celle-ci soit ouverte.
Quittez Access, rouvrez-le, et rouvrez Comptaciel en vous loguant sous Administrateur.
Rendez-vous dans le menu Outils/Sécurité/Autorisations d'Accès.
Dans l'onglet Autorisations d'accès, cliquez sur Administrateur à gauche, sur T_Salaire à droite, et regardez toutes les coches du bas.
Ce sont les autorisations accordées à l'utilisateur Administrateur : il a tous les droits, en clair !
Les genres de restrictions possibles
Lire la structure
L'utilisateur a-t-il le droit de visualiser la table T_Salaire
en mode création
Modifier la structure
A-t-il le droit de modifier la structure des champs de T_Salaire,
d'en ajouter ou d'en enlever
Administrer
A-t-il le droit de faire ce que nous faisons actuellement : à savoir
mettre ou enlever les coches (nous "administrons" la table T_Salaire)
Lire les données
L'utilisateur a-t-il le droit de visualiser les données de la table,
c'est à dire voir les salaires
Modifier les données
A-t-il le droit de changer les salaires ?
Ajouter des données
A-t-il le droit d'ajouter du personnel (de nouvelles lignes dans la table) ?
Supprimer des données
Peut-il effacer des lignes dans la table ? Nous parlons bien de lignes complètes.
S'il a l'autorisation Modifier les données,
il pourra modifier les champs en les effaçant simplement
Les tables sont les objets les plus importants à sécuriser.
Vous constatez qu'il est possible de choisir d'autres objets à sécuriser
: 
. Mais si la table
T_Salaire est protégée, nul besoin de
bloquer également la R_PetitSalaire. On ne peut
pas biaiser la sécurité ainsi. Il serait trop simple de créer
une requête basée sur une table protégée pour visualiser
des données interdites, bien sûr.
Solidarité des coches
Constatez que certaines coches sont solidaires avec d'autres. Par exemple, si vous ôtez la coche Lire la structure, toutes les autres coches disparaissent également pour des raisons qui m'échappent parfois. Par exemple, il est impossible de donner l'autorisation de lire les données sans donner l'autorisation Lire la structure... Je reste perplexe !
Par contre, il me parait totalement logique de lier les deux coches Lire les données et Modifier les données. En effet, il me paraît difficilement concevable de modifier des données sans pouvoir les lire. Mais pouvoir les lire sans pouvoir les modifier est possible. Essayez, ça marche très bien.
Je vous laisse vous amuser à cocher et décocher les cases de manière à prendre en compte ce système de solidarité de certaines coches avec d'autres.
Nous allons maintenant supprimer toutes nos propres autorisations. Je vous rappelle notre schéma :
Nous sommes Administrateur, et nous faisons partie de facto de deux groupes : Utilisateurs et Administrateurs. Il va donc falloir ôter TOUTES les autorisations sur T_Salaire pour Administrateur, Administrateurs et Utilisateurs.
Supprimer toutes les autorisations pour une table
Marche à suivre :
Allez dans le menu Outils/Sécurité/Autorisations d'Accès
Choisissez le bouton radio Utilisateurs, choisissez à gauche Administrateur, et à droite T_Salaire. Décochez toutes les cases, cliquez sur Appliquer.
A ce stade, si vous cliquez sur OK pour fermer la boîte de dialogue, vous constaterez que vous avez toujours accès a la table T_Salaire. Il s'agit maintenant de supprimer les autorisations pour T_Salaire à la fois pour le groupe Utilisateurs et Administrateurs :
Il suffit de mettre le bouton radio sur Groupes, et refaire l'opération avec Administrateurs :
Et encore la même chose avec le groupe des utilisateurs :
Maintenant que vous avez cliqué sur OK, vous vous retrouvez dans votre base de données, mais si vous double-cliquez sur la table T_Salaire, vous avez un message d'interdiction :
Si vous pouvez toujours ouvrir la table, refaites très consciencieusement les étapes ci dessus : il est très facile d'oublier une coche, un utilisateur ou un groupe.
L'administrateur se procure les privilèges à lui-même
Le hic, c'est que comme Administrateur est le maître absolu de la base de données, il peut très bien cocher les cases qu'il désire, et se remettre les autorisations qu'il veut pour tout objet.
Pour tenter de remédier à ça, nous allons étudier la notion de propriété.
Au-delà de l'utilisateur Administrateur et du groupe Administrateurs, il faut savoir que chaque objet (Table, requête, formulaire, état, et même la base de données en globalité) appartient à quelqu'un.
Par défaut, tous les objets appartiennent à la personne qui a créé la base de données, c'est à dire Administrateur.
Prenez soin de vous loguer sous Administrateur,
Ouvrez Comptaciel, rendez-vous dans le menu Outils/Sécurité/Autorisations d'Accès, et cliquez sur l'onglet Changer le propriétaire.
Vous constatez slors que le propriétaire des deux tables
est Administrateur : 
En observant cette boîte de dialogue, vous constatez qu'il
est possible de choisir d'autres objets de la base de données, et, pour
chacun d'eux, de sélectionner le propriétaire dans la liste déroulante
Nouveau propriétaire : 
.
Dans le chapitre précédent, nous avons conclu que le système de sécurité comportait une faille énorme : l'Administrateur pouvait se mettre et se retirer toutes les autorisations à sa guise.
Don d'un objet à un autre utilisateur
Attention : la procédure suivante ne va pas fonctionner correctement, mais il est nécessaire de la suivre pour comprendre la suite.
Administrateur va donc donner T_Salaire à Céline Duchiffre. Une fois que T_Salaire lui appardiendra, nous allons quitter Access, et nous reloguer sous duchiffre. Mme Duchiffre va alors elle-même prendre soin de retirer toute autorisation à Administrateur.
On s'attend alors légitimement à ce qu'Administrateur ne puisse plus se remettre lui même les autorisations pour T_Salaire.
Marche à suivre :
avec le N° personnel
1111. 
(Cliquez sur OK)
.
Ce qui va donner : 
Fermez et rouvrez Access. Rouvrez Comptaciel en vous loguant sous Administrateur. Lorsque vous essaierez d'ouvrir T_Salaire, vous aurez effectivement le message suivant :
Impossible de lire les définitions; pas d'autorisation de lecture des définitions pour la table ou la requête 'T_Salaire'. Céline Duchiffre a dont bien réussi à modifier les autorisation de l'Administrateur.
MAIS... En tant qu'Administrateur, vous avez toujours la possibilité de vous rendre les autorisations qui vous ont été supprimées par Céline Duchiffre !
C'est assez troublant, mais c'est ainsi. Il faut savoir que la personne qui a la mainmise inconditionnelle sur la base de données n'est pas la propriétaire de la table, et pas forcément l'administrateur, mais le propriétaire de la base de données.
Vous pouvez visualiser le propriétaire de la base de données
ici : 
En tant qu'Administrateur, vous devriez donc ainsi pouvoir donner carrément toute la base de données à Céline Duchiffre, ce qui réglerait probablement le problème de l'administrateur qui a trop de pouvoir.
Impossibilité de changer le propriétaire de la base de données
En réalité, et pour une raison que j'ignore, il
est impossible de donner une base de données à qui que ce soit.
Même si on est soi-même Administrateur
et créateur de la base de données, on ne peut pas la donner. Le
bouton reste toujours grisé : 
Le propriétaire d'une base de données est simplement et forcément celui qui l'a créé.
Ainsi donc, si on se logue sous duchiffre, et qu'on crée une base de données avec tables, requêtes, etc., cette base de données appartiendra à duchiffre. Céline Duchiffre pourra alors à loisir donner et reprendre les autorisations sur ses objets, et les autres utilisateurs, y compris Administrateur.
Le propriétaire n'a pas le pouvoir absolu
On pourrait alors penser que le propriétaire d'une base de données est seul maître à bord.
Marche à suivre :
Tentatives d'accès infructueuses d'Administrateur
1. On constate qu'effectivement, lorsqu'on essaie d'ouvrir T_ListeDuchiffre, nous obtenons un message d'erreur "Impossible de lire les définitions"
2. Lorsqu'on essaie alors de s'attribuer à soi-même, Administrateur, les autorisations sur T_ListeDuchiffre, un message d'erreur nous indique que ce n'est pas possible (Vous ne pouvez pas changer les autorisations pour T_ListeDuchiffre)
3. Essayons enfin de nous remettre nous-même, Administrateur, dans le groupe des Administrateurs. Vous constatez que ce n'est pas possible : les boutons sont grisés, inutilisables :
C'est alors qu'on s'imagine que le problème de la sécurité vient d'être réglé. En réalité, pas vraiment ! Pour en parler, il faut que je vous parle de la notion de groupe de travail par défaut.
Le groupe de travail est une sorte de base de données spéciale avec l'extension MDW (Microsoft Database Workgroup). C'est dans cette base de données que sont consignés les noms des groupes et des utilisateurs, ainsi que leurs identificateurs (1111 dans nos exemples) et leurs mots de passe.
Actuellement, vous utilisez sans le savoir un groupe de travail nommé system.mdw (ou system1.mdw, system2.mdw, ... systemX.mdw), ça dépend du nombre de fois que vous vous êtes amusés a faire des tests de sécurité tels que ceux que je vous propose dans ce didacticiel.
Groupe de travail par défaut
Vous pouvez voir exactement de quel fichier il s'agit et où il se trouve en allant dans le menu Outils/Sécurité/Administrateur de groupe de travail.
Dans les versions d'Access 97 et antérieures, ce menu n'existait pas. Il fallait aller chercher soi-même un utilitaire qui s'appelle wrkgadm.exe et qui se trouvait dans le même dossier que msaccess.exe.
Je constate que j'utilise (inconsciemment) system5.mdw, qui se trouve dans mon profil (C:\Documents and Settings\Michel\Application Data\Microsoft\Access).
A partir de maintenant, je vais appeler ce fichier systemX.mdw, puisque le numéro ne sera pas forcément le même chez vous et chez moi.
Visualisation du contenu de systemX.mdw
C'est donc ce fichier systemX.mdw qui contient les précieuses données d'identification. C'est une base de données comme une autre, mais cryptée et protégée. Si ça vous amuse, vous pouvez très bien l'ouvrir, mais vous serez dans l'impossibilité totale de modifier quoi que ce soit dans les tables. Attention : Les tables sont invisibles. Pour les visualiser, une fois la base de données systemX.mdw ouverte, vous devez aller dans le menu Outils/Options/Affichage, et cocher "Objets systèmes".
Voici en gros ce que cette base de données contient comme tables :
Vous constatez que certaines données sont cryptées, tels que les mots de passe. Et toutes les tables sont verrouillées de manière interne d'une manière sans doute très différente de la méthode que nous sommes justement en train d'apprendre. Heureusement qu'on ne peut pas manipuler ces données, ou voir les mots de passe en clair ! C'aurait été une sacrée faille de sécurité...
Destruction du groupe de travail par défaut
C'est maintenant que je vais vous expliquer la faille de sécurité annoncée plus haut. Si vous détruisiez purement et simplement ce fichier systemX.mdw, Access ne sourcillerait pas : il perdrait simplement les groupes et utilisateurs créées par vous, ainsi que le mot de passe de Administrateur. Il recréerait alors à la volée un nouveau fichier systemX.mdw, avec à nouveau les indispensables groupes Administrateurs et utilisateurs, et réinstallerait l'utilisateur Administrateur dans ces deux groupes de base.
Il faut bien entendu qu'Access soit fermé pendant que vous détruisez systemX.mdw.
En détruisant systemX.mdw, vous détruisez donc du même coup duchiffre et tout ce qu'elle a accompli au niveau sécurité. C'est à dire que duchiffre avait retiré toutes les autorisations de Administrateur pour la table T_ListeDuchiffre, mais cette restriction est maintenant perdue : Administrateur peut maintenant accéder à T_ListeDuchiffre sans le moindre problème !
C'est ainsi que vous avez la preuve que les autorisations sont stockées dans SystemX.mdw, et non pas dans Comptaciel.mdb, Mais nous verrons que cette assertion va s'avérer à moitié fausse un peu plus tard.
On peut penser qu'il faut déjà bien connaître le mécanisme de sécurité d'Access pour penser à supprimer SystemX.mdw, et que la sécurité est déjà un peu établie malgré cet état de fait. Mais pensez qu'un utilisateur indélicat (Eugène Petimalin par exemple) peut s'envoyer la base de données par e-mail chez lui, à la maison, et comme il n'emportera certainement pas SystemX.mdw, il se retrouvera de facto Administrateur, et sera même peut être surpris de constater que tout à coup, il a accès à tous les objets de la base sans la moindre manipulation supplémentaire !
Vous pouvez détruire tous les fichiers qui s'appellent System1.MDW, System2.MDW, etc. qui se trouvent dans C:\Documents and Settings\Votre nom\Application Data\Microsoft\Access, car nous allons parler de la création de groupes de travail.
Clé de registre contenant le groupe de travail
Pour information, le fichier de groupe de travail (Version Access 2003) est défini dans la base de registre (Démarrer/Exécuter : Regedit) à cette clé :
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Access\Jet\4.0\Engines\SystemDB
Numéros d'identification par défaut
Au début de ce didacticiel, vous avez dû entrer un mot de passe pour Administrateur (adm). C'était la première et indispensable personnalisation pour s'occupper de la sécurité.
Lorsque vous avez créé duchiffre, vous avez dû entrer un numéro personnel d'au moins 4 caractères (1111).
Ces deux concepts (Mot de passe et numéro d'identification) sont donc différents.
Au départ, il y a donc un groupe de travail SystemX.mdw, qui contient un utilisateur Administrateur, sans mot de passe, dont le numéro d'identification n'est pas connu, mais qui est le même pour tous les utilisateurs d'Access du monde.
Il fait partie des groupes Utilisateurs et Administrateurs, qui possèdent également un numéro personnel inconnu, mais dont j'ignore s'ils sont les mêmes sur tous les ordinateurs (possédant Access) du monde.
Lors de la destruction de SystemX.mdw, l'utilisateur Administrateur et les groupes Administrateurs et Utilisateurs seront spontanément recréés.
Il faut savoir que SystemX.mdw possède également une "empreinte" : Le nom du créateur de ce groupe de travail, l'organisation de laquelle il fait partie, ainsi qu'un numéro personnel de 4 caractères minimum.
Vous ne connaissez pas non plus ces informations, car lors de l'utilisation de ce groupe de travail par défaut, ces informations, sont aussi inconnues, mais toujours les mêmes sur toute installation Access du monde.
En résumé, avant l'implémentation de la sécurité, Access vous considère comme le même Administrateur partout dans le monde. Une sorte de "dieu omnipotent", ce qui explique pourquoi cet Administrateur (vous) peut perpétuellement se rendre les autorisations perdues !
Nous avons vu plus haut, lorsque nous avons parlé des propriétaires, que le fait de se loguer sous duchiffre et de retirer Administrateur du groupe des Administrateurs reste sans effet : Il suffit de détruire le groupe de travail par défaut, et Access recrée un nouveau groupe de travail SystemX.mdw, et Administrateur se retrouve à nouveau dans le groupe des Administrateurs, ce qui lui permet de recouvrer toutes les autorisations qu'il décide sur n'importe quel objet.
Création d'un nouveau groupe de travail
Afin de compléter la sécurité de manière fiable, il est indispensable de créer un Groupe de travail personnalisé.
Vous êtes donc maintenant lié au groupe de travail que vous venez de créer.
Rappelez-vous plus haut dans ce didacticiel, lorsque vous avez créé l'utilisatrice duchiffre, vous avez dû lui octroyer un numéro personnel (1111). Maintenant, vous venez de constater que lors de la création d'un nouveau groupe de travail, vous avez dû donner non pas deux mais trois informations : Le nom, la société et un numéro d'identification.
Maintenant, il y a une grosse différence entre les groupes de travail par défaut, et Coffre.mdw. Coffre.mdw possède une sorte "d'empreinte digitale", que sont la conjonction des nom, Société et Numéro d'identification.
C'est à dire que jusque là, Administrateur, et le groupe Administrateurs étaient liés à un groupe de travail sans cette empreinte.
Ainsi, duchiffre avait beau, tout propriétaire qu'elle était, retirer les autorisations à Administrateur ou au groupe des Administrateurs, Administrateur pouvait sans cesse se rendre toutes les autoirisations qu'il voulait.
Admettons la situation suivante : duchiffre a créé justement Coffre.mdw, avec son nom, le nom de la société (Fournitout), ainsi qu'un numéro d'identification connu par elle seule. Elle s'est installée dans le groupe des administrateurs, et a viré Administrateur du groupe des administrateurs. Elle a alors créé une base de données, et a supprimé toutes les autorisations d'accès à toutes ses tables pour Administrateurs et Administrateur.
Un jour, Céline Duchiffre démissionne. Elle est très fâchée pour des questions qui ne nous intéressent pas, et quitte sa place de travail instantanément sans même dire au revoir. Denis Gouillon est un peu perdu car il n'a pas accès aux tables de la base de données, et vous appelle, Bernard Legrand, afin que vous lui donniez au moins l'accès en lecture aux tables.
Mais vous avez alors beau vous loguer en tant qu'Administrateur (si tant est que vous en ayez le mot de passe...), vous n'aurez pas accès à ses tables. Vous ne pourrez pas non plus vous attribuer les accès nécessaires à la table, et ne pourrez pas non plus vous réinscrire dans le groupe des Administrateurs.
Vous quittez Access et détruisez alors purement et simplement Coffre.mdw, puis rouvrez Access. Access recrée donc un groupe de travail par défaut, et vous êtes de facto Administrateur, faisant partie du groupe des Administrateurs.
C'est ici que la sécurité Access est pleinement efficace : Access constate que vous êtes effectivement Administrateur, mais pas celui qui correspond au groupe de travail, et vous n'avez donc accès à aucun objet.
Il vous reste alors trois solutions, mais pour chacune d'elle, il va falloir obtenir des informations confidentielles sensées être entre les mains de Céline Duchiffre :
Récupération des accès par l'administrateur
Et la boucle est ainsi bouclée.
En résumé de tout ce que nous avons vu dans ce didacticiel, voici les étapes à respecter pour obtenir une sécurisation "absolue" de votre base de données :
Dès maintenant, seule Céline Duchiffre aura loisir d'autoriser qui elle veut à n'importe quel objet. Elle doit maintenant s'assurer également que le groupe Comptabilité soit vierge de toute autorisation, et elle pourra, avec votre aide technique, créer l'utilisateur gouillon de manière à ce qu'il puisse accéder en lecture seule à l'unique table T_Depense. A moins qu'elle ne décide d'octroyer cette autorisation à tout le groupe Comptabilité, en cas d'engagement d'autres personnes.
Mais il ne s'agit alors plus de technique, mais de stratégie, ce qui est un tout autre sujet.
Lancement d'une base automatiquement avec un certain groupe de travail
Voici maintenant une petite astuce pour lancer Access avec une certaine base de données et un certain groupe de travail : Créez un nouveau raccourci, que ce soit sur le bureau ou dans le menu démarrer, voici les propriétés :
"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "D:\Dossier\NomBase.mdb" /wrkgrp"D:\AutreDossier\CoffreFort.mdw"
Cryptage de la base de données
Toute cette sécurité, aussi fiable soit-elle, possède un talon d'Achille extrêmement sensible., En effet, il est possible d'ouvrir la base de données avec un simple traitement de texte, tel que Word. Regardez l'image ci-jointe : J'ai ouvert Comptaciel.mdb avec Word, et j'ai simplement été dans le menu Edition/Rechercher : stylo. Je suis alors tombé sur un élément de la table T_Depense :
Nous pouvons ainsi lire des informations telles que "Agrafes", "Caps.. cafÜ", "Bo te de 100 enveloppes", etc. Ce n'est pas très lisible, mais toujours est-il que de cette manière, n'importe quel utilisateur peut ainsi fouiner très indiscrètement dans les données de la base, aussi confidentielles soient-elles.
Il est donc indispensable de rendre cette opération impossible. Pour ce faire, nous allons crypter la base de données. C'est à dire qu'Access va transformer la base de données sur le disque dur de manière illisible pour les utilisateurs, et va se charger de décrypter la base dès qu'on l'ouvrira correctement, avec Access, en entrant le nom d'utilisateur duchiffre et le bon mot de passe.
Pour ce faire, ouvrez la base avec Access en vous loguant sous duchiffre, et rendez-vous dans le menu Outils/Sécurité/Coder-décoder une base de données. Vous devrez alors sélectionner un autre nom pour la base (ComptacielCrypte.MDB par exemple), et OK.
Une fois l'opération terminée, vous serez toujours dans Comptaciel.MDB. Vous aurez alors simplement à ouvrir ComptacielCrypte.MDB pour voir la nouvelle base ainsi Cryptée. En fait, vous aurez simplement l'impression que strictement rien ne s'est passé.
Mais si vous ouvrez Word, et que vous ouvrez ComptacielCrypte.MDB, et que vous allez dans le menu Edition/Rechercher : stylo, vous ne le trouverez simplement pas...
Cette fois enfin, toutes les failles ont été colmatées. On se retrouve dans un environnement sécurisé, et Céline Duchiffre peut dormir sur ses deux oreilles. Vous aussi.
Vous pourrez alors simplement effacer Comptaciel.MDB, et renommer ComptacielCrypte.MDB en Comptaciel.MDB pour n'avoir plus à disposition que la base cryptée. D'après ce que j'ai pu lire, mais pas tester, il semblerait (mais ça paraît logique) qu'une base de données cryptée voit ses performances décroître en terme de vitesse.
Remarques générales sur la sécurité
Ce didacticiel n'avait d'autre ambition qu'éclairer la partie technique de la sécurité Access au niveau utilisateurs, groupes et objets. Gardez à l'esprit que Céline Duchiffre peut tomber malade, donner son congé, effacer des données par erreur, oublier son mot de passe etc. Eugène Petit Malin pourrait essayer de trouver le mot de passe de Céline, chercher des utilitaires pour casser les mots de passe sur le web... Mais le disque dur peut aussi tomber en rade, Denis Gouillon pourrait imprimer des tables et laisser trainer les résultats sur son imprimante, laisser distraitement la base ouverte alors qu'il va boire un café, etc. Les fuites de données confidentielles, les blocages, des problèmes humains et matériels représentent une partie considérable de temps, d'énergie, de compétence, de budget et de formations.
Rappelez-vous toujours que la sécurité est une affaire globale et qu'il ne sert à rien d'installer une porte blindée à votre appartement s'il suffit de casser un carreau dans la cuisine pour entrer chez vous.
Access 2007 n'utilise plus le moteur de bases de donbnées Jet. L'extension tulisée n'est d'ailleurs plus MDB, mais ACCDB. Access 2007 peut très bien continuer, sous l'apparence de sa nouvelle interface (avec le ruban), à gérer les bases de données aux formats MDB (quelle que soit la version antérieure à 2007), et ainsi continuer à gérer la sécurité au niveau utilisateur.
Mais si vous convertissez une base de données au nouveau format ACCDB, la sécurité au niveau utilisateur (ainsi que la réplication) n'existent plus. Elle a tout simplement été supprimée sans autre forme de procès. Pourquoi alors utiliser ce nouveau format ACCDB ? Car il y a d'autres innovations telles que les pièces jointes ou les champs multi-valués qui peuvent s'avérer moins pratiques.
Toujours est-il qu'on est alors en droit de se demander s'il n'est pas alors bien facile de faire sauter toutes la machinerie mise en oeuvre dans cette page en convertissant tout bonnement une base de données, ausi sécurisées soit-elle, en Access 2007. La réponse est non ! Heureusement ! J'ai testé. J'ai suivi scrupuleusement la mise en oeuvre propre de la sécurité telle qu'elle est décrite au chapitre "Résumé". J'ai ensuite transféré cette base de données sur un ordinateur distinct, avec Vista et Office 2007. J'ai essayé d'ouvrir cette base sécurisée, étant alors Administrateur par défaut, mais Access ne voulait pas. J'ai alors essayé de convertir cette base au format 2007 (ACCDB), mais un message d'erreur sans appel m'informet que si je ne suis pas duchiffre, point de salut. La sécurité est donc bel et bien (a ce niveau/apparemment) exempte de faille.