Gartner estime que d’ici 2025, 70 % des applications d’entreprise seront construites sur des plates-formes low-code et no-code telles que Salesforce et ServiceNow. Mais ces plateformes procurent-elles un faux sentiment de sécurité ?
Lorsqu’on leur demande, les administrateurs Salesforce répondent souvent que l’entreprise est responsable de la sécurité. La sécurité est une responsabilité partagée sur les applications SaaS. Votre fournisseur sécurise l’infrastructure, et vos administrateurs et développeurs sont chargés de garantir les droits d’accès au moindre privilège.
Les mauvaises configurations du cloud sont responsables d’une multiplication par trois des violations de données. Généralement, une mauvaise configuration se produit lorsque les paramètres de sécurité sont autorisés par défaut, des niveaux d’accès inappropriés sont attribués ou des barrières de données ne sont pas créées pour protéger les données sensibles. La configuration d’une plate-forme low-code est si facile que l’administrateur low-code ne comprend souvent pas l’impact de cocher une case.
Lorsque l’on regarde l’impact d’une simple coche, ce sont les trois erreurs de configuration les plus risquées sur la plate-forme Salesforce : Modifier toutes les données (MAD) et Afficher toutes les données (VAD), Groupes de partage et de partage et Exécuter le code Apex sans la méthode « runAs » .
Regardons chacun et l’impact qu’ils peuvent avoir.
Les groupes de partage sont très puissants, mais ils peuvent potentiellement ouvrir un accès accidentel à des utilisateurs non autorisés.
MAD et VAD
Nous allons commencer par les plus évidents et les plus dangereux. Les autorisations Modifier toutes les données et Afficher toutes les données font exactement ce qu’elles disent. Il s’agit des autorisations de super utilisateur pour Salesforce.
Si un utilisateur dispose d’un VAD, il dispose d’un accès en lecture à tous les enregistrements de données du système. MAD signifie qu’ils peuvent également mettre à jour et supprimer chaque enregistrement. Ces autorisations ne doivent être accordées qu’aux administrateurs et même dans ce cas, à un nombre très limité de personnes.
Pourquoi un administrateur serait-il tenté de donner MAD ou VAD à des non-administrateurs ? Le cas typique est lorsqu’un utilisateur n’est pas en mesure d’accéder aux données dont il a besoin de voir. L’administrateur examine le profil et les ensembles d’autorisations de l’utilisateur, toutes les règles de partage et la hiérarchie des rôles, et ne peut pas déterminer pourquoi l’utilisateur ne peut pas voir les informations. En tant que « correction temporaire », ils donnent à l’utilisateur MAD ou VAD et maintenant l’utilisateur peut voir les enregistrements – ainsi que tout le reste du système.
Cette erreur peut également se produire lorsque les développeurs rencontrent le même dilemme. Ils activent temporairement MAD dans le profil utilisateur afin de progresser dans leur code et oublient plus tard qu’ils l’ont activé.
