Least Privilege

Autoridad suficiente para una función

Least Privilege es el principio de conceder a una identidad únicamente las autorizaciones y los recursos necesarios para realizar su función bajo condiciones definidas. Se aplica a personas, procesos y servicios. No significa impedir todo trabajo ni conseguir el menor número posible de permisos sin considerar qué debe funcionar. El glosario de NIST reúne definiciones compatibles centradas en la necesidad de la tarea.

La pregunta útil es qué puede hacer una identidad, sobre qué recurso, para quién y durante cuánto tiempo. Una función legítima puede necesitar autoridad considerable; el principio exige justificarla y acotarla. Una restricción arbitraria que provoca bloqueos permanentes no demuestra mejor diseño.

Identidad, operación, recurso y tiempo

Permitir consultar pedidos no implica permitir reembolsarlos. Permitir una modificación en staging no implica permitirla en producción. Un permiso sobre un tenant tampoco debe convertirse silenciosamente en acceso a todos los tenants. El alcance combina dimensiones; no queda descrito por el nombre del rol.

Conviene distinguir los permisos declarados de la autoridad efectiva. Grupos heredados, credenciales compartidas, procesos auxiliares y servicios intermediarios pueden habilitar caminos adicionales. Una interfaz que oculta el botón de borrado no restringe una API que sigue aceptando esa operación.

La duración también importa. Un permiso temporal reduce la ventana de exposición, pero puede producir consecuencias duraderas mientras está vigente. Que una credencial expire después no revierte una exportación ni un cambio remoto.

Ejemplo: diagnóstico de Commerce

Un servicio de soporte necesita consultar el estado de una compra para explicar un fallo. Puede disponer de una operación que devuelve el pedido autorizado y un resultado de diagnóstico limitado. No necesita una conexión administrativa a todas las tablas ni la capacidad de reembolsar cualquier compra.

Si el diagnóstico descubre un cobro incorrecto, el hallazgo puede justificar otro flujo autorizado. No transforma retrospectivamente la consulta en permiso para corregir dinero. La frontera debe relacionar identidad, pedido y operación antes del efecto.

Ese diseño tampoco exige pedir confirmación por cada lectura ya autorizada. Preautorizar operaciones acotadas permite trabajar con fluidez. La decisión adicional corresponde a una ampliación de autoridad o a un efecto que el sistema haya decidido proteger.

Aplicación y comprobación

Una revisión puede seguir una operación real: identificar el principal, enumerar capacidades necesarias, retirar las innecesarias y comprobar tanto el caso permitido como un caso fuera del alcance. Probar únicamente el camino exitoso no muestra que la frontera exista.

La separación de identidades entre tareas puede reducir autoridad compartida. Sin embargo, duplicar cuentas sin cambiar sus permisos conserva el mismo problema. Del mismo modo, registrar una acción mejora la evidencia posterior, pero no sustituye impedir una operación que no debería ejecutarse.

Trust Boundaries ayuda a localizar dónde debe comprobarse ese alcance. Confused Deputy explica cómo un intermediario puede emplear su propia autoridad a favor de un solicitante que no debería recibirla.

Límites y especialización

Least Privilege no equivale a autenticación: reconocer al principal no determina sus operaciones permitidas. Tampoco equivale a una instrucción, una aprobación puntual o un sandbox. Un proceso aislado puede conservar una credencial excesiva; una persona puede aprobar un paso sin conceder acceso general.

Least Privilege for Agents desarrolla esta misma idea para herramientas, contexto y delegación. Es una perspectiva del principio, no una segunda definición canónica. El mecanismo operativo se conecta con Agent Permissions and Approval Boundaries.

Fuentes y alcance

El ejemplo y la secuencia de comprobación son síntesis editorial del Atlas; no prescriben un producto IAM ni una jerarquía universal de roles.