Celle-là je l'ai déja faiteEnvoyé par ypicot
Rien à redire ! Vraiment géniale
Pas assez fiable, difficile à mettre en oeuvre
Pas assez fiable, mais aisée à mettre en oeuvre
Pas de soucis de fiabilité, mais difficile à mettre en oeuvre
Pas de soucis de fiabilité et aisée à mettre en oeuvre
C'est trop nul !
Autre (expliquez et commentez ce choix)
Sans avis ...
Celle-là je l'ai déja faiteEnvoyé par ypicot
J'avoue n'avoir pas compris grand chose.Envoyé par bidou
Tu veux dire que mon fichier .mdw est accessible à tous et qu'un hacker de haut niveau peut le 'craquer' ?
Je rappelle que je ne me pose pas ce genre de question :
1- il s'agit toujours de protéger l'accès à un fichier .mdb (base de données et/ou applicatif). Je sais qu'un bon hacker peut casser toutes les protections. Si les données sont hautement confidentielles, faut pas les mettre dans un .mdb, même crypté. Tout comme faut pas les envoyer par email, même crypté.
2- nous savons que même la sécurité 'système' tant vantée par Microsoft et autres peut être cassée par les hackers acharnés.
Ce qui ne veut pas dire, je suis bien d'accord, qu'elle n'est pas plus efficace que la sécurité Access. Elle l'est. Mais mon but n'est pas de protéger une base fichier, donc ambulante, facile à copier, contre ce genre d'attaque.
3- enfin, je rappelle, même si c'est un détail, que je peux me passer de tout fichier .mdw pour les utilisateurs les moins privilégiés.
4- il s'agit avant tout de distinguer, parmi les utilisateurs non programmeurs (a priori encore moins hackers), des rôles correspondant à leurs responsabilités. Et de personnaliser l'application pour qu'elle reflète exactement ces rôles.
Ça m'intéresse beaucoup de savoir comment tu fais ça, à partir de VBA, sans te logger sous un nom différent.Envoyé par bidou
Voir plus haut, remarques de ypicot : le but n'est pas de contourner la sécurité contre la malveillance.
J'aimerais que mon applic puisse installer et modifier des fichiers dans un dossier que l'utilisateur en cours ne peut pas voir.
Même si c'est moi l'utilisateur en cours. J'aime travailler selon 2 modes :
- 1 mode 'Administrateur' où j'ai tous les droits. Je l'utilise pour (ré-)installer Windows et autres applis, peaufiner le système... Bref, j'enfile "la casquette du mécanicien qui soulève le capot".
- 1 mode 'sécurisé' où je me contente de faire tourner mes applis : capot fermé, je mets "la casquette du pilote qui conduit son bouzin".
C'est un garde fou de ne pas travailler en tant qu'Administrateur. Mais mes applis devraient pouvoir accéder là où il faut (ouvrir une base, par exemple, que je ne verrai même pas dans l'Explorateur Windows, comme proposait ypicot).
Développement Office, support technique, assistance, sur place (Loire atlantique, Vendée, Maine et Loire) ou à distance.
ypicot, bonjour.
Je comprends bien ce que tu exposes en mettant la base dans un répertoire non accessible. Mais je doute que l'appli ouverte sur un poste lambda puisse modifier cette base ! Tu fais ça couramment ?
Donc, je ferai des tests.
et, processus hélas totalement inévitable, et qui fait partie de la vie de tout programmeur :Envoyé par ypicot
- le programmeur explique une seule et unique fois qu'il faut lire la doc et s'y tenir. (Si elle est mal faite, il la corrige/complète d'abord).
- le programmeur qui travaille en interne explique à son chef qu'il doit perdre son temps à faire du "support technique" pour ces utilisateurs là...
- l'indépendant qui travaille en régie explique à son client que ça va lui coûter bonbon s'il doit passer son temps à refaire ce genre d'opérations...
Je crois surtout qu'il faut arrêter de prendre nos utilisateurs pour les derniers des cons, sous prétexte que ce ne sont pas des pros.
Il est normal qu'ils se plantent (une fois ou 2) : c'est comme ça qu'ils apprennent (et nous aussi, voir réf. au "fichier .mdw jamais sauvegardé" <- ça, c'est TA faute).
Il y en a inévitablement qui foutent le b...
Ça fait partie de notre boulot de les prendre une fois entre 4 zyeux et leur expliquer les conséquences pour eux même, pour les autres, pour la boîte.
Par la suite, si un climat de confiance s'installe, tout va bien.
Avec quelques plantages par ci par là. La routine.
Développement Office, support technique, assistance, sur place (Loire atlantique, Vendée, Maine et Loire) ou à distance.
oui mon papy on c'est mal compris deux fois.
Je voulais juste te dire qu'à mes yeux gérer la sécurité dans un fichier séparé ne présente aucun avantage.
Sinon, tu utilises des API qui elles se loguent sous un nom différents. D'où le risque que je signale, car tu vas devoir utiliser un Security_descriptor qui contiendra les informations de log et qui lui sera malheureusement vulnérable dans du VBA.
La solution consiste à créer des DLL encapsulant les informations de compte. C'est viable au sein d'une même entreprises utilisant des groupes de droit mais ce n'est pas très souples.
Si ca t'intéresse je te donnerais un exemple
Voui, voui, vouiEnvoyé par bidou
Développement Office, support technique, assistance, sur place (Loire atlantique, Vendée, Maine et Loire) ou à distance.
Je l'ai fait une fois, avant de remplacer le bazard par un MSDE.Envoyé par Papy Turbo
Petite précision :et, processus hélas totalement inévitable, et qui fait partie de la vie de tout programmeur :Envoyé par ypicot
- le programmeur explique une seule et unique fois qu'il faut lire la doc et s'y tenir. (Si elle est mal faite, il la corrige/complète d'abord).
- le programmeur qui travaille en interne explique à son chef qu'il doit perdre son temps à faire du "support technique" pour ces utilisateurs là...
- l'indépendant qui travaille en régie explique à son client que ça va lui coûter bonbon s'il doit passer son temps à refaire ce genre d'opérations...
Je n'ai jamais refusé d'expliquer plusieurs fois (je suis aussi formateur : j'ai interêt ). Je pense notamment un à client qui tous les six mois m'envoie un mail, il s'agit toujours d'un pb de mdw, et je ne lui ai jamais dit "regardez dans le manuel et foutez-moi la paix".
C'est généralement au bout d'un quart d'heure qu'il me dit "effectivement, il me semble que vous nous l'avez déjà expliqué".
Et accessoirement je ne facture pas le 1/4 d'heure passé.
En fait, pour moi le pb n'est pas qu'il m'appelle (au contraire, dans un sens ça permet de garder le contact), mais qu'il ressente le besoin de m'appeler. A chaque fois il se sent mal, et passe plus de temps à s'excuser et me remercier que moi à le dépanner.
L'informatique doit être une source de solution, et dans ce cas précis c'est plus une source de problèmes.
Donc, dans ce cas là, je me serai bien passé de fichier mdw (manque de bol, c'était une demande du client), et depuis je cherche plutôt à les éviter.
Mais c'est mon opinion, je la partage, et je ne force personne à être d'accord avec moi.
Accessment
Yvan
Une solution n'est valable que dans un contexte donné.
Une solution n'est valable que dans un contexte donné
Salut,
j'en reviens à ce fameux problème :
Tu peux me dire comment tu fais (détails des rôles et droits sous Windows...). J'en ai reparlé à des spécialistes Windows. Personne ne comprend comment tu peux bloquer l'accès au répertoire et permettre, avec les autorisations de l'utilisateur, à l'appli Access d'ouvrir et modifier la base ??Papy Turbo a écrit:
Je comprends bien ce que tu exposes en mettant la base dans un répertoire non accessible. Mais je doute que l'appli ouverte sur un poste lambda puisse modifier cette base ! Tu fais ça couramment ?
Donc, je ferai des tests.
Je l'ai fait une fois, avant de remplacer le bazard par un MSDE.
Quant aux problèmes psychologiques des rapports client - développeur, je ne m'en prends pas à toi. Bravo pour ton attitude, qui me paraît la seule correcte pour travailler avec plaisir, en plus du gagne-pain.
Pardon de m'être un peu échauffé. C'est dû aux innombrables développeurs que j'ai croisés un peu partout, qui fourent tous les problèmes sur le dos des utilisateurs (avec les blagues lourdes que tu as sûrement entendues). Je trouve ça facile, gratuit, et pas très constructif.
Peut être tu devrais proposer à ton client un contrat de support technique (xx € par appel ou par 1/4h ?). Il n'hésitera pas à t'appeler, ne se sentira pas coupable, tu garderas le lien, tout bon pour tout le monde ? 8)
Développement Office, support technique, assistance, sur place (Loire atlantique, Vendée, Maine et Loire) ou à distance.
Bon alors moi et la sécurité sur ACCESS 2000 ça fait deux !!!
j'ai suivi tout ce qui été recommandé sur la FAQ , j'ai un mot de passe, des groupes d'utilisateurs, un fichier mdw....
puis je veux partager ma base avec ma collègue: le test est, en fait, un envoi de la base par mail (c'est au final ce qui va arriver envoyer la base à un groupe seulement de lecteur) pour voir s'il elle ne peut faire aucunes modifs et là le comble c'est qu'elle ouvre la base sans mot de passe alors que moi je l'ouvre maintenant avec mon mot de passe ET elle fait ce qu'elle veut dedans ....c'était pas du tout prévu
alors je vous montre que des débutants ça existe , j'ai du virée blonde et surtout loupé quelque chose
est-ce impossible de donner une base sécurisée par mail ????
T'as pas du enlever les droits aux groupes et utilisateurs par défaut.
j'ai du zapper un étape , ça je l'ai fait par contre en relisant j'ai bien créer une base de données mais je l'ai fait avec l'assitant ...fallait peut être pas !!!
Pour protéger efficacement ta base, il faut
1- enlever tous les droits
- à l'utilisateur Administateur (utilisateur par défaut, donc généralement est le propriétaire de tous tes objets)
- au groupe 'Administrateurs'.
Tu peux supprimer cet utilisateur et ce groupe de ton fichier .mdw, mais n'oublie jamais qu'il sont inclus dans tout fichier system.mdw "de base" (installé avec Access).
2- Si 'Administateur' est le propriétaire de tous objets (tu as créé ces objets avant de mettre en place la sécurité avec ton nom/ton code :
- Changer le propriétaire... (Outils, Sécurité, Autoisations d'accès...) : mettre ton code utilisateur.
Je ne sais pas exactement ce que fait l'assistant, mais faut vérifier cela.
Enfin, avant d'envoyer ton fichier,
- réutiliser WRKGADM.EXE pour réactiver le fichier system.mdw d'origine (dont j'espère que tu as gardé une copie ), qui contient l'utilisateur 'Admin' et les groupes de base. C'est ce fichier qui est utilisé par défaut par ton destinataire.
- tester ton appli avec : tu ne dois pas pouvoir ouvrir ta base, ou modifier les objets protégés...
Développement Office, support technique, assistance, sur place (Loire atlantique, Vendée, Maine et Loire) ou à distance.
bonjour,
j'ai pas mal parcouru le forum. je n'ai jamais utilisé la sécurité ACCESS. Je gerais toujours mes bases avec un table utilisateur et une colonne password.
Ce que je ne comprends pas, c'est l'interet de définir des droits programmeurs si on distribue un MDE où on a interdit l'accès a la fenetre base de donnée et au code.
Si je dois modifier mon code, j'ouvre le fichier client, je le modifie, j'en fais un autre MDE que je distribue et le tour est joué.
De plus, je ne vois pas pourquoi je definis des droit sur les tables, les requetes etc... puisque dans mes MDE, on ne peut y acceder. Seul le développeur, qui possède le mdb client, a la possibilité de modifier le code et a donc les droits aux tables et requetes...
bref, eclairez ma lanterne, et j'espere avoir été clair
sinon je recommence..
Salut, anikeh
D'abord, tu as raison dans une très large mesure en ce qui concerne la partie applicative : un .mde est très suffisant dans la plupart des cas, pour protéger tables locales, requêtes, formulaires, états... Un mot de passe est aujourd'hui suffisant (et efficace) pour protéger tout le code.
Je pense que c'est une bonne solution si tu vends une appli à un public large (10, 100 ou 1000 clients...), ce qui n'est pas courant avec Access.
Mais,
- il y a de nombreux cas où on ne veut pas (ou ne peut pas) distribuer de .mde : je laisse quasiment toujours aux utilisateurs la possiblité de créer leurs propres requêtes, des états nouveaux, d'en copier/modifier d'autres, ce qui est un des très gros points forts d'Access par rapport à n'importe quel autre langage. Dans ce cas, je dois quand même protéger les formulaires, certains états de base, etc.
- j'octroie des droits au programmeur qui vont bien au delà de simples droits d'accès : la 1ère chose que fait l'application (fonction AppInit()), c'est de déceler si l'utilisateur en cours est un programmeur ou pas. Si oui, l'application se comporte très différemment du cas standard : Stop en cas d'erreur, affichage de messages + techniques et + complets, pas besoin de créer un journal d'erreurs à envoyer au programmeur, etc. etc. Il y a même un "programmeur" caché dans le code VBA, qui peut mdifier les paramètres de l'application, etc. alors que l'utilisateur standard ne peut pas le faire (je pourrais continuer longtemps, mais on va me taxer de bavardage intempestif ).
- autre raison de distribuer un mdb : le débogage "sur site". J'arrive avec mon fichier .mdw, je lance la même appli sur le poste du client, tout se débloque...
Enfin, il y a la base de données elle-même (les tables) :
- je n'ai jamais vu personne la distribuer sous forme de .mde. Les données appartiennent au client + il faut pouvoir intervenir : maintenance, imports/exports, etc.
- n'importe qui peut l'ouvrir directement, sans mot de passe et sans passer par ton appli, si tu ne la protèges pas.
Développement Office, support technique, assistance, sur place (Loire atlantique, Vendée, Maine et Loire) ou à distance.
salut Papy Turbo,
je vois ce que tu veux dire. En fait, je n'ai jamais developpé d'appli ou je laissais aux personnes le droit de developper leurs propres états et leurs propres requête. Je comprends mieux.
Par contre, le MDB ( les tables comme tu dis) tu peux les proteger avec un mot de passe fichier ( c'est proposé dans le menu).
Voila comment je protège mes tables.
De plus, je ne les distribue pas les tables, elle sont sur le reseau...
donc en gros, le fichier mdw est optimal, mais tout depend de l'appli et de la demande du client. Ce que je comprends, c'est qur ma manière de developper reste correcte, quoique pas optimale.. suis je dans le vrai??
CiaoEnvoyé par anikeh
Le mot de passe fichier est une erreur de Microsoft. Ils expliquent eux-même, dans MSDN, que c'est dangereux et pas stable.Envoyé par anikeh
Ici, sur le forum, j'ai déjà vu 2 cas de bases corrompues, impossible à réouvrir, même avec le bon mot de passe (Access ne le reconnait plus !!! Grosse Katastrof !)
Tout le monde a accès au réseau, sinon, l'appli non plus n'y aurait pas accès... Argument rejeté, votre honneurEnvoyé par anikeh
Toi seul, avec ton client, pouvez juger : il y a toute une série de "niveaux" de sécurité, et il n'y a effectivement aucune raison de "blinder" des applis qui n'en ont pas besoin ! Ça complique la maintenance, et ça emm... la vie des utilisateurs.Envoyé par anikeh
Si j'étais toi,
- soit je ferais une sauvegarde automaitque de la base toutes les heures,
- soit je supprimerais vite fait le mot de passe.
Relis le débat + haut. Je te conseille quand même de
- rouvrir la base (tables) pour modif, avec TON fichier .mdw,
- n'autoriser que le groupe "programmeurs" (dont tu fais partie) à modifier la structure des tables,
- interdire toute modification de cette structure par les 'Administrateurs' et 'Utilisateurs'
- autoriser l'accès aux données (ajout, suppression, modif. etc.) aux 'Administrateurs' et 'Utilisateurs',
- remettre la base sur le serveur (si tu l'as bougée),
- enlever ton fichier .mdw (si tu l'as mis temporairement sur le serveur) et en faire 3 copies de sauvegarde, en lieu sûr.
Prévoir 1/2 journée, avec les tests et tâtonnements divers...
Tes utilisateurs ne verront pas la différence, mais ils ne pourront rien bousiller...
Développement Office, support technique, assistance, sur place (Loire atlantique, Vendée, Maine et Loire) ou à distance.
Dans ce cas, comment tu protèges tes tables??Le mot de passe fichier est une erreur de Microsoft. Ils expliquent eux-même, dans MSDN, que c'est dangereux et pas stable.
Ici, sur le forum, j'ai déjà vu 2 cas de bases corrompues, impossible à réouvrir, même avec le bon mot de passe (Access ne le reconnait plus !!! Grosse Katastrof !)
Bonjour à tous,
Une fois n'est pas coutume, je ne vais pas demander d'aide sur Access mais plutôt poster un lien vers un article (désolé pour les américanophobes) qui parle des machines à voter américaines en Georgie.
http://www.wildboar.net/politics/voting/articles/scoop/S00065.htm
Je trouve cet article assez intéressant par rapport à la politique de sécurité des bases access et les travers que cela peut entraîner. Il a au moins le mérite de poser des questions qui fâchent ... Une équipe de hackers chez W. ferait (a fait ? ) des ravages !
La question est : comment ont ils pu accéder à des données aussi sensibles ?
Bonne lecture !
@++
Ce document ne justifie en rien que la sécurité Access serait mal pensée mais plutôt que la sécurité du produit est mauvaise.
Un point qui m'a fait rire :
Franchement s'agit t'il d'un mot de passe alors que :Mot de passe par défaut : GEMSUSER
Qui plus est la sécurité n'a été fait qu'au niveau Système et non Utilisateur. Or, il s'agit de la sécurité utilisateur qu'il est recommandée d'utiliser !Envoyé par L'aide
Encore une fois, une sécurité bien faite est solide... évidemment, si elle est mal faite, voire inexistante....
Ce message vous a été utile ? Si oui, cliquez sur
Mes tutoriels Access
La rubrique Microsoft Access
Cours et tutoriels pour apprendre Access
La FAQ Access
Le Forum Access
Offres d'emploi développeur Access
Mon intention n'est pas de démontrer que la sécurité est mauvaise, je ne connais pas assez Access pour prétendre le dire.
Ce qui m'a plutôt fait sourire c'est qu'une application aussi sensible soit aussi mal sécurisée (même si c'est pas la faute d'Access mais plutôt la faute des développeurs du logiciel)
@++
En tout cas, pour moi qui suit novice de chez novice, j'ai parcouru tout l'historique et voici ce que j'en conclu:
1) Malgré toute la meilleur volonté, ce n'est pas simple
2) Il ne faut oublier que ce que l'on sait et qui peut être simple pour soi, ne l'est pas pour tout le monde
3) Vous n'etes pas tous d'accord entre vous
4) Dans la FAQ, c bien mais pour un novice, il manque peut être quelques eclaircissements
5) Enfin mais peut être parce que nous les novices, ils nous manquent les fondamentaux, il y a des termes qui me parle pas comme :
-le paramètre /WRKGRP qui te permet de pointer sur un mdw
- que le fichier .ldb contient tous les verrouillages ('locks')
- ...
J'exagère à peine en disant tout cela.
En tout cas, j'en conclu que moi perso 8) g du boulot, que pour la sécurité, il faut passer du tps avant de comprendre (que l'on a pas toujours en entreprise) et que vous êtes vraiment pros.
Vous croyez qu'un jour je pourrais postuler pour être modérateur ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager