Discussion :

[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]

... 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,

[7r17r1]

Bonjour,

J'ai penser a un moyen de sécurisé la base en utilisant le gestionnaire de table lié. Ce n'est que théorique car je n'ai pas le temps de le tester pour mon projet, celui-ci étant en phase de finalisation et devant être rendu sous peu.

Mais je me demande s'il ne serait pas possible de sécurisé la base de donnée en créant une base avec plusieurs frontale lié à une seule dorsale. En liant, via le gestionnaire de table lié, chaque frontale à cette dorsale
Après il suffirait de donner ou pas les autorisations windows sur chaque base frontale a chaque utilisateur, chacun ayant donc sa propre interface par la même occasion

Qu'en pensez vous, possible ou ca ne marchera pas ?

[naphta]

Bonjour,

Loufab avait raison il y a en gros 2 types de sécurités :
Celle qui consiste à protéger les données d'un pirate ou personne malveillante car la base contient des infos stratégiques

et celle qui consiste à éviter les modifications d'informations cruciales par des personnes non compétentes, la base ne contient rien d’extraordinaire

Pour la première, et à partir de la version 2007, Microsoft propose de crypter les données.
Dans tous les cas si la base contient réellement des infos très importantes faut passer par SQL server et des frontaux dotnet, faut pas jouer avec access.

Pour la seconde et bien c'est en utilisant une table lue au démarrage de type "personnel" avec les champs login et niveau d'autorisation.


a+

[bigguy2]

Bonjour,

Bon la discussion est un peu ancienne, mais je tente ma chance...

Je serais très intéressé par la solution de contrôle d'accès proposée par Naphta.
Par contre, je ne trouve pas la base exemple à laquelle il est fait référence dans le premier post.

Quelqu'un aurait un exemple de base dans laquelle cette solution seraient implémentée et dont je puisse m'inspirer ?

Merci d'avance...

[naphta]

Bonjour,

Désolé il n'y avait pas suffisamment de place sur mon espace pour conserver cette base. Ce n'est pas très difficile, j'ai retrouvé ceci en DAO :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
Function posivariable() As String
 
On Error GoTo CapteErr
 
Dim lasq As String
Dim rst As Recordset
Dim letexto As String
 
letexto = "Il faut renseigner le fichier des salariés"
 
lasq = "SELECT Personnel.IDPersonnel, Personnel.Genre, Personnel.NomSalarie, Personnel.PrenomSalarie, Personnel.Login, Personnel.nivsecure, Personnel.DashboardType"
lasq = lasq + " FROM Personnel"
 
Set rst = CurrentDb.OpenRecordset(lasq, dbOpenSnapshot)
 
rst.FindFirst "login='" + Environ("Username") + "'"
 
If Not rst.NoMatch Then
    numeroempl = rst!IDPersonnel
    NOMPRENOM = rst!PrenomSalarie + " " + rst!NomSalarie
    nivsecure = rst!nivsecure
    DashboardType = rst!DashboardType
    posivariable = "OK"
    Else
    If Environ("Username") = "Administrateur" Then
        numeroempl = 0
        NOMPRENOM = "Administrateur réseau"
        nivsecure = 2
        DashboardType = 0
        MsgBox "L'application ne vous a pas reconnu mais vous êtes administrateur." + vbCrLf + letexto, vbInformation, "Attention"
        posivariable = "Admin"
    Else
        numeroempl = 0
        NOMPRENOM = "Utilisateur inconnu"
        nivsecure = 1
        DashboardType = 1
        MsgBox "Vous n'êtes pas administrateur. Il vous sera impossible de configurer cette base" + vbCrLf + letexto, vbInformation, "Attention"
        posivariable = "Rien"
    End If
End If
 
rst.Close: Set rst = Nothing
 
Sortie:
    Exit Function
CapteErr:
  Select Case Err.Number
    Case Else
     MsgBox "Erreur " & Err.Number & ": " & Err.Description, vbCritical, "Module :Posivariable "
  End Select
posivariable = "Rien"
Resume Sortie
 
End Function

Ici c'est un test effectué au lancement d'une application attention il y a des variables globales.

Good luck

[bigguy2]

Merci Naphta pour la rapidité de la réponse.

Je vais m'inspirer de ça...