ARDNTECH | Threat model público

Metodología: STRIDE (Spoofing / Tampering / Repudiation / Information disclosure / Denial of service / Elevation of privilege) aplicada a cinco superficies del producto. Cada línea: amenaza - mitigación ARDNTECH - trade-off asumido.

Documento destinado a los CISO, auditores e investigadores de seguridad. El código fuente AGPL es público en github.com/aegirex/server. Los runbooks operativos detallados quedan reservados a los design partners bajo NDA.

1. Actores modelados

Los nueve perfiles de atacante considerados en el modelo.

Actor	Descripción	Capacidades
Atacante externo	Internet, sin acceso inicial	Fuerza bruta, phishing, exploits web, MITM de red
Usuario víctima de phishing	Usuario objetivo de un sitio clon	Envía sus credenciales a un dominio atacante
Coinquilino malicioso	Usuario de otra organización ARDNTECH	Intenta leer los secretos de organizaciones vecinas
Navegador comprometido	Navegador infectado por malware o extensión maliciosa	Acceso al DOM, puede leer los campos de entrada
Administrador de servidor	Operador de infraestructura con acceso SSH al servidor	Lee la base de datos, lee la memoria, modifica el código
Exfiltración de base de datos	Backup robado, dump SQL filtrado	Snapshot completo de la base de datos
Autoridad judicial	Requerimiento legal, mandato administrativo	Obliga al proveedor de alojamiento a entregar los datos almacenados
Insider ARDNTECH	Empleado o proveedor futuro de ARDNTECH	Revisión de código, acceso al despliegue, lectura de los logs
Adversario cuántico	Ordenador cuántico operativo (horizonte > 2030)	Rompe RSA / ECC en tiempo polinómico (Shor)

2. Datos protegidos

Clasificación de los datos y nivel de protección en reposo.

Dato	Sensibilidad	Almacenamiento
Contraseña maestra del usuario	Crítica	Hash Argon2id únicamente (RFC 9106)
Contenido de los secretos (payload)	Crítica	Cifrado de extremo a extremo (OpenPGP), el servidor almacena un blob opaco
Clave privada OpenPGP del usuario	Crítica	Nunca en el servidor. Almacenada localmente, protegida por una passphrase del usuario
Secretos TOTP en reposo	Crítica	Cifrados con XChaCha20-Poly1305 (clave fuera de la base de datos)
Secretos webhook en reposo	Crítica	Cifrados con XChaCha20-Poly1305 (clave fuera de la base de datos)
Nombres de secretos y de carpetas	Moderada	En claro en el lado del servidor. Trade-off documentado 5.1
Registro de auditoría	Elevada	Cadena HMAC-SHA-256, tamper-evidence en O(1)

3. Amenazas y mitigaciones por superficie

3.1 Aplicación web SaaS

Amenaza	Mitigación	Estado
Fuerza bruta sobre la contraseña	Rate limiter de 5 intentos / 15 min por IP + Argon2id (256 MiB, 5 pasadas) - 1 s por intento local	Entregado
Credential stuffing	Mismo rate limiter + escaneo HIBP opt-in tras el login (consentimiento RGPD explícito)	Entregado
Bypass de 2FA	TOTP RFC 6238 con issuer pinning + códigos de recuperación de un solo uso + WebAuthn PRF	Entregado
XSS almacenado o reflejado	CSP estricta (script-src 'self' 'wasm-unsafe-eval'), Trusted Types activados, escapado automático Twig	Entregado
Compromiso de la dependencia OpenPGP.js	Biblioteca vendorizada con huella SHA-256 verificada en el build (manifiesto de integridad SRI)	Entregado
Phishing de la contraseña maestra	Mitigación fuerte próximamente: passkeys WebAuthn PRF, que eliminan la transmisión de la contraseña y están vinculadas al dominio de origen por el navegador. Mientras tanto: formación de usuarios + indicadores UI.	Próximamente

3.2 Almacenamiento cifrado

Amenaza	Mitigación	Estado
Dump de la base de datos robado	Payload cifrado OpenPGP E2E ilegible sin la clave privada del usuario. Contraseñas en hash Argon2id no recuperables	Entregado
Backup robado	Backups cifrados (Argon2id + ChaCha20-Poly1305), multidestinatario. Prueba de restauración automatizada en CI	Entregado
El administrador de servidor lee el contenido de un secreto	Imposible sin la clave privada del usuario. El servidor solo almacena blobs opacos	Entregado
Alteración del registro de auditoría (tampering)	Cadena HMAC-SHA-256, detección en O(1) en la verificación. Detalle de la cadena	Entregado

3.3 API REST

Amenaza	Mitigación	Estado
Fuga de datos entre organizaciones	Cada token API vinculado a una organización única. Filtrado sistemático en cada endpoint. Pruebas de aislamiento explícitas en CI en cada commit	Entregado
Robo de token API	Token con hash Argon2id en base de datos. Rotación libre por parte del usuario. Scope mínimo (lectura / escritura) configurable	Entregado
Denegación de servicio a nivel de aplicación	Rate limiter por token y por IP (framework Symfony)	Entregado

3.4 Extensiones de navegador

Amenaza	Mitigación	Estado
Compromiso del pipeline de build	Verificación de la huella SHA-256 de las dependencias encadenada al build. SBOM firmado planificado	Entregado
Cierre del popup = pérdida temporal de acceso	Compromiso de la primera versión: la clave privada no se persiste para limitar la superficie de ataque. Próximamente: auto-bloqueo configurable + persistencia mediante service worker controlado.	Próximamente
Captura de credenciales en un sitio de phishing	El usuario ve el nombre de dominio real en el popup de la extensión antes de hacer clic en «Guardar»	Entregado

3.5 Infraestructura auto-alojada

Amenaza	Mitigación	Estado
Imagen Docker comprometida	Escaneo de vulnerabilidades automatizado en CI. Firma Sigstore planificada para la verificación por el usuario en el despliegue	En curso
Backup sin probar	Prueba de restauración automatizada en CI en cada release. Ningún backup sin verificar en producción	Entregado
mTLS en producción	Activable por configuración. Modos de auditoría (solo logs) y luego de enforcement disponibles	Entregado

4. Perímetro de protección - límites asumidos

Honestidad editorial: estas son las superficies que ARDNTECH no cubre por sí solo, y la mitigación recomendada.

Límite	Por qué	Mitigación recomendada
Compromiso completo del equipo del usuario	Un malware con acceso a la RAM del navegador puede leer la clave privada descifrada	Passkey hardware (YubiKey, TPM) que confina la clave en un elemento seguro
Compromiso del servidor ARDNTECH (root)	Un atacante con privilegios root puede leer las sesiones HTTP activas	Los secretos almacenados permanecen ilegibles (zero-knowledge). Solo las sesiones abiertas en el momento del compromiso están en riesgo. Se recomienda un auto-bloqueo corto
Pérdida de la contraseña maestra	Consecuencia directa del zero-knowledge estricto: ningún medio del lado del servidor para recuperar la clave	Códigos de recuperación impresos en la creación. Próximamente: reparto Shamir M-de-N para los planes Enterprise
Adversario cuántico (horizonte > 2030)	OpenPGP v6 + AES-256 se estiman seguros entre 5 y 10 años según el RGS ANSSI 2024	Migración post-cuántica (ML-KEM, ML-DSA) en evaluación a largo plazo
Ataque físico sobre el equipo del usuario	ARDNTECH es una bóveda lógica, no una bóveda física	Auto-bloqueo corto de la bóveda + passkey WebAuthn de hardware
Insider ARDNTECH (futuro empleado)	Límite asumido del modelo de confianza del editor SaaS	NDA, separación de responsabilidades, revisión de código obligatoria, cadena de auditoría tamper-evident, principio del mínimo privilegio

5. Compromisos asumidos

5.1 Nombres de secretos y de carpetas en claro del lado del servidor

Elección: nombres almacenados en claro del lado del servidor.

Por qué: búsqueda instantánea del lado del servidor, visualización del árbol sin descifrado en cada navegación, posibilidad de compartir carpetas de forma jerárquica.

Impacto: un atacante que exfiltre la base de datos ve que existe un secreto llamado «AWS Prod» en la carpeta «DevOps / Cloud». NO ve el contenido (payload cifrado E2E).

Alternativa considerada: opción «anonymise me» que cifra también los nombres. Coste de UX significativo: sin búsqueda del lado del servidor, escaneo completo del lado del cliente en cada petición.

5.2 Contraseña en claro en el DOM durante la introducción

Elección: OpenPGP cifra el payload después de que el usuario haya escrito su contraseña.

Por qué: no hay alternativa - el navegador debe ver el texto en claro para permitir que el usuario lo introduzca.

Mitigaciones: Trusted Types CSP impide que el DOM XSS inyecte JavaScript de exfiltración. Próximamente: passkeys WebAuthn que eliminan por completo la transmisión de contraseñas.

5.3 Contraseña maestra = única clave de la bóveda

Elección: no hay recuperación si el usuario pierde tanto su contraseña maestra COMO sus códigos de recuperación.

Por qué: zero-knowledge estricto. Si pudiéramos recuperarla, existiría una ruta de descifrado del lado del servidor.

Mitigación próximamente: reparto Shamir de la clave privada (M-de-N partes), una parte en ARDNTECH con salvaguardas procedimentales (desbloqueo únicamente con la presencia de N-1 otras partes validada por el usuario). Reservado a los planes Enterprise.

6. Plan de respuesta a incidentes

Nivel	Desencadenante	Acción
L1 Sospecha	Anomalía en el registro de auditoría, notificación de usuario	Investigación interna en menos de 24 h, verificación de la cadena de auditoría
L2 Compromiso confirmado	Compromiso técnico confirmado por la investigación	Notificación a los usuarios en menos de 72 h (RGPD Art. 33), rotación de las claves afectadas, implementación de mitigaciones
L3 Compromiso grave	Base de datos o código fuente comprometidos	Notificación a la CNIL y la ANSSI, transparency report público, auditoría forense externa

Divulgación responsable: Conforme a la RFC 9116, un archivo /.well-known/security.txt en la raíz del sitio indica nuestra dirección de contacto security@aegirex.eu. Plazo de acuse de recibo: 72 h.

¿Precisar el documento?

Este threat model es un documento vivo. Si usted es RSSI, auditor o investigador en seguridad y considera que una amenaza está mal modelada, contáctenos directamente.

Matriz claims/pruebas security@aegirex.eu

Threat model <em>público.</em>