Les récentes violations de données sur CircleCI, LastPass et Okta soulignent un thème commun : les piles SaaS d’entreprise connectées à ces applications leaders du secteur peuvent être gravement compromises.

CircleCI, par exemple, joue un rôle intégral de SaaS à SaaS pour le développement d’applications SaaS. De même, des dizaines de milliers d’organisations s’appuient sur les rôles de sécurité Okta et LastPass pour la gestion des identités et des accès SaaS. Les applications SaaS d’entreprise et de niche ont effectivement introduit une multitude de terminaux non surveillés dans des organisations de toutes tailles.

Alors que dépenses pour la sécurité SaaS est à la hausse, il est en retard par rapport à des catégories telles que la protection de l’infrastructure cloud et la sécurité du réseau. Selon Statista, l’organisation moyenne emploie plus de 100 applications SaaS, dont beaucoup ne sont pas autorisées par l’informatique, ce qui crée une lacune flagrante dans la sécurité SaaS.

Pourquoi les utilisateurs affluent vers les applications SaaS – et contournent souvent l’informatique dans le processus

Alors que les outils de productivité pour des tâches telles que l’automatisation du marketing, la signature de documents et la prévision des ventes sont passés du logiciel installé au SaaS, il en va de même pour les comportements des utilisateurs finaux. Les employés trouvent des solutions SaaS pour les aider à accomplir plus en moins de temps, en particulier avec la décentralisation croissante de la fonction informatique.

Les employés chercheront toujours des moyens d’augmenter leur productivité avec les outils de leur choix. Ce comportement n’a rien de nouveau ni de malveillant en soi, mais il pose des risques de sécurité importants. À l’ère des logiciels installés, les entreprises ont ajouté la sécurité des terminaux aux machines et appareils de travail pour s’assurer que leurs employés ne pouvaient pas télécharger de logiciels nuisibles ou être victimes d’attaques basées sur des logiciels malveillants. Cette approche reste un aspect clé de la sécurité globale des terminaux, mais elle ne reflète pas l’évolution de la façon dont les gens travaillent aujourd’hui : en dehors des réseaux d’entreprise et souvent sur des appareils personnels.

Plutôt que d’approcher la sécurité ou l’informatique pour comprendre les politiques d’intégration de nouvelles solutions SaaS – et faire face à la probabilité de bureaucratie, de retards ou de refus pour leurs demandes – ils sortent la carte de crédit ou optent pour un essai gratuit de 30 jours des applications SaaS . Les travailleurs prennent rarement en compte les implications de sécurité de la informatique fantôme ils ont introduit dans l’écosystème en autorisant la connexion de leurs nouvelles applications aux systèmes SaaS d’entreprise tels que Microsoft 365, Salesforce, Workday ou ServiceNow.

Ces connexions, associées aux paramètres d’autorisation hérités des utilisateurs, pourraient toucher les données les plus sensibles de l’organisation, sans possibilité de surveiller ou de contrôler ce risque de surface d’attaque. Et ça arrive tous les jours.

Comment les applications SaaS héritent des autorisations via les jetons OAuth

Dans de nombreuses organisations, les applications SaaS (et les connexions SaaS à SaaS) capitalisent sur Jetons d’accès OAuth à la fois au point de connexion initial et tout au long de leur cycle de vie. Le processus suit généralement ces étapes :

• Un utilisateur a été authentifié dans une application SaaS d’entreprise, que ce soit via une authentification simple ou une authentification forte Zero Trust. Ils sont maintenant dans le cloud SaaS.
• Cet utilisateur souhaite gagner du temps en basculant entre son outil de gestion de projet et ses documents, feuilles de calcul et e-mails. En conséquence, ils recherchent des moyens de rationaliser leur travail. Cette recherche mène à un plug-in SaaS de gestion de projet populaire, peut-être avec un essai gratuit, et l’utilisateur décide de l’essayer.
• L’utilisateur commence l’installation et clique sur « Oui » à une invite autorisant l’accès en lecture-écriture aux données d’une plate-forme SaaS majeure comme une suite de productivité bureautique, et aux données qui y sont associées. L’utilisateur ne peut sélectionner aucun niveau de droits d’autorisation différents.
• Un jeton OAuth est créé par la suite bureautique. Ce jeton permet à l’application de gestion de projet et à la suite de productivité bureautique de maintenir une communication cloud à cloud basée sur l’API sans que l’utilisateur ait à se connecter et à s’authentifier régulièrement.

À partir de ce moment, l’application de gestion de projet est continuellement connectée après l’authentification forte initiale. Les CASB et les SWG pas détecter cette connectivité SaaS à SaaS.

Figure 1 : Répartition de la manière dont une connexion SaaS à SaaS interagit avec un jeton OAuth.

Ces jetons d’application sont précieux car ils rendent l’application de gestion de projet facilement accessible pour l’utilisateur. Malheureusement, ils sont tout aussi précieux, sinon plus, pour les attaquants à la recherche d’un point d’entrée facilement exploitable dans un système SaaS d’entreprise.

La portée – et le risque – des applications SaaS et des connexions SaaS à SaaS présentes

Si les pirates réussissent à pirater les jetons OAuth, ils peuvent accéder aux CRM, aux référentiels de code, etc. Une connexion SaaS à SaaS compromise peut fournir un accès API valide et autorisé à une multiplicité d’environnements et de données SaaS de production différents.

Les équipes de sécurité et informatiques sont surchargées de surveillance et de maintenance des paramètres de configuration et de la croissance de leurs plates-formes SaaS d’entreprise, sans parler des applications SaaS non autorisées. Sans aucun examen de sécurité, les connexions SaaS à SaaS créent des terminaux potentiellement vulnérables.

La prévalence de ces connexions SaaS à SaaS est importante et souvent sous-estimée par les organisations informatiques. Selon le fournisseur de sécurité SaaS AppOmni:

• L’organisation moyenne d’une entreprise compte plus de 42 applications SaaS à SaaS distinctes connecté à des environnements SaaS en direct au sein d’une entreprise. Près de 50 % de ces applications étaient connectées directement par les utilisateurs finaux, et non par les équipes informatiques.
• Environ la moitié de ces 42 applications connectées n’ont pas été utilisées au cours des six derniers mois. Qu’elles soient actives ou inactives, les applications SaaS à SaaS connectées conservent leurs droits d’accès aux données.
• Bon nombre de ces organisations ont atteint un total de près de 900 connexions utilisateur-application.

Figure 2 : Les environnements SaaS contiennent de nombreux points d’entrée en dehors du réseau traditionnel et de la protection CASB.

Comme le montre cette recherche, le nombre d’applications « autorisées » en contact avec des données potentiellement sensibles est impossible à évaluer et à surveiller sans les outils de sécurité SaaS appropriés.

Étapes pratiques pour surveiller et sécuriser les connexions SaaS

La plupart des équipes de sécurité ne disposent pas des outils appropriés pour obtenir une visibilité sur la connectivité SaaS et l’activité utilisateur associée. Gestion de la posture de sécurité SaaS (SSPM) répondent à ces préoccupations en apportant visibilité et contrôle sur le parc SaaS.

Un professionnel de la sécurité ou de l’informatique peut, par exemple, utiliser SSPM pour découvrir tout ce qui s’exécute dans Salesforce, ainsi que les applications SaaS qui y sont connectées. Il en va de même pour de nombreuses autres applications SaaS utilisées par l’organisation.

Cette visibilité et ce contrôle accrus dans la surveillance continue des applications SaaS et des connexions SaaS à SaaS réduisent le risque de surface d’attaque et permettent un contrôle de sécurité proactif. Si une vulnérabilité est découverte, l’équipe de sécurité peut prendre des mesures, comme identifier les applications SaaS non autorisées, non sécurisées et sur-autorisées.

Grâce aux capacités de surveillance continue d’une solution SSPM, l’équipe de sécurité est en mesure de déterminer une ligne de base de l’activité SaaS à utiliser comme cadre de référence temporel. Bien que le potentiel d’une violation liée au SaaS ne puisse jamais être complètement éliminé, l’utilisation de SSPM réduit considérablement ce risque.