10110010011101001011001101101110101018200.devFrom Enterprise.Systems

Comment auditer les applications OAuth tierces dans Google Workspace

The 8200.dev TeamLecture de 7 min

Demandez à la plupart des administrateurs IT combien d'applications tierces ont accès aux données de leur Google Workspace, et vous obtiendrez une estimation, pas un chiffre. Cette incertitude est le problème. Chaque fois qu'un utilisateur clique sur « Se connecter avec Google » ou installe un module complémentaire depuis le Marketplace, il accorde à une application OAuth une part durable d'accès aux données de l'organisation — et cet accord survit à l'intérêt de l'utilisateur, à la pertinence de l'éditeur, et souvent à la connaissance qu'en a l'administrateur.

Cet article propose une méthode pratique pour auditer ces autorisations : où les trouver, comment juger lesquelles sont risquées, et comment les nettoyer en toute sécurité.

Ce qu'est réellement une autorisation OAuth

Lorsqu'un utilisateur autorise une application « avec Google », il ne transmet pas son mot de passe. Il accorde à l'application un jeton limité à des permissions spécifiques — les *scopes* — qui lui permettent d'appeler les API Google pour le compte de l'utilisateur (ou de l'organisation). Un scope peut être aussi restreint que « voir votre adresse e-mail » ou aussi large que « voir, modifier, créer et supprimer tous vos fichiers Google Drive ».

Deux propriétés justifient d'auditer ces autorisations :

  • Elles persistent. Un jeton continue de fonctionner jusqu'à ce qu'il soit explicitement révoqué, que l'application soit supprimée, ou que le compte soit désactivé. « J'ai arrêté d'utiliser cet outil il y a un an » ne révoque rien.
  • Elles sont initiées par l'utilisateur. L'accès est accordé par la personne qui a cliqué sur « Autoriser », et non provisionné par l'IT. C'est la définition même du shadow IT, et cela signifie que votre inventaire des accès est par défaut incomplet.

Où trouver l'inventaire

Il existe deux points de vue.

La vue utilisateur se trouve dans le compte Google de chaque personne, sous *Sécurité → Applications et services tiers* (anciennement « Applications ayant accès à votre compte »). Elle montre ce qu'un utilisateur a autorisé. Utile pour des vérifications ponctuelles, peu praticable à grande échelle.

La vue administrateur se trouve dans la console d'administration Google, sous *Sécurité → Contrôles des API → Contrôle d'accès des applications* (ainsi que le reporting des applications connectées associé). C'est la vue d'ensemble de l'organisation : quelles applications sont connectées, quels scopes elles détiennent, et combien d'utilisateurs ont autorisé chacune. C'est ici que se déroule l'audit.

Si vous disposez des privilèges d'administrateur appropriés, le reporting des jetons de l'Admin SDK peut recenser les mêmes données de manière programmatique, ce qui permet une revue continue et automatisée plutôt qu'une corvée manuelle annuelle.

Comment évaluer le risque

Toute application connectée n'est pas nécessairement un problème. Un outil de planification de calendrier qui peut lire les disponibilités présente un risque faible ; une application de prise de notes disposant d'un accès complet à Drive et utilisée par une seule personne, c'est une autre histoire. Notez chaque application selon plusieurs dimensions :

  • L'étendue du scope. L'accès complet à Drive, la lecture/envoi Gmail et l'accès à l'annuaire administrateur sont les scopes à fort enjeu. Une application capable de lire et d'exfiltrer chaque fichier est votre priorité absolue, quelle que soit la confiance qu'elle inspire.
  • La sensibilité de ce qu'elle peut atteindre. Le contenu de Drive et l'accès à la messagerie priment sur les métadonnées de profil ou de calendrier.
  • Le nombre d'utilisateurs et son étendue. Une application utilisée par une seule personne mais détenant un accès étendu constitue un risque discret et concentré. Une application utilisée par toute l'entreprise mérite un examen attentif car son rayon d'impact est vaste.
  • La confiance envers l'éditeur. Les éditeurs vérifiés et les fournisseurs reconnus sont des choix plus sûrs que les applications non vérifiées ou anonymes. Le statut de vérification des applications de Google est un signal utile, pas une garantie.
  • L'activité. Une application que personne n'a utilisée depuis des mois ne présente que des inconvénients : tout le risque, aucune valeur.

Une manière simple de combiner ces critères : tout ce qui possède un scope à fort enjeu *et* une faible confiance *ou* aucune utilisation récente passe en tête de la liste de nettoyage.

Un audit reproductible, étape par étape

  1. Recenser. Extraire la liste complète des applications connectées et de leurs scopes depuis la console d'administration (ou via l'API).
  2. Classer les scopes. Signaler les plus dangereux — Drive complet, envoi/lecture Gmail, annuaire, et tout scope administrateur.
  3. Croiser avec l'usage. Identifier les applications sans activité récente et celles détenues par très peu d'utilisateurs.
  4. Vérifier l'éditeur. Noter les éditeurs non vérifiés ou inconnus.
  5. Décider. Pour chaque application : conserver, restreindre ou révoquer. Documenter la raison — le journal des décisions est ce qui accélère le prochain audit.
  6. Révoquer en toute sécurité. Supprimer l'accès des applications que vous avez décidé d'abandonner, et communiquer avec la poignée d'utilisateurs qui dépendaient d'un outil que vous retirez.
  7. Mettre en place des garde-fous. Passer du nettoyage à la prévention : restreindre les installations depuis le Marketplace aux applications approuvées par l'administrateur, et bloquer ou mettre sur liste blanche l'accès aux scopes à haut risque afin que la proliération ne reprenne pas simplement.

Révoquer sans tout casser

La crainte qui freine la plupart des nettoyages est : « et si je révoquais quelque chose dont les gens ont besoin ? ». Pour l'atténuer :

  • Commencez par les décisions évidentes : les applications non vérifiées, aux scopes étendus et sans utilisation récente.
  • Pour les applications à petite base d'utilisateurs, envoyez un avertissement préalable avant de révoquer ; si personne ne s'y oppose, procédez.
  • Conservez une trace de ce que vous avez révoqué et quand, afin de pouvoir restaurer rapidement et délibérément en cas de problème.

La révocation dans les outils Google est immédiate et réversible — un utilisateur peut toujours réautoriser une application dont il a réellement besoin, cette fois avec vos garde-fous en place.

En faire un processus continu

Un audit ponctuel procure une belle satisfaction, mais se dégrade immédiatement. De nouvelles applications sont connectées dès le lendemain de sa fin. La réponse durable est la découverte continue : recenser automatiquement les applications connectées et leurs scopes, noter chacune d'elles, et alerter dès qu'une nouvelle autorisation à haut risque apparaît ou qu'une application dormante détient un accès étendu.

Ce basculement — d'une feuille de calcul périodique à un inventaire toujours à jour — fait toute la différence entre connaître votre exposition OAuth aujourd'hui et la deviner. C'est aussi l'un des piliers d'une sécurité Google Workspace plus large, aux côtés de l'identité, du partage et de la configuration.

Les scopes qui devraient vous faire réfléchir

Puisque l'étendue du scope est le principal facteur de risque, il est utile de savoir quels scopes OAuth pèsent réellement lourd. Quelques schémas à reconnaître en lisant la liste des permissions d'une application :

  • `drive` (Drive complet) — lire, créer, modifier et supprimer *tous* les fichiers Drive d'un utilisateur. C'est le scope de données le plus étendu qu'une application puisse détenir, et il est bien plus répandu qu'il ne devrait l'être ; de nombreuses applications le demandent alors qu'un scope plus restreint, fichier par fichier, suffirait.
  • `gmail.send` / `gmail.modify` / `mail.google.com` — la capacité d'envoyer des e-mails au nom de l'utilisateur, ou de lire et modifier la boîte de messagerie. Une application disposant d'un accès à la messagerie peut à la fois exfiltrer la correspondance et se faire passer pour l'utilisateur auprès d'autres personnes.
  • **admin.directory.*** — lire ou gérer votre annuaire d'utilisateurs et de groupes. Une application détenant ce scope a une portée sur l'ensemble de l'organisation, pas seulement sur un utilisateur.
  • `spreadsheets` / `documents` — accès au contenu de Sheets et Docs, qui contiennent souvent exactement les données sensibles (données financières, plans, identifiants collés « temporairement ») que vous souhaitez le plus protéger.

Les scopes restreints et en lecture seule — userinfo.email, calendar.readonly, drive.file (accès limité aux seuls fichiers créés par l'application elle-même) — sont ceux à encourager. Lorsque vous évaluez un nouvel outil, privilégiez la version qui demande le moins.

Transformer l'audit en politique

Un audit propre a bien plus de valeur s'il aboutit à une politique permanente plutôt qu'à une purge ponctuelle. Trois politiques permettent d'éviter que la prolifération ne reprenne :

  • Installations Marketplace approuvées par l'administrateur. Exiger l'approbation d'un administrateur avant que les utilisateurs puissent installer des applications du Marketplace, afin que chaque nouvelle connexion soit une décision plutôt qu'un défaut.
  • Contrôle d'accès basé sur les scopes. Bloquer ou autoriser explicitement, via liste blanche, les scopes à haut risque (Drive complet, Gmail, annuaire). Une application qui souhaite un accès Drive complet doit franchir un certain seuil ; une application qui ne souhaite qu'une adresse e-mail ne devrait pas avoir à le faire.
  • Un responsable de la revue récurrente. Confier à quelqu'un la mission permanente d'examiner régulièrement les nouvelles autorisations et celles à haut risque. Une revue sans responsable n'a pas lieu.

Ces garde-fous font passer le comportement par défaut de « tout utilisateur peut accorder n'importe quel accès à n'importe quelle application » à « un accès étendu est un choix délibéré et contrôlé » — sans pour autant bloquer les outils légitimes dont les gens ont réellement besoin.

8200.dev découvre les applications tierces connectées à votre Workspace, les note selon leur scope, la confiance envers l'éditeur et leur usage, et fait apparaître en priorité les plus risquées — en lecture seule et en continu. Consultez ce que nous vérifions pour une vue d'ensemble complète.

Envie de savoir quelles applications peuvent accéder à vos données dès maintenant ? Lancez votre audit de sécurité gratuit et obtenez un inventaire des applications OAuth connectées, classées par risque, à travers votre Google Workspace.

PartagerX / TwitterLinkedIn

Articles connexes