Attention à l'usurpation d'identité dans les applications Low-Code/No-Code

Le mois dernier, j'ai écrit un article sur la façon dont les plates-formes low-code/no-code proposent le partage d'informations d'identification en tant que service, pourquoi elles le font et à quoi cela ressemble le point de vue d'un attaquant. Dans cet article, je vais me concentrer sur les implications de ce compromis et comment il affecte les entreprises aujourd'hui.

Voici pourquoi le partage de vos informations d'identification d'entreprise avec quelqu'un d'autre est une mauvaise pratique. Supposons que je souhaite transmettre mes informations d'identification à un collègue afin d'interroger les journaux de production pour une analyse ponctuelle du comportement des utilisateurs. Dans une entreprise typique, accorder à quelqu'un des autorisations pour interroger une nouvelle source de données peut signifier un long processus d'examen des accès, en particulier lorsqu'il s'agit de données de production ou sensibles. Mon collègue pourrait facilement être frustré. "Tout ce que je voulais, c'était faire cette petite requête ponctuelle, et ça fait déjà un mois que j'attends !" pourraient-ils dire. Je pourrais simplement exécuter la requête pour eux, mais je suis submergé par mes propres tâches quotidiennes et les requêtes ponctuelles ont tendance à se compliquer.

Il me reste une solution rapide : je pourrais simplement partager mon nom d'utilisateur/mot de passe avec mon collègue. S'ils obtiennent un défi MFA, j'approuverai avec plaisir. Je n'ai pas besoin de passer du temps à exécuter la requête et mon collègue est débloqué. Tout le monde gagne ! Droit?

Eh bien, vous auriez raison dans votre analyse, mais vous manquez la vue d'ensemble. Bien qu'il soit important pour l'entreprise que votre collègue effectue son analyse du comportement des utilisateurs, il est tout aussi important, sinon plus, que votre entreprise reste conforme à toute une série de normes de confidentialité et de sécurité et maintienne la confiance des clients en respectant l'engagement de l'entreprise en matière de sécurité. .

Si les objectifs d'entreprise de haut niveau ne vous convainquent pas, envisagez les équipes de gestion centrales en informatique ou en sécurité. Ces équipes fondent leurs opérations et leurs stratégies de sécurité sur le fait que chaque utilisateur a sa propre identité unique. Les équipes informatiques mettent en place des politiques de mise en réseau et d'accès qui supposent que chaque utilisateur serait connecté à partir d'une adresse IP d'entreprise ou d'un ordinateur portable d'entreprise à la fois ; les équipes de sécurité corrèlent les événements en fonction de l'ID utilisateur ; les équipes financières pourraient agréger les rapports de coûts par utilisateur et leur environnement cloud personnel. Le partage des informations d'identification sape toutes ces hypothèses, entre autres. Il enlève la signification fondamentale d'une identité en ligne.

Un exemple concret

Passons au monde du low-code/no-code et examinons un scénario du monde réel. Dans une grande entreprise, Jane, une employée inspirée de l'équipe du service client, s'est rendu compte que lorsque les employés de toute l'organisation prennent part à un cas client, il leur manque généralement des informations clés sur le client, telles que l'historique de leur cas de support et leurs derniers achats. Cela dégrade l'expérience du client, car il doit expliquer son problème encore et encore pendant que le cas est acheminé vers le bon employé qui peut résoudre le problème.

Pour améliorer cela, Jane a créé une application qui permet aux employés de l'entreprise d'afficher ces informations clés sur les clients lorsque ces employés font partie de l'équipe chargée de traiter le dossier d'assistance du client. Tout d'abord, prenons un moment pour reconnaître la puissance du low-code/no-code, qui permet à Jane d'identifier un besoin et d'y répondre par elle-même, sans demander de budget ni attendre les allocations de ressources informatiques.

Lors de la création de l'application, Jane a dû résoudre plusieurs problèmes, le plus important étant les autorisations. Les employés de l'entreprise n'ont pas un accès direct pour interroger la base de données clients afin d'obtenir les informations dont ils ont besoin. S'ils le faisaient, Jane n'aurait pas à créer cette application. Pour surmonter ce problème, Jane s'est connectée à la base de données et a intégré sa session authentifiée directement dans l'application. Lorsque l'application reçoit une requête d'un utilisateur, elle utilise l'identité de Jane pour exécuter cette requête, puis renvoie les résultats à l'utilisateur. Cette fonctionnalité d'intégration des informations d'identification, comme nous l'avons exploré le mois dernier, est une fonctionnalité clé des plates-formes low-code/no-code. Jane s'est assurée de configurer le contrôle d'accès basé sur les rôles (RBAC) dans l'application de sorte que chaque utilisateur ne puisse accéder qu'aux cas clients auxquels il est affecté.

L'application a résolu un problème commercial important et a rapidement été adoptée par les utilisateurs dans toute l'entreprise. Les gens étaient heureux de pouvoir offrir un meilleur service à leurs clients en ayant le bon contexte pour la conversation. Les clients étaient également ravis. Un mois après la création de l'application par Jane, celle-ci était déjà utilisée par des centaines d'utilisateurs dans toute l'organisation, avec des taux de satisfaction client en hausse.

Pendant ce temps, au SOC, une alerte de haute gravité indiquant une activité anormale autour de la base de données client de production a été déclenchée et attribuée à Amy, une analyste de sécurité expérimentée. L'enquête initiale d'Amy a montré qu'un utilisateur interne tentait de récupérer l'intégralité de la base de données, en demandant des informations sur plusieurs clients à partir de plusieurs adresses IP de l'entreprise. Le modèle de requête était très complexe ; au lieu d'un simple modèle d'énumération que l'on s'attendrait à voir lorsqu'une base de données est récupérée, les données du même client ont été interrogées plusieurs fois, parfois via différentes adresses IP et à différentes dates. Serait-ce un attaquant essayant de confondre les systèmes de surveillance de la sécurité ?

Après une enquête rapide, Amy a découvert une information cruciale : toutes ces requêtes sur toutes les adresses IP et les dates utilisaient une seule identité d'utilisateur, une personne nommée Jane de l'équipe du service client.

Amy a contacté Jane pour lui demander ce qui se passait. Au début, Jane ne savait pas. Ses identifiants ont-ils été volés ? A-t-elle cliqué sur le mauvais lien ou fait-elle confiance au mauvais e-mail entrant ? Mais lorsque Jane a parlé à Amy de l'application qu'elle a récemment créée, elles ont toutes les deux réalisé qu'il pourrait y avoir un lien. Amy, l'analyste SOC, n'était pas familière avec le low-code/no-code, alors ils ont contacté l'équipe AppSec. Avec l'aide de Jane, l'équipe a découvert que l'application de Jane contenait les informations d'identification de Jane intégrées. Du point de vue de la base de données, il n'y avait pas d'application — il n'y avait que Jane, exécutant un grand nombre de requêtes.

Jane, Amy et l'équipe AppSec ont décidé de fermer l'application jusqu'à ce qu'une solution soit trouvée. Les utilisateurs de l'application dans toute l'organisation étaient frustrés car ils en étaient venus à s'y fier, et les clients le ressentaient également.

Alors qu'Amy a clos le problème et documenté ses conclusions, le vice-président du service client n'était pas content de voir le taux de satisfaction client baisser, alors ils ont demandé à Jane de rechercher une solution permanente. Avec l'aide de la documentation de la plate-forme et de l'équipe du centre d'excellence de l'organisation, Jane a supprimé son identité intégrée de l'application, a modifié l'application pour utiliser l'identité de chaque utilisateur pour interroger la base de données et s'est assurée que les utilisateurs obtiennent des autorisations uniquement pour les cas clients auxquels ils sont associés. . Dans sa nouvelle version améliorée, l'application utilisait l'identité de chaque utilisateur pour interroger la base de données clients. Jane et les utilisateurs de l'application étaient heureux que l'application soit de nouveau en ligne, Amy et l'équipe AppSec étaient heureuses que l'identité de Jane ne soit plus partagée, et l'entreprise a vu le taux de satisfaction client recommencer à grimper. Tout allait bien.

Deux semaines plus tard, le SOC a reçu une autre alerte concernant un accès anormal à la base de données des clients de production. Cela ressemblait étrangement à l'alerte précédente sur cette même base de données. Encore une fois, les adresses IP de toute l'organisation utilisaient l'identité d'un seul utilisateur pour interroger la base de données. Encore une fois, cet utilisateur était Jane. Mais cette fois, l'équipe de sécurité et Jane savaient que l'application utilise les identités de ses utilisateurs. Que se passe-t-il?

L'enquête a révélé que l'application d'origine avait partagé implicitement Session de base de données authentifiée de Jane avec les utilisateurs de l'application. En partageant l'application avec un utilisateur, cet utilisateur a obtenu un accès direct au connexion, un wrapper autour d'une session de base de données authentifiée fournie par la plate-forme low-code/no-code. Grâce à cette connexion, les utilisateurs pouvaient exploiter directement la session authentifiée - ils n'avaient plus besoin de passer par l'application. Il s'est avéré que plusieurs utilisateurs avaient découvert cela et, pensant que c'était le comportement prévu, utilisaient la session de base de données authentifiée de Jane pour exécuter leurs requêtes. Ils ont adoré cette solution, car l'utilisation directe de la connexion leur a donné un accès complet à la base de données, et pas seulement pour les cas clients auxquels ils sont affectés.

La connexion a été supprimée et l'incident est terminé. L'analyste SOC a contacté les utilisateurs qui avaient utilisé la connexion de Jane pour s'assurer qu'ils avaient supprimé toutes les données client qu'ils avaient stockées.

Relever le défi de la sécurité Low-Code/No-Code

L'histoire ci-dessus est un scénario réel d'une entreprise multinationale B2C. Certains détails ont été omis ou ajustés pour protéger la vie privée. Nous avons vu comment un employé bien intentionné pouvait involontairement partager son identité avec d'autres utilisateurs, causant toute une série de problèmes dans l'informatique, la sécurité et l'entreprise. Comme nous l'avons exploré le mois dernier, le partage des informations d'identification est une caractéristique clé du low-code/no-code. C'est la norme, pas l'exception.

As le low-code/no-code continue de fleurir dans l'entreprise, consciemment ou non, il est crucial que les équipes de sécurité et informatiques se joignent à la conversation sur le développement commercial. Les applications low-code/no-code sont livrées avec un ensemble unique de défis de sécurité, et leur nature prolifique signifie que ces défis deviennent aigus plus rapidement que jamais.