😞 ➰ 🌩️ ¿Cómo hicimos el chequeo de seguridad de Google? 🥗 ✍🏻 🚴🏽

Para garantizar la seguridad de los datos del usuario, Google verifica cuidadosamente todas las aplicaciones que utilizan ámbitos API restringidos y tienen acceso a los Datos del usuario de Google. No hace mucho tiempo, en Snov.io pasamos por el proceso de verificación y recibimos la aprobación de Google, con la que queremos compartir.

Nuevas reglas para aplicaciones

El 9 de octubre de 2018, Google anunció nuevas reglas para las aplicaciones que usan los ámbitos de API restringidos de Google. Incluyeron 2 etapas de verificación:

Verifique que su aplicación cumpla con la política de datos de usuario de la API de Google
Verifique los requisitos mínimos de seguridad

La verificación de la aplicación de alcance restringido verifica el cumplimiento de la Política de datos de usuario de la API de Google y un conjunto adicional de políticas descritas en Requisitos adicionales para ámbitos API específicos. Primero, se revisará su aplicación para verificar que cumpla con los Servicios API de Google: Política de datos del usuario. A partir de entonces, tendrá el resto de 2019 para demostrar el cumplimiento de los requisitos de manejo seguro.

La verificación del cumplimiento de los requisitos mínimos de seguridad cuesta mucho dinero, de $ 15,000 a $ 75,000.

Las evaluaciones serán realizadas por un asesor externo designado por Google, puede costar entre $ 15,000 y $ 75,000 (o más) dependiendo de la complejidad de la aplicación, y será pagado por el desarrollador. Esta tarifa puede ser requerida ya sea que su aplicación apruebe o no la evaluación .

Ya el 9 de enero de 2019, Google endureció las reglas para las aplicaciones que planean usar la API de Google. Para las aplicaciones que utilizaron la API de Google anteriormente, había un requisito para enviar una solicitud de verificación antes del 15 de febrero . De lo contrario, el acceso a la aplicación estaría cerrado para los nuevos usuarios a partir del 22 de febrero , y los usuarios existentes no podrían usar la aplicación desde el 31 de marzo .

Las consecuencias de tal desarrollo serían desagradables. Esto se debe al hecho de que un número significativo de nuestros usuarios (y hay más de 100 mil) usan Gmail. Por lo tanto, simplemente perderíamos a estos clientes.

Para los proyectos que requieren acción, debe enviar las aplicaciones para su verificación antes del 15 de febrero de 2019. Si no lo hace, el acceso para nuevos usuarios se deshabilitará el 22 de febrero de 2019, y las subvenciones existentes para cuentas de consumidores se revocarán el 31 de marzo, 2019.

¿Cómo sucedió todo antes de las actualizaciones?

Nuestra plataforma Snov.io ha estado utilizando la API de Google desde 2017. Nuestra aplicación utilizó varios ámbitos restringidos: para leer el correo entrante y para trabajar con borradores.

Google ha probado previamente aplicaciones que usan la API de Google. Para aplicar el nuevo alcance de API, fue necesario agregarlo a la consola e indicar para qué se utilizará. Mientras los empleados de Google revisaban la aplicación, los usuarios vieron la notificación "Esta aplicación no está verificada" en sus pantallas:

Por lo general, este control nos llevó de 2 a 3 días hábiles (aunque en una carta de Google se indicó que el proceso puede durar hasta 7 días) y siempre se aprobó sin problemas. Esperamos hasta que Google verificó nuestra aplicación y solo entonces vertimos la función en el producto para que los usuarios no vieran la notificación "Esta aplicación no está verificada".

Paso de la primera etapa.

Para empezar, decidimos centrarnos en la primera etapa de verificación, a saber, el cumplimiento de nuestra aplicación con la política de datos de usuario API de Google.

El 16 de enero, el botón Enviar para verificación apareció en la consola de Google y enviamos una solicitud. Antes de partir, nos aseguramos de cumplir con todos los puntos de la política de datos de usuario de la API de Google. Hicimos cambios en nuestra política de privacidad, en particular, agregamos la sección Datos de usuario de Google, que describe en detalle qué datos recibimos de la API de Google que almacenamos, cómo la usamos y cuándo la eliminamos.

12 de febrero, recibimos una respuesta a la solicitud presentada. Nos pidieron grabar videos y mostrar cómo usamos los ámbitos de API restringidos solicitados.

Como resultado, tuvimos que abandonar nuestros dos proyectos en Google Cloud y fusionarlos en uno. Abandonamos el primer proyecto para el servidor de prueba, que funcionaba en modo de prueba, y utilizamos el mismo proyecto para la prueba que en el producto. También eliminamos el segundo proyecto para autorización en el sistema a través de Google y en su lugar utilizamos el proyecto que requería verificación para iniciar sesión.

Los representantes de Google respondieron nuestras cartas en algún lugar después de 2 semanas. Para preguntas, en lugar de respuestas directas, recibimos citas. Nos pareció que tienen un script especial mediante el cual verifican las aplicaciones.

Por ejemplo, se nos recordó que usamos una aplicación con una ID para ingresar al sistema, y cuando conectamos una cuenta de correo electrónico, una aplicación con una ID diferente. Hicimos esto a propósito, ya que estas son dos funciones completamente diferentes. La aplicación de inicio de sesión no requirió ninguna verificación y no queríamos que la falla de pasar la verificación de la aplicación con ámbitos API restringidos para deshabilitar la aplicación de verificación.

¡El 20 de abril, finalmente pasamos la primera etapa de la verificación de cumplimiento de la política de datos de Google!

Paso de la segunda etapa.

Paso 1. Elegir una compañía para pasar la auditoría

En la segunda etapa de prueba de nuestra aplicación, Google envió contactos de dos compañías para elegir: Bishop Fox y Leviathan Security . Era posible pasar el cheque solo con ellos. La fecha límite se dio hasta el 31 de diciembre .

El 20 de mayo, enviamos cartas a dos expertos independientes para aprobar la auditoría. Bishop Fox y Leviathan Security enviaron cuestionarios con preguntas sobre nuestra aplicación. Era necesario responder qué tipo de datos de Google usamos, cuántas líneas de código se escriben para cada lenguaje de programación, así como preguntas sobre nuestra infraestructura, el proceso de implementación de software y el proveedor de alojamiento. Completamos todo y comenzamos a esperar la oferta de precios.

Durante la preparación y comunicación preliminar con los representantes de la compañía, supimos que el alojamiento en el que se encuentran nuestros servidores no cumple con SOC2 . Y para una verificación exitosa tuvimos que pasar al alojamiento SOC2 apropiado . Llevamos mucho tiempo pensando en mudarnos a Amazon , por lo que comenzamos el proceso de mudanza en paralelo.

También aprendimos que necesitamos el programa Bug Bounty ofrecido por muchos sitios web y desarrolladores de software. Con él, las personas pueden recibir reconocimiento y recompensa por encontrar errores, especialmente aquellos relacionados con vulnerabilidades y vulnerabilidades.

En septiembre, teníamos dos contratos confeccionados por Bishop Fox y Leviathan Security. Tuvimos que decidir con quién celebrar un contrato. No sabíamos para qué criterios elegir un experto, pero el acuerdo con Leviathan Security nos pareció más transparente, a pesar de que costaba un poco más.

Paso 2. Firmar el contrato y prepararse para la verificación

El 8 de octubre, firmamos un acuerdo con Leviathan Security. Al momento de firmar el contrato, aún no hemos completado el proceso de mudarse a Amazon. Por lo tanto, en nuestro contrato en la columna "hosting" había un vacío y tuvimos que ingresarlo más tarde.

También aprendimos qué verificación incluirá:

Prueba de penetración de red externa
Prueba de penetración de aplicaciones
Revisión de implementación
Revisión de políticas y procedimientos

Y los siguientes pasos:

Preparación
Evaluación
Verificación validación
Reporte final

El cheque dura aproximadamente un mes. Su precio incluye tiempo para eliminar las vulnerabilidades encontradas. Luego se realiza una segunda verificación. Como resultado de la verificación, deberíamos haber recibido una Carta de evaluación (LOA), que luego debe enviarse a los representantes de Google. Pero el experto no garantiza la recepción de LOA como resultado del 100% de la evaluación.

El 23 de octubre, Leviathan Security envió un cuestionario de autoevaluación (SAQ). Junto con ella, también proporcionamos nuestras políticas necesarias para aprobar la auditoría:

Plan de respuesta a incidentes: establece roles, responsabilidades y acciones cuando ocurre un incidente
Política de gestión de riesgos: identifica, reduce y previene incidentes o resultados indeseables
Política de divulgación de vulnerabilidades: proporciona un medio para que terceros externos denuncien 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

El 8 de noviembre, se llevó a cabo una reunión de alineación externa, en la que discutimos todos los problemas de la organización, identificamos un mensajero para la comunicación ( Slack ) y hablamos brevemente sobre nuestra aplicación. Se nos advirtió que sería necesario proporcionar acceso al código fuente; esto no fue un problema para nosotros.

En el rally, aprendimos que necesitamos cifrar los tokens Oauth usando KMS , lo cual no hacíamos antes. También discutimos el tiempo aproximado de nuestro cheque. Se nos aseguró que si ella era nombrada a fin de año y no teníamos tiempo para hacerlo, Leviathan Security negociará con Google para extender el plazo para nosotros.

14 de noviembreRecibimos información sobre el inicio previsto de nuestra inspección: finales de diciembre o principios de enero. Y Leviathan Security advirtió a Google que podríamos proporcionar LOA más tarde de la fecha límite.

El 16 de noviembre, recibimos la confirmación de Google de que el plazo se pospuso hasta el 31 de marzo.

Paso 3. Verificación

El 13 de diciembre, recibimos una carta en la que se nos notificó sobre el inicio de la auditoría, el 2 de enero, y se nos solicitó cumplir con los siguientes requisitos:

1. Confirmar la posibilidad de una auditoría.

2. Una vez más proporcione la información necesaria.

Los documentos tuvieron que cargarse en la carpeta compartida en OneDrive una semana antes del escaneo, hasta el 26 de diciembre . No proporcionamos ningún documento adicional, excepto los requeridos:

Plan de respuesta a incidentes
Política de gestión de riesgos
Vulnerability Disclosure Policy
Information Security Policy
Privacy Policy
Supporting Privacy Documentation
Terms and Conditions
Self Assessment Questionnaire (SAQ)
API
URL-
IP

3. Proporcione acceso al código fuente.

4. Invita a ciertas personas al mensajero Slack.

5. Indique el número de teléfono y los detalles para la escalada del proyecto.

6. Proporcione información sobre cómo se nos debe facturar.

7. Informe a los equipos de seguridad interna, CDN y proveedores de hosting que la verificación se realizará del 2 al 27 de enero.

8. Cree una carpeta compartida en OneDrive.

9. Salida Google Checkout Frequently Asked Questions .

30 de diciembrese celebró una reunión inicial, en la que casi todo fue igual que en el primer rally. Nos presentamos, describimos el producto con un conjunto de tecnologías y confirmamos que nuestro sistema es estable y que no se lanzarán lanzamientos importantes durante la evaluación del producto. Terminó con preguntas y comentarios.

El 2 de enero, comenzó un control de seguridad. Tenga en cuenta que tuvo lugar sin mucha dificultad. A veces era inconveniente debido a la diferencia en las zonas horarias: todas las llamadas y comunicaciones en Slack que ya teníamos durante las horas no laborables para nosotros.

Hemos encontrado muchas vulnerabilidades: nivel alto y crítico (alto y crítico). Tales vulnerabilidades necesitaban ser reparadas. Las vulnerabilidades del nivel medio e inferior podrían corregirse a discreción. La corrección se dio 30 días. Pero los arreglamos literalmente al día siguiente.

Las vulnerabilidades se relacionaron principalmente con métodos obsoletos de encriptación de datos de usuario y registro insuficiente. No hubo quejas contra nuestros documentos de política. El Departamento de Política de Seguridad de Leviatán hizo algunas preguntas aclaratorias y dijo que parecían sólidas.

No hubo falta de comunicación. Podríamos aclarar todos los asuntos oscuros en el estado de las manifestaciones o en Slack. Los informes de vulnerabilidad estaban bien documentados y también incluían recomendaciones para su reparación. El último día de nuestra evaluación, todas las vulnerabilidades críticas, altas y algunas medias y bajas fueron reparadas y verificadas.

El 31 de enero, recibimos el LOA y lo enviamos a los representantes de Google.

El 11 de febrero recibió la confirmación de verificación de Google.

Lo más difícil para nosotros fue lo desconocido. ¿Que esperar? ¿Cómo va a pasar todo? Nos sentimos pioneros. En ninguna parte había información sobre cómo otras compañías pasaron esta prueba, lo que nos llevó a compartir información sobre el Chequeo de seguridad con otros.

Queremos decirles a aquellos a quienes tal cheque aún está por llegar, que no da tanto miedo como podría parecer. Sí, el proceso lleva mucho tiempo, pero habrá un buen margen de tiempo para corregir todas las vulnerabilidades. A pesar de que nos llevó un año pasar por Google Security Checkup, esta vez no se desperdició. Podemos seguir usando la API de Google, que es vital para nosotros, y también cerró las vulnerabilidades que posteriormente podrían quedar de lado para nosotros o nuestros clientes.

Hay compañías, como Context.io, que han decidido no pasar la auditoría y han cerrado. Hay quienes continúan trabajando sin acceso a la API, pero al mismo tiempo pierden su reputación a los ojos de los usuarios. Cada negocio que necesita ser probado, por supuesto, tendrá que sopesar independientemente los pros y los contras. Lo más difícil será para las empresas muy jóvenes que aún no tienen ganancias. Pero si la empresa tiene los recursos para pasar la prueba, definitivamente vale la pena hacerlo.

¡Esperamos que nuestra experiencia lo ayude con esto!

¿Cómo hicimos el chequeo de seguridad de Google?