Paradoxes du système de vérification et d’évaluation de la sécurité OAuth de Google

Je souhaite partager ici mon expérience sur le système de vérification et d’évaluation de la sécurité OAuth de Google. Pour vous recontextualiser le sujet, depuis début 2019, Google a décidé d’être plus strict sur la validation d’une application Google créée par les entreprises et les indépendants dans le cas où celle-ci accéderait à des données sensibles (e-mails, agendas, etc.).

De ce fait, dès qu’une application nécessite l’accès à des données sensibles, le développeur doit faire auprès de Google une demande de vérification et d’évaluation de la sécurité de celle-ci. Toutefois, cette étape peut être évitée si on opte pour l’option “interne” qui limite l’accès de l’application aux seules données de l’utilisateur ayant installé celle-ci et, dans le cas des organisations utilisant GSuite, à celles des utilisateurs du même domaine.

Ainsi pour le projet qui me concerne, j’ai souhaité mettre à la disposition des utilisateurs qui le souhaitent un microservice que j’ai créé, à titre personnel il y maintenant plus de 8 ans, pour améliorer mon expérience dans l’utilisation de Gmail et de Google Agenda. Ce service est une simple automatisation qui permet de convertir un certain type d’e-mail en événement inscrit dans Google Agenda.

Exemple : À chaque fois que je reçois un e-mail d’erreur, je crée un événement dans un agenda dédié, à l’heure de réception dudit e-mail, et y inscris le contenu de l’e-mail. Autre exemple : Chaque semaine, je reçois un rapport de Google Analytics au format PDF et, pour pouvoir facilement le retrouver parmi les autres rapports, mon microservice l’inscrit dans mon agenda et enregistre automatiquement la pièce jointe dans mon Google Drive accessible depuis mon événement.

Avec le temps, j’ai continué à perfectionner mon service et à l’étendre sur plusieurs typologies d’e-mails, de factures, de notifications, etc. Il y a quelques semaines, j’ai décidé de créer une application Web permettant, à qui le souhaite, de réaliser les mêmes automatisations, afin que cela puisse être utile à chacun.

N’ayant aucun besoin d’informations personnelles pour faire fonctionner l’application, seuls l’ID Google de l’utilisateur et ses permissions qui sont chiffrés et stockés. Ce projet, extrêmement minimaliste, est basé sur 3 tables en base de données (sans accès extérieur) : 1 table de compte (avec l’ID et les permissions), une table listant les tâches configurées par l’utilisateur et une table de log pour chaque exécution de tâche ne contenant que le nombre de messages traités. C’est tout.

J’ai donc pris le temps de créer les interfaces applicatives et de saisir les différents textes pour la vitrine afin d’expliquer au mieux l’utilisation du service. Parallèlement, j’ai trouvé une offre qui me permette de rentrer dans mes frais d’infrastructures (1 € HT / mois ^^).

Après avoir réalisé l’ensemble de ces tâches, j’ai donc mis en ligne le service, avec une application non encore validée par Google mais fonctionnelle. J’ai entamé la démarche auprès de Google pour valider mon application, sachant que, comme il l’est inscrit sur leur interface, cela peut prendre entre 4 et 6 semaines. J’ai néanmoins eu un premier retour dès le lendemain avec une liste assez exhaustive de demandes.

Pour synthétiser un peu ce qui m’a été demandé :

• Suivre le branding de Google concernant le bouton de connexion ;
• Faire une vidéo de l’ensemble du process client pour présenter l’exploitation des permissions demandées ;
• Réaliser une page dédiée à la politique de confidentialité, dans laquelle doivent être détaillés l’ensemble des droits demandés à l’utilisateur et leurs buts ;
• Permettre à l’utilisateur test de Google d’accéder à l’application et de réaliser ses propres tests.

Toutes les demandes ont été réalisées dans les quelques jours qui ont suivi, avec un échange quotidien avec la personne en charge de la validation. Malheureusement, certains tests de l’utilisateur Google n’ayant pu être satisfaits à cause des restrictions appliquées au compte de Google chez eux. L’ensemble des tests n’ont pu être finalisés.

Après quoi, vient l’étape la plus contraignante : l’audit de sécurité réalisé par un partenaire tiers de Google et dont la fourchette de prix varie entre 15 000 $ et 75 000 $. Je vous invite à lire la FAQ concernant ce point : https://support.google.com/cloud/answer/9110914

Vous pensez bien, qu’en tant qu’indépendant, je n’ai pas vraiment les moyens de débourser une somme aussi conséquente pour un audit de sécurité. Je pense d’ailleurs que très peu de personnes et/ou structures peuvent se permettre de payer un tel montant pour un produit qui n’est pas encore commercialisé…

Petit aparté concernant l’audit et les problématiques de celui-ci :

1. Tout d’abord, l’audit étant réalisé à un instant t, cela veut dire que : si le code change (par exemple suite à l’évolution du projet, l’ajout de services ou l’application de correctifs) ou si une nouvelle faille de sécurité est découverte vis-à-vis de l’infrastructure hébergeant l’application, un nouvel audit doit être réalisé. L’audit n’est donc valable qu’au moment où il est fait ce qui est la définition même d’un audit.
2. L’audit de base ne vérifie pas tout. Il va uniquement tester les méthodologies de hacking par brute force et autres méthodologies préétablies. Si vous souhaitez quelque chose de plus complet, il faudra fournir les accès au code source de l’application pour l’analyse de celui-ci. Et donc payer plus cher.

Que faire ? Soit laisser tomber et abandonner ce genre de projets aux seules grosses structures qui peuvent, elles, se permettre de payer un audit de ce prix (et qui, par ailleurs, sauront sûrement quoi faire de vos données et de vos accès ainsi collectés…). Soit contourner le problème en dégradant quelque peu l’expérience utilisateur.

D’un naturel obstiné - ceux qui me connaissent vous le confirmeront -, j’ai donc opté pour la seconde solution et décidé de dégrader un peu l’expérience utilisateur en usant d’un point important précédemment cité. Toute cette partie d’audit et de sécurité n’est valable QUE si l’application est à destination du public. MAIS si l’application est à destination interne (personnelle ou aux utilisateurs du domaine) alors aucune validation n’est nécessaire.

Pour faire une comparaison qui parlera à tout le monde, imaginez les applications Google comme des clés et les données utilisateurs comme des maisons.

Dans le premier cas, le cas idéal si l’application publique était validée, chaque personne qui autorise l’application à accéder à ses informations crée une porte d’entrée munie d’un verrou qui ne peut être ouvert que par la clé dont dispose mon service. Dans le second cas, celui que je me vois contraint de retenir, l’utilisateur va créer une nouvelle porte d’accès à sa maison (ses données) et l’équiper d’un verrou dont il me fournira un double de la clé. Celle-ci sera ajoutée au trousseau de mon service.

On n’arrive donc au même résultat en terme de service mais je suis ici obligé de demander à l’utilisateur de me fournir sa propre application. 

In fine#

La finalité - et donc le paradoxe engendré par tout cela - est que :

• Mon application va devoir stocker plus d’informations “sensibles” de l’utilisateur pour pouvoir accéder à ses informations de l’utilisateur et réaliser sa tâche. L’application sera donc plus à risque.
• Cette démarche sera moins User Friendly, car l’utilisateur doit préalablement créer une application sur sa propre Google Cloud Platform. Cela s’avèrera donc plus fastidieux pour l’utilisateur.
• Cette démarche est moins contrôlée puisqu’il n’y a aucune validation de la part de Google pour l’emploi des API par ses utilisateurs quand il s’agit d’usages “internes”.

Je comprends qu’un minimum de contrôle soit imposé pour tout ce qui touche à l’accès à des données sensibles, c’est la moindre des choses. En cela, la première étape de vérification de Google est pertinente et permet déjà de réaliser un premier tri dans toutes les demandes d’évaluation. En effet, tant que l’application n’est pas finalisée ou que les tests effectués ne justifient pas l’accès à certaines informations sensibles, celle-ci n’est pas validée par Google. Jusque-là je suis d’accord.

Par contre, ce qui est inacceptable et inutile sur le moyen et long terme est d’imposer un contrôle de l’application par un auditeur externe désigné parmi les partenaires de Google pour un montant allant de 15 000 $ à 75 000 $ pour quelques heures seulement de travail . En effet, au début lors du lancement du service, très peu de personnes utiliseront cette nouvelle application et cela demandera plusieurs mois pour qu’elle se fasse connaître. Je vous assure qu’entre-temps, l’application devra s’adapter aux utilisateurs et à leurs demandes et que parallèlement l’infrastructure nécessaire à son bon fonctionnement grossira. De ce fait, l’audit réalisé au tout début n’aura pas une réelle valeur alors qu’il serait plus utile à terme lorsqu’il y aura plus d’utilisateurs.

Tout ceci est un frein à toute personne, tout développeur souhaitant proposer des microservices.