Git melakukan audit


16

Saya memiliki server git yang menjalankan ssh dan setiap pengguna memiliki akun unix di sistem.

Mengingat bahwa dua pengguna memiliki akses ke repo, bagaimana saya bisa memastikan pengguna mana yang melakukan komit, karena nama pengguna dan email komit diajukan dan dikendalikan oleh klien git.

Saya khawatir bahwa pengguna mungkin mencoba menyamar sebagai orang lain, meskipun mereka memiliki hak otorisasi yang sama.


Saya bingung. Anda mengatakan dalam pertanyaan bahwa setiap pengguna memiliki akun shell mereka sendiri, tetapi dalam komentar Anda mengatakan bahwa mereka semua berbagi satu akun dan menggunakan kunci terpisah untuk otentikasi. Yang mana, atau keduanya?
Scott Pack

Bisa jadi salah satunya. Pengaturan saat ini adalah yang dijelaskan dalam pertanyaan (satu akun ssh per pengguna), tetapi ini tidak skala dengan baik dan saya mungkin ingin pergi dengan satu pengguna / banyak kunci di masa depan. Saya hanya mencari solusi paling serbaguna yang tidak akan mengunci saya ke satu atau metode otentikasi lain.
yannisf

1
Perlu ditunjukkan bahwa "orang yang membuat komit" dan "orang yang mendorong beberapa komitmen untuk repo ini" tidak harus sama dalam kasus umum. Saya bisa menarik komitmen Anda dari repo Anda dan kemudian mendorong mereka (seperti saya) ke repo pihak ketiga.
jamaah

Jawaban:


13

Jika Anda begitu khawatir tentang itu, ada beberapa cara untuk mengatasi masalah ini.

  1. Buat pengguna Anda menandatangani komitmen Anda, ada dukungan untuk menandatangani GPG.
  2. Jangan beri pengguna hak untuk komit ke repositori utama, minta mereka komit ke repositori mereka sendiri dan kemudian minta pengguna tepercaya membawa perubahan ke repositori utama. Itu sebabnya jika Anda melihat pesan log untuk beberapa proyek git (seperti git itu sendiri) Anda akan melihat bahwa mereka adalah bidang yang terpisah untuk "Penulis" - orang yang membuat perubahan. dan "Committer" - orang yang melakukan perubahan ke dalam repositori.

1. Saran ini tampaknya paling tepat untuk tujuan saya. Namun, apakah ada mekanisme untuk menolak komitmen yang tidak ditandatangani di sisi server? 2. Sejauh menyangkut solusi ini, pengguna yang menarik dari repo bawahan harus memeriksa ulang apakah committer tersebut belum menggunakan nama pengguna / email palsu. Benar?
yannisf

Berhati-hatilah, Anda dapat menandatangani komit dengan identitas penggantinya dan pengarang yang ingin Anda pilih. Jelas, Anda akan dapat melihat siapa yang melakukan penempaan (atau tidak menjaga kunci pribadi mereka).
CB Bailey

Karenanya peringatan saya tentang hanya memiliki pengguna tepercaya yang berkomitmen pada repositori utama.
Abizern

@ Ambizern: Cukup adil. Ketika saya membacanya, (1) dan (2) Anda sepertinya menggambarkan opsi-opsi alternatif.
CB Bailey

1
@yannisf Mengenai pertanyaan pertama Anda, kait pembaruan (jalankan server-side) mungkin memeriksa tanda tangan dan menolak memperbarui masing-masing referensi. Lihat .git/hooks/update.sampleuntuk inspirasi. Tolong @ beri tahu saya jika Anda mengajukan pertanyaan tentang ini di SO, itu akan menarik bagi saya juga
Tobias Kienzler

9

Saya melihat dua cara bagus untuk mendapatkan informasi semacam ini. Salah satunya adalah dengan meningkatkan logging dari sshd itu sendiri, dan yang lainnya dengan melakukan pemantauan yang lebih dalam dari repositori git pada disk. Karena tidak ada satu pun yang memberi Anda informasi yang Anda inginkan, Anda mungkin ingin melakukan keduanya dan mengkorelasikan data log menggunakan mesin analisis log eksternal atau sesuai permintaan menggunakan mata manusia dan cap waktu.

Modifikasi sshd

Secara default, seperti yang Anda lihat, Anda dapat melihat ketika pengguna masuk, dan dari mana, menggunakan log otentikasi ssh. Yang ingin Anda lakukan adalah mengubah level saat Anda keluar dari sshd. Jadi edit /etc/ssh/sshd_configdan temukan garis yang terlihat

#LogLevel INFO

dan mengubahnya menjadi

LogLevel VERBOSE

kemudian restart layanan sshd. Ini meningkatkan level logging sshd sebanyak 1 langkah, yang memberikan lebih banyak informasi. Lihat potongan log ini dari akses jarak jauh saya setelah melakukan perubahan itu.

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 

Hal-hal penting yang perlu diperhatikan di sini adalah dua kali lipat

  1. Kami melihat sidik jari kunci publik yang digunakan untuk mengotentikasi saya
  2. Kami melihat stempel waktu logout saya

Menggunakan default LogLevel (INFO) sshd tidak mencatat kedua item tersebut. Mendapatkan sidik jari kunci adalah satu langkah ekstra. Anda harus memproses authorized_keysfile yang sesuai dengan 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)

Jadi sekarang Anda tahu informasi berikut:

  1. Nama pengguna yang masuk
  2. Waktu pengguna itu masuk
  3. Kunci publik mana yang digunakan untuk otentikasi
  4. Waktu pengguna itu logout

Sekarang kita memiliki cara untuk mengaitkan tindakan pengguna pada waktu tertentu, dengan asumsi kedua pengguna tidak masuk pada saat yang sama, kita dapat mulai melihat perubahan yang dilakukan pada repositori.

Pemantauan Direktori dengan Auditd

Seperti yang dikatakan sysadmin1138, ini bisa menjadi kasus penggunaan yang sangat baik untuk subsistem auditd. Jika Anda tidak menggunakan distro berbasis RedHat mungkin ada analog, tetapi Anda harus menemukannya. Konfigurasi untuk auditd cukup intens dan memiliki sejumlah opsi konfigurasi yang redonkulous. Untuk mendapatkan gagasan tentang beberapa opsi, silakan lihat pertanyaan ini di situs saudara kami untuk Profesional Keamanan Informasi .

Minimal, saya akan merekomendasikan pengaturan apa yang disebut "jam tangan" pada direktori pada disk yang berisi repositori git Anda. Apa yang dilakukan adalah menginstruksikan modul kernel untuk melaporkan upaya untuk melakukan panggilan akses file, seperti open()atau creat(), pada file menangani menunjuk ke file atau direktori yang kami daftarkan.

Berikut contoh konfigurasi yang akan melakukan ini, dan hanya ini. Jadi berhati-hatilah untuk membaca, dan memahami, keberadaan Anda /etc/audit/audit.rulesuntuk mengintegrasikan perubahan dengan tepat.

# 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

terima kasih banyak atas jawaban terinci Anda! Ini benar-benar lengkap dari perspektif administrator sistem. Apa yang saya cari adalah solusi yang tidak perlu satu untuk menyelesaikan begitu banyak audit tingkat rendah, dan idealnya akan mencegah melakukan palsu daripada menyelesaikan forensik setelah fakta.
yannisf

2
Nah, Anda memang bertanya di situs Sistem Administrasi dan saya seorang pemeriksa forensik .... :)
Scott Pack

5

Satu-satunya pendekatan teknis yang dapat Anda lakukan adalah mempercayai identitas koneksi ssh. Anda kemudian dapat memastikan bahwa setiap pengguna hanya mendorong komit yang dibuatnya dengan memvalidasi committer dari setiap komit yang didorong baru.

Agar ini dapat diandalkan, Anda hampir pasti tidak ingin memberikan pengguna Anda akses shell tidak terbatas ke kotak tempat repositori berada; Anda ingin memastikan penggunaan sesuatu seperti git-shellhanya sebaliknya pembatasannya mudah diatasi.

Namun, para pengguna masih dapat menyamar sebagai penulis. Anda dapat membatasi ini juga, tetapi ini akan kehilangan alur kerja umum seperti memetik dan memurnikan kembali ceri dan bahkan mungkin bercabang (tergantung pada implementasi kait Anda) sehingga Anda mungkin tidak ingin melakukan ini.

Pada titik tertentu, sampai batas tertentu, Anda perlu mempercayai pengembang Anda.


3

Banyak daemon ssh membuat entri /var/log/audit.logatau sesuatu yang serupa ketika koneksi ssh diterima. Referensi silang log ini dengan commit-log harus memberi Anda gambaran tentang pengguna ssh mana yang digunakan untuk mengeluarkan komit. Ini adalah langkah audit, yang akan digunakan setelah fakta untuk verifikasi.

Sebenarnya menegakkan pengguna ssh yang benar untuk pengguna git yang tepat adalah untuk salah satu jawaban lain di sini.


Masih ada pengaturan yang pengguna login dengan pengguna ssh yang sama tetapi menggunakan kunci (resmi) yang berbeda. Ini membuat audit semakin sulit.
yannisf

@yannisf: Anda benar, itu memang sedikit mengubah keadaan. Dengan sedikit keberuntungan saya membantu mengatasi kebutuhan ekstra Anda untuk berurusan dengan akses akun yang tidak dapat diatribusikan.
Scott Pack

0

Jika semua pengguna memiliki akun shell dengan akses tulis ke repositori, Anda tidak akan dapat membuat log audit yang dapat dipercaya: mereka masih bisa memodifikasi repositori tanpa menulis ke log, dan mereka dapat menulis apa pun yang mereka inginkan ke log.

Untuk dapat mempercayai log audit, Anda harus mencegah akses tulis tingkat file langsung ke repositori, alih-alih menggunakan sesuatu seperti gitolite (yang berjalan di akunnya sendiri) untuk memediasi akses ke repositori.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.