Gitコミット監査


16

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

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

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


よくわかりません。質問では、各ユーザーが独自のシェルアカウントを持っていると言いますが、コメントでは、すべてのユーザーが単一のアカウントを共有し、認証に個別のキーを使用すると言います。どちらですか、それとも両方ですか?
スコットパック

どちらかです。現在のセットアップは質問で説明されているものです(ユーザーごとに1つのsshアカウント)が、これはうまく拡張できず、将来的には単一のユーザー/多くのキーを使用したいと思うかもしれません。いずれかの認証方法に縛られることのない、最も用途の広いソリューションを探しています。
yannisf

1
「コミットを行う人」と「このリポジトリにいくつかのコミットをプッシュする人」は、一般的なケースでは必ずしも同じではないことを指摘する価値があります。リポジトリからコミットをプルし、サードパーティのリポジトリにプッシュすることができます。
ニックグリム

回答:


13

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

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

1.この提案は、私の目的に最も適しているようです。それでも、サーバー側で未署名のコミットを拒否するメカニズムはありますか?2.このソリューションに関する限り、下位リポジトリからプルするユーザーは、コミッターが偽のユーザー名/電子メールを使用していないことを再確認する必要があります。本当?
yannisf

ただし、選択したいコミッターと著者のIDを使用してコミットに署名できます。明らかに、誰が偽造したのか(または、秘密鍵の面倒を見なかった)を確認できます。
CBベイリー

したがって、信頼できるユーザーのみがメインリポジトリにコミットすることについての私の警告。
アビゼル

@Abizern:結構です。私がそれを読んだとき、あなたの(1)と(2)は代替オプションを説明しているように見えました。
CBベイリー

1
@yannisf最初の質問については、更新フック(サーバー側で実行)が署名をチェックし、それ以外の場合はそれぞれの参照の更新を拒否します。.git/hooks/update.sampleインスピレーションのために見てください。あなたはSOで、この上の質問をするならば、それはあまりにも、私にとって興味深いものになるだろう、私に連絡してください@
トビアスKienzler

9

この種の情報を取得するには、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_keysssh-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

詳細な回答ありがとうございます!これは、システム管理者の観点からは本当に完全です。私が探していたのは、それほど低レベルの監査に解決する必要はなく、理想的には、事後のフォレンジックに解決するのではなく、偽造されたコミットを防ぐソリューションです。
-yannisf

2
さて、あなたはシステム管理サイトで尋ねましたが、私は法医学の審査官です。...:)
スコットパック

5

あなたが取ることができる唯一の技術的アプローチは、ssh接続のアイデンティティを信頼することです。次に、プッシュされた各コミットのコミッターを検証することにより、各ユーザーがコミットしたもののみをプッシュするように強制できます。

これを信頼できるものにするためには、リポジトリが存在するボックスへの無制限のシェルアクセスをユーザーに与えたくないでしょう。git-shellそうでない場合にのみ制限を簡単に回避できるようなものの使用を保証したいと思うでしょう。

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

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


3

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

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


ユーザーは同じsshユーザーでログインしますが、異なる(許可された)キーを使用する設定がまだあります。これにより、監査がさらに難しくなります。
-yannisf

@yannisf:その通りです、それは少し物事を変えます。運がよければ、帰属しないアカウントへのアクセスに対処するという余分なニーズに対処することができました。
スコットパック

0

すべてのユーザーがリポジトリへの書き込みアクセス権を持つシェルアカウントを持っている場合、信頼できる監査ログを設定することはできません。ユーザーは、ログに書き込むことなくリポジトリを変更でき、ログに必要なものを書き込むことができます。

監査ログを信頼できるようにするには、リポジトリへの直接のファイルレベルの書き込みアクセスを防止し、代わりにgitolite(独自のアカウントで実行)などを使用してリポジトリへのアクセスを仲介する必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.