¿Quién obtiene acceso de root?


8

Estoy trabajando en una aplicación web que maneja algunos datos confidenciales. Nos estamos volviendo bastante estrictos con la seguridad y estamos estableciendo políticas para bloquear el acceso a las máquinas y registrar todo para fines de auditoría técnica.

La pregunta a la que seguimos volviendo es esta: ¿Quién obtiene la raíz?

Nuestras instancias de servidor tendrán un usuario root. Ese usuario root tendrá una contraseña. ¿Quién debería tener acceso a esto? ¿Es posible / deseable tener una máquina donde nadie pueda tener acceso de root?

Agradecería cualquier idea que tenga sobre el tema.


Esto me ha llamado la atención. Parece buena práctica.
Ross McFarlane

Respuestas:


14

Ninguno. Haz que se usen sudopara que todos los comandos de nivel raíz se registren y sean atribuibles a una persona específica.


66
+1. Cambie la contraseña de root a algo muy aleatorio, imprímala y séllela en un sobre solo para uso de emergencia.
EEAA

44
también, cambie su cuenta raíz .bashrc para que PROMPT_COMMAND esté configurado para registrar todo como usuario root simple en syslog. Práctico.
Sirex

1
el usuario puede usar sudo para ejecutar shell, luego los comandos no iniciarán sesión (solo iniciar sesión bash)
ooshro

cierto, a menos que hagan "sudo bash -l", que deberían. si configura la raíz .bashrc prompt_command, también registrará esto, lo cual es una razón por la que vale la pena hacerlo.
Sirex

+1 Además, asegúrese de configurar sudo para niveles de acceso más altos. En un lugar, todas las contraseñas raíz se guardaron en un sobre sellado por si acaso, si el sello se rompía, se tenía que informar por seguridad y cambiar las contraseñas.
st3v3o

3

¡Nadie, excepto quizás un administrador de hardware, obtiene la contraseña de root! La contraseña de root solo debe ser utilizable en la consola, no a través de SSH u otros servicios.

Utilice grupos para definir el acceso a diferentes conjuntos de programas con el uso de privilegios privados escalados sudo. Por ejemplo, el grupo de rueda es típicamente para personas que obtienen privilegios de root, pero todo se registra como su usuario. Si las personas no necesitan privilegios de root completos pero solo unos pocos comandos como otro usuario, cree otro grupo.


-1

Si usa e implementa selinux, es posible eliminar la típica cuenta divina "que todo lo ve y todo lo que sabe" que es la configuración raíz normal, y convertirla en una cuenta más consciente de la seguridad.


1
¿cómo? La respuesta no es realmente útil, siempre y cuando no dé ningún indicio de cómo;)
0xC0000022L

Es un tema demasiado grande para caber en una respuesta. Pero que yo sepa, selinux puede ser (y a menudo es) usado para este propósito.
Sirex

-5

Mi opinión es que las personas no deberían ejecutar comandos que requieren permisos de root, excepto, por supuesto, cuando realmente inician sesión como root.

Recomendaría usar su (cambia al usuario raíz) en lugar de sudo (aumenta temporalmente los permisos al nivel raíz para un comando) por este motivo. Si necesitan permiso de root, haga que cambien a usuario root.

Mi pregunta es, ¿qué están haciendo sus usuarios que creen que necesitan root?


44
@ user76897: No estoy de acuerdo. sudoes perfectamente adecuado para el propósito y registra cada comando emitido directamente con el sudoantepuesto. Donde, cuando se usa su, obtienes un shell y no se registra nada dentro de ese shell. /etc/sudoersSe puede sintonizar mucho. Puede saber qué comando se puede ejecutar como qué usuario por qué usuario y si se requiere contraseña o no, además de una serie de otras opciones útiles. Una razón por la que alguien podría necesitar root es reiniciar un demonio. Esto se logra fácilmente sudosin dar acceso completo a la cuenta raíz.
0xC0000022L

Esta respuesta no tiene ningún sentido ni aborda la pregunta. La preferencia de sumás sudono se defiende y, según la mayoría de las otras voces aquí, en realidad sería parte del problema original de los chicos, no una solución.
Caleb
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.