30 de septiembre de 2026 · IT-Sicherheit · Zero Trust · Compliance · Schwachstellenmanagement

Least privilege figura en la etiqueta, no en el host

Las cuentas se consideran de privilegios mínimos, pero el host a menudo permite mucho más. Cómo comprobar los derechos reales y por qué hace falta una prueba negativa.

«Least privilege» –el principio del mínimo privilegio– es uno de los pocos principios de seguridad a los que nadie pone objeciones. En consecuencia, aparece escrito a menudo: en conceptos de permisos, descripciones de roles, solicitudes y manuales de operación. Pero ninguno de estos documentos decide lo que una cuenta puede hacer realmente. Eso lo decide la configuración del sistema en el que trabaja la cuenta. Este artículo describe por qué ambas cosas pueden divergir, cómo determinar el estado real y qué hay que tener en cuenta antes de una corrección.

Lo que exigen los estándares

El requisito en sí está formulado en términos equivalentes en los marcos de referencia habituales. El NIST lo describe en SP 800-53 como control AC-6: solo se permiten los accesos necesarios para las tareas asignadas, expresamente también para los procesos que actúan en nombre de los usuarios. La automatización y las cuentas de servicio no quedan, por tanto, exentas, sino incluidas. Las ampliaciones del control son más concretas: las cuentas privilegiadas deben limitarse a personas o roles determinados (AC-6(5)), los derechos asignados deben revisarse periódicamente en cuanto a su necesidad y, en su caso, retirarse (AC-6(7)), y la ejecución de funciones privilegiadas debe registrarse (AC-6(9)).

El BSI exige en el módulo ORP.4 del IT-Grundschutz el mismo principio: los identificadores y los permisos solo pueden concederse en función de la necesidad real (ORP.4.A2). Destaca el requisito ORP.4.A3. No solo exige que se documenten los identificadores y los perfiles de derechos, sino que esa documentación «debe revisarse periódicamente para comprobar si refleja el estado real de la asignación de derechos».

Con ello queda fijada la dirección de la comprobación: del sistema a la documentación, no al revés. Una documentación que nadie contrasta con la realidad describe una intención.

El patrón: la documentación dice X, los derechos efectivos dicen Y

La desviación rara vez es fruto de la negligencia. Surge porque los permisos actúan en varios lugares a la vez, y porque un nombre o una descripción son más fáciles de leer que un permiso efectivo. Dos ejemplos de manual lo hacen tangible.

Supongamos que una cuenta de servicio para las copias de seguridad está descrita en el concepto de permisos como «solo lectura». En el servicio de directorio es miembro de un grupo que, a su vez, es miembro de un grupo administrativo. Cada pertenencia por separado parece plausible. En conjunto, la cuenta puede hacer mucho más que leer, y quien solo mira la pertenencia directa al grupo no lo ve.

Supongamos que un rol en una plataforma se llama «Observador», pero, además de derechos de lectura, contiene el permiso de modificar asignaciones de roles. El nombre está bien elegido; el rol, no. Quien asigna el rol fiándose del nombre concede de hecho la posibilidad de otorgarse a uno mismo más derechos.

En ambos casos rige el mismo principio: una restricción solo se aplica allí donde el sistema de destino la comprueba. Lo que figura en el concepto, en el nombre o en una herramienta que realiza la llamada es una descripción, no un control.

Preguntar al sistema, no a la documentación

Los derechos reales pueden consultarse, por regla general, directamente al sistema:

  • En Linux con sudo: sudo -n -l enumera, según el manual, los derechos del usuario que lo invoca en el host actual. La opción -n impide cualquier solicitud de contraseña: si hace falta una entrada, sudo termina con un mensaje de error en lugar de esperar. Eso hace que la llamada sea adecuada para comprobaciones automatizadas. Con un comando añadido, sudo responde de forma específica si exactamente esa llamada estaría permitida, sin ejecutarla.
  • En servicios de directorio: los permisos efectivos de una cuenta sobre un objeto, incluidos los grupos anidados y los derechos heredados, no la lista de grupos de los que debería ser miembro.
  • En servicios de nube y plataformas: la política evaluada para una acción concreta, no la denominación del rol.

Sin prueba negativa, la comprobación no demuestra nada

Una comprobación que solo confirma el caso permitido tiene una debilidad incorporada. A la pregunta «¿puede la cuenta hacer lo que puede hacer?» responde que sí también una cuenta con acceso total. El resultado no distingue, por tanto, entre una cuenta limpiamente restringida y una sin restricciones.

Solo la contraprueba es concluyente: una solicitud que debe ser rechazada. Supongamos que una cuenta solo debe poder reiniciar un servicio determinado. Entonces la comprobación incluye preguntas como: ¿puede editar la configuración de permisos? ¿Crear cuentas? ¿Iniciar una shell cualquiera con privilegios elevados? Con sudo -n -l <befehl> pueden plantearse estas preguntas sin ejecutar nada; en los servicios de directorio y las plataformas, las evaluaciones de los permisos efectivos hacen lo mismo. Sin embargo, un no a sudo -n -l /bin/sh no excluye una shell de root: los programas permitidos con escape a shell –por ejemplo find, vim o less– o los comodines en los argumentos permitidos abren el mismo camino. Si alguna de estas preguntas obtiene un sí, la descripción es falsa, con independencia de lo que haya dado la comprobación positiva.

Dos detalles hacen sólida la prueba negativa. Primero: evalúe la respuesta, no solo la ausencia de un sí. Una llamada que ni siquiera llegó a producirse por un error de red o una solicitud de contraseña inesperada parece, de lo contrario, un rechazo. Segundo: la prueba negativa forma parte de la revisión periódica según AC-6(7) y ORP.4.A3, no solo de la aceptación. Los permisos cambian por la gestión de la configuración, las actualizaciones y las intervenciones de emergencia.

Antes de restringir, asegurar la vía de reparación

Quien encuentra un permiso demasiado amplio quiere cerrarlo. Para ello rige un principio que fácilmente falta en las planificaciones: una restricción no debe eliminar la única vía para su propia corrección. Si la cuenta restringida es a la vez la única que puede modificar la configuración de permisos, un error en la nueva regla solo puede corregirse después mediante acceso por consola, restauración o reconstrucción.

La consecuencia es un orden, no una relajación. Antes de retirar un derecho hay que aclarar qué vía podría devolverlo y si esa vía sobrevive a la restricción. Debería existir y haberse probado una segunda identidad de administración independiente, con acceso propio, antes de restringir la primera. El BSI formula en ORP.4.A20 una idea afín para la preparación ante emergencias: tomar precauciones para seguir siendo operativo cuando la propia gestión de permisos no esté disponible.

Las cuentas de automatización de gran alcance son Tier 0

Las cuentas a través de las cuales se despliega, se configura o se automatiza se consideran a menudo una herramienta de operación. En cuanto poseen amplios derechos administrativos sobre muchos sistemas, son más que eso: quien las controla, controla los sistemas.

Microsoft describe en el Enterprise Access Model que el antiguo nivel Tier 0 se amplió al «Control Plane», y exige imponer la jerarquía de modo que los niveles inferiores no puedan controlar los superiores. Ello incluye expresamente buscar de forma continua debilidades de configuración que permitan una escalada de privilegios no intencionada. Para los identificadores con permisos de gran alcance, el BSI recomienda la autenticación multifactor (ORP.4.A10).

Lo que debería comprobar

  • Determinar los derechos efectivos: para cada cuenta de servicio y de automatización, en el sistema.
  • Definir para cada comprobación positiva una prueba negativa que deba ser rechazada.
  • Anclar las restricciones allí donde se aplican.
  • Antes de cada restricción, establecer y probar la vía de reparación.
  • Tratar las cuentas de automatización de gran alcance como Tier 0: protección multifactor, registro, responsabilidad nombrada.

Cómo apoya sector7

Le apoyamos con conceptos de roles y permisos, con la gestión de cuentas privilegiadas, con la autenticación multifactor y con el endurecimiento de sistemas operativos, incluidas directrices, documentación y auditorías. Más información en Ciberseguridad.

Fuentes

Hablemos de su situación.

Concertar una conversación+49 212 240915 0