¿Quién puede acceder a tus datos de clientes?

En mucho software se decide quién puede ver qué en el sitio donde se construye la pantalla. Eso funciona mientras cada pantalla lo haga bien. Si una sola página se olvida del control, ahí aparecen los datos de otra empresa, y no te enteras hasta que alguien lo avisa.

En Nermio esa frontera está una capa más abajo: en la base de datos. Cada tabla con datos de clientes tiene reglas en la tabla misma que determinan qué filas puede ver una cuenta con la sesión iniciada, y la base aplica esas reglas en CADA consulta, sea cual sea la pantalla o la ruta que la haga. Un fallo en la aplicación puede dar un error, pero no los datos de otra organización. Los visitantes sin cuenta no tienen ningún permiso de lectura sobre esas tablas.

Dentro de tu propia organización decides tú. Hay cuatro roles —propietario, manager, usuario y solo lectura— y quien está en «solo lectura» tampoco puede cambiar nada por un atajo: lo impone esa misma capa.

Un registro que nadie puede retocar

Nermio lleva dos registros. Uno anota lo que se hace en tu entorno y quién lo hace. El otro anota lo que les pasa a las cuentas: intentos de inicio de sesión, la puesta en marcha de un segundo factor, un cambio de contraseña. Están separados para que, ante un incidente, puedas leer uno sin tener que pescarlo dentro del otro.

Más importante es lo que NO se puede hacer con ellos. En el registro de actividad es una propiedad de la tabla: modificar o borrar una línea lo rechaza la base de datos, incluso cuando la petición viene de nuestro rol de administración más alto. En el registro de cuentas hoy descansa en permisos y no en la tabla misma — esa diferencia va aquí y no en una nota al pie. Los dos desaparecen cuando vence su plazo de conservación: veinticuatro meses el de actividad, seis el de cuentas. Un registro que el administrador puede limpiar mientras tanto no es un registro.

No miramos en silencio

A veces alguien de aquí tiene que mirar en tu entorno para resolver un problema. Se puede, pero no a tus espaldas y no sin límite. Para eso un compañero abre una sesión de soporte y tiene que indicar un motivo. Esa sesión tiene un final —quince, treinta o sesenta minutos, nunca un final abierto— y se cierra sola cuando se acaba el tiempo. Un compañero no puede tener dos sesiones abiertas a la vez, así que «me había quedado con la sesión abierta en algún sitio» no existe.

Al empezar se elige si la sesión solo puede leer o también modificar; mirar es lo que viene por defecto. Borrar durante una sesión de soporte no se puede nunca: no hay ninguna ruta para eso, ni con el rol correcto. Y tampoco es iniciar sesión como tú: en el registro no aparece tu nombre sino el del compañero, con la sesión al lado.

Y puedes leerlo después. El propietario de una organización tiene permiso de lectura sobre su propio historial de soporte: qué sesiones hubo, con qué motivo, cuándo, y qué pasó en su entorno durante esa sesión. No es un extra; es lo que hace que un acceso del soporte se pueda explicar.

Iniciar sesión

Tu contraseña no la guardamos. Va cifrada a Supabase Auth y después ya no se puede volver a leer, tampoco por nosotros, tampoco durante una sesión de soporte. Una contraseña olvidada solo se puede restablecer, nunca consultar. Quien se haga pasar por ti y llame para que le lean su contraseña no la consigue, porque no se puede.

El inicio de sesión y el restablecimiento de contraseña tienen un límite: demasiados intentos en unos minutos se rechazan. Ese contador está en la base de datos y no en la memoria de un solo servidor, porque con varios servidores a la vez un atacante apenas notaría el límite en la práctica.

Después de tu contraseña viene siempre un código de una aplicación de autenticación, para cada cuenta: la tuya, la de tus compañeros y la de nuestro propio personal. La comprobación es por sesión, no por cuenta. No «esta cuenta activó la verificación en dos pasos en algún momento», sino «esta sesión ha pasado por ahí»; si no, una contraseña robada seguiría bastando.

Puedes registrar dos aplicaciones de autenticación: tu móvil y una de reserva, por ejemplo un gestor de contraseñas en tu ordenador. Está pensado para el día en que un móvil se cae al agua. Con una de reserva entras con el otro aparato y configuras tú mismo un móvil nuevo. Sin reserva no se puede, y entonces tienes que pedírnoslo: solo nosotros podemos volver a abrir un segundo factor, no el administrador de tu propia organización. Es una decisión deliberada, porque si no, la verificación en dos pasos de todo un equipo vale lo que valga la persona menos atenta. Más de dos no se puede, por la razón contraria: cada aparato de más es un sitio más desde el que se puede abrir tu cuenta.

Dónde están tus datos

En una base de datos Postgres de Supabase, en servidores de Fráncfort (eu-central-1), o sea dentro de la UE. El tráfico entre tu navegador y Nermio va por una conexión cifrada.

Tus datos siguen siendo tuyos, y los sacas tú: en Ajustes hay un botón de exportación por tipo que te da tus empresas, contactos, oportunidades, tareas, tu historial y tus notas en CSV. Se puede cualquier día que tu cuenta esté en marcha, no solo al irte, y puede hacerlo cualquiera de tu equipo, incluso con permisos de solo lectura. Sigue funcionando treinta días después de que lo hayas dejado; cambiar algo, ya no.

Lo que no afirmamos

Nermio es un producto joven, y en una página sobre seguridad eso es información pertinente. No tenemos certificación ISO 27001 ni informe SOC 2, no tenemos la certificación del Esquema Nacional de Seguridad, y no tenemos informe de una prueba de intrusión externa. El software que muestra esos logotipos sin tenerlos hace justo el tipo de afirmación que solo se comprueba cuando algo ha salido mal.

Lo que está escrito aquí no es un sello, por tanto, sino una descripción de lo que hay en el código y en la base de datos. Si encuentras un punto débil, nos gusta saberlo en info@nermio.com con «beveiliging» en el asunto —la palabra neerlandesa, porque es la que buscamos en el buzón—; avisar es más útil que callarse, y nos tomamos un aviso en serio.