Centro de Confianza

Seguridad y privacidad en Hober

Cómo protegemos los datos que nuestros clientes nos confían. Cada compromiso a continuación corresponde a un control concreto ya implementado en la plataforma, no a una aspiración. Cuando una capacidad todavía no existe, lo decimos con claridad más abajo.

Aislamiento entre inquilinos (tenants)

Los datos de cada inquilino se aíslan en la capa de base de datos con Row-Level Security (RLS) de PostgreSQL, y las tablas con datos sensibles se ejecutan en modo FORCE — de modo que ni siquiera el propio rol de base de datos de la aplicación puede leer entre inquilinos. El acceso se limita por solicitud a un único inquilino mediante una variable de sesión establecida dentro de cada transacción; la clave de API de un inquilino nunca puede acceder a los suscriptores, canales o credenciales de otro.

Cifrado

Los datos se cifran en tránsito (TLS) y en reposo. Los secretos y credenciales se protegen con cifrado de sobre (envelope) respaldado por Google Cloud KMS: cada credencial se sella con su propia clave de datos AES‑256‑GCM, que a su vez se envuelve con una clave de KMS y nunca se almacena en texto plano. Claves distintas separan las credenciales de canal, los secretos de doble factor y los tokens de OAuth. Un volcado de la base de datos por sí solo no revela ningún secreto utilizable.

Sus derechos sobre los datos (GDPR / CCPA / LGPD)

• Acceso y portabilidad — un portal de autoservicio permite a un suscriptor (o a un cliente en su nombre) solicitar una copia de sus datos. La portabilidad a nivel de cuenta — exportación completa y salida garantizada — es un compromiso escrito: consulta nuestra Política de Portabilidad de Datos.
• Derecho de supresión — las solicitudes de borrado se propagan por los registros del suscriptor y anonimizan los registros históricos de entrega; las eliminaciones son irreversibles y auditadas.
• Consentimiento, aplicado en el envío — cada mensaje se verifica contra el consentimiento del destinatario antes de la entrega; un consentimiento retirado suprime la entrega automáticamente.
• Registro de consentimiento inmutable — cada cambio de consentimiento se registra en un libro de solo anexado (append‑only).

Consulte nuestro Anexo de Tratamiento de Datos, la lista de subprocesadores y el centro de preferencias.

Retención de datos

Los registros de entrega se conservan 90 días y luego se anonimizan. Los registros de auditoría de eliminación se conservan 7 años como evidencia de cumplimiento. Los datos personales se conservan hasta que se solicita su supresión.

Autenticación y protección de cuentas

• Autenticación multifactor (TOTP) para los usuarios de clientes y para nuestra propia consola de personal/operador.
• Sesiones firmadas con RS256 (RSA) y tokens de corta duración.
• Bloqueo de cuenta tras intentos fallidos repetidos de inicio de sesión o MFA.
• Restablecimiento de contraseña e inicio de sesión con OAuth 2.0.

Acceso con privilegios mínimos

• Roles de base de datos por binario: cada servicio se ejecuta con su propio rol de base de datos de alcance limitado, sin capacidad de alterar el esquema en tiempo de ejecución.
• Control de acceso basado en roles dentro de cada inquilino.
• Nuestro plano de operador interno está separado del acceso a datos de clientes, requiere MFA y escribe en su propio registro de auditoría.

Pruebas y gestión de vulnerabilidades

• Una suite de seguridad automatizada se ejecuta contra staging antes de promover cualquier versión a producción — verificando el cifrado en reposo, los límites de acceso y que ningún secreto se filtre a registros o colas.
• Escaneo de imágenes de contenedor en cada compilación (una vulnerabilidad crítica detiene la compilación) más actualizaciones automáticas de dependencias.
• El análisis estático y el linting validan cada cambio.
• Una suite dedicada de pruebas de penetración ejercita rutas de ataque de autenticación, sesión y aislamiento de tenants antes de cada lanzamiento, y un rol de prueba permanente de privilegio mínimo respalda las evaluaciones de seguridad externas.

Infraestructura y subprocesadores

Hober se ejecuta en Google Cloud (Cloud Run, Cloud SQL, Cloud KMS, Pub/Sub), con los datos almacenados en Estados Unidos (región us‑central1). Utilizamos un conjunto pequeño y divulgado de subprocesadores — consulte la lista de subprocesadores y su historial de cambios.

Notificación de brechas

Nos comprometemos a notificar a los responsables afectados de una brecha de datos personales en un plazo de 72 horas (GDPR) / 2 días hábiles para brechas de alto riesgo (LGPD).

Certificaciones y hoja de ruta

Creemos en ser francos sobre nuestra situación. Hober actualmente no cuenta con certificaciones SOC 2, ISO 27001 ni HIPAA. Una auditoría SOC 2 Tipo I y la residencia de datos en la UE (europe‑west1) están en nuestra hoja de ruta, y actualizaremos esta página cuando se concreten — no las afirmaremos antes de que sean reales.

Mapa de controles

Reportar una vulnerabilidad

¿Encontró un problema de seguridad? Queremos saberlo. Escriba a security@hober.io con los detalles y los pasos para reproducirlo. Confirmaremos su reporte y le mantendremos informado sobre la solución. Le pedimos que nos dé un plazo razonable para remediar antes de cualquier divulgación pública.

Nuestro security.txt legible por máquinas está en /.well-known/security.txt.

Dentro del alcance: las propiedades web de Hober (hober.io y sus subdominios), el panel, la API pública y los SDKs publicados.

Fuera del alcance: pruebas de denegación de servicio o volumétricas, ingeniería social o phishing al personal o clientes de Hober, ataques físicos, y hallazgos que requieran un dispositivo ya comprometido o credenciales robadas.

Puerto seguro: no emprenderemos ni apoyaremos acciones legales contra la investigación de seguridad de buena fe que se mantenga dentro del alcance, evite violaciones de privacidad e interrupciones del servicio, y conceda un plazo razonable de remediación antes de la divulgación pública. Actualmente no tenemos un programa de recompensas de pago — lo decimos claramente en lugar de insinuarlo.