Precisa de uma técnica para coagir administradores de sistemas para registrar o motivo de acessar um servidor prod

Minha empresa exige que, sempre que um usuário efetue login no servidor de produção, o motivo pelo qual a pessoa efetuou login e as alterações que ele pretende fazer sejam registradas. Minha equipe quer fazer isso, mas é fácil esquecer. Eu gostaria de ajudá-los a se lembrar. Eu considerei um motivo, mas quero algo um pouco mais forte.

Meu primeiro pensamento foi mudar o shell do usuário para um script que faz algo como

vim /logs/logindate.txt 
bash -l

Existe uma técnica melhor ou mais padrão?

Nota: A idéia é que esses usuários sejam administradores de sistemas e gostariam de fazer a entrada do log sem subverter o sistema - eles apenas esquecem de fazê-lo. Então, se eles podem pressionar Ctrl-C, bem ... estamos assumindo que não.

Veja pam_exec.so . Você pode executar um script no login na interface da sessão de autenticação do sistema do PAM. O script é executado como root antes que o usuário obtenha um shell, portanto, ele não pode capturar entrada com read? Porém, você pode tentar e usar readpara obter uma razão do usuário e registrá-la no syslog com uma loggerinstrução (Omiti abaixo, mas você pode interceptar CTRL + C para impedir que alguém saia sem motivo.) $ PAM_USER será definido como a pessoa que está efetuando login, para que você possa incluí-lo na instrução de logger.

Exemplo:

Na parte superior da sessão em /etc/pam.d/system-auth:

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

E / 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}"

Desculpas se isso não funcionar perfeitamente. Não testei, mas fiz recentemente algo semelhante. (Ele não capturou entrada.)

Edit: Quanto mais eu penso sobre isso, mais eu acho que não vai funcionar por causa do estágio em que é executado. O mesmo getreasonscript deve funcionar após a substituição $PAM_USERpor $(logname), mas pode ser necessário executar o /etc/profile. (Teste primeiro o shell interativo.)

Deixarei as duas opções em aberto, pois, pelo menos, você deve pensar na direção certa.

A alternativa é uma solução privilegiada de gerenciamento de contas, onde, em vez de fornecer aos administradores acesso por conta própria, as contas de administrador são mantidas em custódia por terceiros e os procedimentos obrigatórios devem ser seguidos antes que os administradores possam acessar os sistemas de produção http: // en. m.wikipedia.org/wiki/Privileged_Identity_Management

Outra maneira de conseguir isso seria ter seu recurso de registro centralizado (estou pensando no Logstash, mas você pode fazer isso de outras maneiras) levar o seu auth.log nos sistemas de produção, alimentá-lo em um aplicativo onde as pessoas possam registrar suas justificativas .

A maneira como eu vi isso implementado em clientes que executam o HP Server Automation ^* é que eles confiam no registro inato da ferramenta com uma combinação de etapas de aprovação (já estive em vários clientes onde não há sudo ou privs raiz, exceto no Dev )

As aprovações podem ser feitas por meio de Remedy and Operations Orchestration ou logon administrativo na SA, etc.

Dito isso, fora das ferramentas de automação e gerenciamento corporativo, a resposta de @ Aaron Copley é uma excelente escolha.

^* Sou HPSA, HPOO e outros aspectos do consultor do conjunto de automação HP

Enquanto procurava uma solução, li a resposta de Aaron Copley e pensei: "E se eu mudar o shell do meu usuário?"

Fiz isso com sucesso na minha máquina Ubuntu 14.04:

# usermod -s /usr/bin/loginScript username

No seu script, você pode capturar o motivo do login simplesmente. A minha é assim:

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

Uma coisa que você deve observar: o script não é executado como root; portanto, você pode precisar conceder ao usuário algumas permissões para fazer isso funcionar.