La información de tu negocio es tuya. Aquí contamos cómo la cuidamos, en palabras que cualquiera entiende y con el detalle que tu técnico va a querer revisar.
Todos nuestros clientes corren sobre el mismo sistema, y aun así cada negocio vive encerrado en su propio candado. La regla no depende de que un programador se acuerde de aplicarla. Está escrita dentro de la base de datos, y es la base la que decide.
Cada dato lleva grabado a qué negocio pertenece. Si una consulta pide algo que es de otra cuenta, la base no lo entrega, venga de donde venga el pedido. Aunque el programa se equivocara por arriba, abajo el candado sigue puesto.
Desactivas su acceso y queda fuera en el acto. Si alguien deja tu empresa un martes, esa tarde ya no ve tu información.
Para vigilar sus fallas, casi todos los sistemas le mandan a una empresa extranjera copia de lo que ocurre dentro del panel, con datos personales adentro. Nosotros armamos ese registro por dentro. Nos costó más trabajo. Pero la Ley 29733 nos exige saber dónde termina la información de tus clientes, y la respuesta más corta es que no termina en ningún lado.
Cuando una cuenta se elimina, el sistema exporta primero toda su información. Si ese respaldo no se completa, el borrado se cancela.
Una prueba automática se hace pasar por un cliente y trata de meterse en los datos de otro, en los dos sentidos. Debe fallar siempre. El día que no falle, el sistema se frena solo y no publicamos nada hasta resolverlo.
No te entregamos un programa para que lo mantengas tú. Vive en nuestra infraestructura y lo cuidamos nosotros, así que una falla se corrige una vez, en el origen, y queda corregida para todos los clientes el mismo día. Con software entregado, cada cliente se queda solo con su copia y con su bug.
A un dueño no le interesa qué tecnología usamos. Le interesa qué pasa el día que algo salga mal.
Ese día lo trabajamos antes de que llegue. Los datos ya están aislados cuando ocurre el problema, el respaldo ya se hizo antes del borrado, y el acceso de quien no debería tenerlo se corta en segundos. Del otro lado hay una persona del equipo con nombre y apellido, en un WhatsApp. No un ticket número 4392.
Cada negocio que trabaja con nosotros tiene una persona asignada y un WhatsApp directo. Si tienes una duda de seguridad antes de decidir, pregúntala. Te vamos a responder con la verdad, incluso cuando la verdad sea que todavía no llegamos hasta ahí.
Habla con el equipoEsta parte está escrita para quien nos va a auditar. Son los controles que hoy corren en producción, contados con el nivel de detalle que corresponde a una página pública. Si tu equipo necesita el detalle fino, lo revisamos con ellos en una llamada.
| Control | Estado | Cómo está implementado |
|---|---|---|
| Aislamiento por fila | Activo | Todas las tablas del negocio tienen Row Level Security activa, con políticas que exigen rol y cuenta a la vez. El frontend filtra por comodidad; la que decide es la base. |
| Sin sesión no hay datos | Activo | El rol anónimo no tiene privilegios sobre las tablas del negocio. Aunque alguien tome la clave pública que vive en el navegador, no obtiene ni una fila. |
| Escrituras públicas selladas en el servidor | Activo | Un formulario nunca decide a qué cuenta pertenece lo que envía. El servidor resuelve el negocio por su dominio, y los mensajes de WhatsApp por el número al que llegaron. Lo que diga el navegador no se cree. |
| Segundo factor | Activo | La administración de la plataforma exige un segundo factor verificado. Sin él, la sesión pierde esos permisos automáticamente, aunque el usuario sea quien dice ser. Los administradores de cada negocio también pueden activarlo, y se lo recomendamos. |
| Doble llave en lo irreversible | Activo | Eliminar una cuenta pide segundo factor reciente, una frase de confirmación escrita a mano y un respaldo completo. Si el respaldo no se completa, el borrado se cancela. |
| Política de contenido en el navegador | Activo | El panel y los sitios de cliente aplican una CSP que bloquea de verdad, no solo advierte: nada de scripts de fuera, nada de código evaluado al vuelo, y el panel no puede embeberse dentro de otra página para engañar a un usuario. |
| Mensajes entrantes firmados | Activo | Cada mensaje de WhatsApp que llega se valida contra su firma criptográfica. Si la firma no cuadra, se descarta. Y si el sistema no encuentra su secreto de validación, rechaza todo el tráfico en vez de dejarlo pasar. |
| Freno a los envíos automatizados | Activo | Los formularios públicos tienen límites por origen y por cuenta dentro de una ventana de tiempo. Los intentos quedan registrados en una tabla que ningún cliente puede leer, para que la dirección de un visitante no quede a la vista de nadie. |
| Origen restringido en el servidor | Activo | Las funciones que trabajan con una sesión iniciada solo atienden peticiones de orígenes autorizados. Una página ajena no puede pedirles nada en nombre de tu usuario. |
| Anti-bot en el ingreso | Activo | Cloudflare Turnstile protege el acceso, y el token se verifica en el servidor, no en el navegador. No usamos reCAPTCHA: molesta al usuario y no protege más. |
| La sesión caduca sola | Activo | Una sesión abierta no dura para siempre. Vence y obliga a entrar de nuevo, aunque nadie se acuerde de cerrarla. |
| Registro de errores propio | Activo | Los errores del navegador se guardan en nuestra base, no en un servicio extranjero. Solo Moderniva los lee, ni siquiera el propio cliente, porque el detalle de un error puede arrastrar datos personales de terceros. |
| Cifrado en tránsito | Activo | Todo viaja por HTTPS con certificados gestionados por Cloudflare, incluidos los dominios propios de cada cliente. |
| Cambios versionados | Activo | Ningún cambio de la base ocurre a mano sobre producción. Todo queda escrito, versionado y es reversible. |
Un control que nadie comprueba es una promesa. Las comprobaciones de aquí abajo corren solas, sin que nadie tenga que acordarse, y si alguna falla frena la publicación del cambio que la rompió.
Cada mañana, y también con cada cambio del sistema, dos negocios de prueba intentan robarse los datos el uno al otro: leer sin haber iniciado sesión, colarse en las filas del vecino, guardar información atribuyéndola a otra cuenta, modificar lo ajeno, abrir sus archivos. Todo eso tiene que fallar. Cuando algo pasa, la prueba se detiene con una orden que no admite interpretación: no desplegar.
Antes de publicar recorremos las pantallas del panel con la protección real puesta, en claro y en oscuro, y la consola tiene que quedar sin un solo error. Hacemos además la prueba al revés: cargamos a propósito un script de fuera, y si el navegador no lo bloquea, algo está mal.
Un analizador de seguridad revisa la base buscando permisos abiertos de más y reglas mal puestas. Hoy no arroja ningún hallazgo crítico. Quedan avisos menores, que revisamos uno por uno; algunos los dejamos ahí a propósito, porque quitarlos rompería el propio candado.
Nuestros clientes no tienen copias distintas del sistema: comparten el mismo motor, y lo que los diferencia vive en la configuración. En seguridad eso pesa. Un problema que aparece en un negocio se arregla en el origen y queda arreglado para todos a la vez, en lugar de parchar el caso del que reclamó y dejar a los demás esperando turno con el mismo agujero abierto.
No tenemos veinte personas en un departamento de seguridad, y no vamos a fingir que sí. Tenemos un sistema construido con el aislamiento como primera regla, pruebas que corren solas todos los días y una empresa con nombre y dirección en Trujillo, que responde con un contrato firmado. Si encuentras algo que no cuadra, escríbenos y lo revisamos contigo.
Los cambios de seguridad que vamos haciendo, con su fecha. Es la forma más simple de demostrar que esto no es una página que se escribió una vez y se dejó ahí.
Abrimos al público los controles con los que protegemos la información de cada negocio, cómo los comprobamos y qué nos falta todavía. Un cliente no debería tener que creernos de palabra.
Los errores del navegador se guardan ahora en nuestra propia base y solo los lee Moderniva. Descartamos las herramientas del mercado, que habrían sido más cómodas, porque mandan a otro país una copia de lo que ocurre dentro del panel.
Antes, una sesión ya abierta podía seguir viva un rato después de que le quitaran el acceso a esa persona. Ahora la base lo comprueba en cada consulta, así que quien fue dado de baja deja de ver información en el acto, aunque tenga la pantalla abierta.
La política de contenido del panel y de los sitios de cliente pasó de avisar a bloquear. El navegador ya no ejecuta código que no venga de nosotros, y el panel no puede embeberse dentro de otra página para engañar a un usuario.
Los formularios de captación tienen límites por origen y por cuenta. Los intentos quedan registrados en una tabla que ningún cliente puede leer, para que la dirección de un visitante no quede expuesta a nadie.
Revisamos las seis superficies del sistema buscando cualquier forma de que los datos de un negocio asomaran en otro. No encontramos ninguna. Lo que sí encontramos fueron deudas menores, que quedaron cerradas en los días siguientes.