Cómo protegemos los datos de su bufete

Los bufetes manejan datos del más alto nivel de sensibilidad: secreto profesional, datos personales de clientes, comunicaciones privilegiadas, estrategias procesales. JurisRD se construyó desde el primer día con esa realidad en mente. Esta página describe nuestra postura técnica y operativa.

1. Cifrado

En tránsito

• TLS 1.3 obligatorio en todas las conexiones externas (HTTP rechazado en producción)
• HSTS con preload, max-age de dos años, includeSubDomains
• Política de seguridad de contenido (CSP) estricta en las páginas públicas

En reposo

• Base de datos PostgreSQL cifrada con AES-256 a nivel de Supabase
• Almacenamiento de archivos (documentos del Cliente) cifrado a nivel de Supabase Storage
• Respaldos diarios cifrados con AES-256-GCM usando claves derivadas mediante HKDF-SHA256 con salt rotativo por fecha; clave maestra bajo control exclusivo de Dren Group, no almacenada en infraestructura compartida

2. Aislamiento de datos por bufete

Toda tabla con datos del Cliente lleva una columna firm_id y está protegida por Row-Level Security (RLS) a nivel de PostgreSQL. Las políticas RLS se ejecutan en el motor de base de datos, no en el código de aplicación, por lo que no es posible sortearlas mediante una vulnerabilidad en la capa web.

Cada miembro del bufete inicia sesión con su propio enlace mágico (passwordless), y solo puede acceder a datos del bufete del que es miembro activo. La verificación de membresía ocurre en cada llamada API.

3. Control de acceso

Para usuarios del Cliente

• Autenticación passwordless mediante enlace mágico de un solo uso (Supabase Auth)
• Roles granulares: dueño, administrador, abogado, paralegal, personal, solo-lectura
• Capacidades específicas por miembro (enviar cartas, ver facturación, gestionar usuarios, etc.)
• Solo el dueño puede asignar el rol de "administrador". Los administradores pueden invitar a otros miembros con roles inferiores.
• No se permite eliminar al último dueño del bufete (protección contra lock-out)

Para personal de Dren Group

• Acceso al sistema únicamente para personal autorizado y por necesidad operativa documentada
• Autenticación de dos factores obligatoria en Supabase, Cloudflare, Netlify, GitHub, Stripe
• Llaves de servicio rotadas trimestralmente
• Toda acción administrativa registrada en bitácora con marca de tiempo, identidad y dirección IP

4. Bitácora de auditoría

Cada acción material sobre un expediente —creación, edición, nota, generación con IA, envío de carta, carga o eliminación de documento, registro de comparecencia, cambio de rol de miembro, modificación de cuenta bancaria, eliminación— se registra en la tabla case_activity_log con identidad del actor, marca de tiempo, recurso afectado y descripción. La bitácora es inmutable para usuarios del Cliente y se conserva según el plan contratado (90 días a 7 años).

5. Respaldos cifrados

• Snapshot completo de la base de datos cada noche a las 03:00 UTC
• Cifrado con AES-256-GCM, clave por bufete derivada mediante HKDF
• Almacenamiento en Cloudflare R2 (jurisdicción Estados Unidos, ENAM)
• Bitácora pública del estado de cada respaldo en la tabla backup_log (solo visible para administradores de plataforma de Dren Group)
• Pruebas de restauración cada 90 días contra un proyecto de prueba aislado, documentadas en docs/DR-DRILLS.md
• Procedimiento de restauración completo documentado en restore-from-backup.md (entregable a auditores bajo NDA)

6. Modelo de amenazas y limitaciones de mitigación

Lo que defendemos

• Acceso no autorizado a datos de otro bufete (vía RLS)
• Acceso por personas externas a través de la red (vía TLS + WAF + autenticación)
• Pérdida de datos por fallo de hardware (vía respaldos diarios cifrados externos)
• Lectura de respaldos por el proveedor de almacenamiento (vía cifrado del lado del cliente con clave bajo nuestro control)
• Inyección SQL clásica (vía consultas parametrizadas en todas las operaciones)
• Cross-site scripting (vía escape de HTML estricto, CSP)
• Cross-site request forgery (vía verificación de JWT en cada llamada API)
• Abuso del periodo de prueba (vía huella digital del dispositivo + dirección IP + correo, dedupe estricto)

Lo que no podemos defender

• Comprometimiento del dispositivo del usuario (su correo personal, su Mac, su navegador): si un atacante controla el dispositivo del usuario, puede obtener acceso vía el enlace mágico legítimo
• Errores deliberados o negligentes del personal del Cliente (ej. compartir el enlace de portal del cliente con la persona equivocada)
• Vulnerabilidades zero-day en sub-encargados de los que dependemos (Supabase, Cloudflare, etc.) — mitigamos seleccionando proveedores con programa de seguridad maduro y certificaciones SOC 2
• Decisiones legales o judiciales que obliguen a entregar datos en jurisdicción donde se almacenan los datos (Estados Unidos). Recurriremos cuando sea posible y notificaremos al Cliente cuando la ley lo permita.

7. Respuesta a incidentes

1. Detección. Monitoreo continuo de logs de aplicación y de infraestructura. Alertas automáticas en eventos anómalos.
2. Contención. Aislamiento del incidente; rotación de credenciales comprometidas; restricciones temporales si aplica.
3. Notificación al Cliente. Si una brecha afecta Datos del Cliente: notificación dentro de las 72 horas siguientes al conocimiento, conforme al DPA.
4. Notificación a autoridades. Dren Group asistirá al Cliente en sus obligaciones ante la Autoridad de Datos correspondiente.
5. Análisis y remediación. Causa raíz documentada; medidas correctivas implementadas; lecciones aprendidas registradas y compartidas con el Cliente si aplica.

8. Divulgación responsable (Responsible Disclosure)

Agradecemos el reporte responsable de vulnerabilidades. Si usted ha descubierto una falla de seguridad en JurisRD:

• Contacto: security@dren.group
• Pretendemos responder dentro de 5 días hábiles
• Pretendemos remediar vulnerabilidades de severidad alta en menos de 30 días
• No demandaremos ni perseguiremos legalmente a investigadores que actúen de buena fe, sin acceder a datos de Clientes y sin causar daño
• Reconocimiento público en esta página si así lo desea el reportante

9. Cumplimiento

• Ley 172-13 (República Dominicana, Protección Integral de Datos Personales): cumplimiento integral. Sub-procesadores declarados. Garantías de transferencia internacional documentadas.
• GDPR (Unión Europea): para clientes europeos, SCC firmadas con sub-encargados, DPA disponible, derechos del titular respetados.
• SOC 2 Type II: en proceso de adquisición; aplicaremos formalmente una vez que tengamos cuatro bufetes en producción.
• HIPAA: no aplicable a nuestro caso de uso (no procesamos información de salud protegida).

10. Sub-encargados con certificación de seguridad

Para preguntas técnicas detalladas, cuestionarios de seguridad de su departamento de IT, o solicitud del reporte SOC 2 más reciente de nuestros sub-encargados, escriba a security@dren.group.