Вместо этого используйте GitHub App
Если это возможно, попробуйте использовать GitHub App вместо OAuth app. Как правило, GitHub Apps предпочтительнее OAuth apps. GitHub Apps используют подробные разрешения, дают пользователю больше контроля над тем, к каким репозиториям приложение может получить доступ и использовать короткие маркеры. Эти свойства могут затвердить безопасность вашего приложения, ограничив ущерб, который можно сделать, если учетные данные вашего приложения просочились.
Как и OAuth apps, GitHub Apps по-прежнему может использовать OAuth 2.0 и создавать тип маркера OAuth (называемый маркером доступа пользователя) и выполнять действия от имени пользователя. Однако GitHub Apps также может действовать независимо от пользователя.
Дополнительные сведения о GitHub Appsсм. в разделе "Создание приложений GitHub".
Дополнительные сведения о переносе существующих данных OAuth app на GitHub Appсм. в разделе "Перенос приложений OAuth в приложения GitHub".
Использование минимальных область
Ваши OAuth app должны запрашивать только область, необходимые приложению для выполнения своих предполагаемых функций. Если какие-либо маркеры для приложения скомпрометируются, это приведет к ограничению объема ущерба, который может произойти. Дополнительные сведения см. в разделе Авторизация приложений OAuth.
Защита учетных данных приложения
С помощью секрета клиента приложение может авторизовать пользователя и создать маркеры доступа пользователей. Эти маркеры можно использовать для выполнения запросов API от имени пользователя.
Необходимо безопасно хранить секрет клиента приложения и все созданные маркеры. Механизм хранения зависит от архитектуры интеграции и платформы, на которой она работает. Как правило, следует использовать механизм хранения, предназначенный для хранения конфиденциальных данных на используемой платформе.
Секреты клиента
Если ваше приложение является веб-сайтом или веб-приложением, рассмотрите возможность хранения секрета клиента в хранилище ключей, например Azure Key Vault, или в качестве зашифрованной переменной среды или секрета на сервере.
Если ваше приложение является собственным клиентом, клиентским приложением или работает на пользовательском устройстве (в отличие от запуска на серверах), вы не сможете защитить секрет клиента. Если вы планируете получить доступ к собственным службам на основе маркеров, созданных приложением, следует будьте осторожны, так как любой пользователь может получить доступ к секрету клиента для создания маркера.
Маркеры доступа пользователей
Если приложение является веб-сайтом или веб-приложением, необходимо зашифровать маркеры на серверной части и обеспечить безопасность в системах, которые могут получить доступ к маркерам. Рассмотрите возможность хранения маркеров обновления в отдельном месте от активных маркеров доступа.
Если приложение является собственным клиентом, клиентским приложением или работает на пользовательском устройстве (а не на серверах), возможно, вы не сможете защитить маркеры, а также приложение, которое выполняется на серверах. Маркеры следует хранить с помощью механизма, рекомендуемого для платформы вашего приложения, и помните, что механизм хранения может быть не полностью безопасным.
Использование соответствующего типа токена
OAuth apps может создавать маркеры доступа пользователей для выполнения запросов API, прошедших проверку подлинности. Приложение никогда не должно использовать пароль personal access token или GitHub для проверки подлинности.
Создание плана по обработке нарушений безопасности
У вас должен быть план, чтобы вы могли своевременно обрабатывать любые нарушения безопасности.
Если секрет клиента вашего приложения скомпрометирован, вам потребуется создать новый секрет, обновить приложение, чтобы использовать новый секрет и удалить старый секрет.
В случае компрометации маркеров доступа пользователей следует немедленно отозвать эти маркеры. Дополнительные сведения см. в разделе Конечные точки REST API для авторизации OAuth.
Проверка доступа пользователя к организациям
Ваше приложение OAuth может получить доступ к пользователям за пределами вашей организации или предприятия. Если вы планируете использовать приложение только участниками вашей организации или предприятия, необходимо проверка состояние членства пользователя при входе пользователя в приложение.
Чтобы найти список организаций, в которые входит пользователь, можно использовать конечную точку "Список организаций для прошедших проверку подлинности пользователей". Затем вы можете проверить этот список в списке утвержденных организаций для вашего приложения. Дополнительные сведения см. в разделе Конечные точки REST API для организаций.
Примечание. Даже данные OAuth app , созданные управляемая учетная запись пользователя или организация с управляемыми пользователями могут быть доступны пользователям за пределами предприятия.
Выполнение регулярных проверок уязвимостей
Выбор подходящей среды
Если приложение работает на сервере, убедитесь, что среда сервера безопасна и может обрабатывать объем ожидаемого трафика для приложения.
Безопасное использование служб
Если приложение использует сторонние службы, они должны использоваться в безопасном режиме:
- Все службы, используемые приложением, должны иметь уникальный вход и пароль.
- Приложения не должны совместно использовать учетные записи служб, такие как электронная почта или службы баз данных, для управления службой SaaS.
- Только сотрудники с административными обязанностями должны иметь доступ администратора к инфраструктуре, в которую размещается ваше приложение.
Добавление ведения журнала и мониторинга
Рассмотрите возможность добавления возможностей ведения журнала и мониторинга для приложения. Журнал безопасности может включать:
- события аутентификации и авторизации;
- изменения конфигурации службы;
- операции чтения и записи объектов;
- Изменения разрешений пользователей и групп
- повышение прав роли до администратора;
Журналы должны использовать согласованную метку времени для каждого события и записывать пользователей, IP-адреса или имена узлов для всех зарегистрированных событий.
Включение удаления данных
Если ваше приложение доступно другим пользователям, необходимо предоставить пользователям способ удаления своих данных. Чтобы удалить данные, пользователи не должны отправлять сообщения электронной почты или обращаться в службу поддержки.