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