3 façons dont les développeurs sans code peuvent se tirer une balle dans le pied

Il fut un temps où les organisations peu enclines au risque pouvaient limiter considérablement la capacité de leurs utilisateurs professionnels à commettre des erreurs coûteuses. Avec un savoir-faire technique limité, des autorisations strictes et un manque de vent arrière, la pire chose qu'un utilisateur professionnel puisse faire était de télécharger des logiciels malveillants ou de tomber dans le piège d'une campagne de phishing. Ces jours sont maintenant révolus.

De nos jours, toutes les principales plates-formes logicielles en tant que service (SaaS) sont fournies avec des capacités d'automatisation et de création d'applications conçues et commercialisées directement auprès des utilisateurs professionnels. Les plates-formes SaaS telles que Microsoft 365, Salesforce et ServiceNow intègrent plates-formes no-code/low-code dans leurs offres existantes, les plaçant directement entre les mains des utilisateurs professionnels sans demander l'approbation de l'entreprise. Les fonctionnalités qui n'étaient autrefois disponibles que pour les équipes informatiques et de développement sont désormais disponibles dans toute l'organisation.

Power Platform, la plate-forme low-code de Microsoft, est intégrée à Office 365 et en est un excellent exemple en raison de la forte présence de Microsoft dans l'entreprise et de la vitesse à laquelle elle est adoptée par les utilisateurs professionnels. Peut-être sans s'en rendre compte, les entreprises placent le pouvoir au niveau des développeurs entre les mains de plus de personnes que jamais auparavant, avec beaucoup moins de sécurité ou de connaissances techniques. Qu'est ce qui pourrait aller mal?

Beaucoup, en fait. Examinons quelques exemples concrets tirés de mon expérience. Les informations ont été rendues anonymes et les processus spécifiques à l'entreprise ont été omis.

Situation 1 : Nouveau fournisseur ? Fais-le c'est tout

L'équipe du service client d'une entreprise multinationale de vente au détail souhaitait enrichir ses données clients avec des informations sur les consommateurs. En particulier, ils espéraient trouver plus d'informations sur les nouveaux clients afin de mieux les servir, même lors de leur achat initial. L'équipe du service client a choisi un fournisseur avec lequel elle aimerait travailler. Le fournisseur exigeait que des données lui soient envoyées pour enrichissement, qui seraient ensuite récupérées par leurs services.

Normalement, c'est là que l'informatique entre en scène. Le service informatique aurait besoin de créer une sorte d'intégration pour obtenir des données vers et depuis le fournisseur. L'équipe de sécurité informatique devrait évidemment être également impliquée pour s'assurer que ce fournisseur peut se fier aux données client et approuver l'achat. Les achats et le juridique auraient également joué un rôle clé. Dans ce cas, cependant, les choses sont allées dans une autre direction.

Cette équipe de service client particulière était composée d'experts Microsoft Power Platform. Au lieu d'attendre les ressources ou l'approbation, ils sont simplement allés de l'avant et ont construit l'intégration eux-mêmes : en collectant les données des clients à partir des serveurs SQL en production, en les transmettant à un serveur FTP fourni par le fournisseur et en récupérant les données enrichies du serveur FTP vers la base de données de fabrication. L'ensemble du processus était exécuté automatiquement chaque fois qu'un nouveau client était ajouté à la base de données. Tout cela a été fait via des interfaces glisser-déposer, hébergées sur Office 365, et en utilisant leurs comptes personnels. La licence a été payée de sa poche, ce qui a tenu l'approvisionnement hors de la boucle.

Imaginez la surprise du RSSI lorsqu'il a découvert un ensemble d'automatisations commerciales transférant les données des clients vers une adresse IP codée en dur sur AWS. Étant un client Azure uniquement, cela a déclenché un drapeau rouge géant. De plus, les données étaient envoyées et reçues avec une connexion FTP non sécurisée, créant un risque de sécurité et de conformité. Lorsque l'équipe de sécurité l'a découvert grâce à un outil de sécurité dédié, les données entraient et sortaient de l'organisation depuis près d'un an.

Situation 2 : Ohh, est-ce mal de collecter des cartes de crédit ?

L'équipe RH d'un grand fournisseur informatique se préparait pour une campagne annuelle "Give Away", où les employés sont encouragés à faire un don à leur organisme de bienfaisance préféré, l'entreprise participant en égalant chaque dollar donné par les employés. La campagne de l'année précédente a été un énorme succès, de sorte que les attentes explosaient. Pour alimenter la campagne et alléger les processus manuels, un employé créatif des RH a utilisé la Power Platform de Microsoft pour créer une application qui a facilité l'ensemble du processus. Pour s'inscrire, un employé se connecterait à l'application avec son compte d'entreprise, soumettrait le montant de son don, sélectionnerait un organisme de bienfaisance et fournirait les détails de sa carte de crédit pour le paiement.

La campagne a été un énorme succès, avec une participation record des employés et peu de travail manuel requis de la part des employés des RH. Pour une raison quelconque, cependant, l'équipe de sécurité n'était pas satisfaite de la façon dont les choses se sont déroulées. En s'inscrivant à la campagne, un employé de l'équipe de sécurité s'est rendu compte que les cartes de crédit étaient collectées dans une application qui ne semblait pas devoir le faire. Après enquête, ils ont constaté que ces détails de carte de crédit étaient en effet mal traités. Les détails de la carte de crédit étaient stockés dans l'environnement Power Platform par défaut, ce qui signifie qu'ils étaient disponibles pour l'ensemble du locataire Azure AD, y compris tous les employés, fournisseurs et sous-traitants. De plus, ils étaient stockés sous forme de simples champs de chaîne de texte en clair.

Heureusement, la violation du traitement des données a été découverte par l'équipe de sécurité avant que des acteurs malveillants - ou des auditeurs de conformité - ne la repèrent. La base de données a été nettoyée et l'application a été corrigée pour gérer correctement les informations financières conformément à la réglementation.

Situation 3 : Pourquoi ne puis-je pas simplement utiliser Gmail ?

En tant qu'utilisateur, personne n'aime les contrôles de prévention des pertes de données d'entreprise. Même lorsque cela est nécessaire, ils introduisent des frictions gênantes dans les opérations quotidiennes. Du coup, les utilisateurs ont toujours essayé de les contourner. Un bras de fer permanent entre les utilisateurs professionnels créatifs et l'équipe de sécurité est le courrier électronique d'entreprise. Synchroniser les e-mails d'entreprise avec un compte de messagerie personnel ou le calendrier d'entreprise avec un calendrier personnel : les équipes de sécurité ont une solution pour cela. À savoir, ils ont mis en place des solutions de sécurité des e-mails et de DLP pour bloquer le transfert d'e-mails et assurer la gouvernance des données. Cela résout le problème, non ?

Et bien non. Un constat répété dans les grandes et les petites entreprises constate que les utilisateurs créent des automatisations qui contournent les contrôles de messagerie pour transférer leur messagerie et leur calendrier d'entreprise vers leurs comptes personnels. Au lieu de transférer des e-mails, ils copient et collent des données d'un service à un autre. En se connectant à chaque service avec une identité distincte et en automatisant le processus de copier-coller sans code, les utilisateurs professionnels contournent facilement les contrôles de sécurité - et sans aucun moyen facile pour les équipes de sécurité de le découvrir.

La communauté Power Platform a même développé modèles que tout utilisateur d'Office 365 peut récupérer et utiliser.

Un grand pouvoir implique de grandes responsabilités

L'autonomisation des utilisateurs professionnels est excellente. Les métiers ne doivent pas attendre l'informatique ni se battre pour les ressources de développement. Cependant, nous ne pouvons pas simplement donner aux utilisateurs professionnels un pouvoir de niveau développeur sans conseils ni garde-fous et nous attendre à ce que tout aille bien.

Les équipes de sécurité doivent éduquer les utilisateurs professionnels et les sensibiliser à leurs nouvelles responsabilités en tant que développeurs d'applications, même si ces applications ont été créées "sans code". Les équipes de sécurité doivent également mettre en place des garde-corps et une surveillance pour s'assurer que lorsque les utilisateurs professionnels commettent une erreur, comme nous le faisons tous, cela ne fera pas boule de neige en fuites de données à grande échelle ou en incidents d'audit de conformité.