En teoría, el Principio de Mínimo Privilegio (PoLP, Principle of Less Privilege, por sus siglas en inglés) es la regla más básica de la ciberseguridad: dale a un usuario solo los permisos estrictamente necesarios para hacer su trabajo, y ni uno más. En la práctica, es el concepto más pisoteado en cualquier infraestructura IT.
Pero muchas veces el día a día manda. El desarrollador necesita acceso total a la base de datos «solo un momento» para depurar un error, el CEO exige ser administrador local de su portátil porque no quiere abrir un ticket para instalar Spotify, y una aplicación legacy requiere permisos de Domain Admin porque si no, inexplicablemente, no arranca. Y así, parche a parche, tu red se convierte en un campo de minas.
En este artículo vamos a dejarnos de definiciones de manual. Vamos a ver por qué la falta de mínimo privilegio es la causa raíz de los peores desastres de seguridad, cómo aplicarlo en entornos reales (incluyendo infraestructuras Cloud mediante IAM) y cómo empezar a revocar accesos sin que el resto de la empresa pida tu cabeza.
Índice de contenidos
¿Qué es realmente el Principio de Mínimo Privilegio? (Más allá del manual)
El concepto base (least privilege) es simple: limitar el acceso a recursos del sistema al mínimo indispensable. Pero el error más común es pensar que esto solo aplica a los empleados.
El principio de mínimo privilegio debe aplicarse a usuarios, aplicaciones, redes, cuentas de servicio y procesos.
Piénsalo con una analogía del mundo físico: si contratas a un fontanero para arreglar una tubería en la cocina, le abres la puerta de casa y le indicas dónde está la cocina. No le das la llave de la caja fuerte, ni las llaves de tu coche, ni le das acceso a tu cuenta bancaria «por si necesita comprar materiales».
En IT, sin embargo, hacemos esto a diario cuando ejecutamos un script cotidiano con permisos de root o asignamos roles genéricos en la nube.
Por qué saltarse esta regla es el mejor regalo para un atacante
Los actores de amenazas rara vez «hackean» para entrar a tu red; hoy en día, simplemente inician sesión. Y una vez dentro, lo que define el impacto del ataque no es por dónde entraron, sino qué pueden hacer con la cuenta que acaban de comprometer.
Si un empleado de marketing cae en un ataque de phishing y su equipo está configurado bajo el principio de mínimo privilegio, el atacante solo podrá acceder a los recursos de marketing. Es un problema, sí, pero contenido.
Sin embargo, si ese mismo empleado es administrador local de su máquina, el atacante puede:
- Desactivar el antivirus o EDR.
- Volcar las credenciales de la memoria (pass-the-hash o mimikatz) buscando la sesión de algún técnico de soporte que se haya logueado en ese equipo recientemente.
- Iniciar un movimiento lateral hacia servidores críticos.
- Desplegar un ransomware que cifre toda la red.
El PoLP actúa como un sistema de compartimentos estancos en un barco. Si hay una brecha, se inunda una habitación, no se hunde el barco entero.
La pesadilla del Privilege Creep (El síndrome del «por si acaso»)
Uno de los mayores enemigos del mínimo privilegio no es una mala configuración inicial, sino el tiempo. Es lo que en la industria conocemos como Privilege Creep (acumulación de privilegios).
Imagina a un empleado que entra en el departamento de Soporte Técnico. Se le otorgan ciertos permisos. Dos años después, es ascendido a Administrador de Sistemas; se le añaden nuevos accesos. Más tarde, pasa a ser responsable de Operaciones.
A lo largo de su ciclo de vida en la empresa, a este usuario se le han ido sumando permisos, pero rara vez se le ha revocado el acceso de sus puestos anteriores. Con el tiempo, los empleados más veteranos se convierten en auténticos «administradores en la sombra» con acceso a facturación, bases de datos de producción y repositorios de código, simplemente porque «siempre lo han tenido».
Limpiar esto sin romper flujos de trabajo es uno de los mayores retos de un equipo IT.
Caso de uso: IAM en Cloud y el peligro de los permisos comodín (*)
Para entender la criticidad del PoLP hoy en día, no hay mejor ejemplo que la Gestión de Identidades y Accesos (IAM) en entornos Cloud como AWS, Azure o Google Cloud. En la nube, la identidad es el nuevo perímetro.
Imaginemos que un equipo de desarrollo necesita que una aplicación lea archivos de un bucket de almacenamiento (por ejemplo, Amazon S3). Por las prisas, el administrador de IAM crea una política JSON rápida:
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}Ese asterisco (*) es la antítesis del mínimo privilegio. Le acaba de decir al sistema: «Permite a esta aplicación hacer cualquier cosa (s3:*) en todos los buckets de la empresa (Resource: *)».
Si un atacante compromete esa aplicación, no solo podrá leer los archivos que la app necesitaba, sino que podrá borrar todos los buckets de la empresa, descargar bases de datos de clientes o modificar archivos críticos.
Aplicando PoLP en IAM, la política correcta debería ser quirúrgica:
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-facturas-2024/*"
}Ahora, la aplicación solo puede leer (GetObject) y solo en ese bucket específico. Si cae en manos hostiles, el radio de explosión es menor.
Cómo implementar «Least Privilege» en el mundo real
Aplicar PoLP en una empresa que lleva años funcionando con el «todo abierto» es un proyecto de gestión del cambio, no solo un cambio técnico. Si lo haces de golpe, pararás la producción. Estos son los pasos lógicos:
Auditoría inicial: Descubre quién tiene las llaves del reino
No puedes proteger lo que no ves. Antes de quitar nada, audita. Revisa quién está en los grupos de Domain Admins, Enterprise Admins o Global Administrators (en Microsoft Entra ID). Te sorprenderá la cantidad de cuentas que no deberían estar ahí.
Implementar RBAC (Roles) en lugar de permisos por usuario
Nunca asignes permisos directamente a «María» o «Juan». Asigna permisos a un rol llamado Auditor-Financiero o DevOps-Backend, y luego mete a María y a Juan en esos grupos. Esto facilita enormemente revocar permisos cuando alguien cambia de departamento (RBAC – Role-Based Access Control).
PAM y Just-In-Time (JIT): Permisos con fecha de caducidad
Nadie necesita ser Administrador Global las 24 horas del día, los 7 días de la semana, ni siquiera el director de IT. Utiliza soluciones PAM (Privileged Access Management) para implementar accesos Just-In-Time.
Si un técnico necesita reiniciar un servidor, solicita la elevación de privilegios. El sistema le otorga el permiso de administrador durante 2 horas y, al terminar el tiempo, el permiso se revoca automáticamente.
Cuentas de servicio: El agujero negro silencioso
Las cuentas de servicio (las que usan las aplicaciones para hablar entre ellas) suelen ser el punto ciego de la seguridad. Muchas tienen permisos de administrador de dominio y sus contraseñas no se han cambiado en cinco años por miedo a romper la aplicación.
Identifícalas, aísla sus permisos y, si usas entornos Microsoft, migra a cuentas de servicio administradas de grupo (gMSA) siempre que sea posible.
Checklist: Por dónde empezar mañana por la mañana
Si quieres mejorar la postura de tu empresa esta misma semana sin grandes presupuestos, empieza por aquí:
- Elimina los administradores locales: Ningún usuario estándar (ni siquiera el CEO) debería usar su equipo en el día a día con permisos de administrador local. Usa herramientas de LAPS (Local Administrator Password Solution) para gestionar estas contraseñas.
- Aplica MFA estricto a las cuentas privilegiadas: Si una cuenta tiene poder para destruir la infraestructura, una contraseña no es suficiente. El MFA aquí no es negociable.
- Separa las cuentas de administración: Un administrador de sistemas debería tener su cuenta normal (
j.perez) para leer el correo y navegar por internet, y una cuenta separada (admin.j.perez) exclusiva para tareas críticas. - Revisa los accesos de terceros: Proveedores, agencias y soporte externo suelen quedarse con accesos activos meses después de terminar su trabajo. Deshabilítalos por defecto.
Conclusión
El Principio de Mínimo Privilegio no es una casilla que marcas en una auditoría y te olvidas. Es una postura continua. Implementarlo genera fricción operativa al principio: los usuarios se quejarán porque ya no pueden instalarse sus propios programas y los desarrolladores protestarán porque tienen que definir bien sus políticas IAM.
Sin embargo, cuando un malware entre en tu red —y entrará—, el hecho de que no pueda moverse lateralmente ni escalar privilegios será la diferencia entre restaurar un solo equipo portátil o tener que salir en las noticias explicando por qué se han filtrado los datos de todos tus clientes.
