Моя компания требует, чтобы каждый раз, когда пользователь входит на производственный сервер, должна регистрироваться причина, по которой этот человек вошел в систему, и изменения, которые пользователь намеревается внести. Моя команда хочет это сделать, но об этом легко забыть. Я хочу помочь им вспомнить. Я рассматривал мотд, но хочу чего-нибудь покрепче.
Моей первой мыслью было изменить оболочку пользователя на сценарий, который делает что-то вроде
vim /logs/logindate.txt
bash -l
Есть ли лучшая или более стандартная техника?
Примечание. Идея состоит в том, что эти пользователи являются системными администраторами и хотели бы делать запись в журнале, не нарушая работу системы - они просто часто забывают это делать. Итак, если они могут Ctrl-C, ну ... мы предполагаем, что они этого не сделают.
смотреть на pam_exec.so. Вы можете запустить сценарий при входе в систему в интерфейсе сеанса PAM system-auth. Сценарий запускается с правами root до того, как пользователь получит оболочку, поэтому он не может захватывать ввод с помощью read? Однако вы можете попробовать и использовать read чтобы получить причину от пользователя и зарегистрировать ее в системном журнале с logger заявление. (Я пропустил ниже, но вы можете перехватить CTRL + C, чтобы никто не мог выйти без причины.) $ PAM_USER будет установлен для человека, вошедшего в систему, поэтому вы можете включить это в оператор журнала.
Пример:
В верхней части сеанса в /etc/pam.d/system-auth:
session required pam_exec.so /usr/local/sbin/getreason
И / 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}"
Приносим извинения, если это не сработает. Я не тестировал, но недавно сделал нечто подобное. (Входные данные не регистрировались.)
Редактировать: Чем больше я думаю об этом, тем больше не думаю, что это сработает, из-за стадии, на которой он работает. Такой же getreason скрипт должен работать после замены $PAM_USER с участием $(logname), но может потребоваться выполнить его в /etc/profile. (Сначала проверьте интерактивную оболочку.)
Я оставлю оба варианта, поскольку это должно, по крайней мере, заставить вас думать в правильном направлении, если ничего больше.
Альтернативой является решение для управления привилегированными учетными записями, при котором вместо предоставления администраторам доступа с их собственной учетной записью учетные записи администраторов хранятся на условном депонировании третьей стороной, и необходимо выполнить обязательные процедуры, прежде чем администраторы смогут получить доступ к производственным системам. http://en.m.wikipedia.org/wiki/Privileged_Identity_Management
Другой способ добиться этого - иметь ваше централизованное средство ведения журнала (я думаю, Logstash, но вы можете сделать это другими способами), чтобы взять ваш auth.log в производственных системах, передать его в приложение, где люди могут регистрировать свои оправдания. .
Я видел, как это реализовано у клиентов, использующих HP Server Automation* заключается в том, что они полагаются на внутреннее ведение журнала инструмента с комбинацией шагов утверждения (я был у нескольких клиентов, у которых нет sudo или root-прав, кроме Dev).
Утверждение может быть выполнено с помощью чего-то вроде Remedy and Operations Orchestration или административного входа в SA и т. Д.
При этом, помимо средств автоматизации и управления предприятием, @Аарон Коплис ответ отличный выбор.
* Я старший специалист по HPSA, HPOO и другим аспектам консультанта HP по автоматизации.
В поисках решения я прочитал ответ Аарона Копли и подумал: «Что, если я изменю оболочку моего пользователя?»
Я успешно сделал это на своей машине с Ubuntu 14.04:
# usermod -s /usr/bin/loginScript username
В вашем скрипте вы можете просто зафиксировать причину входа в систему. Моя такая:
#!/bin/bash
read -p "Tell me why you logged in:" reason
echo "You told me: $reason" >> /var/log/reasonLogin.log
/bin/bash
Следует отметить одну вещь: сценарий не запускается от имени пользователя root, поэтому вам, возможно, придется предоставить пользователю некоторые разрешения, чтобы это работало.