Get best of the week

Como fizemos a verificação de segurança do Google

Para garantir a segurança dos dados do usuário, o Google verifica cuidadosamente todos os aplicativos que usam escopos de API restritos e têm acesso aos dados do usuário do Google. Há pouco tempo, no Snov.io, passamos pelo processo de verificação e recebemos a aprovação do Google, com a qual queremos compartilhar.

Novas regras para aplicativos


Em 9 de outubro de 2018, o Google anunciou novas regras para aplicativos que usam os escopos de API restritos do Google. Eles incluíram 2 estágios de verificação:

  • Verifique se seu aplicativo está em conformidade com a política de dados do usuário da API do Google
  • Verifique os requisitos mínimos de segurança

A verificação do aplicativo de escopo restrito verifica a conformidade com a Política de dados do usuário da API do Google e com um conjunto adicional de políticas descritas em Requisitos adicionais para escopos específicos da API. Primeiro, seu aplicativo será analisado quanto à conformidade com os Serviços de API do Google: política de dados do usuário. Posteriormente, você terá o restante de 2019 para demonstrar a conformidade com os requisitos de manuseio seguro.

A verificação da conformidade com os requisitos mínimos de segurança custa muito dinheiro - de US $ 15.000 a US $ 75.000.
As avaliações serão conduzidas por um avaliador terceirizado designado pelo Google, podem custar entre US $ 15.000 e US $ 75.000 (ou mais), dependendo da complexidade do aplicativo, e serão pagas pelo desenvolvedor. Essa taxa pode ser necessária se o aplicativo for ou não aprovado na avaliação .

Desde 9 de janeiro de 2019, o Google reforçou as regras para aplicativos que planejam usar a API do Google. Para aplicativos que usaram a API do Google anteriormente, havia um requisito para enviar um aplicativo para verificação antes de 15 de fevereiro . Caso contrário, o acesso ao aplicativo seria fechado para novos usuários a partir de 22 de fevereiro , e os usuários existentes não poderiam usá-lo a partir de 31 de março .

As consequências desse desenvolvimento seriam desagradáveis. Isso se deve ao fato de que um número significativo de nossos usuários (e existem mais de 100 mil) usa o Gmail. Portanto, simplesmente perderíamos esses clientes.

Para projetos que exigem ação, você deve enviar aplicativos para verificação antes de 15 de fevereiro de 2019. Caso contrário, o acesso para novos usuários será desativado em 22 de fevereiro de 2019, e as concessões existentes para contas de consumidor serão revogadas em 31 de março, 2019.

Como tudo aconteceu antes das atualizações?


Nossa plataforma Snov.io usa a API do Google desde 2017. Nosso aplicativo usou vários escopos restritos: para ler e-mails recebidos e trabalhar com rascunhos. 

O Google já testou aplicativos que usam a API do Google. Para aplicar o novo escopo da API, foi necessário adicioná-lo ao console e indicar para que ele será usado. Enquanto os funcionários do Google verificaram o aplicativo, os usuários viram a notificação "Este aplicativo não foi verificado" em suas telas: 



Normalmente, essa verificação nos leva de dois a três dias úteis (embora, em uma carta do Google, tenha sido indicado que o processo pode durar até sete dias) e sempre seja aprovada sem problemas. Esperamos até que o Google verifique nosso aplicativo e só então coloquei o recurso no produto para que os usuários não vissem a notificação "Este aplicativo não foi verificado". 

Passagem da primeira etapa


Para começar, decidimos nos concentrar no primeiro estágio da verificação, a saber, a conformidade do nosso aplicativo com a política de dados do usuário da API do Google. 

Em 16 de janeiro, o botão Enviar para verificação apareceu no console do Google e enviamos um aplicativo. Antes da partida, garantimos o cumprimento de todos os pontos da política de dados do usuário da API do Google. Fizemos alterações em nossa política de privacidade, em particular, adicionamos a seção Dados do usuário do Google, que descreveu detalhadamente quais dados recebidos da API do Google armazenamos, como os usamos e quando os excluímos. 

Em 12 de fevereiro, recebemos uma resposta ao aplicativo enviado. Nos pediram para gravar vídeos e mostrar como usamos os escopos de API restritos solicitados. 

Como resultado, tivemos que abandonar nossos dois projetos no Google Cloud e fundi-los em um. Abandonamos o primeiro projeto para o servidor de teste, que funcionava no modo de teste, e usamos o mesmo projeto para o teste que no prod. Também excluímos o segundo projeto de autorização no sistema por meio do Google e, em vez disso, usamos o projeto que exigia verificação para fazer login. 

Os representantes do Google responderam às nossas cartas em algum lugar após duas semanas. Para perguntas, em vez de respostas diretas, recebemos citações. Pareceu-nos que eles têm um script especial pelo qual verificam os aplicativos. 

Por exemplo, fomos lembrados de que usamos um aplicativo com um ID para entrar no sistema e, ao conectar uma conta de email, um aplicativo com um ID diferente. Fizemos isso de propósito, pois essas são duas funções completamente diferentes. O aplicativo de login não exigiu nenhuma verificação e não desejamos que a falha passasse na verificação do aplicativo com escopos de API restritos para desativar o aplicativo de verificação.



Em 20 de abril, finalmente passamos a primeira etapa da verificação de conformidade da política de dados do Google!

Passagem da segunda etapa 


Etapa 1. Escolhendo uma empresa para passar na auditoria


Na segunda etapa de teste de nosso aplicativo, o Google enviou contatos de duas empresas para escolher - Bishop Fox e Leviathan Security . Foi possível passar no cheque apenas com eles. O prazo foi dado até 31 de dezembro .

Em 20 de maio, enviamos cartas a dois especialistas independentes para passar na auditoria. O bispo Fox e a Leviathan Security enviaram questionários com perguntas sobre nossa solicitação. Era necessário responder que tipo de dados do Google usamos, quantas linhas de código são escritas para cada linguagem de programação, além de perguntas sobre nossa infraestrutura, o processo de implantação de software e provedor de hospedagem. Enchemos tudo e começamos a aguardar a oferta de preço.



Durante a preparação e a comunicação preliminar com os representantes da empresa, aprendemos que a hospedagem em que nossos servidores estão localizados não está em conformidade com o SOC2 . E para uma verificação bem-sucedida, tivemos que mudar para a hospedagem SOC2 apropriada . Há muito que pensamos em mudar para a Amazon , então começamos o processo de mudar em paralelo. 

Também aprendemos que precisamos do programa Bug Bounty oferecido por muitos sites e desenvolvedores de software. Com isso, as pessoas podem receber reconhecimento e recompensa por encontrar bugs, especialmente aqueles relacionados a explorações e vulnerabilidades. 

Em setembro, tínhamos dois contratos prontos do bispo Fox e da Leviathan Security. Tivemos que decidir com quem celebrar um contrato. Não sabíamos para que critério escolher um especialista, mas o acordo com a Leviathan Security nos pareceu mais transparente, apesar de custar um pouco mais.

Etapa 2. Assinando o contrato e preparando a verificação


Em 8 de outubro, assinamos um contrato com a Leviathan Security. No momento da assinatura do contrato, ainda não concluímos o processo de mudança para a Amazon. Portanto, em nosso contrato na coluna "hospedagem" havia uma lacuna e tivemos que entrar mais tarde.

Também aprendemos que verificação incluirá:

  • Teste de Penetração de Rede Externa 
  • Teste de penetração de aplicativos 
  • Revisão de implantação 
  • Revisão de Políticas e Procedimentos 

E os seguintes passos:

  • Preparação 
  • Avaliação
  • Validação de verificação
  • Relatório final

O cheque dura cerca de um mês. Seu preço inclui tempo para eliminar as vulnerabilidades encontradas. Em seguida, uma segunda verificação é realizada. Como resultado da verificação, deveríamos ter recebido uma carta de avaliação (LOA), que precisa ser enviada aos representantes do Google. Mas o especialista não garante o recebimento da LOA como resultado de 100% da avaliação. 

Em 23 de outubro, a Leviathan Security enviou um questionário de auto-avaliação (SAQ). Juntamente com ela, também fornecemos nossas políticas necessárias para passar na auditoria:

  • Plano de resposta a incidentes: Estabelece funções, responsabilidades e ações quando ocorre um incidente
  • Política de gerenciamento de riscos: identifica, reduz e evita incidentes ou resultados indesejáveis
  • Política de divulgação de vulnerabilidades: fornece um meio para as partes externas reportarem vulnerabilidades
  • 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

Em 8 de novembro, ocorreu uma Reunião de Alinhamento Externo, na qual discutimos todas as questões organizacionais, identificamos um messenger para comunicação ( Slack ) e falamos brevemente sobre nossa aplicação. Fomos avisados ​​de que seria necessário fornecer acesso ao código fonte - isso não foi um problema para nós. 

No comício, aprendemos que precisamos criptografar tokens Oauth usando o KMS , o que não fizemos antes. Também discutimos o tempo aproximado de nossa verificação. Estávamos certos de que, se ela fosse nomeada no final do ano e não tivéssemos tempo para fazê-lo, a Leviathan Security negociaria com o Google para estender o prazo.

14 de novembroRecebemos informações sobre o início planejado de nossa inspeção: final de dezembro ou início de janeiro. E a Leviathan Security alertou o Google de que poderíamos fornecer LOA depois do prazo. 

Em 16 de novembro, recebemos uma confirmação do Google de que o prazo foi adiado para 31 de março.

Etapa 3. Verificação


Em 13 de dezembro, recebemos uma carta na qual fomos notificados sobre o início da auditoria - 2 de janeiro e solicitados a cumprir os seguintes requisitos: 

1. Confirme a possibilidade de uma auditoria.

2. Mais uma vez, forneça as informações necessárias. 

Os documentos precisavam ser carregados na pasta compartilhada no OneDrive uma semana antes da verificação - até 26 de dezembro . Não fornecemos documentos adicionais, exceto os necessários: 

  • Plano de resposta a incidentes
  • Política de gerenciamento de riscos
  • Vulnerability Disclosure Policy
  • Information Security Policy
  • Privacy Policy
  • Supporting Privacy Documentation
  • Terms and Conditions
  • Self Assessment Questionnaire (SAQ)
  • API
  • URL-
  • IP


3. Forneça acesso ao código fonte.

4. Convide certas pessoas para o messenger do Slack.

5. Indique o número de telefone e os detalhes da escalação do projeto.

6. Forneça informações sobre como devemos ser cobrados.

7. Informe às equipes de segurança interna, CDN e provedores de hospedagem que a verificação ocorrerá de 2 a 27 de janeiro.

8. Crie uma pasta compartilhada no OneDrive.

9. Confira Google Saída Asked Questions . 

30 de dezembroocorreu uma reunião inicial, na qual quase tudo foi igual ao do primeiro rali. Nós nos apresentamos, descrevemos o produto com um conjunto de tecnologias e confirmamos que nosso sistema é estável e que nenhuma versão importante será lançada durante a avaliação do produto. Terminou com perguntas e comentários. 

Em 2 de janeiro, uma verificação de segurança começou. Observe que ocorreu sem muita dificuldade. Às vezes, era inconveniente devido à diferença de fuso horário - todas as chamadas e comunicações no Slack que já tínhamos durante o horário de expediente para nós. 

Encontramos muitas vulnerabilidades - nível alto e crítico (alto e crítico). Tais vulnerabilidades precisavam ser corrigidas. Vulnerabilidades do nível intermediário e inferior podem ser corrigidas a seu critério. A correção foi dada em 30 dias. Mas nós os consertamos literalmente no dia seguinte. 

As vulnerabilidades estavam principalmente relacionadas a métodos desatualizados de criptografia de dados do usuário e registro insuficiente. Não houve reclamações contra nossos documentos de política. O Departamento de Política de Segurança do Leviatã fez algumas perguntas esclarecedoras e disse que elas pareciam sólidas.

Não houve falta de comunicação. Poderíamos esclarecer todas as questões obscuras no status de comícios ou no Slack. Os relatórios de vulnerabilidade estavam bem documentados e também incluíam recomendações para correção. No último dia de nossa avaliação, todas as vulnerabilidades críticas, altas e algumas médias e baixas foram corrigidas e verificadas. 

Em 31 de janeiro, recebemos a LOA e a enviamos aos representantes do Google.  

O dia 11 de fevereiro recebeu a confirmação da verificação do Google.



A coisa mais difícil para nós era o desconhecido. O que esperar? Como tudo vai acontecer? Nós nos sentimos pioneiros. Em nenhum lugar havia informações sobre como outras empresas passaram no teste, o que nos levou a compartilhar informações sobre o exame de segurança com outras pessoas.

Queremos dizer àqueles a quem esse cheque ainda está por vir, que não é tão assustador quanto possa parecer. Sim, o processo é demorado, mas haverá uma boa margem de tempo para corrigir todas as vulnerabilidades. Apesar de levarmos um ano para passar pelo Google Security Checkup, esse tempo não foi desperdiçado. Podemos continuar usando a API do Google, que é vital para nós, e também encerramos vulnerabilidades que poderiam surgir de lado para nós ou nossos clientes.

Existem empresas, como a Context.io, que decidiram não passar na auditoria e fecharam. Há quem continue trabalhando sem acesso à API, mas, ao mesmo tempo, perca sua reputação aos olhos dos usuários. Toda empresa que precisa ser testada, é claro, terá que pesar independentemente os prós e os contras. O mais difícil será para empresas muito jovens que ainda não têm lucro. Mas se a empresa tiver os recursos para passar no teste, definitivamente vale a pena.

Esperamos que nossa experiência o ajude com isso!

More articles:


All Articles