У мене працює сервер git, що працює над ssh, і кожен користувач має unix-акаунт у системі.

Зважаючи на те, що двоє користувачів мають доступ до репо, як я можу бути впевнений, який користувач виконував, хто виконує, оскільки ім'я користувача та електронна адреса комісії передаються та контролюються клієнтом git.

Я стурбований тим, що користувач може спробувати представити себе іншим, навіть якщо вони мають ті ж права авторизації.

Якщо вас це турбує, є кілька способів вирішити цю проблему.

1. Зробіть так, щоб ваші користувачі підписали свої зобов’язання, є підтримка підписання GPG.
2. Не дайте користувачам права брати участь у головному сховищі, дозвольте їм взяти на себе зобов’язання у власному сховищі, а потім довірений користувач внесе зміни до основного сховища. Ось чому, якщо ви подивитеся на повідомлення журналу для деяких git-проектів (наприклад, самого git), ви побачите, що це окремі поля для "Авторки" - людини, яка створила зміни. та "Комітер" - особа, яка здійснила зміну у сховищі.

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

Тепер, коли у нас є спосіб віднести дії користувача до певного часу, якщо припустити, що обидва користувачі не входили одночасно, ми можемо почати перегляд змін, внесених у сховище.

Моніторинг каталогів з аудитом

Як сказав sysadmin1138, це може бути відмінним випадком використання для підсистеми аудиту. Якщо ви не використовуєте дистрибутив на основі RedHat, можливо, є аналог, але вам доведеться його знайти. Конфігурація для аудита досить інтенсивна і має безліч варіантів конфігурації. Щоб отримати уявлення про деякі варіанти, перегляньте це питання на нашому сестринському сайті для спеціалістів з інформаційної безпеки .

Як мінімум, я б рекомендував налаштувати те, що називається "дивитися", на каталог на диску, що містить ваше сховище 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

Єдиний технічний підхід, який ви можете скористатись, - це довірити особі ssh-з'єднання. Потім ви можете встановити, що кожен користувач натискає лише на зобов’язання, які він зробив, перевіряючи виконувальник кожного нового надісланого комітету.

Щоб це було надійно, ви майже напевно не хочете надавати своїм користувачам необмежений доступ оболонки до вікна, де знаходиться сховище; Ви хочете забезпечити використання чогось подібного git-shellлише в іншому випадку обмеження легко подолати.

Однак користувачі все одно зможуть себе представити як автори. Ви можете також обмежити це, але це втратить загальні робочі процеси, такі як збирання та вивільнення вишні та, можливо, навіть розгалуження (залежно від реалізації вашої гачки), тому ви, можливо, не захочете цього робити.

У якийсь момент, певною мірою, вам потрібно довіряти своїм розробникам.

Багато ssh-демонів роблять запис /var/log/audit.logабо щось подібне, коли надходить ssh-з'єднання. Перехресне посилання цього журналу з журналом комісій повинно дати вам уявлення про те, якому ssh-користувачеві було використано для видачі комісії. Це етап аудиту, який слід використовувати після факту для перевірки.

Насправді примусити правильного ssh-користувача до відповідного користувача git - це одна з інших відповідей тут.

Якщо всі користувачі мають облікові записи оболонок із доступом до запису до сховища, ви не зможете налаштувати надійний журнал аудиту: вони все ще можуть змінювати сховище, не записуючи в журнал, і вони можуть записувати все, що хочуть у журнал.

Щоб мати можливість довіряти журналу аудиту, вам потрібно буде не допустити прямого доступу на рівні файлу до запису до сховища, замість цього використовувати щось на зразок gitolite (який працює у власному обліковому записі) для посередництва доступу до сховища.