Где хранятся ключи в GitHub?

Управление ключами в GitHub: хранилище, виды и практика безопасности

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

1. Ключи пользователя: SSH и токены

Для аутентификации и авторизации GitHub использует два основных механизма.

SSH ключи

• Хранилище: Связь SSH ключей с учетной записью пользователя осуществляется через настройки профиля. Публичные ключи хранятся в специальном разделе на сайте GitHub (Settings -> SSH and GPG keys).
• Процесс: Пользователь генерирует пару ключей (приватный и публичный) локально, например, с помощью ssh-keygen. Публичный ключ загружается на GitHub. Приватный ключ никогда не передается GitHub и остается на локальной машине пользователя, обычно в файле ~/.ssh/id_rsa (или аналогичном).

  # Пример генерации SSH ключа
  ssh-keygen -t ed25519 -C "your_email@example.com"
  

• Использование: При операциях git clone, git push через SSH протокол GitHub проверяет соответствие публичного ключа в своей базе и приватного ключа на стороне клиента.

Токены доступа (Access Tokens)

• Хранилище: Токены (Personal Access Tokens, PAT) генерируются в разделе Settings -> Developer settings -> Personal access tokens. Сам токен как строка (например, ghp_xxxxxxxxxxxxxxxxxxxxxxxx) хранится в базе данных GitHub в защищенном виде.
• Практика безопасности: GitHub никогда не показывает полный токен после его создания (отображается лишь его часть для идентификации). Токены используются для HTTPS операций или API запросов и должны храниться у пользователя в безопасном месте (например, в системных переменных, секретах CI/CD).

  # Пример использования токена для HTTPS операции
  git clone https://github.com/user/repo.git
  # В запросе будет использоваться токен как пароль
  

2. Ключи интеграции: Deploy Keys и Secrets

Для автоматизации и интеграции с внешними системами GitHub предоставляет дополнительные механизмы.

Deploy Keys

• Хранилище: Это SSH ключи, которые связаны с конкретным репозиторием, а не с учетной записью пользователя. Они добавляются в настройки репозитория (Settings -> Deploy keys). Публичный ключ хранится там, приватный — на стороне сервера или системы, которой нужен доступ.
• Применение: Часто используются для автоматического деплоя на серверы, где нужен доступ только к одному репозиторию.

GitHub Secrets

• Хранилище: Для GitHub Actions секреты хранятся в зашифрованном виде в базе данных GitHub. Они доступны в настройках репозитория или организации (Settings -> Secrets and variables -> Actions).
• Механизм: GitHub использует шифрование на стороне сервера и обеспечивает доступ к секретам только во время выполнения workflow, через защищенное окружение.

  # Пример использования секрета в GitHub Actions workflow
  jobs:
    build:
      runs-on: ubuntu-latest
      steps:
        - name: Use a secret
          run: echo ${{ secrets.MY_API_TOKEN }}
  

3. Внутренние ключи GitHub

Для обеспечения безопасности собственной инфраструктуры GitHub использует:

• Ключи для шифрования данных: например, для шифрования секретов в Actions, используя стандарты типа AES.
• Ключи для TLS/SSL: для защиты трафика между клиентами и серверами GitHub.
• Системные ключи для внутренних сервисов: которые хранятся в защищенных хранилищах (например, HashiCorp Vault или аналогичных) внутри инфраструктуры GitHub.

Резюме: принципы и рекомендации

• Разделение ответственности: GitHub хранит только публичные части ключей (SSH) или зашифрованные токены/секреты. Приватные ключи всегда остаются у владельца.
• Шифрование: Все данные, которые считаются секретными (токены, secrets), шифруются GitHub на стороне сервера.
• Практика для пользователей:

    * Никогда не загружайте приватные SSH ключи на GitHub.
    * Используйте токены с минимально необходимыми правами (scopes).
    * Регулярно обновляйте и удаляйте неиспользуемые ключи и токены.
    * Для интеграций предпочтительно использовать **Deploy Keys** или **Secrets**, а не личные токены пользователя.

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