Necesita una técnica para obligar a los administradores de sistemas a registrar el motivo para acceder a un servidor prod

17

Mi compañía requiere que cada vez que un usuario inicie sesión en un servidor de producción, la razón por la cual esa persona inició sesión y los cambios que el usuario tenga la intención de realizar deben estar registrados. Mi equipo quiere hacer esto, pero es fácil de olvidar. Me gustaría ayudarlos a recordar. Lo consideré un motd, pero quiero algo un poco más fuerte.

Mi primer pensamiento fue cambiar el shell del usuario a un script que haga algo como

vim /logs/logindate.txt 
bash -l

¿Existe una técnica mejor o más estándar?

Nota: La idea es que estos usuarios sean administradores de sistemas y deseen realizar la entrada de registro sin subvertir el sistema; con frecuencia se olvidan de hacerlo. Entonces, si pueden controlarlo, bueno ... estamos asumiendo que no lo harán.

linux logging

66

Estás tratando de encontrar una solución técnica para un problema de flujo de trabajo / procedimiento. En mi humilde opinión, tal esfuerzo está condenado al fracaso, y el problema del flujo de trabajo / procedimiento real debe abordarse directamente a través de medios no técnicos.

— John

11

Gracias amigo. Estoy tratando de usar la tecnología para promover un cambio de comportamiento. Supongo que podría simplemente golpearlos con una roca cada vez que lo olviden, pero creo que RR.HH. prefiere el enfoque tecnológico.

8

@John ¿No es parte del propósito de la tecnología implementar y ayudar en los flujos de trabajo?

— Michael Martinez

1

Acción disciplinaria, hasta e incluyendo el despido.

— Michael Hampton

44

Sí, pero la pregunta no era "¿deberías hacerlo?" la pregunta era "¿puedes hacerlo?" Uno es un juicio de valor; Una es una pregunta técnica digna de este foro. Confío en mi capacidad para administrar mi equipo. Podría usar la roca con gran éxito, pero tanta sangre. Me gusta ser amable Tengo buenos administradores solo olvidadizos. :) Parece que @ aaron-copley es el hombre esta vez. ¡Gracias a todos!

19

Mira pam_exec.so . Puede ejecutar un script al iniciar sesión en la interfaz de sesión de la autenticación del sistema de PAM. El script se ejecuta como root antes de que el usuario obtenga un shell, por lo que es posible que no capture la entrada con read? Sin embargo, puede intentar y utilizar readpara obtener un motivo del usuario y registrarlo en syslog con una loggerdeclaración. (Lo he omitido a continuación, pero puede atrapar CTRL + C para evitar que alguien salga sin razón). $ PAM_USER se configurará para la persona que inicia sesión, por lo que puede incluir eso en la declaración del registrador.

Ejemplo:

En la parte superior de la sesión en /etc/pam.d/system-auth:

session required pam_exec.so /usr/local/sbin/getreason

Y / usr / local / sbin / getreason:

#!/bin/bash
read -p "Reason for logging into production: " reason
logger -t $(basename $0) "$PAM_USER logged in with reason: ${reason}"

Disculpas si esto no funciona perfectamente. No lo probé, pero recientemente he hecho algo similar. (No capturó la entrada).

Editar: cuanto más pienso en esto, más no creo que funcione debido a la etapa en la que se ejecuta. La misma getreasonsecuencia de comandos debe trabajar después de sustituir $PAM_USERcon $(logname), pero puede necesitar ser ejecutado en /etc/profile. (Prueba de shell interactivo, primero.)

Dejaré ambas opciones arriba, ya que al menos debería hacerte pensar en la dirección correcta si nada más.

— Aaron Copley
fuente

1

Muchas gracias por esto. Se ve perfecto Si nada más puedo escribir una cosita en C para capturar la entrada. Implementaré esto y le haré saber si funciona.

1

@BiggyDevOPs: sugerencia útil: si usa un archivo plano para mantener el registro, póngalo en git o svn para que tenga un historial

— Michael Martinez

7

La alternativa es una solución de administración de cuenta privilegiada, en la que, en lugar de dar acceso a los administradores con su propia cuenta, las cuentas de administrador están en custodia por un tercero y se deben seguir los procedimientos obligatorios antes de que los administradores puedan acceder a los sistemas de producción http: // en. m.wikipedia.org/wiki/Privileged_Identity_Management

— HBruijn
fuente

0

Otra forma de lograr esto sería tener su instalación de registro centralizado (estoy pensando en Logstash, pero puede hacer esto de otras maneras) tome su auth.log en los sistemas de producción, alimente eso en una aplicación donde las personas puedan registrar sus justificaciones .

— gWaldo
fuente

0

La forma en que he visto esto implementado en los clientes que ejecutan HP Server Automation ^* es que confían en el registro innato de la herramienta con una combinación de pasos de aprobación (he estado en varios clientes donde no hay sudo o root privs, excepto en Dev )

Las aprobaciones se pueden hacer a través de algo como Remedy and Operations Orchestration, o inicio de sesión administrativo dentro de SA, etc.

Dicho todo esto, fuera de las herramientas de gestión y automatización empresarial, la respuesta de @ Aaron Copley es una excelente opción.

^* Soy senior HPSA, HPOO y otros aspectos del consultor de la suite de automatización de HP

— madriguera
fuente

0

Mientras buscaba una solución, leí la respuesta de Aaron Copley y pensé: "¿Qué pasa si cambio el shell de mi usuario?"

Lo hice con éxito en mi máquina Ubuntu 14.04:

# usermod -s /usr/bin/loginScript username

En su secuencia de comandos puede capturar la razón del inicio de sesión simplemente. El mío es así:

#!/bin/bash
read -p "Tell me why you logged in:" reason
echo "You told me: $reason" >> /var/log/reasonLogin.log
/bin/bash

Una cosa que debe tener en cuenta: el script no se ejecuta como root, por lo que es posible que deba otorgarle al usuario algunos permisos para que funcione.

— william.wd
fuente