Ключевой аспект в методологии DevSecOps – применение лучших инструментов для обеспечения безопасности вашей среды разработки.
Программное обеспечение важно защитить от злонамеренного и случайного воздействия или изменения. В этой статье вы узнаете, как контролировать и управлять доступом к GitLab.com и к исходному коду, конвейерам сборки, репозиториям зависимостей, ключам развертывания.
Инструкции для защиты кода предоставляются для конечных пользователей на
мультитенантном GitLab.com и написаны для лицензии Ultimate.
Настройки группы
Многие параметры, связанные с безопасностью, могут быть установлены в группе верхнего уровня и будут распространяться на все подгруппы и проекты. Это самые простые и важные элементы для защиты вашего экземпляра GitLab.com.
Общие настройки
В группе верхнего уровня следует применить следующие конфигурации, чтобы обеспечить максимальную безопасность кода внутри этой группы:
Сделайте уровень видимости группы конфиденциальным
Это самая важная настройка. Если вы обозначите группу как «приватную», для всех, кто не входит в нее, будет закрыт доступ. Кроме того, если группа верхнего уровня получит статус «приватная», все подгруппы и проекты также будут конфиденциальными.
Разрешения и функции группы
1. Установите «Запретить участникам отправлять приглашения во внешние группы». Это предотвратит случайное добавление людей, которые не должны состоять в группе.
2. Установите «Запретить делиться проектом с другими группами». Это обезопасит код от утечки, проекты будут доступны только участникам текущей группы.
3. Разрешите создание токенов доступа к проектам и группам. Они во многом похожи на токены личного доступа со следующими улучшениями:
- их можно увидеть, и они управляются владельцами и сопровождающими групп, что означает, что они могут быть отозваны, а сроки их действия устанавливаются администратором.
- они создают виртуального пользователя-бота, который не учитывается в рамках вашей лицензии.
4. Включите отложенное удаление проекта. Это даст вам семидневный льготный период для обнаружения и предотвращения случайного или злонамеренного удаления репозитория. GitLab.com, как и GitLab с самоуправлением, не имеет возможности восстановить отдельный проект без значительных затрат на профессиональные услуги.
5. Внесите в список разрешенных бесклассовую междоменную маршрутизацию (CIDR) или суперсети, из которых пользователи должны получать доступ к коду.
6. Ограничьте пользование только теми доменами электронной почты, которые принадлежат вашей организации и подрядчикам.
7. Предоставьте право на создание подгрупп только владельцам. Это поможет сохранить структуру группы верхнего уровня в ваших политиках и упростит управление синхронизацией групп SAML для участия.
8. Заблокируйте разветвление проектов за пределами текущей иерархии групп. Это поможет предотвратить утечку кода.
9. Установите двухфакторную аутентификацию. Таким образом, отключается возможность использовать идентификацию по паролю в Git через HTTPS.
10. Запретите добавление новых участников в проекты в этой группе. Все участники должны быть закреплены в текущей группе.
Подтверждение мерж-реквестов
Утверждения мерж-реквестов поможет предотвратить внедрение вредоносного кода в репозиторий, поскольку их просматривают другие люди, кроме автора. Включите одобрение мерж-реквестов для всех проектов в вашей группе, чтобы:
- запретить подтверждение со стороны авторов;
- запретить подтверждение пользователями, которые добавляют коммиты;
- запретить редактирование правил одобрения в проектах и отдельных мерж-реквестах.
Система единого входа SAML SSO
Чтобы более жестко контролировать доступ к вашему коду на GitLab.com, настройте единый вход SAML. Это гарантирует, что каждый, кто получит к нему доступ, будет одобрен кем-то из уполномоченных лиц.
Для настройки единого входа SAML:
- включите аутентификацию SAML для этой группы;
- активируйте аутентификацию только с использованием единого входа для веб-активности этой группы;
- включите идентификацию только с помощью SSO для Git и активности прокси-сервера зависимостей для этой группы.
- установите значение «Минимальный доступ» для участников по умолчанию. Роли могут быть расширены по мере необходимости в подгруппах или отдельных проектах, минимальный доступ предотвращает любую видимость, где пользователю не предоставлена другая роль.
- строго контролируйте доступ к ролям Сопровождающего и Владельца, каждому разработчику не обязательно иметь роль Сопровождающего.
Аудит группы и соблюдение требований
Регулярно и периодически просматривайте отчеты о соответствии, чтобы узнать, кто утверждает мерж-реквесты и какие MR получают одобрение.
Настройте потоковую передачу событий аудита в свою систему управления информацией, инцидентами корпоративной безопасности (SIEM) и отслеживайте их на предмет необычной активности. Это необходимо повторить для каждой группы и проекта в иерархии, чтобы получить максимальное количество событий аудита.
Правила push-уведомлений на уровне группы
Установка ограничительных правил push-уведомлений поможет гарантировать, что вредоносный код не будет внедрен в репозиторий:
- потребуйте подтверждения коммиттеров;
- отклоните неподписанные коммиты;
- убедитесь, что автор коммита является пользователем GitLab;
- запретите отправку секретных файлов;
- проверьте, чтобы адрес электронной почты автора коммита находился в вашем почтовом домене.
CI/CD
Следующие настройки могут помочь обеспечить целостность конвейеров CI/CD и уменьшить возможности злоупотреблений и злонамеренных действий:
- регистрация агентов GitLab Runner устанавливается на самом низком уровне, чтобы уменьшить радиус любого злонамеренного использования;
- использование защищенных исполнителей с безопасными переменными и ветвями, чтобы значительно ограничить круг лиц, которые могут выполнять развертывание в рабочих средах или злоупотреблять облачными ресурсами;
- основательный контроль доступа для изменения файла обозначения конвейера gitlab-ci.yml во всех репозиториях через файл CODEOWNERS, это предотвратит злонамеренное использование системы CI/CD.
Настройки проекта
Некоторые параметры не передаются каскадом из группы или недоступны на уровне группы и вместо этого должны устанавливаться в отдельных проектах. К ним относятся настройки, характерные для репозитория.
Репозиторий
Настройте защищенные ветки и теги для работы с Protected Runners и безопасными переменными, определенными выше.
CI/CD
Отключите общедоступные конвейеры. Используйте отдельные кэши для защищенных ветвей.
Безопасная среда
Используйте защищенные среды и ограничьте круг лиц, которые могут развертывать и требовать одобрения для развертывания.
Доступ к токену
Ограничьте доступ к CI_JOB_TOKEN этого проекта только отдельным программам, чтобы вредоносные объекты не могли получить токен и использовать его для доступа к API.
Безопасные файлы
Сохраняйте хранилища ключей, профили подготовки и сертификаты подписи в библиотеке защищенных файлов, а не в репозитории.
Тестирование безопасности и соответствие требованиям на уровне проекта
Конфигурация
Включите статическое тестирование безопасности приложений SAST, чтобы предотвратить внедрение вредоносного кода в приложение.
Запустите сканирование зависимостей и регулярно просматривайте их список, программное обеспечение или спецификацию ПО (SBOM), созданную в результате сканирования зависимостей на наличие уязвимостей и вредоносных компонентов.
Активируйте сканирование контейнеров и образов кластеров.
Политики
В качестве альтернативы приведенному выше разделу тестирования безопасности вы можете включить политики выполнения тестового сканирования. Это нужно, чтобы предотвратить объединение кода с критическими уязвимостями.
Следование этим рекомендациям поможет вам обезопасить код, размещенный на GitLab.com, защитить от несанкционированного доступа и публичного разоблачения. Вы сможете быть уверенными, что цепочка поставок программного обеспечения безопасна и только авторизованные пользователи имеют доступ к вашим программным ресурсам.