Lorsque le RPA est apparu il y a quelques années, beaucoup l’ont présenté comme la solution technologique ultime attendue par les établissements financiers. Ces robots logiciels pouvaient en effet exécuter les tâches les plus banales et les plus répétitives d’une organisation presque instantanément, ce qui permettait non seulement de libérer le personnel pour qu’il se consacre à des tâches créatives ou demandant de la réflexion, mais aussi d’améliorer l’efficacité, la précision, l’agilité et l’évolutivité.
Cependant, le RPA s’accompagne également d’une certaine inquiétude quant à la cession du contrôle ; de la même manière que les équipes de sécurité redoutent la surveillance et la gestion du cloud ou du Shadow IT. De nombreux employés craignaient aussi de perdre leur emploi mais, jusqu’à présent, le RPA a été exploitée pour la récupération, et non pour remplacer, les ressources humaines. Il a au contraire permis aux employés de mettre à profit leur expérience et leurs capacités d’une manière plus stimulante et bénéfique, en prenant en charge des processus plus manuels et chronophages du secteur financier. Il s’agit notamment de l’ouverture des comptes, de la prise en charge des clients, des prêts hypothécaires, de la production des rapports, de la conformité, ou encore de la lutte contre le blanchiment d’argent.
L’évolution du RPA
Dans l’ensemble du secteur financier, les employés ont appréhendé la RPA comme un moyen pour résoudre les problèmes de l’entreprise, mettant ainsi les principes et les pratiques de DevOps à la portée d’une communauté plus large. Le « développeur citoyen » était désormais devenu une réalité : des personnes de toute l’entreprise créaient leurs propres processus automatisés à l’aide de plateformes low-code, voire sans code.
Néanmoins, si les premiers systèmes RPA favorisaient l’automatisation, ils nécessitaient également une supervision humaine. Les applications RPA utilisaient ainsi des bots semi-surveillés qui nécessitaient une intervention humaine pour lancer une tâche, ainsi que la saisie de l’identité numérique de l’utilisateur pour l’accomplir.
Les développeurs citoyens étaient désireux de faire passer l’automatisation à la vitesse supérieure et de qualifier des robots complètement autonomes ; le Saint Graal du RPA. Cependant, cette approche présentait de lourdes implications en matière de sécurité, car les bots sans surveillance doivent avoir accès aux mêmes réseaux, systèmes et applications que leurs homologues humains.
Cela implique souvent l’accès à des systèmes d’entreprise critiques, et donc des privilèges de haut niveau. Or, les identifiants et les identités des robots sont tout aussi exposés que celles d’une personne réelle et, si elles ne sont pas correctement sécurisées, elles permettent aux cybercriminels un moyen supplémentaire de dérober des données et de semer le chaos.
Par conséquent, le recours au recours à des robots sans surveillance a provoqué un désaccord entre les équipes chargées de la sécurité et celles responsables de l’automatisation ; les premières exigeantes des mesures de protection plus fournies et les secondes ayant du mal à les appliquer, soit par manque de connaissances, soit par manque de temps.
Les équipes de cybersécurité peinent ainsi à faire appliquer les pratiques de sécurité définies et leurs recommandations divisent les développeurs citoyens. Certains de ces derniers se sont découragés et résignés à utiliser l’automatisation assistée, ce qui a entraîné l’innovation. D’autres sont allés de l’avant et ont déployé des applications RPA non approuvées, qui ont créé des failles dans la cybersécurité de leur organisation.
Sécuriser l’automatisation sans surveillance
Il est possible d’optimiser la cybersécurité des bots d’une manière qui permette l’utilisation de robots sécurisés et sans surveillance, tout en garantissant la productivité de chacun – des équipes de sécurité comme des utilisateurs RPA. Ainsi, il s’agit de posséder une gestion automatisée et centralisée des identifiants RPA. Plutôt que d’attribuer, de gérer et de mettre à jour manuellement ces derniers, toutes les informations d’identification à privilèges codées en dur sont supprimées des scripts du robot et renvoyées par un appel API renvoyant à des identifiants à rotation automatique intégrés dans un référentiel sécurisé et centralisé.
Cette approche assure une mise en œuvre cohérente des mesures de sécurité telles que la rotation des identifiants, l’authentification multifacteurs (MFA), l’unicité et la complexité des mots de passe et, sous réserve de certains critères, la suspension des privilèges.
Les meilleures pratiques cohérentes également à attribuer aux robots une identité, des identifiants et des droits qui leur sont propres ; afin de garantir un contrôle adéquat de la non-répudiation et de la séparation ou de la ségrégation des tâches, et de limiter l’accès aux applications et aux bases de données dont ils ont besoin pour faire leur travail. Il s’agit finalement d’appliquer le principe du moindre privilège aux robots, tout un utilisateur humain serait limité aux niveaux d’accès minimaux ou aux autorisations minimales dont il a besoin pour s’acquitter de son travail.
Exploiter la puissance de la RPA
Une solution de référentiel centralisé automatisé tout-en-un contribue à éliminer les obstacles traditionnels. Mais pour exploiter le potentiel du développeur citoyen et les avantages ultimes de la RPA, les établissements financiers doivent adopter les DevSecOps et associer l’automatisation et la sécurité dès le départ.
Une collaboration proactive et précoce avec les équipes et les professionnels de la sécurité permettra en effet aux équipes RPA et aux développeurs citoyens de surmonter rapidement ces problèmes et de faire efficacement le nombre de bots RPA dans leur organisation, sans pour autant induire des risques de sécurité ou freiner l’innovation.
