Lors de la création d’un Sandbox, l’état d’esprit tend à être que le Sandbox est considéré comme un endroit pour jouer, tester des choses, et il n’y aura aucun effet sur la production ou le système opérationnel. Par conséquent, les gens ne pensent pas activement qu’ils doivent s’inquiéter de sa sécurité. Cet état d’esprit est non seulement faux, mais extrêmement dangereux.
En ce qui concerne les développeurs de logiciels, leur version de bac à sable est similaire à une aire de jeux pour enfants – un endroit pour créer et tester sans interrompre les flux de production. Pendant ce temps, dans le monde de la cybersécurité, le terme « sandbox » est utilisé pour décrire un environnement virtuel ou une machine utilisée pour exécuter du code suspect et d’autres éléments.
De nombreuses organisations utilisent une Sandbox pour leurs applications SaaS – pour tester les modifications sans perturber l’application SaaS de production ou même pour connecter de nouvelles applications (un peu comme la Sandbox d’un développeur de logiciels). Cette pratique courante conduit souvent à un faux sentiment de sécurité et à son tour à un manque de réflexion sur ses implications en matière de sécurité. Cet article vous expliquera ce qu’est un bac à sable SaaS, pourquoi il est vulnérable et comment le sécuriser.
Fondamentaux de la cybersécurité et du bac à sable SaaS
UN la cyber-sécurité Le bac à sable permet de séparer les actifs protégés du code inconnu, tout en permettant au programmeur et au propriétaire de l’application de voir ce qui se passe une fois le code exécuté. Les mêmes concepts de sécurité sont utilisés lors de la création d’un SaaS Sandbox – il duplique l’instance principale de SaaS, y compris ses données. Cela permet de jouer avec l’application SaaS, sans influencer ni endommager le SaaS opérationnel – en production.
Les développeurs peuvent utiliser le bac à sable pour tester l’API, installer des modules complémentaires, connecter d’autres applications, etc., sans se soucier que cela affecte les utilisateurs réels de l’organisation. Les administrateurs peuvent modifier les configurations, tester les fonctionnalités SaaS, modifier les rôles, etc. Cela permet à l’utilisateur de mieux comprendre comment les modifications apportées au SaaS se dérouleront avant de l’implémenter sur une instance SaaS opérationnelle et critique. Cela laisse également du temps pour créer des directives, former le personnel, créer des flux de travail, etc.
Dans l’ensemble, l’utilisation d’une Sandbox est un excellent concept pour toutes les utilisations de logiciels et de SaaS ; mais comme toutes les grandes choses dans le monde du SaaS, le problème est qu’il y a un risque de sécurité majeur qui se cache à l’intérieur.
Sandbox Security Risques et réalités du monde réel
Un grand hôpital privé par inadvertance a révélé les données de 50 000 patients lorsqu’ils ont créé un site de démonstration (c’est-à-dire une Sandbox) pour tester un nouveau système de prise de rendez-vous. Ils ont utilisé la vraie base de données du centre médical, laissant les données des patients exposées.
Souvent, une Sandbox est créée à partir de données réelles, parfois même un clone complet de l’environnement de production, avec ses personnalisations. D’autres fois, la Sandbox est directement connectée à une base de données de production. Si un attaquant parvient à pénétrer dans la Sandbox en raison d’une sécurité laxiste, il aura accès à des trésors d’informations. (Cette fuite d’informations peut être problématique, en particulier si vous êtes une entreprise de l’UE ou si vous traitez des données de l’UE en raison du RGPD. Si vous traitez des informations médicales aux États-Unis ou pour une entreprise américaine, vous pouvez être en violation de HIPPA.)
Découvrez comment une SSPM peut vous aider à automatiser la sécurité de votre sandbox SaaS.
Même les organisations qui utilisent des données synthétiques, ce qui est recommandé pour toutes les entreprises, peuvent toujours être exposées à un risque d’attaque. Un attaquant peut utiliser la Sandbox pour la reconnaissance afin de mieux comprendre comment une organisation configure ses fonctions de sécurité et ses éventuels points faibles. Étant donné que la Sandbox reflète dans une certaine mesure la configuration du système opérationnel, un attaquant peut utiliser ces connaissances pour pénétrer dans le système de production.
Comment sécuriser votre bac à sable SaaS
La solution au problème de la Sandbox non sécurisée est assez simple : sécurisez la Sandbox étape par étape comme s’il s’agissait d’un système de production.
Étape 1. Gérez et contrôlez l’accès à une Sandbox et limitez l’accès des utilisateurs à la Sandbox. Par exemple, tous les utilisateurs ayant accès à la production ne doivent pas également avoir accès à la Sandbox. Contrôler quels utilisateurs peuvent créer et accéder à une Sandbox est la première étape pour sécuriser votre environnement SaaS.
Étape 2. Implémentez les mêmes paramètres de sécurité que ceux configurés dans le système opérationnel pour la version Sandbox ; de l’exigence de MFA à la mise en œuvre de SSO et IDP. De nombreuses applications SaaS disposent de fonctionnalités de sécurité supplémentaires conçues sur mesure pour cette application SaaS spécifique et doivent être reflétées dans la Sandbox. Par exemple, Salesforce dispose de fonctionnalités de sécurité uniques telles que la protection contre le reniflage de contenu, les niveaux de sensibilité des données par défaut, l’authentification via un domaine personnalisé, etc.
Étape 3. Supprimez les données de production et remplacez-les par des données synthétiques (c’est-à-dire inventées). Les bacs à sable sont généralement utilisés pour tester les modifications apportées aux configurations, aux processus, aux flux (tels qu’APEX), etc. Ils ne nécessitent pas de données réelles pour tester les modifications – toutes les données avec le même format peuvent être suffisantes. Par conséquent, évitez de copier les données de production et utilisez plutôt Data Mask.
Étape 4. Gardez votre Sandbox en ligne avec les améliorations de sécurité apportées dans l’environnement de production. Souvent, une Sandbox n’est ni actualisée ni synchronisée au jour le jour, ce qui la rend vulnérable aux menaces qui ont été minimisées lors de la production. Pour réduire les risques et vous assurer que votre Sandbox remplit son objectif, une Sandbox doit être synchronisée tous les jours.
Automatisez votre sécurité SaaS
Les équipes de sécurité peuvent également mettre en œuvre et utiliser des solutions SSPM (SaaS Security Posture Management) pour automatiser leurs processus de sécurité SaaS et relever les défis détaillés ci-dessus, pour surveiller et empêcher les menaces de s’infiltrer dans le bac à sable SaaS.
Un SSPM, comme Adaptive Shield, entre en jeu pour permettre aux équipes de sécurité d’identifier, d’analyser et de hiérarchiser les erreurs de configuration dans la Sandbox et sur l’ensemble de la pile d’applications SaaS, ainsi que de fournir une visibilité aux applications tierces avec accès aux applications principales, Device -to-SaaS Gestion de la posture des utilisateurs et plus encore.
Découvrez comment automatiser la sécurité de votre pile d’applications Sandbox et SaaS.
Noter: Cet article est rédigé par Hananel Livneh, analyste produit senior chez Adaptive Shield.
