Besoin d'une technique pour contraindre les administrateurs système à enregistrer la raison de l'accès à un serveur de prod


17

Mon entreprise exige que chaque fois qu'un utilisateur se connecte à un serveur de production, la raison pour laquelle la personne s'est connectée et les modifications que l'utilisateur a l'intention d'apporter doivent être enregistrées. Mon équipe veut le faire, mais c'est facile à oublier. Je voudrais les aider à se souvenir. J'ai considéré un motd, mais je veux quelque chose d'un peu plus fort.

Ma première pensée a été de changer le shell de l'utilisateur en un script qui fait quelque chose comme

vim /logs/logindate.txt 
bash -l

Existe-t-il une technique meilleure ou plus standard?

Remarque: L'idée est que ces utilisateurs sont des administrateurs système et souhaitent effectuer l'entrée de journal sans renverser le système - ils oublient souvent de le faire. Donc, s'ils peuvent le ctrl-c, eh bien ... nous supposons qu'ils ne le feront pas.


6
Vous essayez de trouver une solution technique à un problème de flux de travail / de procédure. À mon humble avis, un tel effort est voué à l'échec, et le problème de flux de travail / de procédure devrait être résolu directement par des moyens non techniques.
John

11
Merci mon pote. J'essaie d'utiliser la technologie pour promouvoir un changement de comportement. Je suppose que je pourrais simplement les associer à un rocher chaque fois qu'ils oublient, mais je pense que les RH préfèrent l'approche technologique.

8
@John Cela ne fait-il pas partie de l'objectif de la technologie de mettre en œuvre et de faciliter les flux de travail?
Michael Martinez

1
Action disciplinaire, pouvant aller jusqu'au licenciement.
Michael Hampton

4
Oui, mais la question n'était pas "devriez-vous le faire?" la question était, "pouvez-vous le faire?" L'un est un jugement de valeur; l'une est une question technique digne de ce forum. Je suis confiant dans ma capacité à gérer mon équipe. J'ai pu utiliser le rock avec beaucoup de succès, mais tellement de sang. J'aime être gentil. J'ai de bons administrateurs juste oublieux. :) On dirait que @ aaron-copley est l'homme cette fois. Merci tout le monde!

Réponses:


19

Regardez pam_exec.so . Vous pouvez exécuter un script lors de la connexion dans l'interface de session de l'authentification système de PAM. Le script s'exécute en tant que root avant que l'utilisateur n'obtienne un shell, il ne peut donc pas capturer d'entrée avec read? Vous pouvez cependant essayer et utiliser readpour obtenir une raison de l'utilisateur et l'enregistrer dans syslog avec une loggerinstruction. (J'ai omis ci-dessous, mais vous pouvez intercepter CTRL + C pour empêcher quiconque de quitter sans raison.) $ PAM_USER sera défini sur la personne qui se connecte, vous pouvez donc l'inclure dans l'instruction logger.

Exemple:

En haut de la session dans /etc/pam.d/system-auth:

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

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

Toutes mes excuses si cela ne fonctionne pas parfaitement. Je ne l'ai pas testé, mais j'ai récemment fait quelque chose de similaire. (Il n'a pas capturé d'entrée.)


Edit: Plus j'y pense, plus je ne pense pas que cela fonctionnera en raison de l'étape dans laquelle il s'exécute. Le même getreasonscript devrait fonctionner après le remplacement $PAM_USERpar $(logname), mais il peut être nécessaire de l'exécuter dans /etc/profile. (Testez d'abord le shell interactif.)

Je vais laisser les deux options en place, car cela devrait au moins vous faire penser dans la bonne direction, si rien d'autre.


1
Merci beaucoup pour ça. Ça a l'air parfait. Si rien d'autre, je peux écrire une petite chose en C pour capturer l'entrée. Je vais implémenter cela et vous faire savoir si cela fonctionne.

1
@BiggyDevOPs: suggestion utile: si vous utilisez un fichier plat pour conserver le journal, mettez-le en git ou svn afin d'avoir un historique
Michael Martinez

7

L'alternative est une solution de gestion de compte privilégiée, où plutôt que de donner aux administrateurs un accès avec leur propre compte, les comptes d'administrateur sont détenus par un tiers et les procédures obligatoires doivent être suivies avant que les administrateurs puissent accéder aux systèmes de production http: // fr. m.wikipedia.org/wiki/Privileged_Identity_Management


0

Une autre façon d'y parvenir serait d'avoir votre installation de journalisation centralisée (je pense à Logstash, mais vous pouvez le faire d'autres façons) de prendre votre auth.log sur les systèmes de production, de l'intégrer dans une application où les gens peuvent enregistrer leurs justifications .


0

La façon dont j'ai vu cela implémenté chez les clients qui exécutent HP Server Automation *, c'est qu'ils s'appuient sur la journalisation innée de l'outil avec une combinaison d'étapes d'approbation (je suis allé chez plusieurs clients où il n'y a pas de sudo ou de privilèges root, sauf dans Dev ).

Les approbations peuvent être effectuées via quelque chose comme Remedy and Operations Orchestration, ou une connexion administrative dans SA, etc.

Cela étant dit, en dehors des outils d'automatisation et de gestion d'entreprise, la réponse de @ Aaron Copley est un excellent choix.


* Je suis un HPSA senior, HPOO, et d'autres aspects du consultant HP Automation Suite


0

En cherchant une solution, j'ai lu la réponse d'Aaron Copley et j'ai pensé: "Et si je change le shell de mon utilisateur?"

Je l'ai fait avec succès sur ma machine Ubuntu 14.04:

# usermod -s /usr/bin/loginScript username

Sur votre script, vous pouvez simplement saisir la raison de la connexion. Le mien est comme ça:

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

Une chose que vous devez noter: le script n'est pas exécuté en tant que root, vous devrez donc peut-être donner à l'utilisateur certaines autorisations pour que cela fonctionne.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.