Principio de mínimo privilegio (PoLP): qué es y cómo aplicarlo

El principio de mínimo privilegio (en inglés, principle of least privilege o PoLP) dice algo que suena obvio: cada usuario, proceso o servicio debe tener solo los permisos que necesita para hacer su trabajo, y solo mientras los necesita. Ni uno de más, ni un minuto más de la cuenta.

Suena razonable, pero es una de las reglas que más se incumplen en la práctica. Y no por dejadez: dar permisos de más es cómodo, es rápido y no se nota… hasta que se nota. Cuando una cuenta con privilegios de administrador cae en malas manos, el atacante no tiene que escalar nada: ya está en la cima y desde ahí lo alcanza casi todo.

En este artículo veremos qué es exactamente el PoLP, de dónde viene, cómo se aplica a personas, grupos, procesos, servicios y cuentas de nube, por qué cuesta tanto sostenerlo y cómo implantarlo sin que parezca una aduana. Si ya controlas los modelos de permisos, el control de acceso basado en roles (RBAC) es la pieza complementaria; el mínimo privilegio es el principio que lo sostiene todo.

Qué es el principio de mínimo privilegio

El principio de mínimo privilegio es la regla de diseño por la que a cada entidad —una persona, una cuenta, un proceso o un servicio— se le concede únicamente la capacidad de hacer aquello para lo que fue creada, y nada más. Todo lo que no esté explícitamente permitido queda denegado.

La formulación clásica es de Jerome Saltzer y Michael Schroeder, que en 1975 publicaron «The Protection of Information in Computer Systems» en las actas del IEEE, uno de los textos fundacionales de la seguridad informática. De ahí sale la frase que se sigue citando medio siglo después: cada programa y cada usuario del sistema deben operar con el menor conjunto de privilegios necesario para completar su tarea. Puedes consultar el texto original en el repositorio del MIT.

Pese a su antigüedad, la idea sigue vigente. El NIST la recoge como control explícito AC-6 en su catálogo de controles de seguridad, la publicación NIST SP 800-53 Rev. 5, y casi todos los marcos modernos la dan por sentada como punto de partida.

Conviene no confundirlo con «dar pocos permisos». El objetivo no es repartir escasez, sino dar los permisos justos. Un contable que no puede abrir su propia aplicación de contabilidad no está mejor protegido: está bloqueado. El mínimo privilegio no va de negar, va de ajustar.

Por qué importa tanto

Importa porque el exceso de privilegios es el multiplicador silencioso de casi cualquier incidente. Un atacante que consigue una credencial de usuario corriente puede hacer un daño limitado; si esa credencial es de un administrador, el mismo acceso se convierte en llave maestra: borrar bases de datos, instalar software malicioso, crear cuentas nuevas, desactivar copias de seguridad o leer información que ni le correspondía.

La lógica es la del daño potencial. Con más permisos de los necesarios ocurren dos cosas a la vez: es más probable que alguien cometa un error, y es más grave cuando lo comete. El mínimo privilegio reduce las dos caras del riesgo —el accidente y el ataque— limitando lo que una identidad puede llegar a hacer: no impide que te roben la llave, pero hace que la llave abra menos puertas.

En qué se aplica: personas, grupos, procesos y servicios

El PoLP no es exclusivo de las cuentas humanas. Se aplica a cualquier entidad que acceda a un recurso, y en la práctica abarca tres frentes que conviene tratar por separado.

Usuarios y grupos

El caso más conocido. A una persona se le asignan únicamente los permisos que su función requiere, y la recomendación habitual es asignar permisos a grupos, no a individuos: es más fácil auditar un grupo que cien excepciones sueltas, y da menos trabajo cuando alguien entra o sale de la organización.

Si Juan es contable, lo sensato no es darle privilegios de creación de plantillas «porque a veces los necesita», sino incorporarlo al grupo de contabilidad y que el grupo tenga exactamente lo que la contabilidad necesita. Cuando Juan cambie de puesto, se cambia su membresía y ya está. Ese enfoque es, en esencia, lo que formaliza el modelo RBAC: los permisos viajan con el rol, no con la persona.

Procesos y cuentas de servicio

Aquí está la parte que más se descuida. Los procesos y servicios también acceden a recursos, y muchas veces lo hacen con cuentas todopoderosas porque «así funcionaba y no lo tocamos». Si un servicio web se ejecuta como root o como administrador del dominio, una vulnerabilidad en ese servicio entrega al atacante los mismos privilegios que tuviera el proceso.

La práctica correcta es la contraria: crear una cuenta específica de bajo privilegio para cada servicio, darle solo lo que ese servicio necesita y aislarlo del resto. En Linux, eso significa ejecutar demonios con usuarios dedicados y usar sudo para elevaciones puntuales y auditables; en contenedores, no ejecutar el proceso como root salvo que sea imprescindible.

Accesos temporales: el privilegio «just in time»

A veces alguien necesita algo para lo que no está autorizado: un comercial que debe crear un registro puntual de un cliente nuevo, un técnico que tiene que reiniciar un servicio una madrugada. La respuesta no es subirle el privilegio de forma permanente, sino concederlo de forma temporal.

Lo ideal es que ese acceso lo conceda un proceso automático con caducidad: se añade al usuario a un rol elevado y, pasadas dos horas, se le retira sin intervención manual. Así el privilegio dura exactamente lo que dura la tarea. Este patrón se conoce como just-in-time access (acceso justo a tiempo) y es una de las aplicaciones más útiles del PoLP en organizaciones con mucha rotación de tareas.

Cuentas privilegiadas: el objetivo más codiciado

Una cuenta privilegiada es la que tiene acceso a todo, o casi todo: las cuentas de administrador, de superusuario o de root. Si un atacante o un programa malicioso se hace con esas credenciales, puede destruir un sistema operativo entero, vaciar una base de datos o desactivar las defensas desde dentro. Por eso el número de personas con acceso a ellas debe ser mínimo y su uso, excepcional.

En Linux y macOS el superusuario se llama root y su uso directo está desaconsejado; en Windows se llama Administrator y el control de cuentas de usuario (UAC) obliga a elevar permisos de forma explícita con la opción «Ejecutar como administrador». Ese diálogo no es un estorbo: es el mínimo privilegio funcionando en el escritorio. Un error frecuente es dejar que la cuenta de uso diario sea administradora; si se infecta navegando por una web comprometida o abriendo un adjunto malicioso, el malware hereda permisos totales.

Cuentas privilegiadas en la nube

En la nube el problema se multiplica, porque el perímetro desaparece y las identidades son la nueva frontera. Las tres grandes plataformas ofrecen un sistema de gestión de identidades y accesos (IAM) para repartir permisos con criterio:

• AWS. El servicio IAM permite crear usuarios, roles y políticas. La cuenta raíz es un superusuario total y solo debería usarse para tareas imprescindibles; el día a día se hace con identidades de permisos acotados, protegidas con autenticación multifactor (MFA).
• Microsoft Azure. El acceso a los recursos se gobierna con Azure RBAC, y la elevación temporal se gestiona con Privileged Identity Management (PIM), pensado precisamente para no tener permisos de administrador permanentes.
• Google Cloud. Su IAM reparte roles sobre los recursos, y servicios como Cloud KMS centralizan la gestión de claves para que el acceso al material criptográfico también esté controlado.

La idea es la misma que en un servidor físico: quien solo necesita consultar informes de una base de datos no debe poder modificar ni insertar registros. Planificar ese reparto es trabajo del equipo de seguridad, y hacerlo mal está detrás de buena parte de los sustos en la nube.

Cómo se cuela un atacante cuando no se aplica

Sin mínimo privilegio, la cadena de un incidente se acorta peligrosamente. Estos son los vectores más habituales:

• Robo de credenciales. El phishing y la reutilización de contraseñas siguen siendo la puerta de entrada más común. Si la credencial robada es de un usuario corriente, el daño se limita; si es de un administrador, el atacante entra por la puerta principal.
• Movimiento lateral. Con permisos amplios, quien ya está dentro salta de un sistema a otro sin obstáculos. El mínimo privilegio levanta compartimentos: comprometer uno no significa comprometer todos.
• Amenaza interna. Un empleado con acceso a información que no le corresponde podría copiarla o venderla. Reducir el alcance de cada cuenta limita también lo que puede extraer.
• Malware y ransomware. Un virus informático que se ejecuta con permisos de administrador puede cifrar todo lo que alcanza; con una cuenta limitada, su radio de acción se reduce de forma drástica.

Un caso que se cita mucho para ilustrar el coste de no limitar accesos ni segmentar bien es el de Equifax en 2017: la brecha expuso datos de unos 147 millones de personas y en 2019 la compañía llegó a un acuerdo con la Comisión Federal de Comercio de Estados Unidos (FTC) por el que pagaría entre 575 y 700 millones de dólares. La FTC lo documenta en su comunicado. El episodio recuerda que un fallo sin parchear, sumado a controles de acceso y segmentación insuficientes, puede convertirse en uno de los incidentes más caros de la historia.

Los beneficios de aplicarlo

Aplicar el principio de mínimo privilegio no solo evita desastres; también mejora el funcionamiento cotidiano. Sus ventajas principales:

Beneficio	Qué significa en la práctica
Menos superficie de ataque	Cada cuenta con permisos de más es una puerta adicional. Reducirlas reduce las vías de entrada posibles.
Menor impacto de un incidente	Si una cuenta se ve comprometida, el atacante se encuentra con un límite. El daño deja de ser total.
Datos mejor protegidos	El acceso a información sensible queda restringido a quienes realmente la necesitan.
Trazabilidad y auditoría	Es más fácil explicar quién podía hacer qué, requisito habitual en normativas y auditorías.
Menos tiempo de recuperación	Cuando un incidente afecta a menos sistemas, recuperarse cuesta menos horas y menos dinero.

Por qué es tan difícil de aplicar

Si el principio es tan sensato, ¿por qué casi nadie lo tiene bien resuelto? Porque choca con la comodidad y con la complejidad real de las organizaciones.

El primer obstáculo es la inercia. Muchas empresas arrancan dando privilegios de administrador a todo el mundo «para no tener problemas» y, cuando quieren corregirlo, se topan con resistencias. Retirar privilegios ya concedidos genera fricción; hay que explicar por qué se hace, que la seguridad es cosa de todos y que un ataque exitoso daña también la reputación de los propios empleados.

El segundo es la productividad. Quien se queda sin permisos que necesita se bloquea y acaba dependiendo de otra persona para cada gestión, con la consiguiente frustración. El objetivo no es maximizar la restricción, sino encontrar el equilibrio: el mínimo suficiente para trabajar con fluidez. Si el resultado es un cuello de botella, el diseño está mal.

El tercero es la fragmentación. Un mismo empleado usa hoy decenas de aplicaciones, unas en local y otras en la nube, cada una con su propio sistema de roles. Configurar el PoLP aplicación a aplicación es laborioso; hacerlo bien entre sistemas que además se hablan entre sí, mucho más. Y muchas funciones se rompen al recortar permisos, lo que tienta a conceder «un poco más» y acaba deshaciendo el trabajo.

El cuarto es el abandono. Un modelo de permisos se estropea por falta de mantenimiento: entran personas, cambian de puesto, se van, y los permisos antiguos siguen ahí años después. Sin revisiones periódicas, el mínimo privilegio se degrada solo y vuelve al punto de partida.

Mínimo privilegio y Zero Trust

El Zero Trust («confianza cero») es un modelo que parte de una premisa incómoda: no existe una red interna de confianza. Da igual si la petición viene de dentro o de fuera del perímetro; cada acceso debe autenticarse y autorizarse. El NIST lo describe en la publicación SP 800-207 como la desaparición del privilegio implícito que se concedía por estar en la red corporativa.

El mínimo privilegio es, en ese marco, la pieza que decide qué puede hacer quien ya ha demostrado quién es. La guía de Zero Trust de CISA lo formula de forma muy directa: el objetivo es tomar decisiones de acceso «con mínimo privilegio, petición a petición». En la práctica, Zero Trust se apoya en dos mecanismos que ya hemos visto: la elevación temporal y el mínimo privilegio suficiente, que juntos evitan el privilegio permanente.

Qué dicen los marcos y las normativas

El mínimo privilegio no es una recomendación suelta: aparece recogido en la mayoría de marcos y estándares de seguridad, lo que en la práctica lo convierte en algo exigible en cualquier auditoría.

• NIST SP 800-53 (control AC-6). El catálogo de controles del NIST dedica un control específico al mínimo privilegio y exige cuentas sin privilegios para las tareas cotidianas, elevando permisos solo cuando sea necesario.
• OWASP Top 10. El «control de acceso roto» encabeza la lista de riesgos de aplicaciones web de 2021; su A01 insiste en denegar por defecto y verificar permisos en cada petición. La guía de control de acceso de OWASP concreta cómo llevarlo al código.
• CIS Benchmarks y CIS Controls. Las recomendaciones del Center for Internet Security incluyen el mínimo privilegio entre sus prácticas básicas de endurecimiento de sistemas.
• Normativas de cumplimiento. Marcos como ISO/IEC 27001, SOC 2 o PCI DSS exigen, con distintos nombres, control de acceso, segregación de funciones y trazabilidad de permisos. El PoLP es la forma habitual de demostrarlo.
• Protección de datos. El Reglamento General de Protección de Datos (RGPD) exige medidas de seguridad e integridad y minimización del acceso a datos personales; limitar quién puede leerlos forma parte de ese cumplimiento.

Cómo implantarlo paso a paso

Poner el mínimo privilegio en marcha es un proyecto, no un interruptor. El orden que suele funcionar es este:

1. Inventariar. Antes de recortar nada, hay que saber qué cuentas existen, a qué acceden y quién las usa. Las cuentas huérfanas y las de servicio olvidadas son las que más sorpresas dan.
2. Definir roles y funciones. Traducir el organigrama a un mapa de roles con permisos claros. Es la parte más difícil, y es análisis del negocio, no configuración.
3. Partir de cero. La regla es «denegar por defecto»: se empieza sin permisos y se conceden los justos, nunca al contrario. Conceder y luego retirar siempre cuesta más.
4. Usar grupos, no excepciones. Los permisos van a roles o grupos; las excepciones individuales, cuanto menos, mejor.
5. Añadir elevación temporal. Para los casos puntuales, acceso con caducidad automática en lugar de privilegio permanente.
6. Separar funciones. Quien aprueba un pago no debería poder ejecutarlo; quien administra un servidor no debería poder borrar sus propios registros.
7. Probar en un entorno de pruebas. Se replica el modelo, se pide al personal que trabaje con él un tiempo y se corrigen los fallos antes de tocar producción.
8. Desplegar por fases. Es habitual que el sistema antiguo y el nuevo convivan semanas o meses hasta validar el nuevo; una prueba piloto de al menos un mes, con el viejo como red de seguridad, reduce el riesgo de parón.
9. Auditar y supervisar. Se revisan los permisos con periodicidad, se retiran los que ya no corresponden y se vigila qué recursos se usan. La monitorización continua es la única forma de detectar que el modelo se degrada.

Cuando toca verificar que el modelo aguanta, no hay nada como ponerlo a prueba: las organizaciones que maduran en seguridad contratan pruebas de intrusión autorizadas para comprobar si los límites de permisos resisten. Es el terreno de los sombreros blancos, que buscan los huecos antes de que lo haga un atacante real.

Errores comunes que estropean el modelo

• Convertir el administrador en cuenta de uso diario. La cuenta de administrador se usa para administrar, no para leer el correo.
• Permisos «temporales» que nunca se retiran. Un acceso puntual sin fecha de caducidad es un acceso permanente con otro nombre.
• Ignorar las cuentas de servicio. Son cuentas sin persona detrás, con contraseñas que nadie cambia y privilegios que nadie revisa.
• Compartir cuentas privilegiadas. Si varias personas usan la misma cuenta de administrador, se pierde la trazabilidad: nadie sabe quién hizo qué.
• No revisar tras los cambios de puesto. Los permisos heredados de funciones anteriores se acumulan y acaban por encima de lo necesario.

Preguntas frecuentes

¿Qué es el principio de mínimo privilegio en una frase?

Dar a cada usuario, proceso o servicio solo los permisos imprescindibles para su tarea, y solo durante el tiempo necesario. Todo lo demás queda denegado por defecto.

¿PoLP y RBAC son lo mismo?

No. RBAC es un modelo concreto para organizar permisos mediante roles; el mínimo privilegio es el principio de diseño que dice cuántos permisos debe tener cada uno. RBAC es una forma práctica de aplicar el PoLP, pero el principio también se puede aplicar con otros modelos, como ABAC.

¿Qué es una cuenta privilegiada?

Una cuenta con permisos de administrador o superusuario, capaz de modificar el sistema casi sin límites: root en Linux y macOS, Administrator en Windows, o la cuenta raíz de un proveedor de nube. Debe usarse lo mínimo posible y protegerse con contraseñas robustas y autenticación multifactor.

¿En qué se diferencia del Zero Trust?

Zero Trust es el marco que elimina la confianza implícita en la red y verifica cada acceso; el mínimo privilegio es el criterio con el que se decide cuánto se concede a quien ya se ha autenticado. Son complementarios: Zero Trust necesita al mínimo privilegio para funcionar.

¿Cada cuánto hay que revisar los privilegios?

Depende del tamaño y la criticidad de la organización, pero conviene una revisión periódica —trimestral o al menos anual— y, sobre todo, revisiones ligadas a eventos: altas, bajas, cambios de puesto y auditorías. Sin revisión, el modelo se degrada con el tiempo.

Conclusión

El principio de mínimo privilegio es una de esas ideas que caben en una frase y cuestan años de sostener. No es una herramienta que se instala, sino una disciplina que se mantiene: conceder lo justo, por el tiempo justo, y revisar a menudo que sigue siendo lo justo.

Su fuerza está en que actúa antes del incidente. No promete impedir que te roben una credencial; promete que esa credencial, en manos equivocadas, no sirva para arrasarlo todo. Si quieres seguir tirando de este hilo, el control de acceso basado en roles explica cómo estructurar los permisos una vez decidido el principio, y qué es un hacker ayuda a entender desde el otro lado por qué conviene no dejarse puertas abiertas.