Acceso delegado
Trae a un desarrollador, entrega la facturación a tu contador, dale a un cliente una ventana de solo lectura a sus propios sitios o permite que nuestro equipo de soporte revise un problema. Cada concesión es un rol con permisos definidos, delimitado a una organización, aplicado en la base de datos y registrado en un registro de auditoría de solo adición.
Compartir un solo inicio de sesión es cómo el acceso a la cuenta falla. En Zinn Digital® cada persona tiene su propia identidad, y el acceso es una membresía —un usuario, una organización y un rol— que puedes otorgar, cambiar o revocar por sí misma.
Cada colaborador inicia sesión con sus propias credenciales a través de Keycloak, nuestra capa de identidad. Nadie escribe tu contraseña, nadie comparte una sesión de navegador y eliminar a alguien es una sola acción en lugar de una rotación de contraseñas y un apuro por averiguar quién más la sabía.
Las cuentas son jerárquicas: una organización de revendedor contiene organizaciones de clientes y las organizaciones de clientes contienen sitios. Una membresía se aplica a una organización y a todo lo que está debajo de ella, por lo que puede otorgar a un cliente de agencia el control de su propia organización sin exponer nunca a sus otros clientes.
La separación de inquilinos no es un filtro en el código de la aplicación que un error pueda omitir. La seguridad a nivel de filas de Postgres limita cada consulta al subárbol de la organización del invocador, por lo que una solicitud fuera de su ámbito no tiene nada que devolver.
Pregunta por una organización o un sitio fuera de tu ámbito y la API responde con un error de no encontrado en lugar de un error de permisos. Un error de permisos confirmaría que el registro existe; el no encontrado no le revela absolutamente nada a un extraño.
Los permisos son claves granulares (módulo más acción, como sites.restart o billing.refund) y los roles las agrupan. Cuatro roles cubren las configuraciones que los equipos reales necesitan, y cada uno es un dato que inicializamos, no lógica oculta en el código.
Control total: crea organizaciones secundarias, invita y elimina miembros, cambia roles, gestiona claves de API, crea, reinicia, depura, suspende y elimina sitios, procesa facturación y facturas, abre tickets y lee el registro de auditoría. El rol que te guardas para ti.
Ve la organización, sus miembros y el catálogo de planes, y gestiona las facturas, los métodos de pago y los cargos. Sin acceso para crear, modificar o eliminar un sitio web individual: exactamente el perfil que debe tener un contable externo.
Visualiza y crea sitios, reinicia servicios, vacía la caché, administra claves de API y gestiona tickets. Se excluyen deliberadamente: facturación, facturas, métodos de pago, gestión de miembros, suspensión de sitios y eliminación de sitios. Un contratista puede desarrollar sin poder facturarle ni destruir nada.
Ve la organización, sus miembros, sus sitios, su facturación, el catálogo de planes, los tickets, el estado de la traducción y el registro de auditoría, pero no puede modificar nada de esto. El permiso adecuado para un cliente que desea visibilidad, un auditor o un inversor que solo necesita consultar.
Delegar el acceso solo es seguro si las cuentas en las que delegas son difíciles de vulnerar. La autenticación se ejecuta a través de Keycloak para cada usuario en la cuenta, en cualquier superficie.
El trabajo de soporte a veces implica mirar dentro de su cuenta. Dicho acceso se rige por el mismo modelo de permisos que todo lo demás: el personal simplemente se sitúa en una organización de personal, organizada en departamentos con concesiones limitadas.
El personal se agrupa en Soporte, Facturación y Finanzas, Abuso y Confianza y Seguridad, Ventas, Incorporación, Ingeniería y Operaciones, Marketing y Gestión. Cada rol otorga módulos y acciones específicos, por lo que un agente ve la parte de la consola de administración que su trabajo requiere y no el resto.
El rol de Agente de Soporte otorga exactamente esto: ver clientes, ver y responder tickets, ver sitios, reiniciar un sitio y purgar su caché. No conlleva configuración de facturación, ni reembolsos, ni edición de planes, ni gestión de flotas. La corrección que un agente puede realizar está limitada por el rol, no por las buenas intenciones.
El permiso customer.impersonate no forma parte del rol de gestor; está reservado exclusivamente para el Superadministrador. Cuando hay una sesión activa en tu nombre, el panel muestra un banner de suplantación persistente para que nunca haya ambigüedad sobre quién está actuando.
Cada acción con privilegios y administrativa se añade a un registro de auditoría de solo adición que registra el actor, la acción, el objetivo, los metadatos de respaldo, la dirección IP y la marca de tiempo (con partición temporal en producción). Los propietarios y los miembros de solo lectura pueden leer el registro de su organización por sí mismos.
Las acciones delicadas y destructivas del personal pueden requerir autenticación reforzada o aprobación de dos personas antes de ejecutarse, y los nuevos departamentos y roles son una configuración en lugar de un cambio de código.
Los scripts, las canalizaciones de CI, la CLI, el proveedor de Terraform y los agentes de inteligencia artificial se autentican a través del mismo modelo de permisos que las personas: sin credenciales humanas compartidas y sin secretos de larga duración pegados en una compilación.
Las claves pertenecen a una organización y tienen permisos granulares vinculados a los mismos permisos de RBAC: solo lectura, facturación y aprovisionamiento. Concede a una canalización el alcance limitado que necesita en lugar de toda la cuenta de un miembro.
Las claves de modo de prueba y de producción son distintas, por lo que una integración en desarrollo no puede acceder a los datos de producción por accidente o mediante una variable de entorno copiada.
Almacenamos un hash SHA-256 del secreto y un prefijo de búsqueda, nunca la clave sin procesar. Solo ves una clave una vez al crearla. Cada clave registra cuándo se usó por última vez y se puede revocar de forma independiente sin afectar a nada más.
Nuestro servidor MCP permite que cualquier agente compatible con MCP gestione su alojamiento en lenguaje natural, autenticado con OAuth 2.1 y limitado a su organización y rol de RBAC, con tokens revocables por herramienta, confirmación en acciones destructivas, límites de gasto y registro de auditoría completo.
El acceso a la cuenta y el acceso al servidor son problemas distintos. Las credenciales a nivel de sitio se gestionan en el panel de control, se emiten con el principio de mínimo privilegio y se aíslan para que el shell de un colaborador sea el shell de un solo sitio.
Un operador independiente mantiene una sola organización y una membresía de propietario, y añade un rol de Desarrollador cuando un contratista entra para un proyecto. Cuando el proyecto termina, la membresía se elimina y su inicio de sesión deja de funcionar de inmediato; no queda ninguna credencial compartida que deba rotarse.
Una agencia utiliza el árbol de organizaciones. Cada cliente obtiene su propia organización dependiente, que contiene los sitios de ese cliente, y las personas del propio cliente obtienen membresías allí: de solo lectura para un interesado que desea visibilidad, o de propietario para un cliente que quiere autoservicio. Su personal tiene membresías más arriba en el árbol y ve la cartera; un cliente ve solo su propia rama, y la seguridad a nivel de fila es lo que hace que eso sea una realidad en lugar de una promesa.
Un revendedor funciona de la misma manera, un nivel más arriba: una organización de revendedor contiene organizaciones de clientes, cada una con sus propios miembros, vista de facturación y sitios. El mismo principio básico alimenta a las subcuentas, los equipos de agencia y las jerarquías de revendedores; no existe un mecanismo separado y más débil para ninguno de ellos.
Todo está disponible en la prueba de 14 días sin tarjeta. Regístrese sin datos de pago, invite a un compañero, compruebe a qué puede acceder cada rol y qué no, y consulte su propio registro de auditoría.
Hoy en día, una membresía otorga su rol en toda una organización y en todo lo que se encuentra debajo de ella en la jerarquía, por lo que la forma de separar los conjuntos de sitios es separando las organizaciones: coloque esos sitios en su propia organización secundaria y conceda la membresía allí. Es un modelo limpio para agencias y revendedores, donde cada cliente ya desea su propio límite. La limitación de recursos por membresía, es decir, asignar una sola membresía a sitios específicos dentro de una misma organización, es una mejora planificada en lugar de una función disponible actualmente.
El rol de desarrollador no incluye la eliminación ni la suspensión de sitios; esas llaves pertenecen al rol de Propietario. Concede la visualización y creación de sitios, el reinicio de servicios, el vaciado de caché, la gestión de claves de API y la atención de tickets. Los permisos de despliegue y subida a producción tampoco forman parte de la concesión de Desarrollador, por lo que la promoción a producción sigue en manos del titular de la cuenta. Combina esto con un entorno de pruebas (*staging*) para que el trabajo de compilación se realice fuera del sitio en vivo desde el principio.
Depende enteramente del rol del personal, y cada rol cuenta con un conjunto limitado de claves de permisos. Un Agente de soporte, por ejemplo, puede ver su cuenta y sitios, ver y responder a sus tickets, reiniciar un sitio y purgar su caché, pero no puede tocar la configuración de facturación, reembolsos, planes ni la infraestructura. Iniciar sesión como cliente es un permiso independiente que solo posee el Superadministrador, y cuando esto ocurre, el panel muestra un banner de suplantación persistente. Cada acción con privilegios se registra en el registro de auditoría con el actor, la acción, el destino, la IP y la marca de tiempo, y usted mismo puede consultar el registro de su organización.
Elimina la membresía y su acceso a esa organización finaliza; aún conservan su propia identidad, pero no tienen ningún rol y, por lo tanto, ningún permiso en tu cuenta. Las claves de API se revoca de forma individual, por lo que se puede interrumpir una clave de canalización sin alterar nada más. Si utilizas el inicio de sesión único SAML, la baja deaprovisionamiento en tu proveedor de identidad gestiona el inicio de sesión de forma centralizada. Las credenciales a nivel de sitio, como las claves SSH, se revokan en el panel de control, y la eliminación en sí queda registrada en la auditoría.
No — pero vale la pena ser preciso sobre el motivo. Las claves de API pertenecen a la organización, no a un miembro individual, y conllevan sus propios ámbitos granulares vinculados al mismo catálogo de permisos. Así que, en lugar de entregarle una clave a una persona, creas una clave para la tarea que realiza con el ámbito más reducido que esa tarea necesita, y revocas esa clave cuando la tarea finaliza. Solo se almacena un hash del secreto, y cada clave registra cuándo se usó por última vez, por lo que las claves sin usar son fáciles de encontrar y retirar.
Sí. Nuestro servidor MCP autentica a los agentes mediante OAuth 2.1 y limita sus permisos a tu organización y a tu rol de RBAC, con tokens revocables por herramienta, de modo que concedes una capacidad específica en lugar de un acceso general. Las acciones destructivas requieren confirmación, se aplican límites de gasto y cada acción queda registrada en el mismo registro de auditoría que la actividad humana.
La seguridad a nivel de fila de Postgres limita las consultas al subárbol de la organización del emisor en la propia base de datos, utilizando el filtro a nivel de aplicación como defensa en profundidad en lugar de ser la única línea. Las solicitudes de registros fuera de alcance devuelven un error de no encontrado en lugar de un error de permiso, por lo que no se revela nada sobre lo que existe. En el lado del servidor, el aislamiento por sitio a través de CageFS mantiene la terminal y los archivos de cada inquilino en su propio sitio.
Sí. La prueba de 14 días no requiere tarjeta (sin datos de pago ni compromiso) y cubre el alojamiento Footprint-Free con un máximo de cinco sitios. Es suficiente para invitar a un colega, asignar un rol y confirmar que los límites se comportan como necesitas antes de comprometerte.
Empieza la prueba de 14 días sin tarjeta, invita a alguien y observa cómo el modelo de permisos hace su trabajo: roles que puedes nombrar, ámbitos que puedes revocar y un registro de auditoría que indica exactamente quién hizo qué.
Empieza gratis