Cuando una agencia es pequeña, gestionar el acceso de los usuarios es más una cuestión de costumbre que un proceso. Compartes las credenciales de administrador porque es más rápido, concedes acceso a nivel de empresa en MyKinsta porque crear un usuario a nivel de sitio lleva unos minutos más, y dejas a un colaborador en el sistema porque eliminarlo no es urgente.
El problema es que estos atajos terminan siendo el modelo a seguir para todos los proyectos que vienen después. Para cuando un cliente te pregunte quién ha cambiado una configuración, o resulte que un colaborador con el que dejaste de trabajar el trimestre pasado sigue teniendo acceso a un sitio en producción, ese patrón ya se habrá repetido en todo tu portfolio.
La gestión del acceso de los clientes es uno de esos problemas que va creciendo al mismo ritmo que tu agencia sin llamar la atención, hasta que sale a la luz en el peor momento posible.
El modelo de permisos de Kinsta te ofrece la infraestructura necesaria para que las decisiones sobre el acceso sean tan meditadas como cualquier otra parte del flujo de trabajo de tu agencia.
Cómo se va extendiendo silenciosamente la «expansión de accesos» dentro de una agencia en crecimiento
La expansión descontrolada de los accesos suele empezar con una decisión que en su momento tenía sentido y que se ha ido repitiendo sin revisarla. La primera vez suele ser algo sin mucha importancia, como compartir las credenciales de administrador con un cliente durante la revisión de un proyecto, porque crear una cuenta aparte te llevaría diez minutos que no tienes.
La segunda es parecida: le das a un colaborador acceso de Desarrollador de la empresa en MyKinsta porque crear un usuario a nivel de sitio te parece un trabajo extra al final de una llamada de incorporación. Ambas decisiones parecen razonables, pero ninguna se tomó pensando en el futuro.
Sin embargo, cada una de ellas sienta un precedente para el siguiente proyecto. En menos de un año, una agencia que gestiona veinte sitios de clientes puede acabar teniendo una docena de usuarios con niveles de acceso que nunca se planificaron:
- Antiguos empleados a los que nunca se les retiró el acceso al salir de la empresa.
- Colaboradores externos con permisos para proyectos que terminaron hace meses.
- Clientes que tienen acceso a datos a nivel de empresa que nunca se pensaron para ellos.
Los dos sistemas de permisos que toda agencia debe conocer
Una configuración de Kinsta incluye dos sistemas de permisos distintos. Tú controlas el acceso al entorno de alojamiento desde MyKinsta y configuras lo que los usuarios pueden hacer dentro de la aplicación a través de WordPress.
Sin embargo, como funcionan de forma independiente, la mayoría de los errores de acceso empiezan cuando se mezclan ambos conceptos.
Los roles de MyKinsta y lo que realmente controlan
MyKinsta tiene seis roles repartidos en dos niveles, y entender la diferencia entre ellos es lo que hace que el sistema te resulte útil.
Hay cuatro roles a nivel de empresa:
- Propietario de la Empresa. Solo hay uno por cuenta, y es el único que puede cancelar un plan o transferir la titularidad de la empresa. En el día a día, funciona igual que el Administrador de la Empresa y suele corresponder al responsable de la agencia.
- Administrador de la Empresa. Esto te da control total sobre todos los datos de la empresa y acceso completo a todos los sitios, incluidas las solicitudes de migración. Incluye visibilidad de la facturación y la posibilidad de cambiar de plan, así que es para los miembros más veteranos del equipo en los que confías para que se encarguen de esas responsabilidades.
- Desarrollador de la Empresa. Este rol te permite gestionar todos los sitios y DNS de la cuenta, además de los usuarios a nivel de sitio. Los desarrolladores de la empresa pueden ver la lista de usuarios de la empresa (incluidas las direcciones de correo electrónico y los roles), pero no pueden modificar el acceso a nivel de empresa ni ver los detalles de facturación. Esta es la configuración predeterminada adecuada para la mayoría de los desarrolladores internos.
- Facturación de la Empresa. Este rol sirve para dar acceso únicamente a los detalles de facturación, como facturas, nombres de empresas y direcciones. Úsalo para los contactos del departamento financiero que necesiten ver las facturas y nada más.
Los dos roles a nivel de sitio son los que determinan el acceso del cliente y del proveedor:
- Administrador del Sitio. Tienes acceso completo a un sitio específico y a todos sus entornos, incluida la gestión de DNS de ese sitio. Quienes tengan este rol no pueden eliminar el sitio de la cuenta de la empresa, enviar solicitudes de migración ni crear entornos staging premium.
- Desarrollador del Sitio. Esto te da acceso solo a los entornos staging. No pueden tocar el entorno de producción, pasar de staging a producción ni ver datos a nivel de empresa de ningún tipo.
La lógica de protección de los roles a nivel de sitio es la base de una política de acceso de clientes sólida. En resumen, el alcance de un rol de usuario se limita a un solo sitio. En el caso de un Desarrollador del Sitio, solo al entorno staging.
Los roles del panel de control de WordPress y para qué sirven
Los roles de usuario de WordPress determinan lo que los usuarios pueden hacer dentro de WordPress y son totalmente independientes de MyKinsta. Por lo tanto, un usuario puede tener un rol de WordPress sin tener acceso a MyKinsta, y viceversa.
Un error habitual es conceder a un cliente acceso de «Administrador del sitio» en MyKinsta y acceso de «Administrador de WordPress» en el mismo sitio al mismo tiempo. El resultado es que el cliente puede ajustar la configuración a nivel de servidor en un sistema, mientras que en el otro instala plugins, gestiona usuarios y cambia temas.
Es importante que el rol de WordPress se ajuste a la tarea concreta:
- Un cliente que gestiona contenido necesita acceso de Editor en WordPress y ningún acceso a MyKinsta.
- Un desarrollador que trabaje en el entorno staging necesita acceso de Desarrollador del Sitio en MyKinsta y, posiblemente, acceso de Administrador en WordPress en ese mismo entorno. Deberías revisar esto antes de la puesta en producción.
- Un cliente que se haga cargo de su sitio tras la entrega necesita acceso de Administrador del Sitio en MyKinsta y un rol de Administrador en WordPress, si sus capacidades y el alcance del proyecto lo justifican.
En ambos sistemas se aplica el mismo principio: concede solo el acceso mínimo que requiera el rol. Conceder más acceso solo porque es más fácil de explicar genera un riesgo que pasa desapercibido hasta que surge un problema.
En qué suelen equivocarse las agencias cuando involucran a los clientes
La mayoría de las agencias no acaban teniendo una configuración de acceso defectuosa por negligencia, sino por creencias razonables consideradas de forma aislada. Sin embargo, cada creencia tiene un modo de fallo que no se hace evidente hasta que las circunstancias lo provocan.
«Nos encargaremos del acceso manualmente»
La gestión manual de accesos funciona cuando el portfolio es pequeño y el equipo es estable, pero falla cuando ninguna de esas dos cosas se cumple.
Por ejemplo, un cliente al que se le concede por error acceso de Desarrollador de la Empresa porque se envió una invitación a nivel de empresa en lugar de a nivel de sitio web puede ver las direcciones de correo electrónico y los roles de todos los usuarios de tu cuenta. Del mismo modo, un colaborador al que se le haya dado acceso de Administrador de WordPress en el sitio de un proyecto puede exportar toda la tabla de usuarios, incluidos los contactos del cliente almacenados allí.
Aunque ninguno de los dos casos supone un incidente de seguridad grave, son vulnerabilidades que se habrían evitado con una política de acceso por escrito. Basta con una tabla sencilla que relacione los roles del proyecto con los de MyKinsta y los de WordPress:
| Rol del proyecto | Rol de MyKinsta | Rol de WordPress | Notas |
| Propietario de la agencia o responsable | Propietario de la empresa | Administrador | Uno por cuenta. Es el único rol que puede cancelar un plan o transferir la titularidad de la empresa |
| Desarrollador sénior o responsable de cuenta | Administrador de la empresa o desarrollador de la empresa | Administrador | Usa Administrador de la Empresa si la visibilidad de la facturación es adecuada; Desarrollador de la Empresa si no lo es |
| Colaborador externo del proyecto | Desarrollador del sitio | Administrador (solo entorno staging) | Solo acceso al entorno staging. No puedes publicar en el entorno de producción ni eliminar entornos staging |
| Cliente — gestión de contenidos | Ninguno | Editor | No necesitas visibilidad del alojamiento para las tareas de contenido |
| Cliente — titularidad tras la entrega | Administrador del sitio | Administrador | Solo si sus capacidades y el alcance del proyecto lo justifican |
Cuando la decisión ya está tomada, el paso de incorporación se convierte en una simple ejecución, en lugar de una decisión que hay que tomar bajo presión de tiempo.
«Los clientes no necesitan tanto acceso»
Limitar el acceso de los clientes parece una cuestión de gestión de riesgos, aunque en la práctica no es lo mismo. Por ejemplo, un cliente que necesite actualizar la biografía de un empleado, cambiar una imagen destacada o publicar una entrada de blog no necesita acceso al servidor.
Si no tienes un rol de WordPress que te permita hacer esas cosas, cada tarea se convierte en un ticket en tu herramienta de gestión de proyectos. Dar el acceso adecuado es una decisión que elimina las solicitudes recurrentes de tu equipo. Por ejemplo, un cliente con acceso de Editor en WordPress gestionará su propio contenido sin tener visibilidad alguna del entorno de alojamiento.
Organic Media Group, una agencia de marketing digital que gestiona portfolios de clientes en Kinsta, describe la experiencia desde el punto de vista del equipo:
Puedo incorporar a alguien nuevo al equipo y podrá gestionar algunas de estas cuentas sin ningún problema.
La misma lógica se aplica desde el punto de vista del cliente. La interfaz de MyKinsta es accesible para usuarios sin conocimientos técnicos, y la estructura de roles limita su acceso a lo que les corresponde.
«Esto aún no ha dado problemas»
Los incidentes de acceso suelen salir a la luz de inmediato o aparecer meses después, cuando se dan las circunstancias adecuadas. Por eso, un proveedor que siga teniendo acceso staging a un proyecto que terminó hace seis meses no supone ningún problema hasta que haga algún cambio. Cuanto más tiempo pase entre que se concede un permiso y la siguiente revisión, más difícil resulta reconstruir qué y cuándo ocurrió.
Además, el proceso manual de baja de usuarios puede pasar por alto constantemente ciertos problemas de acceso. Por ejemplo, eliminar a un usuario de MyKinsta no revoca automáticamente las claves API que haya podido crear ni restablece las credenciales de SSH/SFTP.
Ambas acciones requieren un paso adicional. Para revocar las claves API, ve a Configuración de la empresa > Claves API, identifica las claves que haya creado el usuario que se va y elimínalas. Para restablecer las credenciales SSH/SFTP, ve al nivel del sitio, ve a Información y vuelve a generar las credenciales. Ninguna de estas acciones se realiza automáticamente cuando se elimina a un usuario.
El registro de actividad te ayuda en esto, pero solo si lo revisas. Los administradores y desarrolladores de la empresa pueden filtrar el registro por usuario o sitio, y puedes hacer clic en cada entrada para ver la acción en detalle. Cuando des de baja a un usuario, filtra el registro por su nombre antes de eliminarlo. Así tendrás un registro de sus últimas acciones y podrás confirmar si hay algún cambio que debas revisar o revertir.
Cómo estructurar los accesos en Kinsta a medida que tu agencia crece
Primero, echa un vistazo a tu estructura de roles. Empieza desde Ajustes de la empresa > Usuarios > Invitar usuarios en MyKinsta. Desde la ventana emergente de invitación, puedes invitar hasta diez usuarios a la vez introduciendo sus direcciones de correo electrónico separadas por comas; después, elige si quieres concederles acceso a la Empresa o al Sitio.
A continuación te explicamos cómo asignar roles en un equipo de agencia estándar y para las relaciones con el cliente:
- El propietario o director de la agencia debería tener el rol de Propietario de la Empresa.
- Los desarrolladores sénior y los responsables de cuentas podrían recibir el rol de Administrador de la Empresa si el acceso a la facturación es adecuado para su puesto, o el de Desarrollador de la Empresa si no lo es. El rol de Desarrollador de la Empresa es el más adecuado por defecto para la mayoría del personal técnico interno.
- A los colaboradores externos del proyecto, asígnales el rol de Desarrollador del Sitio solo en el entorno staging correspondiente.
- Si tienes clientes con responsabilidades de gestión de contenidos, asígnales acceso de Editor en WordPress. No necesitan acceso a MyKinsta a menos que el alcance del proyecto incluya explícitamente un alojamiento autogestionado.
Para los roles específicos de un sitio (como Desarrollador del Sitio), elige Sitio en lugar de Empresa en la ventana modal de invitación. Desde ahí, busca el sitio y configura el rol correcto.
A modo de recordatorio, asigna el rol de Administrador del Sitio en MyKinsta y el rol de Administrador de WordPress a los clientes que vayan a hacerse cargo del sitio tras la entrega, si sus competencias lo permiten.
Una configuración que vale la pena activar en toda tu cuenta es la autenticación de dos factores (2FA). Kinsta exige la 2FA a todos los usuarios y soporta tanto la verificación por correo electrónico como mediante una aplicación de autenticación. Puedes ver qué método tiene activado cada usuario en Configuración de la empresa > Usuarios > 2FA. Para una agencia que gestiona varios sitios web de clientes, asegurarte de que todos los usuarios de tu cuenta tengan la 2FA activada es una medida de control básica que va de la mano con tu estructura de roles.
Traspasar un sitio a la propia cuenta del cliente
Cuando un proyecto se completa y el cliente asume la propiedad total, Kinsta te permite transferir el sitio directamente a su propia cuenta de Kinsta, en lugar de dejarlo en la tuya con los permisos reconfigurados.
Para iniciar la transferencia, ve a Sitios en MyKinsta, haz clic en el menú de los tres puntos (kebab) en la fila del sitio y, a continuación, selecciona Transferir sitio en el menú desplegable.
En el cuadro de diálogo, introduce la dirección de correo electrónico o el ID de empresa de la cuenta de destino. También puedes seleccionar cualquier dominio DNS que quieras transferir junto con el sitio y, si quieres, recomendar un plan de Kinsta al cliente. Haz clic en Transferir sitio para enviar la solicitud.
En cuanto el cliente inicia sesión en Kinsta, el sitio aparece como una Transferencia entrante en su lista de Sitios. Para aceptarla, solo tiene que hacer clic en el nombre del sitio y, a continuación, seleccionar Confirmar transferencia > Aceptar transferencia.
Realizar una revisión trimestral de accesos
Programar una revisión trimestral es una forma rápida de subsanar las carencias que se pasan por alto en el proceso diario de baja de usuarios. Primero, ve a Configuración de la empresa > Usuarios en MyKinsta y genera la lista completa de usuarios. Puedes filtrar por sitio para ver quién tiene acceso a cada propiedad del cliente.
A continuación, compara la lista con los registros de tus proyectos activos. Cualquier persona cuyo proyecto haya finalizado y que no haya sido eliminada es un dato que debes corregir. Para eliminar usuarios, haz clic en el icono de la papelera de su fila, o selecciona varios usuarios y haz clic en Eliminar.
Te recordamos que elimines cualquier clave API asociada y compruebes que se hayan renovado las credenciales de SSH/SFTP en cualquier sitio web donde haya habido cambios recientes de personal.
Tu estructura de acceso de clientes es, en realidad, una infraestructura de relaciones
La gestión de accesos es una cuestión que siempre hay que tener en cuenta y que puede tener consecuencias para la seguridad. La forma en que organizas los permisos les da a entender a los clientes si un sitio está aislado de los demás y si tu agencia funciona siguiendo un proceso o simplemente según sus costumbres.
El siguiente paso es plasmar por escrito la política de acceso utilizando la tabla de asignación de roles anterior y hacer una primera revisión trimestral de tu portfolio actual para sacar a la luz lo que ya se ha acumulado. A partir de ahí, la estructura de acceso que crees se hará visible para los clientes de la forma adecuada: un colaborador que solo pueda acceder al entorno staging, un cliente cuyas herramientas de contenido no expongan tu entorno de alojamiento, y una baja ordenada cuando termine un proyecto. Así es como funciona una agencia que opera con un proceso en lugar de con un hábito.
Para las agencias que gestionan sitios web de clientes a gran escala, el Programa para Socios de Agencias de Kinsta te ofrece soporte dedicado, recursos de venta conjunta y herramientas diseñadas pensando en cómo trabajan las agencias que alojan sus sitios en Kinsta.
