Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы может все еще выполняться. Актуальные сведения см. в документации на английском языке.

Рекомендации по обеспечению безопасности для приложений на Магазин GitHub

Рекомендации по подготовке безопасного приложения для предоставления общего доступа к GitHub Marketplace.

Примечание: Эта статья относится только к публикации GitHub Apps в GitHub Marketplace. Дополнительные сведения о публикации GitHub Actions в GitHub Marketplace см. в разделе Публикация действий в GitHub Marketplace.

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

Авторизация, проверка подлинности и контроль доступа

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

  • Приложения должны использовать принцип наименьших привилегий и запрашивать только те области OAuth и разрешения приложения GitHub, которые необходимы приложению для выполнения своих функций. Дополнительные сведения см. в статье Википедии Принцип наименьших привилегий.
  • Приложения должны предоставлять клиентам возможность удалить свою учетную запись без необходимости отправлять сообщения по электронной почте или обращаться в службу поддержки.
  • Приложения не должны совместно использовать маркеры в различных реализациях приложения. Например, классическое приложение должно иметь отдельный маркер от веб-приложения. Отдельные маркеры позволяют каждому приложению запрашивать доступ к ресурсам GitHub отдельно.
  • Разрабатывайте приложение с разными ролями пользователей в зависимости от функциональности, необходимой для каждого типа пользователя. Например, стандартный пользователь не должен иметь доступа к функциям администратора, а специалистам по выставлению счетов может не потребоваться доступ к отправке кода в репозиторий.
  • Приложения не должны совместно использовать учетные записи служб, такие как электронная почта или службы баз данных, для управления службой SaaS.
  • Все службы, используемые в приложении, должны иметь уникальные учетные данные с именем входа и паролем.
  • Права администратора на доступ к производственной инфраструктуре размещения должны предоставляться только инженерам и сотрудникам с административными обязанностями.
  • Приложения не должны использовать personal access tokens для проверки подлинности и должны проходить проверку подлинности как Приложение OAuth или Приложение GitHub:

Защита данных

  • Приложения должны шифровать данные, передаваемые через общедоступный Интернет, с помощью протокола HTTPS, действительного сертификата TLS или протокола SSH для Git.
  • Приложения должны безопасно хранить идентификатор клиента и секретные ключи клиента. Мы рекомендуем хранить их в виде переменных среды.
  • Приложения должны удалять все пользовательские данные GitHub в течение 30 дней после получения запроса от пользователя или в течение 30 дней после окончания юридических отношений пользователя с GitHub.
  • Приложения не должны требовать, чтобы пользователь предоставил свой пароль на GitHub.
  • Приложения должны шифровать маркеры, идентификаторы и секреты клиента.

Ведение журналов и мониторинг

Приложения должны иметь возможности ведения журнала и мониторинга. Журналы приложений должны храниться не менее 30 дней и архивироваться на период не менее одного года. Журнал безопасности должен включать следующие данные:

  • события аутентификации и авторизации;
  • изменения конфигурации службы;
  • операции чтения и записи объектов;
  • все изменения разрешений пользователей и групп;
  • повышение прав роли до администратора;
  • согласованные метки времени для каждого события;
  • исходные пользователи, IP-адреса и (или) имена узлов для всех зарегистрированных действий.

Рабочий процесс по реагированию на инциденты

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

Пример рабочего процесса реагирования на инциденты см. в разделе "Data Breach Response Policy" (Политика реагирования на нарушение безопасности данных) на веб-сайте Института SANS. Краткий документ с четкими действиями, которые необходимо предпринять в случае инцидента, является более полезным, чем длинный шаблон политики.

Рабочий процесс управления уязвимостями и исправлениями

Следует проводить регулярные проверки уязвимостей производственной инфраструктуры. Следует проанализировать результаты сканирования уязвимостей и определить период времени, в течение которого вы соглашаетесь устранить уязвимость.

Если вы не готовы сразу внедрить полную программу управления уязвимостями, можно начать с создания процесса установки исправлений. Рекомендации по созданию политики управления исправлениями см. в статье TechRepublic Establish a patch management policy (Внедрение политики управления исправлениями).

Дополнительные материалы