Skip to main content

Рекомендации по защите учетных записей

Руководство по защите учетных записей, которые имеют доступ к цепочке поставки программного обеспечения.

Об этом руководстве

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

В чем заключаются риски?

Безопасность учетных записей имеет важное значение для обеспечения безопасности цепочки поставок. Если злоумышленники перехватят контроль над вашей учетной записью GitHub AE, они затем смогут внести вредоносные изменения в ваш код или процесс сборки. Поэтому ваша первая цель должна заключаться в том, чтобы кто-то затруднил управление вашей учетной записью и учетными записями других участников вашей организации или предприятия.

Настройка двухфакторной проверки подлинности

Лучший способ повышения безопасности настраивает двухфакторную проверку подлинности (2FA) в поставщике удостоверений SAML (IdP). Пароли сами по себе могут быть скомпрометированы путем угадывания, в результате повторного использования на другом сайте, который был скомпрометирован, или с помощью методов социотехники, например фишинга. Двухфакторная проверка подлинности значительно усложняет компрометацию учетных записей, даже если у злоумышленника есть пароль.

Подключение к GitHub AE с помощью ключей SSH

Существуют и другие способы взаимодействия с GitHub AE помимо входа на веб-сайт через поставщик удостоверений. Многие пользователи авторизуют код, который они отправляют в GitHub, с помощью закрытого ключа SSH. Дополнительные сведения см. в разделе Сведения о SSH.

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

Другой вариант — создать ключи SSH в аппаратном ключе безопасности. Вы можете использовать тот же ключ, что и для двухфакторной проверки подлинности. Аппаратные ключи безопасности очень трудно скомпрометировать удаленно, так как закрытый ключ SSH остается на оборудовании и недоступен напрямую из программного обеспечения. Дополнительные сведения см. в разделе Создание нового ключа SSH для аппаратного ключа безопасности.

Аппаратные ключи SSH довольно безопасны, но требования к оборудованию могут не работать для некоторых организаций. Альтернативный подход заключается в использовании ключей SSH, которые действительны только в течение короткого периода времени, поэтому даже если закрытый ключ скомпрометирован, его не получится использовать очень долго. Эта концепция лежит в основе запуска собственного центра сертификации SSH. Хотя этот подход обеспечивает широкий контроль над проверкой подлинности пользователей, вам также придется самостоятельно обслуживать центр сертификации SSH. Дополнительные сведения см. в разделе Сведения о центрах сертификации SSH.

Дальнейшие действия