Jump to content
  • 0

Sécurité


Matessias
 Share

Question

Bonjour à tous

Dès la création de l'application et tout au long de sa réalisation, je joue avec les "droits" que je définis dans les tables et dont dépend le masquage des boutons sur les modèles.

Exemple : un utilisateur ayant le droit administrateur peut créer un document > le bouton nouveau document apparaît sur le modèle document si la rubrique administrateur a pour valeur "oui" dans la table utilisateurs

Pour cela, les informations de l'utilisateur sont vérifiées à sa connexion avec son login et son mot de passe >>> capture-écran 1

J'ai pensé réserver à la fin de la réalisation de l'application la sécurité.

Pour cela, je crée les comptes avec les privilèges d'accès.

A son lancement, FM ouvre "sa fenêtre propre" de connexion >>> capture-écran 2 >>> puis ouvre "ma" fenêtre de connexion, ce qui n'est pas du tout génial !

Je veux me passer de la fenêtre de connexion de FM et garder la mienne tout en faisant ainsi le lien entre les droits que j'ai créés et les privilèges d'accès.

Cela relève-t-il du monde du possible ?

capture_ecran_1.jpg

capture_ecran_2.jpg

Link to comment
Share on other sites

23 answers to this question

Recommended Posts

  • 1
il y a 26 minutes, Matessias a dit :

je "perds" les droits que j'ai définis pour chaque utilisateur au profit des privilèges d'accès associés au compte prédéfini.

Salut Mamy,

Ces droits de l'utilisateur, tu peux les retrouver lors de ton script lié au bouton OK : il faut une action de script Reconnexion (sans boîte de dialogue), pour cela…

Ca marche ?

Link to comment
Share on other sites

  • 0

Bonjour,

Une manière de réaliser cela est de définir dans les options du fichier l'ouverture par défaut avec un compte et un mdp prédéfini.

Ce compte sera associé à un privilège aux accès très limités (par exemple ne voir que le modèle de login et ne pouvoir exécuter que les scripts d'ouverture et de connexion)


Bien à vous,

Tanguy

Link to comment
Share on other sites

  • 0

Cela signifierait-il que FM garderait les deux fenêtres d'ouverture ?

- la fenêtre FM pour se connecter avec le compte "par défaut"

- ma fenêtre de connection

Je me rends compte que dès qu'il y a un compte créé, FM ouvre "sa" fenêtre d'ouverture et tout le reste dépendra des privilèges associés à ce compte sans plus tenir compte des droits que j'ai définis !

Link to comment
Share on other sites

  • 0

La fenêtre d'ouverture de FM disparaît, certes, car l'application est ouverte automatiquement avec le compte prédéfini.

Seulement, je "perds" les droits que j'ai définis pour chaque utilisateur au profit des privilèges d'accès associés au compte prédéfini.

Link to comment
Share on other sites

  • 0

Haïe, j'ai mal en voyant ça ! Désolé, mais je ne peux pas laisser dire ça :

Il y a 19 heures, tcolles a dit :

Une manière de réaliser cela est de définir dans les options du fichier l'ouverture par défaut avec un compte et un mdp prédéfini.

Ce compte sera associé à un privilège aux accès très limités (par exemple ne voir que le modèle de login et ne pouvoir exécuter que les scripts d'ouverture et de connexion)


Bien à vous,

Tanguy

Désolé @tcolles mais le fait d'avoir un compte / mot de passe associé à un jeu de privilèges (même le plus restreint) utiliser en compte par défaut à l'ouverture n'est pas une protection. J'ai déjà pu le démontrer et sortir toutes les données de toutes les tables (y compris celles dont je n'avais aucun droit en lecture) et sans utiliser d'applications externes ! Donc NON !

Ce qu'il faut : c'est utiliser la gestion de l'authentification de FileMaker, en cela on définit des comptes/mot de passe dans la sécurité de FileMaker, puis lorsque l'utilisateur aura été authentifier par FileMaker, avec le nom de compte (Obtenir ( NomCompte) ) rechercher les droits spécifiques dans sa table. Mais en aucun cas on laisse la base s'ouvrir avec un compte par défaut.

Désolé, c'est mon coup d'humeur du matin 😉 je vais aller prendre mon café.

Link to comment
Share on other sites

  • 0

J'oublie de préciser que je ne peux expliquer ma méthode car c'est une faille de sécurité et que je ne souhaite pas la divulguer en publique. Mais je peux au moins vous conseiller de définir la version minimale autorisée à ouvrir vos solutions dans les préférences de fichier à 19.

Link to comment
Share on other sites

  • 0

Un bonjour à tout le monde

Mon apprentissage de FM s'enrichit et c'est un apport pour tous ceux qui foulent ce sentier de la passion !

Link to comment
Share on other sites

  • 0
Il y a 23 heures, David Julot a dit :

J'oublie de préciser que je ne peux expliquer ma méthode car c'est une faille de sécurité et que je ne souhaite pas la divulguer en publique

Bonjour @David Julot,

J'ai une question majeure sur tes tests et cette faille de sécurité : est-ce qu'elle joue d'un fichier à l'autre ?

Exemple :

  • j'ai un base d'entreprise, bien sécurisée par l'authentification native de FM,
  • sur les iPhones des salariés itinérants, j'ai un fichier satellite, sans authentification (car sinon, le taux d'utilisation par les-dits salariés passera de 80% à 2%, or mon but serait que cette utilisation monte au contraire à 100%) et qui s'ouvre en lecture/écriture,
  • avec ce fichier satellite, mes itinérants flashent des codes barre après chaque intervention,
  • ces flashs viennent alimenter la base principale, par liaison simple entre fichiers FM.

La grande question est donc : ton astuce et la faille de sécurité en question permettraient-elles de pirater le fichier principal ??

Bon dimanche à toi,

Jérémie

Link to comment
Share on other sites

  • 0

Si je comprends bien, @David Julot dit qu'aucun jeu de privilèges FileMaker ne peut empêcher l'accès aux données à cause d'une faille de sécurité. Il est donc désirable de n'accorder l'accès qu'aux gens de confiance, excluant donc un compte par défaut. Ai-je bien compris?

Link to comment
Share on other sites

  • 0

Hello @David Julot, vu l'importance de la faille que tu évoques cela mérite un peu plus d'infos - comment peux tu nous en dire plus ?. Il n'est pas toujours possible d'avoir un parc complètement à jour et chez de nombreux clients on fonctionne avec un patchwork de versions 17, 18, 19. Quelle a été la réaction de Claris face à cette faille ? Le monde aurait une autre allure si l'on pouvait fonctionner uniquement sur la confiance comme le suggère @David Lalonde, je crains qu'en matière de sécurité informatique on ait besoin d'un peu plus de solidité.

 

Link to comment
Share on other sites

  • 0

Bonjour à tous

Vos échanges enrichissent le sujet et me transportent dans une dimension qui ne m'est pas encore accessible !!!

Je suis confronté à une situation bien inattendue, toujours sur la question de sécurité :

1. Je n'ai que deux comptes pour le moment, apprentissage oblige :

- admin = accès intégral

- utilisateur = accès limité

Ci-joint la capture-écran des privilèges du compte utilisateur.

2. Ce compte utilisateur n'exécute pas les scripts servant à ouvrir les PDF en affichant l'erreur 3 sur la commande de script "sauvegarder en PDF"

compte.jpg

Link to comment
Share on other sites

  • 0

Salut Tanguy

Comme quoi, il suffit d'un rien pour être à côté de la plaque !

Merci !

Link to comment
Share on other sites

  • 0

Bonjour tout le monde,

À la demande générale… La faille fait appel au visualiseur de données qui pouvait être accessible sans aucun compte Full Access… Depuis, Claris a corrigé cette faille en appliquant la même règle que pour le Script Debugger. Autre point et c'est le plus important : tout le monde néglige les options de fichier, et plus grave encore l'option sur la version minimale autorisée.

Conclusion :

  • Toujours utiliser les versions les plus récentes d'une application (pour les failles corrigées).
  • Toujours bien vérifier les options de fichier.
  • N'essayez pas de recréer la roue, en recréant par exemple un système d'authentification (compte/mot de passe) en lieu et place de celui de l'application.

 

J'ai oublié de préciser que cette faille fonctionne aussi sur les fichiers dont on a supprimer le jeu de privilèges Full Access…

Edited by David Julot
ajout de la précision.
Link to comment
Share on other sites

  • 0
Il y a 2 heures, David Julot a dit :
  • Toujours utiliser les versions les plus récentes d'une application (pour les failles corrigées).
  • Toujours bien vérifier les options de fichier.
  • N'essayez pas de recréer la roue, en recréant par exemple un système d'authentification (compte/mot de passe) en lieu et place de celui de l'application.

Mouais… non!

Je te remercie @David Julot pour les informations relatif aux faiblesses de sécurité de FileMaker. Ici se heurtent, par contre, les besoins de sécurité et les autres besoins des solutions. L'équilibre est parfois délicat. Ça me fait penser à la constitution canadienne.

Chaque nouvelle version de FileMaker nous apporte de nouveaux bogues. Ils sont parfois assez problématiques que certains clients doivent attendre un correctif avant de faire les mises à jour. Claris a malheureusement une manie de maintenir des bogues pendant longtemps.

Nos clients nous mettent parfois dans une situation difficile au niveau de la marque en exigeant que toutes mentions de FileMaker soient masquées. La fenêtre d'authentification cri FileMaker.

Il y a aussi des cas d'utilisation où le moyen d'authentification des utilisateurs doit être simplifié, sinon les taux d'utilisation (comme le suggère @Jérémie Gimenez) et de productivité chutent.

FileMaker ne nous donne qu'un moyen à ma connaissance d'éviter la fenêtre d'authentification : l'étape de script Reconnexion. Ce moyen nécessite que la solution soit ouverte, donc déjà authentifiée. Je ne vois pas comment faire sans l'utilisation d'un compte à accès minimal.

Je sais que cette approche demande plus de soins pour assurer une sécurité adéquate. Nous avons souvent recours à d'autres outils pour augmenter la sécurité de FileMaker. L'utilisation d'un réseau VPN est un exemple.

Link to comment
Share on other sites

  • 0

Merci @David Julot, je serais intéressé par plus de détails sur les conditions qui permettent cette faille. Eventuellement en MP. Mes premières tentatives de reproduction ne sont pas fructueuses.

Il n'est par ailleurs pas normal que des failles de sécurité ne soient corrigées que par des versions majeures. La 18 est encore supportée, 18.0.3 corrige t'elle la faille ?

 

 

 

Link to comment
Share on other sites

  • 0
Il y a 5 heures, David Julot a dit :

 

  • Toujours bien vérifier les options de fichier.

Je pense que la faille est en lien avec la coche "Exiger les privilèges d'accès intégral.." dans l'onglet Accès au fichier des Paramètres de sécurité. Et sans utiliser le visualiseur de données..

Donc cette case devait être toujours coché ! surtout pour un import depuis un fichier tiers..

Link to comment
Share on other sites

  • 0
17 minutes ago, Jacques R. said:

"Exiger les privilèges d'accès intégral.."

Il n'y a pas vraiment de faille de FileMaker à ce niveau, mais tu as bien raison de mettre ce point en avant @Jacques R. si on ne règle pas correctement les privilèges au niveau de la couche des tables et rubriques et que l'on pense faire de la sécurité simplement via l'interface en affichant ou masquant une rubrique, on se trompe complètement. L'option d'accès au fichier uniquement réservé à un compte type  accès intégral devrait être cochée par défaut.

Link to comment
Share on other sites

  • 0

Donc on règle le problème de la gestion des autorisations via une table dédiée. Qui n'est plus une passoire avec le "Exiger les privilèges d'accès intégral". Mais la faille citée par @David Julot est-elle toujours d'actualité ?

 

Link to comment
Share on other sites

  • 0

Bonjour Jacques

Ce que j'évoquais est que le fait qu'un utilisateur ne puisse voir, éditer, supprimer un enregistrement ou une donnée contenue dans une rubrique ne peut être basé uniquement sur ce qui passe dans un modèle. Dans le privilège associé à l'utilisateur, il faut régler les droits sur les tables et rubriques.

(Il n'est pas question d'une table dédiée.)

Dès lors si la sécurité est correctement définie au niveau des droits sur les tables et enregistrements, on pourrait éventuellement laisser un utilisateur créer une source de données externe vers le fichier. Mais cette possibilité peut venir court-circuiter tout ce que le développeur aura mis en place au niveau de l'interface ( accès en mode utilisation à une rubrique, déclencheurs de scripts, listes de valeurs,...)

Il serait plus judicieux que par défaut seul un accès intégral ait la possibilité de créer une source de données externes vers un fichier X et que le développeur doive spécifiquement autoriser cela pour un autre type d'utilisateur ( par exemple dans le privilège)

La faille dont parle David est en lien avec le visualiseur de données

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...