Выбор подходящего метода проверки подлинности
Вы должны выбрать метод проверки подлинности, подходящий для задачи, которую вы хотите выполнить.
- Чтобы использовать API для личного использования, можно создать personal access token.
- Чтобы использовать API от имени организации или другого пользователя, необходимо создать GitHub App.
- Чтобы использовать API в рабочем процессе GitHub Actions, необходимо выполнить проверку подлинности со встроенной
GITHUB_TOKENверсией.
Дополнительные сведения см. в разделе Сведения о проверке подлинности в GitHub.
Ограничение разрешений учетных данных
При создании personal access tokenвыберите только необходимые минимальные разрешения или области и задайте дату окончания срока действия для минимального количества времени, необходимого для использования маркера. GitHub рекомендует использовать fine-grained personal access tokens вместо personal access tokens (classic). Дополнительные сведения см. в разделе Управление личными маркерами доступа.
При создании GitHub Appвыберите минимальные разрешения, необходимые GitHub App . Дополнительные сведения см. в разделе Рекомендации по созданию приложения GitHub.
При проверке подлинности в GITHUB_TOKEN рабочем процессе GitHub Actions укажите только минимальное количество необходимых разрешений. Дополнительные сведения см. в разделе Автоматическая проверка подлинности токенов.
Безопасное хранение учетных данных проверки подлинности
Обработайте учетные данные проверки подлинности так же, как и пароли или другие конфиденциальные учетные данные.
- Не делитесь учетными данными проверки подлинности с помощью незашифрованной системы обмена сообщениями или электронной почты.
- Не передайте данные personal access token в виде обычного текста в командной строке. Дополнительные сведения см. в разделе Управление личными маркерами доступа.
- Не следует отправлять незашифрованные учетные данные проверки подлинности, такие как маркеры или ключи в любой репозиторий, даже если репозиторий является закрытым. Вместо этого рекомендуется использовать секрет GitHub Actions секрет или секрет Codespaces. Дополнительные сведения см. в разделе "AUTOTITLE" и AUTOTITLE.
- Вы можете использовать сканирование секретов для обнаружения маркеров, закрытых ключей и других секретов, которые были отправлены в репозиторий, или блокировать будущие отправки, содержащие секреты. Дополнительные сведения см. в разделе Сведения о проверке секретов.
Ограничение доступа к учетным данным проверки подлинности
Не делитесь своими данными personal access token с другими пользователями. Вместо совместного использования personal access tokenрассмотрите возможность создания GitHub App. Дополнительные сведения см. в разделе Создание приложений GitHub.
Если вам нужно поделиться учетными данными с командой, сохраните учетные данные в безопасной общей системе. Например, можно безопасно хранить и совместно использовать пароли с помощью 1Password или хранить ключи в Azure KeyVault и управлять доступом с помощью IAM (управление удостоверениями и доступом).
Если вы создаете рабочий процесс GitHub Actions, который должен получить доступ к API, вы можете хранить свои учетные данные в зашифрованном секрете и получить доступ к зашифрованным секретам из рабочего процесса. Дополнительные сведения см. в разделе "[AUTOTITLE" иИспользование секретов в GitHub Actions](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)".
Безопасное использование учетных данных проверки подлинности в коде
Никогда не закодируйте учетные данные проверки подлинности, такие как маркеры, ключи или секреты, связанные с приложением, в коде. Вместо этого рекомендуется использовать диспетчер секретов, например Azure Key Vault или HashiCorp Vault. Дополнительные сведения о защите учетных данных GitHub App см. в разделе "Рекомендации по созданию приложения GitHub".
При использовании personal access token в скрипте рассмотрите возможность хранения маркера в виде секрета GitHub Actions и запуска скрипта с помощью GitHub Actions. Вы также можете сохранить маркер в виде секрета Codespaces и запустить скрипт в пространствах codespaces. Дополнительные сведения см. в разделе "AUTOTITLE" и AUTOTITLE.
Если ни один из этих вариантов не существует, вы можете хранить учетные данные проверки подлинности в .env файле. Не забудьте зашифровать .env файл и никогда не отправлять его в любой репозиторий.
Подготовка плана исправления
Необходимо своевременно создать план для обработки любых нарушений безопасности. В случае утечки маркера или других учетных данных проверки подлинности вам потребуется:
- Создайте новые учетные данные.
- Замените старые учетные данные новым везде, где вы храните или обращаетесь к учетным данным.
- Удалите старые скомпрометированные учетные данные.
Сведения о смене скомпрометированных учетных данных для GitHub Appсм. в разделе "Рекомендации по созданию приложения GitHub".
Сведения о создании и удалении данных personal access tokens см. в разделе "Управление личными маркерами доступа".