Dans l’environnement SaaS actuel, en évolution rapide, l’accent est mis sur les utilisateurs humains. Il s’agit de l’un des domaines les plus compromis de la gestion de la sécurité SaaS et nécessite une gouvernance stricte des rôles et autorisations des utilisateurs, la surveillance des utilisateurs privilégiés, leur niveau d’activité (dormant, actif, hyperactif), leur type (interne/externe), s’ils sont les nouveaux arrivants, les déménageurs ou les sortants, et plus encore.
Il n’est pas surprenant que les efforts de sécurité aient été principalement centrés sur l’humain. Les options de configuration incluent des outils tels que MFA et SSO pour l’authentification humaine. Le contrôle d’accès basé sur les rôles (RBAC) limite le niveau d’accès ; Les directives relatives à la complexité des mots de passe empêchent les personnes non autorisées d’accéder à l’application.
Pourtant, dans le monde du SaaS, les accès accordés aux acteurs non humains, ou en d’autres termes, aux applications connectées tierces, ne manquent pas.
Les comptes de service, les autorisations OAuth et les clés API ne sont que quelques-unes des identités non humaines qui nécessitent un accès SaaS. Vus à travers le prisme de l’application, les comptes non humains sont similaires aux comptes humains. Ils doivent être authentifiés, dotés d’un ensemble d’autorisations et surveillés. Cependant, comme ils ne sont pas humains, on se préoccupe beaucoup moins de leur sécurité.
Exemples d’accès non humain
Les intégrations sont probablement le moyen le plus simple de comprendre l’accès non humain à une application SaaS. Calendly est une application qui élimine les échanges d’e-mails liés à la prise de rendez-vous en affichant la disponibilité d’un utilisateur. Il s’intègre au calendrier d’un utilisateur, lit le calendrier pour déterminer la disponibilité et ajoute automatiquement des rendez-vous. Lors de l’intégration à Google Workspace via une autorisation OAuth, il demande des étendues qui lui permettent d’afficher, de modifier, de partager et de supprimer des agendas Google, entre autres étendues. L’intégration est initiée par un humain, mais Calendly n’est pas humain.
 |
| Figure 1 : Étendues d’autorisation requises par Calendly |
D’autres comptes non humains impliquent le partage de données entre deux ou plusieurs applications. SwiftPOS est une application et un appareil de point de vente (POS) pour les bars, les restaurants et les points de vente. Les données capturées par le point de vente sont transférées vers une plateforme de business intelligence, comme Microsoft Power BI, où elles sont traitées et analysées. Les données sont transférées de SwiftPOS vers Power BI via un compte non humain.
Le défi de la sécurisation des comptes non humains
Gérer et sécuriser les comptes non humains n’est pas aussi simple qu’il y paraît. Pour commencer, chaque application a sa propre approche pour gérer ces types de comptes d’utilisateurs. Certaines applications, par exemple, déconnectent une intégration OAuth lorsque l’utilisateur qui l’a autorisée est déprovisionné de l’application, tandis que d’autres maintiennent la connexion.
Les applications SaaS adoptent également différentes approches pour gérer ces comptes. Certains incluent des comptes non humains dans leur inventaire des utilisateurstandis que d’autres stockent et affichent les données dans une section différente de l’application, ce qui les rend faciles à ignorer.
Les comptes humains peuvent être authentifiés via MFA ou SSO. En revanche, les comptes non humains sont authentifiés une seule fois et oubliés, sauf en cas de problème d’intégration. Les humains ont également des comportements typiques, comme se connecter à des applications pendant les heures de travail. Les comptes non humains accèdent souvent aux applications pendant les heures creuses afin de réduire le trafic et la pression réseau. Lorsqu’un humain se connecte à son SaaS à 3 heures du matin, cela peut déclencher une enquête ; lorsqu’un non-humain arrive sur le réseau à 3 heures du matin, c’est tout simplement comme d’habitude.
Dans le but de simplifier la gestion des comptes non humains, de nombreuses organisations utilisent la même clé API pour toutes les intégrations. Pour faciliter cela, ils accordent de larges ensembles d’autorisations à la clé API pour couvrir tous les besoins potentiels de l’organisation. D’autres fois, un développeur utilisera sa propre clé API à autorisation élevée pour accorder l’accès au compte non humain, lui permettant ainsi d’accéder à tout ce qui se trouve dans l’application. Ces clés API fonctionnent comme des laissez-passer d’accès complet utilisés par plusieurs intégrations, ce qui les rend incroyablement difficiles à contrôler.
 |
| Figure 2 : Une application OAuth malveillante détectée via le SSPM d’Adaptive Shield |
Le risque que les comptes non humains ajoutent à la pile SaaS
Les comptes non humains ne sont en grande partie pas surveillés et disposent de vastes étendues d’autorisation. Cela en fait une cible attrayante pour les acteurs malveillants. En compromettant l’un de ces comptes, les acteurs malveillants peuvent accéder à l’application sans être détectés, entraînant des violations, des modifications non autorisées ou des interruptions de service.
Prendre des mesures pour sécuriser les comptes non humains
En utilisant une plateforme SaaS Security Posture Management (SSPM) de concert avec des solutions Identity Threat Detection & Response (ITDR), les organisations peuvent gérer efficacement leurs comptes non humains et détecter lorsqu’ils se comportent de manière anormale.
Les comptes non humains nécessitent la même visibilité de la part des équipes de sécurité que les comptes humains et doivent être gérés dans le même inventaire d’utilisateurs que leurs homologues humains. En unifiant la gestion des identités, il est beaucoup plus facile de visualiser les accès et les autorisations et de mettre à jour les comptes, quel que soit le propriétaire. Il garantit également une approche unifiée de la gestion des comptes. Les politiques organisationnelles, telles que l’interdiction du partage de comptes, doivent être appliquées à tous les niveaux. Les comptes non humains doivent être limités à des adresses IP spécifiques pré-approuvées sur une liste verte et ne doivent pas avoir accès via les écrans de connexion standard (connexion à l’interface utilisateur). En outre, les autorisations doivent être adaptées pour répondre à leurs besoins spécifiques en tant qu’applications, et ne pas être vastes ou correspondre à leurs homologues humaines.
L’ITDR joue également un rôle important. Les comptes non humains peuvent accéder aux applications SaaS à toute heure de la nuit, mais leurs interactions sont généralement assez cohérentes. ITDR peut détecter des anomalies de comportement, qu’il s’agisse de changements de calendrier, du type de données ajoutées à l’application ou des activités effectuées par le compte non humain.
La visibilité fournie par SSPM sur les comptes et ITDR sur les comportements d’identité non humaine est essentielle pour gérer les risques et identifier les menaces. Il s’agit d’une activité essentielle pour maintenir des applications SaaS sécurisées.
En savoir plus sur la protection contre les identités non humaines
