Seguridad técnica, nivel de servicio y certificaciones

1. Arquitectura y aislamiento

Zign opera con arquitectura hexagonal: el núcleo de firma y certificación está desacoplado de los adaptadores de entrada (portal web, API REST, webhooks) y de los adaptadores de salida (Prestador de Servicios de Certificación, almacenamiento, correo, blockchain). Esto permite sustituir proveedores sin cambiar reglas de negocio y contener el impacto de una falla externa.

Las operaciones largas o dependientes de terceros (emisión de constancias, envío de correos, anclaje diario, análisis con IA) se procesan mediante colas con bloqueo por trabajo, reintentos e idempotencia, de modo que un reintento nunca duplica una constancia ni un cargo.

• Multi-tenencia lógica: cada documento, sobre, constancia y llave pertenece a una organización, con jerarquía padre-hijo para grupos corporativos y marca blanca.
• Separación estricta de código cliente y servidor: las credenciales privilegiadas y las llaves de proveedores solo existen en el runtime de servidor, nunca en el navegador.
• Ambientes separados de pruebas (sandbox) y producción, con llaves distintas; sandbox no contacta al PSC real ni consume certificados.

2. Cifrado en tránsito y en reposo

• TLS 1.2+ obligatorio en todos los endpoints públicos, con HSTS y redirección forzada a HTTPS; no se aceptan conexiones en claro.
• Cifrado en reposo AES-256 para base de datos, respaldos y objetos almacenados, administrado por el proveedor de infraestructura.
• Los archivos, PDF sellados y constancias ASN.1 se guardan en almacenamiento privado, sin acceso público por URL; toda descarga se sirve con enlaces firmados de vida corta.
• Los secretos de integración (llaves de PSC, credenciales de correo, llave privada del sello) se almacenan en bóveda de secretos, se inyectan en tiempo de ejecución y no se registran en bitácoras.

3. Control de acceso y autenticación

• Autenticación de usuarios con correo y contraseña o proveedores federados (Google, Apple); contraseñas con hash y política de restablecimiento por token de un solo uso.
• Autorización por roles dentro de cada organización (propietario, administrador, miembro) y roles de plataforma almacenados en tabla independiente, nunca en el perfil del usuario, para evitar escalación de privilegios.
• Seguridad a nivel de fila (RLS) activa en todas las tablas de negocio: cada consulta se evalúa contra la identidad del solicitante y su organización; los datos comerciales sensibles (suscripciones, órdenes de compra, créditos) solo son visibles para propietarios, administradores y la organización superior que los gestiona.
• Firmantes externos acceden por enlace único no adivinable más código de un solo uso (OTP) enviado a su correo, con expiración y número limitado de intentos.
• Registro de cada acceso relevante: emisión, apertura, firma, descarga y revocación quedan en bitácora inmutable.

4. Seguridad de la API

• Autenticación Bearer con llaves cfk_ generadas por organización; se muestran una sola vez y se almacenan como hash, por lo que no pueden recuperarse ni por nuestro equipo.
• Alcances (scopes) mínimos por llave: nom151:read, nom151:write, envelopes:read, envelopes:write; una llave sin el alcance requerido recibe 403.
• Límite de peticiones por minuto y por llave, con respuesta 429 y cabeceras de límite; revocación inmediata desde el backoffice.
• Idempotencia por huella y por clave de idempotencia: reintentar la emisión de la misma constancia no genera duplicados ni doble consumo de certificados.
• Validación estricta de entrada (esquemas, tamaño máximo de 20 MB por archivo, huellas SHA-256 en 64 hexadecimales) y respuestas de error tipificadas sin filtrar detalles internos.
• Webhooks firmados con HMAC-SHA256 sobre el cuerpo crudo, con marca de tiempo y reintentos con retroceso exponencial; el receptor debe verificar la firma antes de procesar.
• Bitácora de peticiones y de entregas de webhook consultable por el cliente en el panel de integraciones.

5. Criptografía de firma, sellado y NOM-151

• Huella SHA-256 calculada al cargar el archivo, al cerrar el sobre y al certificar; cualquier alteración posterior cambia la huella y se detecta en el verificador público.
• Sello institucional con certificado X.509 RSA-2048 y firma RSA-SHA256 (PKCS#1 v1.5) bajo el DN C=MX, O=Codex, OU=Zign, CN=sello.zerozign.com.
• Firma con e.firma del SAT admitida para firma electrónica avanzada, además de firma autógrafa digitalizada con evidencia de sesión.
• Constancia de conservación NOM-151 emitida por Prestador de Servicios de Certificación acreditado (Codex), entregada en formato ASN.1 y validable en línea contra el PSC.
• Colombia: cumplimiento de la Ley 527 y sus decretos sobre mensajes de datos y firma electrónica, con la misma cadena de evidencia técnica.
• Bitácora encadenada: cada evento guarda el hash del evento anterior, de modo que eliminar o alterar un eslabón rompe la cadena y es detectable.

6. Anclaje en blockchain y verificación independiente

• Las huellas de documentos certificados y de eventos de auditoría se agrupan en un árbol Merkle diario.
• La raíz diaria se ancla en la cadena de Bitcoin mediante OpenTimestamps; se conserva la prueba .ots y la ruta Merkle de cada hoja.
• Cualquier tercero puede verificar por su cuenta con el archivo o su huella en el verificador público, sin cuenta ni credenciales, y contrastar el bloque en un explorador independiente.
• La verificación no depende de que Zign exista: la prueba criptográfica es autocontenida.

7. Continuidad, respaldos y failover de proveedores

• Respaldos automáticos diarios de base de datos con recuperación a un punto en el tiempo y retención acorde al plan contratado.
• Almacenamiento de objetos con redundancia gestionada por el proveedor de infraestructura.
• Modelo multiproveedor con failover para certificación y correo transaccional: si un proveedor no responde, la operación queda en cola como pendiente y se reintenta o se reencamina, sin perder la firma ya realizada.
• Objetivos de recuperación: RPO ≤ 24 h y RTO ≤ 8 h para el servicio completo; las constancias ya emitidas son inmutables y recuperables desde el respaldo y desde el propio PSC.
• Degradación controlada: una falla del PSC no bloquea el cierre del sobre; el archivo queda marcado como pendiente de certificación y se certifica al restablecerse el servicio.

8. Nivel de servicio (SLA)

• Disponibilidad objetivo de la plataforma y de la API: 99.9 % mensual, excluyendo ventanas de mantenimiento anunciadas y fallas atribuibles a terceros del cliente.
• Ventanas de mantenimiento programado notificadas con al menos 48 horas de anticipación, preferentemente fuera de horario laboral de México y Colombia.
• Tiempos de respuesta de soporte: crítico (servicio caído) 2 horas hábiles; alto (funcionalidad degradada) 4 horas hábiles; medio 1 día hábil; bajo 3 días hábiles.
• Latencia objetivo de la API: p95 por debajo de 800 ms en operaciones de lectura y por debajo de 3 s en emisión de constancia, sujeta al tiempo de respuesta del PSC.
• Entrega de webhooks con reintentos durante 24 horas y bitácora consultable de cada intento.
• Notificación de incidentes de seguridad con impacto en datos del cliente dentro de las 72 horas siguientes a su confirmación.
• Los compromisos contractuales definitivos, créditos por incumplimiento y horarios de cobertura se formalizan en el contrato de servicio de cada cliente.

9. Certificaciones de la infraestructura y proveedores

Zign no opera centros de datos propios: se ejecuta sobre proveedores de nube con certificaciones internacionales vigentes. La certificación aplica a la capa de infraestructura y servicios administrados que utilizamos, y podemos entregar los reportes públicos de cada proveedor bajo solicitud.

• Cómputo y red de borde: SOC 1 / SOC 2 Tipo II, SOC 3, ISO/IEC 27001, 27017 y 27018, PCI DSS y adhesión al RGPD.
• Base de datos, autenticación y almacenamiento administrados: SOC 2 Tipo II, ISO/IEC 27001, cifrado en reposo AES-256, respaldos y recuperación a un punto en el tiempo, y HIPAA disponible en planes empresariales.
• Certificación NOM-151: Prestador de Servicios de Certificación acreditado ante la Secretaría de Economía de México, con constancias de conservación de mensajes de datos.
• Correo transaccional: proveedor con SOC 2 y dominios autenticados con SPF, DKIM y DMARC.
• Anclaje temporal: OpenTimestamps sobre la cadena pública de Bitcoin, verificable de forma independiente.
• Bajo acuerdo de confidencialidad entregamos la matriz de proveedores, subprocesadores, ubicación de datos y los reportes de certificación correspondientes.

10. Privacidad y tratamiento de datos

• Cumplimiento de la LFPDPPP (México) y de la Ley 1581 de 2012 (Colombia); avisos de privacidad publicados y actualizados.
• Minimización: solo se recaban los datos necesarios para la firma y su evidencia; los correos de firmantes se muestran enmascarados en la verificación pública.
• Los documentos del cliente son propiedad del cliente; no se usan para entrenar modelos de terceros. El análisis con IA se ejecuta sobre proveedores sin retención de datos para entrenamiento.
• Retención y borrado configurables por organización; la evidencia criptográfica (huellas y constancias) puede conservarse aun tras eliminar el archivo, para sostener la validez legal.
• Localización: los datos se procesan en regiones de nube de Norteamérica salvo que el contrato indique otra región.

11. Desarrollo seguro y gestión de vulnerabilidades

• Revisión de código, análisis estático y escaneo de dependencias en cada cambio; despliegues versionados con posibilidad de reversión.
• Escaneo periódico de configuración de base de datos y políticas de acceso, con seguimiento formal de hallazgos hasta su cierre.
• Principio de mínimo privilegio para el acceso del equipo interno, con autenticación multifactor obligatoria y registro de actividad administrativa.
• Pruebas de penetración de terceros disponibles como servicio adicional para clientes empresariales; el resumen ejecutivo se comparte bajo acuerdo de confidencialidad.

12. Contacto para equipos de seguridad

Reportes de vulnerabilidad y cuestionarios de seguridad: seguridad@zerozign.com. Solicitudes contractuales, acuerdos de tratamiento de datos y evidencia de certificaciones: legal@zerozign.com. Te pedimos no acceder a datos de terceros ni degradar el servicio durante cualquier prueba, y darnos un plazo razonable de remediación antes de una divulgación pública.