Seguridad que es estructural.
Un aislamiento que no se puede configurar mal vale más que una política que nadie lee. Esta página enumera lo que protege los datos de sus clientes, comprobado línea a línea contra el código fuente, el registro de direcciones y nuestro operador.
- 12
- Factor de trabajo de BCrypt
- 15
- Minutos hasta que muere un token de acceso
- 7
- Políticas de límite de frecuencia aplicadas
- 27
- Amenazas analizadas en el modelo STRIDE
Dónde viven sus datos.
Primero la separación, después el cifrado, y una salida que es un archivo y no una negociación.
Aislamiento entre tenants
Una cuenta creada a través del registro recibe su propia base de datos, y cada módulo instalado mantiene sus tablas en su propio esquema dentro de ella. En las tablas de identidad de la propia plataforma, el ámbito de tenant lo aplica también la capa de datos, en vez de dejarlo a cada consulta.
Dónde se ejecuta
Los servidores de la plataforma están en los Países Bajos, alojados por TransIP. La entrega de correo y los SMS usan proveedores fuera de la UE; la política de privacidad nombra a cada uno y dice qué recibe.
Cifrado en reposo
Las bases de datos funcionan con Transparent Data Encryption de SQL Server, así que los archivos de base de datos están cifrados en disco.
Credenciales almacenadas
Las cadenas de conexión a la base de datos y las credenciales de los proveedores de pago se cifran con ASP.NET Core Data Protection antes de almacenarse, y nunca se escriben en los registros.
Cómo sacar sus datos
Cuando una cuenta tiene su propia base de datos, podemos exportarle una copia completa bajo petición, como un archivo .bacpac estándar de SQL Server.
Si dejáramos de operar
Esa exportación es un archivo estándar sobre una pila corriente, no un formato propietario que nos necesite para abrirse. Desde el nivel Dedicated, además, una copia del código fuente de la plataforma queda en manos de un agente de depósito independiente en los Países Bajos, bajo un acuerdo que fija las condiciones de entrega; en los demás planes firmamos el mismo acuerdo si nos lo pide.
Identidad y sesiones.
De vida corta por defecto, revocables de una sola vez, y cada número de abajo está fijado en el código.
- 15min
- duración del token de acceso
- 256bits
- tokens de refresco aleatorios
- 5min
- caducidad del código de un solo uso
- 3intentos
- límite del código de un solo uso
- 5intentos
- umbral de bloqueo
- 12
- factor de trabajo de BCrypt
Contraseñas
Hasheadas con BCrypt a factor de trabajo 12, fijado en el código. Bloqueo tras 5 intentos fallidos por defecto, configurable por tenant y desactivable.
Sesiones
Los tokens de acceso caducan en 15 minutos. Los tokens de refresco son valores aleatorios de 256 bits, almacenados solo como hash, de un solo uso y rotados en cada refresco.
Códigos de un solo uso
Códigos opcionales de 6 dígitos por correo o SMS, hasheados en reposo, con caducidad de 5 minutos y un máximo de 3 intentos.
Dispositivos de confianza
Cookies con prefijo de host, seguras y de sitio estrictamente propio, que contienen un valor almacenado en el servidor como hash. Presentar una cookie ya sustituida revoca el dispositivo y bloquea el inicio de sesión.
Revocar el acceso
Todos los dispositivos de confianza se pueden revocar de una vez, y la revocación se dispara sola tras un cambio de contraseña, un bloqueo, la desactivación del doble factor o un cambio de correo o de teléfono.
Fronteras, límites y el registro.
Comprobaciones en el borde, topes en el camino de entrada y un rastro que solo se añade detrás de cada cambio.
Autorización
Los endpoints protegidos por permisos declaran el permiso que exigen, comprobado en la frontera HTTP contra los claims del token firmado y sin ida y vuelta a la base de datos. Los endpoints que solo sirven los datos del propio usuario autenticado se protegen únicamente con autenticación.
Límites de frecuencia y cabeceras
Siete políticas de límite de frecuencia aplicadas, y ocho cabeceras de seguridad, entre ellas HSTS y una política de seguridad de contenido que deniega por defecto en las respuestas de la API.
Registro de auditoría
Los cambios en las tablas propias de la plataforma — accesos, roles, permisos, ajustes — se registran de forma que solo se añade: quién, qué, en qué tabla y fila, cuándo y los valores posteriores al cambio. Se excluyen los hashes de contraseñas, los hashes de códigos de un solo uso, los secretos de doble factor y los sellos de seguridad. Un borrado registra la clave de la fila, no su contenido anterior.
Modelo de amenazas
Un modelo STRIDE escrito: 27 amenazas analizadas en cuatro zonas de confianza y en la frontera host-tenant, con cuatro riesgos residuales aceptados y declarados.
Cada línea de arriba se comprobó por última vez el 19 de julio de 2026: contra el código fuente, y en el caso del alojamiento y el cifrado en disco, contra el registro de direcciones y nuestro operador.
Envíenos su cuestionario de seguridad.
Lo responderemos línea a línea, con las personas que escribieron el código.
Póngase en contacto