¿Cuáles son los beneficios reales de asignar privilegios de sudo a un usuario en lugar de usar root?


25

Soy bastante nuevo en la administración del servidor, y he visto muchos sitios que recomiendan asignar privilegios de sudo a un usuario creado por el usuario raíz y le dan al usuario raíz una contraseña increíblemente larga para mejorar la seguridad.

Sin embargo, si el usuario recién creado puede realizar las mismas funciones que un usuario raíz, ¿cuál es el beneficio real de hacer esto?


77
El sudoer no puede hacer todo lo que root puede hacer, solo lo que root permite a los sudoers sudo, y el sudoer todavía tiene que sudo el comando. Por último, los sudoers sudo las cosas como su propia cuenta de usuario, lo que significa que no tienen que iniciar sesión como root y, en segundo lugar, le permiten ver quién de repente algo.
KeithS

Respuestas:


48

Hay varios beneficios al usar sudosobre la entrega de la contraseña de root. En ningún orden particular:

  • No está dando su contraseña de root.
    Como regla general, si alguien abandona su empresa y conoce la (s) contraseña (s) de root, ahora tiene que cambiar esas contraseñas en todas partes. Con una gestión de configuración adecuada, esto es una molestia menor. Sin ella es una tarea enorme.

  • No está regalando las llaves del reino, le
    sudo permite especificar una lista restringida de comandos que los usuarios pueden ejecutar, por lo que si decide que Alice solo necesita la capacidad de detener e iniciar Apache, pero Bob necesita todos los derechos de root, puede establecer ellos en consecuencia.

  • Puede administrar la autorización de forma centralizada, sudo admite la configuración de LDAP, lo que significa que todos los sistemas de su empresa pueden mirar un servidor central de LDAP para determinar quién puede hacer qué.
    ¿Necesita autorizar (o desautorizar) a alguien? Cambie la configuración de sudoers en LDAP y todos sus sistemas se actualizan a la vez.

  • Hay una pista de auditoría
    Con la excepción de los usuarios que tienen permiso para hacerlo sudo su -, sudo sho algo equivalente, sudoproducirá una pista de auditoría de los cuales corrió usuario qué comandos.
    (También producirá una lista de las personas que se dieron una cáscara de raíz sin registrar, para que pueda señalarlas con el dedo y silbar con desaprobación).

  • sudoes bueno para algo más que root. Todos se concentran en sudouna forma de hacer cosas como su peruser, pero eso no es todo para lo que es bueno.
    Digamos que Alice es responsable de una compilación de software en particular, pero Bob también debería poder ejecutar el script de compilación. Puede darle a Bob una entrada en sudoers que le permita ejecutar el script de compilación como usuario de Alice. (Sí, claro, hay formas mucho mejores de tratar este caso en particular, pero el principio de Let user A run a program as user Bpuede ser útil ...).
    También obtienes los mismos beneficios de seguimiento de auditoría que mencioné anteriormente cuando haces esto ...


1
Respuesta muy útil: si sé (y quiero decir con 100% de certeza) que voy a ser el único que administre un solo servidor, ¿ve algún beneficio en asignar privilegios de sudo a otro usuario (que sería yo mismo de todos modos) fuera de evitar que me joda algo?
JM4

3
@ JM4 Consistencia y buenas prácticas para un día en el futuro cuando trabaje en un entorno más amplio. Desde un punto de vista práctico, nunca deberías iniciar sesión como root directamente a menos que estés en la consola física arreglando algo que está realmente regado, por lo tanto, en sudocomparación con suuna distinción académica, tendrás que saltar a través de un aro u otro. El uso le sudoofrece la oportunidad de ejercer el principio del menor privilegio (mi último punto) cuando sea práctico, y eso siempre es algo a considerar seriamente.
voretaq7

2
Además, use visudo para editar su archivo sudoers.
Justin Dearing

3
Tenga en cuenta que muchos comandos interactivos permitirán a los usuarios omitir la pista de auditoría. Por ejemplo, cualquier usuario que sudo vipueda :! bashuna vez dentro de vi.
Dietrich Epp

44
@DietrichEpp La NOEXECetiqueta ayuda en ese caso.
Shane Madden

17

La principal diferencia es que los usuarios se autentican para sudousar su propia contraseña, mientras que con suel inicio de sesión raíz directo se usa la contraseña raíz.

Esto significa que no tiene que compartir la contraseña de root con todos , y que si necesita deshabilitar el acceso de root para uno o dos usuarios en el futuro, simplemente puede deshabilitarlo para ellos, en lugar de tener que cambiar el contraseña de root

sudotambién es capaz de limitar qué comandos puede ejecutar cada usuario como root, por lo que los usuarios específicos solo pueden tener acceso a las tareas que necesitan realizar, si no requieren acceso completo a la raíz.


1
Gracias por tu ayuda. Veo el beneficio de su punto, pero también realmente miré a un usuario básico a usuario root como un punto de autenticación doble dado que he desactivado el inicio de sesión de usuario root desde ssh en mi servidor.
JM4

4

Además de las respuestas dadas, que son válidas, no olvide que un usuario registrado como root puede potencialmente romper el sistema con cada comando. Si los obliga a escribir sudo antes de hacer algo potencialmente peligroso, al menos les hace saber que necesitan verificar antes de hacer un comando en particular.


2

Sí, de hecho, desde una perspectiva de control y registro, sudo es mucho mejor.

Por ejemplo, si su su el único evento capturado en los registros es su suceso. Cualquier cosa después de eso va como raíz. Y si alguna vez has mirado registros en Unix / Linux, sabes que root hace un montón de cosas.

Sudo, por otro lado, registra casi todo como el usuario de origen.


0

El uso de sudo hace que sea más difícil para un usuario malicioso obtener acceso a un sistema. Cuando hay una cuenta raíz desbloqueada, un usuario malintencionado conoce el nombre de usuario de la cuenta que quiere descifrar antes de comenzar. Cuando la cuenta raíz está bloqueada, el usuario debe determinar el nombre de usuario y la contraseña para entrar en un sistema.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.