Skip to main content

Enterprise Server 3.15 в настоящее время доступен в качестве кандидата на выпуск.

Обеспечение безопасности учетных данных API

Следуйте этим рекомендациям, чтобы обеспечить безопасность учетных данных и маркеров API.

Выбор подходящего метода проверки подлинности

Вы должны выбрать метод проверки подлинности, подходящий для задачи, которую вы хотите выполнить.

  • Чтобы использовать 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 секрет. Дополнительные сведения см. в разделе "[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. Дополнительные сведения см. в разделе "[AUTOTITLE".

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

Подготовка плана исправления

Необходимо своевременно создать план для обработки любых нарушений безопасности. В случае утечки маркера или других учетных данных проверки подлинности вам потребуется:

  • Создайте новые учетные данные.
  • Замените старые учетные данные новым везде, где вы храните или обращаетесь к учетным данным.
  • Удалите старые скомпрометированные учетные данные.

Сведения о смене скомпрометированных учетных данных для GitHub Appсм. в разделе "Рекомендации по созданию приложения GitHub".

Сведения о создании и удалении данных personal access tokens см. в разделе "Управление личными маркерами доступа".