La seguridad de datos como función, no como idea tardía.
Cada tabla de inquilino ejecuta seguridad a nivel de fila de Postgres con FORCE y WITH CHECK. Los webhooks van firmados y resisten las repeticiones. El rol de base de datos en tiempo de ejecución no puede saltarse RLS. Lo documentamos todo en /trust.
RLS multiinquilino. Verificación de webhooks al nivel de Stripe. Separación de Postgres en dos roles.
3 módulos. Una sola superficie: Seguridad.
Cada tarjeta lleva a su sección detallada más abajo. Todos los módulos están disponibles hoy salvo que el texto indique lo contrario.
Una fuga de datos entre inquilinos no es un bug que parcheamos. La base de datos se niega a permitirla.
Cada tabla con ámbito de inquilino tiene una política de seguridad a nivel de fila de Postgres ligada a la organización actual. El rol en tiempo de ejecución es NOSUPERUSER NOBYPASSRLS, así que aunque una consulta esté mal formada, no se devuelve ninguna fila de otro inquilino. Probamos el aislamiento entre inquilinos en CI con Testcontainers.
Ir a la secciónNadie puede falsificar un webhook ni repetir uno antiguo.
Cada webhook de Stripe y Clerk se verifica con firma HMAC-SHA256 y una tolerancia de repetición de 300 segundos. Registramos cada ID de evento procesado por organización en billing_events con un índice UNIQUE, así que las repeticiones no hacen nada. Las comprobaciones de firma fallidas devuelven un 401 en silencio y nunca revelan el motivo.
Ir a la secciónCada cambio de estado queda registrado. Para siempre.
Se escriben entradas en el registro de auditoría por cada creación de campaña, invitación de afiliado, envío de pago, evento de facturación, acción del copiloto de IA y cambio manual de un administrador. El registro es de solo anexado, está limitado a la organización, captura el actor, la acción, el objetivo, la marca de tiempo y el origen de la petición tal y como lo ve nuestro edge, y se puede buscar desde la app de administración.
Ir a la secciónLo que esta superficie te da.
Seguridad de un vistazo
RLS multiinquilino. Verificación de webhooks al nivel de Stripe. Separación de Postgres en dos roles.
Integrados en Seguridad
Cada cambio, cada actor
Verificado con HMAC-SHA256
Aplicado en la base de datos
Una fuga de datos entre inquilinos no es un bug que parcheamos. La base de datos se niega a permitirla.
Cada tabla con ámbito de inquilino tiene una política de seguridad a nivel de fila de Postgres ligada a la organización actual. El rol en tiempo de ejecución es NOSUPERUSER NOBYPASSRLS, así que aunque una consulta esté mal formada, no se devuelve ninguna fila de otro inquilino. Probamos el aislamiento entre inquilinos en CI con Testcontainers.
- FORCE ROW LEVEL SECURITY en cada tabla de inquilino (más de 15 hoy)
- La cláusula WITH CHECK impide las inserciones entre inquilinos
- Postgres con dos roles: rekomi (superusuario, migraciones) y rekomi_app (tiempo de ejecución, NOSUPERUSER NOBYPASSRLS)
- Aislamiento entre inquilinos garantizado por pruebas de integración con Testcontainers en CI
Nadie puede falsificar un webhook ni repetir uno antiguo.
Cada webhook de Stripe y Clerk se verifica con firma HMAC-SHA256 y una tolerancia de repetición de 300 segundos. Registramos cada ID de evento procesado por organización en billing_events con un índice UNIQUE, así que las repeticiones no hacen nada. Las comprobaciones de firma fallidas devuelven un 401 en silencio y nunca revelan el motivo.
- Webhooks de Stripe: firma HMAC-SHA256 con ventana de repetición de 300 s
- Webhooks de Clerk: verificación de firma con Svix
- Cada evento se registra en billing_events para idempotencia y auditoría
- Una firma fallida devuelve un 401 y nunca revela qué comprobación falló
Cada cambio de estado queda registrado. Para siempre.
Se escriben entradas en el registro de auditoría por cada creación de campaña, invitación de afiliado, envío de pago, evento de facturación, acción del copiloto de IA y cambio manual de un administrador. El registro es de solo anexado, está limitado a la organización, captura el actor, la acción, el objetivo, la marca de tiempo y el origen de la petición tal y como lo ve nuestro edge, y se puede buscar desde la app de administración.
- Tabla audit_log de solo anexado por organización
- Captura el actor, la acción, el objetivo, la marca de tiempo y el origen de la petición tal y como lo ve nuestro edge
- Con búsqueda desde la app de administración
- Conservado indefinidamente para revisiones de cumplimiento
Preguntas habituales.
¿Dónde se almacenan los datos?
Postgres en un proveedor gestionado (producción); la app y la API de seguimiento de clics corren en infraestructura regional gestionada. Hoy solo en la región de EE. UU. El alojamiento en la UE está en la hoja de ruta.
¿Los datos están cifrados en reposo?
Sí. AES-256 en reposo, TLS 1.3 en tránsito. Los secretos de firma de las claves de API se cifran en reposo con ASP.NET Core Data Protection. El cifrado a nivel de campo de los datos identificativos de los formularios fiscales es un paso de refuerzo previsto.
¿Tenéis un informe SOC 2 que pueda leer?
Todavía no. No reclamamos una certificación que aún no tenemos. Nuestro modelo de seguridad de datos está documentado en detalle en /security y /trust. Cuando se complete una auditoría externa independiente, enviaremos el informe bajo NDA a quien lo solicite.
¿Qué pasa con mis datos si cancelo?
Puedes exportar tus datos en cualquier momento, antes o después de cancelar. Al cancelar, tus datos se conservan para que puedas reactivar la cuenta, y se eliminan si lo pides o cuando eliminas la cuenta. Las entradas del registro de auditoría sobre tu organización se conservan indefinidamente por cumplimiento legal.
¿Puedo usar mi propio AWS / GCP / Azure?
Por ahora no. Traer tu propia nube está en la hoja de ruta para empresas. Usamos un proveedor gestionado de Postgres y Cloudflare para el edge. Ambos cumplen los estándares de seguridad empresariales.
¿Hay un programa público de recompensas por errores?
Todavía no. Un programa formal está en la hoja de ruta. Mientras tanto, informa de los problemas de seguridad a support@rekomi.com y te responderemos en un día laborable.
¿Admitís SAML SSO?
Todavía no. SAML SSO está en la hoja de ruta para empresas. Hoy, Clerk gestiona la autenticación con correo y contraseña, enlace mágico y proveedores OAuth.
Otras partes de Rekomi.
Seguridad es una de las ocho superficies de Rekomi. Todas se construyen sobre los mismos cimientos (Stripe, Postgres con RLS, Clerk, Anthropic) y comparten el mismo listón de auditoría y seguridad.
Diez minutos hasta el primer clic.
Prueba gratis de 14 días. Stripe, Paddle, Braintree y más, de forma nativa. En marcha esta misma tarde.
- Prueba gratis de 14 días
- Cancela cuando quieras, $0 cobrados