Política de sudo como archivos independientes en /etc/sudoers.d, verificados con visudo -c

Objetivo

Conceder a una cuenta el privilegio de sudo más acotado posible, como un archivo revisable, sin arriesgarse a un archivo sudoers roto que bloquee el acceso administrativo.

Requisitos previos

Acceso root, o una cuenta sudo que ya funcione; conocer el comando o comandos exactos que necesita ejecutar la cuenta de destino y como qué usuario.

Pasos

1. No editar nunca /etc/sudoers ni los archivos bajo /etc/sudoers.d/ con un editor normal directamente sobre el archivo activo; usar siempre visudo, que bloquea el archivo y valida la sintaxis antes de guardar: visudo -f /etc/sudoers.d/deploy-restart.
2. Escribir la regla más acotada que satisfaga la necesidad — un comando concreto, argumentos concretos y un usuario de destino concreto, no ALL: deploy ALL=(root) /usr/bin/systemctl restart myapp.service Evitar NOPASSWD:ALL o una lista de comandos sin restricciones; ambas permiten a quien recibe el permiso ejecutar cualquier cosa como root, incluida la edición de archivos para concederse a sí mismo más permisos, lo que anula por completo el propósito de acotar la regla. Si el objetivo de sudo es un script, hay que tratarlo como el límite real del privilegio — todo lo que se pueda hacer que ese script haga se ejecuta como root.
3. Cuidado con el nombre del archivo: sudo omite los archivos de /etc/sudoers.d/ cuyo nombre termina en ~ o contiene un ., de modo que deploy.conf se ignora en silencio mientras que deploy-restart sí se lee. Mantener el modo en 0440, propiedad de root. Validar el archivo sin aplicarlo, útil en un despliegue no interactivo o mediante script: visudo -c -f /etc/sudoers.d/deploy-restart realiza una validación de sintaxis únicamente y notifica los errores sin abrir un editor.
4. Confirmar que la regla se respeta, desde la cuenta de destino: sudo -l -U deploy lista lo que tiene permitido ejecutar; sudo -u deploy sudo /usr/bin/systemctl restart myapp.service la pone a prueba directamente.
5. Comprobar qué registra realmente sudo: las invocaciones de sudo correctas y fallidas van al journal/syslog del sistema mediante la facilidad authpriv/auth por defecto; revisar con journalctl -t sudo o con el registro de correo/seguridad de la distribución.

Resultado esperado

visudo -c no informa de errores de sintaxis; sudo -l -U deploy muestra exactamente el comando previsto y nada más amplio; el journal muestra una entrada por cada uso.

Límites y base de verificación

Basado en sudoers(5) y visudo(8). Para deshacer, eliminar el archivo independiente (rm /etc/sudoers.d/deploy-restart) — nunca eliminar el propio archivo base /etc/sudoers. Como visudo bloquea y valida, un error ahí no puede corromper la política activa; esa misma protección no se extiende a un archivo editado fuera de visudo y solo comprobado después, así que siempre hay que crear o editar el contenido de sudoers a través de visudo -f, no con un editor aparte seguido de una comprobación con visudo -c.