Cuentas de usuario y sudo en servidores Linux empresariales: accesos con nombre, mínimo privilegio y bajas

La respuesta corta: dé a cada persona que trabaja en un servidor Linux su propia cuenta con nombre, otorgue derechos de administrador mediante un grupo y archivos pequeños en /etc/sudoers.d editados con visudo, limite a cada persona a los comandos que realmente necesita y desactive el acceso el mismo día en que alguien se va. Después, revise periódicamente quién tiene acceso. Estos hábitos no cuestan nada en software y convierten un "alguien ejecutó algo como root" en un registro claro y atribuible. Esta guía cubre la parte de cuentas de usuario en Debian 12/13, Ubuntu 24.04 y RHEL/AlmaLinux 9/10; para la base general, comience con nuestra guía de fundamentos de endurecimiento de servidores Linux.

Por qué compartir el acceso root es un problema

Cuando tres personas y un proveedor inician sesión como root con la misma contraseña, el servidor no puede distinguirlos. Los registros solo dicen "lo hizo root", la contraseña nunca se cambia porque cambiarla afecta a todos y, cuando alguien se va, la única opción segura es rotar una credencial de la que depende todo el equipo.

Las cuentas con nombre resuelven esto:

• Responsabilidad: cada inicio de sesión y cada comando sudo queda registrado con un nombre de usuario real.
• Bajas ordenadas: se desactiva una cuenta en lugar de rotar un secreto compartido.
• Mínimo privilegio: cada persona recibe exactamente los permisos que su trabajo requiere.

Ubuntu ya funciona así: la contraseña de root está bloqueada por defecto y el primer usuario administra el sistema con sudo. En Debian, si definió una contraseña de root durante la instalación, puede bloquearla cuando sus cuentas de administrador con nombre ya funcionen (sudo passwd -l root). Antes de hacerlo, tenga documentado un acceso de emergencia, como la consola de su proveedor de hosting.

Cree una cuenta por persona

Cree el usuario, asigne una contraseña inicial segura (o ninguna, si usará llaves SSH) y agréguelo a los grupos correspondientes.

## Debian / Ubuntu
sudo adduser maria

## RHEL / AlmaLinux
sudo useradd -m maria
sudo passwd maria

Nunca reutilice la cuenta de un exempleado para un nuevo empleado y evite nombres genéricos como admin o support. Si un proveedor necesita acceso, recibe su propia cuenta con fecha de vencimiento (lo veremos más adelante).

Otorgue sudo mediante grupos, no a individuos

Ambas familias de distribuciones incluyen un grupo que ya tiene derechos completos de sudo:

Distribución	Grupo de administradores	Agregar un usuario
Debian 12/13, Ubuntu 24.04	sudo	sudo usermod -aG sudo maria
RHEL / AlmaLinux 9/10	wheel	sudo usermod -aG wheel maria

La opción -a (agregar) es importante: sin ella, usermod -G reemplaza los grupos suplementarios del usuario. El cambio se aplica en el siguiente inicio de sesión.

Los administradores completos deben ser pocos. La mayoría de las personas que necesitan privilegios elevados solo necesitan algunos comandos específicos.

Use /etc/sudoers.d y edite siempre con visudo

No edite /etc/sudoers directamente. Coloque sus reglas en archivos pequeños dentro de /etc/sudoers.d/ y ábralos siempre con visudo, que verifica la sintaxis antes de guardar. Un archivo sudoers dañado puede dejar a todos los administradores sin acceso a sudo.

sudo visudo -f /etc/sudoers.d/20-webops
sudo visudo -c   # revisa la sintaxis de todos los archivos sudoers

Un detalle que confunde a muchos: sudo ignora los archivos de ese directorio cuyo nombre contiene un . o termina en ~. Un archivo llamado webops.conf se ignora sin aviso. Use nombres como 20-webops.

Restrinja comandos para aplicar el mínimo privilegio

En lugar de ALL, indique los comandos exactos que necesita cada función. Por ejemplo, un equipo web que solo reinicia servicios:

## /etc/sudoers.d/20-webops
Cmnd_Alias WEB_SERVICES = /usr/bin/systemctl reload nginx, \
                          /usr/bin/systemctl restart nginx, \
                          /usr/bin/systemctl restart php8.3-fpm
%webops ALL=(root) WEB_SERVICES

Luego cree el grupo y agregue a las personas:

sudo groupadd webops
sudo usermod -aG webops maria
sudo -l -U maria   # confirma lo que maria puede ejecutar

Algunas reglas mantienen útiles estas restricciones:

• Use rutas completas de los comandos, nunca solo el nombre.
• No otorgue editores, paginadores ni shells (vim, less, bash, find, tar y similares) como root. Muchos pueden abrir una shell, lo que convierte una regla limitada en acceso root completo. Para permitir que alguien edite un archivo, use una regla sudoedit.
• Evite reglas de "todo excepto" como ALL, !/bin/su. El manual de sudoers y la documentación de Red Hat advierten que las reglas negativas son fáciles de evadir.
• Use NOPASSWD con moderación, idealmente solo para cuentas de automatización con una lista de comandos muy limitada.

Asegúrese de que la actividad de sudo quede registrada

Sudo registra por defecto cada intento exitoso o denegado. Dónde queda el registro depende del sistema:

• RHEL / AlmaLinux: el journal y /var/log/secure.
• Ubuntu 24.04: el journal y /var/log/auth.log.
• Debian 12/13: el journal (rsyslog, y por lo tanto /var/log/auth.log, no se instala por defecto).

sudo journalctl _COMM=sudo --since "7 days ago"

En servidores sensibles también puede grabar las sesiones completas de terminal ejecutadas con sudo. Agregue un archivo como /etc/sudoers.d/10-logging:

Defaults log_output
Defaults logfile=/var/log/sudo.log

Las sesiones grabadas se pueden listar y reproducir con sudoreplay -l. Pueden contener datos sensibles, así que protéjalas e inclúyalas en sus reglas de retención. Envíe también estos registros fuera del servidor: un atacante con acceso root puede modificar los archivos locales.

Bajas: desactive el acceso el mismo día

Cuando alguien se va, o termina el trabajo de un contratista, actúe de inmediato. Tenga en cuenta que bloquear solo la contraseña no impide el inicio de sesión con llaves SSH. El manual de passwd lo dice explícitamente, y el manual de usermod recomienda fijar también la fecha de vencimiento para bloquear toda la cuenta.

## 1. Bloquear la contraseña y vencer la cuenta
sudo usermod -L -e 1 maria

## 2. Retirar las llaves SSH
sudo mv /home/maria/.ssh/authorized_keys /root/maria-authorized_keys.disabled

## 3. Cerrar sesiones y procesos activos
sudo loginctl terminate-user maria
sudo pkill -KILL -u maria

## 4. Quitar los derechos de administrador
sudo gpasswd -d maria sudo      # o: wheel

Después revise si queda algo ejecutándose con ese usuario, como sudo crontab -l -u maria y temporizadores de usuario de systemd, y rote los secretos compartidos que la persona conocía (contraseñas de bases de datos, llaves de API). Elimine la cuenta más adelante, según su política de retención, cuando confirme que nada depende de ella. Nuestra lista de verificación de TI para altas y bajas de empleados cubre la parte que no es de servidores.

Ponga fecha de vencimiento a las cuentas temporales

Para proveedores y proyectos cortos, fije la fecha de fin al crear la cuenta:

sudo chage -E 2026-12-31 vendor-acme
sudo chage -l vendor-acme

Vencimiento de contraseñas: úselo con cuidado

chage puede forzar cambios periódicos de contraseña (-M), pero la guía actual del NIST (SP 800-63B) indica que no se deben exigir cambios periódicos y que solo se debe forzar un cambio cuando hay evidencia de que la contraseña fue comprometida. La rotación forzada suele producir contraseñas más débiles y predecibles. Un mejor enfoque para servidores:

• Prefiera llaves SSH para los inicios de sesión interactivos y protéjalas según su política de SSH.
• Use contraseñas largas y únicas para sudo, guardadas en un administrador de contraseñas para el equipo.
• Use chage -E para fechas de fin reales y cambie una contraseña de inmediato si sospecha que quedó expuesta.

Cuentas de servicio: sin shell y sin contraseña

Las aplicaciones, como una aplicación web, un agente de respaldos o un proceso de colas, deben ejecutarse con su propia cuenta de sistema con la que nadie pueda iniciar sesión:

sudo useradd --system --shell /usr/sbin/nologin \
  --home-dir /var/lib/myapp --create-home myapp

Las cuentas de sistema creadas así no tienen una contraseña utilizable. La shell nologin rechaza los inicios de sesión interactivos. Haga que la cuenta sea dueña solo de sus propios archivos y, si necesita una acción privilegiada, escriba una regla sudoers limitada a ese único comando.

Revise los accesos cada trimestre

Las cuentas se acumulan. Una revisión breve y recurrente detecta las que sobran:

## ¿Quién puede administrar este servidor?
getent group sudo wheel webops

## ¿Qué cuentas tienen una shell de inicio de sesión real?
cut -d: -f1,7 /etc/passwd | grep -v -E 'nologin|false'

## Últimos inicios de sesión (las versiones nuevas reemplazan lastlog por lastlog2)
lastlog 2>/dev/null || lastlog2

Para cada cuenta, pregúntese: ¿esta persona todavía trabaja aquí?, ¿todavía necesita este nivel de acceso? y ¿cuándo lo usó por última vez? Anote la fecha de la revisión y los cambios. Muchos marcos de cumplimiento esperan revisiones periódicas de accesos, y un registro con fecha facilita demostrarlo.

¿Necesita ayuda para ordenar el acceso a sus servidores?

Si sus servidores Linux todavía usan contraseñas de root compartidas o nadie está seguro de quién tiene sudo, podemos ayudarle. Core Florida IT configura cuentas con nombre, reglas sudo de mínimo privilegio y procedimientos de baja para empresas de Miami-Dade y todo el sur de Florida, como parte de nuestros servicios de instalación y reparación de servidores y ciberseguridad. Solicite una evaluación de TI gratuita y revisaremos quién puede acceder a sus servidores y qué puede hacer en ellos.

Fuentes

• Manual de sudoers (proyecto sudo, en inglés)
• Managing sudo access, documentación de RHEL 9 (Red Hat, en inglés)
• User management, documentación de Ubuntu Server (Canonical, en inglés)
• Página de manual usermod(8)
• Página de manual chage(1)
• NIST SP 800-63B: autenticación y gestión de autenticadores (en inglés)