Discussion :

[STAT_resuval]

Bonjour,

Context : Je dois mettre en place une base de données avec plusieurs profils d'utilisateur. Un des profil concerné est "opérateur de saisie". Ce profil doit avoir accès aux formulaires, pouvoir ajouter et modifier des lignes dans les tables exclusivement à partir des formulaires. Ce profil ne doit pas pouvoir ouvrir directement les tables ou les exporter par exemple sous forme de fichier Excel.

Avancement : J'ai pu à l'aide de ce forum et autres guides mettre en place différents profils protégés par des identifiants et mots de passe et attribuer des droits différents selon les profils.

Problème : Je n'arrive pas à paramétrer les droit du profil "opérateur de saisie" afin qu'il corresponde aux exigences du projet. Dans le cas où je ne donne accès que aux formulaires, ce profil ne peut pas interagir avec les tables même au travers du formulaire. Dans le cas où je donne accès aux formulaires et aux tables, ce profil peut réaliser des extractions.

Pistes :

• J'ai vu qu'il était possible d'exécuter des requêtes avec les droits du créateur au lieu des droits de l'utilisateur. Malheureusement je ne trouve pas comment faire de même pour les formulaires. Est-ce possible ?
• Y-a-t'il une combinaison de droits permettant d'obtenir le résultat que je recherche (droit de modification via formulaire mais pas d'export ou ouverture des tables)

Je vous remercie d'avance pour votre aide.

[marot_r]

Bonjour.

Si tu mets en place des politiques de sécurités alors cela veut dire que tu n'utilises pas format accdb mais le vieux format mdb (Access 2003).
Avec les nouveaux formats (.accdb, Access 2007 et suivant) tu n'as plus de sécurités intégrées et il est assez facile de contourner celles qu'on peut mettre en place.

Pour limiter l'accès aux tables tu peux simplement les cacher et éventuellement même cacher là où elles sont affichées. Tu peux aussi verrouiller la possibilité de déverrouiller cela. Juste faire gaffe à se garder un moyen d'accéder :-).
Probablement aussi, mais ça fait un bout que je ne m'en sert plus, si tu fait un "executable" (.mde) de ton application (garde précieusement l'original) et que tu installes un runtime au lieu d'un vrai Access sur le poste tu vas réduire les possibilités.
Dernier point tu peux encrypter la BD dorsale, perso la seule fois où je l'ai fait cela a ralenti considérablement Access et rendu le tout assez instable.

Attention par contre je pense que quelle que soit les versions, tu peux toujours faire un copier/coller des enregistrements à partir du formulaire.

Si tu veux une sécurité à toutes épreuves n'utilise pas Access mais une "Grosse base" (genre MS-SQL Server ou Oracle, peut-être MySQL) qui ont une gestion de droit bien plus fine et une autre interface (ex : VB.NET).
Je dis toujours à mes clients qu'avec Access, si la personne a accès à l'application elle a accès aux données (ex : via Excel). Avec les
"grosses" bases cela reste encore possible mais c'est franchement plus compliqué.

A+

[STAT_resuval]

Merci pour votre réponse. Je pense cacher les tables comme vous le conseilliez. En effet, j'ai mis AC-2016 dans le titre car j'utilise ce logiciel et je n'avais pas vu que la base avait été crée sur une ancienne version.