Seguridad

Última actualización: agosto 2026

RQE trata la seguridad como propiedad del sistema, no como capa adicional. El aislamiento entre organizaciones se aplica en la base de datos con Row Level Security (RLS); una consulta SQL directa con credenciales de usuario no puede cruzar organizaciones.

Aislamiento multi-tenant

• Toda tabla tenant-scoped tiene org_id NOT NULL.
• Toda tabla tenant-scoped tiene RLS habilitado con policies explícitas por rol.
• Las RPCs sensibles validan pertenencia a la organización antes de fijar el contexto.
• Los GRANT se aplican explícitamente por tabla y por rol; no se depende de defaults del esquema.

Control de acceso

• Los roles se almacenan en una tabla user_roles separada del perfil, para evitar escalamiento de privilegios.
• Las verificaciones de rol usan funciones SECURITY DEFINER con search_path fijo, para no incurrir en recursividad de RLS.
• Ningún check de rol se hace en cliente ni en localStorage.

Cifrado

• En tránsito: TLS 1.2+ obligatorio en toda la superficie pública.
• En reposo: cifrado a nivel de disco en la base administrada.
• Los secretos de aplicación se guardan en un almacén de secretos, nunca en el repositorio.

Auditoría

• Cambios de propiedad (ownership transfer) quedan registrados con actor, timestamp y contexto.
• Cambios en reglas de comisión quedan versionados; cada payout guarda snapshot de reglas.
• Las RPCs sensibles emiten logs estructurados (por ejemplo org_context_missing fn=X user=Y) antes de fallar.
• Los errores de API llevan un requestId trazable en logs.

Datos y modelos

• Los datos de una organización nunca se usan para entrenar modelos que sirvan a otras organizaciones.
• Los componentes opcionales que usan modelos de lenguaje procesan datos por request; no se realiza fine-tuning con datos del cliente por defecto.

Retención y borrado

• Retención estándar de logs operativos: 90 días.
• Borrado de cuenta a pedido, dentro de los 30 días hábiles.
• Backups periódicos con retención acotada.
• Exportación de datos disponible por CSV y vía API.

Autenticación de la aplicación

• Autenticación con proveedor gestionado; contraseñas nunca almacenadas en claro.
• OAuth social soportado (Google) con redirect_uri restringido al origen público.
• Sesiones con expiración y refresh controlado.

Prácticas de ingeniería

• Revisión de código obligatoria para cambios en tablas, RLS y RPCs sensibles.
• Guardas automáticos: revisiones de policies, filtraciones de contexto de organización y linting de seguridad en CI.
• Dependencias auditadas periódicamente.

Reporte de vulnerabilidades

Reportá vulnerabilidades a security@revenuequalityengine.com. No se ejecutan represalias por reportes hechos de buena fe.