Mam serwer git działający na ssh, a każdy użytkownik ma konto uniksowe w systemie.

Biorąc pod uwagę, że dwóch użytkowników ma dostęp do repozytorium, w jaki sposób mogę się upewnić, który użytkownik wykonał które zatwierdzenie, ponieważ nazwa użytkownika i adres e-mail zatwierdzenia są przesyłane i kontrolowane przez klienta git.

Obawiam się, że użytkownik może podszyć się pod innego, nawet jeśli ma takie same uprawnienia autoryzacyjne.

Jeśli martwisz się tym, istnieje kilka sposobów rozwiązania tego problemu.

1. Niech użytkownicy podpiszą twoje zobowiązania, istnieje obsługa podpisywania GPG.
2. Nie daj użytkownikom prawa do zatwierdzenia do głównego repozytorium, poproś, aby zobowiązali się do własnego repozytorium, a następnie niech zaufany użytkownik wprowadzi zmiany do głównego repozytorium. Dlatego jeśli spojrzysz na komunikaty dziennika dotyczące niektórych projektów git (takich jak sam git), zobaczysz, że są to osobne pola dla „autora” - osoby, która stworzyła zmianę. oraz „Committer” - osoba, która dokonała zmiany w repozytorium.

Widzę dwa dobre sposoby na uzyskanie tego rodzaju informacji. Jednym z nich jest zwiększenie rejestrowania z samego sshd, a drugim poprzez głębsze monitorowanie repozytorium git na dysku. Ponieważ żaden z nich indywidualnie nie podaje potrzebnych informacji, możesz wykonać jedno i drugie i skorelować dane dziennika za pomocą zewnętrznego silnika analizy dziennika lub na żądanie przy użyciu ludzkich oczu i znaczników czasu.

Modyfikacje sshd

Domyślnie, jak niewątpliwie widziałeś, możesz zobaczyć, kiedy użytkownik się zalogował i skąd, korzystając z dzienników uwierzytelniania ssh. Co chcesz zrobić, to zmienić poziom wylogowania z sshd. Edytuj więc /etc/ssh/sshd_configi znajdź linię, która wygląda

#LogLevel INFO

i zmień to na

LogLevel VERBOSE

następnie uruchom ponownie usługę sshd. Zwiększa to poziom rejestrowania sshd o 1 krok, co daje znacznie więcej informacji. Sprawdź ten fragment dziennika mojego zdalnego dostępu po wprowadzeniu tej zmiany.

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 

Ważne rzeczy, które należy tutaj zauważyć, są dwojakie

1. Widzimy odcisk palca klucza publicznego używanego do uwierzytelnienia mnie
2. Widzimy znacznik czasu mojego wylogowania

Korzystanie z domyślnego sshd LogLevel (INFO) nie rejestruje żadnego z tych elementów. Uzyskanie odcisku palca klucza to jeden dodatkowy krok. Musisz przetworzyć odpowiedni authorized_keysplik za pomocą ssh-keygen jako takiego.

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

Więc teraz znasz następujące informacje:

1. Nazwa użytkownika, który się zalogował
2. Czas zalogowania się użytkownika
3. Który klucz publiczny został użyty do uwierzytelnienia
4. Czas wylogowania użytkownika

Teraz, gdy mamy możliwość przypisania akcji użytkownika w określonym czasie, zakładając, że obaj użytkownicy nie byli zalogowani w tym samym czasie, możemy zacząć patrzeć na zmiany wprowadzone w repozytorium.

Monitorowanie katalogów za pomocą Auditd

Jak powiedział sysadmin1138, może to być doskonały przypadek użycia podsystemu poddanego audytowi. Jeśli nie używasz dystrybucji opartej na RedHat, prawdopodobnie jest to analog, ale musisz go znaleźć. Konfiguracja audytu jest dość intensywna i zawiera ponurą liczbę opcji konfiguracji. Aby zapoznać się z niektórymi opcjami, sprawdź to pytanie na naszej siostrzanej stronie dla specjalistów ds. Bezpieczeństwa informacji .

W minimalnym stopniu zaleciłbym ustawienie tak zwanego „watch” w katalogu na dysku, który zawiera dane repozytorium git. W ten sposób instruuje moduł jądra, aby raportował o próbach wywołań dostępu do plików, takich jak open()lub creat(), na uchwytach plików wskazujących na pliki lub katalogi, które wymieniliśmy.

Oto przykładowa konfiguracja, która by to zrobiła i tylko to. Uważaj więc na przeczytanie i zrozumienie swojego /etc/audit/audit.rules, aby odpowiednio zintegrować zmiany.

# 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

Jedynym technicznym podejściem, jakie możesz zastosować, jest zaufanie do tożsamości połączenia ssh. Następnie możesz wymusić, aby każdy użytkownik wypychał tylko zatwierdzenia, które sam wykonał, poprzez sprawdzenie zatwierdzającego każdego nowego wypychanego zatwierdzenia.

Aby było to niezawodne, prawie na pewno nie chcesz dać użytkownikom nieograniczonego dostępu powłoki do skrzynki, w której znajduje się repozytorium; chciałbyś upewnić się, że używasz czegoś takiego jak git-shelltylko w przeciwnym razie ograniczenia można łatwo obejść.

Użytkownicy nadal jednak mogliby się podszywać pod siebie jako autorzy. Możesz to również ograniczyć, ale straciłoby to typowe przepływy pracy, takie jak wybieranie i przekształcanie, a może nawet rozgałęzienie (w zależności od implementacji haka), więc możesz tego nie chcieć.

W pewnym momencie do pewnego stopnia musisz zaufać programistom.

Wiele demonów ssh dokonuje wpisu /var/log/audit.loglub czegoś podobnego po otrzymaniu połączenia ssh. Odwołanie tego dziennika do dziennika zmian powinno dać ci wyobrażenie, który użytkownik ssh został użyty do wydania zatwierdzenia. Jest to etap audytu, który należy zastosować po fakcie do weryfikacji.

Właściwe wymuszenie poprawnego użytkownika ssh dla odpowiedniego użytkownika git dotyczy jednej z pozostałych odpowiedzi tutaj.

Jeśli wszyscy użytkownicy mają konta powłoki z dostępem do zapisu do repozytorium, nie będzie można utworzyć wiarygodnego dziennika audytu: nadal mogą modyfikować repozytorium bez zapisywania w dzienniku i mogą zapisywać w nim wszystko, co chcą.

Aby móc zaufać dziennikowi kontroli, należy uniemożliwić bezpośredni dostęp do zapisu na poziomie pliku do repozytorium, zamiast tego używać czegoś takiego jak gitolite (który działa na swoim koncie) w celu pośredniczenia w dostępie do repozytorium.