IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Exprimez-vous sur la sécurité d'Access

Votants
112. Vous ne pouvez pas participer à ce sondage.
  • Rien à redire ! Vraiment géniale

    1 0,89%
  • Pas assez fiable, difficile à mettre en oeuvre

    22 19,64%
  • Pas assez fiable, mais aisée à mettre en oeuvre

    18 16,07%
  • Pas de soucis de fiabilité, mais difficile à mettre en oeuvre

    29 25,89%
  • Pas de soucis de fiabilité et aisée à mettre en oeuvre

    5 4,46%
  • C'est trop nul !

    15 13,39%
  • Autre (expliquez et commentez ce choix)

    4 3,57%
  • Sans avis ...

    18 16,07%
Sondages et Débats Discussion :

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


Sujet :

Sondages et Débats

  1. #41
    Expert éminent
    Avatar de bidou
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2002
    Messages
    3 055
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Transports

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 055
    Points : 7 962
    Points
    7 962
    Par défaut
    Citation Envoyé par ypicot
    Je ne te parle meme pas du fichier mdw qu'on n'a jamais sauvegardé et qu'on ne trouve plus parce que le serveur (ou le client) à été réinstallé...
    Celle-là je l'ai déja faite

  2. #42
    Membre expérimenté
    Avatar de Papy Turbo
    Homme Profil pro
    Développeur Office/VBA
    Inscrit en
    Mars 2004
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Office/VBA
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2004
    Messages : 822
    Points : 1 709
    Points
    1 709
    Par défaut
    Citation Envoyé par bidou
    Mais ce qui rend ta sécurité plus vulnérable car on peut facilement trouver ta stratégie de mdw, tu délègue la sécurité de celui ci à l'administration système et de fait il peut pas être trop sécurisé puisqu'il doit être au minimum accessible en lecture pour les utilisateurs faiblement privilégiés.
    J'avoue n'avoir pas compris grand chose.
    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.


    Citation Envoyé par bidou
    Citation Envoyé par Papy Turbo
    Je rêve moi aussi d'un API ou autre bout de code qui permettrait au code VBA d'avoir des droits supérieurs à ceux de l'utilisateur en cours, au niveau de windows (pour tripatouiller les installations, notamment !)
    Tu peux t'exécuter sur un compte différent mais le remède est souvent pire que le mal. Car VBA est un code interprété donc par définition faiblement protégé et alors là tu peux donner à l'utilisateur les moyens de récupérer un accés fortement privilégié.
    A mon avis il vaut mieux prendre le risque d'une vulnérabilité au niveau de la base que d'en ouvrir une au niveau du système.
    Ça m'intéresse beaucoup de savoir comment tu fais ça, à partir de VBA, sans te logger sous un nom différent.
    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.

  3. #43
    Membre expérimenté
    Avatar de Papy Turbo
    Homme Profil pro
    Développeur Office/VBA
    Inscrit en
    Mars 2004
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Office/VBA
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2004
    Messages : 822
    Points : 1 709
    Points
    1 709
    Par défaut
    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.

    Citation Envoyé par ypicot
    Le processus classique est
    - on copie le fichier mdb
    - on essaie de lancer le fichier mdb
    - on appelle le développeur parce que ça marche pas
    et, processus hélas totalement inévitable, et qui fait partie de la vie de tout programmeur :
    - 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.

  4. #44
    Expert éminent
    Avatar de bidou
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2002
    Messages
    3 055
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Transports

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 055
    Points : 7 962
    Points
    7 962
    Par défaut
    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

  5. #45
    Membre expérimenté
    Avatar de Papy Turbo
    Homme Profil pro
    Développeur Office/VBA
    Inscrit en
    Mars 2004
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Office/VBA
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2004
    Messages : 822
    Points : 1 709
    Points
    1 709
    Par défaut
    Citation Envoyé par bidou
    Si ca t'intéresse je te donnerais un exemple
    Voui, voui, voui
    Développement Office, support technique, assistance, sur place (Loire atlantique, Vendée, Maine et Loire) ou à distance.

  6. #46
    Membre confirmé Avatar de ypicot
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    412
    Détails du profil
    Informations personnelles :
    Âge : 60
    Localisation : France

    Informations forums :
    Inscription : Mai 2004
    Messages : 412
    Points : 579
    Points
    579
    Par défaut
    Citation Envoyé par Papy Turbo
    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.

    Citation Envoyé par ypicot
    Le processus classique est
    - on copie le fichier mdb
    - on essaie de lancer le fichier mdb
    - on appelle le développeur parce que ça marche pas
    et, processus hélas totalement inévitable, et qui fait partie de la vie de tout programmeur :
    - 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...
    Petite précision :
    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é

  7. #47
    Membre expérimenté
    Avatar de Papy Turbo
    Homme Profil pro
    Développeur Office/VBA
    Inscrit en
    Mars 2004
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Office/VBA
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2004
    Messages : 822
    Points : 1 709
    Points
    1 709
    Par défaut
    Salut,
    j'en reviens à ce fameux problème :
    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.
    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 ??

    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.

  8. #48
    Candidat au Club
    Inscrit en
    Mars 2005
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 3
    Points : 4
    Points
    4
    Par défaut
    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 ????

  9. #49
    Membre émérite

    Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 683
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 683
    Points : 2 576
    Points
    2 576
    Par défaut
    T'as pas du enlever les droits aux groupes et utilisateurs par défaut.

  10. #50
    Candidat au Club
    Inscrit en
    Mars 2005
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 3
    Points : 4
    Points
    4
    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 !!!

  11. #51
    Membre expérimenté
    Avatar de Papy Turbo
    Homme Profil pro
    Développeur Office/VBA
    Inscrit en
    Mars 2004
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Office/VBA
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2004
    Messages : 822
    Points : 1 709
    Points
    1 709
    Par défaut
    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.

  12. #52
    Membre régulier
    Profil pro
    Inscrit en
    Février 2005
    Messages
    218
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Février 2005
    Messages : 218
    Points : 85
    Points
    85
    Par défaut
    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..

  13. #53
    Membre expérimenté
    Avatar de Papy Turbo
    Homme Profil pro
    Développeur Office/VBA
    Inscrit en
    Mars 2004
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Office/VBA
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2004
    Messages : 822
    Points : 1 709
    Points
    1 709
    Par défaut
    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.

  14. #54
    Membre régulier
    Profil pro
    Inscrit en
    Février 2005
    Messages
    218
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Février 2005
    Messages : 218
    Points : 85
    Points
    85
    Par défaut
    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??

  15. #55
    Membre expérimenté
    Avatar de Papy Turbo
    Homme Profil pro
    Développeur Office/VBA
    Inscrit en
    Mars 2004
    Messages
    822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Office/VBA
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2004
    Messages : 822
    Points : 1 709
    Points
    1 709
    Par défaut
    Citation Envoyé par anikeh
    salut Papy Turbo,
    Ciao
    Citation Envoyé par anikeh
    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).
    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 !)
    Citation Envoyé par anikeh
    Voila comment je protège mes tables.
    De plus, je ne les distribue pas les tables, elle sont sur le reseau...
    ).
    Tout le monde a accès au réseau, sinon, l'appli non plus n'y aurait pas accès... Argument rejeté, votre honneur

    Citation Envoyé par anikeh
    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??
    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.

    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.

  16. #56
    Membre régulier
    Profil pro
    Inscrit en
    Février 2005
    Messages
    218
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Février 2005
    Messages : 218
    Points : 85
    Points
    85
    Par défaut
    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 !)
    Dans ce cas, comment tu protèges tes tables??

  17. #57
    Membre à l'essai
    Inscrit en
    Mars 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 16
    Points : 15
    Points
    15
    Par défaut [ACCESS] Access et les élections américaines
    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 !

    @++

  18. #58
    Expert éminent sénior

    Avatar de Tofalu
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Octobre 2004
    Messages
    9 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Associations - ONG

    Informations forums :
    Inscription : Octobre 2004
    Messages : 9 501
    Points : 32 311
    Points
    32 311
    Par défaut
    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 :

    Mot de passe par défaut : GEMSUSER
    Franchement s'agit t'il d'un mot de passe alors que :

    Citation Envoyé par L'aide
    Note Utilisez des mots de passe forts qui combinent des majuscules et des minuscules, des nombres et des symboles. Des mots de passe faibles ne combinent pas ces éléments. Mot de passe fort : Y6dh!et5. Mot de passe faible : Maison27. Utilisez un mot de passe dont vous pouvez vous souvenir sans le noter.
    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 !

    Encore une fois, une sécurité bien faite est solide... évidemment, si elle est mal faite, voire inexistante....

  19. #59
    Membre à l'essai
    Inscrit en
    Mars 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 16
    Points : 15
    Points
    15
    Par défaut
    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)


    @++

  20. #60
    Membre du Club
    Profil pro
    Inscrit en
    Février 2005
    Messages
    110
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2005
    Messages : 110
    Points : 66
    Points
    66
    Par défaut Allo la Terre, Ici la Lune
    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 ?

Discussions similaires

  1. besoin d'eclaircissement dans la sécurité dans access
    Par oops1980 dans le forum Sécurité
    Réponses: 4
    Dernier message: 09/05/2007, 12h05
  2. [Sécurité]Rejoindre fichier mdw dans access 2000
    Par pam-pg dans le forum Sécurité
    Réponses: 2
    Dernier message: 17/04/2007, 18h31
  3. Sécurité dans Access
    Par Ithilien dans le forum Sécurité
    Réponses: 4
    Dernier message: 27/01/2007, 00h21
  4. Sécurité dans Access
    Par vautour29 dans le forum Sécurité
    Réponses: 14
    Dernier message: 27/07/2006, 11h21
  5. Sécurité dans Access
    Par Jordmund dans le forum Sécurité
    Réponses: 3
    Dernier message: 16/03/2006, 11h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo