Política de seguridad de la información

• Mínimo privilegio: cada componente accede solo a lo suyo y nada más.
• Denegar por defecto: si un permiso no está concedido de forma explícita, no existe.
• Defensa en profundidad: ninguna protección depende de una sola capa.
• Degradar antes que exponer: si falta una credencial, la función se apaga; nunca se abre el dato.
• Honestidad operativa: preferimos declarar un límite a insinuar una garantía que no podemos sostener.

• Todo el tráfico viaja por HTTPS con TLS. No hay endpoints en texto plano.
• Los archivos se almacenan cifrados en reposo por el proveedor de almacenamiento.
• La base de datos está gestionada por un proveedor que cifra en reposo y exige conexión cifrada.
• Las credenciales de las integraciones se cifran con AES-256-GCM antes de guardarse; el modo autenticado detecta cualquier alteración del dato cifrado.
• Las llaves de la API se guardan solo como resumen criptográfico de una vía: el secreto real no queda almacenado en ningún lado y se muestra una única vez.

• El permiso solicitado es de solo lectura. No se pide, en ningún momento, capacidad de enviar, modificar o borrar correo.
• El flujo de autorización usa PKCE y un parámetro de estado cifrado y autenticado: un intento manipulado no llega a completarse.
• Los tokens se guardan cifrados, cuelgan del negocio y no de una sesión, y nunca se exponen en respuestas de la API ni se escriben en registros.
• El token de acceso se renueva solo cuando hace falta, no en un ciclo fijo, para reducir la ventana de uso.
• Si el permiso se rompe —porque lo revocaste o cambiaste tu contraseña— la conexión pasa a “requiere atención” y deja de leer, en vez de reintentar en silencio.
• Solo se procesan los mensajes cuyo remitente pertenece al catálogo de bancos; el resto se descarta sin almacenarse.

• Almacenamiento privado, con acceso público bloqueado en todos sus niveles y versionado activo.
• La subida va directo al almacenamiento con un permiso firmado de corta duración, y el servidor confirma después que el objeto existe de verdad antes de darlo por válido.
• La lectura NO se hace con enlaces firmados: un enlace firmado es un portador y quien lo tenga lo usa desde donde sea. Los archivos se sirven a través de la plataforma, revalidando sesión y permisos en cada petición.
• El visor pinta el archivo en memoria dentro de la pestaña: no queda una dirección que copiar ni compartir.
• Los tipos de archivo aceptados están definidos en el código, no en un panel de configuración: es superficie de ataque, no una palanca de negocio.
• Las descargas de archivos remotos validan el destino contra redes internas y metadatos de la nube, con topes de tiempo, tamaño y tipo.

• Permisos por rol dentro de cada negocio, evaluados en cada petición y denegados por defecto.
• Una persona puede pertenecer a varios negocios; los datos de uno nunca son visibles desde otro.
• Las acciones administrativas quedan registradas en una bitácora de auditoría con autor, momento y motivo.
• El acceso del equipo de Verifika a datos de un negocio está restringido, es para soporte y queda auditado.
• Las credenciales de integración se pueden rotar y revocar en cualquier momento, y tienen límite de peticiones por credencial.

Es la regla que sostiene el valor del producto y por eso está escrita en el sistema, no en un manual:

• El estado “verificado por banco” solo lo escribe el sistema a partir de un mensaje real recibido de una entidad del catálogo. Ningún usuario, ni siquiera el dueño, puede declararlo.
• Un pago registrado por el bot o por la API nace pendiente, nunca verificado.
• Los registros que entran por integración son inmutables desde el panel.
• Los mensajes entrantes se autentican por firma antes de procesarse; uno sin firma válida se rechaza.
• La detección de duplicados se hace por negocio y por referencia, para que un mismo comprobante no sirva dos veces en dos turnos o sucursales.

• Tres ambientes separados —desarrollo, pruebas y producción— con almacenamiento y credenciales propios. Un error en desarrollo no puede tocar un comprobante de producción.
• Cada credencial de infraestructura alcanza únicamente su propio ambiente.
• Los secretos viven en variables de entorno del proveedor, nunca en el código ni en el repositorio.
• Reglas automáticas de limpieza para archivos incompletos y versiones antiguas.
• Cabeceras de seguridad en las respuestas y política restrictiva de recursos entre orígenes.

Ninguna medida de seguridad ofrece protección absoluta y ningún sistema detecta el cien por ciento del fraude. El servicio se presta según disponibilidad y depende de terceros —bancos, WhatsApp, proveedores de correo— cuyo funcionamiento no controlamos. Revisamos y mejoramos nuestras prácticas de forma continua.

Si encuentras un fallo de seguridad, escríbenos a verifika05@gmail.com con el asunto “Seguridad” y una descripción que permita reproducirlo. Respondemos y damos crédito a quien lo reporte, si así lo desea.

Te pedimos no acceder a datos de terceros, no degradar el servicio, no divulgar el fallo hasta que esté corregido, y no ejecutar pruebas destructivas ni de denegación de servicio. Con esas condiciones, no emprenderemos acciones contra quien reporte de buena fe.

Ante un incidente que afecte datos personales, contenemos, investigamos y corregimos. Informaremos a los afectados y a la Superintendencia de Industria y Comercio en los términos que exige la ley, explicando qué pasó, qué datos se vieron involucrados y qué hicimos al respecto.