Dónde residen tus datos y quién puede llegar a ellos.

La plataforma funciona sobre OVHcloud, un proveedor europeo que opera sus propios centros de datos en Francia. Eso está por encima de la respuesta de residencia anterior: las máquinas, los discos y las copias están en la Unión Europea porque desplegamos en sus regiones francesas, no porque un campo de región tenga hoy un valor europeo y pudiera tener otro mañana.

Saber sobre qué hardware están tus saldos es lo que te permite evaluar la capa que de verdad los guarda. Muchos proveedores no lo dicen, y a nosotros no has tenido que preguntárnoslo.

Nada llega a esas máquinas en claro. La aplicación web y la API se sirven sobre TLS, y un fichero que llega por SFTP llega con credenciales emitidas solo para tu organización, no con un punto de entrega compartido que vean varios clientes. Ya en las máquinas, el almacenamiento de producción y las copias de seguridad que se sacan de él están cifrados en reposo. La criptografía es estándar y está revisada por medio mundo —la nuestra no la escribimos nosotros— y las claves y credenciales que hay detrás viven en almacenamiento controlado, nunca en el código, en un fichero de configuración, en un ticket ni en un mensaje; se rotan con una cadencia fija y se reemplazan de inmediato si se marcha alguien que podía llegar a ellas.

El software con el que prestamos el servicio también es nuestro. Las peticiones de soporte, y el histórico de lo que se dijo en ellas, se atienden en una herramienta que hemos construido y operamos nosotros: no hay un servicio de asistencia de terceros guardando una copia de lo que nos escribes, ni un proveedor de soporte que añadir a una revisión de subencargados.

Las copias de seguridad se hacen solas, se conservan treinta días y se guardan aparte de la infraestructura de producción a la que protegen: lo que se lleve por delante producción no se lleva la copia. Las restauraciones se prueban de forma periódica en vez de darse por buenas. Desarrollo, pruebas y producción son entornos separados, y los datos de producción de un cliente no salen del de producción. El plan de continuidad que hay detrás se ejercita al menos una vez al año y después de cualquier cambio importante, y un ejercicio del que no sale nada se trata como un ejercicio mal diseñado y no como un aprobado.

El inicio de sesión único es la forma prevista de entrar en Tresora. Se conecta con cualquier proveedor de identidad que hable OpenID Connect —el que tu organización ya usa para todo lo demás— y la conexión la hacemos contigo durante la puesta en marcha, no se te deja en un formulario y una dirección de soporte. A partir de ahí, quién entra lo decide tu proveedor.

Los accesos siguen los grupos que ya mantiene tu directorio. Quien entra en la empresa recibe Tresora cuando recibe todo lo demás, y quien se va lo pierde en el mismo momento: no hay una segunda lista de personas que alguien tenga que mantener al día, ni bajas que conserven una cuenta porque se traspapeló un formulario.

Dentro del espacio de trabajo, lo que cada persona ve y hace depende del rol que le das. Un rol es un conjunto de permisos explícitos y no un nivel, así que quien necesita una pantalla tiene una pantalla; y el rol se comprueba en cada operación, no una sola vez al entrar.

Iniciar sesión directamente en Tresora exige siempre un segundo factor: una passkey en tu propio dispositivo o un código de una aplicación de autenticación. Es obligatorio y no opcional: no hay un ajuste que lo desactive, ni en tus cuentas ni en las nuestras, así que una contraseña por sí sola no abre nada. Cuando el inicio de sesión pasa por tu proveedor de identidad, la política de factores vive allí: se aplican las reglas que ya tengas puestas en él.

Quién puede llegar a producción por nuestro lado es una lista corta de personas con nombre. Cada una entra con su propia cuenta y sus propias credenciales —no hay cuentas compartidas ni genéricas en ninguna parte— y el trabajo de administración usa una cuenta administrativa aparte, con nombre, no una cuenta normal a la que se le añaden permisos. El acceso se concede contra un rol definido, sobre una petición que aprueba otra persona; nadie aprueba la suya; y la lista se revisa de forma periódica en lugar de dejarla crecer. Dentro del producto, cada rol lleva lo mínimo que necesita para su trabajo y nada al lado.

Una regla editada, una aprobación dada, una corrección contabilizada, un pago liberado: cada cosa queda escrita con quién la hizo y cuándo. Ese registro es lo que se lee cuando hay que revisar un incidente, y lo que te dice que un martes tranquilo fue tranquilo de verdad.

Las cifras reciben el mismo trato. Los importes se guardan y se calculan como números enteros de la unidad menor de la divisa, nunca en coma flotante binaria, de modo que un total no se desvía al ir sumando; y cada cifra se abre sobre el apunte bancario o el asiento que tiene debajo, con el fichero en el que llegó y la fecha en la que llegó. Tu auditor la reproduce a partir de tus propios datos en lugar de fiarse de los nuestros.

Lo que se le muestra a una persona cuando algo falla también lo escribimos nosotros. Un mensaje de excepción en crudo es una descripción de las tripas de un sistema entregada a alguien que no la pidió, y es una forma muy conocida de que un sistema cuente más de lo que pretendía. El texto de la pantalla dice qué ha pasado y qué hacer.

La supervisión no es solo un rastro que se sigue después. Los mismos eventos disparan las alertas que tu equipo configura — las condiciones las pones tú, así que un umbral superado o una aprobación que falta llega a la persona adecuada cuando aún se puede actuar, en vez de aparecer en una revisión una semana más tarde.

Esa traza es de solo adición. Las entradas se añaden y no se editan ni se borran, y no hay ninguna vía de aplicación ni de administración que pueda tocar una, tampoco la nuestra: quien hace un cambio en producción no es quien puede cambiar el registro de ese cambio. Y es tuya para leerla: el rol de Auditor se la abre a tu propia gente, acotada a tu organización, así que comprobar qué pasó no empieza por pedírnoslo.

Esta web sirve /.well-known/security.txt — el fichero que define la RFC 9116 y lo primero que lee quien investiga, o su escáner. Contiene el buzón al que escribir, los idiomas que leemos y la fecha en la que el propio fichero caduca.

Un aviso hecho de buena fe es bienvenido, y a quien lo hace no le responde un abogado. Cuéntanos qué encontraste y cómo reproducirlo, y contesta una persona.

Cuando los que encontramos algo somos nosotros, entra un plan de respuesta a incidentes documentado: las severidades están clasificadas, los roles están repartidos de antemano en vez de improvisarse el día que toca, y los canales por los que te llegamos están por escrito. Saber quién hace qué antes de que pase nada es casi todo lo que hace que una respuesta sea rápida.