Definición
El principio de mínimo privilegio dice que cada usuario, cada proceso y cada clave debe tener exactamente los permisos que necesita para su función, y ni uno más.
No parte de desconfiar de la gente. Parte de aceptar un hecho: las cuentas se comprometen. Una contraseña se filtra, un portátil se pierde, una clave acaba en un repositorio. Cuando eso pasa, lo único que decide el tamaño del desastre es qué podía hacer esa cuenta.
Es, por tanto, una medida de contención de daños, no de prevención.
Dónde se aplica
Usuarios de la aplicación. Un comercial necesita ver sus clientes y crear pedidos. No necesita poder borrar la base de datos ni cambiar los precios de coste.
Cuentas de base de datos. La aplicación web rara vez necesita permisos para crear o borrar tablas. Con lectura y escritura de datos suele bastar.
Claves de API. La mayoría de servicios permiten crear claves limitadas — solo lectura, solo un ámbito. Casi nadie las usa, y se genera una clave total «por comodidad».
Servidores y procesos. Un proceso web no debería ejecutarse como administrador del sistema.
Personas de la empresa. Los accesos que se dan al entrar y no se retiran al cambiar de puesto acumulan permisos durante años.
Ejemplo práctico
En un sistema de gestión con varias personas, el planteamiento útil es por roles, no por persona. Se definen los roles reales del negocio, se decide qué puede hacer cada uno y se asignan personas a roles.
Lo que aprendí: la lista de permisos hay que construirla desde cero hacia arriba, no desde el todo hacia abajo. Si empiezas dando acceso completo y vas quitando, nunca terminas: cada recorte rompe algo, alguien se queja y se devuelve el permiso. Si empiezas sin nada y vas añadiendo lo que hace falta, el resultado es ajustado y nadie discute — porque cada permiso se ha concedido por una razón concreta.
Y hay una consecuencia práctica que compensa el esfuerzo: un sistema con permisos bien puestos es más fácil de usar. Cada persona ve solo su parte, la interfaz se simplifica sola y desaparecen los errores por tocar lo que no toca.
El segundo aprendizaje, y es el que más se descuida: la parte difícil no es dar permisos, es quitarlos. Los accesos se conceden con urgencia y se retiran nunca. La medida que lo arregla es aburrida y funciona: una revisión periódica —dos veces al año basta— en la que se mira la lista de usuarios activos y se pregunta persona por persona si sigue necesitando lo que tiene.
Y en particular, un procedimiento de salida claro: cuando alguien deja la empresa, hay que poder cortar todos sus accesos, no solo el correo. Ver sesión.
Y una advertencia sobre las claves de integración: son las que más incumplen esto. Una clave con permisos totales guardada en un servidor es el escenario que convierte un incidente pequeño en uno grande. Ver gestión de secretos.
Errores comunes
- Dar acceso total «de momento» y no revisarlo jamás.
- Un solo rol de administrador para todo el equipo.
- La aplicación conectando a la base de datos como superusuario.
- Claves de API sin limitar cuando el servicio permite limitarlas.
- No retirar accesos al cambiar de puesto o al salir.
- Confundir ocultar con proteger. Esconder un botón no impide llamar al endpoint: el permiso se comprueba en el servidor.
- No registrar quién hace qué. Sin traza, no hay forma de saber qué pasó.
Cuándo aplicarlo
Al diseñar cualquier sistema con más de un usuario, al crear cualquier clave de integración y en cada revisión periódica de accesos.
La pregunta que ordena todo: si esta cuenta cayera en malas manos hoy, ¿hasta dónde llegaría el daño? Si la respuesta es «a todo», el problema no es la contraseña.
