Le Software as a Service, également connu sous le nom de SaaS, est un service basé sur le cloud où, au lieu de télécharger un logiciel que votre PC de bureau ou votre réseau professionnel peut exécuter et mettre à jour, vous accédez à une application via un navigateur internet.

Les récentes violations de données chez CircleCI, LastPass et Okta soulignent un thème commun : Les piles SaaS d’entreprise connectées à ces applications de pointe peuvent être sérieusement menacées.

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

Si les dépenses consacrées à la sécurité SaaS ont tendance à augmenter, elles sont à la traîne par rapport à des catégories telles que la protection de l’infrastructure cloud et la sécurité du réseau. Selon Statista, une entreprise de taille moyenne utilise plus de 100 applications SaaS, dont beaucoup ne sont pas approuvées par le service informatique, ce qui crée une lacune flagrante en matière de sécurité SaaS.

Pourquoi les utilisateurs se tournent en masse vers les applications SaaS – et contournent souvent l’informatique dans le processus

Les outils de productivité pour des tâches telles que l’automatisation du marketing, la signature de documents et les prévisions de ventes sont passés d’un logiciel installé à un logiciel-service (SaaS), tout comme les comportements des utilisateurs finaux. Les employés trouvent que les solutions SaaS les aident à 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’accroître leur productivité avec les outils de leur choix. Ce comportement n’a rien de nouveau ni de malveillant en soi, mais il présente des risques importants pour la sécurité. À l’époque des logiciels installés, les organisations ajoutaient une sécurité de point final 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 une facette essentielle 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 de s’adresser à la sécurité ou au service informatique pour comprendre les politiques d’intégration des nouvelles solutions SaaS – et de faire face à la probabilité de paperasserie, de retards ou de refus pour leurs demandes – ils sortent leur carte de crédit ou optent pour un essai gratuit de 30 jours des applications SaaS. Les travailleurs prennent rarement en compte les implications en termes de sécurité de Shadow IT qu’ils ont introduite dans l’écosystème lorsqu’ils autorisent la connexion de leurs nouvelles applications aux systèmes SaaS de l’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 qu’il soit possible de surveiller ou de contrôler ce risque de surface d’attaque. Et cela se produit tous les jours.

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

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

• Un utilisateur a été authentifié dans une application SaaS d’entreprise, que ce soit via une authentification simple ou une authentification forte zero trust. Il se trouve maintenant dans le cloud SaaS.
• Cet utilisateur souhaite gagner du temps en passant de son outil de gestion de projet à ses documents, feuilles de calcul et courriels. Il cherche donc des moyens de rationaliser son travail. Cette recherche aboutit à un plug-in SaaS de gestion de projet populaire, éventuellement assorti d’une version d’essai gratuite, 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 plateforme SaaS majeure telle qu’une suite bureautique, et aux données qui y sont associées. Il n’y a pas de niveaux de droits d’autorisation différents que l’utilisateur peut sélectionner.
• Un jeton OAuth est créé par la suite bureautique. Ce jeton permet à l’application de gestion de projet et à la suite bureautique de maintenir une communication de cloud à nu basée sur l’API sans que l’utilisateur n’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 ne détecteront pas cette connectivité SaaS-to-SaaS.

Figure 1 : Schéma de l’interaction d’une connexion SaaS-SaaS avec un jeton OAuth.

Ces jetons d’application sont précieux car ils permettent à l’utilisateur d’accéder facilement à l’application de gestion de projet. Malheureusement, ils sont tout aussi précieux, si ce n’est plus, pour les attaquants qui cherchent un point d’entrée facilement exploitable dans un système SaaS d’entreprise.

Si les acteurs de la menace parviennent à détourner les jetons OAuth, ils peuvent s’introduire dans les CRM, les dépôts de code, etc. Une connexion SaaS-to-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 d’informatique sont surchargées par la surveillance et la maintenance des paramètres de configuration et de la croissance des plateformes SaaS de leur entreprise, sans parler des applications SaaS non autorisées. En l’absence de tout examen de sécurité, les connexions SaaS-to-SaaS créent des points d’extrémité potentiellement vulnérables.

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

• L’entreprise moyenne compte plus de 42 applications SaaS-to-SaaS distinctes connectées à des environnements SaaS vivants au sein de l’entreprise. Près de 50 % de ces applications ont été connectées directement par les utilisateurs finaux, et non par les équipes informatiques.
• Près de 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 dormantes, les applications SaaS-to-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 qui échappent à la protection traditionnelle des réseaux et des CASB.

Comme le montre cette étude, le nombre d’applications « autorisées » en contact avec des données potentiellement sensibles est impossible à évaluer et à contrôler sans l’outil de sécurité SaaS adéquat.

É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 avoir une visibilité sur la connectivité SaaS et l’activité des utilisateurs associée. Les solutions SaaS Security Posture Management (SSPM) répondent à ces préoccupations en apportant une visibilité et un contrôle sur le domaine 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-to-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 l’identification des 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 base d’activité SaaS à utiliser comme cadre de référence. Bien qu’il soit impossible d’éliminer complètement le risque d’une violation liée au SaaS, l’utilisation de la solution SSPM réduit considérablement ce risque.

Source : The Hacker News