El principio de mínimo privilegio: por qué nadie debería tener más acceso del que necesita

21/09/2026

Es común que, dentro de una organización, alguien pida "por las dudas" permisos de administrador para no tener que solicitar acceso cada vez que necesita algo puntual, y que esa solicitud se apruebe sin mayor análisis porque parece más simple que negarla. Ese gesto aparentemente inofensivo es, en términos de seguridad de la información, exactamente lo contrario de lo que recomienda uno de los principios más antiguos y mejor documentados del diseño de sistemas seguros: el principio de mínimo privilegio.

El origen del principio

La formulación más citada de este principio aparece en un trabajo académico fundacional de la seguridad informática, "The Protection of Information in Computer Systems", publicado en 1975 por Jerome H. Saltzer y Michael D. Schroeder en las Proceedings of the IEEE. Los autores enumeraron una serie de principios de diseño para sistemas seguros, y uno de ellos, el de "least privilege" (mínimo privilegio), establece que cada proceso o usuario debe operar utilizando el conjunto más reducido posible de privilegios necesario para completar su tarea, y nada más. El artículo de Saltzer y Schroeder es, todavía hoy, medio siglo después, una de las referencias más citadas en cualquier curso universitario de seguridad de sistemas.

La lógica detrás del principio

La idea central es simple de entender con un ejemplo cotidiano: una cuenta de un empleado de marketing no tiene ningún motivo legítimo para poder acceder a la base de datos financiera de la empresa. Si esa cuenta llegara a ser comprometida (por un correo de phishing exitoso, por una contraseña reutilizada filtrada en otro sitio, o por cualquier otro medio), el daño que un atacante puede causar queda limitado exactamente a lo que esa cuenta específica podía hacer. Si, en cambio, todas las cuentas tuvieran accesos amplios "por comodidad", comprometer una sola cuenta, la más débil de toda la organización, equivaldría a comprometer prácticamente todo.

Cómo se aplica en la práctica

La forma más habitual de implementar este principio en una organización moderna es a través de control de acceso basado en roles (RBAC, por sus siglas en inglés), donde los permisos no se asignan persona por persona de forma manual, sino que se definen roles estándar (por ejemplo, "vendedor", "contador", "soporte técnico de nivel 1") con un conjunto predefinido y limitado de accesos, y cada persona recibe el rol que corresponde a su función real. Esto evita tanto el exceso de privilegios como la inconsistencia de tener decenas de configuraciones manuales distintas, cada una con su propio historial de "excepciones" acumuladas con el tiempo.

La evolución moderna: arquitectura de confianza cero

Medio siglo después del trabajo de Saltzer y Schroeder, el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) publicó en 2020 la guía oficial SP 800-207 sobre arquitectura de confianza cero (Zero Trust Architecture), que lleva el principio de mínimo privilegio un paso más allá: en lugar de confiar automáticamente en cualquier dispositivo o usuario que ya esté "dentro" de la red corporativa, cada solicitud de acceso se verifica de forma explícita, sin importar si viene de adentro o de afuera de la red tradicional. Es, en esencia, el mismo principio de 1975 llevado a su forma más estricta posible: ningún acceso se da por sentado, cada uno se otorga de forma puntual y se revalida constantemente.

Un hábito que se descuida con el tiempo

Incluso las organizaciones que aplican bien este principio al inicio suelen fallar en un punto: revisar y retirar accesos cuando ya no corresponden. Es habitual que una persona cambie de rol dentro de una empresa y conserve, además de los accesos nuevos que necesita, todos los accesos anteriores que ya no usa, simplemente porque nadie revisó ni retiró los viejos. Con el tiempo, esa acumulación de permisos no utilizados (a veces llamada "privilege creep" o acumulación de privilegios) termina erosionando por completo el beneficio original del principio, incluso si en el momento de la contratación todo se configuró correctamente.

La práctica recomendada

Además de aplicar roles definidos desde el principio, la práctica recomendada incluye revisiones periódicas de acceso (por ejemplo, cada seis meses) donde se audita explícitamente si cada persona todavía necesita cada uno de los permisos que tiene asignados, y evitar por completo el uso cotidiano de cuentas con privilegios administrativos completos para tareas rutinarias que no los requieren, reservando esas cuentas de alto privilegio únicamente para las tareas puntuales que realmente las necesitan.

Fuentes: Jerome H. Saltzer y Michael D. Schroeder, "The Protection of Information in Computer Systems," Proceedings of the IEEE, vol. 63, n.º 9 (1975); NIST Special Publication 800-207, Zero Trust Architecture (2020).

Más artículos del blog