Seguridad de la cuenta
La seguridad del servidor protege los sitios. La seguridad de la cuenta protege las claves de acceso a ellos. Cada inicio de sesión de Zinn Digital® funciona con un sistema de identidad único basado en estándares: claves de acceso y WebAuthn, autenticación de dos factores TOTP, inicio de sesión mediante enlace mágico, SAML SSO para equipos de empresas y agencias, con roles granulares, claves de 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, vinculada a un panel de control. La nuestra es un sistema de identidad dedicado — Keycloak, compatible con OIDC y SAML — que se sitúa por delante de todo: el panel de control del cliente, la consola de administración del personal, este sitio público y base de conocimientos, y sus tickets de soporte. Inicie sesión una vez y habrá iniciado sesión en todos ellos.
Dado que se basa en estándares abiertos en lugar de un inicio de sesión propietario, la capa de identidad se puede reemplazar de la misma manera que cualquier otro componente de la plataforma. Ninguna parte de su modelo de acceso queda atrapada dentro del producto de un proveedor, y ninguna autenticación de su equipo depende de que mantengamos un único proveedor. Este es el mismo principio de ausencia de permanencia obligatoria que aplicamos a las cuentas de CDN, DNS y proveedores de pagos.
El inicio de sesión está localizado y la transición del sitio a la pantalla de acceso conserva su idioma, por lo que un equipo distribuido en varios países no se ve obligado a utilizar un inicio de sesión exclusivamente en inglés.
Cuatro métodos, todos de primer nivel, todos configurables por persona. Nadie se ve obligado a recurrir a la opción más débil por ser la única disponible.
Introduzca su correo electrónico, haga clic en el enlace y habrá accedido. Sin contraseñas que puedan ser objeto de phishing, reutilizadas o filtradas en una brecha de seguridad. Esta es la vía predeterminada para las cuentas nuevas y, para la mayoría de las personas, es la única que necesitarán.
Registre una clave de acceso (passkey) — Touch ID, Face ID, Windows Hello o una clave de hardware como una YubiKey — e inicie sesión sin necesidad de contraseña. Las claves de acceso están vinculadas al origen, por lo que una página de inicio de sesión fraudulenta no puede sustraerlas. La plataforma admite autenticadores ES256 y RS256 y prefiere la verificación del usuario.
Inicie sesión con Google a través de una conexión estándar de proveedor de identidades, de modo que una cuenta herede los controles que su Google Workspace ya aplica. Otros proveedores se conectan de la misma manera; nada de esto es una integración personalizada.
Conservado para las personas y los scripts que lo necesitan, y sujeto a una política real: mínimo doce caracteres, nunca su nombre de usuario o dirección de correo electrónico, sin reutilización de sus últimas tres contraseñas, con hash mediante 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 usted compra ni un plugin que instala en su propio sitio.
Si su organización ya utiliza un proveedor de identidades —Okta, Entra ID, Google Workspace o cualquier otro que admita SAML—, conéctelo y su personal iniciará sesión en Zinn Digital® con sus credenciales corporativas existentes. No hay una segunda contraseña que su equipo deba gestionar, ni una segunda lista de verificación de baja que pueda olvidarse.
Esto reviste la máxima importancia a escala de agencias y distribuidores, donde la rotación de personal constituye un verdadero evento de seguridad. Cuando alguien se marcha y usted lo desactiva en su directorio, también habrá desactivado su vía de acceso a su alojamiento. El acceso sigue al empleo de forma centralizada, en lugar de tener que rastrearse a través de una docena de herramientas SaaS.
SAML coexiste con todo lo demás en lugar de reemplazarlo: a los contratistas se les puede seguir proporcionando una cuenta con enlace mágico dentro de un rol específico, mientras que el personal permanente accede a través de SSO. Una sola organización, un solo modelo de permisos, dos puertas de entrada.
El acceso está delimitado al árbol de la organización —del distribuidor al cliente y al sitio— y se aplica en la propia 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 las personas que respeten; 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: cree organizaciones secundarias, invite y elimine miembros, asigne roles, administre cada sitio, gestione la facturación, administre claves de API y consulte el registro de auditoría.
Facturas, suscripciones, métodos de pago y el catálogo de planes; nada más. Su responsable de finanzas o contable puede liquidar una factura sin tener nunca la capacidad de modificar, suspender o eliminar un sitio web activo.
Acceso a sitios y a la API sin control de facturación: visualice y aprovisione sitios, reinicie servicios, purgue cachés, gestione claves de API y tickets de trabajo. Deliberadamente sin acceso a métodos de pago, facturación o cambios de plan.
Solo lectura en toda la organización: sitios, facturación, planes, tickets, estado de la traducción y registro de auditoría. El rol adecuado para un auditor, un cliente que desea visibilidad o un nuevo empleado en su primera semana.
El panel de control es una vía de acceso. La API, la CLI, el proveedor de Terraform y el servidor MCP son otras, y se rigen por el mismo modelo de acceso, ya que una clave sin ámbito elude todas las funciones que acaba de configurar.
Una clave de API se emite para una organización, no para una persona física, y cuenta con sus propios alcances. Trátela como material de credenciales compartido: asígnele un nombre según su propósito, otorgue los alcances más restringidos que funcionen y renuévela cuando la persona que la creó cambie de puesto o se marche.
La clave sin procesar se le muestra solo una vez, en el momento de su creación. Lo que conservamos es un hash SHA-256 y un prefijo corto para la búsqueda. No podemos volver a mostrarle una clave, y un compromiso de la base de datos no otorga credenciales funcionales a un atacante.
Cada clave incluye permisos granulares vinculados al mismo catálogo de permisos que utilizan los roles, registra cuándo se utilizó por última vez y puede revocarse de inmediato en el momento en que parezca sospechosa. Las claves de sandbox independientes permiten probar la API sin que exista facturación ni aprovisionamiento real detrás de ellas.
El servidor MCP permite que cualquier agente compatible con MCP administre su alojamiento, y se autentica a través de OAuth 2.1, delimitado a su organización y a sus permisos RBAC, con tokens revocables por herramienta, confirmación en acciones destructivas, límites de gasto y registro de auditoría completo. Conectar un asistente de IA no significa entregarle las llaves de todo.
Cada acción con privilegios escribe un registro de solo adición: quién la realizó, qué hizo, sobre qué lo hizo, las pruebas que lo respaldan y la dirección IP de origen, con una marca de tiempo. No es una comodidad para la depuración; es el rastro de pruebas.
No, y preferimos que no lo haga. El inicio de sesión mediante enlace mágico por correo electrónico es la opción predeterminada, y puede registrar una llave de paso (Touch ID, Face ID, Windows Hello o una llave de hardware) e iniciar sesión sin haber configurado nunca una contraseña. El correo electrónico y la contraseña siguen estando disponibles como alternativa de respaldo, con un mínimo de doce caracteres, la imposibilidad de reutilizar las tres últimas y el cifrado mediante hash Argon2.
La autenticación de dos factores mediante TOTP está integrada en la capa de identidad y puede exigirse mediante directivas en toda la organización, en lugar de dejarse a la elección de cada miembro. Las llaves de acceso son la opción más segura si los dispositivos de su equipo las admiten, ya que eliminan la contraseña que un atacante intentaría obtener 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 permite ver, aprovisionar, reiniciar, suspender ni eliminar un sitio. Lo contrario también es válido: el rol de Desarrollador gestiona sitios y el 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 una organización independiente y no relacionada, aunque un rol en una organización principal se aplica a las organizaciones subordinadas a ella.
Revóquelo desde el panel de control y dejará de funcionar de inmediato. El alcance de los daños está limitado por lo que esa clave podía hacer en primer lugar, razón por la cual las claves cuentan con permisos granulares y registran una marca de tiempo de último uso; los permisos delimitados y un historial de uso visible son lo que convierten una filtración en un incidente aislado y no en un compromiso total de la cuenta. Tenga en cuenta que las claves se emiten para la organización y no para un individuo, así que trátelas como credenciales compartidas y renuévelas cuando cambie el personal. En nuestro sistema solo se almacena un hash de la clave, por lo que una filtración de nuestra base de datos no generará una credencial funcional.
Sí. Cada acción privilegiada se escribe en un registro de auditoría de solo adición con 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 seguimiento, y las acciones sensibles o destructivas del personal pueden requerir primero autenticación reforzada o la aprobación de dos personas.
Sí: se admite SAML SSO para cuentas empresariales y de agencias, de modo que su personal se autentica con las credenciales corporativas existentes y la baja en su directorio también elimina su acceso aquí. Puede combinar enfoques: SSO para el personal permanente, cuentas magic-link con alcance delimitado para contratistas, todo dentro del mismo modelo de permisos.
No: las contraseñas no se migran de manera deliberada. Su cuenta se importa sin una, y en el primer inicio de sesión puede usar un enlace mágico o establecer una contraseña nueva según la política actual. Migrar los hashes de contraseñas antiguos transferiría vulnerabilidades previas a un sistema nuevo, por lo que no lo hacemos.
La prueba de Footprint-Free dura 14 días, no requiere tarjeta y cubre hasta cinco sitios. Obtendrá la capa de identidad completa durante la prueba: 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 restringidos a un plan de pago.
Registre una llave de acceso, invite a su equipo a los roles correspondientes y emita una clave de API con alcance limitado: todo en una prueba de 14 días sin necesidad de introducir los datos de su tarjeta.
Empiece gratis