Потрібна техніка, щоб примусити системних адміністраторів зареєструвати причину доступу до сервера prod

Моя компанія вимагає, щоб кожен раз, коли користувач увійшов на виробничий сервер, повинна бути зареєстрована причина, за якою людина входила, та зміни, які користувач має намір внести. Моя команда хоче це зробити, але це легко забути. Я хотів би допомогти їм запам'ятати. Я вважав мод, але хочу чогось сильнішого.

Моя перша думка полягала в тому, щоб змінити оболонку користувача на сценарій, який робить щось подібне

vim /logs/logindate.txt 
bash -l

Чи є краща чи стандартна техніка?

Примітка. Ідея полягає в тому, що ці користувачі є систематичними адміністраторами і хотіли б зробити запис у журналі, не підриваючи систему, вони просто забувають це робити. Отже, якщо вони зможуть ctrl-c це, ну ... ми припускаємо, що вони цього не зроблять.

Подивіться на pam_exec.so . Ви можете запустити скрипт при вході в інтерфейс сеансу системи PAM-auth. Сценарій запускається як root перед тим, як користувач отримає оболонку, тому він може не зафіксувати дані read? Ви можете спробувати і скористатися, readщоб отримати від користувача причину, і ввійти в syslog із 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 ^*, - це те, що вони покладаються на вроджений журнал інструмента за допомогою комбінації кроків затвердження (я був у кількох клієнтів, де немає судо-кореневих приватних приватних даних, окрім Dev ).

Схвалення можна зробити за допомогою оркестрації засобів усунення та операцій, або адміністративного входу в SA тощо.

Це все сказане, поза автоматизації і управління підприємством коштів, @ Аарон Коплі «s відповідь є відмінним вибором.

^* Я є старшим 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, тому вам, можливо, доведеться надати користувачеві певні дозволи, щоб зробити цю роботу.