Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы может все еще выполняться. Актуальные сведения см. в документации на английском языке.

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

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

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

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

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

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

Централизованная проверка подлинности

Если вы являетесь владельцем предприятия или организации, можно настроить централизованную проверку подлинности с помощью SAML. Хотя вы можете добавлять или удалять участников вручную, проще и безопаснее настроить единый вход (SSO) и SCIM между GitHub Enterprise Cloud и вашим поставщиком удостоверений SAML (IdP). Это также упрощает процесс проверки подлинности для всех участников вашего предприятия.

Вы можете настроить проверку подлинности SAML для учетной записи предприятия или организации. С помощью SAML вы можете предоставить доступ к личным учетным записям участников предприятия или организации в GitHub.com через поставщика удостоверений или создать учетные записи, принадлежащие вашему предприятию, и управлять ими с помощью Enterprise Managed Users. Дополнительные сведения см. в разделе Сведения о проверке подлинности для предприятия.

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

Некоторые поставщики удостоверений поддерживают протокол SCIM, который может автоматически подготавливать или отзывать доступ к GitHub Enterprise Cloud, когда вы вносите изменения в поставщик удостоверений. С помощью SCIM вы можете упростить администрирование по мере роста команды, а также быстро отзывать доступ к учетным записям. Стандарт SCIM доступен для отдельных организаций в GitHub Enterprise Cloud или для предприятий, использующих Enterprise Managed Users. Дополнительные сведения см. в статье Сведения об SCIM для организаций.

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

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

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

Если вы являетесь владельцем организации, то имеете возможность потребовать, чтобы все члены организации включили двухфакторную проверку подлинности.

Настройка корпоративной учетной записи

Владельцы предприятия имеют возможность требовать двухфакторную проверку подлинности для всех членов предприятия. Доступность политик двухфакторной проверки подлинности в GitHub Enterprise Cloud зависит от того, как выполняется проверка подлинности членов для доступа к ресурсам вашего предприятия.

Если ваше предприятие использует Enterprise Managed Users или для вашего предприятия применяется проверка подлинности SAML, вы не сможете настроить 2FA в GitHub Enterprise Cloud. Пользователь с административным доступом к вашему поставщику удостоверений должен настроить двухфакторную проверку подлинности для этого поставщика удостоверений.

Дополнительные сведения см. в разделах Сведения об управлении удостоверениями и доступом для вашего предприятия и Применение политик для параметров безопасности в организации.

Настройка личной учетной записи

Примечание. В зависимости от метода проверки подлинности, который владелец предприятия настроил для ваше предприятие в GitHub.com, возможно, вы не сможете включить 2FA для личной учетной записи.

GitHub Enterprise Cloud поддерживает несколько вариантов двухфакторной проверки подлинности, и хотя любой из них лучше, чем ничего, наиболее безопасным является WebAuthn. Для WebAuthn требуется аппаратный ключ безопасности или устройство, которое поддерживает его через такие приложения, как Windows Hello или Mac TouchID. Фишинг других форм двухфакторной проверки подлинности (например, кто-то просит вас прочитать 6 цифр одноразового пароля) возможен, хотя и затруднителен. Но WebAuthn не поддается фишингу, поскольку в протокол встроен контроль области домена, что предотвращает использование учетных данных с веб-сайта, выдающего себя за страницу входа, в GitHub Enterprise Cloud.

При настройке двухфакторной проверки подлинности следует всегда скачивать коды восстановления и настраивать несколько факторов. Это гарантирует, что доступ к учетной записи не будет зависеть от одного устройства. Дополнительные сведения см. в разделах Настройка двухфакторной проверки подлинности, Настройка методов восстановления двухфакторной проверки подлинности и Фирменные аппаратные ключи безопасности GitHub в магазине GitHub.

Настройка учетной записи организации

Примечание. В зависимости от метода проверки подлинности, который владелец предприятия настроил для ваше предприятие в GitHub.com, возможно, вы не сможете требовать 2FA для вашей организации.

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

  1. "Проверка включения 2FA у пользователей организации"
  2. Подготовка к включению обязательной двухфакторной проверки подлинности в организации
  3. Обязательная двухфакторная проверка подлинности в вашей организации

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

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

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

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

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

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