Seguridad de la cuenta
La seguridad del servidor protege los sitios. La seguridad de la cuenta protege las llaves de acceso a estos. Cada inicio de sesión en Zinn Digital® funciona con un sistema de identidad basado en estándares —llaves de acceso y WebAuthn, autenticación de doble factor TOTP, inicio de sesión mediante enlace mágico, SSO SAML para equipos empresariales y de agencias— respaldado por roles granulares, claves API por organización y un registro de auditoría de solo adición.
La mayoría de las cuentas de alojamiento son una contraseña en una base de datos, unida a un panel de control. El nuestro es un sistema de identidad dedicado —Keycloak, compatible con OIDC y SAML— que se sitúa frente a todo: el panel del cliente, la consola de administración del personal, este sitio público y base de conocimiento, y sus tickets de soporte. Inicie sesión una vez y habrá iniciado sesión en todos ellos.
Debido a que está construido sobre estándares abiertos en lugar de un inicio de sesión propietario, la capa de identidad se puede intercambiar de la misma manera que cualquier otro componente de la plataforma. Ninguna parte de su modelo de acceso está atrapada dentro del producto de un proveedor, y ninguna de las autenticaciones de su equipo depende de que mantengamos a un solo proveedor. Ese es el mismo principio de ausencia de dependencia de proveedor que aplicamos a las cuentas de CDN, al DNS y a los proveedores de pagos.
El inicio de sesión está localizado y la transición del sitio a la pantalla de acceso conserva tu idioma, por lo que un equipo distribuido en varios países no se ve obligado a utilizar un inicio de sesión exclusivo en inglés.
Cuatro métodos, todos de primer nivel, todos configurables por persona. Nadie está obligado a usar la opción más débil por ser la única disponible.
Introduce tu correo, haz clic en el enlace y listo. Sin contraseñas que puedan ser robadas, reutilizadas o filtradas en una brecha de datos. Esta es la ruta predeterminada para las nuevas cuentas y, para la mayoría de las personas, es la única que necesitarán.
Registra una passkey —Touch ID, Face ID, Windows Hello o una llave de hardware como una YubiKey— e inicia sesión sin contraseña. Las passkeys están vinculadas al origen, por lo que una página de inicio de sesión falsa no puede robar ninguna. La plataforma acepta autenticadores ES256 y RS256 y prefiere la verificación de usuario.
Inicia sesión con Google mediante una conexión estándar con proveedor de identidad, de modo que una cuenta herede los controles que tu Google Workspace ya aplique. Los proveedores adicionales se conectan de la misma forma; nada en esto es una integración a medida.
Conservada para las personas y los scripts que la necesitan, y sujeta a una política real: un mínimo de doce caracteres, nunca tu nombre de usuario o dirección de correo electrónico, sin reutilizar tus últimas tres, y cifrada con Argon2. Las direcciones de correo electrónico se verifican antes de que una cuenta pueda utilizarse.
Los segundos factores forman parte del sistema de identidad, no son un complemento que compras ni un plugin que instalas en tu propio sitio.
Si tu organización ya utiliza un proveedor de identidad (Okta, Entra ID, Google Workspace o cualquier otro compatible con SAML), puedes conectarlo y tus usuarios iniciarán sesión en Zinn Digital® con sus credenciales corporativas actuales. Tu equipo no tendrá que gestionar una segunda contraseña ni olvidar ninguna lista de comprobación de bajas adicionales.
Eso importa más a escala de agencia y revendedor, donde la rotación de personal es un verdadero incidente de seguridad. Cuando alguien se va y lo deshabilitas en tu directorio, también has deshabilitado su vía de acceso a tu hosting. El acceso sigue al empleo, de forma centralizada, en lugar de tener que perseguirlo a través de una docena de herramientas SaaS.
SAML convive con todo lo demás en lugar de reemplazarlo: a los contratistas se les puede seguir dando una cuenta de enlace mágico dentro de un rol delimitado, mientras que el personal fijo accede a través de SSO. Una organización, un modelo de permisos, dos puertas de entrada.
El acceso está delimitado al árbol de la organización (del distribuidor al cliente y al sitio web) y se aplica directamente en la base de datos mediante seguridad a nivel de fila, no solo en la aplicación. El acceso entre inquilinos no es una política que pidamos a la gente que respete; es una consulta que no puede devolver filas. Cuatro roles de cliente cubren la división realista de funciones.
Control total de la organización y sus subcuentas: crear organizaciones hijas, invitar y eliminar miembros, asignar roles, gestionar todos los sitios, administrar la facturación, gestionar claves API y leer el registro de auditoría.
Facturas, suscripciones, métodos de pago y el catálogo de planes, y nada más. Tu responsable de finanzas o contable puede saldar una factura sin tener nunca la capacidad de tocar, suspender o eliminar un sitio activo.
Sitios y acceso a la API sin control de facturación: ver y aprovisionar sitios, reiniciar servicios, purgar cachés, gestionar claves de API y trabajar con tickets. Deliberadamente sin acceso a métodos de pago, facturación o cambios de plan.
Solo lectura en toda la organización: sitios web, facturación, planes, tickets, estado de traducción y registro de auditoría. El rol adecuado para un auditor, un cliente que necesita visibilidad o un nuevo empleado en su primera semana.
El panel de control es una puerta de entrada. La API, la CLI, el proveedor de Terraform y el servidor MCP son otras, y se rigen por el mismo modelo de acceso, porque una clave sin ámbito es una forma de eludir cada rol que acabas de configurar.
Una clave de API se emite para una organización, no para una persona física, y cuenta con sus propios ámbitos. Trátala como material de credenciales compartidas: asígnale un nombre según su propósito, asígnale los ámbitos más restringidos que funcionen y altérnala cuando la persona que la creó cambie de puesto o de organización.
La clave sin procesar se te muestra una sola vez, al crearla. Lo que guardamos es un hash SHA-256 y un prefijo corto para la búsqueda. No podemos volver a mostrarte una clave, y una brecha en la base de datos no le entrega credenciales funcionales a un atacante.
Cada clave conlleva ámbitos granulares vinculados al mismo catálogo de permisos que utilizan los roles, registra cuándo se usó por última vez y puede revocarse por completo en el momento en que parezca incorrecta. Las claves independientes de entorno aislado (sandbox) prueban la API sin facturación ni aprovisionamiento real de por medio.
El servidor MCP permite que cualquier agente compatible con MCP gestione tu alojamiento, y se autentica mediante OAuth 2.1, con alcance limitado a tu organización y sus permisos RBAC, con tokens revocables por herramienta, confirmación de acciones destructivas, límites de gasto y un registro de auditoría completo. Conectar un asistente de inteligencia artificial no significa entregarle las llaves de todo.
Cada acción privilegiada escribe un registro de solo adición: quién la realizó, qué hizo, sobre qué la hizo, la evidencia de respaldo y la dirección IP de origen, con una marca de tiempo. No es una comodidad para la depuración; es el rastro de evidencia.
No —y preferimos que no lo hagas. El inicio de sesión por correo electrónico con enlace mágico es el valor predeterminado, y puedes registrar una llave de acceso (Touch ID, Face ID, Windows Hello o una llave de hardware) e iniciar sesión sin necesidad de establecer una contraseña nunca. El correo electrónico y la contraseña siguen estando disponibles como alternativa, con un requisito mínimo de doce caracteres, prohibición de reutilizar los últimos tres y cifrado Argon2.
La autenticación de dos factores TOTP está integrada en la capa de identidad y se puede aplicar mediante directivas en toda la organización en lugar de dejar que cada miembro decida activarla. Las passkeys son la opción más segura cuando los dispositivos de su equipo las admiten, ya que eliminan la contraseña que un atacante intentaría robar mediante phishing.
Sí. El rol de Gestor de facturación otorga acceso a facturas, suscripciones, métodos de pago y al catálogo de planes, y nada más; no incluye la capacidad de ver, aprovisionar, reiniciar, suspender ni eliminar un sitio. Lo contrario también se aplica: el rol de Desarrollador gestiona sitios y acceso a la API sin ningún tipo de control de facturación. Los roles se asignan por organización, por lo que un rol en una organización no otorga acceso en otra organización separada y no relacionada, aunque un rol en una organización matriz se aplica a las organizaciones anidadas bajo ella.
Revócala desde el panel de control y dejará de funcionar de inmediato. El margen de daño está limitado por lo que esa clave podía hacer en un principio, razón por la cual las claves tienen ámbitos granulares y registran una marca de tiempo de último uso: unos ámbitos reducidos y un rastro de uso visible son lo que convierte una filtración en un incidente contenido en lugar de en un compromiso total de la cuenta. Ten en cuenta que las claves se emiten a la organización y no a un individuo, por lo que debes tratarlas como credenciales compartidas y rotarlas cuando las personas cambien de puesto o se vayan. En nuestro sistema solo se almacena un hash de la clave, por lo que una filtración en nuestra base de datos no genera una credencial válida.
Sí. Cada acción privilegiada se registra en un registro de auditoría de solo adición que incluye el autor, la acción, el objetivo, las pruebas de respaldo, la IP de origen y una marca de tiempo. Los roles de propietario y de solo lectura pueden leerlo directamente. Las acciones del personal en su cuenta se registran en el mismo historial, y las acciones del personal que sean sensibles o destructivas pueden requerir primero una autenticación reforzada o la aprobación de dos personas.
Sí: SAML SSO es compatible con las cuentas empresariales y de agencias, por lo que su personal se autentica con credenciales corporativas existentes y la baja en su directorio también elimina su acceso aquí. Puede combinar enfoques: SSO para el personal permanente, cuentas de enlaces mágicos con alcance limitado para contratistas, todo dentro del mismo modelo de permisos.
No — las contraseñas deliberadamente no se migran. Su cuenta se importa sin una y, al iniciar sesión por primera vez, puede usar un enlace mágico o establecer una contraseña nueva según la política actual. Transferir hashes de contraseñas antiguas arrastraría vulnerabilidades antiguas a un nuevo sistema, por lo que no lo hacemos.
La prueba de Footprint-Free dura 14 días, no requiere tarjeta de crédito y cubre hasta cinco sitios web. Durante la prueba obtienes la capa de identidad completa; las llaves de acceso, la autenticación de dos factores, los roles, las claves de API y el registro de auditoría no están bloqueados tras un plan de pago.
Registra una passkey, invita a tu equipo a los roles adecuados y emite una clave de API con ámbito, todo en una prueba de 14 días sin tarjeta y sin necesidad de facilitar datos de tarjetas.
Empieza gratis