システム管理者にprodサーバーへのアクセス理由を記録するよう強制する手法が必要

17

私の会社では、ユーザーが運用サーバーにログインするときはいつでも、そのユーザーがログインした理由とユーザーが加えようとする変更を記録する必要があります。私のチームはこれをしたいのですが、忘れがちです。私は彼らが覚えているのを助けたいです。私はmotdを検討しましたが、もう少し強力なものが必要です。

私の最初の考えは、ユーザーのシェルを次のようなスクリプトに変更することでした

vim /logs/logindate.txt 
bash -l

より良いまたはより標準的な技術はありますか？

注：これらのユーザーはシステム管理者であり、システムを破壊することなくログエントリを作成したいという考えです-彼らは頻繁にそうすることを忘れます。だから、もし彼らがそれをctrl-cできるなら、まあ...そうしないと仮定している。

linux logging

6

ワークフロー/手順の問題に対する技術的な解決策を見つけようとしています。私見、そのような努力は失敗する運命にあり、実際のワークフロー/手順の問題は非技術的な手段で直接対処されるべきです。

— ジョン14

11

ありがとう。私はテクノロジーを使って行動の変化を促進しようとしています。彼らが忘れるたびに岩でクラブを組むことができると思うが、人事は技術的なアプローチを好むと思う。

8

@Johnテクノロジーの目的の一部ではなく、ワークフローを実装して支援しますか？

— マイケル・マルティネス14

1

解雇を含む懲戒処分。

— マイケルハンプトン

4

はい、しかし質問は「あなたはそれをするべきですか？」ではありませんでした。質問は「できますか？」でした。1つは価値判断です。1つは、このフォーラムに値する技術的な質問です。私は自分のチームを管理する能力に自信があります。私は大成功で岩を使用することができましたが、非常に多くの血。私はいい人が好きです。忘れっぽい管理者がいます。:)今回は@ aaron-copleyが男性のようです。みんな、ありがとう！

19

pam_exec.soを見てください。PAMのsystem-authのセッションインターフェイスでログイン時にスクリプトを実行できます。スクリプトは、ユーザーがシェルを取得する前にルートとして実行されるため、read？を使用して入力をキャプチャしない場合があります。ただし、readユーザーから理由を取得し、loggerステートメントを使用してsyslogに記録するために使用できます。（以下では省略しましたが、理由なく終了することを防ぐために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}"

これが完全に機能しない場合はおApび申し上げます。私はそれをテストしませんでしたが、最近似たようなことをしました。（入力をキャプチャしませんでした。）

編集：これについて考えれば考えるほど、それが実行される段階のために機能するとは思わない。同じgetreasonスクリプトでは、交換後動作するはず$PAM_USERで$(logname)、それはで実行する必要があるかもしれません/etc/profile。（最初に対話型シェルをテストします。）

少なくとも他に何もなければ正しい方向に考えさせるために、両方のオプションを残しておきます。

— アーロン・コプリー
ソース

1

本当にありがとうございました。それは完璧に見えます。何もしなければ、入力をキャプチャするためにCで小さなことを書くことができます。これを実装し、機能するかどうかをお知らせします。

1

@BiggyDevOPs：役に立つ提案：あなたはログを維持するために、フラット・ファイルを使用する場合は歴史を持っているように、gitのやsvnでそれを置く

— マイケル・マルティネス

7

代替手段は特権アカウント管理ソリューションです。管理者が自分のアカウントでアクセスするのではなく、管理者アカウントが第三者によってエスクローに保持され、管理者が本番システムにアクセスする前に必須手順に従う必要があります。 m.wikipedia.org/wiki/Privileged_Identity_Management

— HBruijn
ソース

0

これを実現する別の方法は、集中ログ機能（Logstashを考えていますが、他の方法でこれを行うことができます）に本番システムでauth.logを取得し、人々が正当化を記録できるアプリにフィードすることです。

— グワルド
ソース

0

HP Server Automation ^*を実行している顧客に実装されたこれを見る方法は、承認ステップの組み合わせでツールの生得のログに依存していることです（私はDev以外にsudoまたはroot privがないいくつかの顧客に行ってきました）。

承認は、Remedy and Operations Orchestration、SA内の管理ログインなどの方法で実行できます。

エンタープライズオートメーションおよび管理ツール以外では、@ Aaron Copleyの答えは素晴らしい選択です。

^*私はシニアHPSA、HPOO、およびHPオートメーションスイートコンサルタントの他の側面です。

— ウォーレン
ソース

0

解決策を探している間、私はアーロン・コプリーの答えを読み、「ユーザーのシェルを変更したらどうなるか」と考えました。

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

注意すべき点が1つあります。スクリプトはrootとして実行されないため、この機能を使用するにはユーザーにいくつかのアクセス許可を付与する必要があります。

— william.wd
ソース