Ciberseguridad

Una credencial vale lo que vale su verificación. Nuestro compromiso es que una credencial emitida en OpenChapitas se pueda comprobar años después, sin depender de que la institución emisora siga existiendo ni de que alguien conteste un correo — y que nadie, tampoco nosotros, pueda alterarla sin que se note.

• Firma híbrida exigida. Cada credencial lleva dos firmas sobre los mismos bytes: Ed25519 (clásica) y ML-DSA-65 (post-cuántica, NIST FIPS 204). Si falta o falla cualquiera de las dos, la credencial se declara inválida: no hay degradación silenciosa a solo-clásica.
• Alterar un solo carácter rompe ambas pruebas. Corregir un dato exige volver a firmar el documento; no existe forma de editarlo en silencio.
• Las claves privadas no viven en la aplicación. Se custodian en un gestor de secretos y la firma se delega a él. La verificación es local con las claves públicas y no depende de nuestros servidores.
• Revocación pública. El estado se publica en una lista verificable: revocar no borra la historia, la deja constatable.

Cada emisor solo ve lo suyo, y eso lo impone el motor de base de datos con seguridad a nivel de fila, no una condición en el código. El servicio se conecta con un rol sin privilegios para saltársela. Un error de programación no puede, por sí solo, mostrarle a una academia los datos de otra.

• El origen no es alcanzable desde internet. El servidor solo acepta tráfico web desde los rangos publicados de Cloudflare; una petición directa a su dirección no completa siquiera la conexión. La lista se sincroniza sola cada semana.
• Superficie mínima. Base de datos, gestor de secretos y servicios internos no están expuestos: viven en redes privadas alcanzables solo desde la propia plataforma. IPv6 está apagado en el origen.
• Acceso administrativo solo con llave. No se acepta autenticación por contraseña, con bloqueo automático de intentos abusivos.
• Límites de uso. Se aplican límites por dirección real del visitante, con margen para ráfagas legítimas, y límites más estrictos en las operaciones que consumen más recursos.
• Cabeceras y contenido. TLS en todo el trayecto, política de contenido sin unsafe-inline, y páginas de credencial marcadas noindex.

Los respaldos se cifran antes de tocar el disco, con criptografía de clave pública: el servidor puede crearlos pero no descifrarlos, porque la clave privada se custodia fuera de él. Restaurar es una operación deliberada que exige aportar esa llave.

Y se ensayan: la restauración se prueba sobre una base efímera, verificando que los datos vuelven completos y midiendo cuánto tarda. Un respaldo que nunca se probó no es un respaldo.

Ningún cambio del componente que firma llega a producción sin pasar una batería de pruebas automatizadas que corre antes de cada despliegue, e incluye pruebas de manipulación: se altera deliberadamente una credencial y se comprueba que la verificación la rechaza. El frontend se despliega en caliente, con una réplica de respaldo que atiende mientras la otra se actualiza.

Si encuentras un problema de seguridad, escríbenos a cyber@ttpsec.com. Nuestro canal está publicado según RFC 9116 en /.well-known/security.txt.

Te pedimos que nos des un plazo razonable para corregir antes de divulgar, y que no accedas a datos de terceros ni degrades el servicio durante tus pruebas. A quien reporta de buena fe y respeta eso, no lo perseguimos: lo agradecemos.

• No ponemos CAPTCHA en la verificación. Comprobar una credencial debe ser posible sin cuenta, sin registro y sin fricción: es la promesa del producto.
• No bloqueamos por navegador ni por identificador de cliente. Se falsifica en un segundo y deja fuera a lectores de pantalla y a las vistas previas de los mensajeros.
• No usamos analítica de terceros ni píxeles en los correos.

Responsable: TTPSEC SpA (Chile, ttpsec.cl). Seguridad: cyber@ttpsec.com. Para asuntos de datos personales, la Política de Protección de Datos Personales.

Esta política se revisa al menos una vez al año y tras cualquier incidente o cambio relevante de arquitectura.