La Sécurité dans Access [Débat]

[Maxence HUBICHE]

Que pensez-vous de la sécurité d'Access ?

Ceci est un débat de fond qui a débuté dans les arcanes du forum des modérateurs Access.
Nous vous proposons de le continuer.

N'hésitez pas à voter

[bidou]

Je ne vais parler la que de la sécurité Access utilisateurs puisque le mot de passe de base de données tiens plus de la protection de fichiers que de la sécurisation des données.
La sécurité d'Access repose sur l'utilisation d'un fichier externe.
Cela revient à dire que la sécurité peut être confié à quelqu'un d'autre (admin réseau,…), en cela elle est détachée de l'administration de la base.
Il est toujours possible de savoir ou est le fichier de sécurité, et donc vers ou diriger ses attaques.
La corruption du fichier peut être lourdement pénalisante.
Le système de génération du SID est toujours le même, ce qui fait que celui qui sait casser une sécurité, sait les casser toutes.
Le fait que l'emplacement soit parfois défini dans la base de registre fait qu'un fichier de sécurité peut protéger plusieurs bases de données même lorsque celle-ci n'est pas désirée. Ceci est d'autant plus vrai qu'en réseau on peut faire le choix de mettre le fichier sécurité en réseau ou sur tous les postes clients.
Bien sur quelqu'un qui maîtrise correctement ces concepts ne fait pas l'erreur, mais cela va à l'inverse de la simplicité de prise en main d'Access.
Lors de l'utilisation de tables Access avec le moteur Jet en VB par exemple, tu te retrouves obligé de reprogrammer la sécurité puisque celle ci n'est pas intégrée au fichier ".mdb".

[Etienne Bar]

Je la trouve tellement mal fichue que j'ai préféré reprogrammer moi-même les sécurités dans mes applis.

Au moins, comme ça, je n'ai pas de souci d'installation et je maîtrise parfaitement ce que je veux faire. De plus, je peux laisser les options d'administration de la base à un utilisateur administrateur.

Ce qui m'énerve le +, comme le dit si bien Bidou () , c'est le fait de mettre une sécurité pour une base revient à en mettre une pour toutes les autres.

[Maxence HUBICHE]

Envoyé par Le vieux

Ce qui m'énerve le +, comme le dit si bien Bidou () , c'est le fait de mettre une sécurité pour une base revient à en mettre une pour toutes les autres.

Dire cela est une hérésie !!!
Tu peux faire autant de sécurités différentes que de bases de données si tu veux. Sans le moindre soucis.

[Etienne Bar]

Envoyé par ZeMenace

Dire cela est une hérésie !!!
Tu peux faire autant de sécurités différentes que de bases de données si tu veux. Sans le moindre soucis.

Tu as parfaitement raison, j'ai écrit une bêtise

Ca m'était sorti de la tête. On va mettre ça sur le compte du manque de sommeil (faut bien trouver une excuse...)

[bidou]

Envoyé par ZeMenace

Tu peux faire autant de sécurités différentes que de bases de données si tu veux. Sans le moindre soucis.

C'est exact, néanmoins cela demande un travail particulier. Par défaut le fichier mdw défini dans le registre est le fichier de youtes les bases access. Et cela peut perturber plus d'un utilisateurs.

[Maxence HUBICHE]

ou alors tu leur prévois un beau petit raccourcis avec, dans la ligne de commande, le paramètre /WRKGRP qui te permet de pointer sur un mdw qui sera prioritaire sur l'entrée de la base de registre...

et là, les utilisateurs, ... ils savent cliquer sur une icône quand même (quoi que, quand on voit ce qu'il y a dans la taverne privée... ) Donc rien à faire. Pas de travail particulier.

Et voili !

[bidou]

Oui mais tu en reviens au problème que je soulevais. Celui qui maitrise bien ce problème sauras trouver des méthodes de contournement (je dirais même des astuces car ta méthode demande tout de même la création des raccourcis) mais l'utilisateur Access lambda se fera probablement avoir, voire piéger ses utilisateurs.

[neo.51]

Envoyé par bidou

Celui qui maitrise bien ce problème sauras trouver des méthodes de contournement (je dirais même des astuces car ta méthode demande tout de même la création des raccourcis) mais l'utilisateur Access lambda se fera probablement avoir, voire piéger ses utilisateurs.

c'est pour ça qu'un tutos la dessus ça ferait du mal à personne non ?

[Maxence HUBICHE]

Envoyé par bidou

Oui mais tu en reviens au problème que je soulevais. Celui qui maitrise bien ce problème sauras trouver des méthodes de contournement (je dirais même des astuces car ta méthode demande tout de même la création des raccourcis) mais l'utilisateur Access lambda se fera probablement avoir, voire piéger ses utilisateurs.

Mais c'est pas un utilisateur lambda qui va sécuriser une base de données de manière correcte non plus.
S'il se lance sans savoir comment ça marche, il ne va pas toucher à Admin et donc sa base ne sera pas protégée réellement...
D'autre part, c'est un DBA qui s'occupe de la sécurité aussi sur les serveur de BDD. Donc le problème est identique, que ce soit sur Access ou toute autre BDD.

Enfin, apprendre à faire des raccourcis, on fait ça en initiation Windows quand même. Ca ne devrait pas être trop dur je pense

[bidou]

Envoyé par ZeMenace

Mais c'est pas un utilisateur lambda qui va sécuriser une base de données de manière correcte non plus.
S'il se lance sans savoir comment ça marche, il ne va pas toucher à Admin et donc sa base ne sera pas protégée réellement...

C'est la que tu te trompes. J'ai déjà vu des utilisateurs d'Access, créer leur base, la "sécurisée" (très mal d'ailleurs), et perdre rapidement pied lorsqu'ils utilisent d'autres bases qui paraissent alors sécurisées.
Le problème sur lequel je retombe est toujours le même, Access est destiné aussi aux non expert (tu le met dans les avantages d'Access) est la gestion de la sécurité est "piégeuse".
Je veux bien parier en plus que 99% des utilisateurs d'Access ne savent pas faire la différence entre le propriétaire d'un objet et l'administrateur, pourtant les deux notions ont un impact sur la sécurité.
Note pour Néo : Cela sera expliqué dans mon tuto ADOX.
Note pour les autres : Je sais, je ne vous l'ai pas encore envoyé car il me reste quelque modifs à faire.

Envoyé par ZeMenace

D'autre part, c'est un DBA qui s'occupe de la sécurité aussi sur les serveur de BDD. Donc le problème est identique, que ce soit sur Access ou toute autre BDD.

Tout à fait, mais la sécurité est intégrée au SGBD et les DBA sont en général des professionnels (pour les gros systèmes).

Envoyé par ZeMenace

Enfin, apprendre à faire des raccourcis, on fait ça en initiation Windows quand même. Ca ne devrait pas être trop dur je pense

Je suis sur que tu sous estimes le nombre de personnes incapable de faire un tel raccourci.
Plus sérieusement, je ne suis pas sur que tout le monde pense à le faire.

[UbiK]

Salut,

J'y touches pas grands chose niveau Access aussi j'ai quelques questions :
Existe t-il une fonction intégrée permettant de crypter les données dans les colonnes ou faut-il la développer soit même ?
Comment sont gérés les accès aux informations ? Peut on déterminer que l'utilisateur TOTO voit, par exemple, toutes les tables; alors que TATA ne voit que certaines table et TITI que certaines colonnes de certaines tables (ou là encore faut-il tout bricoler soit même avec des bouts de VB) ?
Comment fonctionne le "système de verrous" ? Exemple un utilisateur est en train de modifier un enregistrement et là sa machine crash, quid du verrou sur l'enregistrement (toujours là ? plus là ?) ?

merci de m'éclairer sur tout ça ;o)

[bidou]

Envoyé par UbiK

Existe t-il une fonction intégrée permettant de crypter les données dans les colonnes ou faut-il la développer soit même

A ma connaissance c'est à toi d'écrire les fonctions de codages partielles, mais Zemenace en sait peut être plus que moi la-dessus.

Envoyé par UbiK

Comment sont gérés les accès aux informations ? Peut on déterminer que l'utilisateur TOTO voit, par exemple, toutes les tables; alors que TATA ne voit que certaines table et TITI que certaines colonnes de certaines tables (ou là encore faut-il tout bricoler soit même avec des bouts de VB) ?

Sous reserve de bien connaitre le fonctionnement de la sécurité Access, tu peux gérer tout cela sans utiliser une ligne de code.

Envoyé par UbiK

Comment fonctionne le "système de verrous" ? Exemple un utilisateur est en train de modifier un enregistrement et là sa machine crash, quid du verrou sur l'enregistrement (toujours là ? plus là ?) ?

La je ne vais pouvoir te répondre que pour les verrous standard (par page). Je sais qu'il existe maintenant un verrouillage par enregistrement mais je ne l'ai jamais utilisé.
Le verrouillage Access est à mes yeux un gros problème.
Le verrouillage par page à tendance à verrouiller des enregistrements en plus ce qui est souvent ennuyeux.
Le comportement du verrouillage dépend de ta méthode d'accès. Pour ce qui est de l'application Access je vais laisser les vedettes d'Access répondre, mais pour le mode de programmation, cela dépend du modèle objet suivi.
Avec DAO, tu utilises un espace de travail, tu ne rencontres en général pas de problème (à part celui que j'ai cité au-dessus), lorsque tu fermes cet espace (volontairement ou non) Jet déverrouille tous les enregistrements verrouillés par ton WorkSpace.
Avec ADO c'est autrement plus vicieux. Cela passe par un objet connection et va dépendre de deux facteur.
La position du curseur (client ou serveur) et le mode de verrouillage utilisé. En théorie tu n'es jamais embêté avec les curseurs serveurs. Par contre en mode client j'ai déjà vu des comportements surprenant. Pour répondre à ta question, les verrous disparaissent lors de la rupture de la connection, mais j'ai déjà vu passer des transactions partielle lors d'un plomb d'où désastre.

[Etienne Bar]

Envoyé par bidou

Pour ce qui est de l'application Access je vais laisser les vedettes d'Access ...

ZeMenace, t'es où, y'a une question pour toi...

[Maxence HUBICHE]

1/ pour le codage, une fonction Coder/Décoder la base de données existe.
cela a pour effet de coder le fichier mdb dans son ensemble. Tu ne peux plus lire les données en l'affichant dans le notepad ou tout autre éditeur d'ailleurs, ce qui serait possible (même si laborieux) autrement.
Par contre, les données sont visibles depuis Access, d'où l'importance d'une bonne implémentation de la sécurité ...

2/ bidou a bien répondu. Mais la mise en place d'une sécurité sur Access n'est pas si laborieuse que cela. Tu en trouveras les fondements dans la FAQ. Le problème est identique à celui que tu trouveras dans les autres BDD : par défaut, tu te connecte en tant qu'administrateur, et c'est pas bien, parce qu'il n'y a pas de mot de passe, et que tu as accès a tout. D'autre part, comme dans les autres bases de données, tu es propriétaire de ce que tu crées. Mais bon... je crois qu'il va falloir écrire un article spécifique sur la sécurité Access, parce que j'ai vraiment l'impression qu'il y a une grosse lacune là-dessus.

3/ là, je rejoins complètement Bidou.
ce verrouillage par page (qu'on retrouve aussi sur SQL Server notamment), c'est d'un lourd !!!

[bidou]

Envoyé par ZeMenace

2/ bidou a bien répondu. Mais la mise en place d'une sécurité sur Access n'est pas si laborieuse que cela.

Je ne dis pas cela, ni même que c'est plus compliqué que pour un autre SGBD. Je souligne juste que
Pour le profil utilisateur moyen d'Access c'est une source d'emm.... D'ailleurs même old timer (que je ne classe pas dans ce profil... Aie pas la tête) avoue qu'il ne l'utilise pas.
Il y a quand même des inconvénients à ce système non négligeables. Mais j'en ai djà parlé.

Je suis tout à fait d'accord avec toi pour reconnaitre que bien utilisé, tu peux obtenir une très bonne gestion des droits.

[UbiK]

merci d'avoir éclairé ma lanterne messieurs ;o)

[youpps]

Envoyé par bidou

(...)
Le problème sur lequel je retombe est toujours le même, Access est destiné aussi aux non expert (tu le met dans les avantages d'Access) est la gestion de la sécurité est "piégeuse".

Bonjour,

J’ai eu l’impression qu’on parlait de moi…
J’ai beau y mettre plein de bonne volonté, n’ayant pas de formation « informatique » au départ, je me perds dans les méandres de la sécurité Access . Je ne sais pas si mon post a sa place ici ou devrait être tout seul, mais je me lance.

Donc j’ai crée une base, qui fonctionne plutôt bien. Il me faut la rendre accessible à tout un service. Certains ne devraient que pouvoir la consulter, d’autres pouvoir la faire évoluer également. Je me dis : « chouette, c’est plus facile que je ne le pensais » J’ai déchanté assez rapidement, quand
1/j’ai crée une nouvelle base et qu’à l’ouverture Access me demandait un mot de passe
2/ j’ai mis ma base que je croyais sécurisée sur un lecteur accessible à plusieurs personnes et que les dites personnes pouvaient y accéder sans mot de passe, qu’on pouvait ouvrir la base sur 2 postes sans message indiquant qu’elle était en cours d’utilisation.
Je reviens sur le site (qui m’a aidée à plus d’une reprise) et fais des recherches dans le forum...je trouve bien des choses, mais j’ai l’impression de tout mélanger.

J’ai lu à plusieurs reprises qu’il fallait partitionner sa base. Si j’ai bien compris, il faut le faire au tout début...trop tard pour moi. Enfin, avec l’outil, hop c’est fait, apparemment sans encombres. Je me retrouve avec mabase.mdb(l’ « applicatif ») et mabase_be.mdb (les tables). Après, je bloque : client serveur, gestion des utilisateurs...
Pouvez-vous m’indiquer si c’est bien cela que je dois faire (et me corriger si besoin) ?
1/ récupérer mon fichier system.mdw et le copier le dans c:\windows\system32 , comme indiqué ici
2/Mettre mabase_be.mdb sur le lecteur commun au service, et ... ? compacter mabase.mdb en mabase.mde que je mettrai sur chaque poste ? c’est pas possible de le mettre sur le lecteur commun aussi ?

Concernant mes utilisateurs, je les avais déjà définis et leur avais octroyé des droits : Si j’ai bien compris cela disparaît avec la récupération du system.mdw . Par contre, le fait d’avoir partitionner la base est-il suffisant pour qu’en recommençant la procédure, je ne bloque pas Access sur mon poste mais que je sécurise vraiment ma base ?
Est-ce suffisant pour qu’il n’y ait pas 2 personnes à la fois qui rajoutent ou corrigent des données ?

Merci

[120]

je ne suis pas aussi pro en matière de sécurité que les précédents interlocuteurs
mais ce que j'en ai compris, c'est qu'en suivant scrupuleusement ce procédé de la faq. je suis maintenant arrivé à quelque chose qui me convient.
http://access.developpez.com/faq/?pa...eral#SecuUsers
bon courage.

[coyott]

Pour ma part j'ai juste parcouru les différentes possibilités de sécurisation des données sur developpez.com et d'autres forum... et franchement on s'y perd...

tout d'abord le novice de chez novice il sécurise sa base et c'est aprés avoir eu des problèmes qu'il se rencontre quel n'est sécurisé que sur son poste...franchement déjà là c'est mal ce genre de chose ne devrait pas exister on sécurise ou on sécurise pas !!!

Ensuite le moins novice va farfouiller un peut et aprés des heures de recherches trouver ce qu'il lui convient ...mais ca reste lourd à mettre en place même si aprés avoir bloquer plusieurs fois toutes ses bases comprendra comment ca marche.

Personellement sur access je suis dans la catégorie je farfouille comme un âne...mon problème n'est pas de mettre en place la sécurité mais de permettre au futur "administrateur" de s'en sortir sans moi (non informaticien et se foutant royalement d'access) donc de construire des formulaires plus aisés plus simple pour piloter la sécurité .
et là déjà ca ce complique et franchement tant qu'a faire cela... Je me demande si je ne vais pas mettre en place ma propre sécurité pour éviter d'avoir des racourcis (ou fichier mdw) qui se balladent, et qui je suis sur aprés 4 ou 5 changements de posts/utilisateurs se verront tomber dans l'oubliète et rendre mon appli obsolète.

Seule inconvénient je ne suis pas sur de trouver toutes les failles pour la sécuriser moi même
N'étant pas expert en la matière dîtes moi si je me trompe. mieux vaut faire sa propre sécurité ou utiliser celle d'access quand on sait que l'administrateur sera en fait juste un responsable ni connaissant rien ?