Get best of the week

Comment avons-nous vérifié la sécurité de Google

Pour garantir la sécurité des données utilisateur, Google vérifie soigneusement toutes les applications qui utilisent des étendues d'API restreintes et ont accès aux données utilisateur Google. Il n'y a pas si longtemps, chez Snov.io, nous avons suivi le processus de vérification et reçu l'approbation de Google, avec laquelle nous voulons partager.

Nouvelles règles pour les applications


Le 9 octobre 2018, Google a annoncé de nouvelles règles pour les applications qui utilisent les étendues d'API restreintes de Google. Ils comprenaient 2 étapes de vérification:

  • Vérifiez que votre application est conforme à la politique relative aux données utilisateur de l'API Google
  • Vérifier les exigences de sécurité minimales

La vérification de l'application à portée restreinte vérifie la conformité avec la politique de données utilisateur de l'API Google et un ensemble supplémentaire de politiques décrites dans Exigences supplémentaires pour des étendues d'API spécifiques. Tout d'abord, votre application sera examinée afin de vérifier sa conformité aux services API de Google: politique de données utilisateur. Par la suite, vous aurez le reste de 2019 pour démontrer la conformité aux exigences de manipulation sécurisée.

La vérification de la conformité aux exigences de sécurité minimales coûte beaucoup d'argent - de 15 000 $ à 75 000 $.
Les évaluations seront effectuées par un évaluateur tiers désigné par Google, peuvent coûter entre 15 000 $ et 75 000 $ (ou plus) selon la complexité de l'application, et seront payables par le développeur. Ces frais peuvent être exigés, que votre application réussisse ou non l'évaluation .

Dès le 9 janvier 2019, Google a resserré les règles pour les applications qui prévoient d'utiliser l'API Google. Pour les applications qui utilisaient l'API Google plus tôt, il fallait soumettre une demande de vérification avant le 15 février . Sinon, l'accès à l'application serait fermé aux nouveaux utilisateurs à partir du 22 février et les utilisateurs existants ne pourraient pas utiliser l'application à partir du 31 mars .

Les conséquences d'une telle évolution seraient désagréables. Cela est dû au fait qu'un nombre important de nos utilisateurs (et il y en a plus de 100 000) utilisent Gmail. Par conséquent, nous perdrions simplement ces clients.

Pour les projets qui nécessitent une action, vous devez soumettre les applications pour vérification avant le 15 février 2019. Si vous ne le faites pas, l'accès pour les nouveaux utilisateurs sera désactivé le 22 février 2019 et les subventions existantes pour les comptes de consommateurs seront révoquées le 31 mars, 2019.

Comment tout s'est-il passé avant les mises à jour?


Notre plateforme Snov.io utilise l'API Google depuis 2017. Notre application utilisait plusieurs étendues restreintes: pour lire le courrier entrant et pour travailler avec des brouillons. 

Google a déjà testé des applications qui utilisent l'API Google. Afin d'appliquer la nouvelle étendue API, il était nécessaire de l'ajouter à la console et d'indiquer à quoi elle sera utilisée. Alors que les employés de Google ont vérifié l'application, les utilisateurs ont vu la notification «Cette application n'est pas vérifiée» sur leurs écrans: 



Habituellement, cette vérification nous prenait 2-3 jours ouvrables (bien que, dans une lettre de Google, il ait été indiqué que le processus pouvait durer jusqu'à 7 jours) et se déroulait toujours sans problème. Nous avons attendu que Google vérifie notre application, puis nous avons ensuite ajouté la fonctionnalité au produit afin que les utilisateurs ne voient pas la notification "Cette application n'est pas vérifiée". 

Passage de la première étape


Pour commencer, nous avons décidé de nous concentrer sur la première étape de la vérification, à savoir la conformité de notre application avec la politique de données utilisateur de l'API Google. 

Le 16 janvier, le bouton Soumettre pour vérification est apparu dans la console Google et nous avons envoyé une demande. Avant le départ, nous nous sommes assurés de respecter tous les points de la politique relative aux données utilisateur de l'API Google. Nous avons apporté des modifications à notre politique de confidentialité, en particulier, ajouté la section Données utilisateur Google, qui décrit en détail les données reçues de l'API Google que nous stockons, comment nous les utilisons et quand nous les supprimons. 

Le 12 février, nous avons reçu une réponse à la demande soumise. On nous a demandé d'enregistrer des vidéos et de montrer comment nous utilisons les portées d'API restreintes demandées. 

En conséquence, nous avons dû abandonner nos deux projets sur Google Cloud et les fusionner en un seul. Nous avons abandonné le premier projet pour le serveur de test, qui fonctionnait en mode test, et avons utilisé le même projet pour le test que sur le prod. Nous avons également supprimé le deuxième projet pour autorisation dans le système via Google et avons plutôt utilisé le projet qui nécessitait une vérification pour se connecter. 

Des représentants de Google ont répondu à nos lettres quelque part après 2 semaines. Pour les questions, au lieu de réponses directes, nous avons reçu des devis. Il nous a semblé qu'ils ont un script spécial par lequel ils vérifient les candidatures. 

Par exemple, il nous a été rappelé que nous utilisons une application avec un ID pour entrer dans le système, et lors de la connexion d'un compte de messagerie, une application avec un ID différent. Nous l'avons fait exprès, car ce sont deux fonctions complètement différentes. L'application de connexion n'a nécessité aucune vérification et nous ne voulions pas que la vérification de l'application échoue avec des étendues d'API restreintes pour désactiver l'application de vérification.



Le 20 avril, nous avons finalement franchi la première étape de la vérification de la conformité aux politiques de Google Data!

Passage de la deuxième étape 


Étape 1. Choisir une entreprise pour réussir l'audit


À la deuxième étape du test de notre application, Google a envoyé les contacts de deux sociétés au choix - Bishop Fox et Leviathan Security . Il était possible de passer le chèque uniquement avec eux. La date limite a été donnée jusqu'au 31 décembre .

Le 20 mai, nous avons envoyé des lettres à deux experts indépendants pour réussir l'audit. Mgr Fox et Leviathan Security ont envoyé des questionnaires contenant des questions sur notre candidature. Il était nécessaire de répondre au type de données Google que nous utilisons, au nombre de lignes de code écrites pour chaque langage de programmation, ainsi qu'aux questions sur notre infrastructure, le processus de déploiement de logiciels et le fournisseur d'hébergement. Nous avons tout rempli et avons commencé à attendre l'offre de prix.



Au cours de la préparation et de la communication préliminaire avec les représentants de l'entreprise, nous avons appris que l'hébergement sur lequel nos serveurs sont situés n'est pas conforme à SOC2 . Et pour une vérification réussie, nous avons dû passer à l' hébergement SOC2 approprié . Nous pensons depuis longtemps à déménager sur Amazon , nous avons donc commencé le processus de déplacement en parallèle. 

Nous avons également appris que nous avions besoin du programme Bug Bounty proposé par de nombreux sites Web et développeurs de logiciels. Avec cela, les gens peuvent recevoir une reconnaissance et une récompense pour avoir trouvé des bogues, en particulier ceux liés aux exploits et aux vulnérabilités. 

En septembre, nous avons eu deux contrats tout faits avec Bishop Fox et Leviathan Security. Nous devions décider avec qui conclure un contrat. Nous ne savions pas pour quels critères choisir un expert, mais l'accord avec Leviathan Security nous a semblé plus transparent, malgré le fait qu'il coûte un peu plus cher.

Étape 2. Signature du contrat et préparation de la vérification


Le 8 octobre, nous avons signé un accord avec Leviathan Security. Au moment de la signature du contrat, nous n'avions pas encore terminé le processus de transfert vers Amazon. Par conséquent, dans notre contrat dans la colonne "hébergement", il y avait un écart et nous avons dû le saisir plus tard.

Nous avons également appris quelle vérification comprendra:

  • Test de pénétration de réseau externe 
  • Test de pénétration d'application 
  • Examen du déploiement 
  • Examen des politiques et procédures 

Et les étapes suivantes:

  • Préparation 
  • Évaluation
  • Vérification validation
  • Rapport final

Le chèque dure environ un mois. Son prix comprend du temps pour éliminer les vulnérabilités trouvées. Ensuite, un deuxième contrôle est effectué. À la suite de la vérification, nous aurions dû recevoir une lettre d'évaluation (LOA), qui doit ensuite être envoyée aux représentants de Google. Mais l'expert ne garantit pas la réception de la LOA comme résultat à 100% de l'évaluation. 

Le 23 octobre, Leviathan Security a envoyé un questionnaire d'auto-évaluation (SAQ). Avec elle, nous avons également fourni nos politiques nécessaires à la réussite de l'audit:

  • Plan de réponse aux incidents: établit les rôles, les responsabilités et les actions lorsqu'un incident se produit
  • Politique de gestion des risques: identifie, réduit et prévient les incidents ou les résultats indésirables
  • Politique de divulgation des vulnérabilités: fournit aux parties externes un moyen de signaler les vulnérabilités
  • Information Security Policy: Ensures that all users comply with rules and guidelines related to the security of the information stored digitally at any point in the network
  • Privacy Policy: Ensures that users can delete their accounts and related user data by demonstrating an account deletion if relevant

Le 8 novembre, une réunion d'alignement externe a eu lieu, au cours de laquelle nous avons discuté de tous les problèmes organisationnels, identifié un messager pour la communication ( Slack ) et brièvement parlé de notre application. Nous avons été avertis qu'il serait nécessaire de donner accès au code source - ce n'était pas un problème pour nous. 

Lors du rassemblement, nous avons appris que nous devons crypter les jetons Oauth à l'aide de KMS , ce que nous n'avions pas fait auparavant. Nous avons également discuté de l'heure approximative de notre chèque. On nous a assuré que si elle était nommée à la fin de l'année et que nous n'avions pas le temps de passer par là, Leviathan Security négocierait avec Google pour prolonger le délai pour nous.

14 novembreNous avons reçu des informations sur le début prévu de notre inspection: fin décembre ou début janvier. Et Leviathan Security a averti Google que nous pourrions fournir une LOA plus tard que la date limite. 

Le 16 novembre, nous avons reçu une confirmation de Google concernant la date limite de transfert jusqu'au 31 mars.

Étape 3. Vérification


Le 13 décembre, nous avons reçu une lettre dans laquelle nous avons été informés du début de l'audit - le 2 janvier, et nous avons demandé de remplir les conditions suivantes: 

1. Confirmer la possibilité d'un audit.

2. Encore une fois, fournissez les informations nécessaires. 

Les documents devaient être téléchargés dans le dossier partagé sur OneDrive une semaine avant l'analyse - jusqu'au 26 décembre . Nous n'avons fourni aucun document supplémentaire à l'exception des documents requis: 

  • Plan de réponse aux incidents
  • Politique de gestion des risques
  • Vulnerability Disclosure Policy
  • Information Security Policy
  • Privacy Policy
  • Supporting Privacy Documentation
  • Terms and Conditions
  • Self Assessment Questionnaire (SAQ)
  • API
  • URL-
  • IP


3. Fournissez l'accès au code source.

4. Invitez certaines personnes au messager Slack.

5. Indiquez le numéro de téléphone et les détails de l'escalade du projet.

6. Fournissez des informations sur la façon dont nous devrions être facturés.

7. Informer les équipes de sécurité interne, le CDN et les hébergeurs que la vérification aura lieu du 2 janvier au 27 janvier.

8. Créez un dossier partagé sur OneDrive.

9. Consultez la foire aux questions de Google Checkout . 

30 décembreune réunion de lancement a eu lieu, à laquelle presque tout était le même qu'au premier rallye. Nous nous sommes présentés, avons décrit le produit avec un ensemble de technologies et confirmé que notre système est stable et qu'aucune version majeure ne sera publiée lors de l'évaluation du produit. Elle s'est terminée par des questions et des commentaires. 

Le 2 janvier, un contrôle de sécurité a commencé. Notez qu'il s'est déroulé sans trop de difficultés. Parfois, c'était gênant en raison de la différence de fuseaux horaires - tous les appels et communications à Slack que nous avions déjà pendant les heures creuses pour nous. 

Nous avons trouvé de nombreuses vulnérabilités - niveau élevé et critique (élevé et critique). Ces vulnérabilités devaient être corrigées. Les vulnérabilités du niveau intermédiaire et inférieur pourraient être corrigées à leur discrétion. La correction a été donnée 30 jours. Mais nous les avons résolus littéralement le lendemain. 

Les vulnérabilités étaient principalement liées à des méthodes obsolètes de chiffrement des données utilisateur et à une journalisation insuffisante. Il n'y a eu aucune plainte contre nos documents de politique. Le Département des politiques de sécurité du Léviathan a posé quelques questions de clarification et a déclaré qu'elles avaient l'air solides.

La communication n'a pas manqué. Nous pourrions clarifier toutes les questions obscures au niveau des rallyes ou à Slack. Les rapports de vulnérabilité étaient bien documentés et comprenaient également des recommandations de correction. Le dernier jour de notre évaluation, toutes les vulnérabilités critiques, élevées, ainsi que certaines vulnérabilités moyennes et faibles ont été corrigées et vérifiées. 

Le 31 janvier, nous avons reçu la LOA et l'avons envoyée aux représentants de Google.  

Le 11 février a reçu une confirmation de vérification de Google.



La chose la plus difficile pour nous a été l'inconnu. À quoi s'attendre? Comment tout se passera-t-il? Nous nous sentions comme des pionniers. Nulle part il n'y avait d'informations sur la façon dont d'autres entreprises ont réussi ce test, ce qui nous a incités à partager des informations sur le contrôle de sécurité avec d'autres.

Nous voulons dire à ceux à qui un tel chèque est encore à venir, qu'il n'est pas aussi effrayant que cela puisse paraître. Oui, le processus prend du temps, mais il y aura une bonne marge de temps pour corriger toutes les vulnérabilités. Malgré le fait qu'il nous ait fallu un an pour passer par Google Security Checkup, ce temps n'a pas été perdu. Nous pouvons continuer à utiliser l'API Google, qui est vitale pour nous, ainsi que des vulnérabilités fermées qui pourraient par la suite apparaître latéralement pour nous ou nos clients.

Il y a des entreprises, comme Context.io, qui ont décidé de ne pas passer l'audit et ont fermé. Il y a ceux qui continuent de travailler sans accès à l'API, mais en même temps perdent leur réputation aux yeux des utilisateurs. Chaque entreprise qui doit être testée devra bien sûr peser indépendamment le pour et le contre. Le plus dur sera pour les très jeunes entreprises qui ne réalisent pas encore de bénéfices. Mais si l'entreprise a les ressources pour réussir le test, cela vaut vraiment la peine.

Nous espérons que notre expérience vous y aidera!

More articles:


All Articles