Le Google Sign-in : la productivité du quotidien

‍‍

Se connecter à une application via son compte Google fait partie des petits gains de productivité du quotidien, qui facilitent l’utilisation de nos apps préférées, en évitant la fastidieuse création de compte avec un mot de passe.

‍

‍

Vous connaissez cet écran : le problème, c’est que dans la majorité des cas, on clique les yeux fermés sur “Autoriser”, sans même lire le contenu.

Ce contenu, c’est la liste des permissions octroyées à une application, sur notre compte Google. Il y en a plus de 200 pour un compte Google, mais on trouve pêle-mêle, la possibilité de :

• Supprimer des fichiers dans Google Drive
• Envoyer des e-mails à la place de l’utilisateur
• Accéder au contenu du calendrier
• …

‍

Un défi majeur à l’échelle de l’entreprise

‍

Très concrètement l’octroi de ces permissions signifie que l’application peut accéder aux données de votre compte Google ; lorsqu’il s’agit d’un compte professionnel, l’application peut donc accéder à des données de l’entreprise.

Chaque application connectée constitue une potentielle porte d’entrée vers vos données ; leur utilisation pose un enjeu de sécurité majeur pour les équipes IT.

‍

Il est difficile d’obtenir des chiffres sur l’utilisation des applications tierces via Google Sign-in. Nous avons échangé avec 30 équipes IT d’entreprises entre 60 et 400 personnes, et voici les tendances qui ressortent.

• En moyenne, 45 apps sont installées par employé
• 10% d’entre elles avec des permissions sensibles, c’est-à-dire de la lecture sur des données potentiellement confidentielles, ou des droits d’écriture
• 80% d’apps n’ont pas été utilisées depuis 3 mois ou plus par le collaborateur.

‍

Un risque qui explose avec l’interconnexion des SaaS

‍

Les écosystèmes SaaS devenant de plus en plus interconnectés, la surface du risque lié aux applications tierces explose : si scanner des fichiers à la recherche de virus est maintenant rentré dans notre quotidien, un futur pas si lointain nous verra scanner nos applications tierces à la recherche d’applications malveillantes.

‍

‍

Les applications tierces compromises

Bien qu’il ne soit pas lié directement à un Google Sign-in, il nous paraît impossible de ne pas illustrer le risque de supply chain attack avec l’exemple de Github.

Lorsqu’on connecte une app à une autre, la permission de lire les données se matérialise par l’échange de tokens 0Auth. En avril 2022, deux applications connectées à Github - Heroku et Travis CI - ont été compromises, et certains tokens qui leur avaient été accordés ont été volés. Les hackers ont pu les utiliser pour accéder aux repos des victimes, et voler leurs données.

Autoriser l’accès à des applications tierces à un compte Google, c’est étendre notre surface de risque, et devenir vulnérable à la compromission de ces fournisseurs.

Les applications tierces malveillantes

Dans d’autres cas, les applications connectées sont carrément malveillantes. On parle dans ce cas là de “phishing consenti” : c’est-à-dire que l’utilisateur est incité à accepter les permissions de cette application frauduleuse, et le hacker n’a pas besoin d’obtenir le mot de passe du compte de l’utilisateur - comme dans le cas du phishing - pour accéder à ses données.

C’est ici un bref aperçu des risques liés aux applications tierces (qui feront l’objet d’un article plus détaillé) mais celles-ci occasionnent de plus en plus d’attaque, à mesure que l’utilisation des applications SaaS explose.

‍

Un risque difficile à mesurer

‍

‍

L’utilisation des apps au sein d’une organisation est massive, évolutive et diffuse. Ce risque est difficile à surveiller avec le panel admin Google Workspace. La console admin est très difficile d’accès, mais surtout elle ne permet d’obtenir du risque qu’une vision limitée, peu granulaire. Elle présente 2 problèmes majeurs :

Problème #1 : Pas de mise en relief en fonction des permissions

La vertu du panel admin est de présenter un indicateur pour savoir si l’application a été vérifiée par Google ou non ; cet indicateur est par contre peu clair, et donc peu actionnable, car il n’est pas possible de fonder son analyse uniquement sur cette base.

Les applications sont présentées de manière uniforme, et manque de granularité au niveau des permissions accordées. Il est possible de savoir quel service est visé (Drive, Calendar…) mais il n’y a pas de segmentation en fonction de la criticité du scope : par exemple toutes les permissions en écriture (suppression de fichier, d’invitations calendriers etc.).

Pour ce faire, une revue application par application est nécessaire, ce qui s’avère très fastidieux.

Problème #2 : Peu d’indicateurs actionnables sur l’utilisation de l’application

Au-delà du nombre d’utilisateurs concernés, il est difficile d’avoir une vision consolidée sur le degré d’utilisation de ces applications au quotidien par les utilisateurs. Difficile notamment de savoir quelles sont les apps inutilisées, dont l’octroi des permissions n’a plus lieu d’être.

De la même manière, aucune possibilité de savoir via la console admin dans quel cadre les applications sont utilisées : Google ne peut renseigner sur le contexte de leur utilisation, et savoir si elles sont nécessaires à l’activité des utilisateurs.

Enfin, si vous parvenez à conduire une analyse fine sur l’utilisation de ces apps au sein de votre organisation, celle-ci ne sera valable qu’à l’instant T ; cette vision est déjà quasi obsolète, étant donné la vitesse d’ajout de nouvelles applications.

‍

Un risque difficile à traiter

‍

Si le risque est difficile à appréhender, il est encore plus dur de le résoudre efficacement. La seule solution à la main des équipes IT est souvent de réaliser un travail manuel, chronophage et à l’efficacité limitée.

‍

‍

Pour traiter le risque lié aux applications tierces à l’échelle de l’organisation, de nombreux défis se pose aux équipes IT :

Défi #1 : Préserver la productivité et la liberté des utilisateurs

Une option retenue par certaines organisations est de bannir purement et simplement l’utilisation du Google Sign-in, et de ne l’accepter que sur demande.

Au-delà de créer un climat de défiance, avec une approche culturelle peu compatible avec les principes du future of work, cette option n’est pas la plus efficace : elle pèse sur la productivité des utilisateurs, comme sur celles des équipes IT, avec une charge de revue des demandes très lourde.

Défi #2 : Résoudre le problème à grande échelle

La deuxième option, la plus retenue, est de traiter le problème manuellement, en demandant aux collaborateurs, sur une base régulière, de revoir les accès depuis leur console Google, et de faire le tri dans leurs apps.

Le problème de cette option est qu’elle difficilement mesurable, peu efficace et forcément sporadique.

Défi #3 : Eduquer les utilisateurs sur le risque, sans les stigmatiser

Cette option pose également un autre problème : ce que recouvre vraiment les permissions est très opaque, et les collaborateurs doivent être sensibilisés sur ceux à quoi ils ont donné accès. Un tel travail est chronophage, et relève plus de la conduite du changement que de l’IT.

Enfin, certaines équipes IT sont réticentes à l’idée de notifier individuellement les employés, car ceux-ci le ressentent parfois comme une intrusion, voire une stigmatisation.

‍

Comment traiter ce risque ?

‍

Trop souvent, face à l’ampleur de ces défis, la décision est de ne pas traiter le risque ; voici comment elba peut vous aider à maîtriser le risque lié aux applications tierces.

Restreindre la surface du risque potentiel

Le pire ennemi des équipes IT est le trop plein d’alertes, avec son lot de faux positifs. Alors que votre panel Google Admin remonte l’ensemble des apps connectées de manière très plate, elba vous permet de mettre ce risque en perspective.

Connectez votre compte Google administrateur, et elba vous fournit l’ensemble des applications à risque - c’est-à-dire avec des permissions sensibles telles que le droit d’écriture ou de lecture sur des données sensibles - et son taux d’utilisation au sein de l’organisation.

Les applications recommandées en interne, ou validées par les équipes IT, pourront être whitelistées : c’est-à-dire qu’elles n’engendreront pas des alertes de sécurité.

‍

‍

Responsabiliser les utilisateurs, et capitaliser sur leur connaissance métier

L’ambition d’elba est de renverser une logique top down, qui voudrait que tout traitement des alertes de sécurité soit décidé par les équipes IT. Dès qu’une application à risque est détectée pour un utilisateur, il sera notifié par elba, et invité à traiter l’alerte.

L’utilisateur est responsabilisé, et elba lui permet de prendre une décision éclairée : toutes les permissions sensibles sont expliquées de manière claire et compréhensible, en toute transparence. Seul l’utilisateur peut savoir si cette app est nécessaire à son travail ou s’il ne l’utilise que très peu, ou pas.

En un clic, depuis elba, il peut choisir de révoquer les permissions ou de faire confiance à l’application.

Automatiser la revue des applications à risque

Le traitement du risque automatisé et décentralisé permet aux équipes IT de contrôler le risque lié aux applications tierces à moindre effort : il est plus facile pour un utilisateur de traiter entre 3 à 5 apps, que pour une équipe IT d’en traiter des centaines.

L’automatisation proposée par elba permet également de réaliser une surveillance continue, avec donc un niveau de sécurité plus élevé.

‍

‍

Conclusion

‍

Le risque lié aux applications tierces est parfois méconnu, car moins intelligible que le risque lié au phishing par exemple, il n’en présente pas moins un enjeu crucial pour la sécurité des organisations.

Le risque lié au Google Sign-in est particulièrement crucial, car Google Workspace héberge la majorité des données de l’entreprise, que ce soit via Gmail ou Google Drive. Grâce à une approche automatisée et centrée sur l’employé, éleva pourra vous aider à le traiter à l’échelle de votre organisation, sans nécessiter une équipe de sécurité dédiée.

‍