GroLabs trata la seguridad como una línea base, no como una casilla a marcar. Esta página describe cómo protegemos los datos que pasan por la plataforma hoy y a dónde nos dirigimos. La actualizamos cuando nuestra postura cambia materialmente.
1. Encriptación en tránsito
Todo el tráfico hacia y desde GroLabs se sirve sobre HTTPS con TLS 1.2 o superior. Forzamos un redirect desde cualquier URL en texto plano. Nuestros certificados son emitidos por autoridades estándar de la industria y rotados automáticamente por nuestros proveedores de hosting.
2. Encriptación en reposo
Los datos de clientes son almacenados por nuestros subprocesadores administrados (Supabase, Vercel, Browserless, etc.). Cada uno encripta los datos en reposo usando AES-256, administrado por la plataforma cloud subyacente (AWS / GCP). Nuestro acceso a esos almacenes de datos es registrado.
3. Autenticación
- Delegamos el almacenamiento de contraseñas a Supabase Auth, que usa bcrypt con un salt por usuario.
- Las sesiones se manejan con JWTs firmados con tiempos de vida cortos; el flujo de refresh se rota del lado del servidor.
- SSO y autenticación multi-factor están en el roadmap.
4. Autorización y aislamiento de tenants
El aislamiento entre tenants se aplica a nivel de fila de base de datos. Cada tabla operacional lleva un instance_id, y las políticas Row-Level Security de Postgres de Supabase hacen que la membresía de un usuario en una instancia sea el único camino a los datos de esa instancia. El código de aplicación nunca escribe cláusulas WHERE instance_id = X — RLS lo hace, eliminando una clase entera de bugs de autorización.
La clave service-role (que evita RLS) se guarda en variables de entorno y solo es usada por flujos confiables del lado del servidor (operaciones de admin, ingest de la API pública anónima, subida de capturas). Nunca se envía al navegador.
5. Rutas públicas de lectura
Algunas URLs de reportes son públicas: el token de compartir para una corrida de diagnóstico es un UUID no adivinable. Cualquiera con la URL puede leer el reporte, pero sin la URL no hay lectura posible. Los buckets de Storage usados para las capturas siguen el mismo modelo — acceso público de lectura con un prefijo de corrida no adivinable.
6. Egreso de red y la sonda de navegador
La sonda basada en navegador (Playwright via Browserless) solo carga las URLs que configurás explícitamente para diagnósticos, más los assets que esas páginas referencian. La sonda corre en un pool de Chromium administrado por Browserless, aislado de nuestra infraestructura de aplicación.
7. Selección de subprocesadores
Elegimos subprocesadores con posturas de seguridad sólidas: Supabase (SOC 2 Tipo II), Vercel (SOC 2 Tipo II), Google Cloud, AWS, Browserless, Railway. La lista completa y qué recibe cada uno está en nuestra Política de Privacidad. Cada uno está sujeto a un Acuerdo de Procesamiento de Datos.
8. Acceso interno
- El acceso a producción está limitado a un número pequeño de operadores.
- Cada acción de admin contra la base de datos de producción es revisada contra prácticas de gestión de cambios.
- Los dispositivos personales usados para acceso a producción corren con encriptación de disco completo y sistemas operativos al día.
9. Logging, monitoreo y alertas
Los errores de aplicación y métricas de performance fluyen hacia nuestro stack de observabilidad (logs de Vercel, logs de Supabase, la sonda interna /configuration/system-health). Las alertas se envían a on-call cuando los chequeos clave de salud regresan. La integración con Sentry está en el roadmap cercano.
10. Gestión de vulnerabilidades
- Las dependencias se mantienen al día con PRs automatizados y se revisan contra advisories.
- Todavía no corremos pen tests externos en un cronograma fijo; damos la bienvenida a reportes de investigadores independientes.
11. Respuesta a incidentes
Si confirmamos un incidente que afecta datos de clientes, vamos a notificar a los clientes afectados sin demoras indebidas (dentro de 72 horas donde lo exija la ley de protección de datos) con lo que sabemos, lo que estamos haciendo y cómo puede afectar a sus datos.
12. Roadmap de compliance
- Hoy: nos apoyamos en las atestaciones SOC 2 de nuestros proveedores de infraestructura y aplicamos los controles técnicos descriptos arriba.
- Cercano plazo: planeamos contratar a una firma independiente para atestar nuestros propios controles (SOC 2 Tipo I, luego Tipo II) a medida que crece la base de clientes.
- Los pedidos de derechos de titulares estilo GDPR se honran hoy vía el email de contacto en la Política de Privacidad.
13. Reporte responsable de vulnerabilidades
Si creés que encontraste una vulnerabilidad de seguridad, por favor enviá un email a [email protected] con los pasos para reproducirla. Por favor:
- Dejanos una ventana razonable para investigar y remediar antes de la divulgación pública.
- No realices pruebas que afecten los datos de otros clientes.
- No retengas, alteres ni transfieras datos que encuentres durante la prueba.
Respondemos dentro de dos días hábiles para acusar recibo del reporte y te vamos a mantener al día sobre la remediación. Todavía no tenemos un bug bounty pago, pero estamos felices de acreditar públicamente a investigadores (con tu permiso) por hallazgos válidos.
14. Contacto
Consultas de seguridad: [email protected].