Seguridad y Row Level Security (RSL)

Última actualización: 2 de enero de 2026

En aideal.dev, aplicamos los mismos estándares de seguridad de alto nivel que exigimos a nuestros usuarios. Esta página explica nuestra arquitectura de seguridad, con especial énfasis en Row Level Security (RSL).

1. Filosofía: 'We Eat Our Own Dog Food'

No pedimos a las empresas que hagan algo que nosotros no hacemos. Si evaluamos sistemas de IA por riesgos de seguridad, nuestro propio sistema debe ser blindado. Por eso:

Zero Trust

Ningún componente confía en otro por defecto. Cada petición se valida.

Defense in Depth

Múltiples capas de seguridad (auth, RLS, encryption, logs).

Privacy by Design

Datos sensibles ocultos por defecto (double-blind matching).

2. Row Level Security (RLS): El Escudo de Datos

RLS es una técnica de seguridad a nivel de base de datos que garantiza que los usuarios solo puedan acceder a sus propias filas de datos.

A. Definición de Políticas RLS

Cada tabla en nuestra base de datos (Supabase PostgreSQL) tiene políticas RLS que filtran automáticamente los datos según el usuario autenticado:

-- Tabla profiles:
SELECT * FROM profiles
WHERE auth.uid()::TEXT = user_id;
-- Tabla evaluations:
SELECT * FROM evaluations
WHERE company_id = auth.uid()::TEXT;
-- Tabla matches:
Solo empresas y profesionales involucrados
pueden ver detalles del match.

B. Ventajas de RLS sobre Lógica de Aplicación

  • Imposible de Saltarse:

    Aunque haya un bug en el código frontend, la base de datos rechazará peticiones no autorizadas.

  • Auditabilidad:

    Todas las políticas están definidas en SQL y versionadas en Git.

  • Rendimiento:

    El filtrado ocurre a nivel de base de datos (índices optimizados), no en el servidor de aplicación.

C. Ejemplo Práctico: Double-Blind Matching

Cuando una empresa publica una evaluación:

  1. 1.La evaluación aparece en el marketplace de forma anónima (solo risk_level, category, ai_function son visibles).
  2. 2.Los profesionales ven un feed de 'leads anónimos' pero NO pueden acceder a company_name, system_name o technical_documentation.
  3. 3.Al aplicar a un match, se crea una fila en la tabla matches con status='pending_request'.
  4. 4.Solo cuando la empresa aprueba el match (status='connected'), la vista matches_with_contact_info desvela los datos completos.
  5. 5.Esta lógica está implementada en SQL puro, no en el código de la app (a prueba de bypasses).

3. Autenticación Multi-Factor (MFA)

Soportamos autenticación de dos factores mediante Passkeys (WebAuthn):

  • Passkeys:Estándar FIDO2 para autenticación sin contraseñas (Touch ID, Face ID, YubiKey).
  • Mandatory MFA para Roles Críticos:Los administradores (Superadmin) deben activar MFA obligatoriamente.
  • Backup Codes:Proporcionamos códigos de recuperación encriptados en caso de pérdida de dispositivo.

4. Logs de Auditoría (Compliance GDPR Art. 33)

Registramos automáticamente todas las acciones sensibles en la tabla admin_audit_logs:

Accesos Administrativos

Quién accedió a qué datos, cuándo y desde qué IP.

Cambios en Evaluaciones

Historial completo de modificaciones (antes/después).

Aprobaciones de Matches

Timestamps exactos de cuándo se desveló información sensible.

Retención

Los logs se conservan durante 7 años (requisito GDPR para detección de brechas).

5. Encriptación

En Tránsito:

TLS 1.3 para todas las conexiones (HTTPS, WSS para websockets).

En Reposo:

AES-256 para datos almacenados en Supabase.

Secretos:

Variables de entorno encriptadas en Vercel (nunca hardcodeadas en el código).

6. Infraestructura y Compliance

Nuestro stack tecnológico cumple con estándares de seguridad globales:

ServicioCertificaciones
Vercel (Hosting)SOC 2 Type II, ISO 27001
Supabase (Database)SOC 2 Type II, GDPR compliant, EU servers
Clerk (Authentication)SOC 2 Type II, GDPR compliant
Stripe (Payments)PCI DSS Level 1 (máxima certificación)

8. Incident Response Plan

En caso de brecha de seguridad:

  1. 1.
    Notificación Inmediata:

    Informamos a los usuarios afectados en un plazo de 72 horas (requisito GDPR Art. 33).

  2. 2.
    Análisis Forense:

    Identificamos la causa raíz y documentamos el incidente.

  3. 3.
    Remediación:

    Aplicamos parches y reforzamos las medidas afectadas.

  4. 4.
    Transparencia:

    Publicamos un post-mortem público (sin revelar detalles que puedan ser explotados).

Reportar Vulnerabilidades

Para reportar vulnerabilidades de seguridad, contacta con security@aideal.dev

O usa nuestro canal cifrado PGP (clave pública disponible bajo solicitud).

Security & Row Level Security | aideal.dev