web-dev-qa-db-ja.com

Gitコミット監査

私はssh上で実行されているgitサーバーを持っており、各ユーザーはシステム上にunixアカウントを持っています。

2人のユーザーがリポジトリにアクセスできる場合、コミットユーザー名と電子メールはgitクライアントによって送信および制御されるため、どのユーザーがどのコミットを実行したかを確認するにはどうすればよいですか。

ユーザーが同じ承認権限を持っている場合でも、別のユーザーになりすまそうとする可能性があるのではないかと心配しています。

gitsecurityaudit
16
yannisf

あなたがそれを心配しているなら、問題に対処する方法がいくつかあります。

  1. ユーザーにコミットに署名させます。GPG署名がサポートされています。
  2. ユーザーにメインリポジトリにコミットする権利を与えないでください。ユーザーに自分のサブリポジトリにコミットさせてから、信頼できるユーザーに変更をメインリポジトリに持ち込んでもらいます。そのため、一部のgitプロジェクト（git自体など）のログメッセージを見ると、「作成者」（変更を作成した人）の個別のフィールドであることがわかります。および「コミッター」-リポジトリに変更をコミットした人。
13
Abizern

この種の情報を取得するには、2つの良い方法があります。 1つは、sshd自体からのロギングを増やすことによるもので、もう1つは、ディスク上のgitリポジトリのより深い監視を行うことによるものです。どちらも必要な情報を個別に提供しないため、両方を実行し、外部ログ分析エンジンを使用して、または人間の目とタイムスタンプを使用してオンデマンドでログデータを相互に関連付けることができます。

sshdの変更

デフォルトでは、間違いなく見てきたように、ssh認証ログを使用して、ユーザーがいつどこからログインしたかを確認できます。やりたいことは、sshdからログアウトするときにレベルを変更することです。したがって、_/etc/ssh/sshd_config_を編集して、次のような行を見つけます。

_#LogLevel INFO
_

それをに変更します

_LogLevel VERBOSE
_

次に、sshdサービスを再起動します。これにより、sshdのログレベルが1ステップ増え、より多くの情報が得られます。その変更を行った後、私のリモートアクセスのこのログスニペットをチェックしてください。

_Nov  2 08:37:09 node1 sshd[4859]: Connection from 10.10.10.5 port 50445
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4860]: Postponed publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4859]: Accepted publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: pam_unix(sshd:session): session opened for user scott by (uid=0)
Nov  2 08:37:10 node1 sshd[4859]: User child is on pid 4862
Nov  2 08:40:27 node1 sshd[4862]: Connection closed by 10.10.10.5
Nov  2 08:40:27 node1 sshd[4862]: Transferred: sent 30632, received 7024 bytes
Nov  2 08:40:27 node1 sshd[4862]: Closing connection to 10.10.10.5 port 50445
Nov  2 08:40:27 node1 sshd[4859]: pam_unix(sshd:session): session closed for user scott 
_

ここで注意すべき重要なことは2つあります

  1. 私を認証するために使用された公開鍵の指紋が表示されます
  2. ログオフのタイムスタンプが表示されます

デフォルトのLogLevel（INFO）sshdを使用すると、これらの項目はどちらもログに記録されません。キーのフィンガープリントを取得することは、1つの追加のステップです。適切な_authorized_keys_ファイルをssh-keygen自体で処理する必要があります。

_[root@node1 ssh]# ssh-keygen -l -f /home/scott/.ssh/authorized_keys
4096 f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06 /home/scott/.ssh/authorized_keys (RSA)
_

これで、次の情報がわかりました。

  1. ログオンしたユーザー名
  2. ユーザーがログオンした時間
  3. 認証に使用された公開鍵
  4. ユーザーがログオフした時間

両方のユーザーが同時にログインしていなかったと仮定して、特定の時間にユーザーアクションを関連付ける方法ができたので、リポジトリに加えられた変更を確認し始めることができます。

Auditdによるディレクトリ監視

Sysadmin1138が述べたように、これはauditdサブシステムの優れたユースケースになる可能性があります。 RedHatベースのディストリビューションを使用していない場合は、おそらくアナログがありますが、それを見つける必要があります。 auditdの構成はかなり集中的であり、非常に多くの構成オプションがあります。いくつかのオプションのアイデアを得るために、これをチェックしてください 質問 私たちの姉妹 情報セキュリティ専門家のサイト をご覧ください。

最低限、問題のgitリポジトリを含むディスク上のディレクトリに「ウォッチ」と呼ばれるものを設定することをお勧めします。これは、リストするファイルまたはディレクトリを指すファイルハンドルで、open()やcreat()などのファイルアクセス呼び出しを実行しようとしたことを報告するようにカーネルモジュールに指示します。

これを行うサンプル構成は次のとおりです。したがって、変更を適切に統合するために、既存の_/etc/audit/audit.rules_をよく読んで理解するように注意してください。

_# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-w /path/to/git/repos-p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2
_
9
Scott Pack

実行できる唯一の技術的アプローチは、ssh接続のIDを信頼することです。次に、新しいプッシュされた各コミットのコミッターを検証することにより、各ユーザーが自分が行ったコミットのみをプッシュするように強制できます。

これを信頼できるものにするために、リポジトリが存在するボックスへの無制限のシェルアクセスをユーザーに許可したくないことはほぼ間違いありません。 git-Shellのようなものを確実に使用したい場合にのみ、そうでなければ制限が簡単に回避されます。

ただし、ユーザーは引き続き作成者としてお互いになりすますことができます。これを制限することもできますが、チェリーピッキングやリベースなどの一般的なワークフローが失われ、おそらくブランチ（フックの実装に応じて）さえも失われる可能性があるため、これを実行したくない場合があります。

ある時点で、ある程度、開発者を信頼する必要があります。

5
CB Bailey

多くのsshデーモンは、ssh接続が受信されると、/var/log/audit.logまたは同様のものにエントリを作成します。このログをcommit-logと相互参照すると、コミットの発行にどのssh-userが使用されたかがわかります。これは監査ステップであり、事後に検証のために使用されます。

実際に正しいssh-userを適切なgit-userに強制することは、ここでの他の答えの1つです。

3
sysadmin1138