Примечание: Эта статья относится только к публикации 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:
- Приложения OAuth должны проходить проверку подлинности с помощью маркера OAuth.
- Приложения GitHub должны проходить проверку подлинности с помощью JSON Web Token (JWT), маркера OAuth или маркера доступа к установке.
Защита данных
- Приложения должны шифровать данные, передаваемые через общедоступный Интернет, с помощью протокола HTTPS, действительного сертификата TLS или протокола SSH для Git.
- Приложения должны безопасно хранить идентификатор клиента и секретные ключи клиента. Мы рекомендуем хранить их в виде переменных среды.
- Приложения должны удалять все пользовательские данные GitHub в течение 30 дней после получения запроса от пользователя или в течение 30 дней после окончания юридических отношений пользователя с GitHub.
- Приложения не должны требовать, чтобы пользователь предоставил свой пароль на GitHub.
- Приложения должны шифровать маркеры, идентификаторы и секреты клиента.
Ведение журналов и мониторинг
Приложения должны иметь возможности ведения журнала и мониторинга. Журналы приложений должны храниться не менее 30 дней и архивироваться на период не менее одного года. Журнал безопасности должен включать следующие данные:
- события аутентификации и авторизации;
- изменения конфигурации службы;
- операции чтения и записи объектов;
- все изменения разрешений пользователей и групп;
- повышение прав роли до администратора;
- согласованные метки времени для каждого события;
- исходные пользователи, IP-адреса и (или) имена узлов для всех зарегистрированных действий.
Рабочий процесс по реагированию на инциденты
Чтобы обеспечить безопасное взаимодействие с пользователями, необходимо иметь четкий план реагирования на инциденты до публикации приложения. Мы рекомендуем иметь собственную группу по безопасности и оперативному реагированию на инциденты в компании, а не обращаться к сторонним поставщикам этих услуг. Вы должны иметь возможность уведомлять GitHub в течение 24 часов после подтвержденного инцидента.
Пример рабочего процесса реагирования на инциденты см. в разделе "Data Breach Response Policy" (Политика реагирования на нарушение безопасности данных) на веб-сайте Института SANS. Краткий документ с четкими действиями, которые необходимо предпринять в случае инцидента, является более полезным, чем длинный шаблон политики.
Рабочий процесс управления уязвимостями и исправлениями
Следует проводить регулярные проверки уязвимостей производственной инфраструктуры. Следует проанализировать результаты сканирования уязвимостей и определить период времени, в течение которого вы соглашаетесь устранить уязвимость.
Если вы не готовы сразу внедрить полную программу управления уязвимостями, можно начать с создания процесса установки исправлений. Рекомендации по созданию политики управления исправлениями см. в статье TechRepublic Establish a patch management policy (Внедрение политики управления исправлениями).