Access 2007 : Microsoft abandonne la gestion de la sécurité utilisateurs

[Tofalu]

Bonjour,

Dans l’aide Access, il est écrit :

Office Access 2007 ne fournit pas de sécurité de niveau utilisateur pour les bases de données créées avec les nouveaux formats de fichier (fichiers .accdb et .accde). Toutefois, si vous ouvrez une base de données créée avec une version précédente d'Access dans Office Access 2007 et que la sécurité de niveau utilisateur est appliquée à cette base de données, ces paramètres seront toujours actifs.

En effet, si vous vous penchez d'un peu plus près sur Microsoft Access 2007 vous constaterez que la gestion de la sécurité au niveau des utilisateurs a complètement disparue. Elle laisse place à une sécurité unique par mot de passe et chiffrement au niveau de la base de données.
Cette information alimente les débats dans les communautés anglophones. A l’heure actuelle, la communauté francophone semble endormie. De toute façon il est trop tard pour faire machine arrière mais il est peut être déjà temps de commencer à réfléchir à des solutions de remplacements. Rassurez-vous elles existent même si elles semblent plus complexe et moins abouties. Nous tacherons de les exposer dans un prochain article (notamment le vPPC d’Alan Cossey).

Que pensez-vous de cette nouvelle ? Pose-t-elle un frein au nouveau format de données Access 2007 ?

[DonkeyMaster]

Je n'utilise pas du tout Access, mais de façon générale je serais tenté de faire confiance aux ingénieurs Microsoft.

À une époque où l'on parle plus que jamais de sécurité informatique, cette décision semble aberrante. À moins qu'ils ne soient en train de reconnaître qu'Access n'est pas un produit complexe. Du genre, si tu veux un vrai SGBD, va voir du côté MSSQL.

Finalement, ce n'est peut-être pas si abérrant que ça. Je suppose que la plupart des fichiers Access sont gérés par des une seule personne, ou par très peu de personnes, et de toutes façons ils ne circulent pas.
Ou alors, le support reçoit beaucoup de problèmes qui en rapport avec cette fonctionnalité, et ce n'est pas toujours évident de le concevoir ou de le résoudre.

Je spécule, mais ce sont les premières idées qui me viennent à la tête.

[Tofalu]

Peut-être que de toutes façons personne ne s'en sert

Mmm si le message me parait correct, le titre que tu as choisi me parait complètement faux. Cette gestion utilisateur était un argument de vente il n'y a pas si longtemps.

[Lou Pitchoun]

Envoyé par DonkeyMaster

Finalement, ce n'est peut-être pas si abérrant que ça. Je suppose que la plupart des fichiers Access sont gérés par des une seule personne, ou par très peu de personnes, et de toutes façons ils ne circulent pas.
...
Je spécule, mais ce sont les premières idées qui me viennent à la tête.

Et bien justement si... c'est abérrant.

Si tu fait une recherche dans le forum avec le terme sécurité, tu te rendras compte qu'au vu des résultats beaucoup utilisent la sécurité utilisateurs car Access est utilisé en multi-utilisateur.

J'ai personnellement eu affaire à une entreprise assez renommée dans la menuiserie PCV-ALU-etc et bien j'ai été surpris de voir le commercial utiliser un outil developpé sur access (sécurité-réplicas-etc...).

Pour beaucoup de petites entreprises, Access reste un outil largement utilisé.

[Tofalu]

Ah oui, j'ai oublié de préciser, il en va de même pour la réplication.

Ceci dit, la réplication reste marginale face à la quantité d'utilisateur de la sécurité niveau utilisateur.

Du genre, si tu veux un vrai SGBD, va voir du côté MSSQL.

Sauf que SQL Server n'est pas déployable n'importe où. Le coup est élevé, nécessite une attention plus particulière, etc.

Si Access a ateint la niche dans lequel il est depuis maintenant 10 ans (grâce à la démocratisation d'Access 97), c'est à cause de sa polyvalence au sein des petits SI. Et toute appli néessite une sécurité utilisateur ne serait ce que pour différencier l'utilisateur du développeur.

La solution d'Alan Cossey est certes pratique : elle protège essentiellement l'accès aux tables par les utilisateurs non autorisés mais elle ne permet pas de restreindre l'accès aux autres objets facilement. Sans compter que cette méthode est jeune, que le produit Access 2007 n'est pas encore diffusé. Si ça se trouve, elle est très facile à outre passser.

La solution viable reste d'utiliser les anciens formats de fichiers mdb. Mais dans ce cas, adieu les nouveautés : pas de champs multivalués, pas de pièces jointes, pas d'historisation mémo.

À moins qu'ils ne soient en train de reconnaître qu'Access n'est pas un produit complexe

Si la suite Office reste largement utilisée par rapport à OpenOffice, c'est justement grâce à Access et Outlook

[mout1234]

Je suis trés surpris par cette nouvelle !



Je suppose que la motivation première est de limiter le périmètre d'exploitation d'Access ... en imaginant transposer plus de projets vers SQL Server et .Net...
ou peut-être est-ce simplement leur souhait de voir disparaitre ce système qui reste déconnecté du monde de la sécurité Microsoft (Active Directory ...)

Je serai probablement amené à regarder de plus prés des solutions concurrentes dans certains cas...!
Même s'il est vrai que je n'ai pas systématiquement utilisé ce système, préférant une simple identification codée par mes soins lorsque l'objectif - ce qui a été souvent le cas - n'est pas un problème de sécurité à proprement parlé mais plus simplement de délimiter un périmètre fonctionnel adapté à chaque besoin...

[mout1234]

Envoyé par Tofalu

Si Access a ateint la niche dans lequel il est depuis maintenant 10 ans (grâce à la démocratisation d'Access 97), c'est à cause de sa polyvalence au sein des petits

Il est clair pour moi que si Access ne répond plus à mes besoins, dans bon nombre de cas, je chercherai probablement une solution type Windev plutot que SQL Server qui est certes à mes yeux un trés bon SGBD mais qui est beaucoup moins adapté qu'Access pour les développements de petites ou moyenne dimension...

[DonkeyMaster]

Envoyé par Kikof

Et bien justement si... c'est aberrant.

Si tu fait une recherche dans le forum avec le terme sécurité, tu te rendras compte qu'au vu des résultats beaucoup utilisent la sécurité utilisateurs car Access est utilisé en multi-utilisateur.

J'ai personnellement eu affaire à une entreprise assez renommée dans la menuiserie PCV-ALU-etc et bien j'ai été surpris de voir le commercial utiliser un outil développé sur access (sécurité-réplicas-etc...).

Pour beaucoup de petites entreprises, Access reste un outil largement utilisé.

Soit. Mais dans ce cas, qu'est-ce qui peut bien motiver cette décision ? À vrai dire je ne comprends pas plus que vous.

Interlude :


En effet, il y a beaucoup de monde qui se plaint, et prévoit de rester sous 2003.
On ne pourrait pas, par exemple, lier le fichier Access à une base de données MySql, qui elle gèrerait tous ces droits? Hmm, non, insuffisant et complexe.
Les développeurs sont parfaitement capables d'écrire leurs propres classes de gestion de sécurité utilisateurs (ULS). Ce qui consommera du temps. Et puis, réinventer la roue, ce n'est jamais une bonne idée, diront tous les profs d'algorithmique après vous avoir fait écrire tous les algorithmes possibles avec des listes chaînées. Bref. Les développeurs Access seraient parfaitement capables de migrer vers MS SQL, mais n'ont pas le temps et l'argent. S'ils en avaient, ils seraient déjà sous Visual Studio, WinDev ou que sais-je encore.

Et puis, il y a aussi les gens qui l'utilisent sans être de grands programmeurs, et qui ne sauront pas attaquer une telle tâche, comme par exemple l'intelligente secrétaire d'une petite entreprise de 3 salariés qui n'a pas vraiment eu besoin d'engager une SSII parce-qu'elle a trouvé sur le net ce dont elle avait besoin et a bidouillé le reste.

Finalement, je suis d'accord avec vous, Microsoft n'a pas l'air d'avoir assuré sur ce coup-là.

Je n'ai pas trouvé (j'ai cherché seulement une demi-heure, cependant) quelqu'un qui défende ce choix. Les "MVP" disent ce qui se passe, ce qui change, mais ils ne disent pas le pourquoi de ce choix. Je chercherais davantage plus tard.

[hors sujet]
Je crois avoir tout compris. En fait, le service de support a convaincu les architectes que cette fonctionnalité était bidon et inutile, alors du coup eux ils auront moins d'appels à cause de cette fonctionnalité qui leur posait trop de problèmes. Et tout le monde les a crus.

Ou alors, ils avaient pas le temps, ils ont sacrifié trop de personnel pour Vista, et du coup n'ont pas eu assez de monde pour bien faire ça à temps pour la sortie d'Office 2007.


[/hors sujet]

[Tofalu]

Les "MVP" disent ce qui se passe

Parce que les MVp ne comprennent pas peut être pas comment la sécurité mdw a été pendant longtemps reputé comme LA sécurité à utiliser et mainetant MS dit : le mdw, c'était bidon.

Les développeurs sont parfaitement capables d'écrire leurs propres classes de gestion de sécurité utilisateurs (ULS).

Mmm, pas si simple quand on voit l'architecture de vPPC, c'est un peu tordu quand même.

développeurs Access seraient parfaitement capables de migrer vers MS SQL

Les développeurs oui, mais la question est : "et les clients ?"

Finalement, je suis d'accord avec vous, Microsoft n'a pas l'air d'avoir assuré sur ce coup-là.

On s'y fera... mais là où le bat blesse : si on nous à très vite informé des nouvelles fonctionnalités, je n'avais jusque là pas entendu parler de ça pendant le programme béta... soit 1 an quand même !

A mon avis, il s'agit clairement d'une volonté de faire de sql server et sharepoint le coeur du SI des sociétés. Ces sociétés suivront-elles ? je ne pense pas.

[Maxence HUBICHE]

Avant tout, je trouve aussi ce choix aberrant.

Cependant, cela s'inscrit, à mon avis, évidemment dans le cadre d'une stratégie de 'professionnalisation' de ce logiciel.
La relative fragilité -niveau stabilité - des BDD Access
La relative fragilité de la sécurité par mdw (cf. les crackers sur le net)
...
A certainement encouragé l'équipe Access dans ses modifications, afin de porter les utilisateurs vers Access, tout en encourageant fortement les développeurs à migrer sur une plateforme DotNet + SQLServer

De plus, toute l'architecture des SI d'information prévue par MS est centrée autour de SPS+SQLServer sur le framewwork DotNET.

Ces points m'encouragent à penser que la tendance n'est pas à l'amélioration du produit au niveau de ses performances, mais plutôt au niveau de son intégration dans cette architecture, ainsi que vers une orientation franchement 'USER' d'Access - d'où, par exemple, les champs multivalués, qui sont une ineptie totale sur le plan de la modélisation, mais tellement pratiques pour des utilisateurs lambda.

J'ajoute que, même si les fonctionnalités n'apparaissent plus dans les modèles, pas plus les classes dans le modèle DAO nouvelle génération, les classes sont visible en affichant les membres masqués du modèle.


Le pire, c'est qu'ils réagissent vraiment au format de BDD !
Voici ce que donne l'interface, suivant le format de fichier ouvert :

[Tofalu]

La relative fragilité -niveau stabilité - des BDD Access
La relative fragilité de la sécurité par mdw (cf. les crackers sur le net)

Mmmm...

Comme j'ai pu le lire ailleurs sur le net, la décision de supprimer les mdw serait motivées par ces deux hypothèses :

1. Fragilité de la sécurité niveau utilisateur
2. Migration DotNet/SQL server

J'ai du mal à croire à la première. Si le modéle actuel est fragile, pourquoi ne pas l'améliorer ? Le supprimer, c'est admettre qu'il était plus que fragile mais carrément nul, non ? Pour ma part je ne le juge pas fragile bien au contraire étant donné le domaine d'application d'Access. Access n'a jamais été destiné à un SI critique. Dés lors que le mdw soit "fragile" ne me pose pas de problème. Il me permet de sécuriser ma base en intranet à 99 %. Le 1 % restant, à la limite, je m'en moque puisque c'est le mieux que je pouvais faire.

De mon point de vue, il ne reste plus que la deuxième hypothèse. Mais n'est ce pas dangereux quand on sait à quel point la fonctionnalité était utilisé ? L'abandonner c'est forcer le choix du développeur.

Ces points m'encouragent à penser que la tendance n'est pas à l'amélioration du produit au niveau de ses performances, mais plutôt au niveau de son intégration dans cette architecture, ainsi que vers une orientation franchement 'USER' d'Access - d'où, par exemple, les champs multivalués, qui sont une ineptie totale sur le plan de la modélisation, mais tellement pratiques pour des utilisateurs lambda.

Oui, et je regrette ces nouveautés trop "newbie". A la limite, je serais partant pour rester en format de base de données 2003 (mais avec Access 2007). Malheureusement dans ce cas, je ne profiterais pas des champs pièces-jointes

J'ajoute que, même si les fonctionnalités n'apparaissent plus dans les modèles, pas plus les classes dans le modèle DAO nouvelle génération, les classes sont visible en affichant les membres masqués du modèle.

Oui mais surement pour la compatibilité non ?

Autre choses, sous Access 2007 (avec SQL 92), les requêtes CREATE GROUP, USER, GRANT, etc. fonctionnent (enfin plutot ne lève pas d'erreur, car il y a aucun résultat )

En vrac, mon avis

Le fichier MDW est très pratique, facile à mettre en oeuvre par le développeur.

Par contre, dans en entreprise, cela veut dire plusieurs types d'administrateurs d'utilisateurs.

Celui qui gère ADS et qui n'a pas besoin d'être défini dans le fichier MDW
et un administrateur de base qui lui doit être défini dans le fichier MDW.

Ce n'est pas le rôle du développeur d'administrer les utilisateurs.

En bref, si le fichier MDW semble et est au départ, la solution, à terme (pour le vivre dans l'entreprise ou je bosse), cela devient la galère pour la gestion des utilisateurs, surtout lorsque l'on va déléguer cette gestion à des postes
créés à cet effet.

Ne connaissant pas Access 2007 et au vu des réactions, je doute que Microsoft ait implémenté dans cette version une interface avec ADS.
Ce serait pourtant le pied.

[pseudocode]

Ah enfin un mouvement dans la bonne direction.

Ms-Access n'est pas un SGBD et encore moins multi-utilisateur.

Ceux qui comme moi ont testé l'integration Ms-Access et IIS se souviennent sans doute des messages "Erreur générale", "2 process ont tentés d'ecrire en meme temps", etc.

En ajoutant des fonctions comme la réplication et les droits d'acces au niveau utilisateur, Microsoft entretenait la confusion entre Ms-Access et Sql-Server. Pour moi, Ms-Access c'est un systeme de stockage, mono-utilisateur qui permet de rechercher ces données avec un langage pseudo SQL.

J'engage tous ceux qui cherchent une petite BdD multi-utilisateur a se tourner vers SQL-Server Express.

Pensée du jour: Access est à SQL-Server, ce que WordPad est a Word.

[Tofalu]

Ms-Access n'est pas un SGBD et encore moins multi-utilisateur.

Ah les arguments

Ceux qui comme moi ont testé l'integration Ms-Access et IIS

Access est un produit complet et tout le monde t'affirmera qu'il n'est pas fait pour du web. Le SGBD Access est destiné surtout à être utilisé avec Access.

c'est un systeme de stockage, mono-utilisateur qui permet de rechercher ces données avec un langage pseudo SQL.

C'est une vision simpliste d'un dixième des fonctionnalités du produits. C'est comme ceux qui affirme qu'on retrouve autant de fonctionnalités dans Office que dans OpenOffice sous prétexte qu'ils n'en utilisent qu'1 dixième.

Enlevez vos oeillères et ne portez un jugement que sur un produit que vous connaissez uniquement.

Access est à SQL-Server, ce que WordPad est a Word.

A la différence prés que Word intègre toutes les fonctionnalités de WordPad. Il n'en ai pas de même pour Access et MS Server

[pseudocode]

Envoyé par Tofalu

Access est un produit complet et tout le monde t'affirmera qu'il n'est pas fait pour du web. Le SGBD Access est destiné surtout à être utilisé avec Access.

Comme quoi ce n'est pas un SGBD autonome, mais un produit qui integre une simili bdd afin de pouvoir offrir des fonctions de persistance. D'ailleur essaye de te connecter a distance au "SGBD" Access sans avoir accès au fichiers de stockage.

Envoyé par Tofalu

C'est une vision simpliste d'un dixième des fonctionnalités du produits. C'est comme ceux qui affirme qu'on retrouve autant de fonctionnalités dans Office que dans OpenOffice sous prétexte qu'ils n'en utilisent qu'1 dixième.

Enlevez vos oeillères et ne portez un jugement que sur un produit que vous connaissez uniquement.

J'ai lu toutes les docs MSDN concernant Access, MDAC (ADO, OLEDB) et Jet-Engine. D'ailleur ca n'etonne personne que la Jet-Engine gere les formats Access, Excel, CSV,... mais PAS SQL-Server ?

A moins bien sur, que Access n'incorpore PAS de moteur de base de donnée, et que ce soit la Jet-Engine qui soit le vrai moteur... Mais alors, c'est quoi Access ? Une interface pour creer des tables/requetes ? Un afficheur de formulaires utilisant ADO ? Un IDE pour VBA ? Un melange des 3 ?