Potrzebujesz techniki, aby zmusić sysadmins do zarejestrowania przyczyny dostępu do serwera prod

17

Moja firma wymaga, aby za każdym razem, gdy użytkownik loguje się na serwerze produkcyjnym, powód, dla którego osoba się zalogowała, oraz zmiany, które użytkownik zamierza wprowadzić, muszą zostać zarejestrowane. Mój zespół chce to zrobić, ale łatwo o tym zapomnieć. Chciałbym im pomóc zapamiętać. Myślałem o motd, ale chcę czegoś nieco silniejszego.

Moją pierwszą myślą była zmiana powłoki użytkownika na skrypt, który działa podobnie

vim /logs/logindate.txt 
bash -l

Czy istnieje lepsza lub bardziej standardowa technika?

Uwaga: Chodzi o to, że ci użytkownicy są administratorami i chcieliby wprowadzić wpis do dziennika bez obalenia systemu - po prostu często o tym zapominają. Więc jeśli mogą to zrobić, Ctrl-C, no cóż ... Zakładamy, że nie.

linux logging

6

Próbujesz znaleźć techniczne rozwiązanie problemu z przepływem pracy / procedurą. IMHO, taki wysiłek jest skazany na niepowodzenie, a faktyczny przepływ pracy / kwestia proceduralna powinna zostać rozwiązana bezpośrednio za pomocą środków nietechnicznych.

— Jan

11

Dzięki stary. Próbuję użyć technologii do promowania zmiany zachowania. Przypuszczam, że za każdym razem, gdy o nich zapomną, mógłbym po prostu uderzyć nimi w kamień. Myślę jednak, że HR woli podejście technologiczne.

8

@John Czy technologia nie jest wdrażana i pomaga w przepływach pracy?

— Michael Martinez,

1

Postępowanie dyscyplinarne, do rozwiązania umowy włącznie.

— Michael Hampton

4

Tak, ale pytanie nie brzmiało „powinieneś to zrobić?” pytanie brzmiało: „możesz to zrobić?” Jednym z nich jest osąd wartości; jedno pytanie techniczne jest warte tego forum. Jestem przekonany, że mogę zarządzać zespołem. Mógłbym użyć skały z wielkim sukcesem, ale z tak dużą ilością krwi. Lubię być miły. Mam dobrych administratorów, tylko tych zapominalskich. :) Wygląda na to, że tym razem @ aaron-copley jest mężczyzną. Dziękuję wszystkim!

19

Spójrz na pam_exec.so . Możesz uruchomić skrypt podczas logowania w interfejsie sesji uwierzytelniania systemowego PAM. Skrypt działa jako root, zanim użytkownik otrzyma powłokę, więc może nie przechwytywać danych wejściowych za pomocą read? Możesz jednak spróbować i użyć, readaby uzyskać powód od użytkownika i zalogować go do syslog za pomocą loggerinstrukcji. (Pominąłem poniżej, ale możesz przechwycić CTRL + C, aby uniemożliwić każdemu wyjście bez powodu.) $ PAM_USER zostanie ustawiony na osobę logującą się, więc możesz to uwzględnić w instrukcji loggera.

Przykład:

Na początku sesji w /etc/pam.d/system-auth:

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

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

Przepraszamy, jeśli to nie działa idealnie. Nie testowałem tego, ale ostatnio zrobiłem coś podobnego. (Nie przechwycił danych wejściowych.)

Edycja: Im więcej o tym myślę, tym bardziej nie sądzę, aby działało ze względu na etap, w którym działa. Ten sam getreasonskrypt powinien działać po wymianie $PAM_USERz $(logname), ale może to muszą być wykonywane /etc/profile. (Najpierw przetestuj interaktywną powłokę.)

Zostawię obie opcje, bo to powinno przynajmniej skłonić cię do myślenia we właściwym kierunku, jeśli nic więcej.

— Aaron Copley
źródło

1

Dziękuję bardzo za to. Wygląda idealnie. Jeśli nic więcej, mogę napisać coś w C, aby przechwycić dane wejściowe. Zaimplementuję to i dam znać, czy to działa.

1

@BiggyDevOPs: pomocna sugestia: jeśli używasz płaskiego pliku do przechowywania dziennika, umieść go w git lub svn, aby mieć historię

— Michael Martinez

7

Alternatywą jest uprzywilejowane rozwiązanie do zarządzania kontami, w którym zamiast zapewniać administratorom dostęp do własnego konta, konta administracyjne są przechowywane w depozycie przez osobę trzecią, a obowiązkowe procedury muszą być przestrzegane, zanim administratorzy będą mogli uzyskać dostęp do systemów produkcyjnych http: // en. m.wikipedia.org/wiki/Privileged_Identity_Management

— HBruijn
źródło

0

Innym sposobem na osiągnięcie tego byłoby posiadanie scentralizowanego narzędzia do rejestrowania (myślę, że Logstash, ale możesz to zrobić na inne sposoby), aby zabrał swój plik auth.log na systemy produkcyjne i umieścił go w aplikacji, w której ludzie mogą rejestrować swoje uzasadnienia .

— gWaldo
źródło

0

Sposób, w jaki widziałem to zaimplementowane u klientów, którzy korzystają z HP Server Automation ^* , polega na tym, że polegają oni na wewnętrznym logowaniu narzędzia z kombinacją kroków zatwierdzania (byłem z kilkoma klientami, w których nie ma uprawnień sudo ani root, z wyjątkiem Dev ).

Zatwierdzeń można dokonać za pomocą czegoś takiego jak Remedy and Operations Orchestration, lub dane administracyjne w SA itp.

Że wszystko zostało powiedziane, poza narzędzi do automatyzacji i zarządzania przedsiębiorstwem, @ Aaron Copley „s odpowiedź jest doskonałym wyborem.

^* Jestem starszym pracownikiem HPSA, HPOO i innymi aspektami konsultanta pakietu automatyzacji HP

— królikarnia
źródło

0

Szukając rozwiązania, przeczytałem odpowiedź Aarona Copleya i pomyślałem: „A jeśli zmienię powłokę użytkownika?”

Zrobiłem to z powodzeniem na moim komputerze Ubuntu 14.04:

# usermod -s /usr/bin/loginScript username

W skrypcie możesz po prostu uchwycić powód logowania. Mój jest taki:

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

Należy zwrócić uwagę na jedną rzecz: skrypt nie jest uruchamiany jako root, więc może być konieczne udzielenie użytkownikowi pewnych uprawnień, aby działał.

— william.wd
źródło