Certaines technologies semblent de prime abord être de simples évolutions lorsqu’elles sont en réalité de véritables révolutions.
Les environnements de développement Low Code/No Code sont des solutions qui permettent de créer des applications avec peu ou pas de connaissances en langages de programmation traditionnels. Elles donnent la possibilité de construire un processus de programmation en manipulant des blocs de construction prédéfinis dans une interface graphique utilisant le moins de code possible.
Il est peut-être un peu trop tôt pour qualifier le Low Code/No Code de révolution, mais il semblerait quand même que ce soit bien le cas. Ce nouveau pas dans l’abstraction de l’environnement de développement (similaire à la manière dont le langage C a abrégé le code assembleur brut) pourrait entraîner de réelles avancées car il offre aux non-codeurs la possibilité de développer leurs propres applications, grâce à une interface qui les invite à décrire/dessiner le processus voulu, au lieu de le coder directement.
Bien entendu, le modèle Low Code/No Code ne vise pas à être uniquement utilisé par les équipes business novices du code, les équipes DevOps et, plus largement, tous les développeurs professionnels peuvent également utiliser ce modèle pour accélérer le développement et compenser le manque constant de ressources en développeurs. Cependant, il est clair que les équipes business peuvent voir dans l’usage de ce modèle une opportunité majeure de créer, de manière autonome, des applications qui répondront à leurs besoins sans aucun codage direct et avec un délai de mise sur le marché très court.
Mais n’existe-t-il pas un risque à utiliser le low code no code ?
Sans une implication claire du DSI et du RSSI, l’usage d’un tel modèle par des équipes peu formées et spécialisées peut représenter une faille dans le système de sécurité des entreprises. Ces équipes novices peuvent déjà bénéficier d’applications SaaS, et elles peuvent désormais créer leurs propres applications. Par conséquent, les entreprises ont tout intérêt à ce que les équipes IT ne bloquent pas cette adoption, mais que cette dernière soit bien encadrée.
Une possibilité pour améliorer la protection est de fournir un catalogue de services permettant d’héberger ces applications dans un cloud public ou privé, et d’y attribuer un niveau de sécurité adéquat.
En qualité de professionnels de la sécurité, nous devons anticiper ces nouveaux cas d’usage, nous préparer à l’avance aux risques qu’ils impliquent et reconnaître que, de toute évidence, l’ancienne façon de penser, qui consistait à interdire les nouvelles technologies comme celles-ci parce qu’elles introduisaient de nouveaux risques, n’est plus d’actualité.
Les critères de décision
Pour ce qui est de l’usage du Low Code/No Code, les RSSI devraient rapidement définir leurs critères de décision. Les données produites, les données consommées dans les systèmes d’information, les données stockées par l’application elle-même, les méthodes d’accès et les autorisations sont autant d’éléments qui leur permettront de valider un projet, de déterminer où héberger l’application et de déceler les mesures de sécurité nécessaires.
Réduire la surface d’attaque
Certaines solutions Low Code/No Code sont liées à de grandes plates-formes telles que des solutions ERP, CRM ou de collaboration et, dans ce cas, les applications publiées s’apparentent davantage à des modules complémentaires, des plugins et à des applications SaaS complémentaires. Par ailleurs, d’autres solutions sont totalement indépendantes et fournissent une application complète qui doit généralement être hébergée dans Kubernetes ou un environnement similaire.
Le contrôle du code final de l’application étant insuffisant, il serait très important de se concentrer sur la validation de la conformité de l’environnement complet de l’application et de la politique de sécurité de l’organisation. L’usage de CSPM (Cloud Posture Management) permet de valider en permanence les environnements de cloud privé ou public utilisés par ces applications et de réaliser automatiquement changements opératoires si nécessaire y compris au niveau du réseau, des droits, des images de conteneurs et d’autres aspects encore.
Modèle de responsabilité partagée
Avec l’introduction des applications Low Code/No Code, le modèle de responsabilité partagée existant entre les fournisseurs de services en cloud et les clients est considérablement élargi avec l’ajout au centre du fournisseur Low Code/No Code. En effet, cette solution d’abstraction produit des applications qui pourraient contenir des vulnérabilités techniques (injection SQL, par exemple), mais nous ne pouvons pas tenir le producteur/client de l’application responsable, car il n’a fourni qu’un schéma du processus.
Dans tous les cas, il faut tenir compte du fait qu’un tel mécanisme d’abstraction est susceptible de créer des vulnérabilités, et que lorsqu’elles sont découvertes, il faudra du temps pour les résoudre : d’abord, parce que vous n’avez pas la main mise sur le code final, et ensuite parce que le fournisseur de Low Code/No Code doit corriger le code qui a produit le code défectueux, une tâche nettement plus difficile.
Pour surmonter cette situation de risque plus élevé, il convient de protéger ce type d’application à l’aide d’une solution de protection des applications Web qui doit inclure un mécanisme d’apprentissage automatique, car l’entreprise aura souvent le cycle de vie en main, et parce que les phases de développement seront très rapides.
En résumé, plutôt que de bloquer des applications susceptibles d’apporter de la valeur à l’organisation, il convient de se préparer à mettre en place des garde-fous et à les héberger en toute sécurité, puisque les nouvelles solutions sont là et qu’elles ne représentent rien de moins qu’une véritable… révolution.
