Хабрахабр

[Перевод] Защита репозиториев на GitHub от вредоносных коммитов

Mozilla старается защитить свои репозитории на GitHub от вредоносных изменений. Как показал недавний инцидент с Gentoo, такие атаки реальны.

Первоначально Mozilla использовала GitHub как запасной хостинг. Подобно Gentoo, оригинальные репозитории хранились на собственной инфраструктуре. И хотя большая часть кода Firefox по-прежнему распространяется с собственной инфраструктуры, но многие проекты существуют только на GitHub. Некоторые — просто эксперименты, а другие используются в продакшне (например, Firefox Accounts). Такие «чувствительные» репозитории нужно защищать от вредоносных правок, при этом не усложняя коммиты для нормальных людей.
Здесь описаны реальные меры против распространения (или развёртывания) кода из скомпрометированного репозитория. Мы делимся опытом и некоторыми инструментами для аудита. Такая защита почти не мешает нормальным рабочим процессам в GitHub.

Как показал случай Gentoo и другие инциденты, в случае взлома подвергается опасности весь код, к которому есть доступ у пользователя. Мы здесь рассматриваем риск взлома учётной записи GitHub через уникальные механизмы этого сайта.

GitHub — замечательная экосистема с множеством расширений или «приложений» для упрощения определённых рабочих процессов. Приложения получают от пользователя разрешение на выполнение действий от его имени. Они могут запрашивать разрешения, включая изменение или добавление дополнительных учёток. GitHub явно показывает эти запросы: пользователь должен одобрить их через веб-интерфейс, но не все знакомы с последствиями. Многие не понимают, что разрешение на доступ к личному репозиторию даёт такой же доступ к любому репозиторию на GitHub от имени пользователя.

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

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

Рекомендации для организаций

  • Обязательная 2FA для всех сотрудников.
  • Всем или хотя бы пользователям с повышенными разрешениями:
    • Предоставить контакт (электронная почта, IM) организации или админу (GitHub позволяет скрывать контактную информацию для конфиденциальности).
    • Обязательно информировать организацию или админа о возможной компрометации своей учётной записи (например, о краже ноутбука).

Рекомендации для репозиториев

  • Важные репозитории следует размещать только в организации, которая следует приведённым выше рекомендациям.
  • Определить и настроить ветки продакшна:
    • Запрет принудительных пушей.
    • Разрешение на коммиты лишь небольшому числу пользователей.
    • Применять эти ограничения также для админов и владельцев.
    • Подписывать все коммиты заранее известными ключами GPG.

Рекомендации по рабочему процессу

  • Деплои, релизы и другие события, достойные аудита, следует отмечать тегом, подписанным заранее известным ключом GPG.
  • Все деплои и релизы должны выпускаться только после аудита всех подписанных коммитов и тегов на предмет правильных ключей.

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

Сначала получаем локальную копию данных для организации octo_org, а затем составляется отчёт по каждому репозиторию: Вот пример аудита.

$ ./get_branch_protections.py octo_org
2018-07-06 13:52:40,584 INFO: Running as ms_octo_cat
2018-07-06 13:52:40,854 INFO: Gathering branch protection data. (calls remaining 4992).
2018-07-06 13:52:41,117 INFO: Starting on org octo_org. (calls remaining 4992).
2018-07-06 13:52:59,116 INFO: Finished gathering branch protection data (calls remaining 4947).

Теперь с локально кэшированными данными можно генерировать любые отчёты. Например, один отчёт показывает соблюдение вышеперечисленных рекомендаций:

$ ./report_branch_status.py --header octo_org.db.json
name,protected,restricted,enforcement,signed,team_used
octo_org/react-starter,True,False,False,False,False
octo_org/node-starter,False,False,False,False,False

Как видим, что только octo_org/react-starter включил защиту от принудительных пушей на ветке продакшна. Результат выдаётся в формате CSV, чтобы легко вставить в электронную таблицу.
Мы все ещё внедряем у себя эти рекомендации и учимся по ходу. Если считаете, что наши рекомендации по безопасности репозиториев вам подходят, помогите упростить реализацию. Поделитесь опытом на странице советов или откройте тикет в репозитории GitHub-Audit.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»