Выбор подходящего метода проверки подлинности
Вы должны выбрать метод проверки подлинности, подходящий для задачи, которую вы хотите выполнить.
- Чтобы использовать 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 процессе указывайте только минимальное количество необходимых разрешений. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.
Безопасное хранение учетных данных проверки подлинности
Обработайте учетные данные проверки подлинности так же, как и пароли или другие конфиденциальные учетные данные.
- Не делитесь учетными данными проверки подлинности с помощью незашифрованной системы обмена сообщениями или электронной почты.
- Не передавайте personal access token Your в виде обычного текста в командной строке. Дополнительные сведения см. в разделе Управление личными маркерами доступа.
- Не следует отправлять незашифрованные учетные данные проверки подлинности, такие как маркеры или ключи в любой репозиторий, даже если репозиторий является закрытым. Вместо этого рассмотрите возможность использования секрета GitHub Actions или секрета Codespaces. Для получения дополнительной информации смотрите Использование секретов в GitHub Actions и Управление секретами, специфичными для ваших аккаунтов, для GitHub Codespaces.
- Вы можете использовать сканирование секретов для обнаружения маркеров, закрытых ключей и других секретов, которые были отправлены в репозиторий, или блокировать будущие отправки, содержащие секреты. Дополнительные сведения см. в разделе Сведения о проверке секретов.
Ограничение доступа к учетным данным проверки подлинности
Не делитесь 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 или в другом месте, вы можете подать запрос на отзыв через REST API. См . раздел AUTOTITLE.
При использовании a personal access token в скрипте рассмотрите хранение токена в GitHub Actions секрете и запуск скрипта через GitHub Actions. Вы также можете хранить свой токен как секрет Codespaces и запускать скрипт в Codespaces. Для получения дополнительной информации смотрите Использование секретов в GitHub Actions и Управление секретами, специфичными для ваших аккаунтов, для GitHub Codespaces.
Если ни один из этих вариантов не существует, вы можете хранить учетные данные проверки подлинности в .env файле. Не забудьте зашифровать .env файл и никогда не отправлять его в любой репозиторий.
Подготовка плана исправления
Необходимо своевременно создать план для обработки любых нарушений безопасности. В случае утечки маркера или других учетных данных проверки подлинности вам потребуется:
- Создайте новые учетные данные.
- Замените старые учетные данные новым везде, где вы храните или обращаетесь к учетным данным.
- Удалите старые скомпрометированные учетные данные.
Для информации о ротации скомпрометированных учетных данных GitHub Appдля , см. Лучшие практики создания приложения на GitHub.
Для получения информации о создании и удалении personal access tokenсм. Управление личными маркерами доступа.