MSP FAQ: mantenga separados el acceso humano y el de máquina entre tenants

Los MSP que compaginan el acceso de los técnicos y la automatización en decenas de tenants de clientes se enfrentan a una versión concreta de un problema sectorial en aumento: las identidades no humanas —cuentas de servicio, claves de API, tokens de automatización— deben gobernarse de forma distinta a la de los humanos que las crean.

Por qué las NHI necesitan una gobernanza separada

El proyecto Non-Human Identity Top 10 de OWASP señala que las identidades de máquina no están intrínsecamente ligadas a una persona y que los controles de seguridad habituales para los humanos, como la MFA, no se adaptan bien a ellas. El desajuste tiene que ver sobre todo con el ciclo de vida: cuando un técnico se marcha, su cuenta suele desactivarse en cuestión de horas, pero las cuentas de servicio y las claves de API que creó pueden seguir funcionando con permisos completos salvo que alguien las localice y revoque expresamente. Dado que las identidades no humanas pueden superar con creces a las cuentas humanas en los entornos modernos, un MSP que gobierne ambas de la misma manera está dejando sin gestionar, de hecho, a su mayor población de identidades.

Mejor credenciales efímeras que permanentes

La recomendación coincidente de OWASP y de la Cloud Security Alliance es sustituir los secretos de larga duración por tokens efímeros y de corta vida que caducan automáticamente, en lugar de credenciales que funcionan de forma indefinida una vez emitidas. Un token de larga duración filtrado da al atacante un tiempo ilimitado; un token que caduca en minutos u horas limita el daño incluso si se filtra.

Qué implica esto en el modelo de tenants de un MSP

• Utilice proveedores de identidad o entidades de servicio distintos para los técnicos humanos y para la automatización.
• No permita nunca que la credencial de emergencia de un técnico sirva también como credencial de servicio de una canalización.
• Vincule los tokens de máquina a un único tenant de cliente; no emita nunca una clave permanente que abarque todos los tenants.
• Mantenga la vigencia de los tokens medida en minutos u horas y rótelos ante cualquier cambio de personal o de automatización.
• Registre la clase de identidad (humana o no humana) junto con el ID de tenant en cada registro de acceso.

La solución no es una única herramienta, sino un hábito de gobernanza: trate la automatización como su propia población de identidades, con su propio ámbito de privilegios mínimos por tenant, en lugar de como una extensión del técnico que la configuró.

Fuentes: OWASP Non-Human Identities Top 10, Cloud Security Alliance — Defining Non-Human Identity.