Ben ssh üzerinde çalışan bir git sunucusu var ve her kullanıcının sistemde bir unix hesabı var.

İki kullanıcının bir repo erişimi olduğu göz önüne alındığında, kesin kullanıcı adı ve e-postası git istemcisi tarafından gönderildiğinden ve denetlendiğinden, hangi kullanıcının hangi taahhüdü gerçekleştirdiğinden nasıl emin olabilirim.

Aynı yetkilendirme haklarına sahip olsalar bile, bir kullanıcının bir başkasını taklit etmeye çalışabileceğinden endişeliyim.

Bu konuda endişeleniyorsanız, sorunu ele almanın birkaç yolu vardır.

1. Kullanıcılarınızın taahhütlerinizi imzalamasını sağlayın, GPG imzalama desteği var.
2. Kullanıcılara ana veri havuzuna bağlılık hakkı vermeyin, kendi alt depolarını taahhüt etmelerini sağlayın ve ardından güvenilir bir kullanıcının değişiklikleri ana veri havuzuna getirmelerini sağlayın. Bu yüzden bazı git projelerinin (git'in kendisi gibi) günlük mesajlarına bakarsanız, bunların "Yazar" için ayrı alanlar olduğunu göreceksiniz - değişikliği yaratan kişi. ve "Committer" - depodaki değişikliği yapan kişi.

Bu tür bilgileri elde etmenin iki iyi yolunu görüyorum. Biri sshd'nin kendisinden günlüğe kaydetmeyi artırmak, diğeri ise diskteki git deposunu daha derinlemesine izlemek. Hiçbiri size tek tek istediğiniz bilgiyi vermediğinden, harici bir günlük analiz motoru kullanarak veya isteğe bağlı olarak insan gözlerini ve zaman damgalarını kullanarak günlük verilerini ilişkilendirmek isteyebilirsiniz.

sshd Değişiklikler

Varsayılan olarak, hiç şüphesiz gördüğünüz gibi, bir kullanıcının ne zaman oturum açtığını ve nereden ssh kimlik doğrulama günlüklerini kullanarak görebilirsiniz. Yapmak istediğiniz şey, sshd oturumunu kapatırken seviyenizi değiştirmek. Öyleyse düzenleyin /etc/ssh/sshd_configve benzeyen satırı bulun

#LogLevel INFO

ve bunu

LogLevel VERBOSE

sonra sshd hizmetini yeniden başlatın. Bu, sshd'nin kayıt seviyesini 1 adım arttırır, bu da çok daha fazla bilgi verir. Bu değişikliği yaptıktan sonra uzaktan erişimimin bu günlük snippet'ine göz atın.

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 

Burada dikkat edilmesi gereken önemli şeyler iki katlıdır

1. Beni doğrulamak için kullanılan ortak anahtarın parmak izini görüyoruz
2. Oturumu kapatmamın zaman damgasını görüyoruz

Varsayılan LogLevel (INFO) sshd kullanıldığında bu öğelerin hiçbiri günlüğe kaydedilmez. Bir anahtarın parmak izini almak ekstra bir adımdır. Uygun authorized_keysdosyayı ssh-keygen ile işlemek zorundasınız .

[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)

Şimdi aşağıdaki bilgileri biliyorsunuz:

1. Oturum açan kullanıcı adı
2. Kullanıcının oturum açtığı zaman
3. Kimlik doğrulama için hangi ortak anahtar kullanıldı
4. Kullanıcının oturumu kapattığı zaman

Artık kullanıcı eylemini belirli bir zamanda ilişkilendirmenin bir yoluna sahip olduğumuza göre, her iki kullanıcının da aynı anda giriş yapmadığını varsayarsak, depoda yapılan değişikliklere bakmaya başlayabiliriz.

Auditd ile Dizin İzleme

Sysadmin1138'in dediği gibi, bu denetleme alt sistemi için mükemmel bir kullanım durumu olabilir. RedHat tabanlı bir dağıtım kullanmıyorsanız muhtemelen bir analog var, ancak bulmanız gerekecek. Audit için yapılandırma oldukça yoğundur ve çok sayıda yapılandırma seçeneğine sahiptir. Bazı seçenekler hakkında fikir edinmek için lütfen Bilgi Güvenliği Uzmanları için kardeş sitemizde bu soruyu inceleyin .

En azından, söz konusu git deponuzu içeren diskteki dizinde "watch" olarak adlandırılanları ayarlamayı tavsiye ederim. Bu ne gibi dosya erişimi aramaları gerçekleştirmek için girişimleri üzerine rapora çekirdek modülü talimat olduğunu open()veya creat()dosyaları veya biz liste dizinlere işaret kolları Dosya.

İşte bunu yapacak örnek bir yapılandırma ve sadece bu. Bu nedenle, /etc/audit/audit.rulesdeğişiklikleri uygun bir şekilde entegre etmek için mevcut bilgilerinizi okuyup anlamaya dikkat edin .

# 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

Alabileceğiniz tek teknik yaklaşım, ssh bağlantısının kimliğine güvenmektir. Daha sonra, her bir kullanıcının yalnızca yeni itilen her bir taahhüdün değiştiricisini doğrulayarak yaptığı taahhütleri itmesini zorunlu kılabilirsiniz.

Bunun güvenilir olması için, kullanıcılarınıza deponun bulunduğu kutuya sınırsız kabuk erişimi vermek istemezsiniz; git-shellancak başka türlü kısıtlamaların kolayca çözülmesini sağlamak istersiniz .

Yine de kullanıcılar birbirlerini yazar olarak taklit edebilirler. Bunu da sınırlandırabilirsiniz, ancak bu kiraz toplama ve yeniden basma ve hatta dallanma (kanca uygulamanıza bağlı olarak) gibi yaygın iş akışlarını kaybeder, böylece bunu yapmak istemeyebilirsiniz.

Bir noktada, bir dereceye kadar, geliştiricilerinize güvenmeniz gerekir.

Birçok ssh arka plan programı /var/log/audit.log, bir ssh bağlantısı alındığında bir giriş veya benzeri bir şey yapar. Bu günlüğe kaydetme günlüğü ile çapraz referans vermek, hangi ssh kullanıcısının bir taahhüt vermek için kullanıldığı hakkında bir fikir vermelidir. Bu, doğrulama gerçeğinden sonra kullanılacak bir denetim adımıdır.

Aslında doğru ssh kullanıcısını uygun git kullanıcısına zorlamak, buradaki diğer cevaplardan biridir.

Tüm kullanıcıların havuza yazma erişimi olan kabuk hesapları varsa, güvenilir bir denetim günlüğü ayarlayamazsınız: günlüğe yazmadan depoyu değiştirebilirler ve günlüğe istedikleri her şeyi yazabilirler.

Denetim günlüğüne güvenebilmek için, depoya erişime aracılık etmek üzere gitolit (kendi hesabında çalışan) gibi bir şey kullanmak yerine, depoya doğrudan dosya düzeyinde yazma erişimini önlemeniz gerekir.