Gestion des constats de sécurité liés à l'exposition des données

Contexte

Vous pourriez découvrir une exposition potentielle de données dans votre Mendix La protection des données de l'application est une responsabilité partagée entre la plateforme et l'équipe de développement. Mendix L'accès aux données est contrôlé par l'application. règles d'accès aux entités, rôles des modules, les rôles des utilisateurs et contraintes XPathSi ces paramètres ne sont pas correctement configurés, les utilisateurs peuvent accéder involontairement à des données qui devraient être restreintes.

Les risques de fuite de données peuvent être identifiés de différentes manières. Vous pouvez les découvrir lors d'un audit de sécurité périodique, d'un test d'intrusion, d'une analyse de sécurité automatisée ou suite à une prise de contact par un hacker éthique ou un chercheur en sécurité.

Dans de nombreux cas, ces constatations sont liées à une configuration d'accès aux entités incorrecte, à des mappages de rôles trop permissifs ou à des contraintes de données insuffisantes au sein de l'application. Il s'agit de problèmes de configuration au niveau de l'application et non de vulnérabilités dans le système. Mendix plate-forme elle-même.

Ce document décrit les étapes recommandées pour évaluer la situation, remédier au problème et réduire le risque de problèmes similaires à l'avenir.

Comprendre Mendix Sécurité des données

Mendix Les applications se composent de deux parties : la Mendix Projet, s'exécutant dans le navigateur ou l'application mobile de l'utilisateur final, et le Mendix Serveur d'exécution.

Le Mendix Le client communique avec le serveur d'exécution en utilisant le Mendix L'API client effectue des requêtes auprès du gestionnaire de requêtes `/xas/` sur le serveur d'exécution. Cette API repose sur le principe que les requêtes provenant du client ne peuvent être considérées comme sûres. Le client s'exécutant sur l'appareil de l'utilisateur final, hors du contrôle du serveur, toute donnée ou action peut y être manipulée. L'affirmation « Rien de ce qui se passe côté client ne peut être considéré comme sécurisé » s'applique à tout ce qui est stocké sur le client (par exemple, dans un navigateur), et pas seulement à l'API client. Mendix applications.

Par conséquent, dans MendixLa sécurité est toujours assurée côté serveur, au niveau du serveur d'exécution. avec des règles d'accès aux entités et des rôles autorisés sur les microfluxLe serveur d'exécution ne peut pas être manipulé par l'utilisateur final.

Vérifier la vulnérabilité

Lorsqu'une exposition potentielle de données est identifiée, la première étape consiste à en déterminer la portée et l'impact. L'équipe de développement doit reproduire le problème et confirmer quelles entités sont affectées et quels rôles utilisateurs y ont accès. Une attention particulière doit être portée à Rôle d'utilisateur anonyme et à tout rôle pouvant avoir un accès plus large que prévu.
Il est important de vérifier si l'exposition est due à une configuration manquante ou incorrecte règles d'accès aux entités, Incorrect mappages de rôles de modules, insuffisant contraintes XPathou une logique personnalisée telle que des microflux ou des services REST publiés qui contournent les contrôles attendus.

Pour comprendre si le problème a pu être exploité, Journaux du serveur web et de l'infrastructure Les journaux peuvent être analysés afin de détecter des schémas de trafic inhabituels ou des requêtes de données inattendues. Cependant, les journaux standard des serveurs Web ne fournissent pas d'informations détaillées sur les appels /xas spécifiques ni sur les données exactes récupérées. Mendix L'environnement d'exécution ne génère pas automatiquement de journaux d'audit détaillés des accès aux données. Si un audit détaillé des accès aux données est nécessaire, il incombe au propriétaire de l'application de mettre en œuvre de tels mécanismes de journalisation.

Remédiation

Après avoir confirmé le problème, nous recommandons les actions suivantes pour l'atténuer.

La configuration des accès aux entités doit être revue dans l'ensemble de l'application concernée. Assurez-vous que toutes les entités disposent de règles d'accès explicitement définies et conformes au modèle de sécurité prévu. Validez soigneusement les correspondances entre les rôles des modules et vérifiez que les contraintes XPath limitent correctement la visibilité des données. Portez une attention particulière aux autorisations accordées aux utilisateurs anonymes. Si l'accès anonyme n'est pas strictement nécessaire, il doit être désactivé ou fortement restreint.
Envisagez de passer à soutenu Mendix versions comme Mendix 10 LTS ou Mendix 11 MTS, le cas échéant, car ils offrent des fonctionnalités et des améliorations de sécurité renforcées. Lors de la migration, effectuez un examen complet des paramètres de sécurité et des règles d'accès.
Établissez un référentiel de sécurité adapté aux besoins de votre entreprise. Cela inclut la définition claire des normes de contrôle d'accès, la vérification des permissions des entités pendant le développement et la validation de la sécurité avant chaque mise en production. Les bonnes pratiques de développement sécurisé sont disponibles ici : Meilleures pratiques en matière de sécurité.
Pour renforcer la sécurité, nous vous recommandons également d'activer le mode strict. En savoir plus ici : Mode strict.
Envisagez la mise en œuvre d'outils comme le Outils de développement Ciphix, QSM (Gestion de la qualité et de la sécurité) ou Omnext pour l'analyse de sécurité.

Support supplémentaire

Si vous avez d'autres questions concernant la configuration de la sécurité des applications, ou si vous pensez que le problème peut être lié à Mendix Veuillez contacter la plateforme elle-même plutôt que la configuration de l'application. Mendix Soutenir.

Pour plus d'informations sur ce sujet, veuillez consulter :

Gestion des constats de sécurité liés à l'exposition des données | Mendix

Recherche du site