Вместо этого используйте 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.
Авторизовать тщательно и надежно
После входа в систему разработчики приложений должны выполнить дополнительные действия, чтобы убедиться, что пользователь должен иметь доступ к данным в вашей системе. Для каждого входа требуются новые проверки членства, доступа и текущего состояния единого входа.
Использование устойчивого, уникального id для хранения пользователя
Проверка доступа организации для каждой новой проверки подлинности
При использовании маркера доступа пользователей следует отслеживать, для каких организаций авторизован маркер. Если организация использует единый вход SAML и пользователь не выполнил единый вход SAML, маркер доступа пользователя не будет иметь доступа к этой организации. Конечную точку GET /user/installations REST API можно использовать для проверки того, к каким организациям имеется доступ маркера доступа пользователей. Если пользователь не авторизован для доступа к организации, следует запретить доступ к данным организации в собственном приложении, пока не будет выполняться единый вход SAML. Дополнительные сведения см. в разделе Конечные точки REST API для установки GitHub App.
Хранение пользовательских данных с помощью контекстов организации и предприятия
Помимо отслеживания удостоверения пользователя с помощью id поля, необходимо сохранить данные для организации или предприятия, в которых работает каждый пользователь. Это поможет убедиться, что вы не утечете конфиденциальную информацию, если пользователь переключает роли.
Например:
- Пользователь находится в
Monaорганизации, для которой требуется единый вход SAML и вход в приложение после выполнения единого входа. Теперь ваше приложение имеет доступ к тому, что пользователь делает внутриMona. - Пользователь извлекает кучу кода из репозитория
Monaи сохраняет его в приложении для анализа. - Позже пользователь переключает задания и удаляется из
Monaорганизации.
Когда пользователь обращается к приложению, он по-прежнему видит код и анализ из Mona организации в учетной записи пользователя?
Поэтому важно отслеживать источник данных, сохраняемых приложением. В противном случае приложение является угрозой защиты данных для организаций, и они, скорее всего, запретят ваше приложение, если они не могут доверять, что ваше приложение правильно защищает свои данные.
Проверка доступа пользователя к приложению
Ваше приложение OAuth может получить доступ к пользователям за пределами вашей организации или предприятия. Если вы планируете использовать приложение только участниками вашей организации или предприятия, необходимо проверить состояние членства пользователя при входе пользователя в приложение.
Чтобы найти список организаций, в которые входит пользователь, можно использовать конечную точку "Список организаций для прошедших проверку подлинности пользователей". Затем вы можете проверить этот список в списке утвержденных организаций для вашего приложения. Дополнительные сведения см. в разделе Конечные точки REST API для организаций.
Примечание. Для GitHub.comдаже OAuth app, созданных управляемая учетная запись пользователя или организация с управляемыми пользователями можно получить доступ к пользователям за пределами предприятия.
Защита учетных данных приложения
С помощью секрета клиента приложение может авторизовать пользователя и создать маркеры доступа пользователей. Эти маркеры можно использовать для выполнения запросов API от имени пользователя.
Необходимо безопасно хранить секрет клиента приложения и все созданные маркеры. Механизм хранения зависит от архитектуры интеграции и платформы, на которой она работает. Как правило, следует использовать механизм хранения, предназначенный для хранения конфиденциальных данных на используемой платформе.
Секреты клиента
Если ваше приложение является веб-сайтом или веб-приложением, рассмотрите возможность хранения секрета клиента в хранилище ключей, например Azure Key Vault, или в качестве зашифрованной переменной среды или секрета на сервере.
Если ваше приложение является собственным клиентом, клиентским приложением или работает на пользовательском устройстве (в отличие от запуска на серверах), вы не сможете защитить секрет клиента. Если вы планируете получить доступ к собственным службам на основе маркеров, созданных приложением, следует будьте осторожны, так как любой пользователь может получить доступ к секрету клиента для создания маркера.
Маркеры доступа пользователей
Если приложение является веб-сайтом или веб-приложением, необходимо зашифровать маркеры на серверной части и обеспечить безопасность в системах, которые могут получить доступ к маркерам. Рассмотрите возможность хранения маркеров обновления в отдельном месте от активных маркеров доступа.
Если приложение является собственным клиентом, клиентским приложением или работает на пользовательском устройстве (а не на серверах), возможно, вы не сможете защитить маркеры, а также приложение, которое выполняется на серверах. Маркеры следует хранить с помощью механизма, рекомендуемого для платформы вашего приложения, и помните, что механизм хранения может быть не полностью безопасным.
Использование соответствующего типа токена
OAuth apps может создавать маркеры доступа пользователей для выполнения запросов API, прошедших проверку подлинности. Приложение никогда не должно использовать пароль personal access token или GitHub для проверки подлинности.
Создание плана по обработке нарушений безопасности
У вас должен быть план, чтобы вы могли своевременно обрабатывать любые нарушения безопасности.
Если секрет клиента вашего приложения скомпрометирован, вам потребуется создать новый секрет, обновить приложение, чтобы использовать новый секрет и удалить старый секрет.
В случае компрометации маркеров доступа пользователей следует немедленно отозвать эти маркеры. Дополнительные сведения см. в разделе Конечные точки REST API для авторизации OAuth.
Выполнение регулярных проверок уязвимостей
Выбор подходящей среды
Если приложение работает на сервере, убедитесь, что среда сервера безопасна и может обрабатывать объем ожидаемого трафика для приложения.
Безопасное использование служб
Если приложение использует сторонние службы, они должны использоваться в безопасном режиме:
- Все службы, используемые приложением, должны иметь уникальный вход и пароль.
- Приложения не должны совместно использовать учетные записи служб, такие как электронная почта или службы баз данных, для управления службой SaaS.
- Только сотрудники с административными обязанностями должны иметь доступ администратора к инфраструктуре, в которую размещается ваше приложение.
Добавление ведения журнала и мониторинга
Рассмотрите возможность добавления возможностей ведения журнала и мониторинга для приложения. Журнал безопасности может включать:
- события аутентификации и авторизации;
- изменения конфигурации службы;
- операции чтения и записи объектов;
- Изменения разрешений пользователей и групп
- повышение прав роли до администратора;
Журналы должны использовать согласованную метку времени для каждого события и записывать пользователей, IP-адреса или имена узлов для всех зарегистрированных событий.
Включение удаления данных
Если ваше приложение доступно другим пользователям, необходимо предоставить пользователям способ удаления своих данных. Чтобы удалить данные, пользователи не должны отправлять сообщения электронной почты или обращаться в службу поддержки.