Подписанные коммиты в GitHub: настройка и защита

Кратко: Подписанные коммиты добавляют криптографическую подпись к каждому коммиту, подтверждая авторство и целостность. Настройка включает создание GPG‑ключа, привязку его к локальному Git и аккаунту GitHub, а также при необходимости — включение требования подписанных коммитов через правила защиты веток.

Быстрые ссылки

• Что такое подписанные коммиты?
• Настройка нового GPG‑ключа
• Принудительное требование подписанных коммитов с помощью защиты веток

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

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

Подписанный коммит — это обычный коммит Git, к которому добавлена цифровая подпись, сформированная приватным криптографическим ключом. На практике чаще всего используют GPG (OpenPGP). Также возможны подписи через SSH или X.509, но здесь описан стандартный GPG‑вариант.

Подпись даёт два основных свойства:

• Проверка целостности: подтверждает, что содержимое коммита не меняли после подписи.
• Подтверждение авторства: показывает, что коммит подписал владелец приватного ключа, которому доверяет аккаунт на GitHub.

Если репозиторий настроен принимать только подписанные коммиты, злоумышленнику придётся получить не только доступ к GitHub‑аккаунту, но и приватный ключ пользователя (обычно — полный доступ к компьютеру). Это делает атаку значительно сложнее.

Важно: подписанные коммиты не защищают от всех векторов атаки. Если приватный ключ украден, или администратор вручную примет неподписанные изменения, подписи не помогут. См. раздел «Когда это не помогает».

Настройка нового GPG‑ключа

Короткий план действий:

1. Сгенерировать GPG‑ключ локально.
2. Экспортировать и добавить публичный ключ в профиль GitHub.
3. Настроить локальный Git на использование ключа и принудительную подпись коммитов.

Требования: установленный пакет gpg (часто уже есть в системе). На Linux используйте менеджер пакетов дистрибутива; на macOS можно установить через Homebrew (gpgtoolset) или GPG Suite.

1. Сгенерируйте ключ:

gpg --full-generate-key

При генерации обычно можно соглашаться с большинством значений по умолчанию. Обязательно задайте надёжную фразу‑пароль и укажите email, связанный с вашим аккаунтом GitHub. Если вы не хотите раскрывать основной email, используйте адрес вида username@users.noreply.github.com.

2. Найдите и экспортируйте публичную часть ключа. Сначала посмотрите список секретных ключей в читаемом формате:

gpg --list-secret-keys --keyid-format LONG

Скопируйте LONG key ID (например ABCDEF1234567890). Затем экспортируйте ASCII‑блок публичного ключа:

gpg --armor --export ABCDEF1234567890

Скопируйте полученный блок (начинается с —–BEGIN PGP PUBLIC KEY BLOCK—–) в буфер обмена.

3. Добавьте публичный ключ в GitHub. В аккаунте откройте «Settings → SSH and GPG keys», затем «New GPG key» и вставьте экспортированный блок. Там можно также включить режим Vigilant, который будет помечать все коммиты, не подписанные добавленными ключами, как «Unverified».

4. Настройте локальный Git. Укажите ID ключа как signingKey (глобально или для конкретного репозитория):

git config --global user.signingkey ABCDEF1234567890

Включите автоматическую подпись всех коммитов:

git config --global commit.gpgsign true

Если не хотите подписывать всегда, можно подписывать отдельно через флаг -S:

git commit -S -m "Ваше сообщение"

Советы по безопасности ключа:

• Храните приватный ключ в зашифрованном виде с сильной фразой‑паролем.
• По возможности используйте аппаратный токен (например, YubiKey) для хранения ключа.
• Не помещайте приватный ключ в облачные хранилища или публичные архивы.

Принудительное требование подписанных коммитов с помощью защиты веток

Правила защиты веток (Branch protection) позволяют требовать определённые условия для веток: обязательные ревью, запрет прямых пушей, и, среди прочего, требование подписанных коммитов.

1. В репозитории перейдите в «Settings → Branches» и добавьте правило для шаблона веток, например * для всех веток.
2. Установите опцию «Require signed commits».

После включения все новые коммиты в соответствующих ветках должны сопровождаться корректной подписью, проверяемой GitHub. Это вынуждает сотрудников иметь настроенные GPG‑ключи и затрудняет незаметные подмены кода.

Когда это не помогает

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

Альтернативные и дополняющие подходы

• Подписи через SSH: альтернатива GPG, поддерживаемая в некоторых рабочих процессах.
• Подписанные теги: используют те же ключи для подписания релизов.
• Жёсткая политика 2FA и управление доступом: снижает шанс компрометации аккаунта.
• CI‑проверки: дополнительно проверяйте подписи в CI и запрещайте merge при несоответствии.

Руководство при компрометации ключа

1. Сразу удалите (revoke) публичный ключ в GitHub и пометьте его как скомпрометированный.
2. Отозвите/аннулируйте ключ локально (gpg –delete-secret-keys / –delete-keys) и опубликуйте список отозванных ключей (revocation certificate).
3. Сгенерируйте новый ключ и добавьте его в GitHub.
4. Проверьте историю коммитов и аудит: ищите подозрительные изменения, неавторизованные слияния или сборки.
5. При необходимости откатите вредоносные коммиты и уведомите команду безопасности.

Критерии приёмки

• На GitHub все последние коммиты помечаются как Verified для разработчиков, которые настроили ключи.
• Правило защиты веток включено и применено к нужным веткам (например, main, release/* или *).
• Все участники команды подтвердили, что у них настроены рабочие ключи и работают сборки/CI.

Чек‑лист по ролям

Разработчик:

• Сгенерировать GPG‑ключ и установить фразу‑пароль.
• Добавить публичный ключ в GitHub.
• Настроить user.signingkey и commit.gpgsign.
• Проверить, что локальные коммиты помечаются как подписанные.

Мейнтейнер/владелец репозитория:

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

Команда безопасности:

• Регулярно проверять логи доступа и события добавления/удаления ключей.
• Обучать сотрудников правилам хранения приватных ключей и использованию аппаратных токенов.

Короткий глоссарий

• GPG: реализация OpenPGP для шифрования и подписей.
• Signing key: приватный и публичный ключ, используемые для подписи коммитов.
• Vigilant mode: режим GitHub, помечающий неподписанные коммиты как непроверенные.
• Branch protection: правила, ограничивающие операции над ветками.

Итог

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

Примечание: при внедрении учитывайте удобство команды: настройте onboarding‑инструкцию и тесты, чтобы переход прошёл гладко.