Limiter l'usage du runtime

[Mumak]

Bonjour,
J ai un souci pour la sécurisation d'Access.
Cette base est composé de deux fichiers, l'un DATA partagé en réseau et l'autre Runtime présent sur chaque poste.

J'ai deux questions de sécurisation,

1/ Comment limiter l'utilisation du Runtime a certains formulaires et pas a d'autre en utilisant des niveaux de compétence des utilisateurs ?

2/ Comment rendre totalement inaccessible le fichier DATA sans le crypter et rendre donc les temps de latence trop importants ?

Merci Beaucoup

Et super travail Loufab!

[tAKAmAkA]

Bonjour,

1-La solution la plus simple (et donc la plus fiable!) à mettre en oeuvre est de sécuriser les tables de la partie DATA, et seulement elles.
L'accès à un formulaire faisant appel à une table dont on n'a pas les droits en lecture donne une page blanche.

2-Totalement inaccessible...pour qui? Si on a pas les droits sur DATA on n'y a pas accès, même avec le bon fichier de sécurité.
Si c'est pour protéger le fichier il faut voir les droits sur le dossier.

[Mumak]

2-Totalement inaccessible...pour qui? Si on a pas les droits sur DATA on n'y a pas accès, même avec le bon fichier de sécurité.
Si c'est pour protéger le fichier il faut voir les droits sur le dossier.

Je veux que ce fichier soit utilisable (consultation des données) qu'à partir de l'interface de mon runtime, mais que aucun autre accès soit possible.

[tAKAmAkA]

A ma connaissance, l'accès au tables avec Access + le mdw qui convient est toujours possible.
Quel est le problème? (Bidouille, malveillance, intégrité, confidentialité...)

[Mumak]

Ces données sont très confidentielles et essentielles pour moi!

Mes collaborateurs doivent pouvoir alimenter cette base et y puiser des informations, mais a l'état actuel des choses n importe qui peut faire ce qu'il veut avec, et ça c'est pas top!

[tAKAmAkA]

Une sécurité appliquée à ta dorsale doit résoudre ton problème.

J'insiste sur le fait que d'appliquer la sécurité à la dorsale seule (les tables) est plus simple et par conséquent plus fiable car beaucoups s'arrachent les cheveux (le forum sécurité est plein de chauves! et loufab, lui, doit avoir quelques cheveux blancs à répondre inlassablement à, en fait, toujours les mêmes questions...).
Ceci peut-être complèté par quelques conditions d'affichage (de boutons de commande, par exemple) basées sur l'appartenance à un groupe.
Bon courage.

[naphta]

Bonjour,

Je m'insère dans ces posts car j'ai eu la même problématique.

Je l'ai résolu en constituant une table collaborateurs dans laquelle je stock le nom de login de l'utilisateur et ses droits.

Quand il ouvre la base, je regarde si le login renvoyé par windows existe et si il correspond à un utilisateur connu dans la table, si c'est le cas alors il a un certain niveau de droit dans la base.

Ensuite en fonction de ses droits je fait apparaître ou non des bouton ou lui donne des droits de lecture ou autre chose.

Je ne sais pas si c'est cela approche de ta demande, mais pour moi cela est souplesse et d'une efficacité démoniaque.

a+

[tben08]

Naphta,

ton idée m'intéresse mais je ne vois pas comment le faire?

comment fais-tu pour donner des droits et surtout comment fait tu pour afficher des choses en fonction d'un code et d'un login?

merci

[naphta]

bonjour,

J'ai envoyé à un autre forumer une base dans laquelle j'ai positionné plusieurs choses.

Au démarrage
- Détection du login Windows comparé à la table utilisateur si il existe alors on y va pour afficher le formulaire de départ de l'appli.
- Sinon login manuel où on lui propose la liste de ce qui sont connus avec un mot de passe.
Dans la table des employés il y a un champ pour déterminer son niveau de privilège "nivsecure" qui est transféré dans une variable globale de l'application, si dans une demande de modification ou de consultation on a besoin de savoir ses droits on test la variable.

Pour ce forumer j'ai ajouté un test pour savoir qui a modifié ou ajouté quelque chose et quand dans une table et une journalisation des modifications.

Je pense que je vais proposer cette base dans les contributions.
Si tu veux la base me faut un email car la base est trop lourde pour la passer ici.

a+

[argyronet]

Envoyé par naphta

bonjour,

J'ai envoyé à un autre forumer une base dans laquelle j'ai positionné plusieurs choses.

Au démarrage
- Détection du login Windows comparé à la table utilisateur si il existe alors on y va pour afficher le formulaire de départ de l'appli.
- Sinon login manuel où on lui propose la liste de ce qui sont connus avec un mot de passe.
Dans la table des employés il y a un champ pour déterminer son niveau de privilège "nivsecure" qui est transféré dans une variable globale de l'application, si dans une demande de modification ou de consultation on a besoin de savoir ses droits on test la variable.

Pour ce forumer j'ai ajouté un test pour savoir qui a modifié ou ajouté quelque chose et quand dans une table et une journalisation des modifications.

Je pense que je vais proposer cette base dans les contributions.
Si tu veux la base me faut un email car la base est trop lourde pour la passer ici.

a+

Bonjour,

D'un point de vue sécurité, c'est risqué...
L'utilisateur averti peut aisément intervenir sur cette table et changer les droits de telle ou telle personne ou pour lui même...
Surtout si tu nommes ton champ "nivsecure" qui a l'inconvénient d'être parlant.
Ce choix reste intéressant pour des utilisateurs novices en la matière.


Si tu codes les données de la table alors, c'est une solution envisageable (voir PJ)

Argy

[naphta]

Bonjour,

J'applique tjs la règle des 80/20, je m'explique au moins 80% des utilisateurs ne savent pas se servir d'access, de plus il y a aussi 80% de runtime installés sur les postes, on trouve au moins 80% d'utilisateur "normaux"

Si on est dans un environnement malsain on pourra coder avec un algo le niveau de sécurité avec des chiffres et des lettres.

de toute façon Microsoft a abandonner la sécurité depuis la version 2007, donc c'est définitif à moins que ..

a+

[tAKAmAkA]

Bonjour,

Je ne sais pas si mumak est toujours à l'écoute mais je me permets de revenir sur sa question

2/ Comment rendre totalement inaccessible le fichier DATA sans le crypter et rendre donc les temps de latence trop importants ?

.
Qu'est-ce qui empêche un utilisateur disposant d'Access de consulter DATA? Je me demande si il n'avait pas déjà la réponse dans sa question (cryptage).

naphta: pourquoi as-tu abandonné définitivement la sécurité niveau utilisateur?

1- Parce que c'est trop compliqué?
2- Parce que tu penses que MS l'a définitivement laissé tombé?
3- Parce que tu veux bénéficier de toutes les nouvelles fonctionnalité d'Access liées au format accdb?
4- Parce que ta solution est plus efficace et souple?
5- Parce qu'il faut vivre avec son temps et aller de l'avant?

[naphta]

Bonjour,

Effectivement faut être pragmatique, sur SQL serveur il y a tout ce qu'il faut pour faire de la sécurité tranquillement puisqu'il la base de donnée se charge des 2 tiers et un frontal présente les données, avec Acces c'est différent faut faire 2 tiers sur le frontal : présentation et sécurité.

Les solutions de cryptage sont lourdes à a l'aller et au retour(même mon wifi n'est pas crypté la sécu est au niveau "ip admis" c'est simple, rapide et efficace).

Il n'y a plus de gestion de la sécurité sur la version 2007 avec les fichiers mdw de mémoire, c'était fastidieux est pas fiable.(c'est microsoft qui a décidé et personnellement je ne les vois revenir en arrière)

Alors faut faire sa propre sécurité, en considérant de façon pragmatique l'environnement utilisateur.(ce n'est pas tous des magouilleurs mais ils sont plutôt susceptibles de faire des bêtises)

Il faut utiliser le compte windows, éventuellement tracer qui fait quoi quand.
Après si on est vraiment parano crypter le champ "niveausecure" et c'est marre.
La solution que je propose est un peu fastidieuse au début mais cela fait plusieurs fois que je duplique le même système sur bon nombre d'applis.
J'ai d'ailleurs déjà vu sur le net le même genre de gestion de la sécurité.

a+