Вопрос: Git совершает аудит


У меня есть git-сервер, работающий поверх ssh, и каждый пользователь имеет учетную запись unix в системе.

Учитывая, что у двух пользователей есть доступ к репо, как я могу быть уверен в том, какой пользователь выполнил, который фиксирует, поскольку имя и адрес пользователя фиксации отправляются и контролируются клиентом git.

Я обеспокоен тем, что пользователь может попытаться выдать себя за другого, даже если он имеет одинаковые права на авторизацию.


16
2017-11-02 11:04


Источник


Я смущен. Вы говорите в вопросе, что каждый пользователь имеет свою собственную учетную запись оболочки, но в комментарии вы говорите, что все они используют одну учетную запись и используют отдельные ключи для аутентификации. Что это такое, или это так? - Scott Pack
Может быть и то. Текущая настройка - та, которая описана в вопросе (одна учетная запись ssh для каждого пользователя), но это не очень хорошо масштабируется, и в будущем я могу захотеть использовать один пользовательский / много ключей. Я просто ищу наиболее универсальное решение, которое не будет блокировать меня в том или ином методе аутентификации. - yannisf
Стоит отметить, что «человек, делающий совершение» и «человек, который подталкивает некоторые обязательства к этому репо», в общем случае не обязательно одинаковы. Я мог бы вытащить ваши коммиты из вашего репо, а затем подтолкнуть их (как я) к стороннему репо. - nickgrim


Ответы:


Если вы беспокоитесь об этом, есть несколько способов решения проблемы.

  1. Сделайте подписку своих подписчиков, есть поддержка подписи GPG.
  2. Не предоставляйте пользователям право передавать основной репозиторий, заставляйте их фиксировать свой собственный субрепозитор, а затем доверенный пользователь вносит изменения в основной репозиторий. Поэтому, если вы посмотрите на сообщения журнала для некоторых проектов git (например, git), вы увидите, что это отдельные поля для «Автор» - человека, который создал изменение. и «Коммиттер» - лицо, совершившее изменение в хранилище.

13
2017-11-02 11:11



1. Это предложение представляется наиболее подходящим для моих целей. Тем не менее, существует механизм отклонения неподписанных коммитов на стороне сервера? 2. Что касается этого решения, пользователь, вытаскивающий из подчиненного репо, должен будет дважды проверить, что коммиттер не использовал поддельное имя пользователя / адрес электронной почты. Правда? - yannisf
Однако будьте осторожны, вы можете подписать фиксацию с любыми объектами коммиттера и автора, которые вы хотите выбрать. Очевидно, вы сможете узнать, кто сделал ковку (или не заботился о своем личном ключе). - CB Bailey
Следовательно, мое предостережение только о том, что доверенные пользователи фиксируют основной репозиторий. - Abizern
@Abizern: Достаточно справедливо. Когда я прочитал, ваши (1) и (2) выглядели как альтернативные варианты. - CB Bailey
@yannisf Что касается вашего первого вопроса, крюк обновления (на стороне сервера) могут проверять сигнатуры и в противном случае отклонять обновление соответствующих ссылок. Посмотрите на .git/hooks/update.sample для вдохновения. Пожалуйста, @ уведомите меня, если вы зададите вопрос по этому поводу в SO, это было бы интересно для меня тоже - Tobias Kienzler


Я вижу два хороших способа получить такую ​​информацию. Один из них заключается в увеличении регистрации с самого sshd, а другой - на более глубоком мониторинге репозитория 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 

Важные вещи, которые можно заметить здесь, в два раза

  1. Мы видим отпечаток открытого ключа, используемый для аутентификации меня
  2. Мы видим временную метку моего журнала

При использовании журнала logLevel (INFO) по умолчанию не отображается ни один из этих элементов. Получение отпечатка ключа - еще один шаг. Вы должны обработать соответствующие 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
2017-11-02 12:27



Большое вам спасибо за подробный ответ! Это действительно полно с точки зрения системных администраторов. То, что я смотрел, было решением, которое не требовало бы такого, чтобы разрешить столь низкий уровень аудита, и в идеале предотвратит кованые коммиты, а не разрешит судебную экспертизу после факта. - yannisf
Ну, вы спрашивали на сайте системного администрирования, и я эксперт по судебной экспертизе .... :) - Scott Pack


Единственный технический подход, который вы можете предпринять, - это доверять личности ssh-соединения. Затем вы можете обеспечить, чтобы каждый пользователь только толкал коммиты, которые он сделал, проверяя коммиттер каждого нового нажатого фиксации.

Чтобы это было надежно, вы почти наверняка не хотите предоставлять своим пользователям неограниченный доступ к оболочке в ящик, в котором находится репозиторий; вы хотели бы обеспечить использование чего-то вроде git-shell только в противном случае ограничения легко обрабатываются.

Тем не менее, пользователи все равно смогут олицетворять друг друга как авторов. Вы также можете ограничить это, но это может привести к потерям общих рабочих процессов, таких как выбор вишни и перезагрузка и, возможно, даже ветвление (в зависимости от реализации вашего крючка), чтобы вы не захотели этого делать.

В какой-то момент, в некоторой степени, вам нужно доверять своим разработчикам.


5
2017-11-02 11:12





Многие демоны ssh делают запись в /var/log/audit.log или что-то подобное при получении ssh-соединения. Перекрестная ссылка на этот журнал с журналом фиксации должна дать вам представление о том, какой из ssh-пользователей использовался для выдачи фиксации. Это шаг аудита, который будет использоваться после подтверждения факта.

На самом деле, правильное использование ssh-user для соответствующего git-пользователя для одного из других ответов здесь.


3
2017-11-02 12:08



По-прежнему существует настройка для входа в систему с одним и тем же пользователем ssh, но с использованием разных (разрешенных) ключей. Это делает аудит еще сложнее. - yannisf
@yannisf: Ты прав, это немного меняет ситуацию. В любом случае я помог вам удовлетворить ваши дополнительные потребности в работе с доступом, не относящимся к учетной записи. - Scott Pack


Если у всех пользователей есть учетные записи с правами на запись в репозиторий, вы не сможете настроить надежный журнал аудита: они все равно могут изменить репозиторий без записи в журнал, и они могут писать все, что захотят в журнале.

Чтобы иметь возможность доверять журналу аудита, вам нужно будет запретить прямой доступ на запись на уровне файла в репозиторий, вместо этого использовать что-то вроде gitolite (которое запускается в его собственной учетной записи) для посредничества доступа к репозиторию.


0
2018-01-11 02:45