Modelo de seguridad

ZetiSecret es una herramienta para compartir secretos de un solo uso. El objetivo central es que el servidor nunca vea el secreto en claro, incluso ante un compromiso parcial de la infraestructura.

Principios de diseño

• El servidor no recibe secretos en claro ni claves privadas.
• La clave de descifrado viaja únicamente en el fragmento #… de la URL y nunca llega al servidor.
• Los secretos son de un solo uso: se borran de la base de datos en el momento de la lectura.
• Los secretos caducados se eliminan automáticamente.
• Los logs nunca contienen secretos, passphrases, claves privadas ni fragmentos de URL.
• Las funciones administrativas están protegidas por IP y auditadas.

Criptografía

Todo el cifrado ocurre en el navegador del remitente usando WebCrypto API, sin dependencias externas de cifrado.

Datos guardados en base de datos

La tabla secrets almacena únicamente:

• id — identificador opaco del secreto
• ciphertext — secreto cifrado con AES-GCM
• iv — nonce AES-GCM (96-bit aleatorio)
• public_key — clave pública ECDH del par efímero
• passphrase_hash — verificador PBKDF2 (si aplica)
• passphrase_salt — salt PBKDF2 (si aplica)
• passphrase_iterations — iteraciones PBKDF2
• failed_attempts — contador de intentos fallidos
• locked_until — bloqueo temporal anti-fuerza-bruta
• created_at, expires_at — metadatos de ciclo de vida

Flujo de lectura

1. El destinatario abre la URL /s/:id#clave_privada_ecdh en su navegador.
2. El navegador extrae la clave privada del fragmento #…. Este fragmento no se envía al servidor.
3. Si el secreto tiene passphrase, el navegador solicita al usuario que la introduzca y deriva el verificador localmente con PBKDF2.
4. El backend valida la passphrase (si aplica), comprueba caducidad y estado de bloqueo.
5. Si todo es correcto, borra la fila de la base de datos dentro de una transacción atómica (un solo uso garantizado).
6. Devuelve ciphertext, iv y public_key al navegador.
7. El navegador realiza el intercambio ECDH, deriva la clave AES y descifra localmente. El texto nunca abandona el dispositivo del destinatario en claro.

Controles técnicos activos

Transporte y red

• HTTPS obligatorio — redirección automática de HTTP.
• Backend escuchando solo en 127.0.0.1 detrás de proxy inverso (App Service / Nginx).
• PostgreSQL accesible únicamente desde la subred de aplicación (VNet privado).

Aplicación

• Rate limiting global (todas las rutas) y específico en endpoints sensibles (creación, lectura de secreto).
• Bloqueo temporal progresivo por intentos fallidos de passphrase (configurable, por defecto 5 intentos / 15 min).
• Limpieza automática de secretos caducados en cada ciclo de mantenimiento.
• Endpoint de mantenimiento protegido por token bearer.
• Cache-Control: no-store en todas las respuestas de la API.
• Cabeceras de seguridad via Helmet: CSP estricta sin unsafe-inline, HSTS, X-Frame-Options, etc.

Operaciones

• Panel HQ (/hq) restringido por IP — no accesible desde internet público.
• Logs JSON estructurados: nunca contienen secretos, passphrases, claves ni URLs completas de secretos.
• Certificado TLS renovado automáticamente con Let's Encrypt (ECC secp384r1).
• Dependencias auditadas periódicamente con npm audit.

Limitaciones actuales

• Sin revisión criptográfica externa (pentest / auditoría formal pendiente).
• Sin SAST/DAST continuo en CI.
• Sin modelo multiusuario con RBAC granular (en roadmap enterprise).
• Sin SSO/SAML/OIDC para empresas (en roadmap).
• Sin política formal escrita de retención y borrado.
• Sin programa de bug bounty público.

Roadmap de seguridad

Cumplimiento normativo: ENS e ISO 27001

Cada componente técnico de ZetiSecret está diseñado para satisfacer controles concretos del Esquema Nacional de Seguridad (RD 311/2022) y de ISO/IEC 27001:2022. La siguiente tabla resume los controles directamente satisfechos por la arquitectura del producto.