La sécurité des applications est l'un des aspects les plus importants que les développeurs doivent maîtriser lors de la création Mendix applications. Cependant, il est courant que les développeurs attendent qu'une application soit presque terminée avant d'implémenter la sécurité ou qu'ils n'implémentent pas correctement les mesures de sécurité appropriées dès le départ. Cela peut entraîner de graves problèmes une fois que l'application est dans un environnement de production.
Cet article de blog abordera les principes fondamentaux clés que vous devez appliquer à une application pour une sécurité réussie.
Sécurité du projet et sécurité du module
Le terme « rôle d'utilisateur » peut avoir différentes significations en fonction du contexte dans lequel vous vous trouvez dans l'application, que ce soit dans le projet ou dans l'un des modules de l'application. Techniquement, un rôle d'utilisateur est le rôle qu'un utilisateur a dans l'application, tandis qu'un « rôle de module » est le rôle qu'un utilisateur a dans un module spécifique de l'application. En pratique, cependant, il est courant d'utiliser « rôle d'utilisateur » pour les deux situations.
Il s'agit d'une définition simple qui vous aidera à vous souvenir de quel rôle est lequel : un rôle utilisateur est le regroupement de rôles de module sélectionnés. Lors du développement d'une application, vous devez créer un ensemble de rôles de module pour chaque module que vous prévoyez d'utiliser dans l'application (si un module n'a besoin d'aucun type de sécurité, aucun rôle de module n'est nécessaire). Ensuite, vous pouvez créer les rôles utilisateur pour le projet lui-même.
Voici un exemple de la manière dont un rôle d'utilisateur est associé à plusieurs rôles de module :
Sécurité des entités et visibilité de la grille de modèles
Il est essentiel de savoir quand utiliser la sécurité des entités et la visibilité de la grille de modèles. Pour garantir la sécurité d'une application, vous devez vous assurer que les données sensibles ne quittent pas la base de données lorsqu'elles ne sont pas censées le faire. La sécurité des entités spécifie les données envoyées de la base de données au client tout en donnant aux utilisateurs la possibilité de créer et de supprimer des objets dans l'application.
Sans sécurité d'entité en place, n'importe quelle page peut récupérer des objets de données à partir d'une entité. Avec une contrainte XPath de grille de modèle, les données du serveur ne sont envoyées que si elles répondent aux critères de contrainte XPath. Cependant, cela n'est en vigueur que pour cette grille de modèle spécifique. En raison de la possibilité que toutes les données d'une entité puissent être envoyées de la base de données au client, une contrainte XPath de grille de modèle n'est pas considérée comme une contrainte de sécurité et ne doit pas être utilisée comme telle. Il s'agit d'une erreur courante que font les développeurs lors du développement d'applications, et cette erreur peut entraîner de graves problèmes de sécurité. Pour définir une contrainte spécifique dans une entité afin de la sécuriser, vous pouvez définir la contrainte XPath au niveau de l'entité afin que chaque grille de données que vous créez dans l'application ait automatiquement cette contrainte activée.
Si la sécurité de ces données n'est pas critique et que vous souhaitez uniquement filtrer les données visibles pour une grille de données spécifique, vous pouvez accéder à la grille de données elle-même et définir le XPath, comme indiqué ici :
Sécurité des applications Microflow
Lorsque vous utilisez des microflux dans une application, le premier contrôle de sécurité qui se produit avant l'exécution d'un microflux permet de s'assurer que l'utilisateur dispose de la sécurité appropriée au niveau du module. Si l'utilisateur dispose de l'accès approprié au niveau du module, le microflux et tous les sous-microflux de ce microflux déclenché s'exécutent. Les sous-microflux héritent de la sécurité de leur microflux parent, quel que soit le type de sécurité au niveau du module défini au niveau du sous-microflux. Ainsi, en pratique, si vous avez un microflux qui comporte plusieurs sous-microflux et que vous vous attendez à ce que seuls certains de ces sous-microflux s'exécutent en fonction de la sécurité du sous-microflux, votre configuration ne doit pas dépendre de la sécurité du sous-microflux, car elle s'exécutera à chaque fois que le microflux principal s'exécutera, ce qui entraînera un problème de sécurité.
La sécurité des microflux peut être délicate, car vous pouvez choisir si un microflux active la sécurité des entités pour déterminer les données qui peuvent être utilisées. Lorsqu'un microflux n'a pas de sécurité d'entité activée, un rôle d'utilisateur peut récupérer des objets d'une entité à laquelle le rôle d'utilisateur n'a pas accès, et donc un problème de sécurité peut survenir. Lorsque Appliquer l’accès aux entités est activé, l'arrière-plan du microflux devient jaune et tout type d'action sur la base de données prendra en compte si le rôle d'utilisateur a accès pour effectuer cette action. Ce niveau de sécurité supplémentaire garantit qu'une application ne donnera pas accidentellement aux utilisateurs la possibilité de lire, d'écrire ou de supprimer des objets qu'ils ne sont pas censés avoir.
La sécurité provoque un comportement étrange de l'application
Lors du développement et du test d'applications, l'un des problèmes courants que vous pouvez rencontrer est de ne pas voir un bouton ou une grille de données clairement visible dans le modélisateur.
Lorsque ce comportement se produit, la première chose à faire est de vérifier la sécurité du bouton d'action. Comme il s'agit d'un NOUVEAU bouton, vous devez d'abord vérifier si le Autoriser la création de nouveaux objets la case à cocher est sélectionnée pour cette entité.
Si cette case est cochée et que le bouton n'est toujours pas affiché, vous devez alors vérifier si le bouton déclenche un microflux au lieu d'afficher la valeur par défaut. Mendix NOUVEAU bouton. Dans le cas ci-dessus, un microflux est déclenché : le bouton d'action appelle un microflux appelé IVK_NewSalesContent. Lors de la vérification de la sécurité de ce microflow, vous pouvez voir que l'utilisateur n'a pas accès au microflow, d'où le fait que le bouton ne s'affiche pas.
Conclusion
La sécurité des applications est un élément essentiel du succès d'une application. MendixPrendre le temps dès le début du développement de votre application vous aidera à éviter certains des problèmes décrits ci-dessus et à vous assurer que votre application est aussi sécurisée que possible !
Si vous souhaitez en savoir plus sur Mendix sécurité des applications, veuillez lire le Mendix documentation du développeur trouvée ici.