L’angle mort du SaaS : pourquoi les équipes de sécurité ne peuvent pas accéder à leurs propres applications

Je pose cette question dans presque tous les engagements : combien d’applications SaaS votre organisation exécute-t-elle ? Les réponses que j’obtiens vont de 30 à peut-être 50. Le nombre réel, une fois que quelqu’un compte, se situe généralement au nord de trois cents. L’étude AppOmni de 2024 le place encore plus haut : 49 % des organisations Microsoft 365 pensaient avoir moins de dix applications connectées à leur locataire alors que la moyenne réelle était supérieure à mille.

Voici la partie qui me préoccupe plus que le décompte. Parmi toutes ces applications, les équipes de sécurité en ont une vue claire sur peut-être une sur dix. Le reste – où se trouvent les dossiers de vos clients, où se trouve votre code source, où vos rapports financiers sont partagés – personne ne les regarde. Pas parce que l’équipe est négligente. Parce que les outils dont ils disposent n’ont jamais été conçus pour y regarder.

Les incidents suivants discuteront de ces réalités.

En avril 2023, KrebsOnSecurity a révélé l’affaire : les sites de la communauté Salesforce divulguaient discrètement des données sensibles appartenant à des agences gouvernementales, des banques et des prestataires de soins de santé. Aucune technique d’attaque sophistiquée. Juste le bon point de terminaison d’API et un profil d’utilisateur invité mal configuré. Les enregistrements exposés comprenaient des numéros de sécurité sociale, des détails de compte et des adresses personnelles. Salesforce a été clair dans sa réponse : il ne s’agissait pas d’une vulnérabilité de plateforme. Les administrateurs avaient mal configuré les politiques d’accès des invités et personne n’avait vérifié.

Les profils d’utilisateurs invités dans Salesforce Communities peuvent avoir accès aux enregistrements de données. Lorsque les administrateurs définissent ces autorisations de manière trop large, souvent sans s’en rendre compte, des utilisateurs externes non authentifiés peuvent interroger ces données directement via l’API. Plus de 150 000 entreprises étaient potentiellement assises dans cette fenêtre avant que quiconque ne tire la sonnette d’alarme.

Le modèle est toujours le même. Configuration réalisée sous pression temporelle, réglage par défaut légèrement trop permissif, personne ne le revoit. Les applications SaaS accumulent ces expositions discrètes au fil des mois et des années.

En avril 2022, GitHub a révélé qu’un attaquant avait utilisé des jetons OAuth volés – délivrés à Heroku et Travis CI – pour accéder et télécharger le contenu de référentiels privés de dizaines d’organisations, dont npm. Les propres systèmes de GitHub n’ont jamais été touchés. Les jetons provenaient d’applications tierces que les utilisateurs avaient autorisées à se connecter à leurs comptes, et ces applications avaient été discrètement compromises.

Le point d’entrée n’était pas GitHub. Ce ne sont même pas les organisations qui ont perdu leurs données. Il s’agissait des outils CI/CD que ces organisations avaient connectés à GitHub des mois ou des années plus tôt – des outils bénéficiant de larges autorisations de lecture et d’écriture qui n’ont jamais été revisités.

C’est le problème d’OAuth en termes simples. Au moment où vous autorisez une application tierce ; sa posture de sécurité devient également votre problème. La plupart des organisations ont des dizaines de ces connexions ouvertes sur leurs plates-formes SaaS – et personne ne les examine.

Le cas Microsoft de 2023 est celui que j’évoque lorsque les gens supposent que cela n’arrive qu’aux organisations imprudentes. Wiz Research a découvert que la propre équipe d’IA de Microsoft avait exposé 38 To de données internes (clés privées, mots de passe et plus de 30 000 messages Teams internes) via un seul jeton d’accès Azure mal configuré. Le jeton était censé partager un ensemble de données de formation sur GitHub. Au lieu de cela, il a ouvert un compte de stockage complet à toute personne trouvant le lien.

Ce qui m’intéresse dans celui-ci, c’est la chronologie. Ce jeton était là depuis octobre 2021. Près de deux ans, au sein de Microsoft, avant que quiconque ne l’attrape. Si une équipe disposant de ce niveau de ressources et d’expertise peut laisser une porte ouverte pendant deux ans, l’idée selon laquelle « nous le remarquerions » n’est pas vraiment une stratégie de sécurité. Et il convient de le noter : il ne s’agissait pas d’une fuite de base de données. C’étaient des messages Teams. Les mêmes outils de collaboration que vos employés utilisent quotidiennement sont tout aussi exposés que les plateformes détenant des enregistrements structurés.

Les outils de gestion de la posture de sécurité du cloud (CSPM) sont conçus pour surveiller la configuration de l’infrastructure : machines virtuelles, compartiments de stockage, règles réseau et politiques IAM au niveau de l’infrastructure. Ils font un travail acceptable à ce niveau. Ce qu’ils ne font pas, c’est regarder à l’intérieur des applications SaaS. Les directives SCuBA (Secure Cloud Business Applications) de CISA soulignent spécifiquement l’écart entre les outils de sécurité de l’infrastructure et la visibilité de la couche SaaS comme l’un des domaines les plus sous-abordés de la sécurité du cloud d’entreprise.

C’est l’écart pour combler l’écart que SSPM a été créé. Au lieu de surveiller l’infrastructure, il surveille la configuration des applications SaaS elles-mêmes : autorisations, paramètres de partage, qui a accès à quoi. Et la distinction n’est pas seulement académique. Les mauvaises configurations de l’infrastructure ont tendance à exposer les systèmes. Les mauvaises configurations SaaS ont tendance à exposer les données – directement, discrètement et souvent sans aucune activité d’attaque détectable.

Vous n’avez pas besoin de déployer une plateforme SSPM complète demain pour commencer à combler l’écart. Il existe des mesures pratiques qui font bouger les choses immédiatement.

• Auditez les applications OAuth connectées sur vos principales plateformes SaaS. Révoquez toute intégration qui ne peut être justifiée par un besoin commercial actuel.
• Source commune d’exposition des données publiques : vérifiez les autorisations d’invité et de partage externe dans Salesforce Communities et Microsoft SharePoint.
• Vérifiez si les protocoles d’authentification hérités sont désactivés dans Microsoft 365. L’authentification héritée contourne MFA et devient un point d’entrée potentiel dans les environnements d’entreprise.
• Établissez un examen trimestriel des accès aux comptes à privilèges élevés dans les applications SaaS. La plupart des organisations effectuent au mieux des évaluations annuelles, ce qui n’est pas assez fréquent pour les plateformes dont la configuration change quotidiennement.
• Une carte indiquant quelles applications SaaS détiennent des données sensibles et lesquelles n’appartiennent à aucune équipe de sécurité. Cette liste sera plus longue que prévu.

Le problème principal n’est pas que les organisations soient négligentes. C’est qu’ils ont construit des programmes de sécurité autour du périmètre et de l’infrastructure, et que les applications SaaS se sont développées à l’intérieur de ce périmètre sans jamais être intégrées à leur portée. Les données sont là. L’accès est là. La mauvaise configuration est souvent là aussi. Ce qui manque, c’est la visibilité pour le voir.

SSPM comble cette lacune. Mais avant même qu’un outil formel ne soit en place, il suffit de se poser la question : que peuvent voir et partager les applications que nous exécutons déjà ? – est une première étape significative. D’après mon expérience, la réponse surprend presque toutes les organisations qui prennent le temps d’y réfléchir.