Acceso delegado
Incorpore a un desarrollador, delegue la facturación en su contable, conceda a un cliente acceso de solo lectura a sus propios sitios o permita que nuestro equipo de soporte examine un problema. Cada concesión es un rol con permisos definidos, circunscrito a una organización, aplicado en la base de datos y registrado en un historial de auditoría de solo adición.
Compartir un solo inicio de sesión es el motivo por el cual 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 usted puede otorgar, modificar o revocar de manera independiente.
Cada colaborador inicia sesión con su propia cuenta a través de Keycloak, nuestra capa de identidad. Nadie escribe su 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 esfuerzo 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. La membresía se aplica a una organización y a todo lo que esté por debajo de ella, de modo que usted 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 fila (Row-Level Security) de Postgres delimita cada consulta al subárbol de la organización del solicitante, por lo que una solicitud fuera de su alcance no tiene nada que devolver.
Si solicita una organización o un sitio fuera de su alcance, la API responderá con un simple «no encontrado» en lugar de un error de permisos. Un error de permisos confirmaría la existencia del registro; «no encontrado» no revela absolutamente nada a un tercero.
Los permisos son claves granulares (módulo más acción, como sites.restart o billing.refund) y los roles los agrupan. Cuatro roles cubren las estructuras que los equipos reales necesitan, y cada uno de ellos son datos que suministramos, no lógica oculta en el código.
Control total: cree organizaciones secundarias, invite y elimine miembros, cambie funciones, administre claves de API, cree, reinicie, purgue, suspenda y elimine sitios, gestione la facturación y las facturas, genere tickets y consulte el registro de auditoría. El rol que se reserva para usted.
Ve la organización, sus miembros y el catálogo de planes, y gestiona facturas, métodos de pago y cargos. Sin acceso para crear, modificar o eliminar ningún sitio: exactamente la configuración que debe tener un contable externo.
Visualiza y crea sitios, reinicia servicios, purga la caché, gestiona claves de API y gestiona incidencias. Deliberadamente excluidos: facturación, facturas, métodos de pago, gestión de miembros, suspensión de sitios y eliminación de sitios. Un contratista puede crear 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, y no puede modificar nada de ello. La autorización adecuada para un cliente que desea visibilidad, un auditor o una parte interesada que solo necesita consultar.
Delegar el acceso solo es seguro si las cuentas en las que delega son difíciles de vulnerar. La autenticación se realiza a través de Keycloak para cada persona en la cuenta, en todas las plataformas.
El trabajo de soporte técnico a veces requiere consultar el interior de su cuenta. Dicho acceso se rige por el mismo modelo de permisos que todo lo demás: el personal simplemente forma parte de una organización de empleados, estructurada en departamentos con permisos estrictamente acotados.
El personal se agrupa en Soporte, Facturación y Finanzas, Abuso y Confianza y Seguridad, Ventas, Incorporación, Ingeniería y Operaciones, Marketing y Dirección. Cada rol otorga módulos y acciones específicos, de modo que un agente ve únicamente 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 a tickets, ver sitios, reiniciar un sitio y purgar su caché. No incluye configuración de facturación, reembolsos, edición de planes ni gestión de flotas. Las medidas correctivas que un agente puede realizar están limitadas por el rol, no por las buenas intenciones.
El permiso customer.impersonate no forma parte del rol Manager; solo lo ostenta Super Admin. Cuando se ejecuta una sesión en su nombre, el panel de control muestra un banner persistente de suplantación para que nunca haya dudas de quién está actuando.
Cada acción administrativa y con privilegios se anexa 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 — particionado por tiempo en producción. Los propietarios y los miembros de solo lectura pueden leer el registro de su organización por sí mismos.
Las acciones confidenciales y destructivas del personal pueden requerir una autenticación reforzada o la aprobación de dos personas antes de ejecutarse, y los nuevos departamentos y roles son cuestión de configuración y no de un cambio de código.
Los scripts, las canalizaciones de CI, la CLI, el proveedor de Terraform y los agentes de IA se autentican mediante el mismo modelo de permisos que las personas: sin credenciales humanas compartidas, sin secretos de larga duración pegados en una compilación.
Las claves pertenecen a una organización y conllevan alcances granulares vinculados a los mismos permisos RBAC: solo lectura, facturación, aprovisionamiento. Otorgue a una canalización el alcance limitado que necesita en lugar de la cuenta completa de un miembro.
Las claves del modo de prueba y del modo en vivo son distintas, por lo que una integración en desarrollo no puede acceder a los datos de producción por accidente ni mediante una variable de entorno copiada.
Almacenamos un hash SHA-256 del secreto y un prefijo de búsqueda, nunca la clave sin procesar. Verá la clave solo una vez al momento de su creación. Cada clave registra cuándo se utilizó 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 cuestiones diferentes. Las credenciales a nivel de sitio se administran en el panel de control, se emiten con privilegios mínimos y se aíslan para que el shell de un colaborador sea únicamente el shell de un sitio.
Un operador individual mantiene una sola organización y una membresía de propietario, y añade un rol de Desarrollador cuando un contratista se incorpora para un proyecto. Cuando el proyecto finaliza, 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 organización. Cada cliente obtiene su propia organización secundaria, que alberga sus sitios, y el personal del cliente obtiene membresías en ella: de solo lectura para una parte interesada que desee visibilidad, o de propietario para un cliente que prefiera el autoservicio. Su personal dispone de membresías en niveles superiores del árbol y puede ver la cartera; el cliente solo ve su propia rama, y Row-Level Security es lo que convierte esto en una realidad y no en una simple promesa.
Un distribuidor funciona de la misma manera, un nivel más arriba: una organización de distribuidor contiene organizaciones de clientes, cada una con sus propios miembros, vista de facturación y sitios. El mismo elemento básico impulsa las subcuentas, los equipos de agencias y las jerarquías de distribuidores; no existe un mecanismo independiente 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 colega, observe a qué puede y no puede acceder cada rol y consulte su propio registro de auditoría.
Actualmente, una membresía otorga su rol en toda una organización y en todo lo que se encuentre por debajo de ella en la estructura, por lo que la forma de separar conjuntos de sitios es separar las organizaciones: coloque esos sitios en su propia organización secundaria y otorgue la membresía allí. Es un modelo claro para agencias y revendedores, donde cada cliente ya desea su propio límite. La delimitación de recursos por membresía, vinculando una única membresía a sitios específicos dentro de una organización, es una mejora planificada y no algo disponible en este momento.
El rol Developer no incluye la eliminación ni la suspensión de sitios; esas funciones corresponden al rol Owner. Permite ver y crear sitios, reiniciar servicios, purgar la caché, gestionar claves de API y gestionar tickets. Los permisos de despliegue y push-to-live tampoco forman parte de las asignaciones de Developer, por lo que el paso a producción permanece en manos del propietario de la cuenta. Combine esto con el entorno de pruebas para que el trabajo de desarrollo se realice desde el principio fuera del sitio activo.
Depende totalmente del rol del personal, y cada rol es un conjunto restringido de claves de permisos. Un agente de soporte, por ejemplo, puede ver su cuenta y sus sitios, ver y responder a sus incidencias, reiniciar un sitio y vaciar su caché — y no puede modificar la configuración de facturación, los reembolsos, los planes ni la flota. Iniciar sesión como cliente es un permiso independiente que solo posee el Super Admin, y cuando ocurre, el panel de control muestra un aviso persistente de suplantación. Cada acción con privilegios se registra en el registro de auditoría con el autor, la acción, el objetivo, la IP y la marca de tiempo, y usted mismo puede leer el registro de su organización.
Elimine la membresía y su acceso a esa organización finalizará; seguirán conservando su propia identidad, pero no tendrán ningún rol y, por lo tanto, ningún permiso en su cuenta. Las claves de API se revocan individualmente, por lo que se puede anular una clave de pipeline sin alterar nada más. Si utiliza el inicio de sesión único con SAML, el desaprovisionamiento en su proveedor de identidades gestiona el inicio de sesión de forma centralizada. Las credenciales a nivel de sitio, como las claves SSH, se revocan en el panel de control y la eliminación en sí queda registrada en el registro de auditoría.
No — pero vale la pena precisar el motivo. Las claves de API pertenecen a la organización, no a un miembro individual, y cuentan con sus propios alcances granulares vinculados al mismo catálogo de permisos. Por lo tanto, en lugar de entregar una clave a una persona, usted crea una clave para la tarea en cuestión con el alcance más restringido que dicha tarea requiera, y revoca esa clave cuando la tarea finaliza. Solo se almacena un hash del secreto, y cada clave registra cuándo se utilizó por última vez para que sea fácil encontrar y retirar las claves sin usar.
Sí. Nuestro servidor MCP autentica a los agentes con OAuth 2.1 y limita su alcance a su organización y a su rol de RBAC, con tokens revocables por herramienta, de modo que usted otorga 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 solicitante dentro de la propia base de datos, considerando el filtro a nivel de aplicación como una defensa en profundidad y no como la única línea. Las solicitudes de registros fuera del alcance devuelven un error de no encontrado en lugar de un error de permisos, por lo que no se revela nada sobre lo que existe. En el lado del servidor, el aislamiento por sitio mediante CageFS mantiene el shell 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) e incluye el alojamiento Footprint-Free con hasta cinco sitios. Es suficiente para invitar a un colega, asignar un rol y confirmar que los límites funcionan como usted necesita antes de comprometerse.
Comience con la prueba de 14 días sin necesidad de tarjeta, invite a alguien y observe cómo el modelo de permisos hace su trabajo: roles a los que puede asignar un nombre, ámbitos que puede revocar y un registro de auditoría que detalla con exactitud quién hizo qué.
Empiece gratis