La sécurité interne

[naphta]

Bonjour,

Pour pouvoir réaliser sa propre sécurité aux niveau utilisateurs avec détection du login Windows et table collaborateurs-services.
(Attention : afin d’aller vite c’est une table qui se mord la queue collaborateurs dans service.)
Dans cette base il y a un contrôle des utilisateurs par le login Windows lié à un login enregistré dans la table employés.
On peut affecter à chaque utilisateur un niveau de sécurité.

Au démarrage de la base on compare le login Windows à celui enregistré si on trouve l’utilisateur pas de questions on affiche le formulaire de départ.
Dans l’autre cas, on ne trouve pas l’utilisateur on propose un formulaire de login avec la liste des utilisateurs connus et un mot de passe.

Dans la base plusieurs formulaires :
Clients : fichier clients
Gestion des Employés : Gestion des utilisateurs et Services
Depart : Formulaire affiché au départ de l’appli , le bouton qui permet l’appel au formulaire de gestion des collaborateurs et service et soumis à la sécurité, réservé aux utilisateurs de niveau >3 seulement. Dans l’exemple : Louis de Funès uniquement a ce droit.
Login : Formulaire qui s’affiche si l’on a pas découvert l’utilisateur, il affiche en autre le login découvert cela permet de savoir son propre login.

Pour les paranos on pourra crypter le champ niveau de sécurité avec un algorithme du style :
(A+x)*B=niveau de sécurité où x = le niveau de sécurité effectif
ou autre chose
En plus dans la base sur le formulaire Clients traçage qui a fait quoi et quand sur la table clients.
Cette base n’est pas complètement débuguée, n’hésitez pas à me remonter vos remarques.

A+

[naphta]

Salut,

Un piti oubli :
Si on est pas reconnu le formulaire de login s'affiche on sélectionne un collaborateur dans la liste le mot de passe pour tous est :
"motdepasse"

a+

[naphta]

Bonjour,
Et voila quand on est préssé ..

Une erreur sur l'algorithme :
ça c'est pas bon
(A+x)*B=niveau de sécurité où x = le niveau de sécurité effectif,

ici des séquences qui ne veulent rien dire à première vue :

(numemployé+C)+ ((A+x)*B) =niveau de sécurité
où x = le niveau de sécurité effectif et numemployé le champ numéro du collaborateur.

Désolé

[loufab]

Bonjour,

Il faut préciser que cette sécurité ne protége en rien les données.

En effet plusieurs techniques peuvent être utilisées pour les consulter :
Import / attachement des tables.
Démarrage avec le shift.
...

Dans l'état de l'applicatif (mdb) la création d'un formulaire/état permet de voir la structure et donc de récupérer les infos de Login, Password et Niveau. Préciser qu'il faut faire une compil MDE.

Concernant les API GetUSerName on remplace par un environ("username") bien moins complexe.

Une solution à coupler avec une base de données externe (SQL serveur, MySQL, Oracle...) mais pas Jet.

Donc pour les utilisateurs de versions <2007 la sécurité utilisateur Jet reste la solution optimale. Pour 2007, c'est le VPPC ou les base de données citées précédemment.

Pour conclure, la démonstration sera surement profitable à ceux qui cherche une "protection" dans un environnement d'utilisateurs très peu expérimentés.

Edit : Pour ne pas induire les lecteurs dans l'erreur, le titre devrait être Controle d'accès utilisateur mais pas Sécurité utilisateur.

Cordialement,

[Domi2]

Bonjour,

Si je peux me permettre...

Concernant les API GetUSerName on remplace par un environ("username") bien moins complexe.

Il est clair que l'emploi de l'API est plus lourd...

Mais sur certains postes de travail, l'utilisation de Environ() ramène "".

Personnellement, et par mesure de sécurité, j'utilise l'API.

Domi2

[naphta]

Bonjour

Il faut préciser que cette sécurité ne protége en rien les données.

C’est vrai c’est de la sécurité interne à l’application pour savoir qui peut modifier une facture ou bien seul le commercial pourra consulter ses marges et l’administrateur aussi cela va de soit etc etc

Concernant les API GetUSerName on remplace par un environ("username") bien moins complexe.

C’est en commentaire dans le code ou je précise que l’on peut substituer l’api par la fonction access, car cette fonction ne tourne pas dans les environnements Citrix.

J’ai déposé cette contribution après l’avoir envoyé à plusieurs membres du forum en pensant que cela pour être utile pour de la sécurisation sans se fouler. Cette base est juste un marche-pied au principe login Windows-base utilisateurs. Ce sera utile aux applications où on veut éviter des erreurs de manip de la part d’utilisateurs et de la discrétion sur certaines informations.

Bien entendu ce n’est pas une protection contre les utilisateurs ayant des connaissances et voulant à tout prix l’information mais là faut être réaliste quand on a des données sensibles on choisi pas access.

A+

[Domi2]

Bonsoir Naphta,

C’est en commentaire dans le code ou je précise que l’on peut substituer l’api par la fonction access, car cette fonction ne tourne pas dans les environnements Citrix.

Information précieuse... Merci...

Je vais en rester à l'emploi systématique de l'API, c'est plus sûr...

Domi2

[loufab]

Envoyé par naphta

... mais là faut être réaliste quand on a des données sensibles on choisi pas access.

Je souhaiterais lever une ambigüité concernant ACCESS. On a trop tendance à faire l'amalgame d'ACCESS et JET.

Rappelons que JET est à ACCESS ce que MySQL est à PHP (MERCI DE NE PAS SORTIR CETTE PHRASE DE SON CONTEXTE). Je prends cet exemple à titre de comparaison pour la raison suivante : PHP est communément utilisé en tandem avec MySQL et sont donc souvent installés conjointement (EasyPHP, solution LAMP...). Mais qui nous empêche d'utiliser un autre SGBDR avec PHP. Comme il n'y a pas d'obligation d'utiliser ACCESS avec Jet.

Notez que beaucoup d'éditeurs proposent maintenant leur SGBDR gratuitement, le dernier en date est Oracle avec sa version 10g limitée. Microsoft également avec une version SQL Serveur 2005 et MSDE.

Pour conclure et résumer : les versions Jet antérieures à 2007 sont correctement sécurisées, à partir de la version 2007 pensez à migrer vos données vers un autre SGBDR et à utiliser ODBC.

Cordialement,