Многие компании выбирающие для себя средства хранения кода и "комбайны" организации процессов CI/CD останавливают свой выбор на Gitlab. С точки зрения небольших и больших организаций, функционала Gitlab вполне хватает, чтоб решать повседневные задачи разработки. Продукт хорошо документирован, имеет платные подписки с расширением функционала (множество доменов для аутентификации, полнотекстный поиск, системные хуки и прочее). Как показала практика использования продукта, основные проблемы начинаются при попытке кастомизировать или расширить внутренний функционал системы. В нашем случае в качестве расширения функционала рассматривается улучшение уровня аудита по работе с репозиториями в части соответствия требованиям ЦБ и ГОСТ Р 56939-2016. В рамкам реализации требований по разработке безопасного программного обеспечения, необходимо обеспечить контроль за программными продуктами и средами используемыми в процессе создания кода. Возникает закономерный вопрос "А зачем?" Рассмотрим простой вариант многопользовательской разработки программных продуктов в рамках организации. В постковидный период многие компании по прежнему придерживаются идеологии и удобства удалённой работы. И здесь как правило возникает несколько проблем: Организация должна обеспечить безопасное подключение пользователя к контуру разработки. Тут понятное дело настройка централизованного VPN/RDP/etc с политиками доступа. Организация должна обеспечить сотрудника удалённым рабочим местом с необходимым набором программных продуктов, необходимых для работы сотрудника. Здесь у нас покупка лицензий на софт, возможно высокие требования к рабочему месту, поддержка рабочих мест инженерами и т.д. Организация должна обеспечить комплекс мер направленных на обеспечение безопасности кода (закладки, порча кода, некачественный код). Комплексно: антивирусы, code review, SAST, DAST и т.д. Организация должна обеспечить контроль за возможной утечкой кода. Здесь DPI, расширенный аудит в системах и т.д. Из этого списка формируется новый комплекс вопросов: Формировать инфраструктуру для удалённой разработки(VDI/RemotePC) или предоставлять доступ к контуру разработки(репозиторию) с удалённой машины пользователя. Первая часть может быть неприятной с точки зрения бюджета, вторая потенциально небезопасной. Контроль/аудит работы пользователя при работе с кодом. Должны быть механизмы для контроля. Контроль использования ключей безопасности(ssh, пароли) при работе с репозиториями. Должны быть механизмы для контроля. Основной вопрос в том, что мало кто смотрит "кто" читает репы и откуда. Контроль процессов CI/CD и ограничение возможного влияния пользователя на эти процессы. Здесь планомерная работа по изоляции сборочных систем от внешних факторов, реп, возможности влияния на процессы сборки и деплоя. Гипотетическая ситуация. Организация «Н» использует для производства своего программного кода набор сервисов «смотрящих» напрямую в интернет, рассчитывая на безопасность сервисов. Всё это администрируется администраторами, всё вроде как безопасно, пишутся журналы работы и прочая. В определённый момент времени пользователи продукта понимают, что логика работы отличается от требуемой и творится что‑то непонятное. Начинается поиск изменений приведших к указанной проблеме и в конечном итоге находится коммит, в котором зафиксированы данные изменения. Коммит сделан «Васей Пупкиным» пару месяцев назад. При этом «Вася» всячески открещивается от сделанных изменений, ведь он был в Тае в отпуске, но с рабочим ноутом. Но коммит же сформирован под его именем ?Что произошло ?Кто изменил код ?Откуда пришли изменения ?Произошла ли утечка кредов, ключей, сертификатов ?Может быть malware в IDE ?Случилось бы это, если пользователь был бы в локальной сети с локальными копиями репозиториев ?Как найти "концы" ? В случае с удалёнными машинами нет никакой возможности проконтролировать, что происходило на машине в этот момент. С каким программным обеспечением работал сотрудник. Что было запущено на машине и т.д. Всё что необходимо для поиска проблемы должно быть в доступных логах, но не всегда там присутствует.  Все кто работал с Gitlab, скорее всего встречались с его подсистемой журналов https://docs.gitlab.com/ee/administration/logs/. Журналы существуют в виде json и plaintext log файлов, содержащих различные данные о происходящих событиях. В рамках решения наших задач, нас интересуют события связанные с активностью пользователя в репозиториях в рамках Gitlab: WEB — подсистема пользовательского интерфейса(UI) сайта Gitlab, доступного через браузер HTTP — подсистема интерфейса взаимодействия пользователя с Git репозиториями через http/https протоколы SSH — подсистема интерфейса взаимодействия пользователя с Git репозиториями по протоколу SSH В чём особенность? При работе пользователя с различными подсистемами, очень сильно отличается механизм взаимодействия внутренних компонент. Основным интерфейсным компонентом ядра является gitaly, он обеспечивает работу с репозиториями по внутренним grpc интерфейсам взаимодействия. Все компоненты, которые «видит» пользователь по сути являются прокси‑компонентами для работы с gitaly. И поэтому в зависимости от того, как написан прокси‑компонент для gitaly, в процессе взаимодействия gitaly получает или не получает ключевые данные, которые нам нужны. Аудит действий пользователя подразумевает журналирование действий при интерактивном взаимодействии пользователя с web интерфейсом сервера Gitlab или прямые вызовы API(если они разрешены). Так например окно активности пользователей в /admin/audit_logs, формируется только из данных веб интерфейса пользователя. Всё что мы видим в профиле пользователя тоже относится только к веб интерфейсу. Как показали исследования, "gitlab-shell" не передаёт в сторону Gitaly IP адрес пользователя работающего с репозиторием и не журналирует такие данные, как текст коммита. В свою очередь web интерфейс gitlab не журналирует IP адрес пользователя при операциях связанных с помещением действий во внутреннюю очередь. Например при работах с merge_request в части слияния веток. Это приводит к тому, что в логах коммит или mr есть, но адрес пользователя либо пустой, либо 127.0.0.1. Часть читателей наверное скажет: "Есть же correlation_id, используй его!"Да. Он есть, но его значение действительно для одной конкретной операции в рамках сессии взаимодействия. Ниже находятся разные виды "связок" механизмов в рамках операции коммита объединённые по correlation_id.    Как видно из логов, состоящих максимум из 14 строк на одну операцию, внутри находится огромное количество служебной информации, довольно сильно затрудняющей поиск данных. По своей сути прекрасно придуманный механизм корреляции оказался довольно бестолковым, т.к. по нему нельзя восстановить полную хронологию событий. После пары итераций по оптимизации механизмов поиска «вручную», было принято решение сделать универсальный механизм и пересобрать все получаемые структуры в единый формат и отправить во внутреннюю поисковую систему. В качестве механизма для сбора логов и замены структур данных был выбран наиболее мощный, популярный и доступный продукт https://www.elastic.co/beats/filebeat Путём поиска в журналах gitlab нужной информации, было выяснено, что 99% нужных действий находятся в 4х файлах. Сразу оговорюсь, что мы не рассматриваем в этой статье события аутентификации, блокировки пользователя по rate-limit и прочие. Все шаблоны и файлы по статье находятся в репозитории указанном в конце. Итак файлы с данными: /var/log/gitlab/gitlab-rails/api_json.log /var/log/gitlab/gitaly/current /var/log/gitlab/gitlab-shell/gitlab-shell.log /var/log/gitlab/gitlab-rails/production_json.log Исправляемые структуры во всех журналах +- похожи, поэтому остановимся на общих принципах и мелких особенностях каждого из журналов. Все исправляемые структуры представлены в формате JSON, поэтому первым делом нам необходимо распаковать данные для того, чтобы filebeat мог ими оперировать. Убираем лишние строки содержащие 'allowed', включаем парсер для данных и перемещаем данные в корень нового объекта. Преобразование данных для api_json: декодируем сообщение удаляем часть служебных полей связанных метриками запроса удаляем все события содержащие данные от ранеров удаляем все события не содержащие интересующие нас методы "post_receive" и "merge_request/approve" добавляем метаданные, формируем ветку в рамках которой будут данные об операции в логе api_json и production_json, часть операций содержит опциональную ветку "params", в которой в виде массива [ { "key": "xxx", "value": "yyy"},  { "key": "xxx", "value": "yyy"}] находятся параметры операции. filebeat имеет встроенный интерпретатор языка ECMAScript 5.1 https://www.elastic.co/guide/en/beats/filebeat/current/processor-script.html, на котором можно писать код. При помощи небольшой функции переформатируем данные в формат key:value, но с правильными названиями полей и их значениями. перемещаем необходимые поля в новую структуру копируем и переименовываем существующие поля в нашу целевую структуру повторно удаляем остатки данных добавляем тэг "gitlab"  Обработка коммита в api_json Исходные данные Итоговые данные   Обработка коммита в gitaly   Обработка коммита в gitlab-shell    Обработка коммита в production_json   В конечном итоге всё это превращается в следующую картинку На эти вопросы отвечает раздел 5.3.3.1 https://allgosts.ru/35/020/gost_r_56939-2016.pdf 5.3.3.1 Разработчик ПО должен идентифицировать каждое инструментальное средство, используемое при разработке ПО, и определить его настройки(опции). применяемые при создании программы. При разработке ПО должны применять только идентифицированные инструментальные средства. Разработчику ПО следует использовать последние доступные версии инструментальных средств и их возможности по проверке создаваемой программы на наличие проблем, имеющих отношение к разработке безопасного ПО. Для организации работ, выполняемых в процессах жизненного цикла ПО. и подтверждения соответствия требованиям настоящего стандарта документация разработчика ПО для каждого идентифицированного инструментального средства должна содержать: — наименование и идентификационные признаки инструментального средства;— наименование разработчика инструментального средства;— ссылку на эксплуатационные документы инструментального средства;— значения применяемых при создании программы опций(настроек) инструментального средства. Примечание — К инструментальным средствам относятся, например, трансляторы, компиляторы, прикладные программы, используемые для проектирования и документирования, редакторы исходного кода программ, отладчики, интегрированные среды разработки. В рамках исполнения указанных требований, разработчик ПО должен иметь срез версий инструментальных средств разработки на момент изменения программного кода(коммита), который предоставляется аудиторам. Поэтому без наличия IP адреса и данных о пользователе, врядли получится идентифицировать машину и софт на ней установленный. Как и чем собирать информацию о софте на машине разработчика каждый решает сам, благо вариантов много: KSC AIDA64 Everest и прочие Поставить системный хук на PUSH/MR, который получит первичные данные о коммите, запросит лог из Gitlab и сходит в inventory больших проблем я думаю не составит. Кстати о системных и локальных хуках. К сожалению Gitlab при обработке события не передаёт наружу IP адрес пользователя сделавшего изменения, поэтому хуки можно использовать только как триггер по инициации процесса. Да, описываемое здесь решение не позволяет решить все проблемы связанные с идентификацией сотрудника и софта в различные моменты времени, т.к. всегда найдётся множество причин способных помешать процессу. Но описываемое решение помогает систематизировать данные для поиска и очень сильно снизить нагрузку на ручной поиск источников возможных проблем + автоматизировать часть механизмов по формированию материалов необходимых для аудиторов. https://github.com/aborche/gitlab-repo-activity-audit Всем безопасной разработки! :) PS: обложка поста от Kandinsky 2.2  IT волшебник