Привет, Хабр! Я Антон Ерёмин, ведущий инженер дирекции инфраструктурных проектов Positive Technologies. Сегодня на примере харденинга реальных сервисов продолжаем рассказывать о нашей методологии ХардкорИТ — подходе к определению времени атаки и вероятных маршрутов хакеров.

В прошлый раз мы проводили харденинг инфраструктуры Microsoft Exchange, затрудняя возможность ее атаки, разбирались в тонкостях защиты zVirt. Теперь настало время рассказать про харденинг GitLab.

---

GitLab — это мощная платформа для управления исходным кодом и автоматизации процессов CI/CD, которая используется во многих компаниях по всему миру. Однако с ростом значимости этой платформы возрастает и ее привлекательность для злоумышленников.

Помимо защиты кода, важно предотвратить продвижение атакующего к другим системам.

Чтобы злоумышленник не смог двигаться дальше в инфраструктуре (shift left, privilegy escalation), необходимо дополнительно защитить:

Docker-окружение — запуск кода через GitLab Runner;

кластеры Kubernetes;

системы управления развертыванием — Argo CD, Helm;

Jenkins Gitlab Branch Source Plugin, Docker Swarm, HashiCorp Vault, FreeIPA и Keycloak, через которые атакующий может получить огромные возможности для перемещения по инфраструктуре.

Компрометация любого из этих сервисов может привести к катастрофическим последствиям. Однако в рамках этой статьи я не буду описывать защиту всей экосистемы, а расскажу, как хитро защитить самое ценное, если вы используете GitLab.

Как писал мой коллега о ХардкорИТ: «Если невозможно защититься от всех атак, защищайтесь от тех, что приносят наибольший ущерб. Если нельзя защитить всё, защищайте самое ценное».

Для удобства навигации по статье

Что самое ценное в вашем GitLab

Цели атакующих: зачем взламывают GitLab компаний

Как перехитрить хакера и защитить код

Практический опыт настройки системы для минимизации уязвимостей

Типовые рекомендации по харденингу GitLab

Заберите бонус! Сборник материалов по харденингу GitLab

Что самое ценное в вашем GitLab и почему его нужно защищать

Независимо от размера кластера и количества пользователей платформы, можно выделить ключевые активы, которые необходимо защищать.

Цели атакующих: зачем взламывают GitLab      

Мы не строим догадки — первый шаг в нашем подходе всегда начинается с владельца бизнеса. Именно он определяет, что действительно критически опасно для компании. Для бизнеса важно понимать, какие последствия могут возникнуть в случае атаки и как это повлияет на прибыль, репутацию и стабильность компании. Владельцам не нужно разбираться в технических деталях атак, но они должны осознавать, что уязвимости в IT-инфраструктуре — это не просто ошибки, а реальные угрозы для бизнеса.

Безопасность GitLab должна восприниматься как инвестиция в стабильность компании, а не как лишняя статья расходов. Если не уделять должного внимания защите, можно потерять деньги клиентов.

Рассмотрим, какие угрозы приведут к рискам, связанным с ключевыми ценностями компании, и какие цели могут преследовать злоумышленники при атаке на платформу GitLab.

1. Компрометация репутации

   • Кража внутренней документации, данных клиентов или исходного кода

   • Продажа утекшей информации конкурентам или на рынке преступных киберуслуг

   • Взлом официальных аккаунтов и публикация ложной информации (например, открытие конфиденциальных репозиториев)

   • Атака на конвейер CI/CD с добавлением вредоносного кода в продукт

   • Атака на цепочку поставок, приводящая к заражению клиентов

2. Финансовый ущерб

   • Шантаж, вымогательство, использование программ-шифровальщиков

   • Незаметная подмена конфигурации (например, изменение платежных реквизитов в коде приложения)

   • Кража данных, приводящая к штрафам и судебным искам

3. Воровство инсайдерами

   • Кража исходного кода, клиентских баз и конфиденциальных данных

   • Саботаж — удаление репозиториев, изменение конвейеров CI/CD

   • Внедрение скрытых бэкдоров для долгосрочного доступа

Чтобы защитить GitLab, важно не только устранить уязвимости, но и предотвратить их использование в качестве точки входа для атаки на всю инфраструктуру. Звучит невероятно сложно, но нужно перехитрить хакера.

Как перехитрить хакера и защитить код

Любой, кто работал с GitLab, видел логотип платформы. Это зверь, похожий на енотовидную собаку, — GitLab Tanuki. Этот символ олицетворяет ум, находчивость и командную работу — ключевые принципы, лежащие в основе платформы.

GitLab помогает разработчикам эффективно управлять кодом, сотрудничать в команде и адаптироваться к изменяющимся условиям. Современные хакеры применяют сложные методы атак и скрывают следы. Чтобы противостоять им, организациям нужно действовать столь же продуманно и адаптивно, как лисы: анализировать поведение атакующих, упреждать угрозы и выстраивать защиту на несколько шагов вперед. Именно такой подход предлагает наша методология ХардкорИТ.

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

 Хардениг в основном считается проактивной техникой, его цель — устранить потенциальные уязвимости до того, как злоумышленники смогут их использовать. Тем не менее на практике отрасли могут применять харденинг и в реактивном контексте. Например, после атаки или выявления новых угроз коллеги могут запустить автоматизацию по внедрению харденинга для немедленного устранения обнаруженных слабых мест и предотвращения повторных инцидентов.

Основной упор в харденинге делается на профилактику, но его методы могут эффективно использоваться и в реактивном режиме для оперативного укрепления защиты систем после атаки. Поэтому мои рекомендации будут разделены на проактивные и реактивные. Первые — для тех, у кого есть время, вторые — для тех, кому надо было выстроить защиту еще вчера.

Практический опыт настройки системы для минимизации уязвимостей

Чаще всего уязвимости возникают из-за ошибок в конфигурации, недостаточной проверки данных, неактуальных зависимостей и неправильно настроенных прав доступа. Известные уязвимости возможно закрыть с помощью обновлений GitLab, которые выпускаются в патч-релизах двух видов: запланированных и срочных. Запланированные патчи выходят дважды в месяц по второй и четвертой средам, а срочные — при возникновении серьезных угроз.

 Что же касается малоизвестных уязвимостей, то здесь не обойтись без постоянного мониторинга, применения обновлений и внедрения рекомендаций по харденингу для минимизации рисков, но следует выполнять эти действия максимально рационально, чтобы не сломать CICD.

 Я надеюсь, что у вас установлена версия GitLab не ниже 17-й (актуальная на момент написания статьи) и включена двухфакторная аутентификация (2FA) — сегодня любая рекомендация в блоге GitLab начинается с этих слов. Помимо того, к этой рекомендации добавилось требование ФСТЭК — установка обновлений из доверенных источников только после оценки всех сопутствующих рисков. Другие типовые рекомендации мы разберем в следующей главе, а пока давайте выполним хардениг, отталкиваясь от самых популярных уязвимостей за 2024 год.

Далее я предлагаю вам ознакомиться с самыми опасными, на мой взгляд, уязвимостями для GitLab и изучить рекомендации, разделенные на две категории:

1. Проактивные — для тех, кто может позволить себе, узнав про уязвимость в инфраструктуре компании, закрывать ее в течение долгого времени, но зато правильно, надежно и без рисков нарушения бизнес-процессов. Часто к проактивным относятся рекомендации, которые исходят от разработчиков платформы GitLab.

2. Реактивные — для тех, кому важно «прикрыть уязвимость» хитрым способом, как можно скорее и только потом приступать к проактивным решениям.

CVE-2023-7028 (ФСТЭК: BDU:2024-00259)

Что позволяет сделать уязвимость

Уязвимость дает возможность захватить любую учетную запись при помощи функции восстановления пароля.

Ошибка в функции сброса пароля позволяет злоумышленнику указать два адреса электронной почты во время запроса на сброс пароля. Код сброса будет получен на оба адреса электронной почты, злоумышленник может запросить код для сброса пароля и отправить его на заранее подготовленный неподтвержденный адрес электронной почты.

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

Уязвимость актуальна для GitLab версий 16.1.0–16.7.1, в которых есть возможность отправки кода восстановления пароля на неверифицированный запасной адрес электронной почты.

Реактивные меры

1. В первую очередь включите 2FA для учетных записей с привилегированным доступом, то есть для УЗ администраторов, тимлидов с правами на push в master и других аккаунтов, имеющих доступ к ключевых репозиториям.

   Стоит отметить, что риск эксплуатации уязвимости при использовании двухфакторной аутентификации сохраняется, но значительно минимизируется.

2. Исключите возможность собирать информацию о пользователях, зарегистрированных в GitLab. Важно не дать хакеру успеть собрать базу программистов, в частности он не должен получить электронный адрес пользователей для выполнения атаки. Для этого нужно выполнить запрос вида:

   gitlab.company.local/api/v4/users/{id}

   Как это работает

   Без необходимости аутентификации можно использовать API-метод для получения информации о зарегистрированных пользователях. Для этого необходимо выполнить запроса вида:

   gitlab.company.local/api/v4/users/{id}

   Можно получить данные о пользователе, включая его логин, электронный адрес и другую полезную информацию. Перебирая идентификаторы пользователей, злоумышленник может быстро собрать список разработчиков. Особенно интересен параметр avatar_url, который содержит электронный адрес, но зашифрован в MD5 в нижнем регистре.

   Тем не менее в случае правильной конфигурации вашей платформы GitLab при попытке обращения с запросом gitlab.company.local/api/v4/users/{id} система должна ответить сообщением:

   403 Forbidden – Not authorized

   Сообщение свидетельствует о том, что доступ к этим данным ограничен. Теперь выполните тот же запрос с правильным токеном или с действительными учетными данными. Пример с использованием персонального токена:

   curl --header "PRIVATE-TOKEN: <your_personal_access_token>" https://gitlab.company.local/api/v4/users/{id}

   Это должно вернуть данные о пользователях в ответе.

3. Проверьте журналы на наличие признаков компрометации.

   Как это работает

    Обратите внимание на файл gitlab-rails/production_json.log. В нем могут быть зафиксированы HTTP-запросы к обработчику /users/password, где в параметре params.value.email указан массив из нескольких электронных адресов.

   Также анализируйте журнал:

   gitlab-rails/audit_json.log

   Ищите записи с указанием PasswordsController#create в поле meta.caller.id, а также массив с несколькими электронными адресами в блоке target_details. Они могут свидетельствовать о попытках массового сброса паролей.

4. Ограничьте возможность отправки писем для сброса паролей через почтовый сервер, так вы уменьшаете риски, связанные с манипуляциями функцией восстановления пароля.

5. Вы можете ограничить доступ к сбросу пароля, настроив политику видимости для вашей платформы GitLab. Это не отключает саму функцию, но может уменьшить риски для незарегистрированных пользователей.

   Как это работает

   Перейдите в Admin → Settings → General → Sign-in restrictions. Установите политику, которая будет ограничивать возможность восстановления пароля только для зарегистрированных пользователей или пользователей с определенными правами доступа.

Проактивные меры

1. Включите двухфакторную аутентификацию для всех учетных записей на платформе GitLab. Это поможет значительно повысить уровень защиты ваших пользователей.

2. Проверьте журналы GitLab с помощью SIEM-решения. Если у вас есть решение SIEM, которое захватывает веб-журналы, можно настроить предупреждения или использовать запросы для поиска возможных попыток эксплуатации уязвимости.

   Вот несколько действий, которые помогут в обнаружении подозрительной активности:

   • Проверка веб-журналов. Нужно искать API-запросы к эндпойнту /users/password, в которых указано несколько электронных адресов. Это может свидетельствовать о попытке массового сброса паролей.

   • Анализ журналов почтового сервера. Внимательно просмотрите журналы почтового сервера на предмет сообщений от GitLab с подозрительными получателями (здесь индивидуальная история — для каждой компании своя). Это может указывать на манипуляции с процессом восстановления паролей.

   • Проверка журналов аудита GitLab. Необходимо исследовать журналы аудита GitLab, чтобы найти записи с меткой meta.caller.id, содержащие значение PasswordsController#create. Такие записи могут сигнализировать о подозрительных попытках вмешательства в процесс сброса паролей.

   Эти действия помогут своевременно обнаружить признаки эксплуатации уязвимости и минимизировать возможный ущерб.

3. Обновите GitLab до исправленной и протестированной вами версии. Вы же не отключали GitLab Alerts?

   

4. Удостоверьтесь, что типовые рекомендации выполнены (см. следующий раздел).

CVE-2024-6385 (ФСТЭК: BDU:2024-05179)

Что позволяет сделать уязвимость

CVE-2024-6385 — критически опасная уязвимость, затрагивающая версии GitLab CE, EE с 15.8 до 17.1.2, с оценкой CVSS 9,6. Эта уязвимость позволяет злоумышленникам запускать задачи в конвейере CI/CD от имени любого пользователя, что потенциально угрожает безопасности конфиденциальных данных и систем. Однако важно отметить, что для эксплуатации уязвимости злоумышленник должен сначала получить доступ к GitLab, что делает ее менее опасной, если ваша платформа защищена от несанкционированных входов.

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

Подробности об этой уязвимости можно найти в Issue GitLab CVE-2024-6385, где представлен Proof of Concept (PoC) и видеодемонстрация эксплуатации. GitLab уже выпустил обновления, устраняющие эту проблему, и настоятельно рекомендуется обновить систему до последних версий, чтобы минимизировать риски. Кроме того, существует похожая уязвимость CVE-2024-5655, которая требует внимания, поскольку ее эксплойт также может привести к нарушениям в безопасности процессов CI/CD.

Реактивные меры

1. Проверьте существующие конвейеры CI/CD на предмет любых несанкционированных изменений или подозрительных действий.

2. Используйте управление доступом на основе ролей (RBAC), чтобы ограничить права выполнения конвейера только доверенными пользователями.

Проактивные меры

1. Обновите GitLab до последних версий (16.11.6, 17.0.4 или 17.1.2), в которых уязвимость исправлена.

2. Проверьте журналы GitLab с помощью SIEM-решения. Если у вас есть решение SIEM, которое захватывает веб-журналы, можно настроить предупреждения или использовать запросы для поиска возможных попыток эксплуатации уязвимости.

Проверяйте журналы аудита на предмет записей, где в поле meta.caller.id указано значение Ci::CreatePipelineService, а инициатором является пользователь, не имеющий прав на запуск пайплайна от имени другого пользователя.

Эти шаги помогут своевременно обнаружить признаки эксплуатации уязвимости и минимизировать возможный ущерб.

Типовые рекомендации по харденингу GitLab

Продолжаем следовать нашей методологии Хардкор ИТ и харденить. Давайте кратко вспомним, что мы успели выполнить:

1. Пообщались с владельцем бизнеса и выяснили, какие события являются недопустимыми для компании.

   Недопустимые события в контексте безопасности GitLab CI/CD — это потенциальные инциденты или нарушения, которые могут привести к утечке данных, компрометации системы или срыву процессов разработки.

2. Провели аудит и выяснили, что надо харденить GitLab.

3. Определили TTA (time to attack) для GitLab-кластера.

   На первом этапе определения TTA проанализировали GitLab-кластер и его подключенные компоненты (например, nginx, PostgreSQL) на наличие уязвимостей, ошибок в конфигурации. На втором этапе необходимо исследовать, с каких точек злоумышленник может получить доступ к кластеру и коду. На третьем этапе рассчитывается, сколько времени потребуется злоумышленнику, чтобы выполнить атаку, например проникнуть в GitLab и выполнить команду через CI/CD. Расчет выполняется на стороне нашей компании с использованием автоматических средств и сложных математических формул.

После того как мы определили TTA для каждой уязвимой точки, можно принять меры для замедления атак. Рассмотрим несколько примеров, которых будет достаточно в рамках типовых рекомендаций.

Исходный код и конфиденциальные данные

Пользователям GitLab удобно хранить пароли, API-токены и ключи аутентификации прямо в коде, поскольку это позволяет быстро использовать учетные данные в процессе работы, но на практике такие секреты — это первое, что будет искать хакер, получив доступ к репозиториям.

Реактивные меры

1. Удаление секретов из истории коммитов. Если чувствительные данные попали в историю репозитория, используйте GitLab’s built-in tools для очистки истории. Инструменты вроде BFG Repo-Cleaner или git filter-branch помогут вам удалить секреты из всех прошлых коммитов.

2. Удаление истории выполнения CICD. В случае утечки конфиденциальных данных через CI/CD важно удалить историю выполнения сборок. В GitLab можно настроить автоматическое удаление старых пайплайнов в разделе Settings → CI/CD → Auto DevOps или ограничить доступ к журналам выполнения с помощью контроля прав доступа. Также стоит следить за тем, чтобы чувствительная информация не попадала в артефакты сборок.

3. Проверка журналов активности. Важно тщательно проверить журналы активности. Это позволит вам понять, кто и как нарушал политику доступа, и принять меры для улучшения безопасности. GitLab-инструмент: просмотр Audit Logs для анализа действий, связанных с правами доступа и изменениями в проектах.

Проактивные меры

1. Управление секретами. Не храните пароли, токены, ключи и другие секреты в открытом виде. Используйте HashiCorp Vault или другие инструменты для безопасного хранения секретов. GitLab интегрируется с Vault, что позволяет безопасно передавать секреты в процессе CI/CD.

2. Ограничение доступа к репозиториям. Переведите видимость проектов, фрагментов и групп в GitLab в режим Private по умолчанию, чтобы предотвратить случайное или злонамеренное раскрытие информации. Только пользователи, которым предоставлен доступ, могут обращаться к этим ресурсам. Более того, если сделать группу top-level group private, то все включенные в нее группы будут наследовать права доступа.

3. Автоматизированный аудит зависимостей. Убедитесь, что в проекте используются инструменты для автоматической проверки зависимостей на уязвимости. Это поможет вам оперативно обнаруживать и устранять недостатки, связанные с использованием небезопасных библиотек или пакетов. GitLab-инструмент: использование встроенных инструментов для анализа уязвимостей, таких как Dependency Scanning и SAST (static application security testing), для анализа зависимостей на наличие известных уязвимостей.

4. Ограничение доступа к раннерам. Разрешите запуск пайплайнов только для доверенных пользователей. Настройте isolated runners для каждого проекта, чтобы минимизировать риски, связанные с использованием общих runners. Используйте теги и правила only/except для ограничения доступа к определенным задачам.

5. Защита файлов .gitlab-ci.yml. Ограничьте возможность редактирования конфигурации CI/CD для неопытных пользователей. Установите code review процесса перед внесением изменений в конвейер. Используйте rules: в .gitlab-ci.yml, чтобы предотвратить запуск неизвестных или неавторизованных кодов из внешних репозиториев (например, форков).

Файл .gitignore

Файл конфигурации .gitignore информирует Git о файлах, которые следует или не следует включать, когда разработчик фиксирует код в репозитории. При использовании стратегии включения коммита .gitignore только указанные файлы будут переданы в репозиторий. Это помогает предотвратить случайное раскрытие секретов из-за отсутствия обслуживания .gitignore.

Особого внимания заслуживает .git/config. Публично доступный каталог Git может позволить злоумышленникам клонировать репозиторий. Затем они смогут сканировать его на предмет секретов в коде или в исторических записях.                                          

Вы должны убедиться, что каталог .git и его подкаталоги (особенно .git/config) не являются общедоступными (в какой-либо форме) и что все взаимодействие с репозиторием осуществляется через защищенный HTTP (HTTPS).

Неподписанные коммиты

Git позволяет легко идентифицировать автора коммита, но если этот коммит не подписан криптографическим ключом GPG, то доверять ему нельзя. Без проверки подлинности злоумышленник может подделать коммиты и выдать их за работу другого разработчика.

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

После подписи коммитов кода рядом с записью журнала коммитов появляется значок verified. Это гарантирует, что каждый участник проекта знает, что код был обновлен автором, который не только прошел авторизацию, но и владеет ключом для подписи коммита, гарантирует, что код не был каким-либо образом подделан.

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

Git позволяет легко идентифицировать автора коммита, но если этот коммит не подписан криптографическим ключом GPG, то доверять ему нельзя. Без проверки подлинности злоумышленник может подделать коммиты и выдать их за работу другого разработчика.

Как сделать харденинг частью бизнес-процессов

Безопасность GitLab — это не просто набор технических параметров, а комплексный процесс, который требует взаимодействия между IT-командой (владельцами системы) и отделом ИБ (CISO и их командой). Без тесного взаимодействия между этими подразделениями сложно добиться эффективной защиты. IT отвечает за работоспособность системы, а ИБ — за минимизацию рисков, связанных с уязвимостями и атаками. Только совместная работа обеспечит сбалансированный подход, при котором безопасность не станет препятствием для продуктивности.

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

• принимать решения об улучшении защищенности своей системы;

• управлять возможным сопротивлением команды, которая может быть не готова к изменениям из-за потенциальных неудобств;

• оценивать влияние мер безопасности на SLA (время отклика, стабильность работы);

• контролировать процесс внесения изменений через запросы на изменение (ЗНИ), тестирование в различных конфигурациях перед развертыванием в продакшене.

Без четких целей, понимания рисков и планирования харденинг превратится в хаотичный процесс, вызывающий недовольство команд и потенциально замедляющий разработку. Обеспечение безопасности не должно быть отдельным процессом, который выполняется по остаточному принципу. Оно должно стать частью всей экосистемы управления IT. Для этого харденинг должен быть интегрирован в ключевые процессы:

• Запросы на изменения (ЗНИ) — каждый новый патч или изменение конфигурации должно оцениваться с точки зрения безопасности.

• Управление конфигурациями — параметры безопасности должны быть строго документированы и применяться по стандарту.

• Управление активами — необходимо точно знать, какие сервисы, серверы и компоненты используются, чтобы своевременно устранять уязвимости.

• Обновление и устранение уязвимостей — автоматизация обновлений GitLab, runners и зависимостей минимизирует риск эксплуатации уязвимостей.

Хотя многие из этих процессов традиционно относятся к сфере ИБ, в небольших компаниях внедрение часто ложится на владельца системы.

Харденинг GitLab — это не разовая настройка, а постоянный процесс. Он требует осознанного подхода, четкого распределения ролей, взаимодействия между IT и ИБ, а также интеграции мер безопасности в существующие бизнес-процессы. Только так можно обеспечить эффективную защиту без ущерба для работы команд.

В качестве бонуса предлагаю вам список материалов, который помог мне собрать эту статью.

Бонус: сборник ссылок по харденингу GitLab

Компания GitLab создала огромное количество материалов о безопасности своей платформы. В моей практике харденинг GitLab — это прежде всего проактивные шаги по правильной настройке и конфигурации системы. Регулярное обновление, настройка 2FA, ограничение доступа, шифрование трафика и принцип наименьших привилегий — это эффективные меры, которые помогают снизить риск успешной атаки. Правда без реактивных мер не обойтись: они важны для восстановления после инцидентов, оперативного устранения последствий атаки и патч-менеджмента. Реактивные меры не уменьшают количества существующих уязвимостей системы, но решают часть проблем, появившихся внезапно.

Проактивные меры: настраиваем защиту до инцидентов

GitLab Hardening

•  Hardening — General Concepts

• Security at GitLab | The GitLab Handbook

• Security — Hardening Your GitLab Instance

GitLab CIS Benchmark

• GitLab introduces new CIS Benchmark for improved security

• CIS GitLab Benchmark Scanner — Compliance Engineering

GitLab Security Blog

• Security — GitLab Blog Categories

• How to harden your self-managed GitLab instance

• How GitLab supports NSA and CISA CI/CD security guidance

• GitLab instance: security best practices

• New CIS GitLab Benchmark scanner boosts security and compliance

• Best practices to keep secrets out of GitLab repositories

GitLab Security Docs

• Secure GitLab

• Administer users | GitLab

 GitLab Reports

• hackerone-reports/tops_by_program/TOPGITLAB.md at master

GitLab Architecture

• Security Architecture | The GitLab Handbook

• Production Architecture | The GitLab Handbook

• Architecture Design Workflow | The GitLab Handbook

• Architecture Design Documents | The GitLab Handbook

• GitLab architecture overview

• GitLab Architecture 101 for Support Engineers (видео YouTube)

• Package defaults | GitLab

• Logs on Linux package installations | GitLab

• Advanced configuration | GitLab

Реактивные меры: что делать после инцидента

GitLab Configure

• Configure GitLab

• Configure GitLab Runner

• GitLab Workhorse

• Configure Gitaly | GitLab

• Configure the bundled Puma instance of the GitLab package

 GitLab Application Security

• Application Security | The GitLab Handbook

 GitLab Backup, Restore & Migrate

• Back up and restore overview | GitLab

• Troubleshooting GitLab backups

 GitLab Troubleshooting

• Troubleshooting a GitLab installation

• https://docs.gitlab.com/ee/security/reset_user_password.html?tab=Self-compiled+%28source%29

• Setting custom environment variables | GitLab

• Troubleshooting | GitLab

• Merge request troubleshooting | GitLab

• Troubleshooting LDAP | GitLab

• Troubleshooting SSL | GitLab

• Troubleshooting two-factor authentication | GitLab

• Troubleshooting GitLab with Kerberos integration

• Troubleshooting Redis | GitLab

• Troubleshooting Sidekiq | GitLab

• Troubleshooting Gitaly | GitLab

• Troubleshooting Gitaly Cluster | GitLab

• Troubleshooting PostgreSQL replication and failover for Linux package installations | GitLab

• Troubleshooting Git | GitLab

• Troubleshooting GitLab Runner

• Troubleshooting the GitLab container registry

• Troubleshooting the container registry | GitLab

• Authenticate with the container registry | GitLab

• REST API troubleshooting | GitLab

---

Спасибо, что прочитали статью. Буду благодарен за комментарии и . Тему гитлаба планирую продолжить в следующих статьях. Харденинга много не бывает, так что — не прощаюсь :)

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