Об этом руководстве
В этом руководстве описываются самые важные изменения, которые можно внести для повышения безопасности учетной записи. В каждом разделе описаны изменения, которые можно внести в процессы для повышения безопасности. Сначала указаны изменения с самым высоким влиянием.
В чем заключаются риски?
Безопасность учетных записей имеет важное значение для обеспечения безопасности цепочки поставок. Если злоумышленники перехватят контроль над вашей учетной записью GitHub AE, они затем смогут внести вредоносные изменения в ваш код или процесс сборки. Поэтому ваша первая цель должна заключаться в том, чтобы кто-то затруднил управление вашей учетной записью и учетными записями других участников вашей организации или предприятия.
Настройка двухфакторной проверки подлинности
Лучший способ повысить безопасность ваше предприятие на GitHub AE настраивает двухфакторную проверку подлинности (2FA) в поставщике удостоверений SAML (Поставщик удостоверений) . Пароли сами по себе могут быть скомпрометированы путем угадывания, в результате повторного использования на другом сайте, который был скомпрометирован, или с помощью методов социотехники, например фишинга. Двухфакторная проверка подлинности значительно усложняет компрометацию учетных записей, даже если у злоумышленника есть пароль.
Чтобы обеспечить безопасность и надежный доступ к учетной записи, рекомендуется всегда иметь по крайней мере два второго фактора учетных данных, зарегистрированных в вашей учетной записи. Дополнительные учетные данные гарантируют, что даже если вы потеряете доступ к одному из учетных данных, вы не будете заблокированы в своей учетной записи.
Подключение к GitHub AE с помощью ключей SSH
Существуют и другие способы взаимодействия с GitHub AE помимо входа на веб-сайт через поставщик удостоверений. Многие пользователи авторизуют код, который они отправляют в GitHub, с помощью закрытого ключа SSH. Дополнительные сведения см. в разделе Сведения о протоколе SSH.
Как и в случае с паролем для учетной записи у поставщика удостоверений, если злоумышленник получит ваш закрытый ключ SSH, он может выдать себя за вас и отправить вредоносный код в любой репозиторий, в котором у вас есть доступ на запись. Если вы храните закрытый ключ SSH на диске, рекомендуется защитить его с помощью парольной фразы. Дополнительные сведения см. в разделе Работа с парольными фразами ключа SSH.
Другой вариант — создать ключи SSH в аппаратном ключе безопасности. Вы можете использовать тот же ключ, что и для двухфакторной проверки подлинности. Аппаратные ключи безопасности очень трудно скомпрометировать удаленно, так как закрытый ключ SSH остается на оборудовании и недоступен напрямую из программного обеспечения. Дополнительные сведения см. в разделе Создание нового ключа SSH и его добавление в ssh-agent.
Аппаратные ключи SSH довольно безопасны, но требования к оборудованию могут не работать для некоторых организаций. Альтернативный подход заключается в использовании ключей SSH, которые действительны только в течение короткого периода времени, поэтому даже если закрытый ключ скомпрометирован, его не получится использовать очень долго. Эта концепция лежит в основе запуска собственного центра сертификации SSH. Хотя этот подход обеспечивает широкий контроль над проверкой подлинности пользователей, вам также придется самостоятельно обслуживать центр сертификации SSH. Дополнительные сведения см. в разделе Сведения о центрах сертификации SSH.