RPA : la sécurité passe par le contrôle d’accès et l’intégration de systèmes
L'automatisation robotisée des processus peut révolutionner les workflows d'entreprise. Mais si les risques de sécurité associés ne sont pas maîtrisés, les robots pourraient finir par faire plus de mal que de bien.
L'automatisation robotisée des processus (RPA) implique l'utilisation de robots, de l'apprentissage automatique et de l'intelligence artificielle pour interagir avec les processus métiers. La RPA peut permettre d’automatiser de nombreux processus manuels chronophages et optimiser les workflows d'entreprise. Mais il n’en faut pas moins tenir compte des problèmes de sécurité liés aux utilisateurs humains – ce sont eux qui supervisent le logiciel, après tout – ainsi que ceux qui sont spécifiques aux bots. En l'absence de contrôles de sécurité efficaces, les projets de RPA pourraient bien s’avérer plus préjudiciables que bénéfiques.
Des utilisateurs pilotent des bots qui agissent comme des utilisateurs
Sommairement, la RPA conduit au remplacement d’humains par des bots. Mais les utilisateurs ont toujours besoin de travailler avec ceux-ci pour planifier, exécuter, visualiser et modifier leurs processus. Pour que cela soit fait en toute sécurité, les administrateurs doivent être en mesure de spécifier qui fait quoi – le contrôle d'accès est encore et toujours essentiel, que ce soit pour les bots ou pour les utilisateurs humains.
Et cela va plus loin : le sujet ne se limite pas à quoi peut faire quoi, mais quand, dans la semaine ou dans la journée. Certains éditeurs parlent de contrôle d’accès basé sur les rôles. Peu importe le nom que l’on donne à l’approche ; tout système de RPA doit l’intégrer d’une manière ou d’une autre. Il s’agit d’observer le niveau de granularité avec lequel il est possible de définir les permissions. Et plus il est élevé, plus il sera possible de contrôler finement ce que qui ou quoi peut faire.
Pour les applications, un bot n'est pas différent d’un utilisateur humain qui doit s'authentifier. Il s’agit donc de savoir où sont stockés ces identifiants lorsqu’ils ne sont pas utilisés par le bot, et comment ils sont protégés : le coffre-fort de stockage est-il chiffré ? Qui en tient les clés ? Et il convient également de savoir comment sont stockés les identifiants lorsque le bot les utilise. Par exemple, s’ils sont conservés en mémoire vive, en clair, ils sont susceptibles d’être compromis par un tiers.
Des éléments spécifiques aux bots
Le bot, qui n’est en fait qu’un programme applicatif en lui-même, s’inscrit dans le cadre d’un processus métier. Ce qui fait de lui un actif de la propriété intellectuelle de l’entreprise qui l’utilise. Il est important que le code du bot soit protégé contre la copie non autorisée. D’où l’importance de demander aux éditeurs envisagés s’ils supportent le masquage de code d’exécution, afin d’éviter qu’il ne soit collecté dans la mémoire vive du système en cours de fonctionnement du bot.
Parce que les robots imitent les utilisateurs, ils peuvent interagir avec les applications en utilisant virtuellement saisies clavier et actions de souris. Une personne non autorisée, ayant un accès physique à l'ordinateur exécutant un bot, pourrait être en mesure de modifier les données ou de modifier le traitement du bot en intervenant à travers des périphériques physiquement présents. Dans l’idéal, la plateforme de RPA doit intégrer les capacités nécessaires au blocage de telles interactions lorsque le bot d’exécute.
Certains éditeurs vont un peu plus loin en proposant un mode d’exécution furtif. Dans ce mode, l'exécution du bot est cachée à quiconque regarde l'écran du PC. Bien sûr, ce n’est pas une option souhaitable lors du débogage d'un bot, mais elle peut être pratique en production.
Intégration avec les autres contrôles de sécurité
Mais il n’est pas possible de traiter la sécurité des bots hors de la stratégie globale de sécurité informatique de l’entreprise. L’intégration est indispensable, à commencer par la remontée des traces d’activité de la plateforme de RPA dans les systèmes de gestion de logs ou d’informations et d’événements de sécurité (SIEM). Les entreprises qui utilisent des systèmes d’authentification unique (SSO) peuvent en outre vouloir s’assurer que la plateforme de RPA supporte des intégrations SAML.
La sécurité du RPA présente de nombreuses facettes. L’importance que l’on accorde à chacune d’entre elles dépend bien sûr des entreprises, de leur stratégie de sécurité. Mais justement, il convient de s’assurer de choisir une plateforme qui réponde aux exigences liées à cette stratégie.
