Architecture overview

Política de Seguridad

Última actualización: 30 de abril de 2026 · Versión: 1.0

NEXXUS Legal está construido desde el primer commit con el principio zero-knowledge: ni nuestros ingenieros, ni nuestro CEO, ni un atacante con acceso al servidor pueden leer el contenido legal de tu despacho. Esta página resume las medidas técnicas y organizativas (TOMs) que sostienen esa promesa.

E2EE real

libsodium · XChaCha20-Poly1305 · Argon2id 64MB

Shamir 3-de-2

Recuperación con 2 de 3 piezas que tú custodias

Audit log Ed25519

Hash chain inmutable, replicado WORM en B2

Multi-tenant RLS

PostgreSQL Row-Level Security por despacho

1. Cifrado end-to-end (E2EE)

1.1 Las tres capas

NEXXUS distingue tres tipos de datos y los protege con criptografía distinta:

CapaAlgoritmoCustodio de la claveEjemplos
MetadataAES-256-GCMNEXXUS (DEK rotada)Índices, búsquedas, contadores
PIICMEK · HSMNEXXUS (HSM dedicado)Email, RUC, teléfono
Contenido legalXChaCha20-Poly1305 (libsodium)Solo el despachoDocumentos, notas, audio, casos

1.2 Derivación de la clave maestra

La master key del despacho se deriva de la contraseña del admin con Argon2id:

Argon2id (
  memoria  = 64 MiB,
  iter     = 3,
  paralelismo = 4,
  salt     = 16 bytes random por despacho
)
→ master_key (32 bytes)

Estos parámetros equivalen a OWASP "high security" 2024. La master key NUNCA viaja al servidor sin estar cifrada por una clave de sesión efímera.

1.3 Implementación cliente

2. Recuperación con Shamir's Secret Sharing 3-de-2

La contraplomadía del E2EE es: si pierdes la contraseña, nadie puede recuperar tus datos. Para no convertir esto en una bomba, NEXXUS divide la master key con Shamir's Secret Sharing:

2.1 Custodia recomendada

PiezaDónde guardarla
1 — "casa"Caja fuerte personal del admin del despacho
2 — "oficina"Caja fuerte de la oficina + custodia notarial
3 — "abogado de confianza"Custodiada por un colega o familiar de confianza

NEXXUS NO almacena ninguna pieza. Si pierdes 2 de las 3, los datos cifrados son irrecuperables — incluso para nosotros.

2.2 Acceso de emergencia (rotura-de-cristal)

Para escenarios extremos (fallecimiento del admin, secuestro de claves), existe un protocolo opt-in:

3. Audit log Ed25519 hash chain

Cada acción significativa (login, lectura de caso, edición, exportación, cambio de permisos) se registra en una bitácora inmutable.

3.1 Hash chain

entry_n = {
  timestamp,
  tenant_id,
  actor_id,
  event_type,
  payload,
  prev_hash = SHA-256(entry_{n-1}),
  signature = Ed25519_sign(entry_n_sin_signature)
}

Cada entrada referencia el hash de la anterior. Cualquier modificación retroactiva rompe la cadena y la verificación falla.

3.2 Replicación WORM

El audit log se replica cada 6 horas a Backblaze B2 con Object Lock Compliance Mode:

3.3 Verificabilidad

El despacho puede descargar el audit log completo + la clave pública Ed25519 y validar la integridad con nexxus-audit-verify (script open-source). El log es admisible como prueba documental en juicio.

4. Aislamiento multi-tenant (PostgreSQL RLS)

Cada despacho es un tenant aislado a nivel de base de datos:

5. Almacenamiento y backups

5.1 Hosting

5.2 Backups

6. Compliance LOPDP Ecuador

NEXXUS cumple íntegramente la Ley Orgánica de Protección de Datos Personales del Ecuador (LOPDP, R.O. Suplemento 459 de 2021) y su Reglamento (Decreto Ejecutivo 904 de 2023):

7. Autenticación y control de acceso

8. Procesos de desarrollo seguro

9. Sub-procesadores

NEXXUS usa sub-procesadores cuidadosamente seleccionados — todos vinculados por DPA. Lista completa y compromisos en el documento DPA NEXXUS § 7.

10. Reportar vulnerabilidades

Si descubres una vulnerabilidad en NEXXUS, agradecemos tu colaboración responsable:

Esta política se actualiza cuando cambia la arquitectura. Versiones anteriores conservadas en el audit log público del proyecto. Aprobado por: Dr. Alejandro Sánchez Muñoz — DPO & Representante legal · DESPACHO LEGAL AXSM S.A.S.